We've adopted Scrum for all of our software development at Vertigo. Although I'm totally in favor of Anything But Waterfall, Scrum is an unfortunate name:

1. It's two additional characters away from a term for male genitalia.
2. The term is derived from rugby, an extraordinarily violent sport. During my first year at college, a guy on our hall participated in Rugby. His ongoing injuries, both small and large, became a running joke in the dorm. Eventually even he started to re-evaluate the merits of the sport. As Steve pointed out, Wikipedia defines scrum as ".. the most dangerous phase in rugby, since a collapse or inproper engage can lead to a front row player damaging or even breaking his neck." My indirect experience with rugby leads me to agree. The most dangerous phase of a violent sport is not exactly the sort of thing you want to add to your project.
3. When you tell customers your software developers use the Scrum process, they have absolutely no idea what you're talking about.

We usually say "agile" to avoid all the weird connotations of the word Scrum.

To promote understanding of Scrum, and Agile software development in general, everyone at Vertigo got a copy of Mary and Tom Poppendieck's book, Lean Software Development: An Agile Toolkit. I was inclined to like the book, because I'm a big fan of Mary Poppendieck's article Team Compensation (pdf).*

Although the book is great, the Poppendiecks spend a lot of their time drawing parallels between software development and manufacturing. Every few pages, you'll find some example from a classic manufacturing company: Ford, L.L. Bean, GM, Dell, Toyota, etcetera. Although the examples do extend beyond the manufacturing sector, they're definitely dominated by it.

Perhaps this makes sense if you consider that Scrum originated in manufacturing:

Scrum was named as a project management style in auto and consumer product manufacturing companies by Takeuchi and Nonaka in "The New New Product Development Game" (Harvard Business Review, Jan-Feb 1986). Jeff Sutherland, John Scumniotales, and Jeff McKenna documented, conceived and implemented Scrum as it is described below at Easel Corporation in 1993, incorporating team managment styles noted by Takeuchi and Nonaka. In 1995, Ken Schwaber formalized the definition of Scrum and helped deploy it worldwide in software development.

The manufacturing examples presented in the book don't resonate with me at all. I'm not convinced that manufacturing industries and software development have much, if anything, in common. Fortunately, the Poppendiecks address this criticism early in the book:

The origins of lean thinking lie in production, but lean principles are broadly applicable to other disciplines. However, lean production practices -- specific guidelines on what to do -- cannot be transplanted directly from a manufacturing plant to software development. Many attempts to apply lean production practices to software development have been unsuccessful because generating good software is not a production process; it is a development process.

Development is quite different than production. Think of development as creating a recipe and production as following the recipe. Thse are very different activities, and they should be carried out with different approaches. Developing a recipe is a learning process involving trial and error. You would not expect an expert chef's first attempt at a new dish to be the last attempt. In fact, the whole idea of developing a recipe is to try many variations on a theme and discover the best dish.

Once a chef has developed a recipe, preparing the dish means following the recipe. This is equivalent to manufacturing, where the objective is to faithfully and repeatedly reproduce a "recipe" with a minimum of variation.

In many ways, software development is the antithesis of manufacturing:

• Variability is the enemy in manufacturing; in software, it's the reason we get up in the morning. Every worthwhile software development project is a custom one-off job for a unique problem.
• Requirements are the bread and butter of manufacturing; in software, we rarely have meaningful requirements. Even if we do, the only measure of success that matters is whether our solution solves the customer's shifting idea of what their problem is.

I suppose the proof is in the pudding; if Scrum works for manufacturers and software development shops alike, then maybe the parallels between the two industries are valid. Still, I think Lean Software Development: An Agile Toolkit would be a much stronger book if it relied more on examples from actual software development efforts and less on examples from the movie Gung Ho.

* which I discovered through Joel Spolsky's The Best Software Writing I.