A lot has been written about Agile – my favorite has to be that it should be written F......Agile.
Seriously though, I think that a lot of the writers miss the point. Agile is a wonderful theory, but that is where all too often it only works, in theory (caveat here: I’m basing much of this on the SCRUM method of Agile project management). As an economist (yes, my career doing that was about as short as my career as an environmentalist) I can tell you that any theory (economists love theories) relies on a lot of assumptions. Some assumptions are valid most of the time; most aren’t (all of the time). As someone who is focused on ensuring that the end client gets what they are looking for at the end of the day, the biggest assumption that underlies the Agile approach – and that is its inherent flaw - is that a client will be happy with an open-ended approach to both duration and cost with no guarantee (or idea) of what they will end up with.
There are of course plenty of customers out there who want things quicker (which is of course how Agile is sold) and there aren’t many people in technology (or any industry) who aren’t keen to try something new (buzz words are of course required, and therefore supplied). The trouble is that when the client gets into the detail and finds out what it actually means the project quickly becomes something quite different, but without any of the up-front structure or process. The result is usually a few key individuals “dying” in the process of trying to get the project out the other side, whilst on-lookers (usually the sales people but sometimes even including some of those on the team, but not those dying) congratulate themselves on a great new methodology.
The disturbing part of this is that it is amazing how frequently I come across people who are fixated on Agile (and only Agile) – whether it is recent graduates (heaven help them or their first client – someone won’t be happy at the end) or seasoned IT professionals (who really should know better).
Like any management “breakthrough”, an Agile approach has its merits and some of its guidelines just make common sense and I would argue are applied by an half-way decent project manager whether it is part of the methodology that they are following or not (I have to ask, in what project management methodology would you not say, for example “Face-to-face conversation is the best form of communication”! – and you can supplement pretty much all of the Agile precepts here).
