In a recent post, An Agile Illusion: How That Nice Backlog is Actually Decreasing Your Team’s Agility, I described how long, well-formed backlogs can actually decrease a team’s ability to respond to the market. This post generated some lively comments – some supportive, some more critical – but all quite perceptive and representing a pretty high degree of sophistication and agile maturity. These comments were refreshing (there may be hope for our industry yet…) and thought provoking and I wanted to respond further in this post.
What drove me to write that lengthy post wasn’t the wait at Starbucks on that dreary Saturday morning. Rather, I wanted to make a few, fundamental points about agile and lean, and address a few things I have seen in practice that continue to bother me.
In rethinking that post, and now in summary, I want to make three key points:
Point #1 – Little’s Law Doesn’t Lie.
Little’s Law tells a fundamental truth – the longer the queue and the slower the processing time, the longer the (mathematically predictable) wait. This core law of lean makes intuitive, logical, and mathematical sense (actually, it was Little that did the formal proof, rather than inventing the law).
What it says, and what we understand from lean, is that long queues of work in process are fundamentally bad. Whether it be elaborated user stories in a backlog that won’t see the light of day, code that has been written but not tested, hundreds of manual tests awaiting automation, blobs of new code that haven’t been checked back into the baseline, a long set of portfolio level projects awaiting resources, etc. etc. etc., they are ALL Universally BAD, as they all decrease agility and time to market. (It’s hard to respond quickly to an order for red fenders with a metallic finish, if you have a boatloads of fenders primed for regular finish stacked up in front of the paint shop).
However, we also understand that, at least when it comes to backlog, Little’s Law isn’t a perfect analogy as a story can jump the queue in agile (I’d recommend that you do not try that at Starbucks, as those people in front of you likely really need that caffeine) and a system can decide not to process all items in the queue (Starbucks could do that to decrease queue length, but the long term economics would be quite unfavorable).
So when it comes to the backlog post, as some readers pointed out, we are not forced to assume that all backlog items will make their way into processing in an orderly fashion. We are smarter than that. And therefore Little’s Law cannot be blindly and universally applied. However, the fact that we are smarter than that does not prevent some undesirable behaviors that I often witness in practice. This brings me to points #2 and #3.
#2 – Don’t be Hostage to Your Own Backlog.
In many sprint reviews, I ask teams how they are doing with respect to the release objectives. Surprise, many times they are behind (and that’s one of the reasons we like agile – we are likely behind less than we would have been, we actually know it and its not too late to take corrective action).
When I ask them how they can “jump the queue” and meet the release objectives though they are behind, they often say – “well, we have all these backlog items we have to finish first. We have elaborated them, we understand them, we have invested in them, we have committed them to others, we believe them important and they are ready to go”.
However, I then comment something like , “as true as that may be, those are sunk costs and that doesn’t make those backlog items necessary, per se. If the backlog you have isn’t the one you need to meet the release objectives, ignore the sunk costs and flush it”!
#3 – The Enterprise Can’t Be Held Hostage to the Team’s Backlog Either.
At enterprise scale; the problem is compounded. Often, we approach release planning boundaries with 10-20 agile teams already having detailed and well structured backlogs for the existing work in process. In that case, the enterprise has little or no agility, as nothing can really be changed. After all, if the teams must first work through their committed backlog, then Littles’ Law is in your face and the result is immutable – you can’t do squat at the enterprise level unless you do one of two things:
1) wait the infinite amount of time it takes teams to work their local backlogs down to near zero (it’s infinite because other laws – the law of “teams don’t like having empty backlogs” the law of “we have too much technical debt” and the law of “work will expand to consume the time allotted to it” – come into play)
2) The enterprise must override the teams, or kill entire projects, in order to move forward with more globally aligned objectives.
Either choice will be painful and sub-optimal.
Wouldn’t it be far better if the system were leaner, and if the team’s backlogs were really short and lightweight, and they didn’t represent fixed commitments based on too-long-a-term thinking?
Backlogs are great, so long as you keep them short, extremely lightweight, and negotiable. Remember, never overinvest in some stories you may just not do. And never, ever, be help hostage by your own backlog.
Finally, if you haven’t yet read Don Reinertsen’s new book, Product Development Flow, I would sure recommend that you do so.