Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 24, 2014
arrowPress Releases
October 24, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Win-win: Great teams make better games and enjoy making them!
by Clinton Keith on 05/15/14 11:49:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutraís community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


Have you ever been a part of an amazing team: a team where work flows and time flies; you have to drag yourself away at the end of the day and come rushing back the next morning  filled with ideas?  If you’ve worked long enough making games, you may have experienced being on such a team (called a “great team”) and know that such experiences are not only the ones we want, but lead to better games.

Great teams:

Don’t get me wrong.  We’re not talking about singing Kumbaya in a circle.  Great teams can be messy, chaotic, noisy and drive each other crazy from time-to-time.  They focus on the game and communicate candidly with one another, even when hard things need to be said.  Great teams often happen by chance, when the right mix chemistry, experience, and skills come together, but when left to chance, it doesn’t happen very often.

During the past ten years of training and coaching, I’ve observed how some studios “get it” and foster great teams, while others haven’t learned to.  This article is about the differences between the two.

How to Improve the Creation and Support of Great Teams

There are better ways to foster great teams than chance.  Models such as Situational Leadership, Tuckman as well as others are useful for leadership, but like any model, they are imperfect.  People are not systems that can be so easily predicted and manipulated, but there are basic tools leaders and coaches can use to foster great teams:

  • Keep teams small.  Plenty of research has shown that teams that are too large simply don’t communicate well.  They stop being teams and become groups, which have less cohesion.
  • Coach interactions based on the maturity level of the team.  Some teams need a good deal of coaching, while others need a light touch.  
  • Make changes where necessary.  Sometimes, despite coaching, the chemistry isn’t working for a team.  Before it irrevocably damages the team, mix the membership up a little.  It’s amazing how much a so-called “bad team member” can become someone valuable for another team.
  • Give the team more autonomy.  As a team grows in maturity, they’ll begin to coach themselves and even influence their membership.  Let it happen.

None of this is tied to any methodology or framework, but a framework can help by establishing a common vocabulary and set of interfaces as a starting script to know when and where coaching occurs.

Agile, and Scrum specifically, are frameworks for supporting such teams.

Some of you might not agree with this.  What you’ve seen or were told was that Scrum is a hard-core set of rules to follow.  It’s too bad this view exists.  It follows from bad implementations and it’s doing real damage to the aim of supporting great teams.

For Scrum to work, the team has to deeply and viscerally understand collective commitment and self-organization. Scrum’s theory, practices, and rules are easy to grasp intellectually. But until a group of individuals has made a collective commitment to deliver something tangible in a fixed amount of time, those individuals probably don’t get Scrum. When the team members stop acting as many and adopt and commit to a common purpose, the team becomes capable of self-organization and can quickly cut through complexity and produce actionable plans.
- Ken Schwaber, Agile Project Management with Scrum

How Scrum Values Bridge Methodology and Great Teams

“Grand principles that generate no action are mere vapor. Conversely, specific practices in the absence of guiding principles are often inappropriately used.”
- Jim Highsmith, Agile Project Management: Creating Innovative Products (2nd ed.)

  • How does standing around in a circle answering three questions a day increase productivity?
  • What practices do we need to follow to make great games?
  • What metrics or tools do we use to ensure we’re making a hit game?
  • How does a good process avoid making mistakes?

These are nonsensical questions.  There are no silver bullet practices and when teams follow good practices without heart they gain little value.  Great teams examine each practice in light of how it allows them to work better.  That said, there needs to be some underlying set of values that drive decisions about practices.

Values are a foundation that are important to people.  For example, the value of respect is important to us all.  I want others to respect my work and I can assume that others want the same for theirs.  How does that value guide our day-to-day behavior?  One way is in how we respond when someone makes a mistake.   When someone makes a mistake, we might have one of two reactions.  The first is that the person who made the mistake was lazy, dumb or incompetent.  The second is that the person who made the mistake didn’t have all the information necessary to do the right thing.  By valuing respect, we’ll intrinsically choose the second reaction.  Valuing respect when mistakes are made avoids the fear of making mistakes that can kill experimentation and learning in studios.  The signs are unmistakable:

  • Highly detailed Gantt charts and documents are created, not to predict the future, but to protect middle management from blame as reality emerges.
  • Bloated processes emerge, built from practices and rules created in response to every past mistake, in hopes that those mistakes will be avoided in the future.

Scrum’s Values

Scrum has five values, which underly the reasons for all the practices and direct how teams are coached:
Respect - Teams share successes and failures and work together to increase respectability, rather than creating an atmosphere of blame and fear.  Respect builds trust.
Courage - Teams challenge themselves and their studios to find ways to work better and to create a better working environment.
Focus - Teams focus on building a few things at a time .
Commitment - Teams commit to building games with quality and become accountable to one another and their results.
Openness - Teams operate with transparency, sharing good news as well as bad to make better decisions faster.

These values not only explain the reasons while a daily scrum is standing-only and time-boxed, but are a foundation for every change made to customize the practices.  For example, some teams will do a quick play-though of the game at the start of a daily scrum because it improves focus, openness and commitment.  Other teams move to an electronic tool to update daily progress and might diminish those values.  A coach (or ScrumMaster) helps guide the team through these decisions by keeping these values in the forefront.

Why is it so Hard to Do This?

When I was three years old, my father tried to teach me how to swim using the same method his father had used: He threw me into a local lake off the end of a long pier and expected me to learn.  Sadly, that day I wasn’t going to learn to swim before drowning and he had to rescue me.  I’m told that I avoided the water for the next few years.

I didn’t use this approach with my own sons.  Instead my wife and I brought them to a swimming instructor, who started them off in shallow water, learning to put their face in and blow out bubbles.  Later lessons grew skills, while managing fear.  I wanted my sons to have a healthy respect for the dangers of water, but I didn’t want them paralyzed with fear and not experience the joys of surfing, diving or just cooling off on a hot summer's day.

Unfortunately, I didn’t apply this approach with my first Scrum team.  I applied dad’s approach of tossing them off the pier.  This involved handing them copies of a book and telling them to “follow the rules”.  Fortunately, the team didn’t “drown”, but they were terrified of all this “agile stuff”.  They clung to the rules, deathly afraid of what book I might read next.  They learned the equivalent of  “treading water” and that was all.

I’m a slow learner, but I eventually correct my bigger mistakes.  For the next team adopting Scrum, I behaved less like my father and more like the swimming instructor.  I had them attend some training to get the big picture, learn the vocabulary and to acquire a vision of what we hoped to achieve using Scrum.   We (management) worked on basic, “safe” practices, such as having leads sit with junior developers to help them estimate a sprint.  The team didn’t commit to a certain number of features for their first sprint, but accomplished what they could.  We measured those features that met a reasonable definition of done and used that metric as a basis for planning future sprints.  In carefully facilitated retrospectives, we listened to their feedback about what worked and what didn’t and agreed on some easy-to-achieve actions.  Slowly, we backed off our involvement and let them assume more responsibilities.

The results for this team were far different than those of the first.  The second team felt empowered with a sense of ownership and were less fearful of change.  This team frequently changed their environment and practices.  They even made demands on management, such as having someone from QA join their team.  The only intervention we found necessary was when, in deciding to tear down cubicles, they exposed live electrical wires and were about to fix the problem directly!

There are too many leaders that don’t understand how to approach this fundamental change.  It has to be done with safety and respect.  I count myself as one of these who has hopefully mended his ways.  I don’t blame others who are stuck in a command-and-control mode because, like my father and myself, they come from a long line of “doing things the way they learned how to do them”.  Breaking this cycle is hard, but rewarding.

You may think this is a bunch of feel-good hand-waving and we should just focus on making games without worrying how, but consider this:   At the end of your career, when you recall your life in game development.  Which do you think will weigh more in your thoughts:  The games you made or the people you made them with?

“Here’s what we all know, deep down, even though we might wish it weren’t true: Change is going to happen, whether we like it or not. Some people see random, unforeseen events as something to fear. I am not one of those people. To my mind, randomness is not just inevitable; it is part of the beauty of life. Acknowledging it and appreciating it helps us respond constructively when we are surprised. Fear makes people reach for certainty and stability, neither of which guarantee the safety they imply. I take a different approach. Rather than fear randomness, I believe we can make choices to see it for what it is and to let it work for us. The unpredictable is the ground on which creativity occurs.”
Ed Catmull  Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True

Games are dependent on the individuals, leaders, teams and cultures that create them.  Game development will always be uncertain and lack the level of predictability we might crave, but when we push for more predictability than our existing knowledge allows we start to do harmful things to our culture, ourselves and the teams we lead.  Rather than trying to create certainty with random teams, we need to be setting great teams loose on uncertainty.

It's a win-win: Great teams make better games and enjoy making them!

Related Jobs

Forio — San Francisco, California, United States

Project Manager / Producer (Games)
Yoh — Vancouver, British Columbia, Canada

Build & Test Engineer
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States

Senior Sound Designer - Infinity Ward
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States

Multiplayer Level Designer - Treyarch


Carsten Busold
profile image
From what I have experienced: Scrum can make a good team great, but makes a bad team even worse. :-)

Clinton Keith
profile image
Hi Carsten,

Scrum doesn't have the power to do either of those. It *will* create transparency that makes those things more apparent!


Paul Furio
profile image
Scrum is certainly "A Methodology" for getting things done. The more articles I see defending Scrum, the more I worry that the people we're trying to convince are ourselves.

Good managers and leaders ramp up their team at a rate that is most effective for each individual. For some members, this means more handholding. For others, rapidly increasing challenges.

Real happiness and drive comes not through a development methodology. Instead, I would encourage reading Dan Pink's "Drive". On my teams, I found that if I provided people with Autonomy, Purpose, and the Opportunity For Mastery, they did very well, made great things, and were always hungry for more. In fact, it made my job easier as I could focus on growth and the long term strategy, and less on sorting out interpersonal problems or firefighting.

That said, the main title is correct: Happy, well gelled teams create great stuff.

Clinton Keith
profile image
Hi Paul,

We're really saying the same thing, at least in your second and third paragraph. I completely agree with your take on Dan Pink. I've been saying that for years:

However Scrum is *not* a "methodology". A methodology is a set of practices you use to make stuff. Scrum isn't because it has no practices for writing code, creating art, testing, etc. etc. It's that way by design because, unfortunately, methodologies bloat and are seen by people as rigid sets of rules that end up being followed without thought as to "why" they are being done.

Three meetings, three artifacts and three roles do not make a methodology.


Paul Furio
profile image
My quotes were there to note that it's one way to do things, but maybe not the necessarily best way for all teams. Ultimately, it's up to each team to figure out the best process for them to be productive and happy.

I think we're in agreement here, but some tone may be lost due to the format.

Clinton Keith
profile image
Fair enough. I completely agree that a team should own most of the process. This is the *point* of Scrum lost on many teams and managers. It's not a process, but a framework for one which supports inspection & adaptation and the emergence of an iterative process.

Brandon Davis
profile image
You take a game management strategy like Agile or Scrum and program in your own variables specific to your business and gaming goals.

Reduce the noise of interpersonal variables by increasing the sound of production points.

Clinton Keith
profile image
Hi Brandon,

100% agree. I love the signal-to-noise analogy.


Judy Tyrer
profile image
I feel like I should have this tattooed on my forehead and then I can just put a picture up every time.


SCRUM is great for projects with unknown requirements and minimal research needs that can still afford to allow developers a chunk of time to work uninterrupted by shifting requirements. It's not that great for other projects and in some cases it just gets in the way creating overhead without increased productivity.

If all your requirements are well known and not likely to change, waterfall is still an amazing development process and we shouldn't just toss it out. There are also many other flavors of iterative that provide different foci, some of which are much better if you have a team that cannot afford time for developers to work uninterrupted but require the ability to "pivot on a dime". You can't pivot on a dime in SCRUM without invalidating the entire sprint.

Clinton Keith
profile image

I agree. Before you get the tattoo, I'd suggest you have it say "Fit the process to the uncertainty". What we call a project can easily change it's complexity from preproduction to production and, as a result, require a change in the process to keep up. Often, no one approach fits an entire project.

For example, years ago we discovered that--as you point out--Scrum is not a great fit for content production:

Many teams turn to a Waterfall or Kanban approach because there is more certainty in what were making and how we make it. The difference between Waterfall and Kanban is that Kanban retains a bit more of the "inspect and adapt" cycle that many content producers benefit from because they always find ways to improve content while making it and it's a benefit to introduce those improvements quickly.


Clinton Keith
profile image
I'm noticing that the comments are focusing on Scrum. This is expected, which is why I wrote:

"Some of you might not agree with this. What youíve seen or were told was that Scrum is a hard-core set of rules to follow. Itís too bad this view exists. It follows from bad implementations and itís doing real damage to the aim of supporting great teams."

I completely understand that many people have had Scrum shoved down their throats by come of the cultists and, as mentioned, it's done real damage.

But the article was really about great teams.

Taking a step back, I'd like to point out the very first value in the agile manifesto.

It says:
"Individuals and Interactions over process and tools".

In full, we value processes and tools, but value individuals and interactions even more. Great teams and better communication are more valuable than any process we use, regardless of whether it's based on Scrum, Waterfall, Anarchy, Chicken entrail readings, whatever.

I happen to agree with this and ardently hope that more studios continue to see through the rhetoric and find ways of building process which values individuals and interactions (people) above process. Every practice has to be examined and questioned.