One of the most counter-intuitive ideas baked into Agile software development is the concept of the last responsible moment, as Jeff Atwood writes about. In a nutshell, the idea is this:

Since it is best to make decisions with the most information possible, we should wait until the last responsible moment to do so, because it’s at that moment we’ll have the most information available to us.

Clearly, to buy into this concept, we must make a few assumptions. First, we must assume that the passing of time does, in fact, allow us to gather more information. If this doesn’t happen — say, we all go on vacation for 2 weeks and put the whole bit out of our minds — then the concept is bust. However, this assumption is a pragmatic one, as it’s entirely likely that a highly functioning team will further understand and catalog details over time.

Second, we must assume that we understand what “responsible” means in this context. Again, speaking in nutshell terms, I offer that “responsible” refers to the duty we have to not let any reasonable design option fall on the floor as the result of too much time having passed. Of course, I have injected yet another word open to interpretation in “reasonable”, but I am not going to delve into variables like business value and total cost of ownership to define it here.

The elusiveness of the concept itself notwithstanding, teams also often grapple with the differences between a decision and an assumption. (And how can we effectively adopt a methodological concept if we can’t agree on the definition of the very thing the concept exists to improve: decisions?) Sometimes, in the worst case scenario, a team becomes vapor-locked and idle because they’re unable to differentiate between assumptions that allow them to separate software elements that are dependent on yet-to-be-made decisions from those that are not.

I’ll give a brief example of all of this in a real world situation:

As Manager of Software Development, I often end up in the ScrumMaster role on my company’s projects. On a current project, our team is faced with the task of building a web-based portal that will be integrated with the client’s backend systems via a message-based API. Unfortunately, the client’s decision around the message format itself will be delayed by weeks. Even after the decision is made, it could be a matter of months before the client is able to develop and deploy the necessary infrastructure for the unit and assembly testing activities, let alone production. And to top it off, the team is still being charged (by me, of course) to build potentially shippable components of the software in the meantime.

While it may sound bleak and chaotic, I consider the immediate future ahead of this team fairly obvious: make pragmatic assumptions to enable the development of components of the software where the decision regarding message format may not matter. They can and should wait on such an important decision.

For example, how about the UI workflow? They can assume that whatever the message format ends up being, it can be transformed into the industry-standard EDI format to drive the frontend, yes? (This is true for virtually all of our clients in the healthcare sector.) Can they build out the CRUD functionality for the system’s local models? They can assume that the eventual message format will not affect how they store or retrieve they system’s models locally, right? And the list goes on.

(For the Agile purists out there: I am not advocating the creation of abstract or generalized frameworks to pass the time — I am a proponent of YAGNI. In large, distributed system architectures, the separation of concerns is vital, and happens to dovetail quite nicely here.)

The team will react to the message format decision when it is made. However, we must all be clear on the reality that doing anything, including building software, takes time. We can’t let so much time elapse that viable implementation options begin to fall off the table for lack of enough time left in the schedule — we’re looking for the last responsible moment rather than the last possible one.

But for now, the team can comfortably make a series of pragmatic assumptions on which to base a series of low-risk decisions — decisions that are completely separate from the message format decision — to enable the construction of perfectly viable software. We do not need to make a decision on the message format before we continue, and, in fact, we should embrace the client’s desire to wait for more information before it reaches that decision.

Meanwhile, we can responsibly carry on with the matter of building precisely what the client is paying for: software.

Armed with the concept of the last responsible moment, a thoughtful observation of the nuanced differences between assumptions and decisions, and how each impacts your project, can often yield productive results.