How Agile Development Prevents Leaders From Investing in a Failing Strategy

London Business School faculty recently published an article titled, Why leaders invest so much in a failing strategy: Once you’ve committed to a business strategy, it’s strangely easy to ignore the warning signs. The gist of the article is that companies often stick to outdated strategies, with Marks & Spencer as an example, for far too long.

In an era when digital disruption is pervasive, how can leaders avoid making a similar mistake? The authors propose that leaders must "challenge mutually reinforcing biases that see people being influenced by a prior commitment to a particular course of action." According to the research, this occurs for six reasons (listed below) and suggests six measures to prevent it. While these measures may help avoid an organizational escalation of commitment, StruXure advocates using agile methodologies and as-a-Service partnerships to mitigate the six (6) reasons.

The rest of this blog will outline how agile methodologies and as-a-Service agreements address each of the six reasons (as it pertains to information technology investments). The combination of these two relatively new concepts drastically reduces the risk, ultimately helping leaders invest in a winning strategy. Without further ado:

• People who make investment decisions proceed with a project even if outcomes are unfavorable because of the costs they have already incurred. Those costs won’t be recovered if they walk away. This is called the ‘sunk cost fallacy’.

Image Credit: London Business School: Why leaders invest so much in failing strategies

Number one is addressed primarily through as-a-Service contracts in combination with agile development. With as-a-Service contracts, leaders invest less up front, which structurally incentivizes providers to demonstrate value quickly and sustain it throughout the relationship to encourage renewals. Read more about the 67% drop in software since 1997. Agile development also mitigates this risk because the "fail-fast and cheaply" mentality, combined with continual feedback and iterative development, allows the business to obtain near-immediate validation that the provider and solution are heading in the correct direction. Put differently, by the end of the second development sprint, you should know if the provider will be able to deliver.

• Decision-makers prefer to invest more in a course of action rather than withdraw and lose everything, believing that they can turn the situation around. In this scenario, people suffer from loss aversion.

Loss aversion is inherent within all of us; it's part of our evolution as a species (it's a survival tactic) and explains why we react more negatively to adverse situations relative to positive situations of similar magnitude (i.e., losing $100 dollars makes people more upset than finding $100 makes them happy). Agile development, when done correctly, positions an organization to know quickly whether or not the solution will work by focusing on the MOST CRITICAL functionality first. Read more about agile development here. If new requirements surface that take precedence over existing functionality, they simply move to the top of the next sprint, and all requirements slide down the queue.

Agile development also mitigates this risk because the mentality of "fail-fast and cheaply" combined with continual feedback and iterative development allows the business near immediate validation if the provider and solution are heading in the correct direction.

• The illusion of control takes hold. This bias, reinforced by the previous two, leads people to overestimate their ability to control the future. They take credit for the outcomes of decisions and confuse forecasting the future with actually making it happen.

Number three is also addressed by agile development as the agile process takes into consideration that the team "doesn't know what they don't know." When it comes to agile software development, if the most critical piece (i.e., the current priority in the current sprint) of functionality cannot be developed, forecasting the future does not happen until the current impediment is addressed. If the team cannot take control and conquer the current technical or operational challenge, it's time to course correct. Weekly or daily SCRUMs will prevent this roadblock from going undiscovered.

• An inherent desire to complete tasks such as loading the dishwasher or finishing a project drives most people who have a preference for completion.

The waterfall (or V-model) methodology was originally borrowed from manufacturing and repurposed for software development. The problem with this approach is that manufacturing a car or building a house has sequential processes (pour foundation, build frame, etc) and a definitive end. This process is inadequate for software development as requirements continually change, and therefore, the system(s) must evolve. Continuous improvement is inherent to the agile process; as the team adopts this understanding, the focus shifts from a preference for completion to a commitment to iterative improvement.

When it comes to agile software development, if the most critical piece (i.e., the current priority in the current sprint) of functionality cannot be developed, forecasting the future does not happen until the current impediment is addressed. If the team cannot take control and conquer the current technical or operational challenge, it's time to course correct. Weekly or daily SCRUMs will prevent this roadblock from going undiscovered.

• Those opposing a course of action often remain silent because they believe no one else shares their view. Meanwhile, colleagues interpret their silence as agreement. That can lead to everyone agreeing to a decision that nobody believes in. This is known as pluralistic ignorance.

Number five is addressed by a combination of the as-a-Service contractual structure and agile development. Firstly, if milestones are not met and value is not created, there is no incentive for the client to continue to make their subscription payments. The agile process further ensures agreement by getting the Subject Matter Experts (SMEs) involved early on in development to validate / sign off on stories. Additionally, by accepting and incorporating feedback from users (named or anonymous) and having that feedback reviewed during planning / priority sessions, the agile process encourages stakeholders to document their concerns and build consensus on what should be developed next.

Continuous improvement is inherent to the agile process; as the team adopts this understanding, the focus shifts from a preference for completion to a commitment to iterative improvement.

• Psychological and sociological studies show that someone’s identity and social status are often linked to their commitments. People can suffer a perceived loss of status or a threat to their identity when they withdraw from a commitment.

Again, agile to the rescue. By having Subject Matter Experts (SMEs) involved in major design decisions, providing sign-off on requirements during user acceptance testing (UAT), and serving as super-users during rollout, the organization can significantly reduce the adoption risk because consensus is built during each new release.

While agile development is not a panacea for all Information Technology woes (you still need capable people and must follow the process), it is no coincidence that the most successful innovators today use some form of agile within their organization. Happy scrumming!