Title: Agile Methodology
1Agile Methodology and Scrum in Game Development
Clinton Keith VP/Director of Technology, High
Moon Studios
2What 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
3The Goal
- Better Games at Lower Cost
4The 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.
5The Problems
- Team Size
- Communication challenge increases faster than
team size - Centralized command and control gets overwhelmed
- Decision bottlenecks
6The 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
7Knowing the product value
8What 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
9The Four Major Agile Methodologies
- XP (eXtreme Programming)
- Evo
- RUP (Rational Unified Process)
- Scrum
10What is Scrum?
- Scrum is commitment-oriented
- Scrum is results-oriented
- Scrum is disciplined
- Scrum has specific roles, artifacts and practices
11Origins
- 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
12Overview
Daily Meeting
(Scrum)
30 day cycle
(Sprint)
Tasks
NPC
New Version of the game
Camera
Prioritized Game Features
Gfx
(Product Backlog)
13The Elements of Scrum
- The Scrum Team
- Customers
- Product Owner
- The Product Backlog
- Sprints (30 day iterations)
- Planning
- Reviewing
- What happens within a Sprint
- Scalability
14The 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
15The 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
16The 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!
17Customers
- Customers of the product
- Publisher
- Marketing
- Management
- Directors
- Usually Chickens
18Product Owner
- Owns and prioritizes the Product Backlog
- Needs to be local
- Mediates customer requests priorities
19Sprints
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
20Sprints
- 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
21Product Backlog
30 days
Product Backlog As prioritized by Product Owner
22Product 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
23Sample 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
24Running 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
25Sprint Backlog
30 days
Sprint Goals
Product Backlog As prioritized by Product Owner
26Sprint 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
27Sprint Planning Meeting
Sprint Planning Meeting
Sprint goals
28Sprint Backlog
30 day Sprint
Sprint Backlog broken out by team
Sprint Backlog
Potentially Shippable Product Increment
Product Backlog As prioritized by Product Owner
29Sprint 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)
30Managing 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
31No 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
32Sprint 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
33Sprint Review
Sprint Backlog broken out by team
30 day Sprint
Sprint Backlog
Potentially Shippable Game
Product Backlog As prioritized by Product Owner
34Sprint 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
35Daily 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
36Daily 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?
37Questions 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
38A 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
39Sprint 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
40Visibility of Problems
- Progress is plotted daily
- You see delays on a daily basis (visibility)
- Drag on velocity will affect slope
41Adjusting 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
42Velocity (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
43The War Room
- Where Daily Scrums Occur
- Where Sprint Backlog is posted
- Where Sprint Burndown is posted
44The War Room
45Scalability of Scrum
- Typical Scrum team is 5-10 people
- Sutherland used Scrum in groups of 500
- We had 7 Scrum teams for 60 developers
46Scrum of Scrums
- Following the daily Scrums
- The Scrum Masters have their Scrum
47Using Scrum to Develop Games
- Benefits
- Lessons learned
- Moving forward
48Benefits
- Improved
- Productivity
- Reliability of build
- Quality of game
- Morale
- Ownership
- Team work
- Communication
- Enabled low-overhead empirical management
49Lesson 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
50Lesson 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)
51Moving 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
52Moving 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
53Where 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
54Where 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
55Questions?
56Appendix A
- Extra stuff if we have time
57Project Planning
- Project components that have more known
requirements and tech can still be waterfalled - Timeboxing parts of development is a useful tool
58TBD product burndown
59TBD product burndown 2