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

Scrumtisch September 2019

The Berlin Scrum User Group meets on September 30th at agile42, Gruenberger Str. 54, 10245 Berlin.

Image of aballer

Alexandra Baller

agile42 Team Assistant

The Scrum Master as an organizational multi-function pocket knife

The Scrum Master is a jack of all trades with a magic problem-solving knife in his back pocket or a master of Scrum?

Image of elrich.faul

Elrich Faul

I’m passionate about helping the current and next generations to develop the skills they need to be successful in a rapidly changing world. I believe that by leveraging my expertise in engineering, psychology and management I can empower individuals and teams to reach their maximum potential. I’m inspired when given the opportunity to coach teams as well as individuals toward growth and happiness.

Campaigning for Dave

agile42 coach Dave Sharrock is running for Scrum Alliance Member Elected Director and we support his candidacy!

Image of abragad

Alessio Bragadini

Web community manager of agile42, trying to post relevant, informational, fun bits of content on the blog and social networks

Talking agility at Agile Islands conference

Pascal Papathemelis and the agile42 team will be present at the Agile Islands 2019 conference in the Åland Islands

Image of pascal

Pascal Papathemelis

Pascal has worked as an agile project manager/scrum master/facilitator of various developments in size and type for almost two decades. His focus is on people and practical approaches in order to deliver value. Currently Pascal is working at agile42 as an agile coach on a journey to help organisations and individuals grow, improve and become more efficient in a sustainable way.

Coaching at the Nordic Business Forum in Helsinki

Giuseppe De Simone will represent the Scrum Alliance at Nordic Business Forum in Helsinki, October 9-10 providing agile conversations to attendees

Image of giuseppe.desimone

Giuseppe De Simone

Giuseppe De Simone is a Certified Scrum Trainer (CST), Certified Enterprise Coach (CEC) and Certified Team Coach (CTC), passionate about helping individuals, teams and organizations become more productive by embracing Agile values, principles and practices. He is one of very few to be accredited from the Scrum Alliance as an educator of the Certified Agile Leadership and Path to CSP programs.