Creativity Inc and Software Dev: Break Large Problems Into Small Ones

As I mentioned in a recent post, I've been reading Ed Catmull and Amy Wallace's new book Creativity, Inc. and continue to find many similarities between how Pixar develops films and how those techniques can be used to develop software in an Agile fashion. This is the first post to explore some of these similarities.

I'm going to start with the following quote, where Mr. Catmull is talking about coloring a bottle:

It was easier to figure out how to color and display each tiny piece

(Excerpt From: Ed Catmull with Amy Wallace. Creativity, Inc., Chapter 1, P. 37, iBooks.)

I like this quote being the source of my first post as this is a fundamental tenet of most Agile development methodologies. In traditional methodologies, the team starts with a requirements specification that can have hundreds or thousands of individual requirements. Trying to analyze a project with a large requirements specification can be overwhelming - it is easy to get lost in the details, and most times the details aren't necessary to come up with accurate estimates or the system design. On the other hand, breaking up a large project into small pieces of functionality (the Agile term for these pieces are stories) makes the project more manageable and easier to understand.

Let me give an example of using stories that ties back to the quote above. I don't know how well this is going to work, but let's just go with it. Assume you work for a company and you're asked to build a customer loyalty system, maybe to be more specific a new frequent flyer program for an airlines company. Just like the bottle in the quote above, thinking about this system as a whole could be overwhelming! Where do you start? What are the most important pieces of functionality? Somehow you need to break up the system in smaller components.

Using a traditional development methodology, you might have a requirements specification with thousands of requirements. This would be akin to shattering the bottle (OK, possibly over the top, but still, work with me) - sure, it might be easy to "color" each tiny little piece but you'll likely never be able to put all the pieces back together. You could also quickly lose sight of the bigger picture.

Instead, an Agile approach would be to define the system in small pieces, each piece representing a specific feature or function the system must perform, such as:

• Users must be able to log in
• Once logged in, users should be able to see their transaction history
• Users should be able to shop for flights using their points/miles
• Users should be able to request credit for missing miles

In this way, it is easier for all interested parties (business owners, project managers, developers, testers) to understand the system. We can also decide on the priority of each story/feature, providing flexibility in building the system. Writing stories is a difficult task but if done well it can be a very powerful and flexible mechanism.

This is just a quick summary of stories and a couple of their benefits. I'll talk a lot more about them in later posts.