There is a fiction that suggests that business decisions are made on purely utilitarian grounds. Psychologists have shown convincingly that people value the avoidance of loss far more highly than capturing gains. There are many and significant implications for those seeking to implement change, particularly in an agile environment.
The Agile Manifesto
The Agile Manifesto and associated delivery methods have gathered significant traction. This makes sense for those navigating uncertain consumer attitudes. It appears quite reasonably to have been adopted most enthusiastically in consumer-facing applications such as web sites and mobile apps, where the early exposure of an approach to end-users provides rapid feedback to the development team, steering later development. Although one of the principles of the Agile Manifesto is “Continuous attention to technical excellence and good design” agile approaches focus deliberately on working changes delivered rather than analysis delivered as an enabler (e.g. documented design). I have therefore seen agile as more applicable to the front-end than core infrastructure. Recent experience is challenging that perception.
Agile Business Transformation
Business transformation is a framework for delivering new or significantly enhanced capabilities to a business. Applications include mergers, demergers, new market entry and major changes in operating model often associated with outsourcing. The delivery of such a competence involves the coordinated development of many aspects concurrently. There are many moving parts. Managing such a complex set of interactions fries brains, driving otherwise calm folk to scream and jump off high structures. This is sad as there are perfectly well established approaches to maintaining orderly progress (read the article “Inside Change“).
If you find yourself contemplating the transformation of your business, I would endorse the adoption of an agile approach, subject to clear thinking about what it gives and where carefully considered underpinnings are still necessary to give excellence and good design. The first of these is in the laying of foundations to ensure that the leadership are committed to a consistent and coherent view of where they seek to go. Resist the temptation to “Just Do It” before you share a view of what “it” is and where the value lies. This is where the business case comes in. Too often, stakeholders have divergent views of one or more elements. If left unresolved, this will surely come to a head at some stage. It is much cheaper to face up to this at the start before the commitment of major resources and time than it is half way through construction.
What has psychology ever done for us?
As one trained as an engineer and accountant, I am used to thinking of myself as fundamentally rational, analytical and used to choosing based on the greatest expected value. Once more, perceptions are challenged. Utility theory would make a clear statement of preference between the following options:
“A: 61% chance to win $520,000 or 63% chance to win $500,000
B: 98% chance to win $520,000 or 100% chance to win $500,000.
If you are like most other people, you preferred the left-hand option in problem A and you preferred the right-hand option in problem B. If these were your preferences, you have committed a logical sin and violated the rules of rational choice.” (Thinking, Fast and Slow, by Daniel Kahneman.)
Daniel Kahneman established through multiple experiments that most people most of the time value certainty of gain and the avoidance of loss significantly more highly than utility would predict. Many quants, spread-sheet in hand, have emerged crest-fallen as their carefully worked-out business cases have been kicked into the grass by managers who have decided against the maximisation of expected value. Myself amongst them.
This matters, and matters greatly. The value that is foregone by choosing under the influence of these fears directly influences economic return. This is well known by insurance companies and retailers, who regularly make irrationally high margins on extended warranties, knowing that a significant number consumers will over-price the value of the risk of product break-down. Lottery operators know that if they can seduce us with the possibility of millions, we will willingly part with far more than a rational expectation of return would suggest; over-valuing the dream. That may provide entertainment for the gullible which is mostly just harmless delusion. If it is the investment of millions on a programme or corporate direction, we should all be more concerned.
The unscrupulous will use the dark arts of presentation to skew a decision. They will conjure vivid imagery to evoke strong emotional reactions that cloud judgement. Great if you want to win a referendum. Both sides do it. If you see such trickery in a business case, I suggest a strong reaction (prompt approval please where I am the prophet of doom).
The Implications for Agile
The agile approach requires rapid experimentation and thrives on early failure. It advocates many small bets as a way of hunting for the optimal solution. If one approach does not quite work as expected, detect this quickly, work out why and refine it. This says of risk “so what?” There is a risk that some or even many of my attempts will fail. Risk must be accepted if progress is ever to be made. Without tolerating risk, we are doomed to failure and irrelevance: the biggest risk of all.
Kahneman reports additional experiments on the subject of “framing”. By this he means the breadth of choice evaluated. In this context a programme is a connected series of sprints. What matters is the achievement of the overall benefits as soon as possible. In business transformation as in Kahneman’s choices, the greatest overall benefit is rarely intuitively guessed from evaluating narrowly framed choices in isolation. In a programme, some elements will be costly and have little direct end-user benefit. An example is the foundation of a building. However, the programme needs them if the edifice is to stand.
Whilst nobody seeks failure, given enough flips of the coin, it is nigh inevitable on some occasion. For a manager transfixed by the fear of loss, this is a real problem. Should the case of each sprint be viewed in isolation, decisions skewed by over-valuing the loss are sub-optimal for the overall achievement. It is vital to be able to proceed in awareness of the risk. Whilst all would acknowledge this in theory, do the individuals follow this through into practice? The success of the programme depends upon it. Sponsors and governance groups may need to wade in to make sure it happens and that the schedule is maintained.
The programme business case may be prepared and managed in the standard manner (see, for example, Managing Successful Programmes, 4th Impression, Axelos). It looks holistically across all the phases, through delivery and into operation. It assesses the risks in the light of the associated benefits, seeking efficiency and effectiveness but also recognising that they can only be managed down so far without losing the essence of the undertaking.
The aspect in which I have seen the agile approach to business transformation make great sense is in aligning the many pieces of the evolving picture. At first, it can be hard to see how they can fit. Then the task of scheduling it blows the poor planner’s mind (if they ever really attempt it). Maintaining the dependencies as projects move drives the planner to jabbering incontinence. Salvation comes in the form of the sprint. Dependency is managed at the level of the sprint: for which will it be available? Coherence is managed at the level of the sprint: does the set constitute a coherent viable product? Benefits are managed at the level of the sprint: how does this advance the programme towards the goal and what is the increment to each outcome? I take it as read that programme costs are related to sprints too, thus giving the governance group overall visibility of programme business case performance. Some sprints will not deliver as hoped, others will exceed expectations. This way the governance body can steer development, holding the programme managers to performance against a business case that is monitored and updated for each sprint.
This approach does not work everywhere. I have recently managed supplier exit and service transition where contractual obligations were not designed for phased delivery. It can however usefully augment your approach tool-kit.
Competition increasingly demands speed, whilst giving no quarter on cost. The many interactions involved make for uncertainty that can be terrifying for those who know only the old ways. The agile approach to business transformation offers an approach to phased development and small bets to manage down the risk. An awareness of the psychology of risky decisions helps the crafting of the question such that the manager thinks it through accurately without irrational distraction.
It takes effort to simplify a complex situation such that the way forward is obvious to all, and the obvious is also the best. There is beauty in simplicity. Strive for it!
This article was first published in Outsource Magazine and is published with permission.