Embedding a

Scrum CultureHarvey Wheaton

Studio Director

About Me

Worked in several industries

Pharmaceuticals/manufacture (ICI/Astra Zeneca)

Retail Banking (BoS)

Public Sector (UK Sports Council)

Consulting (Cap Gemini)

Investment Banking (JP Morgan)

Encountered many methodologies, mostly waterfall

Also seen process improvement initiatives, good and bad, using BPR, CMM and Six Sigma

Joined Electronic Arts (EA) in 2003 – scrum-like environment

Discovered scrum around 2005, took Mike‟s class in 2006

Left EA to start up Supermassive Games Sept 2008

Have been embedding Scrum into this new organisation since then

The Games Industry

It‟s entertainment!

Review-score driven

Hit product mentality

Everyone‟s a consumer

On-line is becoming more important

New casual and social players

Developing GamesCreative, organic process

Requirements are discovered as we go

Continuous invention, R&D

Many disciplines need to work together

Talking to each other is crucial

Rapid iteration gets us to quality

It‟s all about what you can play – the software

“Public & physical” works very well for us

About Our Company

Games development studio

Established Sept 2008

Located in Guildford, near London

Today = 70 employees

Working primarily with Sony

Two PlayStation3 titles + 1 PC title published

Plus lots of downloadable content (LittleBigPlanet)

Today, working on 4+ projects

Our ProjectsTypically 12-18 months duration

3 distinct phases

Target is a games console (PlayStation 3)

Still Largely retail, boxed product

Market shifting to online, service-focused

Plus smaller, quick, e.g. Mobile

Pre-Production Production Final

Engineers

Artists

Designers

Exec

Our TeamsTypically 10-25 people

Multi-discipline

• Code

• Art

• Design

• Audio

• And more...

Often highly specialised

Scrum for Us

Key Elements

Two week sprints, shortening towards final

Cross-discipline teams

No single Product Owner

Physical planning (cards and boards)

Estimating the product backlog using relative (story) points

Estimating in days at task level within each sprint

Daily stand-ups

Emergent scrum masters from all disciplines

Continuous Integration

Builds reviewed daily

Software-focused sprint reviews

Self Organising Teams...

Agree

priorities and

high level

goals

Our Two-Week Cycle

Refresh

the

backlog

Update

high level

plan

Run the

Sprint

Plan the

sprint:- Goals

- Tasks

Review

Sprint Plan

Sprint

Review

Embedding a Scum Culture

Key Factors For Us

1. Environment, culture, organisation

2. Rapid iteration

3. Public, physical, visual

4. It‟s all about the software

5. Inspect, listen and adapt

“People will make important what you pay attention to”

(Mike Laddin, Leaderpoint )

Team Maturity Growth

Hershey and Blanchard’s Situational Leadership

March

2010

October

2009April

2011

1. Environment, culture, organisation

“Build projects around motivated individuals. Give people the environment and support they

need, and trust them to get the job done.”

(Agile Manifesto - Principles)

Creating a Deliberate Culture*Team

Clear communication

Open and honest critique

Decisive

Make mistakes early and cheaply

Respect and support each other as a team

Individuals

Ownership

Leadership

Flexibility

Contribution

Process

Goal driven

Continual review

Software focused

Enables not hinders

First draft of our

studio values from

October „08

*Rather than letting one form accidentally

Culture• Hiring the right people

• Using the language of the values

• Letting go of the right people

• Culture and Scrum induction for all new starters

• Office layout and seating

• Emphasis on delivery as a team and as studio

• Careful and inclusive language, continually reinforced

• “We” not “he”, “she”, “it” or “they”

• “Public and Physical” e.g. Planning and design

• Daily software reviews

• Story telling

• Regular and honest communication, in person

Organisational Structure“Every system is perfectly designed to get the results it gets”

• Cross discipline teams

• Expect flexibility right from the interview

– People not pigeon-holed into narrow roles

• Minimal hierarchy, no managers

– Studio Exec, Senior Staff, non-Senior staff

• Scrum masters emergent within the teams

Art DirectorDesign

Director

Technical

Director

Designers Artists Engineers

Simple, Flat Structure

Senior

DesignersSenior Artists

Senior

Engineers

2. Rapid Iteration“Even a Great

Masterpiece Starts

with a Sketch”

What Matters to Us

• Playing the software as early as we can

• Make mistakes quickly and at low cost

• Number of iterations, not the amount of time

• Working from low fidelity to high fidelity

• Fast, cheap, public and physical

• Visual

Working low to high fidelity

Physical Prototyping

Storyboards

Defining DoneHaving a Strategy for Iterations

Game Play Fidelity 1 2 3 4

Visu

al a

nd A

udio

Fid

elity

In-Game

5

Defining Our Iteration Stages

1 “Sketch”Exploration (working out what we‟re going to do, not necessarily how), rapidly working in low fidelity to test ideas and

should be as cheap and expendable as possible. As well as artwork, this can mean a code ‟sketch‟, a design outline, a

low-fidelity/paper prototype etc.

2 “Commit”Stage 2 is a key commitment stage as up to this point we have spent about 1/3 of the total we could spend so throwing

away is relatively inexpensive. This is therefore the point where we are ready to commit - we know how we are going to

achieve the goal and have shown enough to prove it. At this stage we should have a „good draft‟, certainly something

playable but with low fidelity or placeholder art/audio.

3 “Testable”Functionality/gameplay is complete and the game plays well and is finished enough to complete a full play through. It is

testable by someone with no prior knowledge of the game e.g. Focus test or QA. It should take little or no imagination at

this stage to see what the final game will be. Art and audio will not be finished at this stage but uses representative and

not just placeholder assets and is a significant progression from the low-fidelity assets at the commit stage.

4 A

Sample (Team-Specific) Checklist

Stage 3 – Testable

Functionality/gameplay is complete, the game is in the flow and scoring and

messaging are functional. Art and audio will not be finished at this stage but

will representative and not just placeholder.

Checklist

The game is included in the flow

All player messages are provided:

Start of game

In-game feedback

End of game

Scoring works

A score (or number of stars) is awarded based on how well the player performs

3. Software, software, software“We have come to value working

software over comprehensive documentation”

“Working software is the primary measure of progress.”

(Agile Manifesto)

Software as the Measure of Progress

• Continuous integration

• On-demand builds for anyone on the team

• Disks made every day

• „Drop-in‟ build review every day

• Has driven an emphasis on our build tools

• “Fix major issues immediately” culture

• Sprint reviews are software led

• Conversations happen around software

• Has to be in the build (on disk) to count

• Outlawing a „works on my machine‟ culture

4. Inspect, listen and adapt“At regular intervals, the team reflects

on how to become more effective, then tunes and adjusts its behaviour

accordingly.”

(Agile Manifesto - Principles)

“Insanity is doing the same thing

over and over again and expecting

different results.” (Albert Einstein?)

Actively Encourage Ideas and

Challenges to the Status Quo

• Make improvement everyone‟s responsibility

• Keep repeating this message

• Actively seek feedback opportunities

• Tell stories to foster the culture

• Expect emergent behaviour

• Accept a degree of divergence in process

Build It Into the Process

• Sprint Review

• Team Retrospective

• Exec Retrospective

Any Excuse for a Conversation!

From: Rob Dodd [mailto:r.dodd@supermassivegames.com]

Sent: 26 March 2009 12:18

To: 'Jonathan Amor'; 'Harvey Wheaton'

Subject:

Hi guys, Just a few thoughts I’ve had about how we’re working, and (hopefully) how we can improve a bit. You’re possibly already thought of most of this, and some of it is quite possibly bollocks. As always, feel

Good Old Email

One Year Retrospective• What works well on your team?

• What could be improved?

• What should we do more/less

of as a studio?

• What gets in the way or

frustrates you?

• What are you worried about

looking ahead?

This is NOT an appraisal – it’s an excuse to

have a conversation

Some of our Process Experimentation

• Visual Story

Cards

40

Some of our Process Experimentation

• Physical

board for

feature

status

tracking

Goal/Story Cards

Consequences

• It takes a lot of energy and enthusiasm to keep momentum

• Takes time for some people to adapt

• Previous culture, experience of Scrum, expectations

• Responsibility for individuals feels big

• Some people don‟t like this – can feel scary!

• Rapid feedback

• Rapid decision making – true delegation

• Worries about scaling significantly reduced

• The process is always evolving and sometimes unexpectedly

• The teams start to own it

• People enjoy their work

Questions?

Our Teams Feel Self-Organising

• They are involved in the decision about the goals are for the next sprint

• They decide how best to achieve the goals

• They create the sprint plan

• They decide on the sprint length

• They negotiate for resource when needed

• They take responsibility for delivering

• They remove their own impediments where possible

• They manage themselves throughout the sprint

• They inspect and they adapt the process

• At the end of each sprint

• Team plus Exec attend

• Anyone else welcome to come along as observers

• Review what has been achieved – software as the measure

• Guided by the sprint goals

• Reflect on what didn’t get done and why

• Anything we want to do differently next sprint?

• Collect velocity data (e.g. points achieved)

• Start to consider what the priorities are for the next sprint

The Sprint Review

Our Game Can Be Played• Play it as often as possible (several times a day)

• Polish it - make it better and more fun (easy?)

• Test and test it – everyone on the team

• Fix all the bugs - love QA

• Localise it into different languages (often 15+)

• Finalise Logos, manuals and packaging

• Become part of marketing (advertising, shows etc)

• Send it to Manufacturing!!

Stage 1 - SketchExploration (working out what we’re going to do, not necessarily how), rapidly working in low fidelity to test

ideas and should be as cheap and expendable as

possible.

As well as artwork, this can mean a code ’sketch’, a design outline, a low-fidelity/paper prototype etc.

Stage 2 - CommitA key commitment stage as up to this point we have

spent about 1/3 of the total we could spend so throwing

away is relatively inexpensive.

This is therefore the point where we are ready to commit -

we know how we are going to achieve the goal and

have shown enough to prove it.

At this stage we should have a ‘good draft’, certainly something playable but with low fidelity or placeholder

art/audio.

Stage 3 - TestableFunctionality/gameplay is complete and the game plays

well and is finished enough to complete a full play

through. It is testable by someone with no prior

knowledge of the game e.g.

Focus test or QA. It should take little or no imagination at

this stage to see what the final game will be. Art and

audio will not be finished at this stage but uses

representative and not just placeholder assets and is a

significant progression from the low-fidelity assets at the

commit stage.

Stage 4 - AlphaBy Alpha, the game or feature is potentially shippable and

is submitted to your publishers First Party QA.

Whilst the game as a whole could not ship at this point,

any individual feature could if we had to.

Initially, getting things to Alpha is based on an agreed

and prioritised list of work. Increasingly during this stage

the focus shifts to daily iterations based on continuous

prioritisation to ensure focus on the weakest aspects of the

game.

Stage 5 - FinalAll functionality, visuals and audio complete and

shippable.

Zero bugs...