Robert C. Martin (aka Uncle Bob) has written a provocative article, What Killed Waterfall Could Kill Agile. Besides its main thrust, it also contains some interesting historical tidbits in the history of the agile movement.

Here’ my 2c. Disclaimer/background: interested in “big” methods in the 90s, XP since 1999, and did the CSM 2 years ago.

The problem isn’t certification per se. The CSM, after all, is just a 2-day training course! It’s hard to argue that education is detrimental. There certainly is a problem with what Bob calls “elitism” or, more accurately, “authority without responsibility”. Perhaps there’s also a problem with how organisations are perceiving the CSM and role of Scrum Master. I haven’t experienced it myself. In my case, I have noted severe scepticism about the usefulness of the CSM. As long as it is merely considered a 2-day training course, then I don’t think it does any harm (it merely does what a 2-day training course can do). No doubt it was marketing genius to make attending a course “qualify” someone for a certificate :). I took the course when I was flush with cash from working in the UK. I attended to show my interest in Scrum and XP to potential employers and teammates. I did also hope to learn something in the course :). I did note that the course was full of project-management types… to the degree that I felt somewhat out of place, so I think I know where Bob is coming from.

Agile has become a meaningless term. Agile is dying. Everyone is doing agile. The “agile” label is slapped on everything. Once slapped on, it tends to provide a force field against criticism. Often this is an attempt to get something for nothing (“but you said it would be faster if we had 100% test coverage”) or just merely popularism. One of the worst things about Agile is the unquestioning, unthinking fanboyism that abounds. Agile has become the status quo.

As a young programmer in the 90s, I was entranced by “object-oriented analysis and design” and the glittering lights of the 3 amigos — their respective methodologies and their (Rational) Unified Process. However, by the late 90s, it was the fight against the bureaucracy that drew me to XP and the little white book. It was the questioning of the status quo of the “big” methodologies. Giving working code the respect it deserves.

What’s not important is that we overemphasise a word, “agile”, that has already become synonymous with software development. What’s important is:

  1. Work as productively and economically as we know how to.

  2. Continuously learn to hone and master our skills. Yes, you will have to learn new programming languages :). I recommend Haskell, OCaml, and Erlang.

  3. As always, keep a sceptical eye out and do not to fall prey to dogma.

Most people fail on that last point. Don’t.