Agile Methodology and Scrum in Game Development Clinton

Agile Methodology and Scrum in Game Development Clinton Keith VP/Director of Technology, High Moon Studios

What we’ll 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 • Q&A This is about what we experienced, not the “Right Way” to make games

The Goal Better Games at Lower Cost

The Problems Project “noise” impacts process selected Far from Agreement Requirements Anarchy Close to Agreement Complex C om pl ic at ed Simple Close to Certainty Technology Far from Certainty Source: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.

The Problems o Team Size o Communication challenge increases faster than team size o Centralized command control gets overwhelmed o Decision bottlenecks

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

Knowing the product value

What is Agile Development? The Agile Manifesto: o Individuals and interactions over processes and tools; o Working software over comprehensive documentation; o Customer collaboration over contract negotiation; o Responding to change over following a plan;

The Four Major Agile Methodologies • XP (e. Xtreme Programming) • Evo • RUP (Rational Unified Process) • Scrum

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

Origins • “The 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 90’s

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

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

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

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

The Scrum Team – It’s 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!

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

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

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

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

Product Backlog 30 days Product Backlog As prioritized by Product Owner

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

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

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

Sprint Backlog 30 days Sprint Goals Product Backlog As prioritized by Product Owner

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

s Cu em st om er en t r M an m ag M as te m te a Sc ru m Sc ru Pr o du ct ow ne r Sprint Planning Meeting Product backlog Team capabilities Business conditions Technology Current product Sprint Planning Meeting Sprint goals

Sprint Backlog broken out by team 30 day Sprint Product Backlog As prioritized by Product Owner Potentially Shippable Product Increment

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)

Managing Sprint Backlog • Team self-organizes around how they’ll meet the Sprint Goal – – – Managers don’t 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 don’t make decisions for the team

No changes to the goals allowed during a Sprint in effect Change Inputs Sprint Tested Code • Plan sprint durations around how long you can commit to keeping change out of the Sprint • Resetting the Sprint is an option

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 there’s new information

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

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

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

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: 1. What did you do since the last Scrum? 2. What will you do today? 3. What are the impediments to your progress?

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

A Sprint Backlog Task Mon. Tues. Wed. Code the UI 8 4 8 Code the middle-tier 16 12 10 4 Test middle tier 8 16 16 11 Write user’s guide Write the ABC class 12 8 8 8 4 Add error logging Thurs.

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

Visibility of Problems • Progress is plotted daily • You see delays on a daily basis (visibility) • “Drag” on velocity will affect slope

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

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 • Aren’t used to estimating – Multiple teams working on same backlog

The War Room • Where Daily Scrums Occur • Where Sprint Backlog is posted • Where Sprint Burndown is posted

The War Room

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

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

Using Scrum to Develop Games • Benefits • Lessons learned • Moving forward

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

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

Lesson Learned… • Alpha/Beta & Scrum don’t mix as well • Velocity shows benefit of overtime very limited – After two weeks, velocity returned to normal levels (or below)

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

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 Schwaber’s Certified Scrum Master (CSM) class – Onsite coaching

Where to go next? • www. mountaingoatsoftware. com/scrum – Mike Cohn, a great Agile/Scrum coach – Portions of this presentation come from this site with Mike’s permission • www. controlchaos. com – Ken Schwaber’s CSM class site • http: //agilemanifesto. org/ • Agile Software Development with Scrum – Ken Schwaber and Mike Beedle

Where to go next? • Agile Project Management with Scrum – Ken Schwaber • General information – www. agilealliance. com • My Site – www. agilegamedevelopment. com • Mailing List – scrumdevelopment@yahoogroups. com

Questions?

Appendix A Extra stuff if we have time

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

TBD product burndown

TBD product burndown 2