Practical advice on how to improve the throughput of your agile team, by using the Theory of Constraints and Queuing Theory. Shows how to apply TOC to your task board. Explains how Queuing Theory is built into Scrum and Kanban, powering you to make the most of them.
4. Theory of Constraints (TOC)
Idea
Process
A
Process
B
Process
C
Customer
Where should we strive
to increase throughput?
www.journey-to-better.com
5. Theory of Constraints (TOC)
Idea
Process
A
Process
B
Process
C
Customer
Where should we strive
to increase throughput?
5 units
Per week
2 units
Per week
3 units
Per week
www.journey-to-better.com
6. Theory of Constraints (TOC)
"a chain is no stronger than its
weakest link“
Improving strong links, does not
strength the chain.
To achieve more of your goal,
improve your weakest link.
www.journey-to-better.com
7. 1. Identify the constraint
2. Exploit the constraint
3. Subordinate all else
4. Elevate the constraint
5. Repeat
Five Focusing Steps
Get the most out of the constraint,
with only minor changes.
Major changes to the constraint,
Including increasing capacity.
www.journey-to-better.com
8. Practical TOC
We are going to:
1. Map team workflow to Task Board
2. Populate the board
3. Run the system
4. Use TOC to increase throughput
www.journey-to-better.com
9. Backlog Analysis & Plan Coding Review Testing Accept Done
Map team workflow
www.journey-to-better.com
10. Backlog Analysis & Plan Coding Review Testing Accept Done
Populate with current state
www.journey-to-better.com
11. 1. Identify the constraint
Constraint: The resource or policy that
prevents the organization from obtaining more
of the goal.
Symptoms
• Work piles up waiting to be processed by the
constraint.
• Resource is heavily stressed.
• Resources downstream from constraint are
regularly idle.
www.journey-to-better.com
13. Backlog Analysis & Plan Coding Review Testing Accept Done
Doing ReadyDoing ReadyDoing ReadyDoing Ready
Split all other columns
www.journey-to-better.com
14. 2. Exploit the constraint
Get the most capacity out of the constrained
process, with only minor changes
Some options:
• Shield them from interruptions.
• Limit their WIP.
• Reduce their non value add work.
Note: Do not ask them to do overtime.
www.journey-to-better.com
15. Backlog Analysis & Plan Coding Review Testing Accept Done
Doing ReadyDoing ReadyDoing ReadyDoing Ready
(5)
Exploit the constraint
Limit WIP in Testing
www.journey-to-better.com
16. Backlog Analysis & Plan Coding Review Testing Accept Done
Doing ReadyDoing ReadyDoing ReadyDoing Ready
(5)
Let it run
Constraint remains
www.journey-to-better.com
17. 3. Subordinate all else
Align the whole system or organization to
support the decisions made above.
Some options:
• Limit WIP of upstream to match.
• Upstream do preparation work.
• Upstream improve their quality.
• Pair upstream with constraint staff.
www.journey-to-better.com
18. Backlog Analysis & Plan Coding Review Testing Accept Done
Doing ReadyDoing ReadyDoing ReadyDoing Ready
(5)(5)(5)(5)
Subordinate all else
Match upstream WIP to constraint
Devs do more test prep work.
Dev-QA pairing
www.journey-to-better.com
19. Backlog Analysis & Plan Coding Review Testing Accept Done
Doing ReadyDoing ReadyDoing ReadyDoing Ready
(5)(5)(5)(5)
Let it run
Constraint remains
www.journey-to-better.com
20. 4. Elevate the constraint
Make other major changes needed to break the
constraint. A.k.a. Enhance the capability of the
constraint to increases its throughput further.
Some options:
• Improve their tools.
• Improve their environment.
• Improve their team work.
• Hire more people.
Why do we not do this first?
www.journey-to-better.com
21. Backlog Analysis & Plan Coding Review Testing Accept Done
Doing ReadyDoing ReadyDoing ReadyDoing Ready
(5)(5)(5)(5)
Elevate the constraint
Improve tools (reduce manual effort)
Get Devs to help execute tests
Hire another tester
www.journey-to-better.com
22. Backlog Analysis & Plan Coding Review Testing Accept Done
Doing ReadyDoing ReadyDoing ReadyDoing Ready
(5)(5)(5)(5)
Let it run
Constraint has been broken
www.journey-to-better.com
23. 5. Repeat
• The bottleneck should now have shifted.
• Start all over again
www.journey-to-better.com
24. To increase throughput
apply the Five Focusing Steps:
1. Identify the constraint
2. Exploit the constraint
3. Subordinate all else
4. Elevate the constraint
5. Repeat
Summary – Theory of Constraints
www.journey-to-better.com
Minor changes
Large changes
26. Queuing Theory
Began by answering the question:
How many phone lines will the Copenhagen
Telephone exchange need to handle peak
load?
Paper published by Agner Krarup Erlang in
1909
www.journey-to-better.com
29. Why reduce utilisation
Queuing Theory says that in a system with variability,
increased resource utilisation leads to an increase in cycle
time.
Software development has lots of variability.
Past a tipping point the increase in cycle time is exponential.
www.journey-to-better.com
31. Tipping Point in action
Utilisation above the capacity of the road,
(just one more car),
created unevenness,
created delays,
greatly increased cycle time.
www.journey-to-better.com
32. Why reduce batch size?
• Littles Law is part of Queuing Theory
Avg. Cycle Time =
Work In Progress (WIP)
Avg. Throughput Rate
www.journey-to-better.com
Throughput
Cycle
Time
WIP
Batch Size
33. Why reduce item size?
Large items take longer to process,
leading to:
• Queues (extra WIP)
• Variability (the bad kind)
www.journey-to-better.com
35. Highway - Reduce Utilisation
Q: How would we reduce utilisation?
A: Announce blockage radio & signs.
www.journey-to-better.com
Image: https://www.flickr.com/photos/highwaysagency/
36. Highway - Reduce Batch Size
Q: How would we reduce batch size?
Image: https://www.flickr.com/photos/29233640@N07/
www.journey-to-better.com
37. Highway - Reduce Item Size
Q: How would we reduce item size?
Image: https://www.flickr.com/photos/null0/
A: Replace Trucks with Cars, Cars with Motorcycles.
www.journey-to-better.com
38. The good news
Queuing Theory is already built into:
• agile
• Scrum
• Kanban
www.journey-to-better.com
39. Queuing Theory in agile
How does agile lower Utilization?
• Promoting sustainable development.
• Customer collaboration.
How does agile lower Batch Size?
• Focus on early delivery of Working Software.
How does agile lower Item Size?
• Focus on business feedback & simplicity.
www.journey-to-better.com
Image: http://www.agilemanifesto.org/
40. Queuing Theory in Scrum
How does Scrum lower Utilization?
• Team members 100% allocated.
• Team pulls in work to sprint.
How does Scrum lower Batch Size?
• Sprint length.
How does Scrum lower Item Size?
• Time boxing & D.O.D. encourage
splitting items.
www.journey-to-better.com
41. Queuing Theory in Kanban
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…
Image: https://www.flickr.com/photos/bods/
www.journey-to-better.com
Workflow (borrowed from planning team) Backlog, Approved, In Progress, Peer Review, Review, Share, Done
Some examples of Non Value Add Work: Status updates, reports, organising social events, investigating new tools, …
Pairing of upstream and downstream staff, heads us towards cross functional teams & DevOps.
Communication systems (networks, CPUs, etc).
Software development has lots of variability – types of work, size of work, people, priorities, etc.
Shockwave Traffic Jam Video Link: http://www.youtube.com/watch?v=Suugn-p5C1M
The system is over utilised, so a delays are created when there is no real blockage.
Large batches increase WIP, which increases Cycle time, which usually reduces Throughput.
When it is busy who gets through the traffic fastest? Truck, car or motorcycle? So smaller items can be processed faster.
Early delivery of working software is not possible with large batches.
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.
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.