More on Lean, Backlog and Little’s Law

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.


5 thoughts on “More on Lean, Backlog and Little’s Law

  1. As much as I’d like to have a short backlog in my current job there seems to be no possibility of achieving it. The simple reason is the size of the defect tracker.

    We are more or less actively developing and maintaining a mature and large system (close to 100 productized components) and at any given time we have anything between 40-100 open defects. And most of these defects are from critical production systems (our installation base is over 200).

    Very large proportion of these defects must be corrected, there just is no possibility to ignore them, since they are affecting production systems.

    We started the agile transformation about year and a half ago (and still making it) so the amount of legacy code, manual testing and component dependencies have prevented us from making the system truly lean. Combined with a large backlog we do not feel very agile nor lean.

    So far we haven’t been able to overcome this issue and our backlogs can contain up to 200 stories, with 20% of the stories groomed. Product owners seem to be helpless and unable to cut the backlogs. Fortunately the priorities are actively maintained, so we avoid some of the waste.

    How would you start to tackle this kind of an issue?

    • Bring out some heavy duty analysis tools. It sounds like a forest for the trees. As things scale (people, components, capabilities implemented and capabilities desired) Have you tried use cases in conjunction with stories?

      How many people? How many teams?

      Fascinating problem.

  2. Good post Dean. It feels a little strong on the rules and was hard to detect the balance however, as I slowed down a little balance came through. Half of my battles are with people generating way to much information.

    There is a mind set on data that goes like this… If I have more data (backlog stuff) then I must know more.

    This is an old tired trap and it is all to common.

    – Doug

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s