Did you know that the birth of the waterfall software development methodology is a thing of irony? I was working on a presentation on agile software development when I looked deeper into the history of the waterfall methodology. Dr. Winston Royce first developed the waterfall methodology in 1970 in a paper entitled “Managing the Development of Large Software Systems“. In his paper he first introduces the waterfall approach and then states that it is ”...risky and invites failure“. Royce then proceeded to propose an iterative model as an improvement on his initial waterfall suggestions. Ironically, despite Royce’s own criticisms of a waterfall approach, the industry chose to adopt waterfall, and ignore his superior iterative methodology. You can read more details here.
I was recently in a meeting to discuss and help refine my company’s solutions approach when I mentioned the importance of having a “zero feature release” (ZFR). Some people in the meeting were not familiar with the meaning of a ZFR. I went on to explain that a ZFR is essentially the release of the project’s first iteration that includes all components of the project’s architecture and infrastructure (or as many as possible), but “no features”. Why is this so important? Because highlighting and addressing architectural issues early, is significantly easier than addressing them during later release stages. Leaving core architectural pieces to later release stages can dramatically increase project risk in terms of time, quality, and costs.
A couple of quotes from Kent Beck’s book Extreme Programming Explained highlight the focus of the first iteration:
…the first iteration must be a functioning skeleton of the system as a whole… For the first iteration, pick a set of simple, basic stories that you expect will force you to create the whole architecture. Then narrow your horizon and implement the stories in the simplest way that can possibly work. At the end of this exercise you will have your architecture.
(Beck 113)
The first iteration puts the architecture in place. Pick stories for the first iteration that will force you to create ‘the whole system,’ even if it is in skeletal form.
(Beck 134)
Deployment and configuration issues (like architectural issues) must also be identified as early as possible. Too often, deployment and configuration issues arise later in the project lifecycle creating project delays, increasing costs, and risking the quality of the deliverable. Therefore, in addition to an architectural focus, a zero feature release must also be focused on validating the deployment and configuration of the system.
