Agile Methodology

1
Agile Methodology and Scrum in Game Development
Clinton Keith VP/Director of Technology, High
Moon Studios
2
What well talk about

• The Goal and the Problems
• Overview of Agile Methodology
• Description of Scrum
• The challenges we had using Scrum for game
  development
• What were the benefits
• What lessons were learned
• What we will do next
• QA
• This is about what we experienced, not the Right
  Way to make games

3
The Goal

• Better Games at Lower Cost

4
The Problems
Project noise impacts process selected
Source Strategic Management and Organizational
Dynamics by Ralph Stacey in Agile Software
Development with Scrum by Ken Schwaber and Mike
Beedle.
5
The Problems

• Team Size
• Communication challenge increases faster than
  team size
• Centralized command and control gets overwhelmed
• Decision bottlenecks

6
The Problems

• Issues with Traditional Methodology
• Waterfall
• Up front design does not reduce risk as much as
  we think
• Delays true understanding of the game
• Surprises creep up on you

7
Knowing the product value
8
What is Agile Development?

• The Agile Manifesto
• Individuals and interactions over processes and
  tools
• Working software over comprehensive
  documentation
• Customer collaboration over contract negotiation
  
• Responding to change over following a plan

9
The Four Major Agile Methodologies

• XP (eXtreme Programming)
• Evo
• RUP (Rational Unified Process)
• Scrum

10
What is Scrum?

• Scrum is commitment-oriented
• Scrum is results-oriented
• Scrum is disciplined
• Scrum has specific roles, artifacts and practices

11
Origins

• The New New Product Development Game in Harvard
  Business Review, 1986.
• Studied companies that were able to rapidly
  develop successful products
• Borrows the term from Rugby in which the ball
  gets moved up field by the entire team.
• Adopted for Software Development and used since
  mid 90s

12
Overview
Daily Meeting
(Scrum)
30 day cycle
(Sprint)
Tasks
NPC
New Version of the game
Camera
Prioritized Game Features
Gfx
(Product Backlog)
13
The Elements of Scrum

• The Scrum Team
• Customers
• Product Owner
• The Product Backlog
• Sprints (30 day iterations)
• Planning
• Reviewing
• What happens within a Sprint
• Scalability

14
The Scrum Team

• Typically 5-10 people
• Cross-functional
• Programmers, Designers, Artists, QA etc.
• Teams are self-organizing
• No hierarchies
• Membership can change only between sprints

15
The Scrum Master

• Can be any member of the team
• Responsible for enacting Scrum values and
  practices
• Main job is to remove impediments
• Can be certified
• Not a lead role

16
The Scrum Team Its all about pigs and chickens

• A story/moral about opening a diner
• The definition of a Pig is someone who makes a
  personal commitment to the success of the
  project
• One perspective is that Scrum is all about
  getting rid of the Chickens!

17
Customers

• Customers of the product
• Publisher
• Marketing
• Management
• Directors
• Usually Chickens

18
Product Owner

• Owns and prioritizes the Product Backlog
• Needs to be local
• Mediates customer requests priorities

19
Sprints
24 hours
Daily Scrum Meeting
30 day Sprint
Backlog tasks expanded by team
Sprint Backlog
Potentially Shippable Product Increment
Product Backlog As prioritized by Product Owner
20
Sprints

• Scrum projects make progress in a series of
  Sprints
• Target duration is one month
• /- a week or two
• But, a constant duration leads to a better rhythm
• Game iteration is designed, coded, and tested
  during the sprint
• Vertical slices

21
Product Backlog
30 days
Product Backlog As prioritized by Product Owner
22
Product Backlog

• A list of all desired work on the project
• Prioritized by value
• No items are coarser than a sprint
• Can be time-boxed or estimated for planning

23
Sample Product Backlog
Backlog item Estimate(person-weeks)
Break props into separate rigid bodies 1
Arrow projectiles stick to environment 0.5
Ragdolls can lose limbs 2
NPCs avoid dynamite thrown at them 4
Improve exception handling 0.5
24
Running a Sprint

• Creating Sprint Goals
• Sprint Goals to Sprint Backlog
• Changes to Goals and Backlog
• Reviewing Sprint Progress
• Daily Meetings (Scrums)
• Working with the Sprint Backlog
• The War Room

25
Sprint Backlog
30 days
Sprint Goals
Product Backlog As prioritized by Product Owner
26
Sprint Planning Meeting

• Selects set of Sprint goals from the Product
  Backlog
• This is what the team will work on over the next
  Sprint
• Place time for all the pigs and chickens to get
  their say

27
Sprint Planning Meeting
Sprint Planning Meeting
Sprint goals
28
Sprint Backlog
30 day Sprint
Sprint Backlog broken out by team
Sprint Backlog
Potentially Shippable Product Increment
Product Backlog As prioritized by Product Owner
29
Sprint Backlog

• Scrum team takes the Sprint Goals and determines
  what tasks are necessary
• The tasks become the Sprint Backlog
• Usually written on cards and posted on a wall
• Highest priority goals/tasks are worked on first
  (placed higher on the wall)

30
Managing Sprint Backlog

• Team self-organizes around how theyll meet the
  Sprint Goal
• Managers dont assign tasks to individuals
• Individuals estimate their own tasks
• No tasks can exceed 16 hours. Beyond 16 hours,
  the crystal ball gets foggy
• The main point is that managers dont make
  decisions for the team

31
No changes to the goals allowed during a Sprint
in effect

• Plan sprint durations around how long you can
  commit to keeping change out of the Sprint
• Resetting the Sprint is an option

32
Sprint Backlog during the Sprint

• Changes to Backlog
• Team adds new tasks whenever they need to in
  order to meet the Sprint Goal
• Team can remove unnecessary tasks
• But Sprint Backlog can only be updated by the
  team
• Estimates are updated whenever theres new
  information

33
Sprint Review
Sprint Backlog broken out by team
30 day Sprint
Sprint Backlog
Potentially Shippable Game
Product Backlog As prioritized by Product Owner
34
Sprint Review

• Team presents what it accomplished during the
  sprint
• Typically takes the form of a demo of new
  features or underlying architecture
• Participants
• Same as the planning meeting

35
Daily Scrum
24 hours
Daily Scrum Meeting
Sprint Backlog broken out by team
30 day Sprint
Sprint Backlog
Potentially Shippable Game
Product Backlog As prioritized by Product Owner
36
Daily Scrum

• Parameters
• Daily
• 15-minutes
• Stand-up
• Not for problem solving
• Chickens and pigs are invited
• Helps avoid other unnecessary meetings
• Only pigs can talk
• Each pig answers three questions
• What did you do since the last Scrum?
• What will you do today?
• What are the impediments to your progress?

37
Questions about Scrum meetings?

• Why daily?
• How does a project get to be a year late?
• One day at a time.
• Fred Brooks, The Mythical Man-Month
• Scrum creates daily visibility of issues
• Can Scrum meetings be replaced by emailed status
  reports?
• No
• Entire team needs to see the whole picture every
  day
• Need to make the people commit in front of their
  teammates

38
A Sprint Backlog
Mon.
Tues.
Wed.
Thurs.
Task
8
8
Code the UI
16
10
4
Code the middle-tier
8
16
11
Test middle tier
12
Write users guide
8
8
8
Write the ABC class
8
4
Add error logging
39
Sprint Backlog Burndown Chart

• Shows work being burned down off of total
  backlog hours
• Ideal velocity and task load is displayed as
  baseline
• 800 hours 8 people x 20 working days x 5
  hour/day velocity
• Posted in full view

40
Visibility of Problems

• Progress is plotted daily
• You see delays on a daily basis (visibility)
• Drag on velocity will affect slope

41
Adjusting the Backlog

• In this case, we removed 160 hours of low
  priority backlog
• We adjusted velocity. The team decided to work
  an extra day to catch up

42
Velocity (recap)

• Number of useful hours of production work that
  can be accomplished per day
• Theoretical max is 5 hours useful task work per
  day
• A variety of things can add drag to velocity
• Team not co-located
• Team is new to Scrum
• Arent used to estimating
• Multiple teams working on same backlog

43
The War Room

• Where Daily Scrums Occur
• Where Sprint Backlog is posted
• Where Sprint Burndown is posted

44
The War Room
45
Scalability of Scrum

• Typical Scrum team is 5-10 people
• Sutherland used Scrum in groups of 500
• We had 7 Scrum teams for 60 developers

46
Scrum of Scrums

• Following the daily Scrums
• The Scrum Masters have their Scrum

47
Using Scrum to Develop Games

• Benefits
• Lessons learned
• Moving forward

48
Benefits

• Improved
• Productivity
• Reliability of build
• Quality of game
• Morale
• Ownership
• Team work
• Communication
• Enabled low-overhead empirical management

49
Lesson Learned

• Starting is easy. Getting it right is hard.
• Thinking Agile is a paradigm shift
• Estimating hours instead of days is hard
• Artists Designers should be pigs, not chickens
• Embedded QA is a huge benefit

50
Lesson Learned

• Alpha/Beta Scrum dont mix as well
• Velocity shows benefit of overtime very limited
• After two weeks, velocity returned to normal
  levels (or below)

51
Moving forward

• Use XP, TDD and other Agile engineering practices
• More cross-discipline engineering
• Dynamic teams that are more focused
• Instead of a Character team that stays together
  for the project, form Boss team, that stays
  together for one or two sprints

52
Moving forward

• Improve Product Backlog Sprint Goal definitions
• What we expected was often not what was delivered
• Functionality was often at 90. This comes back
  to bite you
• Learn about User Stories and other planning
  methods
• More consulting
• Ken Schwabers Certified Scrum Master (CSM) class
• Onsite coaching

53
Where to go next?

• www.mountaingoatsoftware.com/scrum
• Mike Cohn, a great Agile/Scrum coach
• Portions of this presentation come from this site
  with Mikes permission
• www.controlchaos.com
• Ken Schwabers CSM class site
• http//agilemanifesto.org/
• Agile Software Development with Scrum
• Ken Schwaber and Mike Beedle

54
Where to go next?

• Agile Project Management with Scrum
• Ken Schwaber
• General information
• www.agilealliance.com
• My Site
• www.agilegamedevelopment.com
• Mailing List
• scrumdevelopment_at_yahoogroups.com

55
Questions?
56
Appendix A

• Extra stuff if we have time

57
Project Planning

• Project components that have more known
  requirements and tech can still be waterfalled
• Timeboxing parts of development is a useful tool

58
TBD product burndown
59
TBD product burndown 2