When to Choose: Part 1
By Tyler
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.
Why though?
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 originally thought.
Final thoughts
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.