Being a developer for a government contract, I'm pretty much tied to a waterfall process. We can call them 'spirals' or 'iterations' or any name we choose, but at the end of our day, requirements, design, code, test is what the government likes to see.
For my debut set of posts, I'd like to start a discussion of how to minimize the negative effects of waterfall development, by borrowing smartly from the agile world. As many have noted before, partly doing agile can cause more difficulties than it solves, so the steps and missteps that we've taken are important learning tools in the path to better waterfall development.
While I'd like to become more agile, the truth is the days in which the government would have accepted that approach easily are gone. Years of bad development practices and late software have moved the government to be more fixed in the waterfall approach, and since they hold the checkbook, we are forced to move along a pretty constrained path.
I hope that my counterparts in the commercial world, who have been free to adopt agile methods wholesale will appreciate a look into the 'dark side' of development.
In a couple of days (sick child at home), I will be discussing "Making the most of traditional peer reviews".