Agile Agile

No doubt Agile is interesting.

One of the most beautiful arguments Agile makes is that creating a grand plan upfront is not the best thing to do, because such a plan would invariably be based on a limited knowledge of what you're going to be building. That is true - as you progress on the work, you get to know more of it, and there's no point in sticking to a plan that you made when you were in ignorance of this new knowledge.

Now, let's apply the same thing to Agile itself.

Let me explain. Look at the whole thing at one level above all this. You've got a set of people who want to build something. Now you need a process that orchestrates these folks and gets the work done. Is it fair to pick a process out of the blue and apply it to the system and stick to it? You picked the process when you had limited knowledge on how it would behave. As you worked your way forward, you know more about the system, and naturally, it makes no sense to stick to that old process that you picked upfront when you were in ignorance of all this new knowledge of the system.

So, it's OK to begin by saying that let's have two-week iterations, a stakeholder demonstration at the end of the iteration, a retrospective meeting, daily scrums, planning poker, story points, incremental builds, unit tests and all this.

But then, you must *consciously* modify the process, based on your experiences of how it's going. Process changes must not come out of frustration, angry stakeholders, and sev-1 issues. It must be in the form of a proactive meta-process that continuously modifies the process to suit changing circumstances.

If someone says that "here is a standard Agile practice, follow it" - treat him with suspicion. There is really no standard. Agile is for self-motivated, self-organizing, self-improving people. It is not for those lambs that want to be told what to do. Any team that works on a set of imposed standards is a set of lambs - expect nothing heroic from it.