An Agile Approach to Deciding When to Decide
Ellen Gottesdiener’s article “Decide How to Decide” lists a number of rules for collaborative decisions focused on who makes decisions and provides information. Being explicit about your process helps streamline decision-making and build support. Deciding how to decide can help a team move quickly, but you also need to decide when to decide.
A premise of agile is that it’s better to make decisions in the context of more information, and the best way to get that information is to make small steps and see what you have. A common heuristic is to defer decisions to the last responsible moment, but defining when that moment is can be a tricky. Because some decisions, such as those around technology and architecture, can have a significant impact on a project, there is often a bias to define standard approaches and frameworks early. But making decisions without the right information can cause teams to incur costs when they discover that the framework or tool is not a good match for the actual problem.
Considering when to make certain decisions is an important factor. Evaluating the reversibility, migration, and sustainability of decisions can help.
Reversibility is the cost of reverting to a preferred approach should an experiment not work. For example, I worked on a project where a team wanted to evaluate using Kotlin as an implementation language. Rather than debating in the abstract, the team thought doing a time-boxed experiment building and deploying a service would identify the pros and cons. The team estimated the cost of rewriting the code in Java, should Kotlin not work, as worthwhile.
Migration is similar to reversibility, but smaller in scope and deferrable. For example, when using Liquibase as a database change management tool, a team might want to standardize between using SQL or YAML to define change sets. If the team decided to try both before standardizing, the processes around the tool would be identical, and because the tool supports mixing and matching, the team could defer changing already written migrations. Liquibase also allows for the generation of SQL from YAML migrations, so the migration cost of the experiment could be small, or even zero.
Sustainability is the ability for the team to retain the knowledge associated with a new technology. If 25 percent of the team is advocating for a tool, you can be confident that you can maintain the work going forward. Only two developers deploying a framework that had no other buy-in would be low sustainability. That does not mean you definitely should not evaluate a tool, but you should factor in the costs of learning.
If a decision has low migration costs or can be easily reversed, and it is sustainable, there are advantages to deferring a standardization decision, as the team might benefit from experience. Having a conversation to understand these factors can provide value.
So resist the temptation to standardize too soon as a matter of routine; you may miss opportunities to improve.
