Bottom-up adoption through the prism of Flow
- 1. Bottom-up Adoption Through the Prism Of Flow Steve Carter @sweavo
- 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
- 3. Variability Queue Lengths Synchronization Flow Batch Size Work In Progress Feedback
- 4. Variability Queue Lengths Synchronization Flow Batch Size Work In Progress Feedback
- 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
- 7. Capacity Utilization and queues Percent Utilization Queue Length 80% 90%
- 8. Capacity Utilization and queues Percent Utilization Queue Length 80% 90%
- 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
- 10. Batch Size
- 11. Batch Size Project Duration Percentage Overrun
- 12. WIP +WIP +Utilization ++Queues +++Delay
- 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.
- 14. Cross-functional Synchronization AKA: “handoffs are bad, m’kay?” 1 2 3 4 5
- 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?
- 28. NO (To the nearest whole answer)
- 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
Editor's Notes
- #2: Team is trying to “do agile” Org doesn’t understand agile “Flow” is a concept from a book by Donald Reinertsen
- #3: 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
- #4: Gives a rational underpinning to product development practices Endorses much of agile Royd For the details… (click)
- #5: Here comes a quick and inadequate introduction
- #6: 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!)
- #7: 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
- #8: 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]
- #9: 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.
- #10: (next slide is diagram)
- #12: Not just by more absolutely, but by a larger proportion
- #14: 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: Handoffs are bad m’kay By synchronising in a cross functional meeting, you could improve throughput by a factor of 8
- #16: 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.
- #18: 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
- #19: 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
- #20: 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
- #25: 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
- #27: 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
- #28: Reinertsen: 95% percent of orgs with stage gates operate a second, unofficial process.
- #29: 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.