October 3, 2006
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:
- It's two additional characters away from a term for male genitalia.
- 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.
- 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.
Posted by Jeff Atwood
Wikipedia got the spelling right.
Or perhaps, just perhaps, Wikipedia had the typo and we both pasted it in. Subsequently someone fixed it on Wikipedia..
On John Price's point, I wonder if the problem is that we've become far _too_ good at the final production process. That is, we have tools which are so automatic in producing the final output that there is no human effort involved in actually producing the work product from the blueprints. In the worst case, the developer must open the IDE for each component and run the Build command. In the absolute best case, the automation is set up so that a component (e.g. CruiseControl.NET) monitors the source repository and, when a checkin occurs, automatically gets the latest source and builds the output.
I wonder if this makes the casual observer, and even some developers, blind to the actual manufacturing phase and see (wrongly) that what the developer is doing as being 'assembling the box of parts'. The corollary is that end-users will _never_ be able to get a 'toolbox' programming system that works well enough to completely replace professional programmers.
Making the assembly of cars fully automated is probably achievable with technology - as in, plug blueprints and components into an industrial automation system at one end, get a fully assembled car at the other - but it would require extensive work to ensure that all the parts were aligned correctly before trying to bolt them in, and there would either have to be some dramatic redesign or some very clever tools to work in some pretty cramped spaces on most cars. Our tools have the advantage that they (now) only have to manipulate bits on disk, which is of course what any program does. It was inevitable that we would eventually get to a point where we could make building a program entirely automatic.
Software development is like software development... When will people stop trying to compare it to anything else? Metaphors are useful in small doses.
Software development is NOT like manufacturing... manufacturing is about the design of a product, and it's subsequent replication. It's about the process of copying. Software development is about creating an entirely new thing every time-- copying is free and is usually as simple as dragging a folder around on the desktop.
I agree with Ken(Ken on October 5, 2006 06:32 AM)in that we are constantly trying to get some new catch phrases and buzzwords to define....what? It all seems to boil down to the same old committees attending meetings. I would guess if you wanted to compare the software process to anything, it would be the process used to create advertising campaigns. Creative people trying to get a different product out each time while dealing with whiney customers.
It's also two letters away from a pirates favorite drink. Arrrrr!
Great post -- as usual. I've seen this parallel made before...and agree with the first post: software development is like software development. I've worked in the manufacturing sector (Ford and American Honda) doing custom software. We weren't crazy enough to ask our manufacturing brethren to "help" out on our schedules/methodology.
Love the comment about requirements Jeff. My current gig is all about requirements. Management randomly thinks we have great requirements (we don't..) or that we don't need them at all(we do...). I'm so glad things don't ever change!
Really, you know, whatever. In this day and age there is a constant desire to define, to model. We must have definitions and catchy terms and phrases. We must follow guidelines and adhere to the latest, greatest thing that's catching on.
For me, though, it all gets to be a bit too much. I know this seems overly simplified but just try to do the job at hand using the right tools and taking the most logical approach.
There's always more than one way to skin a cat, especially in software development.
Additionally, committing your people to the same approach for any and all project projects doesn't seem to be the right answer to me. One size does not always fit all. If it did we wouldn't have multiple languages, multiple platforms, multiple ideologies.
And scrum is just a god-awful name. Don't get me started on all the goofy naming and labeling that's going on these days!!!!!
Just my nickel of thought.
"Is Software Development Like Manufacturing?"
Why would we care?
Here's the interesting question - what can we learn from an organisation that outperforms its peers year-in year-out.
"Recognizing that TPS is about applying principles rather than tools enables companies that in no way resemble Toyota to tap into its sources of success. Alcoa, a company whose large-scale processes - refining, smelting, and so on - bear little resemblance to Toyota's discrete-parts fabrication and assembly operations, has based its Alcoa Business System (ABS) on the TPS rules. ... pilot projects applying the rules at ... health care organizations have led to huge improvements in medication administration, nursing, and other critical processes, delivering better quality care to patients, ..."
Stephen Spear "Learning to Lead at Toyota" Harvard Business Review May 2004 78-86
Steven Spear and Kent H Bowen "Decoding the DNA of the Toyota Production System" Sept 1999 97-106
Ascribed to the Poppendiecks - "This is equivalent to manufacturing, where the objective is to faithfully and repeatedly reproduce a "recipe" with a minimum of variation."
That's strange, read the Stephen Spear articles and you'll see that the objective is to repeatedly vary and improve the recipe - by following a standard approach to process improvement.
Jeff Atwood wrote "Variability is the enemy in manufacturing; in software, it's the reason we get up in the morning."
Variability in the quality of customer experience is the enemy - in manufacturing, in services, in software.
Chapter 2 of Peopleware (DeMarco/Lister). "Make a Cheeseburger, Sell a Cheeseburger."
Same principle. In production, you optimize the steady state. Sqeeze out excess. Sternly deal with goofing off. Get as close to 100% "go" mode as you can.
Development is development is development. (dance, monkey boy!*)
Whether you're developing armour piercing rounds, a new type of vaccine, or software. (I haven't a clue why those examples came to mind..)
[quote source=Peopleware p8.]
(one should) encourage people to make some errors. You do this by asking your folks on occasion what dead-end roads they've been down, and by making sure they understand that "none" is not the best answer.
I forget whose idea it was, but I once heard a much better explanation of software development in terms of manufacturing than what is usually presented (if you simply must use a manufacturing metaphor):
In manufacturing, you spend a whole bunch of time up-front doing design work and end up with a blueprint for what you want to build. You (loosely speaking) feed that blueprint into a bunch of machines who churn out your end product The traditional software-as-manufacturing metaphor maps "creating blueprints" to "writing a spec", "bunch of machines" to "developers", and "end product" to the code that those developers produce.
The revised metaphor instead maps "creating blueprints" to "writing code", "bunch of machines" to "compiler", and your end product is the binaries that you produce.
Using this metaphor better emphazises the challenges and efficiencies of software development as compared to manufacturing.
First, it casts the coding process as the creative design step that it is, rather than suggesting that developers are a bunch of automatons that take specs in at one end and churn out software at the other.
Second, it acknowledges the need for a detailed spec, but casts the code itself in that role. After all, what more detailed spec of how software works is there than the code itself? And unlike real manufacturing where screwing up the blueprints and starting to manufacture something incorrectly is extremely costly, actually "manufacturing" something from code is essentially free. Appreciating this frees you up to try different things with your blueprints to see which one produces the best end product.
I'm embarrased to admit I walked through a lot of names for male genitalia and never got to the one you meant. Who knew you meant a mature, adult word? Be more clear next time. Either way, it's hardly a more unfortunate name than "Scumniotales".
I suppose one can make the manufacturing analogy if one accepts that software development is mostly about the repetitive process called typing. If one doesn't, then analysis deriving from the analogy is wrong. Design/build of bridges or skyscrapers or doghouses is more accurate (yes, design/build is a term of art).
As to variability, we do it differently each time because *we* want to; rarely do our employers, *they* think it's about that repetitive process called typing.
Never forget, it requires a good deal more time, effort, and brains to be a real architect than the software type. You need a license to be a real one. Hell, you need a license to be a dog groomer. Hairball anyone?
"The beatings will continue until morale improves."
Is Software Development Like Manufacturing?
Nor is it like constructing a building, or crafting an exquisite violin, or even playing rugby. It's also not remotely like hunting a tiger either.
Anything else I can do to help, as I'm running a bit late?
PS I can sell you a hardback limited edition 'ScragilefallXP 2.0 - Lose 20 Pounds Instantly'(GBP 20) book if you sign up for the free training course - today!
PPS I am weirded out by your scrum/scrotum word association. I racked my brains before hovering over the link and still couldn't guess it. Is there something you'd like to share with the group? (cough)
Another interesting definition of scrum (in he rugby sense)
One guy trying to push 2 guys up three guys buttholes.
It made me chuckle...and now it is my gift to all of you lovely anonymous readers. Don't spend it all in one place.
When playing Rugby at school I always used to deliberately collapse the scrum.
Perhaps "Huddle" would be a better term - describing a daily (meeting) huddle - but that leaves me with images of poor, cold starving developers huddling together for warmth and comfort in the pouring rain (or backlog)
I think the similarity lies in the chaos seen in the early days of industrial management and that we see now in software development.
Perhaps we'd see a GoldRatt (author of book: Goal) coming out from the software field too.
What I mean to say is practices like the JIT manufacturing and Goldratt's theory of constraints really helped the people in manufacturing industry.
Now when one sees similar problems in the software industry one is tempted to draw experiences from the other industries, particularly the techniques which have really been succesfull.
By the way, has any one heard of www.softwarefactories.com?
Building software is not like manufacturing, it is like designing the first prototype. Which doesn't mean there's nothing to be learned from the manufacturing-sourced idea of "just in time" or "lean."
Yes and no.
In designing a prototype it will never happen to design a Toyota Tercel, then have the customer come and ask for a Hammer.
This can happen quite often in software.
It is a limit in how "lean" you can be.
Not to be crass, but it's also two letters (if you remove them) away from a byproduct of said male genitalia.
The post and some of the comments highlight why most software projects are over budget -- everything has to be 'new', and we do not require customers to fasten their minds down and state what it is they want. Software tries to follow their ramblings.
People don't take the time to think things through or require enough of a specification. So we invent new 'methodolgies', yet things are still over budget and behind schedule.
require customers to fasten their minds down
It's a lot like herding cats.
Rugby might be an "extraordinarily violent sport", but the strange thing about it, is that traditionally it's played by 'upper class' people.
There is an old saying that compares Soccer (aka 'association football', 'the football with the round-ball', 'the world game') and Rugby (aka 'Rugby Union').
"One is a thug's game, played by gentlemen, and the other a gentleman's game, played by thugs."
"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."
Anything inherently not variable in software becomes a "more or less standard" library whose marginal production cost will be zero and purchase cost will be a fraction of the development cost, thus "worthwhile software development" means something not done before.
The word is "iMproper", by the way, not "iNproper". You've made the same error twice in that quote (or you and some other blogger also misquoting Wikipedia, I forget now). Wikipedia got the spelling right.
would be a much stronger book if it relied more on examples from actual software development efforts
Maybe ... just a thought ... there AREN'T many examples from actual software development efforts. :-)
lb wrote "traditionally it's played by 'upper class' people"
What was true 150 years ago, and what's true now are different things.
Software development is a mix of manufacturing and thinking. We moved from breadboards to assembly all the way to today's excellent IDEs for one reason: to ignore the manufacturing and focus our brains on thinking.
There are still plenty of manufacturing processes in the chain (source control, bug tracking, builds, etc.). They can either be done haphazardly, with variable results or documented, optimized, and shoved out of the way.
An article about our experience "manufacturing" software: http://profitdesk.com/content/2006/07/21/switching-out-the-dies/
Michael Schoeffler wrote 'An article about our experience "manufacturing" software:'
Forgive me, but isn't that an example of your experience with factory recall :-)
lb wrote "traditionally it's played by 'upper class' people"
What was true 150 years ago, and what's true now are different things.
yup, Austrailians play it now.
Some good points here -- there are limits to the comparison. However, I think there's another angle that's been missed: Lean is not really about processes and tools as much as it's about a way of thinking. This is why there's so much emphasis on culture. Lean can be (and has been) described in many ways, but it boils down to (1) reducing waste in all its forms in the pursuit of customer value, and (2) trying to do #1 better by hypothesizing, expermimenting, observing in a continuously repeating loop.
Jim Womack, founder of the Lean Enterprise Institute, and author of some of the seminal books on Lean has shifted gears a little bit and now talks about Lean Management vs. Lean Manufacturing, and he makes the point that the thought process can be used virtually anywhere.
By the way, the Stephen Spear article mentioned above is awesome.
I also am not convinced that manufacturing industries and software development have much, if anything, in common--but, Jeff, I don't believe that Mary is arguing this which is perhaps more clear in her more recent book, Implementing Lean Software Development.
The paper that helped inspire Scrum (The New New Product Development Game) is not about manufacturing at all, but about product development. Software Development is product development and a particularly pure form of it since the medium we work in is so malleable--a mere computer-intelligible expression of an idea. While most of what we hear about _Lean_ has to do with the manufacturing approach Toyota and others have adopted, Toyota's process for inventing new products (Lean Product Development) is really the basis of the thinking behind Agile methodologies like Scrum, XP, etc. While Lean Manufacturing and Lean Product Development share a few underlying principles, they are very different processes focused on very different kinds of problems. The process used to design a new car is nothing like the process for manufacturing it.
Another metaphor thrust on software is from construction. Architects design, builders build. Fowler argued persuasively (http://www.martinfowler.com/articles/newMethodology.html) that in software it is all design. The construction phase is what the compiler does. Applying Lean Product Development (not Lean Manufacturing) to Software Development makes precisely this point.
For more on the origins of Scrum http://www.infoq.com/presentations/The-Roots-of-Scrum