Software management: Waterfall, Agile, and Kuhn

In 1962 Thomas Kuhn wrote his renowned book 'The Structure of Scientific Revolutions' which among other things introduced us to the "paradigm shift", a hackneyed phrase much beloved by dull managements these days, but a significant new theme at the time. 

Also in the book was the concept that the adherents of the old way of looking at the world, the old paradigm, could not, with their previous training and experience, understand the new way of looking at the world. This inability to comprehend he termed as incommensurable, a clumsy word hardly surprising it lost out to paradigm. One of the books findings was that the adherents of the old paradigm are not so much converted to the new, but rather they are submerged by it. They and their views die out.

So what has this to do with software management? A great deal is the answer. Currently we have a major debate within the software project world about whether we should use waterfall or agile planning and development methods. Much ink has been spilt, and many strong positions taken. Definitely there is a great deal of incommensurabling going on and the triumph of one over the other is not on the horizon, far from it.

The problem for we project managers is that we are often called upon to bridge the gap. To be translators at best, peace makers at worst, between the disputing theologians. In addition we also have to communicate our schedules to senior managers who are steeped in the point value world. "Give me a date when this will finish and the next phase will start" is their usual response to scheduling questions. Iterative development with its vagaries and imprecision is a foreign land to them. Oh, they get the concepts of the method but they can't break free of the point value mind set.

I had an example recently on a database project I'm managing. We are using an iterative approach with scheduled releases of the database. The later releases will be more a case of fine tuning the model rather than major upgrades. The development, testing, and deployment will continue until the main program is completed. The applications that will use the database understand the approach and when they'll be able to use the new code for their development effort.

So far so good, the techies understand what's going on. Now we come to the incommensurable part, the executives managing the entire program. They want everything on one chart -as an aside I think PowerPoint has a lot to answer for in the ongoing process of dumbing down corporate executives - everything has to have discrete start and end dates that line up with dependent activities, they want waterfall.  After days of futile discussion, basically talking past each other, I gave them a waterfall version. As they say in the espionage world it was a convenient fiction, all that was missing was the traditional starting and finishing phrases of children's fairy tales. Whether they'll all live happily ever after is debatable, it is a software project after all.

The political learning point of this example is that you need to understand the requirements of all of your audiences and accommodate them as well as you can. Leave them comfortable with their illusions while you manage your project in the most effective manner: Duplicitous yes, politic absolutely!