1. Embedding a
Scrum Culture
Harvey Wheaton
Studio Director

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

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

4. Developing Games
Creative, 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

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

6. Our Projects
Typically 12-18 months duration
3 distinct phases
Pre-Production Production Final
Target is a games console (PlayStation 3)
Still Largely retail, boxed product
Market shifting to online, service-focused
Plus smaller, quick, e.g. Mobile

7. Our Teams
Typically 10-25 people
Multi-discipline Exec
• Code
• Art Designers
• Design
Engineers
• Audio Artists
• And more...
Often highly specialised

8. Scrum for Us

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

10. Our Two-Week Cycle
Refresh
the Agree
backlog priorities and Plan the Review Run the Sprint
high level sprint: Sprint Plan Sprint Review
- Goals
- Tasks
Update goals
high level
plan

11. Embedding a Scum Culture

12. Key Factors For Us
“People will make important what you pay attention to”
(Mike Laddin, Leaderpoint )
1. Environment, culture, organisation
2. Rapid iteration
3. Public, physical, visual
4. It‟s all about the software
5. Inspect, listen and adapt

13. Team Maturity Growth
March
2010
April October
2011 2009
Hershey and Blanchard’s Situational Leadership

14. 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)

15. Creating a Deliberate Culture*
Team
Clear communication
Open and honest critique
Decisive
Make mistakes early and cheaply
First draft of our Respect and support each other as a team
studio values from Individuals
Ownership
October „08 Leadership
Flexibility
Contribution
Process
Goal driven
Continual review
Software focused
Enables not hinders
*Rather than letting one form accidentally

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

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

18. Simple, Flat Structure
Design Technical
Art Director
Director Director
Senior Senior
Senior Artists
Designers Engineers
Designers Artists Engineers

19. 2. Rapid Iteration
“Even a Great
Masterpiece
Starts
with a Sketch”

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

21. Working low to high fidelity

25. Physical Prototyping

26. Storyboards

27. Defining Done
Having a Strategy for Iterations
Visual and Audio Fidelity
In-Game
1 3 4 Game Play Fidelity 5
2

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

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

30. 3. Software, software, software
“We have come to value working
software over comprehensive
documentation”
“Working software is the primary
measure of progress.”
(Agile Manifesto)

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

32. 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)

33. “Insanity is doing the same thing
over and over again and expecting
different results.” (Albert Einstein?)

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

35. Build It Into the Process
• Sprint Review
• Team Retrospective
• Exec Retrospective

36. Any Excuse for a Conversation!

37. Good Old Email
From: Rob Dodd [mail to:r.dodd@supermassive games.com]
Sent: 26 March 2009 12:18
To: ' Jona tha n Amor'; ' Harve y W heaton'
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

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

39. Some of our Process Experimentation
• Visual Story
Cards

40. 40

41. Some of our Process Experimentation
• Physical
board for
feature
status
tracking

42. Goal/Story Cards

43. 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 

44. Questions?

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

46. The Sprint Review
• 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

47. 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!!

48. Stage 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.

49. Stage 2 - Commit
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.

50. Stage 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.

51. Stage 4 - Alpha
By 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.

52. Stage 5 - Final
All functionality, visuals and audio complete and
shippable.
Zero bugs...