Wednesday, December 10, 2008

Scrum for artists

“Why use agile for art? When Michelangelo painted the ceiling of the Sistine Chapel he wasn’t using agile. He had a plan to paint the entire ceiling.”

These words were spoken by an artist I worked with when we first started using Scrum. Little did I realize at the time that Michelangelo might have been better off using a more agile approach to painting the ceiling. He had no idea about how to painted images on a curved and segmented ceiling. He signed a fixed price contract calling for 12 figures painted. Four years later he had painted 300 figures. There was a great deal of trial and error and false starts. It’s no wonder he referred to it as one of the worst experiences of his life.

Historical accuracy aside, the questions and impressions about how relevant agile or Scrum is for art creation remains common.

The following are common perceptions about Scrum from artists:

Scrum was created for programmers.

Scrum is largely used in software development projects, but it wasn’t created for programmers.

In fact it has no practices specifically for any discipline. Scrum was defined by studying how many different products (such as cameras and cars) were developed. It’s just as applicable for artists as it is for any other discipline.

Art production runs on a schedule. We can’t be iterative.

With video games, art and technology have to serve the gameplay mechanics together to create a great experience. We have to explore how all these components work together to create the best possible experience. Once we discover this, we can schedule making 10 to 12 hours of this experience. Exploring what we need to create before we mass produce assets is beneficial. Cross-discipline teams support this.

Artists often want to work with other artists.

This is the same with other disciplines. They speak the same language. The problem again is that our product requires an integration of all disciplines. This forces some form of collaboration eventually. Unfortunately a studio structured to separate the disciplines (though a heavily matrix management structure for example) will discourage collaboration or at least make it more difficult. If an artist is evaluated by the number of assets they can create (through promotions or salary reviews), then they will optimize their work along this line. Interrupting an artist to help with a game problem will impact the number of assets they can create, so they discourage those interruptions.

Scrum might be good for preproduction but not for production

It’s true that Scrum is better for preproduction than production. Production requires a more defined work flow that must create a fixed amount of gameplay to ship on a specific date. The Scrum practices should be modified by the team in production. However this doesn’t mean we won’t have challenges in production. The game will still continue to throw challenges at us that we don’t expect. These play havoc with the best planned schedules. Artists creating assets will still need rapid response to problems emerging that they can’t solve. They will need to continually find ways of working more effectively through improved tools and pipeline processed.

While the iterative nature of development will slow during production, the need to incrementally improve what we are making and how we are making it will never slow down.

What specific problems are we trying to solve on the art side with agile? How is this going to make better for the artist and team in general?

We need to know if we are creating the right thing and not wasting time.

Parallel development of assets and technology that the assets depend on is a traditional source of wasted effort. Engine development is often started with optimistic feature sets, performance goals and schedules. We can’t simply shift engine development to iterative development without an iterative asset creation effort. Iteration on technology requires an ongoing conversation and experimentation with what looks and works best. Every artist knows that the quality of a complex asset such as a level depends on a tradeoff between polygon count, texture quality, lighting complexity and the palette of effects available. None of these qualities is independent of the others. Some levels will require more effects than others and there will be a envelope of tradeoffs that occur to balance the overall aesthetic.
We want to build the knowledge of these tradeoffs during engine development before we commit to production. This requires daily collaboration between the engine creators and the first order customers: the artists that use the engine.

We need to have a working build.

Nothing will impact progress more than not having a build that fully works. Graphics bugs that impact the visual quality can prevent an artist from fully evaluating their work. What’s worse, addressing these problems can be put on the back-burner by a separate technology group that is solving problems more relevant to their own local needs. Cross-discipline teams are more likely to have someone on the team who can solve the problem or know someone who can.

We need faster tools and pipelines

Artists are often constrained by the limited or slow control they have over the game. There are often barriers to iteration that slow their progress down. Less iteration means lower quality. The fundamental problem is often that the programmers who have control over improving tools and pipelines are not impacted by their limitations. They don’t see how slow it is to change a texture on a game and see how it looks in the game. They are focused on the tasks that are important to their local team.

As with the build issues, having a programmer on a cross-discipline team experience the drag on the team’s velocity that poor tools and pipelines will help solve the problem. Smoothing the entire pipeline from concept to user experience will allow a better game to be made. Cross discipline teams are the best way for this to happen.


Anonymous said...

This is a very good post that I can't agree more.

I've similar experience also encountering that resistance towards scrum usually seems to be most strong amongst graphics artists and designers. When trying to solve the reason in the project I was working, I found out that most often the biggest reason was that when in the sprint planning the team turned to split the backlog items into tasks the discussion often became very technical as certainly there usually is more discussion in evaluation of technical than artistic tasks. When we started to manage planning so that we started splitting items which artists felt to have something to say first and let them leave the planning (with requirement to be available right away if needed) after those were gone through, the main annoyance of feeling time to be lost was removed.

This seemed to cause attitude shift in our case, and even though they still were not as much into scrumming as programmers, the main resistance was gone.

Anonymous said...

"Two artists don't paint on the same painting.". Creativity is something that isn't shared in the same way as code is.

I believe artwork task should be handled differently from other tasks. No matter how Agile and Iterative.

Would someone else have similar or opposite ideas about that?

Clinton Keith said...


We're not selling paintings. We're selling games. This requires collaboration and iteration between all disciplines.

Yes, every discipline task is handled differently. Animators can't create unit tests. Programmers don't have the same subjective quality bar to reach, but the principles are the same.

Anonymous said...

One methodology that cures all, what planet are these people from. Scrum is great for vanilla development projects and not for multi dev languages products, version as well as hard core support from the stuff the bosses bought a few years ago, and no there's no capcity to rewrite it properly.

When the scrum guys can come up some objective measures of success rather than arbitary judgement of their own success then it might be worth reading this stuff.

And now how to play the flute, blow in one end and move your fingers up and down the other. Its all in the sublte art managing people and what motivates then.

Clinton Keith said...

Scrum isn't a methodology. I can't say this enough. It's a framework for how people work together.

"When the scrum guys can come up some objective measures of success rather than arbitary judgement of their own success then it might be worth reading this stuff."

Start reading. One is when income exceeds cost.