It’s one of the great truisms of history that revolutions almost inevitably end up repeating the mistakes they set out to fix.

Some people level the same accusation at Agile. The ‘revolutionary’ approach to software development was meant to be a rejection of all that had become clumsy and inefficient about the IT industry – focusing on processes over people, documentation over working products, contracts over collaboration and creativity.

Two decades after the release of the famous ‘Agile manifesto’, lots of companies find themselves ‘doing Agile’ because they have heard it will make their development processes more flexible, innovative, adaptable and responsive to real-world needs.

Spurred on by the promise of radically reduced timescales and superior product performance, they organise Scrum teams, they set up Kanban boards, they adopt a test-fist approach. They sit and wait for the benefits – and they never come.

What is Agile really about?

The problem is that Agile approaches like Scrum, Kanban, XP and the rest have become so ritualised that too many companies focus obsessively on the processes, not the outcomes – the exact same thing the original Agile manifesto sought to escape from.

Rather than promoting innovation, creativity and a mindset that development is all about finding solutions to real-world problems, developers in some firms ‘doing Agile’ complain of feeling suffocated by procedure.

It’s a problem common to any ‘big idea’ – especially in business theory – that gets written down, codified, adapted, repurposed and, yes, commercialised over and over. ‘Doing Agile’ is all too often reduced to following a set of procedural rules to the letter, while the understanding of what makes the concepts work has been lost.

In a way, this is understandable. Agile is more about behavioural theory than process management, something that gets easily lost in translation – probably because behavioural theory is a messy, complex field that people try to avoid engaging with, much like the small print on a finance contract.

But the truth is, if you don’t understand the core principles behind Agile, and therefore why it works, you are probably going to do it wrong – and most likely leave your development teams feeling trapped by meaningless, decontextualised procedures. If you want to do Agile right, you have to go back to basics. Here’s how.

People not process

One of the ‘four pillars’ of Agile set out in the original manifesto was “individuals and interactions over processes and tools.” Or in other words, it was about putting people first.

So in many ways, if you go into Agile focusing mainly on Scrums and Sprints, Kanban boards and feedback loops, you are missing the point. These are all a means to an end, not the main goal of Agile. They should be thought of like any toolkit. Yes, good tools are very useful. But what really matters is what you create with the tools, not the tools themselves.

So if the various versions of Agile methodology that have been developed over the past 20 years are intended to get us somewhere, where exactly are we going? The goal of Agile methodology is to increase the efficiency and quality of production by building it around effective cycles of feedback.

Instead of spending a year developing a product only to be told x, y, and z is wrong with it on release, why not involve the end-user or customer in the testing process and iron out all the glitches as you go?

Get this right, and you end up achieving two remarkable things. You end up making better products, because it is developed with the needs and views of actual users front and centre. And you improve the skills and efficiency of your development teams, because they are constantly learning what actual users want and what really works.

When you understand that, you see that Agile is all about communication and changing the behaviour and culture of development teams by changing the thinking on collaboration and feedback. Whether you opt for Scrum or Kanban or XP or Lean Startup, the process is secondary to the goal – finding out what really works as quickly and efficiently as possible, and using that insight to guide development at every stage.

If all the focus is on sticking religiously to a Sprint cycle or a particular script for Scrum meetings, you actually stop being Agile. Because communication and human interaction are by their very nature dynamic, fluid, variable, intrinsically resistant to formal control. In other words, they’re agile.

So if you want to make Agile methodology work for your business, start by loosening the reins. What matters is what works, and what works for your people – not sticking to a process chapter and verse.