Is agile the last word?

Nothing lasts forever and there’s always the next big thing. Has Agile won or is it dead already?  Something I’ve been pondering for a while is what’s the next big thing in project delivery?

Agile has been around for a while now, and businesses are still struggling with its adoption. I asked the IIBA (International Institute of Business Analysis) LinkedIn group what they thought, and I got about 40 differing opinions. I did some research and again I got a typical mix of views.

• ‘Agile is dead already.’
• ‘Agile was never meant to be used for what it is now.’
• ‘Agile is the only way.’
• ‘Businesses need to be agile, but that doesn’t mean they need to adopt a specific ‘agile methodology.’

The conclusion I’ve come to is that actually all of those opinions are right. Most importantly – there isn’t an ‘Agile’ silver bullet that you can implement into your business and make everything better. There isn’t a methodology that you can stringently adopt that will mean all your projects get delivered effortlessly.

Indeed the very premise of agile, as a word, a concept and a manifesto, is about being adaptable and responding to change. A strict project or development methodology breaks that very premise.

The Agile Manifesto

The Manifesto for Agile Software Development was just that. A manifesto for software development. The problem with that?

It was never written to extend beyond software development. As those of us with war wounds from projects know – a large business project never starts and ends with just software development.

Agile was developed to improve software development methodology. The original 17 founders of the agile manifesto, are still trying to do that. Some have moved on from the original manifesto and are looking at new and better ways of developing software.

Death by Popularity

Last year, I attended a conference on family-friendly working. The word agile was used frequently to refer to flexible working in terms of hours and locations. I also heard agile used in reference to hotdesking.

Whilst these applications of the word aren’t actually wrong – agile just means nimble and flexible – they do muddy the water when we have projects of work using Agile methodology. The popularity of the word agile and its potential overuse just adds to the confusion.

There’s also the Agile Marketing movement and more general discussions on agile cultures. Again both merited uses of the word and potentially successful ethoses.

However, they may further add to the confusion when business leaders, technologists and marketers come together to deliver a project – whose agile is this anyway?

Design vs Development

I’ve personally been stuck in the middle of this argument.

What a design sprint entails in an agile world vs a front-end development sprint don’t deliver the same things, don’t have the same rates of execution, the same stakeholders and beyond. Sprint – that simple concept within the agile nomenclature can cause masses of confusion, and honestly they don’t really align.

Design sprints need to test features with users quickly, and so does development, but front-end to back-end development doesn’t follow the same creative cycle of design and they have different gestation times.

Sprints are just time periods during which specific work has to be completed and made ready for review, but you can’t get the same amount of development done as design in the same timeframe.

Design methodologies

Service design, user and customer experience design, user interface design and all the rest could be described as methodologies themselves. But once the design has been done, and technology is required, the agile software development lifecycles begin.

These should still iterate, test and learn with users, and business counterparts. They needn’t be at odds, but what is needed is clarity between the design methods and the project approach or development lifecycle.

De-risking design and de-risking development can both be achieved through iteration – a key premise of agile, but not necessarily within the same sprint cycles.

Beyond Agile

I’ve read a bit on DevOps and think this might be where to hedge your bets on the future of software development at scale, however, I’m not sure the pushing of most work onto less discrete roles is the answer either.

Scaling is certainly one of the key criticisms of agile project methodology. What works to build a small app doesn’t necessarily scale to an enterprise-wide programme. That said traditional waterfall methodology is flawed, as Mike Gill discussed in Seeing the Light and Go Agile or Go Home.

Where that leaves us

So businesses need to be agile – that is flexible around the needs of their teams, their customers and logistically in line with the digital age. But that needn’t be confused with agile software methodology or design methodologies. The most important point in developing a project approach is:

1. That there is an approach that is communicated and understood by all participants
2. That it is not delivered in silos
3. That it is designed around the needs of the customer and that co-creation is looked for
4. There are common goals
5. It is open to change when things don’t work.

Meaning it matters less whether we call it agile or anything else and more that everyone knows what’s happening, is working together and willing to be progressive rather than dogmatic about the methodology.

I do believe agile is better than waterfall, but I don’t think that’s the last word on the subject. There will be the next wave of software development methodology and beyond that businesses will be more agile as they are enabled by technology and respond to the demands of the workforce and their customers.

Arrange a Conversation