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:

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

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:

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
Inspiration

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!