Extreme Programming for Games

AN INTRODUCTION

Often young game developers ask me how to build a large scale development process with a large team. I thought I would write this article outlining the best practices I have learned and leveraged over the years.

Note: I started a new independent game publishing company called Ex Populus. Check it out: https://expopulus.com/

Because of AGILE and other business practices, I led the build of a platform that generated nearly $2M per month with only $150k in capital raised. Earlier in my career I was much more self reliant and leaned too much on my own intuition. Now I depend much more on external validation to drive the direction of product and game development.

Prior to 2010 or so, common issues with the teams I worked with were:

• Fighting for “control” because of a misunderstanding of roles
• Frustration because of not feeling empowered or respected
• Lack of certainty around decisions being made about the product
• Over reliance on engineers to solve all problems
• Bugs!
• Lack of clarity on the roles of designers and product managers
• Over reliance on intuition, under reliance on market feedback

After spending half a year with Pivotal Labs, I adopted the Extreme Programming version of AGILE as my discipline. There are various versions of AGILE, and plenty of debate about which is best. Those debates are likely to never be settled, but more importantly, this is the discipline I was formally trained in.

Having myself and my team trained on-site by Pivotal solved virtually every development problem in my previous company Signal Zero, while speeding up the development process dramatically. As a result, Extreme Programming is a discipline I have convictions about. Further, I respect the months it took to train the nuance and values of the process. Switching, for example, to SCRUM or Crystal wouldn’t be an easy transition, as I’d expect an engagement with experts over the course of several months installing best practices to make the change a success.

AGILE GAME PRODUCTION — EXTREME PROGRAMMING

Most think of AGILE as a software development approach, and it is, but its primary purpose is a business solution. As an operational framework, it creates a process that leads teams to financial success and business value. AGILE solves all of these problems well. One of the key tenets of Extreme Programming is to avoid solving problems that do not currently exist. Often developers relate their previous experiences to the current project, which can lead to them spending significant amounts of time arranging the code for scale or spending time on “code cleanups” (YAGNI). When working in this framework, each feature iteration is subject to user testing. If the iteration fails the user test, it will be either re-written or abandoned. Because of this, time spent optimizing for scale or “cleanliness” is often a waste, because it is unknown if the feature will even be included in release. Extreme Programming is built for speed and market relevance.

AN OVERVIEW OF ROLES AND RESPONSIBILITIES

With Extreme Programming / AGILE, there is no single individual “in charge” of the product. Instead, each role is empowered with specific decision making authority, while being encouraged to give feedback in the areas where authority lies with others. A separation of roles is important to avoid the conflict that can come with dual agency.

A developer may avoid the implementation of a better design element and opt for something that is easier to build, in turn lowering the product’s potential. Because of this, developers should not have design authority. A Product Manager may create designs that nickel and dime users to the point that they turn away from the product, which is why designers are in charge of user experience. A designer may scope creep a project and push it over budget, which is why scope is under the authority of the product manager. Because each role has authority in its own domain, there is a functional and productive set of empowerment and boundaries. This system of checks and balances keeps the project moving forward on budget and with a product / market fit.

Each role on an agile team has specific responsibilities and authority. Authority lies with the individual that ultimately makes the decision on a given topic. It is important to remember that in AGILE, the spirit is to work through problems and challenges as a team. If another individual on the team has authority on a given topic, that doesn’t mean you should remain silent. Expressing your ideas, concerns and thoughts is not only welcome on an AGILE team, but should be considered required. Thinking through issues together is the point. Decision making authority is given by role to insure that the project moves forward as reasonable people can disagree. When there is no consensus, the project must move forward anyways.

Product Managers: Sound Business

The producer or product manager considers the business needs and value. On the development team, they represent the business by making decisions about priority and scope. They support the team by putting each story through acceptance testing to ensure each requirement is met. They are the primary individual in the group writing the user stories, but often with support and feedback from the designer. Sometimes they will push back on designs to keep scope under control and to help ensure the project does not die as a result of scope creep and budget is maintained.

Designers and Artists: User Happiness

Designers and artists are the user’s advocate. They are there to ensure that the user has the best experience possible with the game, its UI, its systems and the overall experience. Whether or not the game is fun to play, easy to navigate and something that will keep players coming back is the primary responsibility of the designer. As a result, all design decisions are made by the designer as long as they are in scope.

Developers: Functional Software

The developer’s job is to insure the game functions as designed without any performance issues or bugs etc. They should understand the big picture of the game from the start, and create a pipeline that is flexible on demand with design needs, user growth and other important elements. The developers ultimately make decisions about engines, tools, language and other elements of technology used in the development of the game.

CEREMONY

Production teams are successful when communication is organized. The majority of the time developers, designers and creatives should be focused on their craft without much interruption from others. This is facilitated by holding consistent and regular meetings, each with their own goal.

Morning Stand-up

Every morning will begin with a 5 minute stand-up. Each individual in the circle should share what they did yesterday and what they plan to do today. We try to keep it under 1 minute per person so the stand-up is focused and on point. Since production happens with a handful of remote teams, each standup session will be recorded and shared with the other teams each day.

Iterative Planning Meeting (IPM):

On Mondays, there should be a planning meeting led by product managers and/or producers. In this meeting, any new user stories should be estimated by the engineers and developers. Engineers and Developers should never estimate time. They should always estimate effort utilizing 0,1,2,3. Each developer should give their opinion on effort, and differences should be discussed. Senior developers should not automatically over rule. The point is to gather insights, concerns etc. Once discussed, developers should agree on effort or at least have a majority. If the story is larger than 3, the product manager should break the story into smaller stories.

Creatives and Designers are present at these meetings as a resource to answer questions about the designs attached to the stories.

Once estimation is finished, the product manager may change priority. Engineers and developers should always work based on the priority set by the product manager. If there is a technical reason that the PM may not be aware that a priority should change, then the developers should discuss this with the PM. These situations should be infrequent.

All remote teams should be a part of IPM via video conference. These are important meetings to plan the week’s work and keep everyone on the same page.

Design meetings

All senior members of the development team should be a part of the design meeting. It gives product managers and developers early looks at design and opens a forum for new ideas to be shared and design to receive feedback.

Oftentimes developers will express concern about the implicit scope that some designs may have. It is important to remember that scope is the domain of the Product Manager. Designers should never feel they need to compromise the scope of their design, unless instructed by the product manager.

Design meetings are often passionate. A good designer will spend most of the meeting listening. What the design ends up being is the designer’s decision as the ultimate authority of the user experience. As a result, designers shouldn’t feel the need to defend their designs on a personal level. Try and listen to the feedback and consider it within your wider view of the user’s experience. The rest of the team may be your first insight into challenges that could arise in user’s tests later on, it’s up to you to be dispassionate and consider all elements prior to making your decision.

Retrospectives

On each Friday and after major releases, teams should hold retrospectives. “Retros” should be led by a different member of the team each week. These meetings typically have 3 columns on a whiteboard: Good | Neutral | Bad with the understanding that anything that is written in a given column is notable and worth discussion with the group. Each team member has the opportunity to write topics in each column. The meeting leader names off each item in each column and the group discusses.

Action item lists are often created to address issues and concerns. It’s important to make sure each action item is assigned to someone on the team, otherwise the item may never be addressed.

Teams around the world should decide if they want to share their retro videos, or have them on a video conference together based on feasibility.

DEVELOPMENT PROCESS

When working as a developer in the extreme programming framework, some parts of the approach will be a relief, while others may take some getting used to. The objective is creating speed, not by thinking or coding faster, but by isolating and focusing on the truly important and critical elements.

Developers should never quote time. When product managers or others ask “how long something will take”, you are within your right to remind them that all estimation in AGILE is based on effort (Hofstadter’s law). The project tracker will predict release dates and timing based on the average velocity of point completion, so product managers can estimate time without the involvement of developers.

TDD is required and 100% coverage should be the goal. Developers should log in to the project tracker and always work on the next user story in line. Once you’ve read the story, you should always write your test for it first based on the acceptance criteria (also consider Gherkin) in the story. The test should fail. You know you have completed the story when the test passes. Stop. You’re done. There is nothing left for you to do on this story, because the test has passed. Commit and move to the next story. (YAGNI) Details on process here.

While you may be tempted to think through an overarching architecture for the project, try to avoid this. The design team won’t know what the product is going to be until its ready to be released and well, at that point it is ready to be released and you’re done. The important thing is that the tests are passing. That means everything works. When tests break, that is a very good thing. If you have a good discipline, you will have good coverage which means bug detection is automated and easy. The design team is on a metaphorical treasure hunt to find what the users want. They will be wrong, and requirements will change. This means tests will fail, but that is why they are there.

When you’ve finished a story, deliver it in tracker. This tells the product manager that you’re done and they need to test your work. It also keeps them in the loop on progress and makes it less likely that they will walk over and interrupt you asking for status.

When you see potential problems arising in the code, talk with your product manager before working on refactors, updates or anything else. Product Managers are ultimately in charge of scope and priority, so all stories including refactors should be prioritized by them.

BUSINESS PROCESS

Product Managers represent the business’s interest on the development team. Each Product Manager should be working with teams of 10 or less including developers and designers. Developers should write and prioritize every user story before they end up in the backlog. Developers and designers may make story suggestions and put them in the icebox for review and re-writing by the Product Manager.

Writing good stories is a skill that takes time to master. Below is an example of a bad story

“Write code so we can make the guy jump when we press space bar. Also, make a tool so that designers can edit values to balance some jump controls.”

The above story is unspecific, unclear and can probably be broken into 4 or 5 stories. Let’s take a crack at writing this properly:

“As a user, I can see Mario jump up and return to the ground when I press space bar”

“As a designer, I can modify the height of the jump by tuning a variable in Unity’s editor”

“As a designer, I can modify the upward speed of the jump by tuning a variable in Unity’s editor”

“As a designer, I can modify the left / right control I have while Mario is in the air by tuning a variable in Unity’s editor”

“As a designer, I can modify the downward speed of the jump’s descent by tuning a variable in Unity’s editor”

We’ve taken one unclear story and turned it into 5 clear stories. This will help the development team understand exactly what is meant, while also helping them work on development in small bite sized pieces. As the developers finish and deliver each story, the product manager will be notified via the tracker, thus keeping them updated on progress without needing to interrupt the developer’s concentration by walking over and asking them. Product Managers should never rush the process of writing stories. It is the singular rail that everyone on the development team follows so attention should be given to detail and clarity.

Product Managers will often “pair” with designers when writing stories. Designers may have a new set of designs ready to be implemented, so the Product Manager should ask the designer to sit with them as they write the stories for the new designs. During this process, the Product Manager should be at the keyboard writing, with the designer commenting as needed to insure the intentionality of the design is appropriately encapsulated in the stories. All designs should be attached to the story. Designers may also wish to leave comments on the story directly in the comment section.

Product Managers run the IPM. This is the weekly meeting used to keep everyone on the same page, estimate new stories and understand scope.

DESIGN PROCESS

The Designer is the user’s advocate on the development team. Designers are often misunderstood as a sort of ultra-intuitive shaman that has “all the good ideas”. This isn’t true. The designer’s job is to solve problems that arise out of user testing. Design in games can be broken into a variety of disciplines: UX, UI, Interaction, Systems, Mechanics and more. In any event, designers should view their role as three sided: Understanding the market, uncovering user problems, solving user problems.

Understanding the market often involves uncovering trends in the market based on popularity and monetization opportunity. These broad strokes are the “top of the creative and design funnel” that from the very first stages of the project will help us to insure a product / market fit.

As production begins, uncovering the problems the user faces can often be the easier part of the job. Having a process in place to get new features and iterations that have been built in front of users in test environments is mandatory. This can be done with play tests, focus groups, pre-marketing campaigns and more. The design team should make an effort to have these sorts of test weekly, but at minimum should happen twice per month. Based on the results of these events, designers should determine what problems need to be solved, features removed and elements added.

Designers should also run a design meeting each week, in which they share with the rest of the development team the problems that are being addressed as well as new designs that are coming down the pipeline.

Market Feedback:

It is important not to wait until the product is finished before getting feedback from users. As a matter of fact, user engagement and feedback should begin before production and continue throughout the development process.

User Interviews:

Oftentimes we begin production with our own assumptions and intuitions about what the audience wants. It is impossible for all of those assumptions to be correct. To mitigate this risk, we identify our target market demographic and reach out to some of these individuals to request a meeting. In these meetings, we simply ask them what they like about the games they play in the same segment of the market.

Persona Development:

If we interview enough users, we can begin to see “personas” form. Generally there are 3–5 different types of players or users. They play the games for different reasons and each one is looking for a different aspect of the experience. We can give these personas names and leverage them in our user stories later on to bring on valuable context that a user story is for a given play style.

User play testing:

Depending on the stage of development these tests should be held weekly or monthly. Users (that we don’t know personally) should be brought into the office to test features, mechanics and systems. It is a best practice to have exit interviews from these sessions, it is even more valuable to record the session. We can find points during the gameplay where the player becomes frustrated or elated that they may not share in the exit interview.

Pre-marketing and Taste Testing:

Another great way to get market feedback is by placing images, videos and gifs of various look ideas or gameplay elements into ad campaigns on Facebook, Instagram or Google. Based on engagement rates set against benchmarks, you will have a good indication of user interest. These campaigns can also be used to get new players to come to the next play test by driving them to an invitation page!

Early Access / Beta:

Finally, early access or beta releases are great ways to get the game in front of a larger audience before doing a full release. At this point, most assumptions should already be removed from the game, but seeing a larger number of people interacting with a more complete game should be a great opportunity to get additional feedback from users before going all in on a big marketing spend for full release.

Other Considerations:

Pair programming can provide a variety of benefits. First, it is easier to solve hard problems as a team. Having someone to talk through a problem with can sometimes get you to the finish line more than twice as fast as going it alone, justifying the 2x resource allocation on the problem. It is also a great way to share knowledge among developers. As each developer follows priority, they will often find themselves working in the code that was written by a colleague. Pairing from time-to-time is a great way to keep everyone familiar with the code base. When pairing, it is important to make sure each individual is contributing. Avoid scenarios where one developer is quietly working, while the other is daydreaming or checking their phone. Pairing 100% of the time isn’t necessary and it is often easier to get through tedious, low effort stories on your own. Initially, it is best to let developers decide when they need a pair, but if developers are stuck on stories, it may be the right time for the product manager to work with the developer to find a pair that can be a wingman on a hard problem.

It is good for individuals to be in the office at the same time. Setting up regular working hours where everyone agrees to be available at the same time works wonders for communication and productivity. Sometimes, individuals may prefer to work later in the day. Decisions about work hours should not be different for each individual and should be made based on what is best for the productivity of the team as a whole. Tele-commuting should generally not be allowed, unless and individual has a circumstance (doctors appointment or school function for children etc.)

Look Development and Vertical Slicing:

Games that are in the mid-market for PC and Console often make bold statements with their graphical styles. In this segment of the market, it is not graphical fidelity that is most important, but the style and authenticity that attract the most players. As a result, it’s probably not necessary to push the limits of the engine to squeeze out every last inch of performance. Instead, designers, artists and technical artists should give time to a process of “look development” experimenting with colors, textures, models, animations, lights and shaders to create an overall look for the game. Vertical slicing lends itself to this process. There is no need to wait for the game to be made to create a scene in the engine that likely excludes all of the game mechanics, and instead focus entirely on the way the game will look. Once the look team is satisfied, they can bring their approach, assets and values into the main game project.

Complete the features, then balance and tune:

My own personal conviction with game development is to focus on getting all of the features into the game before worrying too much about mechanical balance. Of course, building and balancing can happen at the same time depending on the priorities and availability of staff. That said, the first priority should be to build each proposed feature to see how they all interact with each other. The broad stroke assumptions on design should be tested against each other before too much effort is given to optimization and ultimately perfection. Once the main feature set is in the game, decisions are generally first made about removing features, adding new features and then ultimately perfecting each element and how it interacts with other elements and features. In short, the first major development cycle should be getting all the “stuff” in the game. Making it perfect comes second.