SCRUM TRAINING WITH CLINTON KEITH

Transcription

1 SCRUM TRAINING WITH CLINTON KEITH Congratulations on registering for the upcoming course! This guide, less than 3000 words long, contains a portion of my book Agile Game Development with Scrum, and provides the basic information about Scrum. You are strongly encouraged to read it before the course to maximize the benefit of our time together (just knowing the basic Scrum terms helps). The course itself will be highly interactive and team focused. Please come prepared to discuss how Scrum can be applied to your games and your studio culture. See you soon! Clint L OR E M E N I M R E A L E S T A T E Lorem Ipsum et: Work Street Work City, Work State Work ZIP

2 Overview This guide, derived from the book Agile Game Development with Scrum (AGD), is a very brief overview of the core elements of Scrum. It s a starting place for a discovery of Scrum, which might include reading a book, taking a course or joining a Scrum team. The take-away from this guide is simple. After reading the guide you should understand, at a very high level, what the following Scrum elements are: The Scrum Values Sprints Product Backlog Sprint Backlog Releases Scrum Team ScrumMaster Product Owner The Team/Developers Sprint Planning The Daily Scrum Sprint Reviews Retrospectives These terms--along with other important ones-- are in highlighted in bold throughout the guide. The benefit of learning these terms before the course is best explained by comparing Scrum to Chess. The rules of Chess can be learned quickly, but learning the rules doesn't mean you'll be good at the game. Becoming a good Chess player requires practice. It's the same with Scrum; it 9/24/12 Copyright Clinton Keith 1

3 requires hands-on practice. For this reason, it's best if the course focuses on practicing Scrum, which can include simulation, discussion and scenarios where you'll learn strategy. Strategy is harder to learn than simply reading about it and it's where we want to focus our efforts in the course not memorizing terms. Scrum Scrum is a framework for creating complex products. It s not a process or a methodology since its practices aren t specific enough to control how programmers, artists, designers, producers, QA, etc. do their work. A studio adopting Scrum merges their own practices into the Scrum framework to form their own methodology. Success with Scrum is not found memorizing terms, practices or role responsibilities. It s not found in following the practices perfectly. Success with Scrum is found as teams discover better ways to collaborate and create value in their products. The Big Picture Figure 1.1 shows an overview of the Scrum flow. 9/24/12 Copyright Clinton Keith 2

4 Figure The big picture Scrum Values Scrum practices support its core values and these values are the focal point around-which teams improve (from the Agile Atlus): All work performed in Scrum needs a firm basis of values to serve as a basis for the process and principles. Through the use of teamwork and continuous improvement, Scrum both creates these values and relies on them. As defined by Scrum's creators, the values are Focus, Courage, Openness, Commitment, and Respect Focus. Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner. Courage. Because we are not alone, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges. 9/24/12 Copyright Clinton Keith 3

5 Openness. As we work together, we practice expressing how we're doing, and what's in our way. We learn that it is good to express concerns, so that they can be addressed. Commitment. Because we have great control over our own destiny, we become more committed to success. Respect. As we work together, sharing successes and failures, we come to respect each other, and to help each other become worth of respect. If an organization will let Scrum do its work, they will discover the benefits from Scrum and will begin to understand why these values are both needed by Scrum, and engendered by Scrum. Sprints A game developed with Scrum makes progress in short (2 to 4 week) iterations, or sprints, using cross-discipline teams of five to nine people. Sprints are the heartbeat of the project. At the start of a sprint there is a sprint planning meeting. During this meeting, a sprint goal is identified and the work needed to fulfill that goal is estimated to determine if the team can complete it by the end of the sprint. A sprint goal encompasses a number of features from the top of a prioritized list called the product backlog. Each feature on the product backlog is called a product backlog Item (PBI). The team estimates the tasks required to implement each PBI, one at a time, into the sprint backlog. Figure 1.2 shows a simple player jump feature and the tasks from sprint backlog required to implement it. 9/24/12 Copyright Clinton Keith 4

6 Figure An Example of breaking a PBI into tasks for the sprint backlog During the sprint, the team meets daily in a 15-minute time-boxed 1 meeting called the daily scrum. During this meeting, they share their progress and any impediments to their work. By the end of the sprint, the team has created a potentially shippable version of the game: a playable game, that won t necessarily pass all the tests necessary to ship (often referred to as "potentially shippable"). The stakeholders (managers, directors, publisher staff) of the game gather in a sprint review meeting with the team to evaluate if the goals of the sprint were met and to update the product backlog for the next sprint based on what they ve learned. 1 A time-box is a fixed amount of time given to a meeting, task or work. This sets the limit of the amount of time spent. For example, a 15-minute time-boxed meeting will end at the 15 minute mark regardless of whether all the agenda items are addressed or not. 9/24/12 Copyright Clinton Keith 5

7 Many social games or MMOs actually ship every sprint, so it quite possible to achieve this state, especially with improved test automation. 2 Following the sprint review, the team will hold a sprint retrospective. In this meeting, the team will reflect on how effectively they worked together over the last sprint and to find ways of improving their collaboration and work. The Product Backlog The product backlog is a prioritized list of the requirements or features (PBIs) for a game, toolset or the pipeline used to make the game. Examples of these requirements are: "Add a filtering function to the animation exporter." "Add a particle effect to the game." "Add online gameplay." The product backlog changes to reflect the emerging value and priorities of the work. The value of each feature to the player is used to prioritize the backlog. The product backlog is not meant to be a complete list of every feature broken down into its finest detail; that makes it too cumbersome to manipulate. Instead, the PBIs on the top of the list, the PBIs of highest value, are disaggregated, or broken down, into small enough features for the team to achieve in the short term. The following figure demonstrates some PBIs for an example platform game: 2 Chapter 9 of AGD 9/24/12 Copyright Clinton Keith 6

8 Figure A backlog of Features/PBIs Jump, crawl and fly are the most valuable PBIs to implement right now and are at the top of the list. These PBIs are small enough to complete in a single sprint. PBIs such as online or map editor are lower priority and are not disaggregated into smaller PBIs until the team is closer to implementing them. Releases Releases are a set of sprints meant to bring a game, with major new features, to a shippable state 3. A typical release lasts between two to four months. The pace of releases is similar to those of milestones on a typical project. Figure 1.4 show how these might look for a multi-year project with nine releases. 3 On a multi-year project, a shippable state might be considered the same as a magazine demo: you can show it to the world, but there is still more to do. 9/24/12 Copyright Clinton Keith 7

9 Figure A series of releases for a multi-year project Releases establish longer-term goals for the team and stakeholders. They require an elevated level of polish and debugging that reduce a great deal of uncertainty about the work left to do to ship the game. Releases start with a planning session that establishes major goals for the game. A release plan drives the goals for each sprint. Figure 1.5 shows how the Release plan is a subset of features from the product backlog and how each forecasted sprint goal is a subset of the release plan. 4 4 Chapter 7 in AGD 9/24/12 Copyright Clinton Keith 8

10 Figure Subsets of planning Scrum Roles A Scrum team consists of a ScrumMaster, a Product Owner and a Team of developers. Outside the team are stakeholders, which include everyone who has "a stake" in the outcome of the work, and customers: those who will buy the game, or current players we hope to please with upcoming releases. A picture of the relationship between the roles is shown in Figure 1.6 9/24/12 Copyright Clinton Keith 9

11 Figure The roles & relationships The Team The team includes developers from every discipline necessary to accomplish a sprint goal. For example, a team committing to a goal to demonstrate a walking, talking AI character should have animators, AI programmers, character modelers, and QA to help the team best ensure that the goal is reached. Teams are accountable for delivering their work at the highest defined quality, which might include definitions such as "doesn't crash" or "performs at 30 frames-per-second". The team course-corrects their efforts on a daily basis based on problems or opportunities that continually arise during game development. Teams are self-organizing, which at first means that they estimate and track the sprint backlog on their own, but as they gel and mature as a team, then take on more ownership of their practices and membership. 9/24/12 Copyright Clinton Keith 10

12 ScrumMaster The ScrumMaster role is pivotal for the success of Scrum, yet it is often misunderstood because it is neither a traditional leadership or management role. The ScrumMaster improves the use of Scrum through coaching, facilitation and the rapid elimination of anything that distracts the team from delivering value. The ScrumMaster is the conscience of the team in a sense; because at times the Scrum values can be inconvenient. For example, a team may ignore fixing bugs or unpolished assets in their rush to achieve a sprint goal. The ScrumMaster must help them understand that each sprint delivers features to a definition of done and help them find ways of avoiding these problems in future sprints. The ScrumMaster is a bit like a parent: coaching and guiding the team very closely at first and then, as the team becomes more self-organizing, steps back and let's them take on more. Product Owner The Product Owner is accountable for the success or failure of a game. They don't carry out this role in isolation, but are supported by the ScrumMaster, stakeholders, and domain experts. However, there still needs to be one voice, which communicates the vision for the game to everyone inside and outside the team. The Product Owner must be someone who can synthesize the different views on cost, risk and value into the product backlog. The Product Owner guides a game's development by prioritizing the product backlog, appraising the emerging game's fun, establishing a quality bar, and forecasting future progress using the velocity of work completed by the teams. They communicate this progress to the stakeholders to manage expectations and maintain transparency. Scrum Meetings 9/24/12 Copyright Clinton Keith 11

13 At first glance, the number and frequency of meetings in Scrum can scare people off. The reason is that people are accustomed to meetings as typically boring affairs where everyone sits around for hours, trying to stay awake, while others speak. Scrum meetings, if facilitated correctly, are focused, effective and meaningful to all participants. Over time, teams take more control over their meetings and improve them. Sprint Planning Sprints start with a planning meeting. Here a team discusses the goal established by the Product Owner and stakeholders and then estimates the amount of work that they can accomplish towards achieving that goal. After identifying potential PBIs that would fulfill the goal, the team estimates tasks from each PBI, one at a time, to build the sprint backlog. During this time, many questions about requirements and design will be discussed. The entire Scrum Team attends the sprint planning meeting (including the Product Owner and ScrumMaster) along with anyone else needed to help create the best estimates (e.g. a networking expert to help the team estimate online features). The team will finish estimating when the amount of work estimated roughly equals the average amount of work they have been able to complete in previous sprints. At this point, they establish an agreement with the Product Owner about what they will show at the end of the sprint. The Daily Scrum Each day, a team gathers for the daily scrum. There are three goals for this meeting: To synchronize effort among all team members across all disciplines. 9/24/12 Copyright Clinton Keith 12

14 To commit to the work to be accomplished in the next day and reaffirm the team s commitment to the sprint goal. To identify any impediments that threaten that goal. The daily scrum is a brief huddle for the team to confirm that they remain on the same page. The entire team hears about the progress and problems for each member so that they can lend a hand where needed. The meeting allows a team to micro-steer their progress towards a shared goal rather than a collection of individual goals that will be integrated and debugged at the end of the sprint. The daily scrum is usually time-boxed to 15 minutes or less and everyone stands during the meeting 5. Longer problem-solving discussions are deferred until after the meeting to ensure that it is brief and to the point. Teams often modify the daily scrum to best fit their needs. One example is to conduct a play-through of the game just before the meeting. This practice helps identify any changes needed and gives the team a tangible sense of their progress. Sprint Review A sprint ends with a review, which brings the Scrum team and stakeholders together to play the game and discuss its progress. As a result of the review, the Product Owner officially accepts or declines the results of the sprint. Features are then removed from the backlog, if complete, or remain there to be worked on in a coming sprint. Sprint reviews allow frequent communication between stakeholders and teams. This is the opportunity for the stakeholders to inspect the game and communicate with the teams. This helps ensure that the project is heading in a direction understood by everyone. Sprint Retrospective 9/24/12 Copyright Clinton Keith 13

15 Throughout the agile development of a game, we apply the inspect and adapt philosophy. We inspect the progress of the game and adapt our planning to its emerging value. We inspect the progress of the team daily and adapt our tasks to maximize progress. This philosophy also applies to how team members work together and apply scrum. This is the main purpose of the sprint retrospective meeting. The goal of the retrospective is to continually improve how a team creates value for the game. This is accomplished in the retrospective by identifying beneficial practices, stopping detrimental practices and identifying new practices to be tried out in the next sprint. The retrospective is where much of the improvement of development practices occurs. Changes don t necessarily have to be large ones; a one percent improvement in the effectiveness of the team every sprint compounds into huge improvements over the long term. Finally Thanks for reading this guide. Please take a moment to review the terms listed at the start and review the sections for any that are not clear. The rules of Scrum are simple, but from these simple rules emerge vast improvements in how teams work together. They increase their productivity and enjoy their work more. They deliver value every sprint and are better at "finding the fun". Scrum is like chess; from the simple rules of chess emerge complex tactics and strategy that take a lifetime to master. Scrum is a never-ending pursuit for continual improvement, especially in the rapidly changing game development industry. Please send any comments, questions, suggestions or corrections to me through my website at Happy Scrumming! 5 Standing creates a sense of purpose for the meeting. If you don t believe it, try making some meetings standing-only and observe the difference. 9/24/12 Copyright Clinton Keith 14

16 Clinton 9/24/12 Copyright Clinton Keith 15