views:

9319

answers:

5

I believe that Agile is nothing but another implementation of Spiral Model. I am a big supporter of Spiral (The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts) since its beginnings and have seen that lot of projects implement Spiral without knowing that they are operating in a Spiral world. Since the day Agile started gaining popularity the concept of spiral started getting overlooked a little bit. I am sure that for complex projects spiral is still the best alternative but I would like to get a better understanding of the similarities and differences between Agile and Spiral techniques. Can anyone explain their differences/similarities?

+5  A: 

Agile is spiral. Totally. In part, the name was changed for marketing purposes.

The problem is that spiral tends to imply "big design up front" -- where you plan out many spirals, each in order of risk. Spiral, however, isn't Agile -- it's just incremental execution in order of risk.

One big distinction that Agile adds is the "don't overplan things you can't know yet." Agile is spiral, but you create detailed plans for just one increment at a time.

Agile adds a lot of other things, also. Spiral is a very technical approach. Agile, however, recognizes that technology is built by people. The Agile Manifesto has four principles that are above and beyond the Boehm's simple risk management approach.

S.Lott
I think I am following you. Thanks for sharing the knnowledge
Chanakya
I don't think that Agile == spiral. Agile is a subset of the spiral model that uses very tight spirals - a spiral (a sprint in Scrum, sometimes called an iteration) would be 2 weeks. In a generic spiral model, you can have spirals that last months or even years (the length wasn't specified by Barry Bohem) while the Agile methodologies recommend short spirals.
Thomas Owens
@Thomas Owens: I don't get your comment. If Agile is a spiral with short spirals, then it's spiral, right?
S.Lott
I was pointed out a problem where you said "totally". Agile has more restrictions on it than spiral does. It's a square/rectangle relationship - yes, agile is a spiral, but spiral isn't agile and it's separated by more than just "incremental execution in order of risk". Agile accounts for shorter schedules and more frequent releases, among other things. Your first two paragraphs are a little vague, IMO. But it might just be the way I'm reading it.
Thomas Owens
@Thomas Owens: "yes, agile is a spiral". I think that's what I said. "Spiral, however, isn't Agile". I think I said that, too. I'm really having trouble understanding what hair you're splitting.
S.Lott
A: 

First Agile is actually a number of different processes that follow a similar philosophy. One of the philosophy's that makes it different is that each iteration produces a working product. It could be described as iterative and incremental. A lot of emphasis is placed on the working product and on testing. In many agile models testing comes before coding.

In the spiral model the number of iterations are fixed, while each phase of an agile model may consist of any number of iterations.

You are right that there are similarities but the underlying philosophy makes the difference. This page explains in more detail and compares agile to other methods.

You can say that agile processes are Use Case driven...placing a lot of emphasis on people, the end user.

Vincent Ramdhanie
+3  A: 

The basic difference, as I see it, is that most Spiral models of development still insist on big, up-front design. The emphasis is on knowing as much as you can about how the system will be used; discovering all the use cases. Once you know these, then you design the system and break it down into phases that follow an iterative detail-design, implementation, test, refactor-design loop. In Agile, their is some up-front planning -- perhaps gathering large grain understanding (story titles) -- so that reasonable releases can be described, but each release is planned independently and we delay discovery of the details until we are ready to begin implementation of that release. We expect change and don't try to know everything first.

Another thing that differs is that most Agile philosophies involve "test-first" methods. This is different from spiral where testing is often an activity unto itself and tests are not developed prior to code. Most often they are planned in advance, but developed in parallel or after coding. Many agile methods insist on developing tests first as the specification for the code.

They are similar in that they are iterative. They differ in the implementation and understanding of what an iteration is.

tvanfosson
A: 

I'm not an expert for the Spiral Model, but from the wikipedia-definition, it seems to me that there are some significant differences.

For example, in an Agile project, at the end of an iteration doesn't stand a prototype, but a fully functional, fully tested, potentially deployable (1) system, containing the highest priority features on the feature list.

The requirements gathering at the start of the project is meant to be just barely enough to get going (to take the next step) and are meant the be fleshed out just shortly before they get actually implemented. Changes are to the requirements are welcomed.

Also, there is much more to Agile than just doing iterative development - a focus on faces to face conversation instead of written communication, a focus on bringing business people and technical together in their day-to-day work. A focus in collaboratively maximizing value instead of defining and then fulfilling a contract.

In case you didn't see it yet, take a look at the Agile Manifesto, which basically is the definition for Agile Software Development.

(1) That doesn't mean that it has to make business sense to deploy the system, "just" that it is technically feasible. It should be a pure business decision whether to deploy the system at the end of an iteration.

Ilja Preuß
Thanks for sharing the knowledge. I think for the larger projects it is hard to produce something 100% deployable at the end of the iteration, taking into consideration the dependability of certain entities in complex application.
Chanakya
Not true.. I'd say maybe not enough time has spent to eek out smaller blocks that would be actually usable and deliver business value. You don't need to build a monolithic mammoth to get the feedback loop going.
Gishu
Welcome to SO Ilja ;) I spent some time at Ron's agile forums..
Gishu
@Gishu thanks for the welcome! :)@Chanakya it is common Agile practice to not allow the implementation of a feature to span several iterations - if it would, it needs to be broken down. I haven't yet encountered a case where that's not possible, and can't imagine one. And DONE means deployable.
Ilja Preuß
A: 

I'd say spiral and agile are similar. However, lately agile has often seemingly become a propaganda system to excuse cowboy coding. I.e.

  • Extremely minimal requirements
  • Minimal technical analysis
  • Minimal documentation
  • No code comments
  • Special Bonus-- misuse of Domain Driven Design to over-complicate the object model

This was never the idea with spiral. I would argue that it's not really the point of Agile either, although you'd be surprised how many times I've seen this recently. More and more experienced developers/PMs are beginning to see the wisdom of a more balanced approach between waterfall and "agile" -- perhaps this simply brings us back to spiral.

Although there are some useful ideas in the Agile mind-space, it often seems as though it manifested from people who were in organizations that had particularly over-burdensome/unhelpful software design methodologies, and was a reaction/over-reaction to that.

alchemical