Downloaded 15 times
Uploaded byAndrew Rusling
21 Experiments to Increase Throughput
The document outlines 21 experiments aimed at increasing throughput by reducing utilization, batch size, and item size through principles derived from queuing theory and the theory of constraints. It emphasizes agile methodologies, such as scrum and kanban, to enhance development efficiency and provides specific experiments to implement these concepts. Additionally, it offers a structured approach to identify and address constraints within workflows to further improve productivity.
More Related Content
Similar to 21 Experiments to Increase Throughput
21 Experiments to Increase Throughput
- 1. 21 Experiments to increase yourthroughput www.journey-to-better.com
- 3.
- 7.
- 8.
- 9.
- 10.
- 11. Chaos in development •Rushing • Competing • Shifting goals • Misalignment • Indecision • Shortcuts
- 12. Source of Experiments TwoTheories Four Principles 21 Experiments www.journey-to-better.com
- 13.
- 14.
- 15. Serious math Not fortoday www.journey-to-better.com
- 16. Simple principles To increasethroughput, reduce www.journey-to-better.com Utilisation Batch Size Item Size
- 17. System with Variability Whyreduce utilisation? www.journey-to-better.com Throughput Cycle Time Resource Utilisation
- 18. Tipping point Utilisation0 100 CycleTime TippingPoint Some examples: • Computer CPU • Building Fire Exit • Road
- 19. Tipping Point inaction www.journey-to-better.com
- 20. Why reduce batchsize? Littles Law Avg. Cycle Time = Work In Progress (WIP) Avg. Throughput www.journey-to-better.com Throughput Cycle Time WIP Batch Size
- 21. Why reduce itemsize? www.journey-to-better.com Throughput Queue Size (WIP) Item Size Predictability Bad Variability Cycle Time
- 22. Improving freeway throughput Imageby Atlantacitizen at the English language Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=1811360
- 23. Reducing utilisation www.journey-to-better.com Image by:https://www.flickr.com/photos/highwaysagency/ • Radio messages • Signs • Promote Car Pooling • Promote Public Transport • Tolls • High Taxes and fees • Limit access by registration • Add more lanes
- 24. Reducing batch size Imageby: https://www.flickr.com/photos/29233640@N07/ www.journey-to-better.com • Control entry points • Stagger work times • Multi nucleolus city
- 25. Reducing item size Imageby: https://www.flickr.com/photos/null0/ Replace Buses with Cars, Cars with Bikes. www.journey-to-better.com
- 26. Queuing Theory is bakedinto Agile, Scrum & Kanban www.journey-to-better.com Good news! Image by: https://www.flickr.com/photos/jeffrey
- 27. Queuing Theory inagile agile lowers Utilization by • Promoting sustainable development. • Customer collaboration. agile lowers Batch Size by • Focus on early delivery of Working Software. agile lowers Item Size by • Focus on simplicity & business feedback. www.journey-to-better.com
- 28. Queuing Theory inScrum Scrum lowers Utilization by • Team members 100% allocated. • Team pulls in work to sprint. Scrum lowers Batch Size by • Sprint length. Scrum lowers Item Size by • Time boxing & D.O.D. www.journey-to-better.com
- 29. Queuing Theory inKanban How does Kanban lower Utilization? • Pull approach. • Limiting WIP. How does Kanban lower Batch size? • Limiting input queues. How does Kanban lower Item size? • Building a dry stone wall approach… www.journey-to-better.com
- 30.
- 31. Utilisation experiments • Pullin less work (-20%) • Commit to less team hours (-20%) • Limit # of I.P. User Stories (p/2) • Show requesters your team board
- 32. Batch size experiments •Split up Releases (½) • Split up Epics/Features (3 to 12) • Shorten your Sprints (-1w)
- 33. Item Size Experiments •Split up your User Stories (# in sprint ~= p) • Use Spikes • Practice Simplicity • Split up your Tasks (max 1d)
- 34. To increase throughput: Lower Utilisation Workon smaller batches Work on smaller items Queuing Theory Summary www.journey-to-better.com
- 35.
- 36. r0002 | flagstaffotos.com.auCanon20D + Canon 400mm f/5.6 L - Own L 1.2, https://commons.wikimedia.org/w/index.php?curid=5305901 Why add just one lane?
- 37. Why not replacethem?
- 38. Focusing our efforts www.journey-to-better.com Idea Process A Process B Process C Customer •A? • B? • C? • A, B & C? • Need more info?
- 39. Focusing our efforts 5units per week 2 units per week 3 units per week www.journey-to-better.com Idea Process A Process B Process C Customer • A? • B? • C? • A, B & C? • Need more info?
- 40. Theory of Constraints(TOC) "a chain is no stronger than its weakest link“ Improving strong links, does not strengthen the chain. To achieve more of your goal, improve your weakest link. www.journey-to-better.com
- 41. Five Focusing Steps Constraint 1.Identify the constraint 2. Cheap changes 3. Align everyone 4. Expensive changes 5. Repeat
- 42. Applying TOC inagile We are going to: 1. Map team workflow 2. Populate an agile team board 3. Use TOC to increase throughput www.journey-to-better.com
- 43. Backlog Analysis CodingReview Testing Accept Done Map team workflow www.journey-to-better.com
- 44. Backlog Analysis CodingReview Testing Accept Done Populate with current state www.journey-to-better.com
- 45. 1. Identify theconstraint Symptoms • Work waiting in front of the constraint. • Resource is heavily stressed. • Starvation downstream. www.journey-to-better.com Constraint
- 46. Backlog Analysis CodingReview Testing Accept Done Where is the constraint? www.journey-to-better.com
- 47. Backlog Analysis CodingReview Testing Accept Done Doing Ready Split Testing column 1st Possibility www.journey-to-better.com
- 48. Backlog Analysis CodingReview Testing Accept Done Doing Ready Split Testing column 2nd Possibility www.journey-to-better.com
- 49. Backlog Analysis CodingReview Testing Accept Done Doing ReadyDoing ReadyDoing ReadyDoing Ready Split all other columns www.journey-to-better.com
- 50. 2. Cheap Changes Someexperiments: • Shield them from interruptions. • Limit their WIP. • Reduce their non value adding work. No overtime! www.journey-to-better.com
- 51. Backlog Analysis CodingReview Testing Accept Done Doing ReadyDoing ReadyDoing ReadyDoing Ready (5) Cheap Changes Limit WIP in Testing www.journey-to-better.com
- 52. Backlog Analysis CodingReview Testing Accept Done Doing ReadyDoing ReadyDoing ReadyDoing Ready (5) Let it run Constraint remains www.journey-to-better.com
- 53. 3. Align everyone Someexperiments: • Limit WIP of upstream to match. • Upstream do preparation work. • Upstream improve their quality. • Pair upstream with constraint staff. www.journey-to-better.com
- 54. Backlog Analysis CodingReview Testing Accept Done Doing ReadyDoing ReadyDoing ReadyDoing Ready (5)(5)(5)(5) Align everyone Match upstream WIP to constraint Devs do more test prep work. Dev-QA pairing www.journey-to-better.com
- 55. Backlog Analysis CodingReview Testing Accept Done Doing ReadyDoing ReadyDoing ReadyDoing Ready (5)(5)(5)(5) Let it run Constraint remains www.journey-to-better.com
- 56. 4. Expensive Changes Someexperiments: • Improve their tools. • Improve their environment. • Improve their team work. • Hire more people. www.journey-to-better.com
- 57. Backlog Analysis CodingReview Testing Accept Done Doing ReadyDoing ReadyDoing ReadyDoing Ready (5)(5)(5)(5) Expensive Changes Improve tools (reduce manual effort) Get Devs to help execute tests Hire another tester www.journey-to-better.com
- 58. Backlog Analysis CodingReview Testing Accept Done Doing ReadyDoing ReadyDoing ReadyDoing Ready (5)(5)(5)(5) Let it run Constraint has been broken www.journey-to-better.com
- 59. 5. Repeat • Thebottleneck should now have shifted. • Start all over again. www.journey-to-better.com
- 60. Q&A Contact: andrewrusling@hotmail.com @andrewrusling Slides:http://bit.ly/21ExperimentsToImproveYourThroughput
- 61. QT Experiment Summary •Pull in less work (-20%) • Commit to less team hours (-20%) • Limit # of I.P. User Stories (people/2) • Show requesters your Scrum board • Split up Releases (½) • Split up Epics/Features (3 to 12 sub items) • Shorten your Sprints (-1 week) • Split up your User Stories (# in sprint ~= people) • Use Spikes • Practice Simplicity • Split up your Tasks (max 1d)
- 62. TOC Experiment Summary •Shield them from interruptions. • Limit their WIP. • Reduce their non value adding work. • Limit WIP of upstream to match. • Upstream do preparation work. • Upstream improve their quality. • Pair upstream with constraint staff. • Improve their tools. • Improve their environment. • Improve their team work. • Hire more people.
Editor's Notes
- #5 Sparks shoot out of my laptop and it bursts into flames http://safety.lovetoknow.com/Electrical_Safety_Tips_at_Home https://commons.wikimedia.org/wiki/File:Burned_laptop_secumem_11.jpg
- #6 The flames spread, engulfing the desk/podium and starting to spread https://commons.wikimedia.org/wiki/File:Burned_laptop_secumem_14.jpg
- #7 Thick choking smoke billows forth, and starts to fill the room
- #8 The lights go out, while the fire and smoke intensifies.
- #9 At any stage during that did you think about running for the exit?
- #10 I am guessing many of you did and chaos would have ensued. http://ibsc.org.in/ - blue bottleneck https://www.flickr.com/photos/diariocriticove/ - shopping crowd rush – blurry
- #11 Why do intelligent, rational people in pressure situations, act in ways that cause chaos? It is in our nature, and because of that chaos, regularly occurs in software development
- #12 So can I please see a show of hands if you have experienced chaos in software development It seems many of you have experienced the chaos that prompted me to develop this presentation. Today I am going to share with you 21 experiments for applying Queuing Theory and the Theory of Constraints to help reduce the chaos that often exists in software development. Some of the many causes of Chaos: Limited capacity Multiple stakeholders Unclear direction Rewarded individually Changing customer needs Infrequent releases
- #13 The 21 experiments I mentioned come from four principles, And those principles are founded on Queuing Theory and TOC. I am going to explain the theories, principles and then the experiments.
- #15 Q: How many phone lines will the Copenhagen Telephone exchange need to handle peak load? A: Paper published by Agner Krarup Erlang in 1909
- #18 Queuing Theory says that in a system with variability, increased resource utilisation leads to an increase in cycle time. Past a tipping point the increase in cycle time is exponential.
- #20 Utilisation above the tipping point, (just one more car), created unevenness, created delays, greatly increased cycle time. Shockwave Traffic Jam Video Link: http://www.youtube.com/watch?v=Suugn-p5C1M
- #21 Large batches increase WIP, which increases Cycle time, which usually reduces Throughput.
- #22 Large items take longer to process, leading to: Queues (extra WIP) Variability (the bad kind)
- #26 When it is busy who gets through the traffic fastest? Truck, car or motorcycle? So smaller items can be processed faster.
- #27 Early delivery of working software is not possible with large batches.
- #28 A Focus on Customer Collaboration, allows the team to work on customers top priorities; instead of working on everything at once. Early delivery of working software is not possible with large batches.
- #29 Team pulls in work to sprint, leaving some capacity for unknowns. i.e. Less than the tipping point. Sprint length limits the batch size. i.e. max sprint length is 4 weeks which is a significantly smaller batch than waterwall projects, even incremental project. Then a 2 week sprint is half size of 4 week sprint.
- #32 Roughnecks reduced their SP, increasing their throughput, then reduced it again and increases throughput again. Astronauts committed to less hours, completed all stories in sprint for first time. Rocketeers limited their # stories IP and shipped on an extra platform over the crucial Christmas period.
- #33 ? ? Rebel Alliance went from 2w sprints to 1w sprints while they were prototyping for a new game, so that they could learn much faster.
- #34 ? ? Simplicity (Show your customers stories that you are think are too small, see if it provides them value) ?
- #37 Hands up if you have been stuck in traffic like this, as it crawls along? When the government decides enough is enough and swings into action to address the bottleneck, have you ever wondered why they go through all of that time and effort to just widen it by one lane? Why don’t they widen it by two lanes or even three? Surely that would be cheaper and more efficient in the long run? I sure have.. The reason why they one add one extra lane became clear to me once I learnt about the Theory of Constraints.
- #38 A very different example of TOC. In 2008 I was working in a small company building internet banking, it was significant contract for the company. The tester we had in our team was young and inexperienced, and testing was holding up the project. I approached the project manager about getting rid of her and hiring an experienced agile tester. He told me NO, we have to make do with the people we have, it will be costly to replace her and take to long. I am very glad that he gave me that answer for two reasons I got experience the TOC first hand, and she grew to become an excellent tester and now is a very successful contract test team leader.
- #51 Get the most out of the constraint, using only cheap changes. Some examples of Non Value Add Work: Status updates, reports, organising social events, investigating new tools, …
- #54 Align the whole system to support the decisions made above. Pairing of upstream and downstream staff, heads us towards cross functional teams & DevOps.
- #57 Make other expensive changes needed to break the constraint.