Can Artists Be Agile?

There is a lot of conversation about agile methods lately.  Buzzwords like Scrum, Kanban, sprints and daily stand-up meetings are tossed around endlessly.  Most of the conversation revolves around how programmers and engineers have clearly found some benefit in applying these practices to overcome the uncertainty and complexity of creating technology.

But how can agile benefit creative side of product development?   Is there any benefit from agile for artists, designers, musicians and all the other creative disciplines?

This article provides a simple introduction to agile and describes the precedents, challenges and examples for applying it to the creative arts.

What is agile?

Agile is an approach to creating products that has grown in response to challenges the software industry has faced with the emergence of powerful and cheap computers driving the demand for increasingly sophisticated software.  Creating such software is challenging due to its size and complexity and many projects fail to achieve their targets of cost and performance.  As a result there was a drive, decades ago, to do more up-front planning of projects: to write huge requirements specifications that attempted to eliminate the uncertainty of creating software that no one had ever seen before.

Sadly, the result was that even more projects failed.  The truth is that we cannot plan our way out of uncertainty.  Agile practices arose in response with the fundamental principles that uncertainty requires experimentation and that knowledge workers are craftspeople and not factory workers.  They had to use their skills and creativity to achieve something new and not mechanically follow a set of predetermined instructions.

The challenge

The practices of applying agile, commonly labeled as Scrum, Extreme Programming or Kanban, have emerged over the past decade as a way to help teams of programmers become agile.  These practices have been shown to work[1] in improving the creation of new software products and the working environment for programmers.

The challenging question is “can the creation of art benefit from agile practices?”

Precedent

There are many examples of “artistic agility” that go back centuries.

One of my favorite examples of this approach applied to art can be seen in many examples from centuries ago.  Artists were hired by wealthy patrons to paint their portraits.   Like everyone else, a patron is going to be the most sensitive about how his or her head appears in the portrait, and less concerned about anything else.  If they reject the portrait, it’s usually because they don’t like how their head looks.  So an artist would paint the head and leave everything else in the portrait nearly blank.  If the patron approved their head, they would finish the rest of the painting.  If they rejected it, then the artist would start a new portrait, but they would have wasted little paint and time.

This is the same approach that agile practices take; to create the most important bits first and judge where the product is heading before taking the next step.

Figure 1 - A partially complete portrait

There are many examples of how successful creative efforts have emerged by course correcting after an early failure.  For example, Pixar reset movies in the Toy Story [2]series because their initial production results lacked enough character development.  

Early creative vision is rarely perfect.  It has to be reshaped to some degree.  The fundamental truth is that we can’t plan our way out of uncertainty.  We have to experience the important parts first, whether on a monitor or canvas, and use what we see to steer our emerging plan.

Agile practices for artists

Over the past decade or two, the technical disciplines have invented many agile practices such as pair-programming, unit testing, continuous integration and automated testing.  These practices have greatly helped them improve their agility.  Artists don’t have such an extensive set of comparable practices, but there is no reason they can’t become equally agile as the technical disciplines.

The reason can be seen within the Agile Manifesto[3] — a list assembled in 2001 by some of the leading agile thinkers—which describes the values behind agility:

Manifesto for Agile Software Development

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.

The manifesto seems focused on software development, but that’s because the authors were mostly programmers.  The values apply just as well to other disciplines.  Let’s look at the first value, “Individuals and interactions over process and tools” as an example.

Imagine that you are an animator working on a character that has a special physical effect (say stretchable arms).  You’ve received new tech for this effect from a programmer.  So you tune the necessary controls for this new effect and export them.  Much to your surprise, the new effect doesn’t work.  There is a bug.

In a traditional process, you might tell your lead animator about the problem and continue on with other work.  The lead, in turn, will report the bug in a bug-reporting tool or in conversation with the lead programmer.  The lead programmer might then assign the bug to be fixed by a programmer next week (see figure 2).  The next week you receive a new version of the effect and, hopefully, it works.

Figure 2 - A typical hierarchy of disciplines

Does this scenario sound familiar?  If it does, you know the potential pitfalls of such an approach:  the fix might not be what you needed, you had to wait a week for the fix, or it just gets forgotten.

An agile framework, like Scrum, approaches this differently.   Scrum centers around cross-discipline teams who commit to delivering completed features in the order of their importance.  In the example above, a cross-discipline team, which includes artists and programmers, commit to delivering a character with stretchable arms in a few weeks.  When the animator encounters a problem with the stretching technology, they can speak directly with the programmer on the team about the problem.  Because teams succeed or fail to deliver a feature as a team, there is a strong motivation to solve problems fast.  Problems are fixed quickly because the team focuses on the character and not their own set of isolated tasks.

Agile practices focus on delivering value early whether that value is showing a key effect or the head of a subject in a portrait.

Agile artistry in action

The modern application of agile in the creative arts emerged almost ten years ago in the video game industry.  The reason it took root there is simple.  The cost and size of video game projects was doubling every two years to the point where, in 2003, a typical mass-market console game required over 75 people and $20 million dollars to complete.  This was growing larger than most movie budgets and created a lot of risk.  A single game’s failure in the market could put a studio out of business.

The need to reduce risk -- while still exploring creative ideas -- led studios like High Moon[4] to explore agile practices.  The largest part of a video game team consists of artists, so it became imperative to find agile techniques for modeling, texturing, animating, mixing, etc.  Practices, such as “dailies” were combined with Scrum’s “daily standup”.  Small cross-disciplined teams of no more than ten developers slowly formed, whose goals became to demonstrate a character or level of the game that was “more fun than the last iteration”.  When a feature or asset was not as fun or beautiful as expected, plans were altered to change course.

The success of a creative product primarily depends on the talent and imagination of its creators, not the method of development.  However, the introduction of agile practices led directly to a reduction of cost and waste that are typically seen in game development.

Fears

“Could I have worked under a system where there were Draconian controls on my creativity, meaning budget, time, script choices, etc.? Definitely not.” - Michael Mann, Director

A major barrier to finding ways to improve the process of creating assets is with the aversion to process that many artists feel.  Artists often view the creative process as an organic thing that cannot be analyzed, dissected, or reduced to a set of defined practices without killing it.  As a result, they see methodologies as cold instruments from a mechanistic world they don’t belong in.  Experiences with managers who haven’t understood this mindset have further validated this feeling. 

Overcoming this aversion to process requires an understanding of the role of process itself.  Process cannot automate the creation of beauty.  It cannot remove uncertainty without exploration.  It can’t replace communication among a diverse set of craftspeople that must work closely together to create the best results.

Exposing artists to improved practices has to start with a less prescriptive but more visual approach, and lots of communication.

Conclusion

Agile practices work.  They’ve been proven in a wide variety of creative arenas from video game concept development to CG film post-production.  However, it’s not as easy as it might seem.  The means of becoming truly agile does not demand that you must follow practices out of some book.  Agility requires you to adapt your workflow to better inspect your studio’s creative output and react to what is emerging.   It’s about creating transparency, which exposes the daily impediments to creative expression.  Fixing those impediments is up to you and your studio.  It results in a better environment to work in, but it’s not easy to get there.

[1] http://www.versionone.com/pdf/2010_State_of_Agile_Development_Survey_Results.pdf

[2] Toy Story (10th Anniversary Edition) - (Filmmakers Reflect) (DVD). Walt Disney Home Entertainment. September 6, 2005.

[3] http://agilemanifesto.org/

[4] http://highmoonstudios.com/