Can We Learn From Pixar?

As I fly to IT Forum in Las Vegas, I am reading with interest the latest copy of Wired Magazine. Within the normal collection of interesting geek-fest, I stumbled upon a story about Pixar.

It appears that making films is a bit like software projects. They tend to be late, cost too much money, and the value of the project is hard to determine. There is one picture company that does not follow this trend. Since their inception, Pixar has gone against the Hollywood Norm, delivering nine films and nine massive hits. Wouldn’t it be great for application development professionals to be as successful, delivering fantastic projects that are both successful and of high value? So what can application development professionals learn from Pixar?

Pixar have built a fantastic company with great people working on very creative and imaginative projects. But four things stand out as things app dev pros can learn from:

  1. Using teams instead of assembling a cast of freelancers. The normal studio model is a project-based one, with teams of freelancers being assembled to create a film and who are then cut loose after the project. Pixar creates teams of people and then moves them from project to project. This approach has many benefits, but Pixar highlights trust as the most important one, with teams of writers, directors, animators, and technicians knowing each other’s strengths and weaknesses and working effectively in a trust-oriented environment.
  2. From trust comes critique. Each day teams review the work, ensuring that mistakes are highlighted and that “perfection” is pursued. This would be impossible if the team did not trust each other and is very different from traditional projects where teams spend a great deal of time ensuring that any criticism is not placed on them. This aspect of review and change is highlighted by Lee Unkrich, director of Toy Story 3, “We know screwups are an essential part of making something good. That’s why our goal is to screw up as fast as possible.”
  3. Great people are given the environment to create. Freedom to create is a fundamental maxim for Pixar. They allow animators to create their own workspaces that demonstrate their creativity and individuality. They place everyone in the same location and build an environment that encourages people to interact. Steve Jobs can be in part credited with that, insisting that the building’s essential facilities be centrally located.
  4. Release management is a separate function. Teams left to their own devices would continue to develop, extend, and improve the finished product forever. That is part of their DNA and their pursuit for perfection. But effectively managing the balance between development and release is managed by providing a release team who, working with the development team, defines the production time line. That makes sure that development teams are very careful about the prioritization of work, ensuring they keep focused on the things that are important.

Taking these ideas and applying to development:

  • Building teams. The reality of most delivery organizations does not enable teams to only focus on one project, but these cross-project responsibilities should be kept to a minimum, allowing teams to work together for a long period of time – building trust and working practices.
  • Frequent delivery and inspection. Not just in the case of Agile approaches, where code is delivered frequently, but also with traditional approaches, work products should be delivered frequently and reviewed. Change should be encouraged rather than considered to be an insult to the person who created the deliverable.
  • Consider the working environment. Co-location is an ideal environment but often is not practical or possible. But the virtual or physical environment should be considered, allowing team members to have both space and collaborative areas. Wikis and team notice boards should be used to enable collaboration.
  • Keep release processes separate. It is easy to mix development with release, but the cycles and practices are very different. Thus it is important to build a “two-in-a-box model,” allowing development teams to focus on delivering value and the release manager to focus on the delivery schedule and date. By having the teams frequently collaborate and manage the balance, it is possible to optimize the final deliverable.


Jeffrey Hammond and I are working what it means to build a world-class development team. We would love to hear your views…

Dave “the Woody” of software development…


Creativity and Innovation over Process and Methodology

Dave, I could not agree more with that observation. I am aware of that similarity, especially in the area of CGI animation, because my son is a movie director.

But I cannot just offer an overlap in opinion. I can prove that these four points are elementary in successful software development and other IT realted projects. My R&D manager and I have been working like that for the last 18 years. We hardly ever user freelancers and if only for very special short-term skills. We never believed in outsourcing our 'intellectual property' to India and the only time we tried with a service partner failed miserably.

We do recommend the same approach in our implementation projects at our customers. We ask them to get good people and train them. If they do the results are stunning! Outsourced shops are a dead-end and don't deliver any value --- just lower cost. I am a firm opponent to Six-Sixma (except in manufacturing to increase yield) because a business needs errors to improve (screw-ups). No errors --- no learning.

It is encouraging to read that you and others seem to share my opposition to rigid, frozen and lifeless development processes. Thanks.

Read it on my iPAD

I haven't really be a religious Wired reader, but I will plug their new layout on the iPAD. Corporate IT developers will increasingly need to learn to leverage such technologies as we see application and media continue to converge.

Partnering rather than outsourcing is the key

Thanks Max,

I am not saying that you can not outsource, or work with SI's to deliver value. But those relationships will be different from the traditional supplier vs customer models. Instead focusing on shared goals, transparent measures and long term objectives. I think we can learn from the idea at Toyota of tier one suppliers, who work very closely with the development and production process sharing in the success and failure of a design. I guess the idea of ONE TEAM !

Of course there still will be some parts of the portfolio that does not require this model of operation. But for the high value, core competencies of the business this model will make the most sense, and will benefit both the new wave of suppliers AND the customers.

Teams are good, but...

Hi Dave, love the ideas her and couldn't agree more. I have worked in teams of people who have worked together in difficult circumstances for many moons and worked well as a team. The area missing here though for me is great management of the team - more than just giving people a room to sit together and drink coffee managers need to understand the blockers and take responsibility for moving them (based on priority & impact). Otherwise the team soon loses its drive.

Teams and Empowerment

A modern management concept should always involve empowerment. Empowerment is not putting in Enterprise 2.0 and hoping that the technology will motivate people to do something. Empowerment is not decisionmaking for everyone. It is mostly about assigning authority, goals and resources on the appropriate level. The process owner has to guide and lead the team, and yes, the team can and should be cross-departmental where necessary. The process owner has the authority to DECIDE HOW to implement the processes to achieve the goals. To make goals and rules work the PO needs to receive a business architecture of data models for top-down transparency. Rather than measurement, the management should utilize VERIFICATION to ensure that goals are met. Verification focuses on perceived outcomes and not numbers or KPIs. It makes no sense to provide KPIs to be measured if they are not connected to leverage points. Too much data will just confuse people. Each process owner needs information that is local, recent and plausible. A simple reporting and voting process provides the transparency for up the line verification.

The question remains hwo to execute such a strategy. I propose it has today be enabled by technology and not some methodology. That has been the focus of my research and product development.

Thanks for mentioning this one

Hi Dave,
Thanks for mentioning this one at the Agile show during our briefing. I have passed it along to some customers. It's a great analogy and Pixar is a great story that is concrete and will resonate with my customers. Nice seeing you at the Agile show. I had to bounce out early to Munich so I wasn't able to see your presentation on Friday. Was it a good one?