Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration by Ed Catmull has been on my reading list for an embarrassingly long time. It’s one of those books that everyone in both the creative and tech worlds raves about. Well, I finally made time to read it. Despite its length and age, it is a refreshing view of management. And the parallels between how Pixar works and how software is built are uncanny.
I expected a book about creativity and storytelling. What I got was essentially a masterclass in agile team management, written by someone who’s probably never read The Scrum Guide.
If you work in agile software development, or if you’ve spent any time with Scrum, Kanban, or modern product thinking, reading Creativity, Inc. will feel like a strange kind of déjà vu. The practices that Ed Catmull and his teams developed at Pixar (and later Disney Animation) to make some of the most beloved films in history map almost perfectly onto the principles and constructs that the agile software world has been championing for decades. They just called them different things. Today, I’ll walk you through some of the most striking parallels between Pixar’s processes and agile software development.
The Dailies → Getting Feedback
One of the most important cultural rituals at Pixar is something they call “dailies”. Every day, animators show their work-in-progress to the rest of the team for feedback and discussion. This is unfinished, rough, and imperfect work, the kind that most of us diligently hide until someone forces it into the light. The entire point is to normalize incompleteness, share work early, and course-correct before you’ve gone too far down the wrong path.
Most of us will immediately see a connection both to the Daily Scrum (or daily standup) in the Scrum framework and demos each sprint. The Daily Scrum is a short daily meeting where the team inspects progress toward the Sprint Goal and adapts the plan as needed. Demos occur at the end of each sprint (typically every couple of weeks) when teams show each other the valuable, working code they finished that sprint. The underlying principle is identical: small, frequent check-ins prevent large, expensive mistakes. While the length of the meetings may be different (dailies sound like they last quite a while, whereas stand-ups take less than 15-minutes), that daily connection with your teammates is invaluable.
But the more important parallel, in my opinion, is that what Catmull understood intuitively (and what agile figured out in software) is that waiting until something is “done” to share it is one of the costliest mistakes a team can make. The dailies weren’t about showing off. They were about transparency and the kind of psychological safety that makes people willing to show imperfect work so they can get real feedback. In software, that’s iterating and releasing code that’s imperfect in order to get valuable feedback from users. These are core agile principles, the kind that I am constantly trying to drive home with my Capstone students. How do you know you’re creating something of value? You show it off and you get feedback.
Popsicle Sticks → User Stories
Here’s one that made me laugh out loud in recognition. Catmull describes how at one point Pixar tracked the work involved in producing each movie using popsicle sticks with each stick representing a person-week of effort. The sticks gave the team a visual, tactile, honest sense of how much work remained and whether they were on track.
In agile software development, we use tools like JIRA or Linear to track sprint-sized tickets (sprints often last 1-2 weeks) representing work that creates end-to-end value for our customers and we call these user stories. We estimate our work using relative estimation, or story points, but teams often end up figuring out intuitively how much work they can get done in one sprint.
Instead of popsicle sticks taped to the wall, we have sprint backlogs with “popsicle-stick” amounts of work that the team tracks throughout their one or two-week sprints. The mechanism is different, but the intent is almost word-for-word the same: give the team a shared, visible language for sizing work that doesn’t get tangled up in the politics of “how many hours will this take”. Both popsicle sticks and user stories are about creating a common, low-friction way to understand scope and make better decisions about what to take on. They allow us to have conversations about the work that needs to get done and what that really entails.
What strikes me most about this is that Pixar invented this on their own, out of necessity, before most software teams had adopted story point estimation. The problems of knowledge work (how do you estimate creative output? how do you know if you’re on track?) seem to be universal, and the solutions people arrive at independently tend to look remarkably similar.
Limits → Work In Progress (WIP) Limits
Catmull is very candid about how Pixar learned, sometimes painfully, that trying to do too much at once is one of the fastest ways to undermine quality. At various points in the company’s history, leadership had to make hard calls about how many films to have in production simultaneously, how many projects a director could be involved in, and how to protect the team’s capacity for the work that mattered most.
In Kanban, a very lightweight agile framework we use in the software world, this is formalized as Work In Progress (WIP) limits. WIP limits are explicit constraints on how many items can be in progress at any given stage of the workflow. The research behind WIP limits (rooted in Little’s Law and queuing theory) shows that limiting work in progress actually increases throughput and quality, counterintuitive as that sounds. In plain language, that means that the more work you have in progress, the slower you tend to finish individual tasks. So, work moves more slowly for the entire team, department, or company.
Pixar arrived at this truth the hard way. Agile gave software teams a framework to implement it intentionally. Either way, the lesson is the same: doing less at once lets you do it better.
Post-Mortems → Retrospectives
After every film, Pixar conducts a post-mortem. Catmull devotes significant energy to describing how hard it is to make post-mortems genuinely useful. For instance, teams naturally gravitate toward celebrating wins and glossing over failures. Pixar had to actively design the post-mortem process to surface what actually went wrong and why.
This is where Scrum has Pixar beat, in my opinion. While post-mortems only catch issues after-the-fact, Sprint Retrospectives in Scrum offer a path towards continuous improvement every couple of weeks. At the end of every sprint, the team reflects on what went well, what didn’t, and what they’ll change. And just like Catmull describes, the retrospective is only valuable if the team has the psychological safety to be honest. A retrospective where everyone says “everything was fine” is worse than no retrospective at all.
Catmull’s insight is that you have to make it structurally safe to say hard things. Leadership has to model vulnerability first and this is one of the most important lessons in the book. That advice applies just as much to a software team (or any team, for that matter) as it does to a Pixar film crew.
A Culture of Continuous Learning → Inspect and Adapt
More broadly, one of the central themes of Creativity, Inc. is Catmull’s relentless commitment to building an organization that learns. He talks about the importance of hiring people who are better than you, of creating channels for candid feedback, of treating failure as data rather than catastrophe, and of building systems that surface problems before they become crises. All of these ideas ring true to me, as the agile principle of “continuous learning” is one of my top two favorites.
This is the “inspect and adapt” heartbeat of agile at its most fundamental. The Agile Manifesto’s principle of responding to change over following a plan, and the Scrum framework’s empirical process control (transparency, inspection, adaptation) are all expressions of the same organizational philosophy that Catmull built Pixar around. I’m not sure whether Catmull had any idea what the agile community was doing when he championed these ideas. They’re simply effective ideas and they work across industries.
Catmull didn’t call it agile. He didn’t cite the Manifesto. But he was living it because it made sense.
What This Means for Software Teams
I think there are two takeaways worth sitting with here.
The first is for software practitioners: the practices we use aren’t just bureaucratic process and they aren’t some passing “agile” trend. They are based on the agile principles and these practices solve real, fundamental problems of knowledge work, like estimation, coordination, quality, and learning, that humans across industries have been wrestling with independently and arriving at similar answers to. When you understand why a Daily Scrum or a WIP limit or a retrospective exists, it’s much easier to do them well.
The second is for everyone: if you want to understand agile thinking at a deep level but you’ve found the Scrum Guide a bit dry (fair), read Creativity, Inc. It’s one of the best books on building high-performing creative teams ever written, and it will give you a rich, human, story-driven intuition for why these practices matter that no framework document can. Side Note: It’s also very entertaining to find out what your favorite Pixar stories were like halfway through production. Movie production, it turns out, really needs iteration.
Catmull and his teams were making magic at Pixar. They just happened to be doing it the agile way.