Why decide later?

Tom Breur

5 January 2014

Agile, and also Lean, carries the notion of “deciding at the last responsible moment.” To be clear, this is a metaphor, there is no such thing as a discrete moment in time where the cost of delaying the decision any further goes up by some step function.  Many of these ideas were criticized by (among others) Alistair Cockburn in his post “Last Responsible Moment reconsidered.” Another concern is that you never know when that “last responsible moment” is, until it is too late.

Maassen and Matts wrote an interesting graphic novel “Commitment” where they make the case that you should never commit early unless you know why. And most of those reasons, arguably, align nicely with the original notion of “deciding at the last responsible moment.” It also aligns with the Lean concept of “Just-in-Time.” Don’t do work (too) early, because while it sits around waiting, it represents waste. Not good.

The practical challenge in knowledge work, of course, is that there are usually multiple decisions that need to be made. And they happen more or less in parallel. The more complex the system will be, the more decisions you need to make. They will likely have some interdependencies, too. And more often than not, it is all but obvious what that ‘true’ “last responsible moment” was.

There is uncertainty and variation in systems. You ‘plan’ (schedule) some work (regardless of whether ‘formal’ estimates were made), and sometimes things don’t go according to plan. The more sequential dependencies you have, the more likely it is that one (or more) component might get delayed. Such are the “laws” of mathematics.

If somewhere along the value stream you are waiting for upstream decisions that haven’t been made, this is just as wasteful as having work waiting for downstream processing. Both contribute to Work-in-Progress. Which constitutes waste and additional liability. Eli Goldratt’s book “The Goal” provides excellent background into this. David Anderson’s book looks at this phenomenon specifically for Software Engineering.

If you take note of dependencies, and remain aware of variation in your system, I still feel you can gain by delaying decisions. Maybe not “as late as possible”, but at least later, if you can. The main reasons for this are twofold. First, you defer investments, which gives a higher economic return for your project. More importantly, you will have gained more knowledge, allowing you to make a better decision.