Advance slowly – Agile 101

Tom Breur

25 May 2014

Sometimes you have to go slow, to go faster. When people first get introduced to Agile and Lean practices they often find small increments counterintuitive. Isn’t it more efficient to deliver more at once? That way you don’t incur the cost of deployment so often. These are referred to as “transaction costs” in Lean and Kanban.

“Big batch thinking” is deeply ingrained into our brains after more than a century of industrialization, Frederick Winslow Taylor and the huge success Henry Ford enjoyed with mass production. Toyota didn’t have the mass markets that Ford could sell to, so they needed and developed an approach to manufacturing that went in the opposite direction. Efficiency at delivering small batches, ideally single piece flow.

Why is it that Agile (and Lean) practitioners prefer to grow solutions in the smallest possible increments (Lean: “flow”)?

The key to working agile 101 is to:

1 - Look where you are
2 - Determine where you want to go
3 - Move a little in that direction
4 - Rinse and repeat

Of course there is also a level of “meta learning” that is commonly referred to as “retrospectives” or operations reviews (see this excellent post, for instance), where we look how well these steps perform, and we change course accordingly. We’ll disregard that outside loop for now.

In an earlier post, I referred to “minimal necessary planning”, because in knowledge work we don’t have the crisp and accurate specifications that manufacturing often has. Car engines get assembled with known dimensions and tolerance for error. You can “simply” determine which parts are OK, and which need to be rejected.

When you write software, getting timely and frequent feedback from your customer (or Product Owner in Scrum) is paramount to success. Uncertainty over requirements often makes that effectiveness (building “the right” solution) trumps efficiency (building a solution with minimal effort).

Ron Jeffries makes an excellent case for the need to deliver. Deliver working software. In an outstanding post he reminds us of the Agile Manifesto. He was there in 2001 when they wrote it up, and has been practicing these agile principles for as long as anybody else. Sometimes these principles really are pretty simple …