Jan. 28, 2016

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

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

Image of davesharrock

Dave Sharrock

Agile coach passionate about getting things done; helping teams exceed expectations, delivering organizational excellence, and all while having fun doing what they do.
Image of mvonweis

Martin von Weissenberg

Martin helps people understand agile and lean thinking and coaches teams and organizations in the use of agile methods and practices. He is a Scrum Alliance Certified Enterprise Coach (CEC) and is working on a PhD on how to manage and organize for agility.
blog comments powered by Disqus
Image of davesharrock

Dave Sharrock

Agile coach passionate about getting things done; helping teams exceed expectations, delivering organizational excellence, and all while having fun doing what they do.
Image of mvonweis

Martin von Weissenberg

Martin helps people understand agile and lean thinking and coaches teams and organizations in the use of agile methods and practices. He is a Scrum Alliance Certified Enterprise Coach (CEC) and is working on a PhD on how to manage and organize for agility.

Latest Posts

Making Diamonds from your Retrospectives - The Diamond of Participatory Decision Making

As a retrospective facilitator, there are many insights and techniques that you can draw from the Diamond of Participatory Decision Making. 

Image of lklose

Lukas Klose

Article in Creditreform Magazine: Agility and organizational transformation

agile42’s Marion Eickmann, scientists, and business leaders weigh in on agility in an article published in the June 2018 issue


Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.

Agile in Everywhere: Memories of a beginner-level Scrum servant

This is a story of a NGO adopting Agile principles and implementing Scrum in a non-IT context in Turkey and Scrum journey, from their perspectives

Image of aslis

Aslı Silahdaroğlu Bekmen

We are an independent humanitarian organization founded with the principle aim of helping disaster-affected communities meet their basic needs and rights. We are conducting our activities since 2005 with principles of humanity, impartiality, neutrality, independence and accountability.

Discussing large organizations in an Agile HR world

Peter Hundermark presenting a case study about a major agile transition at HR Goes Agile conference in South Africa

Image of peterhundermark

Peter Hundermark

Peter has worked with iterative and incremental software development processes since 1999, focusing on Scrum and Agile practices since 2006. In 2007 he started Scrum Sense in South Africa. He has introduced Scrum into scores of development teams locally and in Brazil. He leads certified Scrum training classes in South Africa and elsewhere. He is a Certified Scrum Coach and Certified Scrum Trainer.

ORGANIC Agility in Discover Germany magazine

An introduction to the concept of ORGANIC Agility presented in issue 62 of May 2018

Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.