Frustration, Despair, Delays
Endless meetings talking about the same thing?
Nothing ever gets settled — at least not for long?
Lack of clear technical direction?
Can’t determine if or when a decision has been made?
Team getting frustrated with their own ability to agree things?
Sounds like yet another team is getting bogged down in decision making. In my experience this is an all too common problem with truly agile teams and it only ever gets worse if you scale. This is not an unrecognised problem in Agile teams. In Scrum we have a single Product Owner to be the one voice of truth to avoid precisely this issue. A single Product Owner is great for business decisions, however Scrum offers no such remedy for the delivery/team side — not even any advice on how group unity on important decisions can be established. Group decision making is notoriously challenging and a source of unhelpful conflict, something anyone who watches “Reality” TV will relish.
What makes this all the more contentious in delivery is that quite often there will be a lot riding on some important decisions, and operating in complex environments, key information can be illusive or non existent. Establishing agreement and making decisions in uncertain and complex situations is a big challenge for all but the most harmonious team. In an empowered team with no single decision maker, we have many competing voices and opinions, different appetites to risk and different levels of experience. All this can end in indecisiveness at the group level resulting in:
- Paralysis, where the team simply cannot move forward
- Forced decisions, which are taken under acquiesce. These rarely sticks and get reopened time and time again like a unhealed wound. These risk creasting deep scares within the team or even denting stakeholders appetite for Agile.
- An increased desire to move back to big up front thinking in an attempt to find the illusive nugget of information that will render the decision obvious
All three states are undesirable. Paralysis will delay the deliver, picking over a decision is likely to impact team harmony and confidence in the long run, and launching into a significant up front analysis will likely throw up yet more information that renders the decision even harder to make. All this results in unwelcome delays.
The root cause of all of this is likely to be the concern around making the wrong decision. By empowering the team we push down responsibility and accountability which naturally brings the consequences of making a “wrong” decision closer to home. Different members of the team will likely feel this pressure to differing extents at different points in time.
To a degree, Agile mitigates this by promoting iterative delivery, where rework is accepted and embraced by all. Using an iterative approach, teams are encouraged to delay decision making to as late as possible, just in time, in the hope that more reliable information is available. This works well for some types of decisions (e.g. user needs) but in my experience it is less helpful for key technology/architecture choices that may be difficult to back out of without starting from scratch. For many teams, starting from scratch is either a luxury they don’t have, or it would be too painful (too costly) to even contemplate — especially in a scaled environment.
So the challenge remains — inevitably we need to make decisions in very uncertain situations without all the information we would ideally like. How can we make this easier for teams?
Perhaps a change in focus will help …
In attempting to elicit a decision, are we asking the right questions? We naturally focus on the subject matter itself — for example, should we use a relational or a graph database, should we use this type of data model or that. Whilst we can always have a good debate on the topic, in uncertain and complex environments, the honest answers will often be that we don’t and can’t genuinely know the answer. Consequently, it becomes a pure matter of opinion and we will almost certainly have many of them within our teams — thats the problem! Maybe additional analysis will lead us to being better informed. But ultimately many decisions will be an educated guess and only time will tell if we are right or wrong — hindsight will ultimately be our judge. If we accept this premise, perhaps we should change our focus …
Instead of getting worked up over the decision itself, we should instead be focusing our deliberations on establishing if we are about to make a reversible or irreversible decision. If it is irreversible, can we take some action that will render it reversible (e.g. encapsulation, abstraction etc)? If we can’t do that, and the decision turns out to be one of those gnarly single shot and critical ones, then putting in additional due diligence may be entirely appropriate. This may take the form of running experiments, getting a wider set of opinions or seeking out prior experience within or outside of the organisation. These decisions almost certaintly deserve a place in our risk registers. However, this does take time and energy, and ultimately we may still not find the answers we are looking for. If the decision is reversible, albeit maybe with a little work — then iterative delivery should be effective enough and we shouldn’t overly deliberate them or spend huge amounts of energy sweating it.
This is certainly the attitude of Jeff Bezos when he talks about “Two way door” decisions and not consuming huge amounts of organisational energy on them. He describes two key types of decision:
- Type 1: Almost impossible to reverse. “One-way doors” — there is no going back or it is extremely difficult/outside our control. For example, resigning from a company.
- Type 2: Easy to reverse. “Two-way doors” — doors that we can go back through if needed. For example, trialling a new SaaS provider.
Type 2 decisions are great for Agile teams as they shouldn’t need the team to expend a huge amount of time and effort on them. Instead we should save our energy and attention for the rarer type 1s.
Kent Beck, father of extremeProgramming (XP), shares similar sentiments on key decisions when reflecting on his time at Facebook (https://m.facebook.com/nt/screen/?params=%7B%22note_id%22%3A681695435785808%7D&path=%2Fnotes%2Fnote%2F&_rdr). He recommends listing a set of decisions that could potentially be deeply regretted (i.e. irreversible ones) — in my experience a pre-mortem is a good workshop technique here. Armed with this, we can actively focus effort on systemically making these decisions reversible — the sword of reversibility becomes a weapon to help teams make timely decision.
Wrap up
Making the wrong decision is part and parcel of life, so it is understandable teams naturally get hung up about making them to the best of their ability. In our quest for perfection, maybe good is enough, anything more risks the team getting bogged down and descending into paralysis. Taking time and effort to explore the reversibility of decisions is a useful tool for any team facilitator. Using it can focus a teams attention on what matters, and more importantly, what matters less.
