Last Responsible Moment
In Agile project management there is a concept of “The Last Responsible
moment”. The principle states that when working on a software project there is
a benefit to holding off on making final decisions until the last responsible
moment that they can be made. I recognize that this can be counter-intuitive
as procrastination is frowned upon, however, it can be shown that there is prudence,
and not procrastination, in delaying decision making.
Why This is a Good Idea
Software teams face hundreds of decisions any time they work on a project. The
questions they face range from foundational (e.g key product features), to the
incidental (e.g. the choice of font to use in the product). These decisions are
fundamental communication points for the team. When a decision is made the
individual members are able to proceed with tasks that are affected by this
decision. However this also incurs a risk. If there were need for a change
any work done will have to be modified, or even thrown out.
Such situations are bound to happen in any project. It’s cliche, but the one of
the only constants in life is change, and this applies to software requirements
as much as anything else. This is where the last responsible moment principle
comes in. Teams who operate by this principle recognize that they do not know
the end from the beginning. Humbled by this awareness of their own ignorance,
they protect themselves by withholding decisions until required, thus hedging
up the risks they take on possibly faulty assumptions. As the project
progresses, the team will become more informed on the needs of the client, the
direction of the project and work that needs to be done. Any time a choice has
to be made, they make it with all that additional knowledge, mitigating the
risks they end up taking over the course of the project.
Those who remain skeptical might point out that decisions will still need to be made
at the start, how else are team members supposed to move on in projects. Agile
has two responses for that.
The first is that, actually, the vast majority of decisions that we think as
very important can easily be sidestepped and worked around. We have a tendency
to over-inflate the importance of decisions. By working to avoid committing
yourself, you can be surprised by how many decisions you thought were
necessary, that you never ended up having to make.
Secondly, for the decisions that really do have to be made, you will see Agile
teams replace having an upfront plan with frequent coordination meetings. Often
these come in the form of “standups”. These are meetings where each team member
answers the following three questions: “What did I work on yesterday?”, “What
am I working on today?” and “What, if any, roadblocks do I have”. While most of
the industry treats standups as simply status-update meetings the true purpose
of the meeting is to make sure the team still has a shared vision of the
project (questions 1, and 2), and address any decisions that need to be
made to move the project along (question 3).
Working in this way also encourages team members to participate in planning and
deconflicting work. Assigning tasks becomes an organic bottom-up coordination
process rather than a top-down imposed plan.
Beyond Project Management
Robert Martin (Uncle Bob) takes this idea a step
further in his book Clean Architecture. He states that:
A good [software] architect maximizes the number of decisions not made.
How can an architect maximize the number of decisions not made? It seems
illogical, to maximize something that doesn’t exist. However, by making this
statement, Bob elucidates a valuable idea. There is a link between decisions
and commitments. Until a binding commitment is made, no decision has been
actually made. The commitments carry risks, and it isn’t until we accept those
risks that we actually make a decision. To put it in regular parlance, it’s all just
talk until you put your money where your mouth is.
Bob shows that developers can exploit this nature of decisions, to
isolate themselves from the decisions of others. In the software
case, a programmer working on the core part of the application doesn’t care
if the client wants a pink or purple website, or a minimalistic command line script.
If he is doing his job as an architect, he has isolated himself from being
dependent on those decisions.
It’s now that I apologize to the readers who really don’t care about software
or project management. If you have stuck around this long, thank you. I hope
this next part proves a valuable payoff.
I have seen this principle pop up beyond more than just software. When it comes
to leadership and management, this principle is an important one to remember.
There is wisdom in refraining from rash decision making, and prudence in
patience. A friend of mine in the Army used to quip, “door kickers get two in
the chest”, as a way to warn against the dangers of being over-eager to implement and
accomplish every new task that would come down from higher. Instead, it is often better to
take a pause in order to understand the situation first before starting those
you lead, down paths that will need to be backtracked.
Dwight D. Eisenhower is quoted to have said:
I have two kinds of problems, the urgent and the important. The urgent are
not important, and the important are never urgent.
This is an echo of the last responsible moment idea. Important things are
things we should consider, study and thought out before commiting to a
decision. Urgent things can be dealt with rapidly, because they bear little
real importance. Personally I have avoided a lot of stress by recognizing that
many of the “Important” choices I had to make, were not as important as I
First of all I want to say, if you are still not convinced, this is just the first in a
three part Thesis, Antithesis, Synthesis project on these ideas that I’m working on. I’ll
link the following articles as they are posted.
Second, and more importantly, I want to thank my friend Nate, who helped me think through
these thoughts. I highly recommend giving his blog a read.