Introducing agile practices, part 1: where agile fits in

Often, when I see organisations introducing agile into their ways of working, two big issues jump out – so I’d like to start this post with an observation and a warning.

The observation: If an organisation is serious about introducing agile into its ways of working, we must assume two things. Firstly, that it has looked into agile and decided it is beneficial to the company’s success; secondly, that it accepts one of the key characteristics of agile practices – iterative test and learn.

In essence, agile works on the basis that when you’re doing something that’s new or unfamiliar you should test your approaches and adapt in an iterative manner. To use a waterfall-style approach to change in order to introduce agile is a clear signal that the organisation doesn’t believe in the principles of agile, and its usefulness as a means to bring about change. If it did, it would be undertaking an agile approach to its transformation.

And now the warning: agile, just like all things in life, isn’t a one-size-fits-all solution to everything, but it does have its rightful place in the lifecycle of change. There are situations in which agile is absolutely the way to go, and then there are times when other delivery approaches are far more suitable. Too many agile transformations set out to make everything and everyone agile, as if everything they’ve done in their past is fundamentally wrong.

“Too many agile transformations set out to make everything and everyone agile, as if everything they’ve done in their past is fundamentally wrong.”

The evolving problem space

To use agile effectively, it’s best to understand what it’s for, and to do this I’d like to take a little time to explain a model I use:

In this diagram, we view the evolution of the problem-solving space from left to right. The upper half considers the environment in which we operate, while the lower half considers the products that exist in that environment (that we can use to solve our problems).

In the product space, new ideas emerge as advances are made in science, technology and technique. Initially immature, these ideas soon evolve into widely available products and cost per unit decreases with volume. These products continue to mature as new uses are found for them and if successful, they become ubiquitous. Eventually, they’ll be superceded and effort will move elsewhere, leaving them to stagnate and lose value. Familiar examples of stagnation include once-prevalent fax machines, film developing booths, and video rental shops.

In the environment space, fresh opportunities arise all the time as new products and techniques emerge. If we fail to take advantage of these opportunities, others will – and these opportunities mature into threats. These are the disruptors that all reasonably aware executives fear. If we continue to prevaricate, eventually these threats resolve themselves into incidents; disruptors grow into competitors and take over our market.

Previously successful companies can, of course, survive at the incident/stagnation end of the circle for some time before going under, and start-ups may initially thrive and grow in the opportunity/emerging space. However, if an organisation desires longevity, it has to be able to function effectively across this continuum.

Where should we become “agile”?

There are essentially three modes of operation that need to be supported to achieve this longevity. I think of them as Incubate, Industrialise and Improve (these modes are remarkably similar to the ones described by Simon Wardley in his Pioneer/Settler/Town planner model; not surprising really as “there are no new ideas under the sun”, and when something’s right, it’s just right).

To explain further, and in reverse order:

Improve involves taking the tried-and-tested practices we already have, tweaking and adapting them to shifts in the market. This works well initially, and companies may persuade themselves that this is enough. Eventually, however, the gap between the existing solutions and the outside world grow so wide that changes become painful and ineffective, and costs escalate. “Sweating the assets” is sound business practice; the trick is knowing when enough is enough. Techniques such as waterfall and Six Sigma work well in this space.

Industrialise is where a company takes a small-scale solution or offering and grows it as demand increases. This act of scaling requires all elements of the solution to be strengthened and optimised (industrialised) in order to maintain cost-effectiveness, increase reliability and deliver great customer experience. Unlike Improve, where changes are typically small, this phase can involve radical changes to the underlying components of a solution, as well as the way in which the service is delivered. This is where Lean can be very effective as an approach.

Incubate is where new ideas get generated or recognised, hands-on experiments are performed, and working solutions emerge. Operating in this space is hard; little will be known or predictable, and the participants are working with unfamiliar concepts. In the absence of hands-on experience, people fall back on assumptions, anecdotes and subjective opinion. Successful outcomes depend heavily on a willingness to test and learn to build up meaningful insights to guide further decisions. And this is where iterative techniques like agile thrive.

Most large organisations work heavily in the Improve space, with some degree of Industrialise capability (although this is often handled via outsourced providers). Inevitably, when such organisations try to adopt agile, the instinctive response is to apply it to these existing capabilities. Needless to say, the outcomes are rarely successful and never pretty.

So the message is clear: the place to introduce agile is at the very beginning of your solution pipeline.

For most organisations, this means creating a new capability, rather than transforming an existing one. The downside is that you’re not adapting something you already have, so your tried and tested change mechanisms won’t work. The upside is that instead of spending money fixing what you have, your money is being invested in something new and valuable.

This article covered where agile fits into the overall picture. In part two, we’ll look at how an organisation should set about bringing agile into its range of delivery practices.