Lights! Camera! Software!

I admit to a penchant for analogies and allegories. I’m a self-confessed liberal arts graduate after all.

I once gave a speech at Toastmasters comparing male pattern baldness to urban flight population shifts (the hair moves from the “central core” to the suburbs of the back, ears, nose, and eyebrows). That being said, I think I’m on to something in comparing software development in an agile-transformed organization to the machinations of making and delivering successful feature films. Stay with me here.

I’ve used a movie industry metaphor before when describing what tends to (or should) happen to requirements that are compiled at the start of a project, listed in a project charter or business case proposal document. They end up on the “cutting room floor.” On reflection, there are a number of striking comparisons worth noting between the endeavors of making a movie and making valuable software. When you consider all that goes on behind the scenes to make a successful feature film, the parallels are there for what happens to make “magic-in-a-can” software, especially if the latter is delivered in an agile-transformed environment.

Start at the beginning. Like with software and most any type of project, the movie industry has its holy triangle of Cost, Schedule, and Scope (or Plot), with, of course “Quality” gratuitously emblazoned in the geometry’s center. The filmmaker has an idea and often has a script to go with that idea. That the idea is compelling and interesting to ticket buyers is kind of the universal “business problem” that movie people are proposing to solve. In contrast to software project proposals, the cost of doing nothing is more subtle and only revealed in retrospect, but, on the other hand, most business cases for software have an ROI that is only teased out in hindsight as well, right?

The script could be an original idea, a derivation of other works done successfully, or an upgrade/remake of a proven commodity. Software solutions are likewise a) innovative and ground-up “greenfield” efforts; b) derivations that improve established functions, or c) upgrades to an entity with established value. For b), think “adding machine learning or AI to search engines,” “automating keystrokes,” or “reworks using new user-friendly building blocks (4G languages).” And for c) there are applications that have worked just fine, but they’re written in VB and need to be modernized. Cinematically, when I think ”c),” I think of the movie “A Star is Born,” a classic example of a proven commodity that filmmakers believe needs an update/remake every couple of decades, from Judy Garland to Barbara Streisand to Lady Gaga.

Any way you look at it, the pitchperson must present a package and justify expenditures to the sponsor. Given that the story, or charter, is compelling, the producer is usually on the hook to propose a schedule and delineate needed resources (that is, what the money will buy). Scripts, like large backlogs of user stories at the start of a year-long software project, describe objectives well enough, but there is tacit understanding that the crew and cast will do what makes sense to make the script work. After all, some things look better on paper than in execution. How true is that for many software development projects?

If we applied all the trappings of a waterfall-method project to movie-making, “sticking to the script” becomes a virtue. I’ll grant you that we’ve seen movies that stepped too far off the story and have failed miserably. Think Bonfire of the Vanities, such a bad movie, compared to the book, that it spawned another book and a documentary about what went wrong. But what is usually true is that the script is just a starting point and successful cinema magic making involves continuous improvisation, compromise, and even abrupt, sometimes seismic, changes.

In software, the executive producer is the group of stakeholders who are investing in the outcome to address a justified need that the application can address, or has addressed and needs to continue to do so. The producer might be the Product Owner, their associate producer the software designer/architect. The director is the project manager or scrum master. The editors and film crew are the analysts and testers who shine the light of daily reality on the script that is the backlog. And, I would argue, when creative self-organization, collaboration, and chemistry underlie the effort, the film, er, the software, hits the mark and delivers the value promised when it was pitched, priced, scheduled, and more or less scoped at the very beginning.

The cast logically parallels the development team. As with the movies, there are stars and supporting cast, there are designers, perhaps front end developers, who are prominently associated with the show itself, just as there are vital builders of all the plumbing and back room magic that makes that search engine do new and amazing things ever faster than before. I just read a column about the importance of supporting actors in ensemble shows and movies. Star power can sometimes carry a film, but chemistry is more often the winning formula. Either way, the director will put their stamp and style into the results by the way they foster chemistry and, in no small way, roll with the punches as the cast (or development team) forms, storms, norms, and performs.

Audience screening and user acceptance testing, as well as all types of testing, are always wise before unleashing the production on the buying public. User experience specialists aim for effective cinematography to make the software click with the audience. The value proposition (what is most important) is continuously in play, whether in the editing room or during backlog refinement. Just like scenes get dropped, despite their promise, if they don’t support the film’s narrative, not all requirements in the backlog become reality if, upon scrutiny, they don’t improve on the software’s treatment of the business problem.

Finally, release planning needs to consider readiness of the products’ beneficiaries, like targeting a blockbuster action film to hit theaters in the summer or bold message-driven productions to be released in alignment with the Oscar nomination season.

I imagine that there are a few movies that have succeeded because of religious adherence to a great script, a seminal story, or a transcendent novel. Perhaps there are directors that dictate all that must happen in every scene, or work in an environment where the producer and executive producer want a full-blown cost benefit analysis to justify any improvisation or adjustment to the originally submitted script. And, as with software, there are cases where all involved, including the carefully chosen stars, completely missed the point despite spending tons of money and energy around all that is supposed to wow us as consumers of the silver screen (I’m thinking “Waterworld” here).

But ask any development team if they prefer rigid and sequential building of applications, based on a distant and thick set of meticulous specifications, over collaboration with the business to deliver what is truly valuable and making the adjustments, through continuous inspection and adaptation, to deliver software in the most elegant way that is financially feasible. To understand why you should guess that the latter is true, think of the Oscar acceptance speech. You know who the star is, maybe even the director, but from acceptance speeches you also hear a list of names of whom you’ve never heard of who “made it all possible.” So too would the software development team prefer Inspection, Adaptation, and Transparency in a collaborative setting to get the most satisfaction, and provide optimal customer value, when the credits roll. **

**As a postscript, I would like to acknowledge and thank Ryan Abrahamson, a senior developer from my company who is surely the equivalent to a movie star when it comes to making great software, for the idea and inspiration to write this little polemic. Lights! Camera! Software!