View
1.547
Download
0
Category
Preview:
Citation preview
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...
Recommended