Game Production: agile development with Scrum Fabiano Dalpiaz f.dalpiaz@uu.nl 1
Copyright and acknowledgement These slides are based upon and extend Mike Cohn s Introduction to Scrum http://www.mountaingoatsoftware.com/presentations/anintroduction-to-scrum The original slides were provided under the Creative Commons Attribution 3.0 Unported license https://creativecommons.org/licenses/by/3.0/legalcode Mike Cohn s presentation on Scrum for games http://www.slideshare.net/mikecohn/agile-and-scrum-for-videogame-development-22871287 Paul Miller s article Top 10 pitfalls using Scrum on Gamasutra http://www.gamasutra.com/view/feature/3724/top_10_pitfalls_usin g_scrum_.php?print=1 2
Outline 1. Introduction, origins, history 2. Overview of Scrum 3. Scrum framework: roles 4. Scrum framework: ceremonies 5. Scrum framework: artifacts 6. Scaling up with Scrum 7. Pitfalls of Scrum for games 3
1. Introduction, origins, history Motivation The relay race approach to product development may conflict with the goals of maximum speed and flexibility. Instead a holistic or rugby approach where a team tries to go the distance as a unit, passing the ball back and forth may better serve today s competitive requirements. Hirotaka Takeuchi and Ikujiro Nonaka, The New New Product Development Game, Harvard Business Review, January 1986. 4
1. Introduction, origins, history Scrum in 100 words Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month) The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features After every inspection, the team collaboratively decides to release it as is or continue to enhance it for another sprint 5
1. Introduction, origins, history Scrum origins Jeff Sutherland Initial scrums at Easel Corp in 1993 IDX and 500+ people doing Scrum Ken Schwaber ADM Scrum presented at OOPSLA 96 with Sutherland Author of three books on Scrum Mike Beedle Scrum patterns in PLOPD4 Ken Schwaber and Mike Cohn Co-founded Scrum Alliance in 2002 6
1. Introduction, origins, history The success of Scrum 7
1. Introduction, origins, history The success of Scrum: application areas Commercial software Video game development In-house development Contract development Fixed-price projects Financial applications ISO 9001-certified applications FDA-approved, life-critical systems Satellite-control software Websites Handheld software Mobile phones Embedded systems 24x7 systems with 99.999% uptime requirements the Joint Strike Fighter Network switching applications ISV applications Some of the largest applications in use 8
2. Overview of Scrum Characteristics Self-organizing teams Product progresses in a series of month-long sprints Requirements are captured as items in a list of product backlog No specific engineering practices prescribed 9
2. Overview of Scrum The Agile Manifesto: the importance of Individuals and interactions Working software over over Process and tools Comprehensive documentation Customer collaboration over Contract negotiation Responding to change over Following a plan Source: www.agilemanifesto.org 10
2. Overview of Scrum Scrum, illustrated 11
2. Overview of Scrum Sprints Scrum projects make progress in a series of sprints Analogous to Extreme Programming iterations Typical duration is 2 4 weeks or a calendar month at most A constant duration leads to a better rhythm Product is designed, coded, and tested during the sprint 12
2. Overview of Scrum Sequential vs. overlapping development Requirements Design Code Test Rather than doing all of one thing at a time......scrum teams do a little of everything all the time Source: The New New Product Development Game by Takeuchi and Nonaka. Harvard Business Review, January 1986. 13
2. Overview of Scrum Golden rule: no changes during a sprint Plan sprint durations around how long you can commit to keeping change out of the sprint 14
2. Overview of Scrum Anatomy of the Scrum framework 15
3. Scrum framework: roles 16
3. Scrum framework: roles Product owner Define the features of the product Decide on release date and content Be responsible for the profitability of the product (ROI) Prioritize features according to market value Adjust features and priority every iteration, as needed Accept or reject work results 17
3. Scrum framework: roles ScrumMaster Responsible for enacting Scrum values and practices Removes impediments Ensures that the team is fully functional and productive Enables close cooperation across all roles and functions Shields the team from external interferences 18
3. Scrum framework: roles Team Typically 5-9 people Cross-functional Programmers, testers, user experience designers, etc. Members should be full-time May be exceptions (e.g., database administrator) 19
3. Scrum framework: roles Team Teams are self-organizing Ideally, no titles but rarely a possibility Membership should change only between sprints 20
3. Scrum framework: roles Team, in game development 21
4. Scrum framework: ceremonies 22
4. Scrum framework: ceremonies Sprint planning 23
4. Scrum framework: ceremonies Sprint planning Team selects items from the product backlog they can commit to completing Sprint backlog is created Tasks are identified and each is estimated (1-16 hours) Collaboratively, not done alone by the ScrumMaster High-level design is considered As a player, I want to have a different starting point whenever I launch the game Develop levels map (16 hours) Write pseudo-random algorithm (4 hours) Integrate algorithms with map (8 hours) 24
4. Scrum framework: ceremonies The daily Scrum meeting Parameters Daily 15-minutes Stand-up Not for problem solving Whole world is invited Only team members, ScrumMaster, product owner, can talk Helps avoid other unnecessary meetings 25
4. Scrum framework: ceremonies The daily Scrum meeting Everyone asks three questions 1. What did you do yesterday? 2. What will you do today? 3. Is anything in your way? These are not status for the ScrumMaster They are commitments in front of peers 26
4. Scrum framework: ceremonies The sprint reviews Team presents what it accomplished during the sprint Typically takes the form of a demo of new features or underlying architecture Informal 2-hour prep time rule No slides Whole team participates Invite the world 27
4. Scrum framework: ceremonies Sprint retrospective Periodically take a look at what is and is not working Typically 15 30 minutes Done after every sprint Whole team participates ScrumMaster Product owner Team Possibly customers and others 28
4. Scrum framework: ceremonies Sprint retrospective: start/stop/continue meeting Whole team gathers, every member says three things concerning the way the team is working What shall we start doing? What shall we stop doing? What shall we continue doing? This is just one of many ways to do a sprint retrospective. 29
5. Scrum framework: artifacts 30
5. Scrum framework: artifacts Product backlog The requirements A list of all desired work on the project Ideally expressed such that each item has value to the users or customers of the product Prioritized by the product owner Reprioritized at the start of each sprint 31
5. Scrum framework: artifacts Product backlog: example 32
5. Scrum framework: artifacts User stories The backlog item typically consists of user stories Short description of a feature told from the perspective of the person that desires it Simple template: As a <role>, I want to <goal> so that <reason> 33
5. Scrum framework: artifacts How to write user stories? Often via a user story card Front: user story itself Back: acceptance criteria (conditions of satisfaction) 34
5. Scrum framework: artifacts On good * user stories: INVEST A framework to characterize good quality user stories Independent = The user story should be self-contained Negotiable = User stories, until the team start working on them, can always be changed Valuable = A user story must deliver value to the end user Estimable = You should always be able to estimate the size Small = Not so big as to make it impossible to plan/prioritize with sufficient certainty Testable = It should be clear when a user story is satisfied * In the workshop by Garm Lucassen, you will see how to write even better user stories 35
5. Scrum framework: artifacts The product backlog as an iceberg 36
5. Scrum framework: artifacts The sprint goal Database Application A short statement of what the work will be focused on during the sprint Life Sciences Support features necessary for population genetics studies. Make the application run on SQL Server in addition to Oracle. Videogame Do the porting from Java 1.6 to Java 1.7 Financial services Support more technical indicators than company ABC with real-time, streaming data. 37
5. Scrum framework: artifacts Managing the sprint backlog Take the product backlog and the sprint goal as inputs Individuals sign up for work of their own choosing Work is never assigned by the ScrumMaster Estimated work remaining is updated daily 38
5. Scrum framework: artifacts Managing the sprint backlog Any team member can add, delete or change the sprint backlog Work for the sprint emerges If work is unclear, define a sprint backlog item with a larger amount of time and break it down later Update work remaining as more becomes known 39
5. Scrum framework: artifacts A sprint backlog 40
5. Scrum framework: artifacts Burndown charts Primary method of tracking progress A burndown chart shows how much work is left as of various dates Two types Release burndown Sprint burndown 41
5. Scrum framework: artifacts A sprint burndown chart 42
5. Scrum framework: artifacts Sprint backlog and corresponding burndown chart 43
6. Scaling up with Scrum Scalability is needed Typical individual team is 7 ± 2 people Scalability comes from teams of teams Factors in scaling Type of application Team size Team dispersion Project duration Scrum has been used on multiple 500+ person projects 44
6. Scaling up with Scrum Scrum of scrums 45
6. Scaling up with Scrum Scrum of scrums (or meta-scrum) Managerial scrum 46
6. Scaling up with Scrum Scrum of scrums of scrums 47
7. Scrum for games Scrum is definitely useful and in most cases provides a significant benefit However, one should not believe that Scrum just replaces all what traditional methods teach Let s look at the top 10 pitfalls by Paul Miller With personal adaptations and merging Turned into best practices / guidelines Remark: this is an authoritative opinion, but it conflicts with the pure Scrum approach 48
7. Scrum for games The backlog spreadsheet does not replace the GDD Design documentation is still needed Recently, prototypes are more and more the essence of design documentation (with source control) Don t interrupt people to join the 15 minutes stand up meeting Some tasks take more than one day do not let the development team waste time when everything is OK Do that when things are not all right Putting everyone in a room does not necessarily fertilize collaboration Mandating collaboration does not work 49
7. Scrum for games Don t let people become reactive The practice of telling the team that only tasks in the backlog can be taken may lead to reactive people staying idle (waiting for the next sprint) Do not let the stand-up meeting become a go-around with status report Center the stand-up meeting around action items Don t just make Scrum mandatory Keep providing feedback and positive reinforcement when tasks are completed Start with sprints early, before the GDD exists 50
References Mandatory 1. Highsmith, Jim, and Alistair Cockburn. "Agile software development: The business of innovation." Computer 34.9 (2001): 120-127. 2. Dingsøyr, Torgeir, et al. "A decade of agile methodologies: Towards explaining agile software development." Journal of Systems and Software 85.6 (2012): 1213-1221. 3. Martin, Chase Bowen, and Mark Deuze. "The independent production of culture: A digital games case study." Games and culture 4.3 (2009): 276-295. 51
References Books Agile and Iterative Development: A Manager s Guide by Craig Larman Agile Estimating and Planning by Mike Cohn Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Software Development Ecosystems by Jim Highsmith Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Scrum and The Enterprise by Ken Schwaber Succeeding with Agile by Mike Cohn User Stories Applied for Agile Software Development by Mike Cohn 52
References Websites and papers www.mountaingoatsoftware.com/scrum www.scrumalliance.org www.controlchaos.com scrumdevelopment@yahoogroups.com Inge van de Weerd, Stefan de Weerd, Sjaak Brinkkemper: Developing a Reference Method for Game Production by Method Comparison. Situational Method Engineering 2007: 313-327 53