The Spiral Model as an Agile Alternative : Page 2

Adopting the software development methodology that best fits your organization is key. In scenarios where Agile isn't the answer, the Spiral Model may be.

by Scott Nelson

Aug 29, 2011

Page 2 of 2

Pros and Cons of the Spiral Model

Let's look at another scenario where Spiral can be a viable option. Oftentimes, funding, completion dates and personnel for projects are decided and committed before requirements have been captured, and then the requirements fall behind schedule. While scope reduction is the standard response, it is difficult to know what can be dropped out of scope when the more concrete scope definitions are missing. The Spiral model can be adapted to produce prototypes based on high-level requirements, with the output being used as a streamlined requirements-gathering tool ("should it look like this?").

On the down-side, this is not a cost-efficient model for the most part. This is especially true when compared with Agile. Both models are best suited at small, distinct deliverables. But models are representations of what should be or could be, and if the reality doesn't resemble the model then something has to change or all that is left is a pretty model of what might have been.

The upside to the Spiral model (and various adaptations of it) is that it always results in something that works. This is definitely a boon in those scenarios where the alternative was to do nothing. If the budget is being burned and nothing is being produced, anything that is delivered becomes an increase in value.

Using a Spiral approach can also get the necessary but missing business participation to make Agile work where it isn't yet. The response will not always be positive but you will have delivered something and will have received a response. If you take that response as a clarification of requirements rather than a legitimate critique, the project will move forward, value will be realized and time that may not have been optimized will not have been wasted.

Conclusion

I'd like to conclude this with some pre-history (thanks to George Lucas for making that a well-known pattern). I started using large sticky notes to record and track software requirements and having daily reviews of status with business users before I heard the terms "story card" and "daily stand up." I was placed in charge of Agile adoption at one company because management had observed my project leadership approach and simply assumed that Agile was what I was doing. I became a major fan of Agile once I started to learn about it more formally.

Likewise, I was in the midst of a project where the team members had been churning out useful functionality and receiving praise from the client sponsor when I searched for an Agile term that I couldn't recall and ran across a Wikipedia article on the Spiral model. My issues with remembering terminology persisted and I ran across a list of software development philosophies, which reminded me that there are more than three (or even two dozen) ways to skin the SDLC cat.

The key to success in software design, development and delivery is not in rigidly following any particular documented approach, it is in adopting the approach that best fits your organization, adapting it to what is most suitable for the people within that organization, and communicating what works in a manner that is clear, concise and repeatable. Most importantly, it is equally acceptable if the result is identical to something that already exists or is so unique that it won't work anywhere else... so long as it does work.