Flow by Donald Reinertsen offers insights into how scrum should work. Considering the scenario of a team trying to "go agile" within a large corporate environment, What insights does Flow grant us?
2. Who he?
• Steve Carter
• Software Developer
– In a small team
– On a large project
– For a large org
• People Person
• Scrum master
• Culture hacker
@sweavo
sweavo@gmail.com
5. Variability
• Generally bad
• Scrum and Kanban (lean manufacturing) try to
eliminate variability
• Flow-based approach acknowledges variability
and seeks to make better decisions
– In product development, variability is not going
away, like it can in manufacturing.
6. Queue Lengths
• Once started, knowledge work starts to age
– (market or technology moves on)
• Better to start later than to commit then delay
• Queues delay work
– For all the items in the queue
• Cost is worse than linear in the queue length
9. Batch Size
• How much stuff must you complete before
(handing off to next step / making money /
getting feedback)
• Economies of scale, vs. economies of learning,
feedback, and reduced cost of doing things
you do often
13. Feedback
• In terms of customer feedback, yes
• But also in terms of control signals
• e.g. a queue reaching its limit might signal
upstream to slow down and/or a
reassignment of resources.
15. Backlogs
Scrum
Story Slicing
Taskboard
Timeboxes
Standups
Review
Scrummaster
Scrum Master
Team
16. Product Backlog
• Not a queue
– Minimal holding cost
– Work is focused on the top priority stories
• Unless someone committed to the whole
backlog: Then it’s a queue!
17. Story Slicing
• Reduce batch size
– Lower schedule variability
– More timely feedback
• Variability pooling
– Win some, lose some
• Decomposition on the level of product
behaviour
– Not work breakdown
18. Sprint Backlog
• Limits batch size
– If slicing is working
– If you do refuse large stories
– Unless a manager keeps negotiating up the sprint
commitment
• (loose) limit on WIP
– Unless you have to take on, e.g. support queries
mid-sprint
• Is a queue
19. Task Board
• Todo and Doing are queues
• Doing is WIP
– “snowplough” pattern tries to limit WIP more
– Unless “can someone start this one? I just want to
see some progress”
20. Timeboxes
• Limit variability
– Time-based review always happens.
– Unless “we’re not reviewing it until it’s complete”
• “if you base reviews on scope rather than time, then
the projects in trouble get reviewed less”—Reinertsen
21. Daily Standup
• Allows resources to be redeployed to
bottlenecks
– Unless manager makes sure everybody has a job
to do
• Synchronization across functions
– Unless your team is not cross-functional
– Or your PO does not attend/engage in standups
22. Sprint Review
• Demonstration of behavior gets fast feedback
– Unless customer/PO is not present or engaged
– Remote customer can mean handoffs between
feature team and end-user, and delays in feedback
23. Scrum Master
• Shields the team from additional WIP
– Unless is “just a dev with a baseball cap on”
• Nurtures the adoption of good practice
– Optimize whole system
– Unless Scrum is regarded as “something teams
do”
24. The Team
• Colocated, cross-functional, Self-organising
– Fast feedback,
– Synchronization
– (Almost) no queue
– Reallocates to address bottlenecks
• Unless
– “use this team in India for testing”
– WIP=team size, then you have a group of soloists
sitting near one another, not a team
25. Backlogs
MIA?
Story Slicing
Taskboard
Timeboxes
Standups
Review
Scrummaster
Scrum Master
Team
26. Suboptimization
• Flow shows us that “whole system”
optimization is the rational way to optimize
profit.
• “Agile in a bubble”: if the company is not
paying attention to batch size of requests and
feedback, it’s unlikely that the development
engine will satisfy the business.
27. Culture Change
• There are significant harmful behaviors
encouraged by BDOs, e.g.
– work harder to perfect the spec
– insert stage gates
– push team to high utilization
• Can these issues be addressed from the
bottom up?
29. Culture Change as a flow problem
• Subject to handoffs up and down Org Chart
– Loss or corruption of message
• Cross-functional meetings might help
– More levels of management present
5
4
3
2
1
30. Culture Change as a flow problem
• People with different department heads do
not have a common goal
– Overhead in uncovering others’ motivations and
getting buy-in
• Get them To Read Reinertsen?
– Large batch size
31. Batch Size Of Culture Change
• How many elements need to be in place for
success?
• Can you get better results than now with
fewer elements?
• Start with visualizing work and reducing batch
size of work.
• Even that can be a hard sell.
32. Work with Suboptimization?
• Instead of “lifetime profitability” go with a
campaign of small victories.
– With success you will get the ear of management
• Go in with eyes open
– Success in one project might not translate to
another
– Watch batch size, queues, capacity utilization
• Depends on your company’s and your
customer’s culture
33. Takeaways
• Read the book!
– Beware of large batches
– watch your queues
– Keep utilization low (70%-80% busy)
• Look for small success stories
• Without manager buy-in, success is limited
34. Thanks!
Script and slides on sweavo.wordpress.com
Tweet or DM me feedback @sweavo
@NewRedo
Notas do Editor
Team is trying to “do agile”
Org doesn’t understand agile
“Flow” is a concept from a book by Donald Reinertsen
7 years in project
Nominated scrum master
No real success stories
Without these, hard to get management and partners to change behaviour to help throughput
Forced to continue learning in order to make more persuasive arguments
Gives a rational underpinning to product development practices
Endorses much of agile
Royd
For the details… (click)
Here comes a quick and inadequate introduction
How length / effort of your activities might vary.
Scrum and Kanban (lean manufacturing) try to eliminate variability
Flow-based approach acknowledges variability and seeks to make better decisions
(but no time for that tonight!)
Once started, knowledge work starts to age
(market or technology moves on)
Better to start later than to commit then delay
More recent knowledge
Avoid leaving tech debt in case of expedite item
Queues delay work
For all the items in the queue
Cost is worse than linear in the queue length
This is the closest to the curve I could get with powerpoint!
Utilization is how busy your people are.
The knee in the curve is the key in the face of variability.
Not only do your queues start to get longer, but now variability starts to hurt you more: [click]
Here where you get a slight variation, you get a Much longer queue
One of the insights of flow: keep utilization low because variability is not going away.
(next slide is diagram)
Not just by more absolutely, but by a larger proportion
In terms of customer feedback, yes
But also in terms of control signals
e.g. a queue reaching its limit might signal upstream to slow down and/or a reassignment of resources.
Handoffs are bad m’kay
By synchronising in a cross functional meeting, you could improve throughput by a factor of 8
So, what does scrum look like through the concepts of flow?
I’m going to go through a bunch of scrum artifacts and show how they actually function
… and in italics, add some things that BDOs do that break it.
Reduce batch size
Lower schedule variability
More timely feedback
Variability pooling
Win some, lose some
Series of small items is lower variability than one large one
Decomposition on the level of product behaviour
not work breakdown
Limits batch size
If slicing is working
If you do refuse large stories
[click]Unless a manager keeps negotiating up the sprint commitment
(loose) limit on WIP
[click]Unless you have to take on, e.g. support queries mid-sprint
Is a queue
Todo and Doing are queues
Doing is WIP
“snowplough” pattern tries to limit WIP more
Unless “can someone start this one? I just want to see some progress”
- Ruins collaboration
Colocated, cross-functional, Self-organising
Fast feedback,
Synchronization
(Almost) no queue
Reallocates to address bottlenecks
Unless
“use this team in India for testing”
WIP=team size, then you have a group of soloists sitting near one another, not a team
Flow shows us that “whole system” optimization is the rational way to optimize profit.
“Agile in a bubble”: if the company is not paying attention to batch size of requests and feedback, it’s unlikely that the development engine will satisfy the business.
“Implement the whole of this international standard and don’t show me till it’s done”
Without increased information for steering, you’re not iterating, just oscillating
Reinertsen: 95% percent of orgs with stage gates operate a second, unofficial process.
I started to look at what I needed to get in place to get Flow working, and started to realize I could frame some of that as a flow problem.
