Flow Mapping by Amber Haley

1 of 59

Slide Notes

Flow Mapping

Published on Jan 12, 2016

Please contact me if you'd like to re-use this deck! Happy to share and support you in using this cool technique :)

At it's heart; Flow Mapping is a communication tool. It can be used as a method to create Living documentation of system architecture

The technique allows architects, developers and business people to be on the same page with their understanding of progress through the development of a feature or service, as well as making a fundamentally complex, intangible system idea intellectually graspable at any level of the business.

View Outline

PRESENTATION OUTLINE

FLOW MAPPING

Mapping user stories to complex interactions

Hello, World! I am Amber.

agilist | scrum professional | massive nerd | origami-nut | @miss_ _haley

I am your friendly neighbourhood agile happy person.
I have been working with development teams in IT and beyond for 13 years, and been a specialist in scrum, agile, and website e2e implementation a further 8 years.

You can find more at:
https://about.me/hyperaktiv

i'll tell a story

of mishaps, miscommunication,
poor planning,
(add the name of your problem here)...

but never fear it has a happy ending.

Picture this:
World changing product
3 agile teams
Waterfall stakeholders
Silo'd team areas
No cross-functionality
OK communication

Data heavy with realtime tracking and processing required

Soft launch date in 3weeks... eek

3 confirmed beta clients

10.

Current data uploading is going well

The ongoing bulk import of current data is functional, and they have run some tests of stopping data flow for 5 days and then seeing if the system can catch back up...

11.

...ish

and then there's historical data...

12.

so they decided that now was the time..
time to up the stakes.

The moment they started with historical data, the problems more or less started right away right away...

13.

10 days of data processed

BUT there were no hiccups. Which is why they started to think they might just pull this off...

14.

20 days of data

The moment they started with historical data, the problems more or less started right away right away...

15.

...
getting weirdness

The Enricher wasn't able to process data as fast as they were pushing it in and got blocked up.

16.

1 month out of the promised year of data processed...

17.

processing halts

18.

multiple failures.

And no restarting was possible. Tried. NOPE.

Essentially, the current architecture meant the processor was crumbling under the weight of the data it had to deal with.

19.

Untitled Slide

Photo by star5112

20.

This was a recipe for disaster

but no one realised....

In this instance a team of smart mind came up with excellent system architecture build for scaling.... but didn't think to take this view to a more granular level

Photo by RobertFrancis

21.

Software architecture is an "intellectually graspable"
abstraction of a complex system.

We need architectural planing. Period. Not planning a system as abstract and complex as a web app, or a load balancer... or and Native smart device app is suicide.

22.

this is a good start

23.

But we rely on this:

We need architecture. Period. Not planning a system as abstract and complex as a web app, or a load balancer... or and Native smart device app is suicide.

24.

What the hell

is intellectually graspable about this???

25.

Untitled Slide

Photo by star5112

30.

Dependencies are not revealed through a flat back log.

31.

So how can we expose dependency?

And do other cool things like add depth to the backlog?

32.

What the hell?

.. is flow mapping?

Photo by Beatnik Photos

33.

In 2010 I saw my first Flow map... and fell in love

34.

..it's many things

process overview.
dependency early warning system.
living documentation tool.
it's a method to give context to the backlog.
a way to link architecture to implementation.
It helps with contextual planning and implementation

35.

The "map" arranges system architecture in order of priority of events (or "the order in which you would describe activities to explain the behaviour of the system").
Identifying touch-points with other areas of your internal and external systems and what the start and end points are.

This slide is pretty self explanatory, really...

36.

Too many words

ESSENTIALLY, it's a plan that slices through a process from end to end.

37.

It's a little big picture

..a current snapshot of the riskiest part of a software process or service

Photo by Adam Melancon

38.

well that's nice

..but why would I use this?

Photo by Ksayer1

39.

How do would we have averted Company X's disaster?

The Agile Straw Man

Photo by digitalshay

40.

ID the most critical part of your software

Start with the part that is the system killer.
Go through it action by action.
Add depth by going beyond just the process.

41.

Step 1

Find the most risky part of the system.

Photo by minifig

42.

Which part is gonna cause rageface if it fails?

Photo by poltrainfat

43.

Find it and figure out how to fix it...

44.

Step 2

Engage.

Photo by DailyPic

45.

Get everyone together and plan out the new..

46.

Step 3

Populate it - epics/stories/technical debt

Break down high goal level tasks into:
• Sub-tasks
• Alternative tasks
• Exceptions
• Details
Down in the details of the map, it’s OK to include details about what UI might look like or what the system might do in the background.

47.