Work In Process Limits, Revisited
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.
Comments (13)
James HT
Amen
Agile Scout
Well said. An Agile transformation is just that… transforming the entire organization from the top down bottom up.
Gary Reynolds
Bang on target. I doubt I’ve ever worked in an organisation where, at some level, there isn’t a significant amount of denial about what can be accomplished in a given time frame.
oyedele olayiwola
Nice!
mitchp
Hey Mike,
Another good post! This is the editor from DZone, and I wanted to make sure that you got our email about the massive swag package we’re starting to send out to our top MVBs. We still need some info from you, so go ahead and send us an email and we’ll give you the details.
Dzone guy… I thought I had replied… want the swag… let me see if I can resend. Thanks!
Andrew Fuqua
Ignoring or being ignorant of excessive backlog creates mood debt that will have to be paid down. Paying it down sooner and in small installments is less painful than paying it off all at once far down the road.
Rick Austin
Spot on, Mike. I often think this denial is exacerbated because organizations are unable to gain clarity on the work that _is_ _in_ progress. Larger organizations often struggle with understanding their overall backlog because there are so many inputs. How then can they reason about what is most important for delivery to customers? They can’t and though all the teams are over saturated (busy is good right) that does not mean the highest customer value is being delivered. I think focus is needed in helping organizations gain clarity at what many call the portfolio or feature delivery layers. This along with clear limits based upon team capacity will go a long ways towards lifting the veil of denial.
Bob Galen
Mike, this is a really ‘tough’ post. I think you’re right-on, but these conversations are going to be really hard to impossible for most agile team members to engage in. They simply don’t have the experience or the tools for it. To simply lay it “out there” might even seem irresponsible. Do you have any practical advice on “how to” initiate, have, and survive these conversations? Perhaps content for another blog post?
Another point is that this post directs all of the overloading of backlogs to “them”…towards leadership. I’ve seen an additional pattern where teams’ overload themselves as well. Perhaps this is succumbing to the pressure or perhaps just pleasing behavior or simple underestimation. The point is though, that we can’t always blame “the man” for everything. We might need to have this tough conversation with ourselves too. Nice post Mike!
Bob… I am learning how to initiate the conversations as we speak. I’ve got a few scars, but also a few successes. Often I am not coming into an organization at a senior enough level. The guys that hired me don’t have influence here either. Generally I try to create an ah-ha moment through some release planning event, that it becomes apparent that there is a problem. Once folks understand there is a problem, you can initiate a conversation about how to fix it.
I agree with your second point, that quite often teams overcommit themselves. I don’t focus on this aspect because it’s not difficult to coach that behavior out of a team. Good solid release planning, understanding of risk and uncertainty, iteration planning, velocity, etc. are all pretty straightforward mechanisms for having this conversation. What’s hard is when the teams are getting so much pressure to deliver more than they can, and the CAN’T say no.
That pattern is disruptive to the team, and the one I am trying to help companies learn how to solve.
Tony R
This post is spot on, and it applies not just to agile organizations, or to organizations that want to be agile, but to any organization that undertakes projects. How many waterfall projects fail, not because they are waterfall projects, but because they overlap with many others requiring the same resources?
I’ve spent quite a bit of my time over the last several years educating the non-technical leadership of the company on the simple physics of it all. There’s been progress, but for those who don’t have direct experience creating or building, it just doesn’t stick. In a couple quarters we’ll be back to arguing about how many hours people work and why we can’t just get everything done faster.
I wouldn’t say that it’s one difficult conversation — I would say that it’s many and a big piece of managing the relationships with the rest of the organization.