Happy 10th birthday Agile

Today marks the 10th anniversary of the creation of the Agile Manifesto. At the heart of Agile are four values:

“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.”

To me it seemed like common sense, and in fact I’d been working in this way for some time before Agile had a name. It’s always felt like the right way to develop software – working together, with the customer, to deliver what they want rather than the adversarial way I’ve seen Waterfall projects run (and fail).

The first few projects I worked on (as a developer then as a team leader) left me with an uneasiness because we were working from documents written months before we needed them, where someone tried to be very specific about what the software should do. By the time we came to refer to them, they were out of date (requirements and/or technology had changed) but we were told to stick to the document, ploughing ahead with writing code we knew wasn’t right. Then, at the end of the project, we presented the customer with something they no longer wanted and this led to the finger pointing and contract analysing part. The customer had to accept we had delivered what was originally stated and then pay for additional change requests. That never felt right but I was too far down the food chain to be able to change it.

That was until I joined Systematic, a Danish software company which was starting to grow its UK development team. As my team started to grow we naturally fell into a way of working which included much closer interaction with the customers, showing them prototypes and getting frequent feedback so that we (jointly) were making small changes in the project’s direction, adapting to changes in requirements and technology. We were a small team so we knew what we were all working on, and we broke the projects into small (month long) chunks. That was back in the mid-1990s, before Agile had been formalised, but our organically evolved practices had many of the same elements … and yet we were still ISO 9001 and AQAP 110 approved.

I’ve seen organisations embrace Agile wholeheartedly and I’ve seen some struggle and ultimately even back away from it, but I can say without any doubt that the most fun, productive and healthy projects I’ve worked on have been those which have adopted at least some elements of Agile. They’ve also been the most challenging, but that’s what I expect because they’ve pushed boundaries (e.g. cutting-edge technology) and demanded that the teams perform at their peak. It’s tough but it’s rewarding, both for the dev team and for the customer.

I agree with Mike Cohn – “In another ten years I hope I am asked to reflect on what will then be twenty years since the Agile Manifesto. […] And when I do reflect back on agile software development ten years from now I hope we’ve stopped calling it agile. I hope we’ve stopped calling it anything at all and are just doing it.”