Just the other day I was asked what I think about Agile Methods during a coffee break on our Refactoring / Unit Testing Workshop. My very first reaction was: I think it’s a become money machine.
The reaction was somewhat puzzled. Then I went on to explain that the ideas of getting rid of a lot of bad working practices like planning everything upfront and forcefully sticking to the schedule are of course great. Keeping communication within a team alive, staying in close contact with stakeholders, being able to change directions in very short timeframes and holding the stakeholder responsible for all changes by letting them decide are great ideas.
But no agile method, whatever it may be called or whoever may have come up with it, is going to heal anything if a team follows it relegiously.
The fact that agile has turned into a big merchandising industry, from books, conferences, certifications to buttons, t-shirts and maybe even underwear (you never know…) makes me sceptic. Not that I think it doesn’t work, but I’m afraid it mostly enables quite a few people to sell their consulting time and written material and may be promising enough to make people buy stuff while it doesn’t work good enough for people to adapt it easily and/or succesfully. All of that is not bad per se. I do a bit of consulting and try to think some of the teams I consult profit from it, but I am seldomly selling a ready-made concept or methodology. The art of consulting lies in helping people find their own pace.
This piece of Gerald Weinberg is a great summary of what I mean by all that. If you only have 30 seconds to learn about his conclusions, I’d recommed you this gem:
Those installations and individuals who have successfully realized the promised benefits of agile programming tend to be the ones who don’t buy the typical hardware or software pitch, but who listen to the pitch and extract what they decide they need for solving their problems. They do their own thinking, which includes using the thoughts of others, if they’re applicable. By and large, they were the most successful problem solvers before agile programming, and are now even more successful.
If you even have 6 minutes, read the full article. It’s not new, but it’s excellent, especially his observatiosn and conclusions are worth thinking about.
I agree to almost all of it. I am not sure if and how you could see if a piece of code was written using agile methods, but the numbers he gives are discouraging, because roughly 100% of the code he looked at was not much better than the code written by non-agile teams. So the hope for higher maintainability and quality seems to be unfulfilled.
Does it mean we should condemn agile methods, eXtreme programming and friends altogether? No. I think it means we should use ideas like “Agile” to reflect on what it can do for our specific project or team. There’s a lot of inspiration in what people write about their approaches to overcome certain problems and their experiences with them.
But we always have to choose carefully what we adapt for our teams.
I haven’t yet seen a team that really got anything from reproducing a methodology and making it their new way of life/working. All they are is a bunch of people pretending to be cool and changing the world whilst ignoring they only replace a well-understood problem with a badly understood “solution”.
But when I visit a team that has adapted maybe one or two ideas and made them a well-understood, common-sense part of their daily work, maybe even tried a few more and stopped using them when it turned out they don’t work for them, I often get the impression they’ve made progress in quality and productivity. Funnily, these teams would never present themselves by “We’re agile” while being much more agile in the sense of speed and quality than those who would.
