Pivotal assumption – “An assumption on business case, priority, minimum viable offer, or requirement that if false will fundamentally change designs, deliverables, or timelines.”
In my post on how organisational factors increase the bad impact of architectural debt, I referred to how the lack of clear business objectives and priorities slow you down and prevent important architectural decisions from being made. The result is that you need to plan along two or more paths in parallel, which obviously slows you down. Sometimes this double work is needed while you are waiting for a decision, and if all outcomes are likely to happen. However, very often one outcome is more likely than the others, it is just difficult to get consensus or a decision has a big impact on something else, so people want to avoid a rash decision.
In these cases, you will get dramatically increased velocity if you can make an assumption about what the decision will be. Teams will get more focus, people will stop doing double work, some things can get lower priority, other things float up to the top. I call this a “pivotal assumption” because a lot hinges on such an assumption, and if you make the wrong assumption, you have lost some time (though often less than you think, because executing on two things in parallel is very inefficient). But what makes a pivotal assumption different from the actual decision?
First of all, you need to make the decision and options explicit and clearly defined, and get people’s acceptance that this is a decision that needs to be made, but that it may take time. You also need to identify the things that do not hinge on the assumption by explicitly stating that “x, y, and z are not impacted by this decision, so we will plan these separately.” You want to do it this way as this will explicitly decouple x,y, and z from your pending decision and will get rid of uncertainty: is x impacted by the decision??
Then, you need somebody in a position to postulate the pivotal assumption. Let’s say you are making a new product for the 10-100 employee segment, and product management is not sure whether import of users from ActiveDirectory is needed in the first version of the product. A senior architect, engineering manager, or senior product owner needs to postulate that “we should execute from here on based on the assumption that ActiveDirectory import will not be needed in this phase.” All discussions and work related to ActiveDirectory import should then be put on hold.
There is one final, crucial element in using pivotal assumption. You need to avoid that it actually becomes the decision by identifying the facts or evaluations that need to happen before a decision can be made and pro-actively follow up. Everybody will be acutely aware that the longer you execute based on the assumption, the more costly it will be to make a decision that is not the same as the assumption. This is an incentive to get a conclusion. Also, I recommend that you actively look for indications that the pivotal assumption may be wrong, and that when it becomes clear that the pivotal assumption was wrong, you swiftly change course and treat throw-away work as sunk cost.
If you can systematically identify areas where people have different assumptions when doing their work, you can make explicit pivotal assumptions to get temporary focus, and then quickly close the identified decisions. This will dramatically increase your velocity. You may think that you get a lot of throwaway work, but truth is that without pivotal assumptions, you get double work, which has the same cost, but in addition you get also the unnecessary code into your codebase, increasing complexity and cost of maintenance. The psychological effect of not having clarity also adds to the cost of executing on two tracks in parallel.
I call this method “hypothesis-driven development” as you continuously identify assumptions, you gather facts and try to falsify your hypothesis. The organisation can get pretty good at identifying good assumptions and quickly close them. Be warned though, unless you pro-actively gather facts to try to falsify your pivotal assumptions, you end up adopting the assumptions as your decisions.
RSS - Posts