Tuesday, November 19, 2019

Too Many Rules

A battle among homeowners is a lesson for studio leaders.

We live in a neighborhood in Colorado that borders a vast national forest.  We have lots of dirt roads, utilities, a lake, and dense forest, which require a great deal of work to maintain.  Volunteer neighbors have done much of this work, but over the past few years, volunteerism has declined.

This community also has a Home Owner Association (HOA) that likes to pass many rules.  For instance, you need to fill out a form to move a rock in the common area. If you don't wear non-flammable clothes while using an outside fire-pit, you are subject to a fine.

I see a connection between the declining volunteerism and the rising number of governing rules. This connection crystallized during a recent mountain bike ride.

I was riding on a world-famous trail network called "Phil's World" in Cortez, Colorado. Phil's contains dozens of miles of amazing trails. It is continually being expanded and maintained by a group of local volunteers that donate days of their time each month.  These volunteers will not only move rocks to clear paths, but build impressive cairns with them.

This effort inspires me to stop my bike and move rocks or pick up any litter I find. Although Phil's is an hour drive away, I feel part of this community.  I feel it more than the one where I live.

Intrinsic Motivation

Dan Pink's book "Drive" explains a lot about why we can work so hard at things we don't get paid for and so little when we are. He describes three factors of intrinsic motivation, backed up by decades of research, to prove it:

  • Autonomy — Our desire to be self-directed. It increases engagement over compliance.
  • Mastery — The urge to get better skills.
  • Purpose — The desire to do something that has meaning and is important.

When leaders or governing bodies define a broad set of rules and penalties for non-compliance, it undermines a sense of autonomy.  Such compliance is a poor substitute for purpose.

Rules and penalties often exist to force behavior that you're not trusted to do on your own. When someone tells me that they'll fine me when I wear the wrong clothes by my fire-pit, I'm less motivated to help them cut a tree down.

Excessive rule-making happens in studios, and the same lack of motivation occurs. The prevailing  attitude becomes "I did my tasks, if the game is broken its someone else's problem." Leaders subsequently get frustrated with the lack of accountability and generate more rules.

A certain number of rules are necessary, but a good practice is to engage those you are making rules for. "Working agreements" are often better. Find ways where purpose can drive behavior instead. Sprint Goals and a definition of done are useful tools for this.  Collaboratively crafted, they drive behavior better than assigning work and creating rules about how disciplines should interface and test.

Wednesday, November 06, 2019

Sprint Commitment?

I recently finished the first draft of the new edition of "Agile Game Development." One of my reviewers commented that I still use the phrase "Sprint Commitment" after its removal from the Scrum Guide, but I left it in there.

One of the reasons that the phrase is no longer in the Sprint Guide is because it has often been weaponized to force teams to complete everything they'd estimated in Sprint Planning regardless of what problems emerge during the Sprint. This has resulted in teams compromising quality to get every feature in the game "done" by the end of the Sprint.

The Sprint Guide now uses the word "forecast" instead of commitment for Sprints, even though "commitment" is still a core value. I agree that forecast is an accurate way to express what the plan is, but I think we've lost something by dumping the word commitment.

It comes down to what we mean by commitment. Often forecast means "we'll get done what we get done," or better yet, "we'll do our best to get everything done, but we might have to drop some less important features." To me, commitment goes a step beyond that, but not so far to mean "we must do everything."

Commitment means doing our best to achieve a goal, but also being accountable as a team, when things don't go according to plan.

A good example is when you commit to picking up your child at daycare. You'll obviously do your best to be there on time, but sometimes things go wrong. Let's say your car breaks down a few miles away from daycare. Do you just say, "oh well, I tried my best"? No! You call your spouse, friend, and/or the daycare to let them know. You do this because you hold yourself accountable to pick your child up.

Similarly, if a team runs into problems with a feature in their Sprint goal, they need to hold themselves accountable. They need to raise the issue. They grab the Product Owner and discuss ways to address it. If they can't solve the problem themselves, they recruit the Scrum Master to help out. It still might mean the feature gets dropped, but the accountability results in risk being managed better.

Commitment is a core value for Scrum Masters to grow with a team. Sometimes the first step is to stop solving problems for the team and start asking them, "what should you do about it?"

Sunday, June 23, 2019

The Death of Projects

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.

Friday, June 07, 2019

Sprint planning and estimation are not the same thing

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:

  1. 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.
  2. Estimates are used to create a forecast of the work the team will commit to achieving with the Product Owner.
  3. 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.
Try this
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.

Saturday, June 01, 2019

Reversing the Vicious Cycle of Excessive Up-Front Game Planning and Design

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.

This is a core aspect of what a Scrum Master or Agile Coach does and is a major topic in the Advanced Certified Scrum Master for Video Games Workshop in June.

15 Years of Agility

It was July 2004 and I was at my wit's end.

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 Mike 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.

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 canceled. 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.
More Pragmatism

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
Going Forward

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.

Monday, May 27, 2019

Impact Mapping for Games

Advanced Scrum Master for Video Game Development Course, June 17-18 Denver Colorado

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.

The book "Impact Mapping: Making a big impact with software products and projects" is an excellent introduction to impact mapping, but it doesn't apply directly to video game development. However with a few variations, it can be very useful.

Impact Mapping for Game Development
An Impact Map asks questions
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:

  1. Saved months of effort
  2. Focused on the player's driving skill, more than simply navigation
  3. 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.

Tuesday, May 07, 2019

The Evolving Role of the Scrum Master

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. 

One of my favorite images is this one from the book "Large-Scale Scrum, More with Less", illustrates the shift:
The Shifting Focus of a Scrum Master

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.

Wednesday, April 24, 2019

Advanced Certified Scrum Master for Video Game Development Workshop, June 17th-18th 2019 in Denver Colorado

Announcing the first Advanced Certified Scrum Master for Video Game Development course on June 17th-18th 2019 in Denver Colorado.

Early bird discounts end on April 30th, or when the workshop is full.


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) 

Monday, February 18, 2019

Our Three Stages Towards Improved Sprint Goals

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 tasks 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.

Tuesday, January 01, 2019

Creative Motivation and Agility

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”.
  • Etc. Etc. 
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).

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; good leaders get recognized and are given greater roles.