Why Agile isn’t Delivering Business Agility

Written by florianbrondel | Published 2018/12/13
Tech Story Tags: agile | product-management | business | innovation | software-development

TLDRvia the TL;DR App

While agile gains traction year over year and most practicing organizations acknowledge most of the benefits, the 12th Annual State of Agile Report (2018) unveils:

‘only 4% [of respondents] report that agile practices are enabling greater adaptability to market conditions’.

So, while we’re all increasingly delivering according to agile practices, the needle is hardly moving when it comes to business agility. And yet, under pressure of fierce market changes, leadership is trying to turn the wheel towards innovation.

Agile and operations

Historically, agile has been welcomed by organizations to improve operations with short, more responsive feedback loops enabled by iterative delivery. Agile transformation, however, was often not intended to change the process deciding what gets executed, but merely to make execution itself more efficient. No feedback loop was implemented covering both strategy and execution, hence the lack of business agility.

Management is traditionally reluctant to leave its strategy-structure-systems approach, maintaining a top-down instructional model. Unfortunately, in an environment where organizations are forced to try out ‘new’ things, the value of what gets executed is not so certain anymore.

Operations and innovation

Innovation has many definitions, but when it comes to methods and frameworks, its most important aspect is uncertainty. If an organization wants to be able to respond faster to changing market conditions, it needs to deal better with uncertainty.

According to Steve Blank, the most promising approach for succesfull innovation in established organizations is by having operational teams adopt the ‘innovation stack’.

these curricula [innovation stack] teach what it takes to turn an idea into a deliverable product/service by using the scientific method of hypothesis testing and experimentation outside the building. This process emphasizes rapid learning cycles with speed, urgency, accepting failure as learning, and innovation metrics.

And this absolutely makes sense:

  • Operational teams are closest to the action, often acquiring vital feedback first-hand.
  • Innovation is a numbers game. With a low hit-ratio, the number of attempts determines the possibility of succes.
  • For an established organization, adoption of new practices is at least as hard as finding and validating a good idea. Operational teams serve as a better catalyst compared to outside-of-business or management enforced initiatives.

Traditionally, in established organizations, agile has been the tool to improve horizon 1 activities. Given the known business model, it is being used to (continuously) improve the supporting processes. From that perspective, dealing with uncertainty is usually limited to managing changing user requirements.

https://steveblank.com/2015/06/26/lean-innovation-management-making-corporate-innovation-work/

Horizon 1 activities support existing business models.

Horizon 2 is focused on extending existing businesses with partially known business models

Horizon 3 is focused on unknown business models.

Agile and innovation

Solutions have blindly been copied across industries and markets, assuming comparable results and outcomes would follow. Leadership assumes ‘we know how to do this’ and ‘we want one of those’ and orders operational teams to compile the same.

In the consumer market, uncertainty is better understood and accepted, but for enterprise initiatives, there is a bias to overestimate what is known. ‘I don’t know’ doesn’t sound very professional, does it? As a result, operational teams are involved in horizon 2 activities, without support of the proper frameworks to deal with the related uncertainty.

As Steve Blank notes:

Trying to integrate new, unbudgeted, and unscheduled innovation projects into an engineering organization that has line item budgets for people and resources results in chaos and frustration.

One of the recurring complaints of agile teams is indeed the mismatch between their iterative approach, enterprise budgets and deadlines. Management, however, ‘has a business to run’. As such, these complaints get ignored. Unfortunately, more than once, the complaints are a symptom of a more profound problem: uncertain business outcome.

Someone should acknowledge and name this uncertainty. Only then could the organization move on and adopt the right tools up to the discovery challenge at hand.

Agile teams should expand their multi-disciplenary skills with the innovation toolkit, popularized by the Lean Startup movement and further evolved as Lean Product Management, allowing them to experiment, challenge and validate expected business outcome instead of blindly accepting it as a fact.


Published by HackerNoon on 2018/12/13