The Agile Anthem

Imagine no deadlines 
I wonder if you can 
No need for plans or schedules 
A brotherhood of man 
Imagine all the people 
Sharing all the pain 

You may say I’m a dreamer 
But I’m not the only one 
I hope someday you’ll join us 
And the world will code as one

- The Agile Anthem, not by John Lennon

The Twelve Commandments of Agile – Conclusion

The Agile Manifesto says:

We are uncovering better ways of developing software by doing it and helping others do it.

Thank you very much. Much obliged.

While their intentions are good, Agile Methodists’ methods simply do not sound appropriate to enterprise-class software development. 

The Agile Methodists are living in a world much simpler than the one I inhabit and from where I stand their methods seem corny to say the least:

The Twelve Commandments of Agile – Commandment XII

Here is the Twelfth Commandment:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

- The Twelve Principles of Agile, The Agile Manifesto

Really? Are you quite sure? Oh my! What can I say!

Team reflecting on how to become more effective

Get real guys!

This is not really a commandment but an ideal. This is the kind of thing that makes Agile less a methodology and more a religion.

The Twelve Commandments of Agile – Commandment XI

Here is the Eleventh Commandment:

The best architectures, requirements, and designs emerge from self-organizing teams.

- The Twelve Principles of Agile Software, The Agile Manifesto

This begs the question what is a self-organizing team? In the absence of a definition of this term I went Googling for a definition:

The Twelve Commandments of Agile – Commandment X

Here is the Tenth Commandment:

 Simplicity–the art of maximizing the amount of work not done–is essential.

- The Twelve Principles of Agile Software, The Agile Manifesto

This is yet another motherhood statement in the same league as “you should have a motivated team” (Commandment V) and “you should create a good design” (Commandment IX). No arguing with this one in principle.

In practice, in the context of enterprise-class software development, this focus on simplicity does create special problems when building software on an enterprise scale.

Consider an insurance policy admin system that one of my teams is building right now:

The Twelve Commandments of Agile – Commandment IX

Here is the Ninth Commandment:

Continuous attention to technical excellence and good design enhances agility.

- Twelve Principles of Agile Software, The Agile Manifesto

Oh well, continuous attention to technical excellent and good design is certainly desierable and nobody can deny that. And it will enhance not only agility but all of the following ilities listed on Wikipedia:

Feasibility of Frequent Releases of “Valuable” Software

This blog post from Borland provides a good example of releasing software frequently to customers.

As Borland develops new features of their products, they permit customers to pick up sprint builds with a caveat:

The Twelve Commandments of Agile – Commandment VIII

Here is the Eighth Commandment:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

- The Twelve Principles of Agile Software, The Agile Manifesto

The term Agile processes is not defined anywhere except in terms of the preceding commandments. Hence, I will have to substitute the term Agile processes with all the preceding commandments to make sense of this commandment:

If you make early and continuous delivery of valuable software, if you welcome changing requirements even late in the development, if you deliver working software every couple of weeks, if business people and developers work together daily, if you build projects around motivated individuals and give them the environment and support they need, if your development team maintains face-to-face conversation, and if you consider working software as the primary measure of progress  then you promote sustainable development…

The logic is not apparent to me.

Real Agilists Don’t Eat Quiche!

Finally I got it!.

Agile Methodists are exactly the same as the Real Programmers who don’t eat Quiche!

Only now, they are older and they talk methodology instead of code.

Somebody should write up “Real Agile Methodists Don’t Eat Quiche”

Real Programmers don’t believe in schedules.
Planners make up schedules.
Managers “firm up” schedules.
Frightened coders strive to meet schedules.
Real Programmers ignore schedules.

- “Real Programmers Don’t Eat Quiche”, Ancient Internet lore

Then again, maybe it does not require too much rewriting!

The Twelve Commandments of Agile – Commandment VII

Here is the Seventh Commandment:

Working software is the primary measure of progress.

- The Twelve Principles of Agile Software, The Agile Manifesto

Now we are getting into the topic of project management (and high time we did).

Project managements is a discipline in it’s own right and is not restricted to software projects. Projects are defined and managed all around us, in every field of endeavour. Projects come in all hues, shapes and sizes. From setting up of nuclear power plants, to building of bridges and dams, to sending out lunar probes, to setting up and running a new cricket league – the examples are simply too numerous to quote.

Project management is a very evolved discipline. The Project Management Institute has published a whole body of knowledge (PMBOK) on this discipline and it also certified practitioners.

For some peculiar reason, the software profession in the west has not, so far, attracted the better project managers. Most software professional who morphed into project managers have done a pretty bad job of project management. In India, the story has been quite different. Over the last ten years, the Indian software industry has produced a large number of very competent software project managers with a high rate of project success under their belts.

Hence, sitting here in India, this commandment seems rather strange and trivial to me.

How would I measure the progress of a requirement elicitation process on one of the projects in my portfolio? I ask my project managers to give me a report such the one below: