How to bet safe and lose
Being Agile Coach allows me to observe lots of interactions between product teams and (senior) management. I bet it would be entertaining experience if only I could care less about the outcome.
Surprisingly, I realised I care also about you and your teams. Yes, I don’t know you and I don’t know the people you’re working with. Nevertheless, it makes me a bit sad every time I think of someone somewhere experiencing the same issues.
Here’s my attempt to share with you patterns I observe. I hope reading this will help you, regardless of whether you are a member of leadership team or a change agent like me.
Let me give you some context first.
From a point of view of adopter categories, Agile processes are now entering late majority segment of organisations and Agile mindset is being adopted by early majority. For Agile Coaches and Scrum Masters it means we more often work with companies in which structure, culture, politics or combination of those prevented successful Agile adoption in the past (or still preventing).
To be clear, I think Agile is not a cure for cancer nor a solution for each and every problem your organisation may be facing. Yet, too often I see leaders try to improve the black box called Agile without understanding what’s inside and how it works.
One of the things in the Agile box is asymmetric payoff. If asymmetric payoff was a magic spell, if would have a power of influencing the possible results of projects, so that the upside potential has a greater chance of occurring than the downside risk. Naturally, each individual initiative with such payoff could still fail, however the portfolio of such initiatives is expected to succeed in the long term.
One approach has a power to counter asymmetric payoff. It is: reducing variation, ensuring there’s no uncertainty at all. It’s a counter-spell.
Unfortunately, people (leaders especially) are averse to uncertainty. I can think of a plethora of reasons behind such behaviour, which I am not going to talk about. Seems to me that making a good decision is about understanding the context and understanding what approach (or tool) may work in such context. So instead, below I describe a few context specific examples, which I see being repeated the most, examples of how people try to bet safe and lose anyway.
Decide product features upfront
When presented with new product/project idea, the management team is concerned about Return of Investment. There are two parts in ROI: perceived benefit and estimated cost.
There are also at least two ways of dealing with it:
A) Decide upfront how to solve the problem and what product to build, then estimate effort related to it.
Given the years of experience and seniority of the decision makers, estimating benefit seems to be a reasonably low risk bet. Cost estimate, based on a known solution should be pretty accurate. All that’s left is to calculate ROI, make decision, await delivery.
B) Delegate problem to the product development team and revisit progress regularly.
The development team may know little about the business area, will need to learn about the problem and figure out how to solve it by interacting with customers and trying multiple hypotheses. Not only does it seem to be a risky bet, it’s also expected to be difficult to estimate and will require regular attention to monitor progress. It’s not a ‘fire and forget’ initiative.
If we frame it that way, it’s no surprise option A wins in some organisations. But here’s what they are missing…
It’s like placing bets in horse racing. Option A is to place your bet upfront and wait until the end of the race, to see which horse wins. Option B is like placing a bet with an option to: select horse later, amend bet at any time, or even remove the bet (paying some % as a cancellation fee).
Due to the incremental nature of product discovery and delivery, Agile teams are capable of verifying (early) the problem-solution hypothesis, while simultaneously learning about what may be the next best bet.
Option B allows for ‘pulling off the plug’ when we learn expected benefits are not in line with estimated costs (becomes an interesting aspect, when we realise that even successful organisations like Google or Amazon are reporting that at least 50% of their initiatives do not deliver expected benefits).
Also, it allows them to pursue opportunities not known upfront, but identified in the process, which can bring much higher benefits than initially anticipated or provide such benefits earlier.
Actually, both A and B are ‘fire and forget’. The subtle but significant difference is that option A targets expected output while option B targets expected outcome (but requires trust to be present).
Deciding features upfront satisfies the need for successful delivery while targeting the problem satisfies the need for delivering success.
Optimise for preventing past problems
When exposed to unexpected and damaging situations, the management team wants to mitigate the risk of running into such circumstances again in the future. The resulting plan usually falls into one of two categories:
A) Add an increment to the existing ecosystem, (consisting of policies, rules, processes, roles, hierarchies, etc.) so that the risk of incident reoccurence is mitigated.
Given the increment is small, this approach is considered a low cost and low risk option. It is assumed that the effort required to implement change and the ongoing cost are both low and that such prediction is expected to be accurate.
B) Redesign / evolve the ecosystem, so that incident occurrence is illogical or not a problem at all.
The intention here is to change the ecosystem. It is assumed that a thorough understanding of both the problem and the ecosystem is required. Therefore, both effort and related cost are considered high. Since almost no one fully understands the ecosystem, it is considered high risk to mess with it.
To keeps things simple, I will not even go into discussion about how both options A and B can suffer from being a project with the solution decided upfront…
Instead, I will attempt to clarify by using an example. Let’s say it’s a situation in which the product team missed the deadline, failed to delight key stakeholder and delivered product of poor quality.
Approach A (adding an increment to the system) may be to add a Project Manager to the team, so that he could manage and improve both timelines and communication with stakeholders. Adding a quality testing phase (and maybe a Quality Assurance manager) can be considered to avoid low quality getting out to customers.
Approach B (redesign the ecosystem) may be to educate the team, provide them with information and decisive power needed to make time/cost trade-off decisions, so that they know how to cheaply buy time (before it’s price goes up late in the project). It may also be to suggest changing the processes in the workplace to allow the team to contact stakeholders directly and create the quick feedback loop so that stakeholders are never dissatisfied regardless of when the project ends. Slowing down product development and rethinking department strategy may be needed to pay off variety of debts (technical included) incurred in the past, so that the rest of the portfolio of initiatives would not fail.
Which option would your organisation choose most of the time?
Here’s what you’re missing if you choose A…
Too many additions spoil the design. Each improvement is designed to prevent a particular problem. How many interventions are needed before the ecosystem will collapse, before delay and rework introduced by additional testing phase will be too much to accommodate and timelines and stakeholders will suffer?
How many managers you can add before you run out of ‘autonomy’ and they start to play politics against each other? Assuming the amount of power in the organisation stays the same, if you want to give more of it to one person, you first need to take away from someone else…
Last few bits
The list above is not at all comprehensive or complete. It is just a means of sharing my observations with you and observing how it resonates, what kind of feedback will I get.
Was it useful for you to read? Would you use better or other examples? Or maybe other problems with asymmetric payoff are the ones you observe the most often — let me know what you think.
More where this came from
This story is published in Noteworthy, where thousands come every day to learn about the people & ideas shaping the products we love.
Follow our publication to see more stories featured by the Journal team.
