Accidental Agility

Today marks the 18th anniversary of the final day of the meeting at Snowbird which ultimately lead to the creation of the agile software development manifesto. If it were a person, it’d be at the legal drinking age (here in Australia). And it has a lot to celebrate, it’s come a long way in that time. What started as scribblings on a blackboard in a meeting of seventeen programmers has since grown to take the business world by storm. Some would even say it’s grown out of control (some of the original authors, no less).

In this post, I want to rediscover the essence of agility by looking at an example of an industry that exhibits the principles outlined in the original manifesto, despite not even being aware of it. This essentially means that they have independently discovered the ideas of agile development, but because they missed the surrounding hype, they’ve managed to avoid a lot of the unnecessary baggage that tends to follow “Agile” in practice. My goal is to make people refocus on what is really important and valuable about agile software development, and see past the noise that has built up around it.

So first, let’s just remind ourselves of the original text in the manifesto.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Some of these points are quite specific to the software industry, so in order to think about these ideas in the context of another industry we need to peel back that specificity and get at the more general concepts underneath. Let’s look at each clause.

• Individuals and interactions over processes and tools: It’s more important to hire the best people and give them the freedom to explore and be creative, than to define guard-rail processes that try to guide people towards “the right thing.”
• Working software over comprehensive documentation: Value and the measure of progress are both defined in terms of working “product” in the hands of your users, whatever that might be in your case. The philosophy of delivering value early and often follows on from this, and one of the key benefits is that the project still delivers value even if the deadline is not met or cut short.
• Customer collaboration over contract negotiation: Your customer requirements will change over time. This isn’t necessarily because they’re fickle, it’s purely because it’s not until you get “product” into their hands that they know if it’s any good. You need to work with them rather than trying to force them to freeze their requirements.
• Responding to change over following a plan: If the above change wasn’t enough, the environment is changing around you all the time. Budgets change, timelines change, your team changes, the world changes. The unknown unknowns will kill you if you aren’t flexible to change.

Now, keeping this all in mind, I want to take a look at the film and TV industry by trying to re-interpret the manifesto in this context.

• The first clause can be interepreted to mean that the talent is more important than the formula, and we see this play out where B-grade shows and movies tend to follow fairly formulaic plots whereas A-graders tend to rely more on hiring the biggest stars and giving them a bit more creative licence to influence the characters or the story.
• The second clause can be interpreted to mean that no amount of gut feel or market research will tell you which scripts are going to be winners, you need to produce something and let the viewing public judge for themselves. This is why TV shows have pilots, and why TV and movie series are renewed in pieces rather than backed for their full runs initially. Another benefit of this approach is that the profits of one season or film can be re-invested to fund the next.
• The third clause is almost non-applicable in its obviousness. Production companies can’t negotiate with their customers—the audience—they can only create a two-way “dialogue” whereby they produce content and the audience provides feedback, in the form of tweets and dollars at the box office, which then feeds back into the production of the next installment.
• The fourth clause can be interpreted exactly as is. The only constant is change. Your cast will change, your crew will change, audience tastes will change, the characters will change. I’ve never heard of a TV show that was able to successfully plan out the plot for the entire run before producing the first episode, and actually stick to it, and you’d be crazy to try anyway. Hell, they planned to kill Jesse Pinkman in season one but thankfully changed their minds on that one.

One thing that’s interesting to note about this example is that it doesn’t require that individual films or TV seasons be produced using typical agile process. Instead, the philosophy of agile software development is being used as a higher-level process. If you translate this back to the “real world of Agile”, we actually see parallels with Scrum. A sprint is not far off a mini project, deliberately scoped to a small timebox to reduce the amount of contained risk and then planned up-front, with parts of the agile philosophy only really applying at the level above this in the transitions between sprints.

But it’s important to remember that the mere act of breaking work up into sprints isn’t inherently agile. The benefits come from delivering working software at regular intervals, getting feedback from customers or users, using that feedback to course-correct from the next sprint onwards, and taking a moment to reflect on your work processes and whether they are helping you to get the best out of your team. It’s all too easy to blindly cargo cult the day-to-day activities of “Agile” and think that the benefits will naturally follow, allowing the day-to-day activities to become the goal. They aren’t the goal, and it always helps to look to other industries for inspiration on how they are solving the same set of problems.