The plot would transform again and again over many months...
...we are true believers in the power of bracing, candid feedback and the iterative process—reworking, reworking, and reworking again...
(Excerpts From: Ed Catmull with Amy Wallace. Creativity, Inc., Chapter 3, P. 85, Chapter 5, P. 127.)
I could talk a long time about iterations, but rather than one long and probably boring post, I will break it up into 2 shorter (but maybe still boring) posts. This first one will focus on the benefits of getting feedback early and often.
Pixar's process for developing films is very iterative. Their films don't get built in a linear "waterfall" fashion, going from writing to storyboarding to animating to lighting. Instead, it's an iterative, agile-like process (granted, their iterations are longer than the usual software sprint or iteration). Every few months, the filmmakers gather everyone at the company to view the film in its current state. Early on, the film is just in storyboard form with scratch voices and music. After eac screening, everyone is able to give notes - what's working, what's not, etc. As Ed says in the second quote above, candid and frequent feedback is critical to their process. The filmmakers take these notes and go back at it, re-working and re-boarding scenes, and slowly moving the film forward.
This is also the Agile way of building software. Rather than the traditional method of first gathering all requirements, then developing the software, then testing and finally releasing software, the system is described in stories (as described in earlier posts), and development starts almost immediately. The business owner or users decide which stories are of highest priority and the developers will work on them in an iteration usually lasting 1-3 weeks. By the end of the iteration, the stories will have been developed, tested and often times ready to be deployed. This process then repeats itself until all the stories are complete.
Why is an iterative approach a better methodology for both movies and software? In both cases, we want to get feedback early, while there's still time to make adjustments with minimal rework. When developing software, by involving the users or business owners early on, they can see and react to what we as developers are translating their requirements into. We may not have understood the user's desires or requirements. In addition, it's difficult to envision what an application is going to look like without something concrete to examine and try out. With an iterative approach and early feedback we can adjust what we're building while we have time and with less rewriting. Finally, by having the business owners involved every step of the way, they are able to pick the most important stories to be worked on each iteration, or even add new stories not envisioned when the project began. This helps us deliver a system that will meet their needs and one that adapts to the changing dynamics of the business.
Compare this with a traditional waterfall project where the users aren't able to see the final product until the end. At that point it's usually too late to make significant changes. And changes that would have been small had they been caught early become hard to implement because now their impact may ripple through much more of the system. This can lead to sub-optimal, quick fixes and technical debt.
Part 2 of this discussion on iterations will cover another benefit of iterations, which is evolving the product.
No comments:
Post a Comment