Hands-On IT

Agile != Chaotic

This is an old one, but it’s important to me, because the NoConsultant Manifesto is based on its principles. I am writing of course about the Agile Manifesto (you might get an error message from your browser when you go there) and the abuse of the term “agile” in many IT departments.

When it was new and fresh, the Agile Manifesto was (and still is) in stark contrast to conventional development approaches.

Because of its novelty in 2001, it was dismissed by many as being chaotic. The concept, that you could change requirements all through the development process and even after the release of the software was simply not conceivable for many who were used to the old ways.

Maybe you remember the days, when you would collect requirements to at one point call a “feature-freeze”. The minions would then sit down in front of their computers and hack away for 6-12 months. At the end of this period, everyone would put together the pieces and see how it works. And sure enough, it was broken and bent, often not even remotely functional as a whole.

Hurried efforts of bug-fixing would kick in, one emergency-meeting after the next and for another 6-12 months, the developers would be busy to fix and patch until the product was somehow useable.

But no one was really happy. The managers were angry at the developers, the developers frustrated and the users would refuse to use the product, because it was perceived slower, less functional and unproductive than whatever they had before.

The Agile Manifesto changed everything. It introduced a very stringent and formalized process which acknowledged the fact, that everything is in flux all the time. It enabled an iterative approach which allows for quick changes without breaking the whole system.

And, that is very important to recognize, it is by no means chaotic. It produces predictable outcomes and when implemented well, happy customers, users, managers and developers.

So all paradise now? No certainly not. There are issues with this method. You need highly committed teams and equality committed stakeholders. You have to take care of your developers, burn-out is quite common due to the often high pace of the progress. And no system, philosophy or approach can substitute for the quality and knowledge of the people involved.

And don’t forget, agile is not the end-all-be-all. It’s just a tool which can be used well or badly.