Agile Methods and Movies
I've seen this idea posited before - that development of software is a lot like the development of a movie. i.e., the process is very expensive, and the end results of the project (ROI, profit, whatever) are up in the air until the very end. Comes this post on the subject, relating it to the innovations of Disney early on:
The work seems to have been structured around a core consisting of Disney himself, and a handful of people that were responsible for the music, the visuals, and so on. The entire machinery was no doubt coordinated using very high volumes of face-to-face communication, model sheets(guidelines for how to draw the specific characters), and written guidelines describing the mood or tone that should characterize the movie in production. They used rough prototypes to get a feel for each scene, which were discussed by a group of people before being done full-out. (I guess they did another round of prototypes if the first was deemed not good enough.)Reading this book has convinced me that there's much to learn for programmers in studying how movies are made. (See also my post Storyboards: a pragmatic tool for coordination) Movies are very expensive to make, and a flop can often be disastrous for the movie company; yet, straightforward methods such as face-to-face communication, sketches, and storyboards, are seen as effective means of executing a project. In software, however, the tools must be advanced and expensive, or they are ridiculed; the obvious simple ones are often not even considered.
Read that last part again - there's a lot of truth there. Consider the plethora of (to my mind) nearly useless modeling tools out there - they are hard to use, expensive, and don't relate to the code well at all. And yet most large teams use them, typically as part of some godforsaken process.
Now consider storyboards. Sounds a lot like what the Agile Alliance guys have been talking about, doesn't it?
Here's more:
In software, however, many people seem convinced that building software is like building bridges or houses, and therefore try to adopt processes from those worlds.From reading The Art of Walt Disney, it's obvious to me that the Disney process was based on exploration, communication, feedback (adaptation), freedom. Despite the image of Walt Disney as the master planner, I'm convinced that the animators were free to be creative both regarding the film and the aspects of the process that involved them. The team constantly tried new things, and met to discuss them and find out how they could improve things. Today in the software business, the followers of the agile movement talk about agile as if it would be something new. In fact, Disney were agile (because they had to be).
Nothing new under the Sun, I guess - except for this insight. What the software development world needs is a good kick in the pants. Or more succinctly, let me post one of my all time favorite email signature lines:
"I think we've shown simplicity to the world ... but I don't think we've jammed simplicity down the throat of the world to the extent that we really should have" - Ron Jeffries

Comments
Re: Agile Methods and Movies
[Rich Demers] March 1, 2003 17:46:37.228
I agree with the spirit of this item - keep both processes and tools simple, but there remain two point to make:
First, you have to know where you're going. Disney had a plot for each movie and at least a rough vision of what the resulting move could be - and that gave all of those creative types a framework to work in. They didn't just feel their way to some unknown end product. Disney was the architect, and any software project without an architect is doomed to failure.
Second, to do things really simply sometimes takes really sophisticated tools. A workshop full of machinists, each operating a simple tool like a drill press or a lathe, can build anything, but complex products require a lot of coordination (i.e., process). On the other hand, a single machinist working with a computer controlled milling machine needs only a block of steel, a program, and an oil can. The key is getting past the knee of the curve where internal tool complexity provides operator simplicity. Same with programming tools, but we're not past the knee of the curve, yet.