Agile development basics

Agile development methodology values: Individuals and interactions over processes and tools Working software over comprehensive documentation Responding to change over following a plan Customer collaboration over contract negotiation

These values have enabled agile frameworks such as Scrum, Lean, Extreme Programming etc.

Game development challenges

Feature creep ­ a term given to features being added to a project after the original scope isdefined. This happens for two reasons; the first is when the stakeholders see the game inprogress and request new features (so­called emergent requirements); two when a featuredoesn’t live up to its expectation so more work is added to find the fun.Feature creep and changes are inevitable. This is often the main problem with writing bigdesigns up front (BDUF): the goal is to answer all the questions about the game. The truth is wecan’t know everything about the game at the start. Knowledge comes only when we get thecontroller in hand and start playing the game at a decent frame rate on the targetmachine/platform. The only way to recognize the fun is to play it. We may be certain we’remaking a first person shooter, but knowledge of exactly what types of weapons are best islacking. We learn more and reduce the uncertainty as we shoot the characters in the game.

Over­optimistic schedules ­ Task estimation is not an exact science. Many things throw off theestimated time to complete a task:

The difference in experience and productivity between people working together on asingle task

How many other tasks a person is working on at the same time The stability of the build and tools used to complete the task The iterative nature of the task; its uncertain how many iterations will be necessary for

tuning and polishing a feature to “find the fun”

Controlling idea ­ A controlling idea is a bit similar to a business statement, but more directedat game features. It’s objective is to capture the essence of what the game is and where the funfactor is. The controlling idea’s essence and strength is in laying boundaries and goals.Whenever the team is faced with a choice of “should we add this” or “does this fit” they go backto the controlling idea and typically find the answer.

Production cycle:

Pre­production is the exploration of what a game is, so biggest challenge is to find the fun ofthe game that will drive the entire production.Production is a stage where the team fleshes out the story and surroundings to leverage themechanics created in pre­production. The challenge of production is to maximize efficiency,minimize waste and create predictability.

Concept ­ basic description of the game idea and mechanics that could be developed into a fullgamePrototype ­ a working/playable version of the concept that allows for the user to feel the gamemechanics and find the fun in the game, which proves if its worth developing further.

Pre­production ­ preparing the game design documentation based on the prototype and userfeedback; working out what is the fun factor of the game and figuring out the game around it.Production ­ making all the designs, code, assets, animation and everything necessary for thereleases during the production.Post­production ­ release, marketing, promotion and post­mortem for the game.

According to these stages as the game is developed, the team might find itself in a position ofgoing through each milestone (in waterfall methodology) and reaching the set goal only to realisethey’d rather be somewhere else with no time left to change much.

By applying the scrum method through iterative game development the goal will reflect thechanges during the production so that the time

Why Agile Game Development?

Knowledge is key ­ game development is primarily about learning what to make and how tomake it. It’s about reducing uncertainty over time. Agile development focuses on buildingknowledge about value, cost and schedule and adjusting the plan to match reality. Knowledge iscreated every day.Cost/Quality ­ costs can easily run high when developing a game, so it’s no wonder that mostgames fail to break even! More cuts made on the resources used to develop a game reduce thefun quality of the game.Finding the fun! ­ a benefit of iterative development is to develop a product in small steps andincrementally add features that add the most value to the game in the fastest and mosteconomical way. “Finding the fun” is the mantra of any iterative and incremental gamedevelopment project. The agile project curve approaches development in a value first approach.Eliminating waste ­ by finding the fun first, the team is able to find the value early in the projectrather than trying to retrofit it at the end. Simple iteration enables game developers to exploremore ideas. This makes it possible to enact the kill­gate model, where a dozen ideas arelaunched and narrowed down until the best remain.

Finding the fun:

Agile values in game development:

Individuals and interactions over processes and tools:

The main goal is to promote the team(s) to solve many of the production problems on their own.They manage the smallest details but none of the highest levels. They unburden the leadershipof managing minor details and enable them to focus on the big picture.

Working/fun game over detailed documentation

Some form of design documentation is necessary, but detailed documents create work that isnot necessary so much of the work is wasted in the end. If the game follows a detailed planup­front it won’t be the best game possible.

Responding to change over following a strict plan

The agile approach is to plan what is known and to iterate against what is unknown.

Structure of an agile project

An agile project is composed of a series of iterations of development. Iterations are shortintervals of time, usually 2­4 weeks, during which the game makes progress. Developersimplement individual features that have value for the end customer each iteration. Thesefeatures are called (user) stories. Iterations include every element of game development thattakes place in an entire game project:

Concept Design Coding Asset creation Debugging Optimizing Tuning and Polishing

Agile project make steps toward a goal. The point is to use the “inspect and adapt” cycle achievebetter results sooner through the ability to steer the plan toward a more desirable goal, ratherthan sticking to a strict plan and reaching the goal and then desiring to be somewhere else.

The game is reviewed at the end of every iteration, and the results influence the goal of futureiterations. This is the so­called “inspect and adapt” principle. Every 4 iterations the game isbrought to a release (build), which means the major goals are accomplished and the game is

getting near completion.

Agile game development flow

From left to right, studio management (stakeholders) and customers, identify the features andother requirements (tools and infrastructure needs) for the game. These features are placed ona list ­ Product backlog, that is prioritized by the Product owner. These product backlog items,(PBI’s) are expressed as stories that communicate the value of each PBI to the customer andstakeholders. Scrum teams commit to completing one or more stories from the product backlogevery iteration (this is called a sprint.), and demonstrating them in an improved version of thegame in each subsequent release (build) of the game.A Scrum master assists each Scrum team, helping them improve impediments to progress andensuring that they are following the agreed progress.

Scrum roles

Stakeholder(s) ­ define many of the items in the product backlog and work with the productowner to prioritize the backlog. These are some of the common stakeholder roles:­ Publisher/producer­ Marketing people­ Studio management

Product owner ­ establishes and communicates the vision of the game and prioritizes its

features. Also is often considered the “lead customer” as a voice of the end users, even thoughhe’s part of the team. The product owner is responsible for:

­ Managing the ROI of the game: he’s responsible for ensuring that the investment in the game isreturned with a profit which requires extensive knowledge on what the market wants.

­ Establishing a shared vision of the game: he’s a single voice for the vision that is shared withthe team in order to ignite creativity and ownership with the team and collaborate with them asthe vision evolves with the emerging game.

­ Knowing what to build and in what order: he owns the product backlog and determines theorder of features on the backlog. This order determines the order in which those features aredeveloped.

­ Creating release plans and establishing delivery dates: he manages release plans based onchanges to the goals or the progress from the team during sprints.

­ Supporting sprint planning and reviews: Establishing and updating the features on the backlog and their priorities Participating in sprint planning Accepting or rejecting the results of the sprint in sprint reviews

­ Representing the end user/player: he makes sure the game has the necessary value for theend user.

Scrum master ­ His role is to make sure the scrum is a success and he must apply theprinciples of scrum and guide the team through the practices.Scrummaster is responsible for:

­ Ensures impediments are addressed: the scrummaster tracks all impediments discovered inthe development process (bugs, crashes, meetings without results, constant distraction to theprocess, progress of each individual on the team on particular tasks...)

­ Monitors overall progress: he makes sure the team knows how well they’re performing againsttheir current goal on a daily basis. If they’re behind the schedule the team is informed as soon aspossible.

­ Facilitates planning, reviews and retrospectives: prepares all team meetings, agendas andmakes sure the time limit is agreed on for each meeting.

­ Helps the team communicate and improve performance: even with the most productive teamthe scrum master seeks new ways of getting more out of them. He might recognize problemsahead of the team but should never lead with implementation the solution but rather guide/allow

the team to see and own the solution to the issue.

The big picture

A game made with Scrum makes progress in 2­4 week iterations, or sprints, usingcross­disciplined teams of 6­10 people depending on the need to complete a sprint. at the startof a sprint, during the sprint planning meeting, the team selects a number of features from theproduct backlog. The team then estimates the tasks required to implement each PBI into asprint. The team only commits to features in a sprint they judge to be achievable.

Sprint meetings (daily scrum) can be held daily or 2­3 times a week, but are always limited to 15minutes (timebox) where the team shares their progress or any impediments in their work.Timebox is a fixed amount of time given to a meeting or a task. The 15 minute timeboxedmeeting will end at the 15­minute mark regardless of whether all the agenda items areaddressed, which pushes the team to be as short and to the point in a meeting as possible.

The principles of Scrum

As a framework Scrum is meant to have practices added and changed as teams and productsevolve.

­ Empiricism: scrum uses an “inspect and adapt” cycle that enables the team and stakeholdersto respond to emerging knowledge and changing conditions in real time using actual data gained

in the development process. scrum meeting enable teams to respond quickly to daily issues.

­ Emergence: As the game is developed we learn more about the game and what makes it fun,what is possible and how best to create it. Scrum practices don’t ban designs from beingdeveloped upfront. They acknowledge that we can’t know everything about a game from thestart.

­ Timeboxing: Scrum is iterative. it delivers value on a regular basis and enables stakeholdersand developers to synchronize and micro­steer the project as value emerges. Sprints are anexpression of this timeboxed practice.

­ Prioritization: Some features are more important to stakeholders and customers than others.Rather than approaching the development of a game by “implementing everything in the designdocument”, Scrum projects develop features for a game based on their value to the player whowill buy the game. This is what the product backlog is for.

­ Self­organization: Small, cross­discipline teams are empowered to organize theirmembership, manage their process, and create the best possible product within the timeboxes.They use the “inspect and adapt” cycle to continually improve the work.

Scrum parts

Product backlog ­ a prioritized list of the requirements or features for a game or the pipeline formaking a game. Example:

Add a new character/enemy on the second level Add a particle effect to the game Add online gameplay

The product backlog is allowed to change after a sprint. PBI’s that weren’t anticipated are thenadded, those that aren’t necessary are removed and the priorities changed if necessary. Thevalue of every feature is measured in terms of how valuable it will be to the player. Thisminimizes work based on assumption.The most valuable items in the backlog are broken down into smaller features to fit into a sprintthat the team can handle.

Sprints ­ a scrum project makes progress in sprints, which are in effect the heartbeat of theentire project. sprints have a fixed duration 2­4 weeks (can be shorter if necessary) and the teamcommits to the PBI’s they can complete in a single sprint. Sprints produce vertical slices offunctionality, sort of like mini­projects on their own that contain everything necessary to get thegame to a shippable state (coding, design, asset creation, debugging etc.)At the end of a sprintthe team has a new build of the game that demonstrates that the sprint goal was reached.

Releases ­ are a set of sprints meant to bring the game with major new features to anear­shippable state. A typical release lasts between 1­2 months, sometimes more.

Sprints

Planning ­ the stakeholder, scrummaster and product owner meet with the team to groom thebacklog and identify the sprint goal. The sprint planning meeting creates the sprint backlog thatdefines the work that the team commits to completing buy the next sprint review.

Prioritization ­ this is where the team meets to set the sprint goals for the high priority items onthe backlog with the product owner describing the features on the backlog that the team needs tounderstand in order to evaluate. This is where the team raises questions, concerns about detailsand requirements for each item. If the items are too large for a single sprint they are brokendown into several PBI’s that can fit into sprints.

Sprint meeting:

What have I done since the last meeting? What am I going to accomplish for the next meeting? What are the problems slowing me down?

Sprint review: What things should we stop doing? ­ Practices that have brought problems in the dev

process What should we start doing? ­ Practices that help the dev process What is working well for us? ­ Practices that we should continue in the process

Sprint resets

When the sprint that the team started working on doesn’t seem achievable for a variety ofreasons (sprint goal needs to change, running out of time, wrong estimate etc.) the team has 3choices:

1. Work overtime to make up for the difference2. Negotiate with the product owner to remove one or more of the lower priority PBI’s or

remove part of the PBI3. Request a sprint reset. Set a new sprint with a more achievable goal.

Everyone on the team needs to be aware of the cost of each of these options for the productioncycle, both money and time­wise so that the best option can be chosen. If the sprint is reset allthe unfinished PBI’s are returned to the backlog and the team returns to sprint planning.

Stories

Stories are a template for expressing the value of a feature/item to the end user. Team

completes one or sometimes more stories per sprint. Usually the stories are formulated in thismanner:

As a <user role>, I want <goal> [so that <reason>].

User role ­ a player of the game or a user of the pipeline who benefits from this story Goal ­ the clear goal of the story. This is a feature or function in the game or pipeline. Reason ­ benefit to the player when this feature is used in the game.

Spikes

Spikes are important for video game development. They are timeboxed stories that addressareas of great uncertainty and their goal is to create knowledge that help the product owner

evaluate the cost of other stories. Example:

“As a product owner I want to see a mock­up video/animation of how our fighting mechanicwould look on an iPhone”

Stories are sized appropriately to fit into a sprint, if they are too big they’re disaggregated intosmaller ones, or if too small can be combined into a larger story to manage more easily by theteam in a sprint. From these sprints a list of tasks can be created so the production can beclearly tracked over time.

Task list (Boards in Trello)

What happens to the design document?

Stories collected on a product backlog are intended to replace much of the designdocumentation. Best practice is to still maintain a technical design document that lists technicalrisks and strategies for overcoming those risks, but use it to help prioritize the backlog, which iswhere all work done by the team originates.

Product backlog

Prioritizing

Value ­ the value that the story has for the player is the primary criteria in determining thepriority of that story on the product backlog. By focusing the team’s effort on addinghighest value every sprint, the product owner is generating the best possible ROI.

Cost ­ is the key factor is product owner’s ROI calculation. Some highly desirablefeatures might cost too much to implement. Two equally valuable features are oftenprioritized by cost, so the lower­cost feature is given a higher priority.

Risk ­ implies uncertainty about value and cost. stories with higher risk are placed higheron the product backlog to refine a product owner’s understanding of value and cost of afeature.

Knowledge ­ sometimes the product owner doesn’t know the value, risk or cost of afeature. So they might introduce a timeboxed story (spike) for a prototype limiting howmuch time team spends working on it to gain more knowledge on the item.

Scrum team(s)

Scrum creates conditions that enable teams to achieve greatness through its practices andprinciples.

Cross­discipline teams ­ enables teams to deliver features and mechanics thatrepresent clear value for the user

Self­management ­ enables teams to select the amount of work they can commit to

every sprint and complete it through whatever means necessary Self­organization ­ enables team to have a degree of authority and responsibility to

select their membership role True leadership ­ provide leadership focused on mentoring and facilitation to free the

best performance possible from the team by finding the approach betweenmicro­managing teams and throwing them in over their head. Both of these extremes willlead to failure.

Cost of change

Changes made late in the project can result in costs that are a magnitude or more greater than ifthose changes were made early in the project.

Too much architecture upfront It slows the introduction of new features upfront Architectures designed upfront often need to be changed later Changing bigger systems is more costly than changing smaller ones

Role of documentation

A goal of a design document is to share the vision about the game with the team. Relying solelyon a document to share a vision is full of weaknesses:

Documents aren’t the best form of communication ­ much of the information between anauthor and reader is lost.

Vision changes over time ­ documents are poor databases of change. Don’t expect teammembers to revisit the design documentation to find modifications. Daily conversation,meaningful sprint and release planning and reviews are all places to share vision.