Agile & Gaming Companies

Handling rich creative content in a traditional Scrum team doesn’t always work as we might think: a single cross-functional team might simply be too large

28 January 2016
Product Owner, Scrum & XP, agile

In many cases, the artwork and creative elements of a product, such as a game, requires work from many skilled artists, from graphic artists and UX to animators and audio engineers. Creating an art team to deliver art assets, and having them operate as a Scrum team can work. But there can be challenges with this too. In the following article I describe the experience of a gaming company that experimented with art Scrum teams and ended up combining engineering Scrum teams with art Kanban teams. This change was driven by the art team as an experiment, with the clear need to outperform the status quo (an art Scrum team).

Design + UX + UI + TESTIn many Scrum development teams, the design component is included in the team’s delivery. Either stories include mock-ups to be implemented as seen, or the cross-functional team includes a dedicated graphic designer/front-end designer who works as part of the cross-functional team to deliver a working product at the end of the sprint.

For highly creative (artistic) products, such as games, that include a large amount of design work, often equal to or greater than the engineering component, this approach can be difficult for a number of reasons.

  First, the team size tends to be too large. Including art, audio, animation and engineering skills on a single team can lead to a large team, easily in double figures.

  Second, there is often weak dependency between art and engineering. Building out art assets, including audio and animation, has little to do with the engineering components (how the art assets behave or interact) once the core mechanics have been proven (normally with wireframes or concept art).

  Third, conflicting product ownership. The product ownership for art assets is typically owned by the Art Director, while the entire game is owned by a Game Designer or Executive Producer.

While there are many different ways to address this, and ultimately, every product team will experiment to find the way that works for their team, below is the story of one such team, and how they solved these challenges.

A well known US-based gaming company develops freemium games for handheld devices. These games are free-to-play with in-app purchases,  and designed specifically to be played online through mobile devices. One of their game teams, in the final stages of development, were developing against a tight deadline with high expectations on the team.

The team itself consisted of up to 25 developers (engineers, testers) and artists (designers, animators and audio engineers) responsible for bringing the final product together. Initially, the game team split into three Scrum teams, two engineering teams and an art team. While this worked well for the engineering teams, the nature of the work that the art team had to deliver (part concept work, part asset creation, part final asset delivery) fit poorly into a sprint. The art team felt pressured unnecessarily to follow a commitment to deliverables that didn’t match the reality of creative work.

The art team required constant review and approval by the Art Director, with a high chance of considerable change as the entire game design developed with time and functions such as audio or animation, were rarely needed until final assembly. It quickly became apparent that an art Scrum team was not going to work, and rather than persevering at the risk of losing the enthusiasm of the designers, the team was asked to come up with a different approach that had to work as well as or better than the current model. With some guidance, the team identified Kanban as a potential alternative, and decided to try it out.

There are four particular guidelines agreed with the team that enabled this to work spectacularly well.

1  The art team stayed as an art team, meeting every day around the board and sharing successes and learnings together at the Sprint Review. Art skills shared with other game teams were also included in the team meetings as necessary.

2  The Kanban board visualized all the asset work to be completed, and broke that work down into the different stages of development, from concept work to final art to animation to audio to final assembly and integration with the game. This helped team members support one another and stay focused to get a particular asset or deliverable all the way across the board.

3  Work on the board was prioritized according to the commitment of the two engineering teams. That is, the highest priority work was directly tied to the expected deliverables of the engineering teams during their sprints. The art team actively participated in the planning, refinement and standup meetings of the engineering teams, and tracked the dependencies between art assets and engineering stories. The aim* of the art team was to deliver completed artwork to the engineering teams during the sprint so that the Sprint Review included a truly shippable product increment, including engineering changes and complete artwork.

4  The team worked to a Definition of Done for concept work, and a separate, more rigorous Definition of Done for final assembly. This was required to make concept reviews consistent and meaningful, so that a minimum level of content was available.

*This was not a hard and fast rule. Sometimes, there was considerable amount of artwork to be delivered once the engineering was complete - for example, think of the levelling up artwork for a building with seven possible upgrade levels. Each level requires considerable creative work, but little or no engineering work.

The result of Scrum engineering teams working in parallel to a Kanban art team was a Sprint Review every two weeks that delivered a working game (shared across the studio for immediate feedback directly after the Sprint Review). The art team was much more comfortable without the constraints of the Sprint, and able to build their own team dynamics driven by the needs of the game that maintained a focus on deliverables for the game, rather than functional areas of responsibility.

Finally, UX work - designing gamescapes and in-game environments, continued to be delivered in close coordination with the engineering teams, building out concept work ahead of the engineering teams so that the engineering teams knew what to build when they needed to build it. UX work, like architecture, requires a runway. Design work needs to be completed ahead of the sprints in which the concepts are built by the development team. This provides enough time for thoughtful and thorough analysis and, where possible, feedback of concepts or prototypes, before providing the development teams with well-defined concepts to build into the product.

In conclusion, as the level of creative work on a product increases, the structure of the cross-functional teams creating the product becomes less ideal, less likely to follow a single cross-functional team. The creative work may need to split from the engineering work. In our case, the teams evolved how they worked to best suit the skills and temperament of the small, cross-functional teams involved. The guiding framework was a clear focus on the game increment as a final product. Although the art teams choose to work using a different method than the engineering teams, the regular cadence of review was maintained - a game increment produced every sprint that included completed artwork. This resulted in iterative and incremental deliveries, combining work from both Kanban and Scrum teams. Regular delivery of a game increment, not how each team worked, is the defining constraint

Subscribe to new blog posts

Did you find this article valuable? To be promptly noticed of new blog posts by agile42 you can subscribe to our notification system via email.

Discussion 2 Comments

I'm not sure I follow how switching from Scrum to Kanban framework eases the delivery pressure off of the art team. I agree that in certain situations such as creative content development or even software maintenance Kanban is more appropriate than Scrum because there are simply too many unknowns. However, I fail to see how Kanban eases the time pressures on a team.

The way I understand it Kanban reduces the overhead of the Sprint (i.e. less rituals). In the example provided the art team still has to deliver within a certain time frame (before the engineering Sprint starts) so that the engineering teams can integrate with the art team's deliverable and demo at the end of their Sprint.

Could you elaborate more please?

Thanks for your question.

The misunderstanding maybe with how Kanban works compared to Scrum. You mention in your response that Kanban reduces overhead (fewer rituals) and therefore works better. Kanban is actually a fundamentally different approach to the same problem - that of getting work done through focussed effort from a talented team.

In the case of Kanban, the approach is to limit work-in-progress (or limit WIP). This increases throughout because the team focusses on many fewer work items, and can therefore get more done.

For the Art Team, it wasn't fewer rituals that made the work flow more easily, but greater focus (because they only worked on a small number of items at a time, and were disciplined on completing a piece of work before picking up a new piece of work).

Scrum, on the other hand, uses the time constraint of the Sprint to control the focus of the team. The approach is subtly different, but the outcome is the same.

Hope that helps




Refresh captcha


Latest entries

LeSS and DevOps

Large Scale Scrum (LeSS) not only accounts for DevOps, but also builds it into the approach, ...


Scrumtisch October 2017

Scrumtisch Berlin October 2017


Scrumtisch Berlin: August 22nd, 2017

August 2017 meeting of the Berlin Scrum User Group, facilitated by agile42 coaches Noel Viehmeyer and ...


Certified Agile Leadership comes to Vancouver

First part of the Scrum Alliance Certified Agile Leadership (CAL) program will be available in Vancouver ...


Survival Tricks for Remote Developers

Video and slides of the talk presented by Alessio Bragadini at PyCon 8 conference in Florence, ...