beyond wip limits (short version)
DESCRIPTION
Limiting work in progress (WIP) is a concept widely popularized by Kanban, but in different forms it also exists in other agile approaches. Despite that, applying limits is a practice which many teams find either counterintuitive or non-value adding and eventually skip it. We should however start with answering a couple of basic questions. Why do we introduce limits in the first place? What do we get thanks to them? After all we don’t apply limits just to make our work less convenient, do we? The session will discuss limiting work in progress revealing a bit of mechanics of the concept and pointing false beliefs which we often embrace in software development teams. It will show how this mechanics can be exploited to improve our processes in both expected and unexpected ways. After the session you should be tempted to apply WIP limits in your process or, if they are already a part of the process, to adjust them accordingly. And most of all, you should know why and how limits are working, which will help you to make a decision when you should introduce them and how strictly a team should respect them.TRANSCRIPT
Once upon a time…
Why?
100% utilization
That is so wrong
Cost of multitasking
Time to market
On a highway
In a call center
On a computer
Ball Flow
Game
No WIP Limits
Using WIP Limits
Why something that intuitive seems so counterintuitive when we talk about management?
…and they lived happily ever after
5O
WIP limits!
Why?
Slack time
We don’t live in ideal world
Automation
Code quality
Simple configuration
Self-balancing team
Slack time introduced by WIP limits drives continuous
improvement
Help others
Learn
Do nothing
Takeouts
100% utilization is a myth
1OO%
Introducing WIP limits results in improved efficiency
Slack time sets us on path of continuous improvement
Thank you
Pawel Brodzinski
blog.brodzinski.com
vsoft.pl
@pawelbrodzinski