A recent New Yorker piece on the actor Steve Carell (subscription required) is actually a fascinating behind-the-scenes look at how the process of creating funny movies has shifted from sequential and scripted to highly improvisational and highly iterative. The old way — writing a movie, casting it, shooting it, editing it, in that order — has evolved, in this Apatowian age, to a new multi-stage creative process:
Hollywood studios have cross-pollinated (mid-shoot) improv with such sitcom staples as the table read (where the script is read aloud by the actors to an audience of writers and executives) and the roundtable (in which a group of writers “punches up” a script). With “Dinner for Schmucks,” the script was crowd-sourced: after Paramount and DreamWorks hired several screenwriters to try to adapt the 1998 French farce “Le Diner de Cons,” without success, David Guion and Michael Handelman, both trained in improv, devised a structure that seemed to work… Guion and Handelman’s draft was fussed with three times by sets of other writers, then tweaked three more times at comedy roundtables, where groups of writers gathered for about six hours to suggest new bits and jokes. Last summer, the script was given a two week polish by [Director Jay] Roach’s writing partner, Larry Stuckey, and revised one last time by Guion and Handelman, before finally being turned over to a cast skilled in improv (with Guion and Handelman on set to suggest yet more alts).
Later in the piece, Will Ferrell observes, “It’s almost a think-tank approach, and it gives you about thirty per cent more options. There are still a fair number of people who don’t work this way — which we kind of don’t understand.”
The resources needed to create comedies this way are non-trivial — nearly twice the film used in a traditional comedy was used during the process of filming “Dinner for Shmucks” (900,000+ feet of film -vs- 500,000) and Apatow “always uses at least a million.” Director Jay Roach says “It’s a sloppy approach. One out of ten moments is great, and you watch the other nine go by and hope.”
The results, however, seem to be worthwhile – Steve Carell’s last five movies have each grossed over $150 million.
The more I read, the more this creative process sounded familiar – I thought: “wow, they’re doing Agile development.”
The same thought occurred to me as I read Anthony Bourdain’s description of the menu development process at David Chang’s wildly successful restaurant, Momofuko Ko, where the menu changes every day:
The creative process by which the final dishes at Chang’s restaurants are arrived at is an absolutely fascinating stream of daily e-mails between chefs and cooks. Preceded and followed by many, many testings and tastings. Five-word rockets detailing a sudden flash of inspiration, 1000-word missives detailing an experience, a flavor, a possibility — an experiment that might lead to something great, continuing back and forth. The hard-drive on Chang’s laptop — from what transcripts I’ve seen — contains a years-long conversation with some of the most exciting and creative minds in gastronomy. And it’s not just the employees weighing in.
So, what is it that these comedians and these chefs are doing? What is this thing called “Agile?”
Traditional software development process is often described as the “waterfall method” because it moves from one phase to another in sequential order: requirements => design => implementation => verification => maintenance. This approach was adapted from construction project management, where the laws of physics enforce strictly sequential builds, and it’s exemplified by the curriculum of the Project Management Institute, an organization that provides professional certification to project managers, and also serves as a sort of Death Star of Innovation, single-handedly sapping energy, fun, and creativity from anything it touches, using a dastardly vortex of turgid documentation matrices and sign-off requirements.
Agile methods take advantage of the comparatively less stringent materials of software development (especially web software development, with the possibility for releases every few hours, if you really want), and differ from traditional methods in that they focus on frequent iterations, builds, and deliverables, each of which may encapsulate several mini-cycles of requirements => design => implementation => verification. Face-to-face conversation is preferred over documentation, and strong emphasis is placed on empowering trusted, motivated team members to be effective and to organize themselves.
I initially dismissed Agile, coming as a suggestion (in a strange cock-up of bad ideas heavily featuring pair programming) from a team member who had a vested interest in limiting visibility and accountability — he was about to get the axe for essentially not being able to code his way out of a wet paper bag. I’d spent much of my career producing web site builds and had never been a particularly strict practitioner of PMI-style project management — generally my feeling has been that each project or build has its right level of planning, design/architecture, and documentation, depending on what the desired outcome is: basically I’ve always tried to do what is useful without slowing things down. When Mr. Agile proposed his new methodology, we were using a heavily customized and hacked up version of Bugzilla as a database of information about our work, and I have to say, it was pretty awesome. Being able to query up not only who is doing what, how important it is, what stage it’s at in the release process, and key details about what a task or project involves, all on the fly, is really pretty useful, and if I’m ever in the role of managing a team of developers that large again, there’s a good chance we’ll be doing something pretty similar. There was no way I was going to let one slacker dictate dismantling a system that worked. (I also had, and continue to have, a skeptical perspective on pair programming — which basically amounts to two developers to get the same amount of work done in the same amount of time in which one developer can do the same work — code reviews are one thing, but let a dude — or Lady Coder — finish his/her thought first.) What we weren’t doing was using the incredible brains of the team we had on board (in a structured way, at least) to help us drive the outcome of our product.
Over time, I realized that the principles behind Agile development are pretty awesome, and that even though they might seem obvious, they were kind of what was missing for me in thinking about how to be good at what I do. These principles are that we should value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Or, as I kind of think about it: “Make Amazing Things Happen” instead of “Don’t Allow Fuck Ups.” The tricky part is, in order to make that change of focus, the overall level of Okayness with Fuckups has to go up to some degree. In fact, one of the most liberating concepts to emerge from this whole Agile thing is a familiar and comfortable relationship with failure — not for its own sake, obviously, but as a way of discovering how to adapt for success. I love this bit from Clay Shirky’s optimistic and fascinating new book Cognitive Surplus:
No one gets it right the first time. Wikipedia was born out of the ashes of a previous, failed experiment in creating an online encyclopedia called Nupedia. Twitter was created for use on mobile phones, then retooled itself for more web use, then saw use explode with the spread of smartphones. If successful uses of cognitive surplus required designers to get it right the first time, you’d be able to count the successes on the fingers of one hand. Instead, the imperative is to learn from failure, adapt, and learn again.
Personally, I am fascinated by the ways that these concepts and methods are infiltrating environments way outside of web development — from movies to food and way beyond, it seems that iteration and other Agile concepts are having a moment, or perhaps a new dominance, in how we think about evolving ideas. It makes sense that these ideas are first defined in the context of web applications, as the web applications themselves tend to enable our ability to publish anything quickly and with minimal investment and commitment, but as we become used to working in these new ways, I can’t wait to see what can emerge from a culture where everyone is Making Amazing Things Happen.
Have you seen Agile methods pop up in strange places? If so, where?
Agile Comedy, Momofuku Ko, and Making Amazing Things Happen
A recent New Yorker piece on the actor Steve Carell (subscription required) is actually a fascinating behind-the-scenes look at how the process of creating funny movies has shifted from sequential and scripted to highly improvisational and highly iterative. The old way — writing a movie, casting it, shooting it, editing it, in that order — has evolved, in this Apatowian age, to a new multi-stage creative process:
Later in the piece, Will Ferrell observes, “It’s almost a think-tank approach, and it gives you about thirty per cent more options. There are still a fair number of people who don’t work this way — which we kind of don’t understand.”
The resources needed to create comedies this way are non-trivial — nearly twice the film used in a traditional comedy was used during the process of filming “Dinner for Shmucks” (900,000+ feet of film -vs- 500,000) and Apatow “always uses at least a million.” Director Jay Roach says “It’s a sloppy approach. One out of ten moments is great, and you watch the other nine go by and hope.”
The results, however, seem to be worthwhile – Steve Carell’s last five movies have each grossed over $150 million.
The more I read, the more this creative process sounded familiar – I thought: “wow, they’re doing Agile development.”
The same thought occurred to me as I read Anthony Bourdain’s description of the menu development process at David Chang’s wildly successful restaurant, Momofuko Ko, where the menu changes every day:
So, what is it that these comedians and these chefs are doing? What is this thing called “Agile?”
Traditional software development process is often described as the “waterfall method” because it moves from one phase to another in sequential order: requirements => design => implementation => verification => maintenance. This approach was adapted from construction project management, where the laws of physics enforce strictly sequential builds, and it’s exemplified by the curriculum of the Project Management Institute, an organization that provides professional certification to project managers, and also serves as a sort of Death Star of Innovation, single-handedly sapping energy, fun, and creativity from anything it touches, using a dastardly vortex of turgid documentation matrices and sign-off requirements.
Agile methods take advantage of the comparatively less stringent materials of software development (especially web software development, with the possibility for releases every few hours, if you really want), and differ from traditional methods in that they focus on frequent iterations, builds, and deliverables, each of which may encapsulate several mini-cycles of requirements => design => implementation => verification. Face-to-face conversation is preferred over documentation, and strong emphasis is placed on empowering trusted, motivated team members to be effective and to organize themselves.
I initially dismissed Agile, coming as a suggestion (in a strange cock-up of bad ideas heavily featuring pair programming) from a team member who had a vested interest in limiting visibility and accountability — he was about to get the axe for essentially not being able to code his way out of a wet paper bag. I’d spent much of my career producing web site builds and had never been a particularly strict practitioner of PMI-style project management — generally my feeling has been that each project or build has its right level of planning, design/architecture, and documentation, depending on what the desired outcome is: basically I’ve always tried to do what is useful without slowing things down. When Mr. Agile proposed his new methodology, we were using a heavily customized and hacked up version of Bugzilla as a database of information about our work, and I have to say, it was pretty awesome. Being able to query up not only who is doing what, how important it is, what stage it’s at in the release process, and key details about what a task or project involves, all on the fly, is really pretty useful, and if I’m ever in the role of managing a team of developers that large again, there’s a good chance we’ll be doing something pretty similar. There was no way I was going to let one slacker dictate dismantling a system that worked. (I also had, and continue to have, a skeptical perspective on pair programming — which basically amounts to two developers to get the same amount of work done in the same amount of time in which one developer can do the same work — code reviews are one thing, but let a dude — or Lady Coder — finish his/her thought first.) What we weren’t doing was using the incredible brains of the team we had on board (in a structured way, at least) to help us drive the outcome of our product.
Over time, I realized that the principles behind Agile development are pretty awesome, and that even though they might seem obvious, they were kind of what was missing for me in thinking about how to be good at what I do. These principles are that we should value:
Or, as I kind of think about it: “Make Amazing Things Happen” instead of “Don’t Allow Fuck Ups.” The tricky part is, in order to make that change of focus, the overall level of Okayness with Fuckups has to go up to some degree. In fact, one of the most liberating concepts to emerge from this whole Agile thing is a familiar and comfortable relationship with failure — not for its own sake, obviously, but as a way of discovering how to adapt for success. I love this bit from Clay Shirky’s optimistic and fascinating new book Cognitive Surplus
:
Personally, I am fascinated by the ways that these concepts and methods are infiltrating environments way outside of web development — from movies to food and way beyond, it seems that iteration and other Agile concepts are having a moment, or perhaps a new dominance, in how we think about evolving ideas. It makes sense that these ideas are first defined in the context of web applications, as the web applications themselves tend to enable our ability to publish anything quickly and with minimal investment and commitment, but as we become used to working in these new ways, I can’t wait to see what can emerge from a culture where everyone is Making Amazing Things Happen.
Have you seen Agile methods pop up in strange places? If so, where?