“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.