Since I’m personally not able to join the Agile 2008 conference, I was very pleased and thankful for Gojko Adzic‘s regular blog entries on discussed topics he attended to. Today he had an entry on Robert C. Martin about The Fifth Element of the Agile Manifesto, which made me think for a while.

Personally I identified some causes of the effects Robert C. Martin addresses in his talk. Since I read recently Alistair Cockburn’s book Agile Software Development – The Cooporative Game my sights are heavily influenced by it.

Failure Modes

When looking through the remaining human failure modes, I see them addressed in Robert C. Martin’s talk. The remaining three human failure modes might also apply, but I leave the application up to your own thoughts or you might be willing to address them in the comments of this article.

Inventing rather than researching

Rather than reusing the practices from a given methodology it is better to re-invent the wheel new by defining practices from yourself. The problem arises here, that you will come up with ignoring the underlying Agile principles as stated in the Agile manifesto while not understanding them. Considering the Shu-Ha-Ri principle of skill-adaption here, when skipping the Shu stage, you’re not going to reach the Ri stage.

Being inconsistent creatures of habit

First of all does Dr. Cockburn enlist humans being inconsistent creatues of habit as one of the individuals failure modes. Robert C. Martin addresses this with the question for the code coverage of the unit tests at the Agile conference. Even the lack of knowledge on the XP practices in the audience is another sign for this.

Cooperative Game

To quote Alistair Cockburn:

Software development is a (resource-limited) cooporative game of invention and communication. The primary goal of the game is to deliver useful, working software. The secondary goal, the residue of the game, is to set up for the next game. The next game may be to alter or replace the system or to create a neighboring system.

Simply put, I you do not set-up yourself for the next game, you missed the secondary goal of the cooperative game principle. This might be achieved by not coming up with unit tests in the proper depth, this might be caused by relying completely on osmotic communications, thereby ignoring the fact to extend the team – yes, this one I address to myself.

Agile mainstream

Last but not least there is an insight I came up with by myself. The more people are adapting agile processes, the more it is likely that sloppy software developers also get in touch with agile and therefore the agile methods might get bad reputations through the people trying to skip the Shu and Ri level of the agile skill-set. Interstingly I came up with the idea for this cause right before reading Gojko’s Wrap up of the conference, where exactly this is also a part of his critics.

If you still did not yet get the clue, I would propose to read an article in the Better Software Magazine on How to Fail with Agile from Clinton Keith and Mike Cohn. Personally I like the second one the most:

If agile isn’t a silver bullet, blame agile.