🔗 This article is a cross post from the Scott Logic blog

It occurred to me that the Agile Manifesto turned 18 this year, making it old enough to drink in pubs in the UK. That's quite a long time. In all honesty, how do you think it's going?

From experience, projects which are decreed as "Agile" up front translates into adopting a particular framework (Scrum, Kanban or SAFe). The implication is that this is how we're "doing Agile". Sure, you can tinker with the edges if something's not quite working out. But ditching the whole framework and doing something else? Unthinkable. Here's your box. Get back to work.

I'm not saying that these frameworks are fundamentally bad; far from it actually. They're fantastic starting points in a journey. Scrum gives you a minimal setup in terms of ceremonies and inspection/adaptation cycles to facilitate you being agile. SAFe provides portfolio-scale delivery projects, typically accustomed to more traditional software development practices, with a transition mechanism to more flexible and adaptable ways of working. Sometimes the benefits these frameworks bring are overlooked because the bleeding-edge have rejected them, or because the SAFe organisational diagrams are daunting to look at. There's a perception of the "enterprising" of Agile Development at play here, especially as the term "business agility" contains an aspect of appropriation. There is good stuff in each of these frameworks that is worth recognising.

All of this overlooks the matter at hand. Software delivery is difficult. Agile methodologies are undoubtedly and provably better than what came before, but in no way have they "solved" the difficult problem.

Returning to the Agile Manifesto, I was surprised by its subtle use of language. The document says "we are uncovering better ways of developing software", not "we have uncovered". Following this are a set of comparative and qualitative values, not entirely rejecting what came before it, but placing more value on some other aspects at play. There's no commandments to follow. Just principles and values.

Dave Thomas, one of the signatories, remarks on the difference between the noun Agile and the verb agile. Confusingly the manifesto is for Agile Software Development - i.e a named thing. Yet the principles and values describe agility, which is what you seek to practice.

Scrum, Kanban, SAFe - these process frameworks are noun-Agile. You can be verb-agile within those, but there's no guarantee. When an Agile project fails, or doesn't seem to be bringing you the proclaimed benefits, we feel disheartened. Very often that's because the culture isn't promoting agility, or is resisting its adoption. This manifests in several forms, such as: Scrum-But ("we're doing scrum, but…"), the "wagile" pejorative, or SAFe's release trains being misused to drive Gantt-chart deliveries, to name a few. At best you've established a division of labour and a management framework but have made no inroads into solving the problem of making software delivery easier.

These are not reasons to feel dejected. Rather, this is empowering. The sages of times gone by have not uncovered a set of universal truths, just painted a rough outline for a way forward. Absolutely, go ahead and adopt Agile frameworks if you need a helping hand, but don't feel bad about moving past them if they no longer suit your needs. You're finely attuned to the workings of your team, your domain, your ways of working. What you think about this matters immensely. The actions your team takes to improve its way of doing things are important. That needs to come from you. Listen to each other. Take what's good, drop what's bad. Repeat.