Skip to main content

Creative Agility

Article

Creative Agility

Better Software Magazine Article by Clinton Keith | Comments: (0) | Tue, 02/07/2012 - 12:45
Summary:

Many new products being developed require the contribution of artists and other such "creatives", but 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. This article explores barriers such as these to the introduction of agile methods and how these barriers can be overcome.

More than ten years ago, a small gathering of authors and consultants published the Manifesto for Agile Software Development, which launched the agile mindset into wider adoption and acceptance. The "world of work" has benefitted from the applied values and principles of agile—to improve new product development and respect those creating them.

Progress continues on improving agile practices, but that progress has been largely focused on software development. This has helped keep pace with developing technology for the unceasing advances in computing power, graphical tools, display resolution, and the miniaturization of powerful ubiquitous devices, such as smartphones and tablets.

The advancement of technology has also created an insatiable demand for beautiful content. Nearly all the movies we see now apply computer graphics and also use sophisticated software for production. We’re entering an age where design and content are as important—if not more so—than function. We can no longer afford to “skin” our software with a pretty interface after the fact. Artists and designers—the "creatives"— are becoming overwhelmed by the growth in complexity and demand, but they lack the agile tools that have benefitted software developers over the past decade.

This article explores the barriers and solutions to "creative agility" based on twenty years of experience building art- and design-intensive products. It introduces approaches that are similar to those used for agile software development, as well as new ones that expand the realm of agile development beyond software.

Background
In 2003, our video game development studio adopted agile practices because the complexities of video game development were growing beyond our ability to manage using traditional processes. By comparison, a decade earlier, ten or fewer people could make a game in half a year at a cost of a quarter of a million dollars. By 2003, the costs had risen by a factor of forty, team sizes were well over 100, and games required years of development. The reason was simple: The hardware platforms continued to follow Moore’s Law [1]: doubling in speed, memory capacity, and graphics realism every two years. Whereas in 1993, a bunch of brightly colored cubes were enough to represent a world, in 2003, we had to rival reality. That fidelity required many more content creators with a much higher degree of craftsmanship.

Our engineers immediately benefitted from the many tools and shared experiences about how to iterate and discover value. They could surround their code with unit tests, pair program with other engineers, and automate early, deep testing of their code to reduce the debt of uncertainty. However, for texture artists, modelers, musicians, animators, designers, and other non-engineering specialists, few such tools existed. There was little in the way of "creative agility" for them to draw upon. They relied more on big up-front plans to tell them how much content needed to be created over the coming years and suffered the most when those plans inevitably proved wrong.

The creative specialists also expressed a great deal of skepticism and resistance to agile. Art was considered abstract and beautiful in its own right; how it survived the technological filter and appeared to the user was considered the responsibility of the engineers. This resistance came to a head one day when our lead artist claimed, “Michelangelo didn't need to be agile when he painted the Sistine Chapel.” However, it turns out that Michelangelo’s project to paint the frescoes might have benefitted from some agile practices. Michelangelo encountered two major problems: He had no prior experience painting frescoes in a chapel, so he was unable to estimate the work required, and the scope of the work increased dramatically from the twelve figures he was originally commissioned to paint to the more than 300 he eventually completed.

Uncertain solutions and scope are common problems that developers face today, which lead them to apply agile. The wisdom of answering uncertainty through early iteration and discovery is universal to all areas of creation, not just engineering.

Barriers to Creative Agility
The barriers to agility for the creatives have much to do with fear and the differences in their approach to creation. Some of the fears are not unfounded. Applied incorrectly, an agile approach to the creative arts can destroy vision. For example, the “prioritized scope” or reductionist approach to software feature development does not match the need for holistic creative phases. For example, a movie story line, written up front, is necessary before principal photography begins. However, this strategy of “not knowing the true value until it's complete" has proven disastrous to quality, budgets, and schedules far outside the confines of fresco painting on a chapel ceiling. Think about movie box office bombs, such as Waterworld or Heaven's Gate. The need for a holistic view has to be balanced against the need to address uncertainty through experience, not conjecture.

The medium of artistic expression has become complex, as the fixed canvas has been replaced with silicon chips and LCD displays. In addition to production costs and schedules, we now have memory budgets, rendering constraints, and interactive aesthetics, which heavily influence what an artist can create and how he creates it. The stereotype of the lone artist suffering in isolation and poverty to bring his vision to reality is changing. The modern artist has to explore and collaborate with specialists and deal with constraints that were utterly foreign to him in the past.

The canvas of constraints

When forced to work within a strict framework the imagination is taxed to its utmost—and will produce the richest ideas. Given total freedom the work is likely to sprawl.—TS Eliot.

Today's artist is often faced with constraints that were unimaginable a century ago. These constraints create barriers to the expression of the artist’s full craftsmanship. A modele cannot express the full beauty and form of the human shape when she is limited to a few thousand polygons with which to draw them. A color palette or image resolution limit for a website will compromise what an artist wants her visitors to experience.

Constraints are nothing new. Michelangelo faced the constraints of painting frescos upside down on an uneven ceiling, and today's artists face constraints that are similar, yet far more uncertain.

Overlapping specialization
Closing credits on computer animated movies list armies of specialists. These include engineers who specialize in shading a bedspread on which a toy character sits, animators who specialize in the motion of fish, and artists who fine tune the millions of strands of hair covering furry monsters. It's interesting to compare these credits with those of the classic Disney movies. The classics required a magnitude fewer specializations than current movies because the progress of tools, technologies, and processes have given rise to capabilities for telling stories that weren’t dreamed of during the era of handdrawn animation.

With this rise of specialization came a corresponding rise of complexity. A modern film director can no longer fully understand the necessary art and craftsmanship of every specialist working for him. This complexity emerged not only from the overwhelming amount of knowledge required but also from interdependencies among all the specialists. Getting a monster's hair just right requires an interplay of physics, lighting, rendering, and animation behaviors. The desired result emerges from a balance among them all.

Process is Evil

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 improving the process of creating assets is 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 that is at odds with an artist's goal to capture and express beauty. Experiences with managers who don't understand 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 who must work closely together to create the best results.

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

Tools for Creative Agility
While iteration and emergence are important, artists often find themselves challenged with the need to repeat the same creative efforts over and over. For example, a sound editor needs to mix the various sound sources or tracks for a television episode every week. This aspect of production, or postproduction, imposes limits on schedule and cost that must be met. Production can be better estimated because it has been done before and is more predictable, but not perfectly so. Variations in content continually challenge both schedule and budget. All the while, new tools and processes emerge offering improvements in productivity. These dynamic, opposing forces create the need for an artist to continuously revisit how he works.

Artists often find themselves transitioning between preproduction, which emphasizes finding beauty while discarding that which isn't, and production, which emphasizes economy of scale and eliminating wasted effort. For artists, knowing what state they are in and switching between the tools of each is a challenge.

Exploration Tools
Creating assets without a full understanding of constraints can lead to a lot of content that cannot be used or that must be heavily reworked. In reality, creative constraints have to be discovered through exploration before realistic product goals can be established. A core lean principle referred to as "deferring commitment" is a useful tool. Because we can only reduce uncertainty through demonstration, we need to defer decisions about production as long as we can responsibly defer them, to a time when better-informed decisions can be made.

This requires preproduction to be focused on collaborative exploration rather than efficient execution of a plan. This is what agile tools are designed to support.

Collaboration over handoffs
The agile manifesto proclaims "working software is valued over comprehensive documentation." This has been misinterpreted as meaning documentation is evil, but this is wrong. Documentation is an effective way of recording what is known, but it's less effective as a planning tool for exploration because, through the magic of human nature, when a speculative solution is written down, it somehow becomes gospel.

This documentation problem is prevalent among specialists in the form of "handoffs." Engineers write technical specifications, writers create scripts, concept artists create storyboards, etc. Each of these different forms of documentation is handed off to the next specialist down the line. The insidious problem with handoffs is that accountability for the final results is handed off as well. If the product fails, then some specialist downstream is blamed for failing to implement the vision embedded in the handoff. However, this is like blaming the canvas or the paint for the ugly painting.

Collaborative exploration is a better tool than handoffs. When teams of specialists inspect an emerging product and engage in an ongoing conversation about improving it, they'll make a better product. Accountability emerges from everyone.

Moving from handoffs to higher levels of collaboration is a challenging and slow cultural shift. It cannot be forced by a management dictate. It must evolve from a shift to shared goals and a commitment to those goals that leads a team toward higher levels of collaboration. One way is through the Scrum framework, which focuses on cross-specialist teams demonstrating improved value every few weeks. These crossdiscipline teams commit to goals such as "prototyping a new customer account web page," which requires UI designers, web artists, and engineers to collaborate. These teams commit to a common, committed goal with the stakeholders. As a result, roles begin to shift. For example, a UI designer might trade a few hours’ time, which was previously spent creating finely detailed screen mockups, to sit with a web artist iterating on the actual running interface. This turns out to be far more effective than ripping apart a completed interface months later when the users suffer from unforeseen usability problems.

Cross-discipline knowledge
With heightened collaboration comes an increasing level of understanding of the needs of different specializations within the team. This doesn't mean that a musician will learn how to write code (although that does happen). It means that conversation improves a specialist's understanding of the needs of surrounding specialists. This can have a dramatic effect on his work. One example is of a concept artist who used to create a dozen drawings to represent scenes of cities to be built for a video game. He spent months creating a dozen pieces of concept art for each of the cities. Halfway through this effort, he learned two disturbing things: First, one third of his concept art had been discarded due to budgetary limitations, and second, the artists building the cities ignored another third of his art. He was told that the ignored art displayed large open areas through which the artificial intelligence technology could not navigate. The original technical specification had predicted this would not be a problem, but that prediction was wrong.

Later, the team adopted Scrum and formed cross-specialist teams that included the concept artist. He began spending a few hours a day sitting with the level designers while producing fewer pieces of concept art. The quality of the cities greatly improved through collaboration, and the need for fewer drawings reduced their cost.

Production tools
Once the critical constraints are established, many projects will shift into mass production (or post-production) of content (multiple characters, textures, models, soundtracks, editing, etc.). Because the constraints are better known, the work becomes less about exploration and more about finding efficiencies in the flow of work. There are a number of well-established tools that help teams do this.

Lean and kanban
It's not uncommon to find art production processes that resemble the discredited Henry Ford assembly line philosophy from a century ago. This is characterized by breaking down the creation of beautiful pieces of art into the smallest set of highly specialized tasks, which are assigned to "workers who repeat the same mundane tasks day in and day out. These workers have little understanding of the final product until it emerges. The drawbacks of this approach are the same as those seen by industries that began abandoning the practice decades ago: Placing accountability for quality and process entirely in the hands of management bypasses the value of everyone working “on the line.” The "lean revolution," which had its roots in manufacturing, established that the people closest to the work will often have the best ideas for improving quality and reducing cost if they are given trust and respect and they are truly accountable for the whole product.

Some art production studios have begun to explore and apply the principles and tools of lean (including kanban and critical chain management) with the same success. These tools focus on the whole product and a collaborative flow toward its creation.

Kanban practices focus on visualizing and guiding the flow of valuable assets—such as levels for a video game or a script for a television show—step by step from concept through delivery. One such visualization takes the form of a"kanban board" that allows a team to manage the flow of work, spot problems quickly, and measure the impact of improvements [2].

Like most agile practices, kanban creates transparency, which allows the creators closest to the work to make decisions on how to improve not only their own work but also their collaboration with others around them.

Conclusion
While the agile practices that engineers enjoy using aren't as well established for creatives, the principles and values behind them remain the same. Those principles are based on the understanding that complex new products are best created through collaborative discovery. While it may be challenging for specialists to understand how others work, embrace collaboration, and see the whole product emerge, there is great reward in doing so.

References
[1] Moore's law

[2] The details are beyond the scope of this article, see Further Reading for more information about kanban.

[3] Figure reprinted from Agile Game Development with Scrum, by Clinton Keith, 2010.

Further reading
Keith, Clinton. Agile Game Development with Scrum. Addison-Wesley, 2010.

Anderson, David. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010

Files: 
No votes yet
About The Author: Clinton Keith

Clinton Keith has gone from programming avionics and other software for advanced fighter jets to overseeing programming for video games. He is currently the chief technology officer at High Moon Studios, a video game developer in Carlsbad, CA. In his video game career Clinton has developed or directed development on titles such as Midtown Madness, Midnight Club, Smuggler's Run, and Darkwatch to name a few. Prior to developing games, Clinton served as software engineer on undersea technology at Raytheon and on the YF-23 and YF-22 avionics for TRW.

Comments

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

Type the characters you see in this picture. (verify using audio)
Type the characters you see in the picture above; if you can't read them, submit the form and a new image will be generated. Not case sensitive.