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.
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.
