image of lights blurred

Agile adoption is a hot topic, and one of the biggest C-suite missions of the year. Let’s face it, who wouldn’t want a more flexible organisation that adapts quickly to market changes? But before we crown it the new standard in ways of working, let’s take a minute to really understand what Agile is and how it should be applied to avoid the common pitfalls of mass adoption failure.

Part process, part philosophy – Agile has emerged from multiple roots (such as Lean, Extreme Programming and Rapid Application Development) over the last 30 or so years. It has two driving factors:

  1. Frustration with inflexible and often unsuccessful big projects that used approaches we now lump together under the title “Waterfall”
  2. A mixture of awe and envy at the speed new, technology-based businesses have grown to colonise and dominate the web-based economy.

‘Old economy’ businesses have experienced first-hand how this cross-functional Agile way of working has been successfully employed to develop highly disruptive products. Just take a look at Spotify or Monzo. Agile done well, through productive sprint cycles, allows rapid iteration and development of a product until the marketplace confirms (through sales, adoption or downloads) that something of value has been built.

Established businesses were, and often still are, plagued by expensive projects that were as likely to fail as succeed. Creating IT systems to support new, engaging, and most importantly customer-oriented offerings dragged on and sticky-plastered over issues rather than fixing them. And ultimately, they failed to achieve benefits quickly enough.

It became easy to blame the Waterfall methodology for these failures, but even so, some of the critiques are wildly exaggerated… “If there is a requirement error, then the project will have to begin from the start and all of the coding has to be re-done” is just one example. The truth is that no real-world methodology was ever “pure” Waterfall. They all allowed for overlap between phases, and for re-work when a problem, or a better idea, was discovered.

This blaming of Waterfall has also fuelled further opinions:

  • Agile is hailed as the silver bullet to improve IT delivery. It can be – but there needs to be a high level of existing IT maturity and delivery focus in the first place for it to work;
  • There is a perception that talent can’t be attracted in the absence of Agile, driven by the fact that many tech companies apply it so effectively

Agile can get confusing quickly. There is a plethora of methodologies; SaFE, Scrum, DAD, Nexus – the list goes on and on. Commentary around these suggests that using a specific style is the only way to guarantee success. But, nobody follows these methodologies to the letter. Smart businesses adapt from many styles and apply what is right for their organisation. A common mistake is to believe that Agile is right for all projects or throughout the development lifecycle. The power is in knowing when and when not to apply it.

In our experience, Agile can work very well in two scenarios:

  1. You are developing a completely new product. It is difficult to define what the exact requirements are, but you know broadly what you want to achieve. Or;
  2. Your product is already in use, and you are continually enhancing performance through developing small incremental features.

The power is in knowing when and when not to apply it.

However, if you are replacing an existing product or system, the requirements should be fairly well-known. It would be unacceptable to release the functionality of the new system incrementally – the “business” simply wouldn’t welcome it. At a minimum, the first release of the new system is going to need to do most or all of what the old system did, or at the very least, what it did well!

To use Agile in this scenario, you’d need to keep “banking” the results of your sprints until you’d accumulated enough robust functionality to launch it to your customers. Under these circumstances, a well-run Waterfall approach may be more efficient. But that said, Agile can be used effectively in parts of these projects – for example, to prototype a new user interface or user experience.

The number of corporate organisations moving towards more Agile ways of working will only continue to grow. The most effective of these transformations will be selective, identifying when and where to apply it and accepting that it may not be sensible, or even feasible, for all teams to work in this way.

Beyond understanding what Agile is, and when it makes sense to apply it, there are also a number of critical factors to get right in your organisation. In the next article in this series we will examine key elements for success, and offer a practical approach to testing and applying the most appropriate working styles.

In the meantime, if you have recently attempted a transformation, or are about to embark on one, we’d love to hear from you. Get in touch.