Work In Process Limits, Revisited
This content is syndicated from LeadingAgile by Mike Cottmeyer. To view the original post in full, click here.
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 we have to get past this barrier.
So here is the deal… limiting work in progress requires an agreement across the entire organization to limit the work in progress. Makes sense huh? Abstracting a gigantic backlog behind a product owner, or even a work in process limit, only works if you have agreement from your senior leaders that they are willing to play by the rules and actually limit work in process. If you try to enforce a rule that they haven’t agreed to, that is formula for frustration and poor performance reviews.
Should I use Scrum in this situation? I don’t care. Should I use Kanban? I don’t care about that either. What I want you to do is visualize all that work you have in queue and come to terms with what can actually be done. No wishful thinking allowed… past performance will be our only indicator of future performance. Once you have a solid idea of what is possible, help your organization come to terms with that reality. Pretending is no longer allowed.
Warning… this is a VERY difficult conversation.
Leave a Reply