When is the Last Responsible Moment?

When is the Last Responsible Moment?
Agile frequently refers to the value in delaying decisions until "The Last Responsible Moment" (LRM), but when, exactly, is the Last Responsible Moment? The usual answer is: Late enough to let you get enough information for a correct decision, but early enough to avoid causing delays or added costs.

 The Problem is.... We almost never get enough information for a guaranteed "Correct Decision"! Consequently, we sometimes leave decisions too late. When you try to defend your project from potential problems, your decision is similar to the decisions facing a military officer who faces possible hostile action by unknown forces: 1. Decide early, build extensive, and all-encompassing defences at once and then stay vigilant. This exhausts your troops, but at least you have defences, right? But it may turn out you built the wrong defence. If so, your exhausted troops may need to change the defence to deal with the consequent problems as they arise, or you may need to abandon your position - so all that effort was wasted and your troops are forced into a running battle when they are already exhausted. Or there may be no attack at all, so again all the effort was wasted - your troops are exhausted and achieved nothing.
2. Delay the decision and continue gathering information until your sentries believe that they may have an approximate number and position of enemy troops that may be approaching your position. You may be too late to build an effective defence.... and you still don't have enough information to build a defence that you definitely won't need to change. However, although you still can't know for sure that you have reached the Correct Decision and your troops might not have time to implement your decision, at least you have better information, so if the troops get it built in time your defence might be about right, and thus the cost to change your defence to match the precise situation should be less.
3. Delay until the sound of claymores going off drowns out the screams of "Oh God, they're coming through the wire"! So now you have the maximum possible amount of information about enemy composition, size, equipment, tactics, disposition, support, intent and so on. Thus, although your decision will be delivered into a crisis and your troops may have no opportunity to implement your decision, at least there is a decent chance that it is the Correct Decision.
In shaping your decision, ask yourself three questions:
1.        Will a delay provide more information?
2.        What is the cost of delay?
3.        What is the cost of corrective action if you decide early and fix it later?
Delay has a cost, but it might also provide a benefit.

 Know the Driver For Delay What might drive the need to delay a decision? Here are some scenarios to consider:

• I need to know something, but it is unknowable. Sometimes we cannot know what the "Correct Decision" is until we try. This is particularly true in complex environments, where the entire outcome of a decision may not be predictable in advance. If that is the case, there is no benefit in delay. This is a scenario in which Complexity Theory would advise designing low-cost Agile Experiments (prototyping, wireframe, walkthrough, "reconnaissance by coding", or something similar), which will guide a decision better than waiting and hoping for information that cannot be known.
• I need to know something, and it is knowable, but not known yet. Frequently, although we don't yet have the information we need, we get to a point where the cost of delay is higher than the cost of change - which means that the "Last Responsible Moment" becomes "As Soon As Possible"! This is when we need to understand the "cost of delay" vs the "cost of change" - as this drives "The Last Responsible Moment".
• I am not in charge of the decision. Sometimes we aren't in charge of the length of time a decision may take. For example, Product Owners are sometimes hard to pin down when we need requirements or priorities, because the PO is trying to get stakeholders to sign-off and the stakeholders aren't sure what the complete, "correct decision" is, so they are frightened to commit to an answer in case they leave out a requirement. Yet we often find that they have a clear understanding of 80% of the answer - their hesitation is around uncertainty over a little added functionality.

If we have developers sitting doing nothing or involved in ineffective make-work while we wait, this fruitless wait for the "correct decision" can represent a very expensive delay! In this case refactoring code to incorporate minor updates from stakeholders is the less expensive option. We develop Iteratively, which allows our stakeholders to make decisions Iteratively! So, in this case, make sure your stakeholders understand the cost of delay versus the cost of change. Explain to them that sometimes we don't need the whole answer - part will do.
If this occurs, it is worth keeping your developers in the loop. Most developers dislike rework, but they dislike idleness and make-work even more! If they understand the situation, they are likely to be understanding about the need to do minor refactoring and rework.

Deciding When To Decide As a guide, if the information you need is:

• Unknowable. Then the Last Responsible Moment is now - using experiments to guide your decision.
• Knowable, but the cost of delay is greater than the cost of change. Then the Last Responsible Moment is now - but with refinements, improvements and corrections later. 
• Knowable, and the cost of change is greater than the cost of delay. Then the Last Responsible Moment is whenever you have enough data to maximise the chance of a correct decision. 

Deciding when to decide is a decision! Understanding what is driving the delay, and being able to estimate the Cost of Delay Vs the Cost of Change helps you decide which way to go.