Game Production: agile development with Scrum€¦ · 8 1. Introduction, origins, history...
53
Transcript of Game Production: agile development with Scrum€¦ · 8 1. Introduction, origins, history...
1
Game Production:
agile development with Scrum
Fabiano Dalpiaz
2
Copyright and acknowledgement
These slides are based upon and extend
Mike Cohn’s “Introduction to Scrum”
• http://www.mountaingoatsoftware.com/presentations/an-introduction-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-video-game-development-22871287
Paul Miller’s article “Top 10 pitfalls using Scrum” on Gamasutra
• http://www.gamasutra.com/view/feature/3724/top_10_pitfalls_using_scrum_.php?print=1
3
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
4
1. Introduction, origins, history
Motivation
Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product
Development Game”, Harvard Business Review, January 1986.
“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.”
5
1. Introduction, origins, history
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
Scrum in 100 words
6
1. Introduction, origins, history
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
Scrum origins
7
1. Introduction, origins, history
The success of Scrum
8
1. Introduction, origins, history
Commercial software
In-house development
Contract development
Fixed-price projects
Financial applications
ISO 9001-certified applications
Embedded systems
24x7 systems with 99.999% uptime requirements
the Joint Strike Fighter
The success of Scrum: application areas
Video game development
FDA-approved, life-critical systems
Satellite-control software
Websites
Handheld software
Mobile phones
Network switching applications
ISV applications
Some of the largest applications in use
9
2. Overview of Scrum
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
Characteristics
10
2. Overview of Scrum
The Agile Manifesto: the importance of…
Process and toolsIndividuals and
interactionsover
Following a planResponding to change over
Source: www.agilemanifesto.org
Comprehensive
documentationWorking software over
Contract negotiationCustomer collaboration over
11
2. Overview of Scrum
Scrum, illustrated
12
2. Overview of Scrum
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
Sprints
13
2. Overview of Scrum
Sequential vs. overlapping development
Source: “The New New Product Development Game” by
Takeuchi and Nonaka. Harvard Business Review, January
1986.
Rather than doing all of
one thing at a time...
...Scrum teams do a little
of everything all the time
Requirements Design Code Test
14
2. Overview of Scrum
Plan sprint durations around how long you can commit to keeping change out of the sprint
Golden rule: no changes during a sprint
15
2. Overview of Scrum
Anatomy of the Scrum framework
16
3. Scrum framework: roles
17
3. Scrum framework: roles
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
Product owner
18
3. Scrum framework: roles
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
ScrumMaster
19
3. Scrum framework: roles
Typically 5-9 people
Cross-functional
Programmers, testers, user experience designers, etc.
Members should be full-time
May be exceptions (e.g., database administrator)
Team
20
3. Scrum framework: roles
Teams are self-organizing
Ideally, no titles but rarely a possibility
Membership should change only between sprints
Team
21
3. Scrum framework: roles
Team, in game development
22
4. Scrum framework: ceremonies
23
4. Scrum framework: ceremonies
Sprint planning
24
4. Scrum framework: ceremonies
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
Sprint planning
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)
25
4. Scrum framework: ceremonies
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
The daily Scrum meeting
26
4. Scrum framework: ceremonies
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
The daily Scrum meeting
27
4. Scrum framework: ceremonies
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
The sprint reviews
28
4. Scrum framework: ceremonies
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
Sprint retrospective
29
4. Scrum framework: ceremonies
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?
Sprint retrospective: start/stop/continue meeting
This is just one of many ways to
do a sprint retrospective.
30
5. Scrum framework: artifacts
31
5. Scrum framework: artifacts
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
Product backlog
32
5. Scrum framework: artifacts
Product backlog: example
33
5. Scrum framework: artifacts
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>
User stories
34
5. Scrum framework: artifacts
Often via a user story card
Front: user story itself
Back: acceptance criteria (conditions of satisfaction)
How to write user stories?
35
5. Scrum framework: artifacts
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
On good* user stories: INVEST
36
5. Scrum framework: artifacts
The product backlog as an iceberg
37
5. Scrum framework: artifacts
A short statement of what the work will be focused on during the sprint
The sprint goal
Database Application
Financial services
Life Sciences
Support features necessary for
population genetics studies.
Support more technical
indicators than company ABC
with real-time, streaming data.
Make the application run on SQL
Server in addition to Oracle.
Videogame
Do the porting from Java 1.6 to
Java 1.7
38
5. Scrum framework: artifacts
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
Managing the sprint backlog
39
5. Scrum framework: artifacts
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
Managing the sprint backlog
40
5. Scrum framework: artifacts
A sprint backlog
41
5. Scrum framework: artifacts
Primary method of tracking progress
A burndown chart shows how much work is left as of various dates
Two types
Release burndown
Sprint burndown
Burndown charts
42
5. Scrum framework: artifacts
A sprint burndown chart
43
5. Scrum framework: artifacts
Sprint backlog and corresponding burndown chart
44
6. Scaling up with Scrum
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
Scalability is needed
45
6. Scaling up with Scrum
Scrum of scrums
46
6. Scaling up with Scrum
Scrum of scrums (or meta-scrum)
“Managerial”scrum
47
6. Scaling up with Scrum
Scrum of scrums of scrums
48
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
49
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
50
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
51
References
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.
Mandatory
52
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
53
References
Websites and papers
www.mountaingoatsoftware.com/scrum
www.scrumalliance.org
www.controlchaos.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
