A Faster Way to Find the Fun

A Framework for Success:

Game development is truly a unique experience.

It has challenges that every project faces – scope, schedule, budget, stakeholder expectations - but also a distinct challenge that is unlike any other industry:?

You need to deliver a product that people actually want to play.

Many successful studios have shutdown, been acquired, or subject to mass layoffs because they couldn’t replicate their initial successful titles. An untold number of games have never seen the light of day because although the vision was great, the team wasn’t able to create it together.?

As I read about these studios, the challenges they faced, and games that “could have been,” I became interested in what processes teams could use to navigate the challenges of game development successfully?

My search led me to “Agile Game Development” which I believe is a worthy read on many different levels.

“Agile Game Development” is a wonderful overview of how Scrum can be used as a framework to build great games and successful teams who can continue to produce them, well into the future.

There’s a lot of ground that’s covered and insights that can be gained from this book. Below is an overview of my article:

“Agile Game Development” - A Brief Synopsis

If you are interested in developing games that are fun to play, this book is full of advice on how to do just that. The book’s main thesis is that when it comes to game development, the use of Scrum is a great framework to “find the fun” faster.

In my opinion, 3 reasons why reading this book is worth your time:

1. It’s as insightful as it is practical. You’ll “level up” by reflecting upon how many game development teams have overcome a myriad of challenges using Scrum.
2. It’s as useful to beginners as it is for experts. For beginners, the Scrum framework is covered + all the basics of what makes a team “Agile.” For experts, the insights and perspectives shared leads to a lot of “aha!” moments.
3. It explains how each individual role within a game development project works together. “There’s no ‘I’ in team” is practically demonstrated, every discipline iterates their work towards one shared and common vision of a great game.

The remainder of my article covers insights I gained while reading “Agile Game Development.” While I gained many:

• I elaborated on the ones I believe have the biggest impact as I’ve seen the same types of problems (and similar solutions) in different industries, companies, and projects.
• I do not attempt to summarize the entire book, as it would take away from the many valuable lessons you can learn from it. Scrum, like any skill, requires practice. There’s no shortcut to it.

I start off with the first insights a lot of game development teams may be able to relate to when they try to explain what they do to someone outside the field. I like to call it, “The Legend of Game Development.”

The Legend of Game Development:

People play a great game and are amazed by how fun it is:

• Great mechanics!
• Interesting levels!
• Engaging gameplay!
• Beautiful artwork!
• Memorable characters!

They start to wonder about who made the game, and unfortunately, imaginations start to run a little wild. The classical misconception:

• A handful of developers
• Doing nothing but fun and creative work all day, every day
• Creating one smash hit after another
• Resulting in never ending fame and fortune
• All smiles + sunshine + rainbows

“Wow - how fun it must be to make games!”

?Fewer jobs could be farther from reality...

For anyone who’s built a game in any capacity – for an AAA studio, a computer programming class, an independent studio, a personal project - you are well aware of how difficult making a successful game can be. Let alone trying to make a successful game on scope, schedule, and budget.

The days of one person creating everything from the artwork to the code are long gone. It’s not uncommon for hundreds of people to be involved in the development of one game.

As each game is different, there’s no one formula, but sufficive to say a great game is made by:

1. Hard-work over many months if not years
2. Dedicated and thoughtful teams
3. Multiple disciplines
4. Incredible amounts of effort going into each mechanic, level, character, line of code?

Why then are games so hard to develop? I like to describe developing a game, “The hardest of all levels.”

The Hardest of All Levels

The game industry is well known as being one of the toughest to succeed in – it’s difficult to build a game, let alone make one popular and profitable enough to make the next.

When it comes to the pressures associated with development, each game has to overcome multiple challenges in multiple areas and disciplines:

How Scrum Can Help

Fortunately for development teams, Scrum is a way to help you reduce many of the difficulties and uncertainties associated with game design, production, and development. It’s not a magic wand, it doesn’t do away with industry challenges, economic downturns, or the general problems you’ll face trying to develop something new and unique.

Rather it provides a framework that when followed correctly has many benefits for game development. Here are just a handful from 3 areas:

If You Are New to Scrum and Agile

The book is easy to follow along with but covers a large amount of ground with a fair amount of depth. Complex topics and ways of working / problem solving are often written in simple language, but solving problems is not easy, it takes practice.

If you are new to Scrum | Agile, my recommendation would be:?

1. Read this book over 2-to-4-week period, a few hours a day
2. Allow ample time to review the Scrum framework
3. Think how the concepts and examples provided can be applied in your current role

However, one great aspect of the book is that each section can be read as standalone. If you are facing a specific challenge - you can jump right to the section that interests you most.

What Scrum Is:

The book does a wonderful job of explaining the Scrum framework, and you could also reference organizations like Scrum.org if you are unfamiliar with Agile projects.?

A good litmus test would be to examine the overview below. If you can articulately describe what’s going, how each role works, what are the artifacts from each area, etc., you likely don’t need additional Scrum training:

If you are not as comfortable with Scrum, then a great place to start would be with the Scrum Guide (again at Scrum.org).

Given how well the book and Scrum Guide provide an overview of Scrum, teaching the entire framework is not necessary for my article. However, a brief recap of 4 Scrum concepts as it relates to game development is useful:

• Sprints: The work that moves your project forward are contained ("time boxed") within Sprints. Each and every Sprint should get you closer to developing features in your game that add value.
• Ceremonies: Supporting the Sprints are ceremonies, essentially “events” that are repeated with the development team to help them plan, communicate, review and improve. The purpose of ceremonies is to create transparency of the work being developed. (More on this later.)
• Backlog: It’s essentially your prioritized list – what the team should work on first, second, third, etc., all geared at making a proven fun and functional game. For example, you likely want to develop your core mechanics first before building 15 different levels you “think” they’ll be used in. (Again, more on this later.)
• Potentially Shippable Game: In the end, that’s what your work, Sprints, and planning is all about – every event, role, and artifact within the framework is there to help support you creating incremental releases, bringing your game one step closer to market.

What Scrum Isn’t:

Before we go further - let’s talk about what Scrum is NOT.

Of late, there seems to be a backlash against Scrum and Agile in general, perhaps due to some misconceptions, a few of them I highlight below:

Scrum is a great framework to explore, to iterate, to build. It’s not a “short cut” to being a good designer, programmer, visual effects artist, or project leader. It offers no immediate solutions on how to make a great game.?

In sum, you’ll still need an inspired team with the right tools, knowledge, dedication, and plenty of enthusiasm to make your vision a reality.

In my next section, I expand upon what Scrum can help us avoid. Mainly, large planning documents that are created prematurely.

“When X” Doesn’t Mark the Spot

Unfortunately, it’s hard to break the theory that everything about a project can be mapped out right from the beginning. There’s still a misconception that large amounts of upfront documentation leads to 100% project delivery success. As such, these types documents are still very common:

• Comprehensive Game Design Documents
• 1,000+ Line Project Plans Outlining "Every" Task + "Every" Potential Risk
• Requirements Documents that Attempt to Define the Truly Unknown

?In other words the development team is often asked to show where “X” marks the spot well before “X” has really even been understood.

While a lot could be said about good planning, preparation, and written expectations when it comes to “find the fun” in a game development project, the word that most often is forgotten (or ignored) is “find.”

• ?“Find” means we are learning and growing our knowledge base as we are iterating on the game
• “Stick to the plan," when the plan doesn’t take into account what is unknown is wishful thinking at best that we’ll ever “find the fun”
• “Find” can sometimes means “explore” and “explore” can’t be 100% mapped out in advance

The main problems with thinking we know everything there is to know up front is wasted work, which I expand upon next.

Throw Away Assets

There was joke in one of my previous departments that no project would ever cost less than $100,000 and take less than 2 months to deliver because of all the overhead management requested us to do up front before anything started:

• Estimate and plan every task down to the dollar and day
• Detailed calculations and projections on ROI for features that weren’t proven
• Estimates and forecasts to get 100% accuracy, even if many change controls will be needed later

?In a similar vein, the book points out that the biggest waste of in the traditional game development process is “throw away assets.”

?Some examples I've seen / thought of to illustrate what they may be:

• ?Levels that don’t work because a core mechanic has changed mid-project
• Lots of artwork and visual assets that no longer fit the levels because of the same core mechanic change
• Characters and dialouge created in great detail that have to be scrapped to meet a ship | deploy date

While the list can go, what all these examples tend to have in common:

• ?They were created in siloes, as a “part” not yet understanding the “whole”
• Integration of these assets was believed to be successfully accomplished at “project end”
• Half of the team made them, the other half was expected to “make them fit”
• They represent time, money, effort, and talent that was frankly wasted?

The concept of “wasted assets” is not unique to games, it can happen on any project where we think we know the ends result in advance.

What’s unique about game development and wasted assets is perhaps the margin of error is much thinner to make up for the resources used:

• As stated earlier, time is rarely on your side in game development
• If this is an independent developer, wasted features at the least could mean less resources available for the next game, at worst it could mean a closed studio
• If this is a large studio, missing a ship | deploy date could mean loss of market share

It’s important not to waste an time, energy, or effort on feature development. The person that is most helpful when it comes to prioritizing what should be worked on, I talk about next.

The Importance of the Product Owner

The Product Owner is one of the most important roles in the Scrum Framework, and for good reasons: 1 Product Owner + 1 Product Backlog = Strong Project Direction.

However, problems on the project, such as wasted assets, can occur when the product owner role starts to break down or dysfunction. The book mentions 5 types of this scenario:

From personal experience, when a product owner: isn’t there, available, or doesn’t understand their role - life on a project can get difficult. Decisions, priorities, and directions can turn into “best guesses” from the development team, which may not be in line with stakeholder expectations.

If the product owner role is dysfunctional resulting in wasted assets being created, this typically leads to what is commonly known as “crunch” time when it comes time to ship | deploy your game.

I do believe, along with the book, that “crunch” can be avoided, more on that next.

Crunch Can Be Avoided

“Crunch” is a term mainly associated with the game development industry – expected overtime, 6-day shifts, mounds of extra work leading up to a game’s ship | deployment date. Although it would be nice to think these are a thing of the past, they are still prevalent.

From my experience, I’ve seen crunch in many industries, it’s just not called that. Any project that has a fixed deadline is almost assuredly going to run into some form of crunch time.

It’s not just the overtime that could be harmful to the inspiration, creativity, and camaraderie of a team. Here are some “symptoms” of crunch I believe that could be just as damaging:

• ?Presentations are being created the day before (or morning of) because everyone is busy
• A “hero rises” scenario. One person puts in intense effort to get a project completed
• Meetings that use to be once a week are turned into daily calls
• Status reports are now expected end of each day and in great detail
• Project plans may be asked for in addition to status reports

What’s typically the “cause” of crunch and a potential solution? As simple as this may sound, the answer is profound:

1. Accept we don’t know everything there is to know up front
2. Avoid planning and making promises since we do not know everything up front

Accepting these two points can be liberating, allowing us to spend our time where it could be of most value – testing, prototyping, building, and proving value with the game.

The beauty of not pretending we know every detail of every aspect of every part of a development project upfront allows us to do away with countless artifacts and assets that will never be used and what is worse, will never be useful.

Crunch can also be avoided by creating transparency and a firm definition of “done” as described next.

Transparency and the Game?

Perhaps the most powerful aspect of Scrum, and the most painful, is you know exactly where your project or games stands at any time.

Each sprint review, each iteration, each release is the perfect time to ask:

• Are we developing the features we said we would?
• Is the game we are developing actually fun to play?

This could be painful, the answer may be “no” and the idea was a better on paper than it is on a controller. That’s a tough message to hear, but it’s an important one.

What Done Means

Related to transparency and something a project team is frequently and inevitably asked: "What percent done are you with the feature, game, project?"

The typical response: “We are [0%, 25%, 50%, 75%, 100%] done with development.”

But what does “done” really mean?

• Does 50% vs. 10% mean that the game is 40% more enjoyable to play?
• Do the features created add some type of value to the game?
• Does a green milestone or 100% complete project plan mean a fun game?
• “Done” can mean different things to different people. Who is saying we are “done”?

This is not just specific to the game industry, I’ve seen project teams move mountains to keep their status reports green and their % complete as high as possible. However, what typically gets sacrificed in the effort to be “done” is quality.

While your team may be rewarded in the short run to be “done” on status reports, it might suffer in the long run if you are frequently called out on the quality of what’s delivered.

?The people that are most likely going to call you out on quality is the end users of your project, product, or game. As that's a situation you would want to avoid, what I would propose:

• “Done” is redefined as “signed off by the end user”
• % complete and status reports are be reserved for describing your team’s work to build the features to show the end user to get THEIR opinion of DONE
• If you are truly “done” your end users are happy with your feature, project, product

“Done” leads to my last insight and reflection on “Agile Game Development” – how the game vision can be communicated correctly so we truly know when we are “done.”

Communicating the Vision

Throughout the book one of the true benefits of Scrum we see, and one of the core aspects that can make or break any development project is communicating the vision.

Historically, the vision, the inspiration, the heart of what we are trying to create has been lost in one over complex master document or another such as:

• Game Design Document
• Project Charter
• 100+ slide presentations that is mostly text
• 1000+ line Gantt charts - somehow we are supposed to know a vision from that?

?The fallacy with these huge documents is: “if you write it, they are guaranteed to read it, and understand it.” The fact of the matter is most development teams don’t have the time to look through 100+ page documents and try to determine what you mean, and even if they do read it page by page, there’s no guarantee the true “vision” is understood.

?My opinion:

• ?Game Design Documents, Project Charters, Written artifacts have value
• Core decisions should always be stored in these documents
• They are the sources of truth, the details of what was agreed to

The problem is not WHAT details are in the which document, it’s HOW those details are described to others.

From my experience, it’s best to talk through what you or stakeholders are envisioning with a development team as opposed to sending them a complex documents trying to outline the end goal.

Don’t think this has to be a “huge one time all hands call” either. Rather it could be:

• A 15-minute meeting with your core developers to go over 1 section at a time
• One well written message in your Team group chat and thoughtful answers to follow up questions
• A 10-minute walkthrough of the 100+ page artifact pointing out exactly what page is relevant to your development team and who they should go to with questions if it's not you

There are a few “don’ts” I would add when it comes to communicating a vision. Don’t:

• Underestimate the power of how much confusion could be cleared up by a simple call
• Be surprised if you have to have many of these types of conversations
• Be upset if you have to read parts from an email or document you sent earlier

Overall, your goal should be that your message, your vision, your thought is understood by your audience. Communicate in the form that is most appropriate to them, not that is most convenient for you. This may require some trial and error, but it is 100% worth the effort.

A Better Way to “Find the Fun”

In closing, I wasn’t exactly going into this book brand new.

I’ve successfully delivered Agile and Waterfall technology projects at multiple companies and industries. I’ve studied game design, developed basic prototypes, and continue to enhance my skillsets to develop my own independent games.

However, I left this book with a lot of insights, perhaps the most valuable one being its main thesis. There is a faster way to “find the fun” by understanding, practicing, and applying the Scrum framework.

I would only add, from personal experience, that Scrum is:

• A better way to find the fun, find the value when you consider the historical game or project development processes
• A stronger way to keep the team’s enthusiasm throughout the entire project by keeping them focused on what really matters - the game and the features of the game
• A way that allows teams to be their most creative and also reach their goal

In sum, Scrum provides the framework for teams to create memorable games:

1. That entertain us
2. That inspire us
3. That stand out
4. That stand the test of time

For your next game development project, consider how Scrum can help you and your team find the fun in it faster.