Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Work In Process Limits, Revisited

DZone's Guide to

Work In Process Limits, Revisited

· Agile Zone
Free Resource

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

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. 
 

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.

Topics:

Published at DZone with permission of Mike Cottmeyer, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}