Work In Process Limits, Revisited
This post is from LeadingAgile by Mike Cottmeyer. Click here to see the original post in full.
I am noticing a troubling trend with many of the organizations I interact with. The project teams have a release date, a relatively fixed team size, and somewhere between 5 to 10 times more work in the backlog than they are ever actually going to get finished. People are in absolute denial about how much work can really get done in the time allotted. When I call them on this fact, they often mumble about contractual obligations and executives that just expect them to get it done.
Let’s level set for a moment… Scrum limits work in process by enforcing the simple rule that the Product Owner gets to decide what gets built, and the team gets to decide how much gets built. The velocity of the team becomes the work limiting factor for the sprint. Kanban teams limit work in process by setting explicit limits on the number of items that can be in any given queue at any given time, forcing the team to remove the bottlenecks before taking on any new work.
Not rocket science, right?
Here is what is hard… far too many organizations are way too overcommitted. Very senior people have made very visible commitments, to very visible customers, and going back on those commitments can be career limiting. I am convinced that many managers would rather live in denial than face the reality of their situation. They would rather live under the illusion that if they put more pressure on the organization, more stuff will get done. Somehow...read more
Leave a Reply