Game development used to all be "project-based" . Projects have discrete beginnings and endings aimed at developing a game which was then released, completely debugged on a cartridge or disc. Following this, a team would then move on to another project. As a developers, I always felt a bit of sadness at shipping a game I'd worked on for many months and starting fresh from scratch on a new one.
With the spread of the internet in the 90's, PC games had the advantage of allowing upgrades and expansions after a release and a few developers stayed with a game for its entire life. Some popular MMOs have support crews fixing bugs or making sure the game keeps up with the latest OS changes many years after their initial release. Digital distribution platforms such as Steam have built upon the PC's strength of connectivity and openness to allow many developers access to popular online marketplaces with incrementally released games.
As consoles gained internet connectivity and local storage, we started seeing a similar adoption. Often, it wasn't a good thing for players. Day one patches became a way for game developers to push off bug fixes and optimizations. This forced players to wait hours for updates to be downloaded before they could play a stable and polished version of the game.
Mobile games have pioneered the live game model and open marketplaces by offering cheap or even free versions of their games, which are monetized through advertising or by selling add-ons which enhance the value of the game, etc. Console and PC games have been slower to catch-up with this model, but as players are becoming accustomed to the expectation of continual growth of their games, it seems the market is changing to adapt to it.
As games and teams transition to live models, the term "project" has less meaning. Schedules, budgets and feature specifications become more fluid based on the day-to-day key performance metrics rather than fixed up-front profit and cost projections (aka guesses) from a marketing group. Rather than the approach of stuffing every conceivable feature into a single release and hoping that some of those features will drive sales, many AAA game developers are approaching a "Games as a Service" (GAAS) model of releasing a Minimally Playable Game (MPG - a variation of the Minimally Viable Product approach) and keeping teams together to release add-on features based on how the market reacts. The project approach may be coming to an end.
I run 10-minute sprint simulations in my classes and notice something consistent. When left to their own devices, teams will plan out the sprint but not estimate much.
For a while, that bothered me. Weren't they listening in the class? Then it occurred to me: when I work on my own projects, I plan out what I hope to accomplish, but I don't estimate much either.
OK, so I don't have a deadline or contract with my own work and neither do my course attendees. Maybe that's the difference.
But then again, we're talking about sprints, which are time-boxed. We know when they end. We also know a sprint's input, the sprint goal, and the output, which are the new features added to an improved game. We typically forecast the future progress of the game by measuring the average output per sprint and multiplying it by the number of sprints remaining.
Planning a sprint is usually a discussion of what a feature needs to do and the work needed to implement it. This is often followed by creating tasks such as "model the character"or "rig the model", etc. This is a useful discussion which reveals questions with the goal and generates discussion.
In addition, teams will put often estimates on those tasks, usually in time. There are a number of typical reasons for this:
It can further discussion by revealing misunderstandings about the effort and complexity of a task and help refine the goal. Many times I've heard large numbers being thrown out which revealed a misunderstanding of the existing tools or tech or a shortage of a certain discipline's capacity.
Estimates are used to create a forecast of the work the team will commit to achieving with the Product Owner.
Estimates are used to track team progress throughout the sprint.
I see the value in #1, but often see #2 and #3 being misused. This reflects back to the Scrum values of commitment and respect:
Commitment: This doesn't mean the team commits to a fixed amount of work. Work is often unpredictable and iterative. When we aim for a fixed amount of work every time, we often have to compromise quality to get there. Commitment is more about doing our best work to achieve a goal, but also committing to doing it with quality.
Respect: You can't respect those you don't trust. Too many times I see teams being tracked using their own estimates and being punished if those estimates are incorrect. All this leads to is padding, disengagement, debt and compromised quality.
If you truly want to measure progress, measure just the output of the team. Let the team decide how to plan and at what level to estimate. It can take some courage, like when I finally had to hand over the car keys to my son for the first time. But as with him, I had to make sure he was first ready. That's my job as a dad. Similarly the job of coaches and leaders is prepare their teams for higher levels of maturity and self-organization.
Sure, some teams might not work well together and their output will show it. It's far better to coach teams on creating better value than creating better estimates.
This causal loop should be familiar to most game developers.
It's a vicious cycle because it builds upon itself, resulting in a negative feedback loop that adds crunch and increasingly impacts the schedule, cost and quality of a game.
Creating a positive feedback loop, or virtuous cycle, which reinforces practices that build towards improved schedule, cost and quality without requiring heroics, is a major reason for having a value and risk-mitigation ordered backlog and a definition of done that teams deliver on every iteration.
The obvious challenge is that you can't just start by asking your stakeholders to establish a relationship and contract built on trust. That has to be built. An even greater challenge is the internal studio challenge of operating with transparency and with a focus on outcome, rather than discipline output.
Two years previously I'd joined a startup game studio, called Sammy Studios. We were owned by a Japanese Pachinko game manufacturer called Sammy Corporation, which wanted to become a major western game publisher. They'd invested tens of millions of dollars in our startup and we were growing quickly...too quickly in fact and we were a chaotic mess.
I was just promoted to CTO. It was one of those promotions that have a clear underlying understanding that "you are being promoted to fix this mess or suffer the same consequences as your predecessor".
Desperation is a strong motivator. I'd run a studio before, but it was one that was far more stable. I started reading everything I could on the latest ideas in management. One called "Agile and Iterative Development: A Manager's Guide" by Craig Larman led me to "Agile Project Management with Scrum" by Ken Schwaber and Mile Beedle.
Scrum seemed like it might be a good fit for us, so I attended a Scrum Master course hosted by Ken Schwaber. The course was illuminating. It created a mind shift about not only how to make games, but how to coach an organization to better serve its more valuable assets: its people. It created a vision.
However, having a vision is not the same as implementing it. Not by a long sho t. It turned out that standing in a circle for 15 minutes a day didn't transform us into an effective organization. Quite the opposite, it created some negative reactions.
High Moon Studios: A Portrait - Scrum - YouTube
Even while we were adopting Scrum, we were mocking it.
But we persisted. We made many mistakes, but we adapted. We started to see the benefits of Scrum. They weren't what we'd expected: no miracles, but we did start to see teams managing more of their day-to-day work and starting to take more ownership over solving problems rather than leaving it to management.
However, after several years, Sammy Corporation decided to acquire Sega who wanted nothing to do with us. We acquired ourselves from them and renamed ourselves High Moon Studios.
A year later we sold the studio to Vivendi. They needed to spend a lot of their World of Warcraft money and we were happy to take it. Vivendi appreciated the benefits we were seeing with Scrum and started sending me to their other studios to talk about it. I also started to talk Scrum at the Game Developer's Conference.
Then Activision and Vivendi merged. During this time we were visited by the Activision scouting party that led the way for an executive review of the studio. Activision was mainly interested in Blizzard and looked at the other studios as baggage to discard if they couldn't help on their existing titles. During the scouting we were told to remove all evidence of agile from our walls if we hoped to survive the review. This and my experience visiting other studios convinced me it was time to move on. So in March 2008, I became an independent agile trainer.
Decades of office work did not prepare me for the life of a traveling trainer. The repetitive and predictable nature of my life disappeared, to be replaced with a life filled with airline chaos, packing and unpacking and entering studios where I knew almost no one.
Although I missed working on a game and seeing the same friends every day of the week, the experience of glimpsing the life of an average of 15 studios a year over the past dozen years has been illuminating. We're all much more alike than I would have guessed. We share many common problems. We all want to have purpose and release great games and enjoy making them.
The Golden Years and the Backlash
Scrum enjoyed (and suffered through) a period of time where it attained a fad status. Studios were embracing it as a miracle solution to their problems, much as we did. It wasn't hard to get work training game developers.
However, like us, studios realized that getting agile to work was hard. It required a cultural shift, which is never easy. Some main causes were:
Modifying the practices to fit a command and control culture. Scrum "managers" were assigning sprint work in tools and weaponizing various aspects of Scrum to micro-manage teams.
Following the defined practices of Scrum without question and never modifying them based on what the game and teams are "telling" you.
Many blamed Scrum for their failure to see success applying Scrum. Just as Scrum is too simple to credit with success, it's also too simple to blame with failure.
One of my first experiences as a trainer was visiting a large studio in Montreal that was adopting Scrum. I was introduced to a junior producer who said: "we're staffing up from 20 to 200 in the next month to get a game out the door in 18 months. This game will run on an engine which has yet to ship a game." "But", he added with enthusiasm, "we're going to be using Scrum!".
Back then, I found it difficult to say "Implemented correctly, Scrum will likely tell you very quickly that you won't be able to achieve that goal" because I knew I wouldn't be invited back, and I wasn't. Sadly, they struggled for 18 months, struggling to hide all the transparency that could have saved them the pain until the game was cancelled. As expected, Scrum was blamed.
The gold rush of agile also produced a lot of brands of agile that went to war with one another. Differing brands of agile, which diverged only in minor ways would accuse one another of being complete failures and that their brand was the perfect approach.
This seems absurd to me.
I've seen many different methodologies result in great games.
Unless the wheel of history has come to a complete halt, we'll keep improving how we make games and eventually look back on our methodologies we use today as outdated.
The very first value of agile is "individuals and interactions over processes and tools". This includes agile processes and tools as well. People are the main ingredient, not what brand of methodology you use.
Since I became an independent trainer in 2008, the industry has seen tremendous change. Mobile, for example, has grown to dominate the industry. Mobile game development now spends most of its effort in live support. The player feedback loop has gone from years to weeks. This is fertile ground for agility. Feedback loops of weeks allow far more experimentation and transparency than a two year console cycle where your game has one change (maybe two with a day one patch) to capture market share.
AAA development practices are starting to look like mobile game practices: viewing games as an ongoing service and focusing more on adding post-launch value.
With more experience using a pragmatic approach to agile, we have far more success stories and a greater abundance of beneficial practices and approaches to apply agile to game development.
The pragmatic approach includes:
Adopting an agile mindset for all disciplines
Continually experimenting with improved practices
An executive-level understanding of how to work with agile development teams
Not getting stuck on following practices by-the-book
My job as a trainer and coach is much more interesting these days. Rather than giving the same beginner course over and over, I work with studios and teams that understand the basics and the principles up front so can focus more effort on addressing the specific needs of the studio.
But we still have a long way to go.
Leveraging creativity and engagement through increased self-organization, trust and respect for developers
Relying more on the emergence of a game and a focus on iteration outcomes rather than a detailed schedule that drives output.
Focusing on outcomes and managing debt to manage ship dates more reliably.
Improving practices to move quality upstream in the development chain.
I look forward to the next ten years. Change is accelerating and agility is still the best approach to staying on top of it.
While working on a game, have you ever asked: "Why are we making the player do this? Why am I working on this feature? Why did we waste time modeling this section of a level in detail when the player doesn’t see it?"
Knowing the reasons for why we are working on something has tremendous benefits of engaging with our work and being able to contribute more creatively.
Impact mapping is a useful technique for doing this. It leverages the creative input of everyone on the team in finding the best way to achieve a goal as opposed to having a few people document a set of requirements that don't communicate that. It's also a good starting point to generate a product backlog and release plan.
Impact mapping starts with identifying a goal for the game or a feature and then deriving purpose, incentives and finally implementation details to achieve the goal by answering the questions asked. The goal will be expressed, like a user story, as something that benefits the player in the game. This is the root of the impact map. Let's take a look at the questions the impact map raises by using PlayerUnknown BattleGround (PUBG) as a simple example:
Goal? This is the goal of the game or feature. For example, the goal of PUBG is to win the game.
How? One or more ways the game's mechanics will serve the goal. For example, in PUBG you win the game by being the last player alive on the island. Note: other games might have multiple ways of winning the game...there can be more ways than one to achieve a goal.
Why? This level will list the incentive for the "how" mechanics. For PUBG, you become the last player alive by eliminating other characters and avoiding elimination yourself.
What? What dives into the specific features that will be worked on to implement "Why?". For PUBG, this will include weaponry, combat, inventory, using sound, etc.
An Example of the Benefit
A frequent example I use in illustrating the benefits of including the team in understanding the purpose and reasons for a feature was from an experience with a racing mechanic team. When initially handed a set of requirements, such as complex police chase AI, it was clear that the team didn't have enough time to implement everything asked for. So instead, we explored at the reasons behind requirements.
The reason for police chasing the player was to incentive them to drive fast, which required the player to develop improved driving skills. When this was understood to be the purpose (rather than simply implementing the initial requirements handed to them), the developers found ways of implementing police that:
Saved months of effort
Focused on the player's driving skill, more than simply navigation
Likely produced better results
This approach is a variation of the YAGNI principle ("You Ain't Gonna Need It"). By focusing on the outcome, you often end up minimizing the work to get there. Think about the sets that they build for western movies. Since old west towns aren't around anymore, they need to recreate them. However, they don't create the entire town, but merely recreate by focusing on what the camera will see. This saves a lot of money and time.
Give it a try. It can take less than an hour at the start of a release cycle and save you weeks of wasted effort.
One of the most challenging questions to answer is "what does a Scrum Master do all day?"
The answer usually begins with "it depends". It depends on:
- The experience and maturity of the team
- The role of the product owner
- The culture and organization of the studio.
The role also changes over time.
Coaching a newly formed team that isn't familiar with agile can be a full-time job. As teams grow, discovering ways to improve their performance and self-organize, their need for a coach diminishes. However, this doesn't mean the Scrum Master's job is done.
As teams improve, impediments from the outside become more pronounced and impactful. As a result, the Scrum Master focuses more on coaching the organization outside the team and on the development practices used at every level.
Example Impediment - The Level Production Battle One example illustrates the focus on development practice improvement and how an organization can resist those improvements.
Our team was working on a side mechanic for a game which required a single level. All other levels were being produced by a level production team, but since we required a unique level, we decided to build it ourselves.
After a few weeks of production, our level artists found that by building the level in the Unreal Editor, rather than the studio standard of using Maya, gave them huge benefits. While Maya is a fantastic tool, it wasn't a good match with the Unreal Engine (at the time). Our level designers were at least twice as fast creating level geometry (including iteration time) than the designers using Maya.
However, the lead artist for the game wasn't happy. They were directing the level designers on our team to return to using Maya. When our designers pushed back, their jobs were even threatened!
We (the SM and I (PO)) took the problem away from the team and to studio management. We used the production metrics and demonstrated that the quality of the level produced using the Unreal Editor was just as good. It wasn't easy to convince everyone, but we did. Eventually the entire studio went over to using the Unreal Editor.
Improving the Studio Studio culture can often impede improvements. There are many reasons. Some examples:
Leads can feel their authority or position is threatened by change at the development level.
Process is considered written in stone and change is not welcome.
Developers don't feel they have permission or the responsibility to suggest change,
Executives can override development on a whim and destroy trust.
A Scrum Master, who usually has little authority at this level in the studio, must use their organizational coaching skills to overcome these obstacles.
Gratuitous Pitch Learning these skills is one of the areas we explore in the Advanced Certified Scrum Master course in June.
After more than a decade of training and coaching game development teams on applying agile to their games, I've assembled an advanced course based on the patterns of success seen in the industry. These successes are largely based on effective coaching and servant leadership skills at the team and organizational levels. This course focuses on building those skills.
Through the A-CSM course, you’ll learn to:
Guide teams toward a focus on “finding the fun” and aligning on a shared vision of delivering fun effectively.
Build on your servant leadership skills to help teams mature and reach higher levels of accountability, ownership and engagement
Facilitate better dialogue between the Product Owner, Team members, customers, stakeholders, and executives.
Respond confidently when encountering resistance to change, lack of engagement, low motivation, and unavailability of key people.
Find way to influence change within your studio’s culture and overcome resistance to process change
Understand advance art and technical practices how teams can apply them without being an artist or programmer yourself
Scale Scrum and Agile beyond a single team.
Distinguish yourself in the global marketplace. An A-CSM certification helps you stand out among the global Scrum community
Anyone can attend
To receive the A-CSM certification, you must Hold a current CSM with the Scrum Alliance and have 12-months of experience as a Scrum Master (it is not necessary hold a certification during this experience)
Sprint goals are one of the most widely misunderstood artifacts of Scrum. They are often misused at first. We misused them and went through several stages as we improved how they were created.
Every 2-3 months, we'd establish a set of release goals, often in the form of "epic stories", that established a vision for the release. Doing this led us through three stages of how we created sprint goals:
Stage 1 - break the epic goals down into many development steps, as described above, to fill up our product backlog before handing it to the team. This required a lot of "producer-like behavior from the Scrum Masters managing the product and sprint goals.
Stage 2 - Have the teams become more involved in that breakdown. Release plans still had a lot of PBIs that looked like requirements derived from design decisions that were locked in at the start of the release. Sprint goals were still mainly a collection of requirements, but with a better definition of done.
Stage 3 - A shift to having a discussion at the start of each sprint about how we could move one or more of the epic stories forward in the sprint. Design decisions were spread out more evenly throughout the release. Sprint goals were usually a sentence about what the team forecasted could be played in the improved game at the end if the sprint.
An example of how this looks with an epic story: "As a player, I want to engage in hand-to-hand combat with an enemy player"
Stage 1 - Write a document that described the hand-to-hand combat and break out a designed development order into a large set of sprint-sized PBIs with estimates for each. There wouldn't be much to see until the end of the release. Backlog refinement didn't happen because there was little to see in early sprints, so there was little to reflect against the release plan. Releases always ended with crunch.
Stage 2 - Work out a release plan with the team. There was still a a lot of task-like PBIs split out and design decisions were front loaded. But teams had more to show each sprint and started to hold backlog refinement sessions throughout the release. The end of the release was still a scramble to have hand-to-hand combat shippable.
Stage 3 - Don't create a release plan, but discuss with the team how we could move the hand-to-hand combat forward each sprint. Backlog refinement and sprint planning merged.
Stage 3 scared the devil out of management. It required a bit of trust established by a highly functioning team delivering high quality work at a consistent pace. Also, it was first attempted when we were given three months to do something very risky that should have taken six months, but it demonstrated the following benefits:
It focused the team on the player essentials. Sprint one implemented the controls and cameras of combat and not the polished animations. You can have fun and learn a lot with simple blends and placeholder reactions.
It reduced risk and cost by exploring the essentials first and postponing design decisions as long as we could responsibly postpone them. Very often design decisions made far in advance are more complex than what is needed and lead to waste. In this case, a high/medium/low hit detection approach was the simplest solution that worked well enough initially, but had the benefit of being tweaked over the remainder of the release.
It delivered early. We could have shipped it in two months, but took the extra two sprints to add elements beyond the release goal.
This approach is ideal for high-risk and uncertain work such as exploring new mechanics. As development becomes more certain, the level of planning can rise where the use of story mapping or Kanban becomes useful. Additionally this can't happen overnight with every team. It requires highly functioning teams.
This wasn't isn't about doing things "right" or "wrong". We're always inspecting and adapting how we make games and must always assume there are things we can improve. As long as teams are doing that, they're on the right path.
In 2009, the non-fiction book “Drive” written by Dan Pink was published. The book summarized research demonstrating that creative workers are not motivated so much by financial incentives or other such explicit motivations, but by intrinsic factors.
The three primary intrinsic factors identified are:
Autonomy - The urge to direct our own lives
Mastery - The desire to get better at something that matters
Purpose - The yearning to do what we do in service of something larger than ourselves
We want motivated teams. We want to be on motivated teams. We want to be motivated ourselves, but a studio’s culture and process can often prohibit it.
This is where the agile values and Scrum practices come into play:
Autonomy - The purpose of self-organization is to give the people closest to the work autonomy in taking greater ownership, as the become ready for it, over more and more of their work. At first it might be how they plan and track their Sprint. Later, it’s how the team membership is managed and the practices they use to create an increment of the game.
Mastery - By giving the team the freedom decide “how” they implement a Sprint, they are given permission to explore better ways of working. For example, when our level artists were given the freedom to explore new ways of creating levels, they eventually found methods that reduced level creation time in half. Note: the challenge to doing this wasn’t with them, but with the lead artists who had a problem letting their people do things “their own way”. For some reason they fought to have the less efficient level creation practices restored.
Purpose - By forming teams that are aligned around a feature area of the game, rather than a discipline silo, developers are far better connected to the purpose of their work. It’s easier to understand if what you are doing helps improve the game when your Sprint goal is to demonstrate an enhanced feature or mechanic than to simply accomplish all the assigned tasks in a tracking tool that contributes to something you’ll see in the game a month or so later.
This all sounds great, but it’s very hard to implement in a culture that doesn’t place a lot of value on intrinsically motivated developers. The signs of this are:
Developers are largely seen as “fungible”. E.g all animators are equally weighted on a spreadsheet or tracking tool, where skill and mastery could for little.
The idea that more developers can be added to a team to make the team more effective.
Management exists to define how developers do their work and to find and address the problems that arise.
The purpose of what is being done exists in the design document and if developers want to know the purpose of what they are doing, they simply need to “read the doc”.
Another hard part is that motivation can’t be forced on developers. They have to find it within. The role of leadership is to help create the conditions for intrinsic motivation to flourish. I’ve worked with some developers that have been so beat up and burnt out by bad leadership that they refuse to extend themselves again. They don’t want to be disappointed again (what to do in these cases is the subject of another article TBD).
Game development leaders should always be asking themselves: “how can I help improve upon these intrinsic motivators?” A core part of this practice is improving the feedback loops so that increases in autonomy, mastery and purpose are quickly reinforced and that mistakes are not punished but initiate a conversation to highlight what valuable thing we learned from the experience.
The ultimate joy, as a leader, comes from this cycle being taken over by the team. I’ll leave you with one warning: When your teams start outperforming your expectations, you might get promoted away from them.
A studio I visited had a live mobile poker game that had been very successful. Money from in-game purchases of poker chips had been pouring in for years, but the competition had been heating up and revenues were slowly falling. The root cause of the problem was the success of the game. The might sound strange, but a successful game often hides problems. It’s human nature to tell yourself not to change anything when things are going well. Ironically, that’s the time when you should explore improvements: you make better decisions when it’s not an emergency.
The other reason success is so dangerous is that it leads us to splurge. For example, it’s easier to staff up by 50% when you’re making a lot of money. But all those new hires need something to do and often that extra work can slow things down. This was the main problem for the poker game. They had 160 people on the team and it was taking six months to implement major new features. Although the team was using Scrum to implement features, there was a lot of waste outside of Sprints that had to be eliminated (and a few challenges for the Scrum teams as well). The first thing to do was to map the flow that an idea for a new feature went from concept to player delivery. Doing this exposed the following:
New feature ideas were huge. They were captured in 20-30 page documents.
Because features were so large, they went through numerous revisions and reviews which took one to two months.
It was easier to shoot down a revision because of the risk and cost of the feature than to approve it.
It took time to gather all the principles for a review (at best twice a month).
The Sprints were not addressing debt as well as they could have, which resulted in a lot of rework in subsequent sprints after a QA team found problems trying to validate builds for submission. A six-month development cycle created problems:
Taking six months to determine if a major new feature will be successful in the market is a very expensive gamble.
The competition that has shorter development cycles can beat you to market.
To address this, we implemented two main changes. One hard, one harder:
The hard change: Improving the “definition of done” with the Scrum teams to address debt. This required some automated testing, QA joining the teams and improved practices such as Test Driven Development. This was hard because it was taking for developers to change how they work and for teams to reorganize a bit. However, the benefits were easy explain, which made the coaching easier.
The harder change: Weaning management off of their need to make big gambles with major features, which led to big design documents. The new approach was to create smaller experiments that could be tested with players and could inform product ownership enough to evolve better features.
An example of this would be a tournament feature for a single-player puzzle game. The original approach would be to design the entire tournament, with ladders and player ranking systems. This could take months and be subject to many design discussions before even the first UI element is created. The new experimental approach was to introduce a simple head-to-head mechanic where the game could experiment with how players could use the puzzle game in a competitive way. This greatly reduces risk as well, because a tournament that took months to develop would likely be a failure if the core of tournament play—the head-to-head mode—wasn’t fun.
This change in design culture took a while to optimize, but seeing the metrics of the flow improve became a motivational token for the leads and they embraced being part of the solution.
Ultimately, the business metrics saw a benefit from this new approach. The throughput of new features (albeit smaller, incremental features) increased from one every three to six months to every four to six weeks. Revenues started increasing. A side-effect of these smaller features was that the team could be smaller. Most of the team moved to other games and the poker team size was reduced to about 60 people.