On the one hand Agile software development has won the war. Agile (and its cousin Lean) are moving into the mainstream and becoming the accepted norm. But I’m detecting signs that things are not quite what they seem. I’ll write more about this in future as I better understand what is happening. For the moment this is how the argument is shaping up so far…
- Agile (and Lean) have become a bit like apple pie: why wouldn’t you be agile? Therefore nobody wants to admit they are not agile and consequently we are all agile.
- A few agile practises like test first development and stand-up meetings are becoming much more common than the others. Based on the adoption of a few practises some people and organizations believe they are agile. (For me the true test of agile is that the team is learning and changing, if you are not holding retrospectives, if you are working the same way you did 6 months ago then you are not agile.)
- Business does not see agile IT the same way software developers do. The idea of “agile” started in a very very small way in the business world. A few people the software community picked up the term, adopted it and grew the idea. Now the term is moving back to the business world and become much bigger. Businesses need to be agile. Making IT agile has become the mantra of management but they are a long way from YAGNI and pair programming.
- Snake oil salesmen have been at work. Agile IT can mean: SOA and server virtualisation. More and more firms are pushing tools to make you agile but true agility comes from people not tools.
Perhaps more worryingly there may be a resurgence in high ceremony development methods in the offing. IT Governance is getting a lot more attention, partly because of things like Sarbanes-Oxley and Basle 2. The problem is that while IT Governance is itself a good thing, and something agile can support and work with, many people – read auditors – equate compliance with procedures and documentation.
Auditors don’t understand IT but they do understand things like written process manuals. The danger is that we re-run the 1990’s and throw away what agile has bought us. It doesn’t have to be this way, agile software development is compatible with regulation.
The real joker in the pack might be ISO 9000. In the 1990’s ISO 9000 was the epitome of high ceremony projects that didn’t achieve anything. Things have changed in the ISO 9000 (specifically ISO 9000:2000) world and it might, could, just be possible, that if we can work out how to get agile teams through ISO 9000 it could provide the insurance people need.
However that is far from certain. The new ISO 9000 could be the same old hammer used in the same old way by people who don’t understand how software development works.
Unfortunately too many people are concerned with the appearance of control rather than actual control. The illusion of control keeps too many managers in their jobs.
(No I don’t have anyone specifically in mind when I say this – I’ve known a whole bunch of these people. Oddly they usually go by the title of project manager.)
Anyway, that’s a quick overview of why I think Agile development as we know it might be about to end.