The Agile Paradox

I bet you work at a company who’s doing Agile. But have you ever actually read the Manifesto for Agile Software Development?

The first of the four key principles is this:

Individuals and interactions over processes and tools.

The Manifesto for Agile Software Development

Now why is this so important? That’s what’s today’s blog post/rant is going to explain…

The agile concept consists of many thing. However, the part called “Scrum” has taken over at the most (only?) dominant feature of Agile. If you Google “Scrum” you will currently get around 62 million hits. A lot of those pages defines the Scrum framework and all it’s relevant processes. Things such as:

  • A daily stand up meeting
  • Sprints
  • Sprint plannings
  • Retrospectives
  • Reviews
  • Backlogs

I bet you can name a few more yourself. And alongside all these fantastic processes, comes a number of Agile tools. Tools such as Azure DevOps or Jira are probably the most prominent. And to manage all of these processes, using these tools, someone invented specific roles, such as Product Owners and Scrum Masters. And to help train those (and the rest of us peasants), we have Agile Coaches.

Maybe you are starting to see my point. If the original Agile values individuals and interactions over processes and tools, then why the heck do we have so many processes and tools? Hence arises The Agile Paradox. The more Agile your company is trying to be, the more processes and tools are introduced, often taking the focus away from individuals and interactions. In the attempt to be agile, we became so agile, that we are no longer agile.

So how do we fix this? If I knew this, I would probably be a very rich man. But I do have some suggestions. First of foremost, read the four key concepts of the manifesto. They are:

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

The Manifesto for Agile Software Development

You can still have processes, tools and special roles. They aren’t necessarily bad on their own. But every time you introduce one of these, you must look out for possible effects on these core concepts. Maybe you introduce Jira and people start looking at user stories instead of talking to each other. Or maybe you introduce a new documentation system, which severely slows down progress on your product development. I cannot tell you all the possible pitfalls. All I can tell you is to be aware.

And finally, if you are looking for a way to reboot your agile ways of working, look towards some of the authors of the original manifesto. For instance, Alistair Cockburn has introduced Heart of Agile, which seeks to take agile back towards the original idea. Robert C. Martin (a.k.a. Uncle Bob) has released a book called Clean Agile (which I have yet to read). Or you could read the book I’m currently reading, called Agile Conversations. Even though the authors of this wasn’t part of the original manifesto, it still captures a lot of the original thoughts and comes with some practical exercises for you and your team.

Whatever you decide to do, remember that processes, tools and roles are never the final objective. A good product is what you should be aiming for. If agile isn’t helping you achieve this, then don’t do agile. Or at least try doing it in a different way…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s