I recently had the chance to watch The Director and the Jedi, an extraordinary documentary about the making of Star Wars: The Last Jedi, and one thing was very clear from the film: Director Rian Johnson deserves a standing ovation.
While there might be some of you out there that feel like the film didn’t live up to the holy standards of The Empire Strikes Back (because it didn’t), it’s hard to argue that it wasn’t a successful movie. (It’s the 10th highest grossing film of all time for crying out loud.) So putting aside criticisms of the film itself, Rian Johnson deserves a round of applause because of the sheer amount of effort that is required to pull off a film like Star Wars.
The variety of decisions and coordination seen in the documentary is almost indescribable — From planning when and where every single shot will be filmed, to coordinating the helicopter ride of an 18-foot animatronic puppet on the side of a cliff, to looking over every detail for every costume and creature at a massive casino party in what Rian described as the most complicated shot in Star Wars history.
In addition to the number of decisions that Rian had to make, I couldn’t help but be impressed by his confidence in his vision of the film. Before The Last Jedi was released, Mark Hamill, who plays Luke Skywalker, was completely against Rian’s take on his character - saying that he “fundamentally disagrees with virtually everything written about Luke.” And this tension permeates the documentary. But despite the attempts by Mark to change his mind, Rian held firm. His overall vision for the film was rock solid.
So what the heck does Rian’s impressive endeavor to make a Star Wars film have to do with agile design?
Well, after watching the entire design process for a major film, it became pretty evident just how different that process is from what happens in most tech companies today. In software, you have the chance to iterate with typically few irrevocable deadlines and the opportunity to decide what to build next on the fly. Most teams create a minimum viable product and then make improvements based on feedback. This is very different than the design team on a major film working towards one final deadline where they reveal the entire product to everyone at the end - and with that deadline, no chance to make subsequent changes or updates.
After this realization, I was tempted to conclude that the film design process is simply behind the times and that they need to follow a more agile design process; but when I thought back to my previous experiences as an architect, I could see similar constraints. Architects, just like film directors, also have to design towards a single deadline. In architecture, we haven’t gotten to the point where it’s cheap enough to build just a small portion of the building, see if people like it, and then build the rest. And in the film industry, it’s not possible to release a film to the public, see what they think, and then make any improvements to it. Once the film is out, it’s out. And once the building is up, it’s up.
This gave me pause. If we consider great films and great works of architecture to be some of the best designs of all time, but yet they weren’t created with an agile design process, then maybe there’s something to learn from this. Put another way: what positive aspects of Rian’s process aren’t present in most agile design processes?
Looking at Rian’s process, the answer is pretty clear: More often than not, software teams are missing the unwavering vision of the end product, like we see Rian had for the Last Jedi. This lack of big-picture thinking - combined with the ability to change course throughout the design process - is the biggest problem agile design today. We’re overwhelmed and all over the place.
Don’t just take my word for it. Ryan Singer, head of product strategy at Basecamp, recently got a lot of love on Twitter for this tweet:
Typical software company: 1. Backlog of stuff somebody decided the team should do -> 2. “Product” role who is really just a project manager -> 3. Designers and programmers overloaded with ill-defined work being asked to work faster and faster instead of smarter. - @rjs
What Ryan is describing is the all-too-familiar design process where we listen to whatever feedback we hear and attempt to solve every problem. A major customer has a feature request, so we add it to the backlog. Someone on the sales team thinks we need another feature to compete with a competitor, so we add it to the backlog. We realize there’s a usability issue with a previous feature we developed, so… we add it to the backlog. And the scary thing is that all of these features are in different parts of the product, leading to rushed and underwhelming features in a bunch of different directions.
Now I can hear the lean advocates out there: “But that’s the point! We’re able to give our users exactly what they want, because we develop just a little bit, see if it ‘works’, and then develop some more.” And that’s exactly right. I, too, am a huge advocate for this type of thinking. But the problem is how we define the word ‘works’. ‘Works’ shouldn’t just mean we fulfilled the request. It needs to be: are we moving in the right direction. My point is that this process often lacks an overall vision, creating Frankenstein software as opposed to a final cohesive and polished product.
It’s time we acknowledge the downsides to continuously changing directions as we work at breakneck speeds.
The dilemma: is it possible to have the best of both worlds?
Is there a way for film and architecture design processes to incorporate some of the agile methodologies in order to get more accurate feedback before their final release? And is it possible for agile software companies to create one cohesive design where all of the details point to a single vision?
MVP Film & Agile Architecture
Looking at the advances in technology, not only is it possible, but we’re already starting to see hints of it happening in both the film and architecture industries. These design teams are starting to incorporate agile methodologies in order to get better feedback. For major films, some teams are starting to animate portions of the movie before they film the real shot; and soon this concept will be pushed further. They’ll be able to quickly animate the entire movie - with voiceovers and all - in order to see what shots they need and what shots could be cut before any sets are even built.
And in architecture, virtual reality now allows architects to create renderings to showcase designs from every angle. And soon enough this will progress to the point where architects will create the entire building in VR so that clients can step onto an omnidirectional treadmill, walk around the entire building, and interact with everyone else in the space.
Big Picture Software
For software, our problem is the opposite. For decades, we’ve been able to quickly change directions, but this has stalled thinking about the product from a big picture perspective. Luckily it’s completely within our power to change that.
In order to fix this problem, agile design teams must:
- Commit to one direction (and maybe even long-term target dates!). We need six-month goals, year-long goals, and a five-year plan. These overall visions must be shared by everyone in the company. We can’t have developers that don’t understand why we’re doing something, and we can’t have members of the sales team committing to features that aren’t part of that shared future vision. Everyone needs to believe in the plan and commit to it.
- Stop chasing every last golden unicorn that flies by. The next step is to actually follow through on that commitment. Just because there’s another opportunity that could be valuable doesn’t mean we should go down that path. If everyone in the company is truly aligned with the long-term goals, then it should be clear which features are part of that plan and which features are distracting.
- Create a process for determining if you should change course. The best part of agile development is that if our users aren’t getting value out of what we’re creating, we can change course. So we shouldn’t be creating these long-term plans without the ability to change course. This means everyone needs to come up with and agree upon the criteria for changing course. Just because some big client wants something doesn’t mean we should do it. Look at the constitution. Its overall vision hasn’t changed too much, but there’s a clear plan in place for making amendments.
- Finish up the important details before moving on. One of the reasons major films and great works of architecture are great designs is because their small details serve the overall vision. In agile design, these details normally get pushed aside for the next major feature. But if we’re committed to long-term plans, we can get these details right before moving on.
- Celebrate the big accomplishments. When we achieve one of these long-term goals on time, we need to all celebrate together. Watching the entire cast of The Last Jedi get together for a final photo-shoot was incredible. The feeling of pride and joy was contagious and inspirational. If we don’t take the time to celebrate our accomplishments, then we’re at risk of falling into a feature death march.
The agile design process has a lot going for it. The speed at which we are able to develop real solutions that solve real problems for real people is amazing. But just because we’re following the agile design process doesn’t mean that we’re going to be successful. We have to take a step back and make sure that we’re heading in the right direction. The greatest innovators of all time had bigger visions than any one person they were designing for. It’s time to commit to a big vision and stick to it — even if that means telling Luke Skywalker he’s wrong.
