When seeking buy-in for adopting Agile software development as a standard, offering alternatives can be useful. Agile alternatives allow enterprises to sample some of the benefits of Agile without making a sometimes drastic transition. They can also help enterprises smooth out bumps in the transition process. The Spiral model (aka spiral lifecycle model) is one such alternative. The model is worth researching in its entirety, but here I will consider only some minified variations with which I have had some personal success.
When Agile Software Development Is Too Much
The software development culture is very success focused. IT organizations could acknowledge over and over again that Waterfall projects had a high rate of failure, yet their pointy-haired bosses would not change how projects were run. But when the IT media tells us that Agile projects are succeeding, those same bosses start putting out job reqs for Scrum masters (ignoring the people on their staff who have been suggesting these approaches for the past few years). Other than the parenthetical note of bad behavior, adopting a best practice is actually a good pattern. However, the same thought process that overlooked local talent can lead to overkill when adopting Agile, call it "solving world hunger with a hammer." Your mother really was right when she told you that too much of a good thing usually isn't.
Even if moving to an Agile approach won't fix the coffee maker or significantly reduce your 60-hour work week, it does indeed have some very valuable charms. The Manifesto for Agile Software Development tells us (in my opinion) that Agile values the needs of the user and working software over following process and meeting the minimum interpretation of the Statement of Work ("SOW"). The Principles behind the Agile Manifesto include (quite reasonably) "Business people and developers must work together daily throughout the project." In my experience, this is one of the major stumbling blocks to fully benefitting from Agile, because many enterprises approach this principal with a modifier of "or their proxies" and consider that good enough. Sometimes it is, but for those times when it isn't, we either need an alternative or just go back to hiding behind a Waterfall.
Using the Spiral Model to Gain Control
No matter what SDLC an enterprise adopts (or dictates, as the case may be), it is extremely rare that some level of iteration is not included. I would even go so far to say that a software project with no iterations is either simply not reporting them or has already failed (leaving out the obvious exception when everything goes perfectly the first time every time through the entire project... soon to be in seen in 3D at a theatre near you).
In psychology there is the TOTE concept (Test Operate Test Exit) where the iterations exit when all tests have passed. Behaviorally the process breaks down when the same operation is run after a test fails, ensuring the same failure. In software projects, the breakdown more often occurs when the test stage of an iteration is inadequate, leading to an early exit or an inability to know when to exit. The early exits are generally caught and corrected during user acceptance testing. It is the inability to exit that can hurt a project. While the daily communication processes inherent in Agile methodologies will provide the necessary direction to find the exit, enterprises in the early stages of Agile maturity may still be struggling to stick to the process -- especially when it comes to the daily participation of business clients.
Obviously project teams don't knowingly start out on a path leading to nowhere, but it does happen. So what to do at that point? There are two philosophies about what to do in the absence of direction: do something or do nothing. Doing nothing is a good way to deflect blame when time or budget runs out (and this includes repeatedly asking for direction, a behavioral breakdown as noted earlier). It is also a natural response to a lack of direction. From either viewpoint, it is a common outcome from a break down in communications and a very non-Agile result.
The Spiral model points to the other option, which is do something. Then you take the result of that action and show it to business stakeholders and ask "what do you think?" The assumption here is that those who have trouble conceptually describing what they want (or others who have trouble eliciting what people want) will be better at evaluating something that already exists.
The Spiral Model as a Bridge to Agile Development
Enterprises that are unfamiliar with Agile methodologies but could benefit from adopting them may find Spiral to be a suitable transition model. In the Waterfall approach, a language issue can lead to a breakdown in direction or definition. The requirements will be stamped "complete" but will be too high level to implement. Business stakeholders don't know SOAP from JNDI and don't really need to. Yet they will fail to articulate any level of detail for fear of giving the wrong message (either of intended direction or defensible ignorance). Adopting a Spiral approach at that stage of an in-flight project can introduce the organization to an iterative approach. Once presented with an accomplished deliverable that everyone can point at, business stakeholders can more easily respond to parts of the deliverable with "more of this" and "less of that." Communication reopens, progress continues, and the value of being iterative is clearly demonstrated.