Monday, May 31, 2010

What Pixar can teach us about Software Development

I had visions of a career focusing on game development and animation, my thesis was even on the subject, and I spent 2 years working in a game development studio. Even though I changed career paths years ago, I have followed Pixar for years, from before the first Toy Story was released. I remember the 1996 Computer Animation Conference at the Ontario Science Centre where Pixar showed off a blooper reel from Toy Story.

So it was instinct that I grabbed the May 2010 issue of Wired magazine, with the cover story of "How Pixar Works". As I read the article I stumbled into something, software companies have it wrong; the core development lifecycle used for close to 50 years is inheriently flawed. It doesn't matter whether they use waterfall, agile, scrum or any other development methodoligies they are all disruptive and prone to failure.

Pixar's culture is one of simplicity, create an environment of success and ownership through innovation and development. Everyone is invested and owns the final product, and after four years in development no one wants to let go of Woody or Buzz, they want to keep making them better. The article highlights a key principle, "the project team meets each morning to rip apart the two or three seconds of film from the previous day searching for ways to make the shot more expressive". This is done collaboratively, even the newest and most junior team members have input. At the end of the project, the team moves intact to the next project allowing trust, communication and relationships to develop between team members.

So, how did software companies get it so wrong?

Arcane software development lifecycles imprinted over time and transferred between software organizations through staff turnover have choked off thought leadership and preserved the inability to change. As it relates to development process, those who come into organzations want it their way, whether it is a conversion to agile or scrum. As it relates to team organization, the standard lifecycle limits input by those working on a project (a developer or tester) as the product is defined before they see it and it is too late in the product development lifecycle to impact design or feature sets. The standard lifecycle prevents trust between roles as it is inheriently combatively and people are afraid of failure. A last minute issue results in arguments over whether it was valid as it wasn't in a test plan, or whether the quality of testing was high enough etc.

What has to change?

Sofware companies need to throw away what they know and start over. They need to stop being combative and work together. Take away the development lifecycle, split the resources into teams, not verticals or by role/department but rather by project. In the simplist terms, a Director is in charge of only one project. They are given a number of resources, covering project management, development, testing and release.

On day 1, the team goes offsite and flushes out the concept of the project.

On day 2, the entire team flushes out storyboards for the design and user experience.

On day 3, the development starts. Everyone who can code does so, there are no more specific roles anymore. Those who can't code are given marketing and other deliverables; everyone is equal.

On day 4, the team rips apart the previous days work; whether it is code or a user interface design seeking ways to make more impactful.

On day 5,6,7,8 etc - new development occurs and as the project takes shape testing starts

Days 4-8 repeat for the length of the project. At periodic points the project is presented to senior management for review.

Do not get the above workflow confused with agile or scrum as it isn't.

The clear difference is ownership and innovation,they are built into the process, everyone is invested in the final outcome as they provide creative and impactful contributions to the outcome.

It also pulls changes/enhancements/defects up to the front of the process reducing rework towards the end. It removes the known phases of the development lifecycles (requirements dev, test, etc).

Once the product is released the entire team moves onto the next project repeating the cycle above, building trust and synergies between the team members. For executives, the team is a known entity who delivers results.