Boyhood, the movie everyone was talking about at the end of last year, and which took Best Picture at the Golden Globes, helped me understand some key Lean concepts as well as the importance of taking a more holistic view on software delivery. Here’s how.
12 Years From Concept to Cash
One of the most interesting things about the movie is that it took 12 years to make it. Director and Writer Richard Linklater wanted to capture the characters growing and evolving throughout all these years. This intrinsic characteristic allows us to watch Mason, the lead character, mature from a six-year-old into a college freshman.
If we look at this movie as a project we can see that it started in 2002 and it was delivered to production 12 years later. Looking from the perspective of the film's distributor and producers, who invested US$ 2.4 million, they started spending money in 2002 and had their return in 2014. [From Concept to Cash took 12 years - explained by Mary and Tom Poppendieck in their book Implementing Lean Software Development.]
39 Shooting Days, A 4,200-Day Production Schedule
Boyhood was shot for 39 out of the 4,200 days during all these years. Every year they would shoot for a few days and wait… and wait… and wait…
Development effort is one of the many steps in software development, like shooting on the process of making a movie. If you have been on a software delivery project, you know that there is a lot more involved other than just writing code. Not to mention all the wait time, which is caused by system's delay, one of the 7 Lean Wastes.
I can imagine Linklater on a stand up meeting for the Boyhood Project being asked how the project was going:
"I'm waiting for my characters to look older so I can shoot another scene."
On real world software delivery team we have many events that make us wait:
- "We are waiting for the definition of the XML schema"
- "We are waiting for the results from our UX research so we know what to implement"
- "We are waiting for a decision that needs to be made by our portfolio manager"
- "We are waiting for the firewall rules to be applied to our testing environment so we can test"
- "We are waiting… waiting… waiting..."
The image below expresses the analogy between the waiting periods for the movie and on software delivery.
All these examples of things that make us wait on projects are real and almost impossible to prevent. What we can do is behave differently when they happen to reduce their negative impact.
Unpredictability Requires Trust and Humility
Boyhood began filming without a completed script and Linklater said it had taken him two to three years to finally know and visualise how the movie would end.
PDCA Cycle - Lean Enterprise
In this Lean Enterprise keynote, Gary O’Brien and Barry O’Reilly explain the importance of Deming's PDCA Cycle (Plan-Do-Check-Act). Boyhood was actually planned in a PDCA way, perhaps inadvertently. Linklater started shooting and adapted his script as he went. If you have ever joined a software project that knew their "last shot" from the beginning, please raise your hand - or better, write a comment below, I want to know in what universe you live.
Here is part of the speech given by Boyhood producer Jonathan Sehring when they won best film at the Golden Globes:
"When he (Richard Linklater) came to us with this project, we said yes, the man has such humanity. He's so humble. He put so much of his own life into this movie"
In the software development world, we call our producers The Business. Having a relationship with them where we, as delivery teams, can get a buy-in on getting started, seeing how things go, re-plan accordingly (even pivoting if necessary) is not easy. It requires a level of trust and humility expressed by this speech. It would not have been possible without Sehring’s trust in Linklater, which teaches us a lesson that building this trust is a huge first step towards success on our software projects.
What movies have affected you in how you view your role as technologist?
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.