Unfortunately the industry has latched on to the word “Agile” and has begun to use it as a prefix that means “good”. This is very unfortunate, and discerning software professionals should be very wary of any new concept that bears the “agile” prefix. The concept has been taken meta, but there is no experimental evidence that demonstrates that “agile”, by itself, is good.
The danger is clear. The word “agile” will become meaningless. It will be hijacked by loads of marketers and consultants to mean whatever they want it to mean. It will be used in company names, and product names, and project names, and any other name in order to lend credibility to that name. In the end it will mean as much as Structured, Modular, or Object.
The Agile Alliance worked very hard to create a manifesto that would have meaning. If you want to know their definition of the word “agile” then read the manifesto at www.agilemanifesto.org. Read about the Agile Alliance at www.agilealliance.org. And use a very skeptical eye when you see the word “agile” used.
– Bob Martin, circa 2003
Bob Martin’s advice from 2003 seems just as applicable today. Which, perhaps, explains my reluctance and concern about companies “going agile”, “doing agile”, “adopting agile”, and so on.
As I re-read the Agile Manifesto, it seems to me that it’s largely about what attitudes are more effective in developing software. Not process – attitude.
So let’s play a game and go back in time, close to a decade ago. I’m sitting in a meeting, hearing about how are going to develop the last great, grandiose, development framework that will be extensible, then after completing the framework, developing the code will be easy. And I’m not buying it.
“Have you guys ever noticed that every time we do this, our crystal ball is wrong? We have unlimited extensibility left and right but the customer always – always – wants us to extend up and down. Let’s work on malleable software, software we can change if the requirements do – and deliver something right now. This week. This month. Then, if we get asked for something similar a second time – then and only then – do we generalize.”
Of course, I “didn’t get it”, had more to learn, let’s pat Matt on the head and move on. (Don’t worry. It turned out ok in the end. Really.)
That’s agile. I don’t think you “do” that. I believe it’s something you are.
So the heart of changing to agile is not process (yes, breaking functional teams into project teams can be hard, that’s a sidebar) – but a change in understanding.
It’s not as easy as hiring a scrum master – because the idea of hiring a guru who will tell us all how to do it is still command and control.
Still more to come.