Agile versus Stubborn Methodologies

I was reading the Sept 2006 issue of Dr Dobb’s Journal today, especially interested in seeing what Ivar Jacobson has come up with in his new and improved Essential Unified Process. The article starts out pretty well with an acknowledgment that his “Unified Process has become too heavy”. But two paragraphs later he says his new process “must provide agility with discipline”. That very statement tells me that Jacobson does not get Agile. Agile is the most disciplined software development process I have used to date. (There is enough material out there regarding the disciplines of Agile that I won’t spend the time here discussing it. If you need further details check out Jim Highsmith’s excellent book Agile Project Management.)

So if I believe that Agile is disciplined, more disciplined than the heavyweight processes like the Unified Process, what word would I use to describe these heavyweight waterfall processes? The word I came up with is stubborn. Here’s why:

• Waterfall has the project’s requirements defined up front. A request to change a requirement during the development phase can be an arduous and slow process of change requests and approvals. Heavyweight processes do not promote change but are designed to stubbornly resist it.

• Waterfall projects have delivery dates set up early on in the development process, often by people too far removed from the actual software development and without the scope of the project well defined. Then the project is stubbornly managed against those early and ignorantly derived dates, even when scope increases.

• Waterfall projects often spend a significant amount of time in ‘Big Upfront Design’. Then this design is stubbornly enforced by the architecture police, even if it is proven to not add any business value and causes delays in delivery.

Discipline means you do what you say you are going to do. On many of the waterfall projects that I have experienced in my IT career, the early rigor (stubbornness) applied to the development process got abandoned when it was realized that the project was in trouble. Specs were left incomplete; testing time was traded for more development time; quality was sacrificed to meet the schedule. I have seen waterfall projects too often end up in this undisciplined state. Is more stubbornness to adhering to the waterfall process the answer? I don’t think so because this stubbornness is a big reason that waterfall projects get into trouble in the first place.

I have found the adaptability of Agile and the disciplines of XP (test driven design, continuous integration, relentless refactoring, early and often delivery of working code) to be a much more satisfying solution for effective software development. And so have my customers.