The Link Between Agile and Agility

Guest Post by Howard Wiener (first posted on CERM ® RISK INSIGHTS – reposted here with permission)

In the previous article in this series, we discussed the difference between Agile and business agility and how Agile 2 addresses some of the omissions and failings of traditional Agile.  Both Agile and Agile 2 focus on accelerating digital development; however, the benefits of any Agile approach can be obviated if it is not implemented within an agile management structure.  Addressing execution issues, as Agile 2 does, will not be sufficient by itself to get you where you need to go. 

Achieving business agility will also require that you reformulate your company into an agile organization capable of increasing the iteration speed of the Strategy-Execution Cycle we presented in the previous article.  This article will focus on aspects of what that will look like.

What Does an Agile Company Look Like?

An agile company treats its products and services as a portfolio.  

As such, it needs to diversify across a number of dimensions, for example:

• Lifecycle stages—concept, experimental, MVP, commercialized
• Risk—the company cannot afford to take on a large number of ‘moonshot’ initiatives. Ideally, it will balance base hits and attempts at home runs.
• Financial Considerations—the company has to manage how much it is able and willing to invest in product and services evolution vs. how much it requires for ongoing operations.

Is this substantially different from how companies have been managed to date?  Not necessarily.  Companies have long been organized into operating divisions in which specific products or services are developed and managed.  The determining factor for many products’ ‘home’ division may have been the products themselves—cars vs. trucks, for example—or targeted customers—businesses vs individuals.

An agile company conducts explicit experiments in developing its products.  It articulates the assumptions and hypotheses it’s testing and prioritizes its activities to prove or refute products’ commercial potential as early in their development as possible.  

One thing that differentiates the agile company of today from the traditionally managed company of a while ago is redistribution of investment decision-making downward toward people performing day-to-day product management.  A requirement to raise issues through the hierarchy to increasingly senior management for resolution has become too burdensome and time-consuming to continue.  Such ‘command-and-control’ management structures are crumbling.

Another thing that characterizes agile companies is that they don’t engage in legacy funding or classic ‘project’ management practices, which can actually constrain agility.  Funding new ‘projects’ only at prescribed intervals (say during the annual budget cycle) and with fixed budgets and timeframes is patently anti-agile.  Trying to execute agile development within the envelope of such approval obviates most of the benefits of agile approaches.  It leads to ‘Water-Scrum-Fall,’ which has been described by many industry pundits similarly to the quote, below.

“Whatever you call it, a partial Scrum implementation can have negative consequences. The fundamental thing to understand is that Water-Scrum-Fall is a hybrid approach to software delivery that mixes different modes of thinking and behaving. The different modes conflict with each other, and that conflict degrades the overall value of either approach. [1]”

Such management approaches intrinsically force management to focus on output—how much of what we said we were going to build has been built—as opposed to outcome—what elements of the product or service have we been able to put in front of potential customers and how has it been received?  When new information comes in, a need to refocus and change can conflict with the original approved ‘project’ parameters of scope, budget or schedule.  A need to request approval to revise a project charter can create an impediment to applying information to evolve what the team has been developing.

If a prospective product does not ‘prove out’ within a reasonable time, its development is terminated.

Venture Capital companies invest in a portfolio of early-stage companies to spread their risks and increase their chances of one or another of their portfolio companies succeeding.  They fully expect that more than 80% of their investments will not pan out but the ones that do will be very rewarding.

Agile companies should maintain a portfolio of developmental product or service ideas and operate in the same way.  Many or most of their ideas will not bear fruit and it is in the company’s best interest to accelerate the process of determining which will and which won’t so that development capital can be redeployed to where it is most likely to bring a return.  Agile companies do not waste time with recriminations about experimental failures.  They are to be expected and provide knowledge that can be applied to both current products and future experiments.

The Link Between Agile and Agility

Here’s where Agile development makes an impact: the faster the development team can iterate the evolving product, the faster it can become market-ready if it going to succeed.  Conversely, the longer it takes to figure out that something isn’t going to work, the more money and time will be wasted on it.  If your development capability isn’t up to speed, you’re going to fall behind competitors whose is.

So, given the importance of the ability to define, build, evolve and release products rapidly, you should see the importance of adopting agile management practices.  Without them, your Agile development practices cannot deliver at the speed you need them to.

Unfortunately Agile, as it is practiced most places, often fails to deliver on its promise, regardless.  Why that is and what you can do about it will be the subject of the final article in this series.

[1] https://www.plutora.com/blog/water-scrum-fall