Should we still be using ‘Agile’ as a selling point? Aren’t we all Agile now?

At Browser Group we use Agile development methodologies in our projects. But you know that already, right? It’s not particularly unique as all our peer agencies are also Agile. In fact, Agile is so ubiquitous it’s hard to argue that it’s a selling point. I mean, aren’t we all Agile now?

The answer to that last question is yes and no, or “yes, but”, or a yes with a pretty hefty list of caveats. Agile has become the dominant development paradigm and its influence has become widespread, but its application is certainly not as consistent as it should be. Outside software development projects, Agile is still embryonic, meaning it can still feel somewhat alien to our business stakeholders and user groups.

From methodology to mindset

Over the past few years, Agile has become more than a methodology to deliver software development projects. It’s arguably now a culture and philosophy that has influenced wider organisational project management and even some team structures beyond IT. It’s a mindset, as much as it is a set of techniques.

At the same time, there is also an increase in general business thinking about the power of more agile and iterative approaches to business, as a source of innovation, competitive advantage and greater responsiveness to customers. Agility and speed to market give you the edge, and a better ability to navigate the challenges of a pretty volatile world. McKinsey even wrote about three main outcomes of “agile transformations” with more satisfied customers, happier employees and improved operational performance, resulting in tangible differences to the bottom line. 

When agility is valued by an organisation, Agile development offers a compelling and mature example of applying a methodology that results in greater agility. The Agile (with a capital A) has influenced the agile (with a little a). Techniques such as the daily stand-up and sprint planning are sometimes encountered in more general project management. It’s also possible that among business stakeholders who don’t fully understand Agile development, the distinction between Agile and agile has become blurred.

To what extent are we Agile?

Back in 2015, our current Head of Product Robert McWhirter wrote a piece on this site called the “Agile web development process explained for non-technical people” which did exactly that, giving the ins and outs on Agile methodology. Robert wrote that Agile development was for many “something new, exotic or unknown”. 

Seven years on and there’s certainly much more awareness of agile among non-IT folk; it’s been a methodology and influence that’s been put into practice in many more organisations, and many more marketers have been involved in an Agile or nominally Agile project. They’ve participated in stand-ups, think in sprints, and even adopted a Kanban board for their own use. Agile development is no longer exotic or unknown.

But this knowledge is certainly not universal. Occasionally we still point people towards Rob’s blog and when we undertake client work, we do encounter many who have never really taken part in a project run on Agile lines.

So how mature are Agile development practices? The Annual State of Agile report from Digtial.AI provides potential answers, suggesting that we have some way to go. Although overall 94% of companies practice Agile, there are many who have practices that aren’t mature; 36% have been implementing Agile for two years or less or aren’t Agile at all. And outside software development, the influence of Agile starts to drop off: while 86% of software development teams have “adopted Agile principles and practices”, this falls to 63% for IT functions as a whole, 29% for operational teams, and only 17% of marketing departments.

Fifty different shades of Agile

One of the problems is there are differing interpretations of Agile. A project that is labelled Agile doesn’t always end up being so. Using a bit of imagination, we can label these different shades of Agile:

• Agile in name only: a project that is actually Waterfall with perhaps some stand-ups and a Kanban board
• One way Agile: a project where the development team are sticking to Agile principles and methods, but the other stakeholders aren’t playing ball
• Selectively Agile: a project that cherry-picks some of the key techniques for Agile, but ends up not really delivering the benefits
• Sprints-only Agile: a project that is not Agile, but where there are sprints which are just periods of two weeks rather than being proper cycles
• Start Agile, end Waterfall: a project that starts out Agile with good intentions but ends up being Waterfall because Agile is applied in a loose or half-hearted manner
• More fragile than Agile: a project that aims to be Agile, but inexperience or lack of commitment means Agile components are not rigorously applied and keep breaking down.

Of course, there is nothing wrong with taking elements of Agile development and making them work for you. Some organisations do this successfully, recognising cultural or structural barriers to going fully Agile. But often not going fully Agile can mean you’re less able to enjoy the benefits. 

Agile doesn’t guarantee success

It’s also important to stress that, even applied in full, Agile methodologies do not guarantee successful outcomes. There are various estimates of the percentage of Agile projects that fail, but most seem to suggest that at least they have a greater chance of succeeding than Waterfall. (Personally, I find the black-and-white of success/fail is unhelpful when applied to projects, as outcomes and their consequences have to be taken into context.)

Agile is also not universally popular. There’s a UK indie band called MJ Hibbett & The Validators whose most recent album contains quite possibly the world’s first pop song about Agile methodologies. The lyrics are very funny and convey some of the valid criticisms when Agile is misapplied, including immortal lines such as “Cos when we muck the whole things up, We can call it Minimum Viable Product, If you don’t like it – tough luck, it’s Agile” and “The Project Team says that’ll do, We’ll not be here for BAU.”

The lyrics reflect a feeling that Agile can become a mantra that can legitimise any output, an overarching methodology where the process seems to be valued more than the actual product. It’s a sentiment that we do encounter among business stakeholders and product teams, and sometimes among IT staff outsides the development team. Perhaps unsurprisingly, it turns out MJ Hibbett has a day job as a database administrator.

What can we do to make Agile development better?

The most pressing question in all of this is how teams who are wanting to make Agile methodologies work better in their organisation. I think this is both about demonstrating good practices, but also about spreading awareness:

• Setting out the roles, rules and process details of the project before it starts, and walking through these in more detail for the entire team, even if it’s treading old ground for some team members.
• Creating a climate where it’s acknowledged that not everybody is used to Agile so people feel OK to ask questions rather than feeling they should know and not asking.
• Being explicit about Agile maturity and identifying where practices need to move.
• Creating an Agile community within your company that can swap tips and tricks, and where teams can ask questions to more experienced practitioners.
• Being disciplined and sticking to the processes and structures, applying persistence across each sprint even if not everyone is playing ball.
• Never using Agile as the mantra to justify poor output or not addressing issues which need to be fixed. 

Conclusion

Are we all Agile now? Well, we’re getting there, but the more truthful answer is no, not really. And should we use it as a marketing term? I’m not sure it’s really helpful, as it’s open to misinterpretation and not always understood. Instead, we need to focus on making Agile development work better, so it truly delivers projects built on human-centred design with fantastic output that makes a difference. As that happens and Agile delivers its true potential, then more people are going to truly embrace Agile methodologies.