Message From The Godfather

Three major points became clear as I read about the spiral model today and this weekend:

1) This model, though related to agile programming, requires greater patience. With cycles lasting six months to a year, rather than weeks or months as in the agile model, those looking for a quick win ought to look elsewhere.

2) This model is geared towards projects that the end users plan on using, with or without modification, for years to come, rather than using it until an alternative comes along, unless that alternative represents a paradigm shift in how the project might be used.

3) Again, as with the agile model, adequate communication is key in making this model work. Without adequate communication, in fact, there is a greater risk of failure at greater cost than with the agile model, because of the time involved in moving from cycle to cycle.

The key component of the spiral model – risk identification – is an exciting feature. Quite often, I note, and I see this in myself and with a lot of people I know, when we’ve got a project, the tendency is to jump in and start working/writing/developing, without really looking at what weaknesses or risks are involved with the approach we’re taking, or what risks may be encountered with any approach. The first iteration of Uncharted.net, for example, was accomplished without properly assessing the risks, the primary risk being that as the site grew, a severe bottleneck would develop when it comes to putting new content up on the site. The goal, obviously, was to present site content in a way that is pleasing to the eye and consistent with company style. An unassessed risk, however, was the WYSWYG editor used for posting content – Number one, you folks in this class already know how I feel about WYSIWYG. Number two, the editor had NO ability to incorporate photos – it was simply a text editor. To incorporate photos into the text, a photo editor had to go in and manually tinker with the site to make it work. That led to a lot of delay, some of which we still haven’t caught up with.

What worries me is that the second iteration of Uncharted, which has adequately addressed this risk, did not include additional risk analysis. Obviously, I’m taking this class a year too late. But we do have one saving grace – a month when we’ll be allowed to tinker with the site and try to make it break in as many ways as possible. I’ll try my best.

It all comes down to communication – there’s a wall there, as Kronk might say. Our design team has worked solely on design and user interface, only occasionally asking the rest of the team for input – and the input has come in the form of having us look at screen shots, which tells us some about design, but little about functionality. So I’m nervous.

So this takes me to what Barry Boehm (who must be the godfather of spiral, as his name shows up everywhere) et al say in “Using the WinWin Spiral Model: A Case Study,” which appeared somewhere; I’ve lost the URL. (UPDATE: Martin found the link for me. Thanks.) Anyway, the article says: “The most important outcome of product definition is not a rigorous specification, but a team of stakeholders with enough trust and shared vision to adapt effectively to unexpected changes.” He outlines how a group of students worked with the USC library on a website that brought some of the library’s collections to the Internet. Initially, there was a lack of trust, but as the teams worked together over a few months, they saw an increase in trust, which came with increased communication. This time to get to know each other and to build that trust is a distinct advantage of the spiral model, as there is time built into the cycles (at least as Boehm outlines them; I realize there are others who use the spiral model as an extreme programming tool, making some cycles last a day) to allow that trust to build.

Another item I like in Boehm’s approach to the model is the admonition not to conclude negotiation – which involves that building of trust and assessment of risk – without coming in with a prototype. He says it best: “Don’t finish negotiations before prototyping. If you do, the agreements destabilize once the clients see the prototypes.” He advocates combining the negotiating and prototyping segments, so clients can visualize how their negotiated points may be integrated into the final product. Again, it comes to communication, rather than coding or documentation, as being the key to making use of any model succeed.