The funny thing is that most shops are unconsciously flirting with Agile Development. They do a release on a regular basis which is very similar to what Agile teams do without even realizing it and then feel ashamed that they had to do it. Afterwards, they hope they won’t have to do another one. Those feelings of guilt and shame get associated with the need to do the release and it doesn’t occur to anybody that they are missing what is right in front of them. I know that I’ve been looking the evidence right in the face for years and I never saw it.
I am speaking of maintenance releases, patches, and hotfixes. Forget for the moment that these are created out of necessity due to problems with “the big release” and that they are often done under intense pressure. Forget for the moment that sometimes you have to redo a hotfix with another hotfix. The need for the second hotfix is often found by the intense scrutiny that is in place during the aftermath of the first hotfix and due to the fact that the hotfix probably didn’t get the full spin cycle of the normal QA process.
Think for a moment about how you later felt about that maintenance release. Didn’t you think something like “too bad we had to do it, but we really pulled together and I’m really proud of that release?” Wouldn’t you say that the type of release that spends the most time in production is actually a maintenance release or patch release?
A lot of the time, those maintenance releases aren’t just maintenance releases. Usually, there are a smattering of small enhancements thrown in for good measure for a customer or two.
So, let’s review. Your maintenance release has the highest quality, was produced in a short time, and it has a fair amount of new features in it. Guess what? This is very close to what Agile teams do on a regular basis. Surprise! But then of course, you revert back to your old habits.
I believe that the reason that most shops drift towards and then away from Agile development is that it is the natural rhythm of software development and it is hard to resist it. The challenge is to sustain it. In order to sustain it, you need two things: understanding of Agile and conscious intent. Without conscious intent and the synchronizing signal of short iterations it is hard to notice the difference between being on the path and off the path unless you stay on the path for a while. The other problem is that while everybody in an organization might from time to time all be synchronized into an Agile rhythm by pure chance, the synchronizing signal of the project plan, habits, and entrenched process interferes with the natural rhythm. Thus, the natural rhythm doesn’t get a chance to take hold.
Let me leave you with this thought: if your best releases are your maint/patch releases, and they are similar to what Agile teams do on a regular basis, perhaps you should take a closer look at Agile.
[Note: many thanks for Soon Hui’s comments on an earlier version of this post.]