Throughput Over Backlog (an Agile Value)

Existing Values

The initial signatories of the Agile Alliance sat (stood according to the Snowbird summit photo) and hashed out some common values in their Agile Manifesto in 1998. Here’s the key four values that they came up with:

“… we have come to value:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more"

The numbers are mine. Their list isn’t numbered or bulleted.

A 5th Value

Colleague Paulo Carroli, a few years ago, socialized a thought that 5th value could be added to the manifesto:

1. Team throughput over detailed work backlog

Or “Throughput over backlog” for short. It is all about the lessons from Lean Manufacturing (of which the Agile software development is a step-child). All us laymen need to remember is that building up inventory between processing nodes in production line making a thing is waste, and that waste needs to be eliminated for a bunch of reasons. Work on progress can build up because you’re feeding an upstream producer of work in an intermediate state has working too fast, or a receiver of that work in progress is working too slowly. Too fast could be “too many people” producing that thing (team/company). Too slow could also be too few people receiving that thing, even though they are processing it to the next stage at an appropriate speed (and duration of working day). Take a look at this flash animation of bottlenecks and Lean Manufacturing – it is the only primer anyone needs on lean throughput, backlogs and constrained resources.

In February 2011, I checked with ThoughtWorks’ Agile demigod, Jim Highsmith – a snowbird attendee in ‘98 and therefore an original signatory. He said that although the topic of rewriting values comes up from time to time, there’s not a huge interest in revisiting the manifesto. I’m sure I’ve discussed this with Martin Fowler too, and there are plenty of groups would want to see alternative 5th Agile values for a revised manifesto, and the topic must be boring to the signatories by now.

SAFe – Scaled Agile Framework

SAFe comes along and executive tiers in companies with sizable IT departments are attracted to the messaging behind it. It leaves me, and many others, with some chills. There are many ways you could look at the SAFe cause, materials and certification and be critical, but in this article I’m just going to look to at just two.

Firstly the “Throughput over backlog” value would suggest it is more important for you get started with a project and tune the flow of stories to perfection. Stories flow from Product Owner, through BA/UX, Dev, QA, to “done”. Anyone of those could be constrained, and you need to tune so that work in progress doesn’t build up. It could be that the machine works too fast, and the Product Owner is feeding feature requests with questionable value into development. If that is all feature requests then worry whether your P.O is the right one for the job, or whether your product is worth making. If they are anomalous, or you totally get #4 – “Responding to change over following a plan” – don’t worry you can pivot after you put it in production because that didn’t involve more than the minimum of people or hours spent.

Secondly..

6th value: Simple libraries over entangling frameworks

Strictly speaking that is about developers and libraries vs frameworks (Java, C#, etc), but in this instance I’m going to make a weak connection given the fact that SAFe has “framework” in its title, and we should be careful with those. Indeed frameworks can often feel like the Sirens of software development, and lure many developers on the rocks of delivery. Stepping away from the weak criticism of SAFe, and going more honestly into software engineering, frameworks are one of the causal pain-points of TDD being hard.