Chapter 20
Self-Organization and Leadership
“At Supercell we celebrate success with beer and failure with champagne.”
—Ilkka Paanenen, CEO (Lappalainen, 2015)
In 2004, my life was threatened by a publishing executive. Our parent company had acquired Sega, who would now control our studio, and a group of us who led High Moon were meeting some of their executives for dinner in San Diego. None of them spoke English, so they brought a translator. At one point during the meal, we were being reprimanded for being late on our first game by a very scary Sega executive and, in mid-yell he drew his finger across his neck. We immediately turned towards the translator for clarification of the gesture, hoping that it implied something more benign in Japan.
Unfortunately, the translator was attempting to soften the message and merely said the executive was “encouraging” us to hit our deadlines, but we didn’t buy that. This became a significant impulse to explore new ways of working. Threats to your life will do that.
But much credit for our transformation goes to our CEO, John Rowe. He recognized the need for radical change and merely told us to do whatever was necessary. He gave us his full trust to succeed or fail. That trust was exceptionally motivating. We didn’t want to let him down and we didn’t.
That was a great lesson for me. Giving people the trust and authority, while setting the vision for where we want to go, engages people in their work. This can be expanded to every level of the studio.
The Solutions in This Chapter
Motivating creative workers can be a challenge. The book, Drive: The Surprising Truth About What Motivates Us, by Dan Pink (Pink, 2013) summarizes three factors, which decades of study revealed motivated creative workers:
Autonomy: A desire to be self-directed
Mastery: The longing to improve skills
Purpose: The impulse to work on something important
This chapter focuses on the autonomous factor. Self-organization is the principle of exploring the boundaries of what we can allow developers to decide on their own. By growing autonomy, we grow responsibility and engagement.
This chapter demonstrates that self-organization has benefits, but that there is no formula and that every studio must find what works for it. The chapter also describes what leadership in an Agile organization encompasses and how coaching, at the studio level, can help.
Self-Organization
The Scrum Guide says:
“Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.”
“Development Teams are structured and empowered by the organization to organize and manage their own work.”
Self-organization is the most culturally challenging aspect of Scrum. It requires a lot of trust and team maturity to grow. Despite the sound of it, it still requires leadership.
Many organizations outside the game industry have embraced self-organization. The book Reinventing Organizations (Laloux, 2014) describes the benefits and challenges those organizations have faced.
In the game industry, we’ve seen a few self-organizing studios emerge. These studios have the following attributes in common:
Their leadership hierarchies are far flatter, with fewer layers between studio leadership and development.
Individual teams are given a great deal of freedom to guide the course of their games and even decide when to abandon them.
They were formed self-organizing from the start, hiring only those people they felt could work in such an environment.
A decade ago, when the discussion of self-organization arose, most felt that the idea was suspect. However, the studios that have formed using flat, self-organized structures have shown that it is possible. Studios such as Valve and Supercell have not only shown that self-organization is possible, but that such organizations can achieve levels of success that most other studios only dream of.
Note that the goal isn’t to transform your studio to the level of self-organization that these studios enjoy—I personally believe that that level of transformation is near impossible—but to use these examples as proof of the benefit that increased levels of team ownership, grown slowly over time, can provide a studio.
Valve Software
In 2012 Valve Software published its new employee handbook.1 The handbook’s release has led to a number of discussions about the merit of the Cabal (what Valve calls its process) and its self-organizing work environment.
1. At the time of this writing, the handbook is located at www.AgileGameDevelopment.com/ValveHandbook.pdf.
Since first reading about the Cabal in 1999 and attending a few Game Developer Conference sessions since, I’ve been inspired. That inspiration was one of the threads that connected Agile thinking to game development. I felt that Valve was the kind of place where I would enjoy working and one of the main reasons for that was the connection to Agile thinking and values, a place where rigid process and hierarchies were considered a barrier to creative development.
Valve’s handbook states this belief near the start:
“Hierarchy is great for maintaining predictability and repeatability. It simplifies planning and makes it easier to control a large group of people from the top down, which is why military organizations rely on it so heavily.
“But when you’re an entertainment company that’s spent the last decade going out of its way to recruit the most intelligent, innovative, talented people on Earth, telling them to sit at a desk and do what they’re told obliterates 99 percent of their value. We want innovators, and that means maintaining an environment where they’ll flourish.”
The handbook goes on to describe the role of an employee in this environment. The criticisms I’ve heard about the Cabal often say, “You need the right kind of people for this to work.” I agree, but I think that the potential pool of such people is larger if you provide mentoring to help the transition into such an environment. The handbook acknowledges this as a challenge:
“There are a number of things we wish we were better at:
Helping new people find their way. We wrote this book to help, but as we said above, a book can only go so far.
Mentoring people. Not just helping new people figure things out, but proactively helping people to grow in areas where they need help is something we’re organizationally not great at. Peer reviews help, but they can only go so far.”
This is a common challenge in any studio that is attempting to increase self-organization. People have to unlearn a lifetime pattern first imposed in our public education systems, which train children how to work in a task-driven top-down hierarchical organization. It’s an even greater challenge for a studio that has been hierarchical, because it threatens the status quo.
Self-organization and leadership aren’t mutually exclusive. Gabe Newell leads Valve; it’s not a pure democracy, but Valve doesn’t have many layers between him and an artist creating texture maps. Nor does the artist being handed a list of texture maps he or she is assigned to create during the week. What self-organization does is to flatten hierarchies and reduce the number of lines of communication between people that need to communicate.
Supercell
Formed in 2010, Supercell’s mobile games lead it to a billion-dollar valuation in 2014 and in 2016, Tencent acquired 84.3 percent of Supercell for $8.6 billion. With a staff of around 200 and yearly revenues of more than $1.5 to $2 billion,2 Supercell outperforms other mobile publishers 10 times its size.
2. https://venturebeat.com/2019/02/12/supercell-revenues-take-a-big-dip-in-2018-to-1-6-billion-and-profits-of-635-million/
Founder and CEO Ilkka Paananen credits the success of the studio to the culture of self-organization. “At Supercell I’m just the team coach and the players score the goals,” he said (Lappalainen, 2015).
As with Valve, Supercell has a flat organizational hierarchy. Small teams, usually less than 10 developers, spend up to a year exploring a potential game before deciding, as a team, whether to deploy it for limited testing or abandon it. Nintendo takes a similar approach: cancelling games that haven’t “found the fun” to focus on those that have.
Why Is Self-Organization So Hard?
So why do few companies ever achieve similar cultures? Why is it so challenging for organizations that adopt the Scrum framework to adopt more self-organization?
Why do few diets work? Why do most people who join gyms after their New Year’s resolution to work out soon quit? Habits are hard to change. It’s the same for studio cultures. As mentioned earlier, an organization that grows in a hierarchical pattern resists the adoption of self-organization.
Observation
Some leaders resist change even when their studio is failing. It always seems to me like the passengers with the best rooms on Titanic refusing to board the lifeboat!
Resistance comes from developers as well, who focus on their tasks and discipline and leave responsibility for solving problems and upholding quality to their bosses. This feels safe, despite evidence that this behavior frequently comes back to haunt those same developers in the form of late-project crunch time and death marches.
Valve and Supercell had the benefit of being founded with the principles of self-organization. Both also have very high standards for hiring. Often new hires won’t make it through a probationary period or simply quit because the environment isn’t a good match for them. Studios that already have a full staff don’t have this option.
Self-Organization Is Not Perfect and It’s not the Goal
Valve and Supercell’s organization demonstrate that self-organization is not impossible and, in the right context, can work quite well. However, examples of working cultures should never be taken as blueprints to model your own culture after.3 Valve and Supercell’s culture were organically grown based on their founding principles. If you impose their practices on your people, I guarantee you that half will quit.
3. As Spotify’s example has shown, as well
That said, pushing the limit of self-organization and growing your culture toward more team ownership and engagement is beneficial. The next section explores more options.
Growing Teams
Team self-organization is a challenging area for teams and studios. Self-organizing teams select their members based on who they believe can help them achieve the best results.
Flattening Hierarchies
With the adoption of cross-functional teams that manage their own work, the need for multiple layers of management decreases. When an artist can just turn in her chair and ask for help from a nearby programmer, it reduces need for intermediate management and tools that might have been needed in the past. This is the Agile value of “individuals and interactions over processes and tools” in action. It’s far more effective.
“Flattening” doesn’t mean “eliminating.” Studios slowly explore how teams can organize themselves and realign their hierarchies based on what the teams need. Flattened hierarchies are often the result of, not the cause of, self-organization.
Self-Selecting Membership
Teams that select their own members exhibit greater levels of accountability. When people are assigned to a team built by management, it’s something that they have no control over, and a lack of control prevents full commitment.
Teams are allowed to change their membership between Sprints, but usually they only make changes at the start of a release cycle. Shortly after a release plan is discussed with the project staff, they negotiate among themselves to exchange members. The teams take the following into account when self-organizing:
What are the release goals and initial release plan? Sometimes release goals require a reorganization of the teams. For example, a game might be transitioning to content production with fewer programmers providing more support to the artists.
What disciplines and skills are required to implement the release goals? For example, if a team that has been implementing a shooting mechanic is now being called upon to create AI characters that shoot back, it needs to bring an AI programmer on board. If some simple changes need to be made to the codebase, perhaps a junior programmer is the best fit.
What are the priorities of the release goals? If teams compete for people, the higher-priority release goal determines where people go. For example, if both a shooting and driving team need AI and there is only one experienced AI programmer, the higher-priority goal determines that the AI programmer first goes to the shooting mechanic team.
Do the team members have chemistry? Although it is often ignored, the chemistry of people working together on a team has as much impact as any of the practices. For example, teams often benefit from having one outspoken member but suffer from having two. Both might be equally talented, but together they just don’t work well. Teams recognize this and should be able to control their membership to avoid it.
Like other Scrum practices, a team isn’t expected to master self-organization from the start. Most studios starting Scrum avoid introducing self-organization at first and over time allow the team a greater degree of influence over who is added and removed from the team. Eventually, the team will make the decisions on its own, with leadership providing help with conflicts and problems that exceed the team’s authority.
The rewards are profound. Self-organizing teams deliver unequalled levels of performance and enjoy their work far more than conventionally managed teams (Takeuchi and Nonaka, 1986).
Dealing with Skepticism
When people first hear about self-organization, they are skeptical. It reminds them of painful childhood memories of not being chosen for a sports team. Indeed, inexperienced teams can treat this practice as a popularity contest. They will need the assistance of management to help them make the best choices. Experienced teams, which understand team commitment, end up making better choices that benefit the game and their teamwork.
When Someone is Kicked off a Team
Occasionally, teams remove a member who is not a great fit. It’s pretty rare for a team to unanimously eject someone from the team. Usually the person ejected has ignored months of Scrum Master coaching and team and leadership feedback about his or her poor performance or lack of teamwork. However, being ejected from a team cannot be ignored. It is a strong statement from a group of peers.
After this occurs, another team willing to take this person has to be found. The new team has to be made aware of the issues that led to that person’s ejection from the last team. Teams cannot be forced to accept people they don’t want.
If it’s the first time this person has been ejected and several other teams are around, the person will likely be able to join another team easily. Most of time this person corrects the issues and becomes a valuable member of another team, or the person simply finds a team where the chemistry is better.
On rare occasions, a person doesn’t work well on the next team either. After a few ejections, it’s common to find that no other team will accept this person. It then becomes management’s duty to release this person from the studio. Sometimes the person gets the message and leaves before this happens.
I’ve only seen this happen a few times. It’s unfortunate, but it makes a statement to the teams: They control their destiny. They are responsible and have the necessary authority to make changes to improve their performance. When this authority doesn’t exist, it doesn’t allow a team to achieve its potential. Teams that can’t self-organize will feel that they are stuck with the members on their team, and there is nothing they can do about it. They feel helpless to make the change they need and don’t make the same level of commitment they possibly could.
When you see the performance of teams that achieve their potential, you stop questioning the value of these practices. Allowing them into your studios does take a leap of faith. Unfortunately, some don’t reach this point and don’t see the potential of great teams realized.
Selecting Practices
After every Sprint, Scrum Teams hold a Retrospective to discuss changes to their practices that would improve their performance and teamwork. This practice leads to one of the major benefits of Scrum: continuous improvement.
To continuously improve, teams must have the ability to change their practices. This is a challenge for many studios. Many studios have very prescriptive methodologies that list a practice for every foreseeable element of work, and any new issue that may arise must be addressed by someone in management.
This creates a bottleneck of decisions and accountability. As a result, outnumbered managers cannot keep up with the daily demands of addressing the impediments of all teams. Small problems are ignored until they become large.
By giving teams permission to solve problems and emboldening them to do so, your organization becomes far more responsive. As it turns out, the people who are closest to the work see the issues far sooner and often have better ideas on how to solve them. They also become more accountable for addressing problems.
Growing Self-Organization
The transformation toward self-organization doesn’t happen overnight. The role of the Scrum Master is to help the team and the studio grow the trust and maturity to take on more ownership and accountability. This is an area where studio culture, which eats strategy for breakfast, can put the hard brakes on self-organization.
Drawing the Line
At High Moon Studios, we established some “laws” that were meant to describe the practices and rules that projects and their teams had the authority over and others that they did not. We referred to these laws as the “state laws” that defined project and team authority and “federal laws” that defined decisions that were made for them.
For international readers, in the United States federal laws govern the entire country, while state laws govern those within a state. If the two conflict, federal laws take precedence.
One example of a federal law was the use of a studio-wide engine and pipeline technology. Studio management didn’t want the teams creating significantly different engines and pipelines for their own games. We wanted the benefits that came from individuals understanding a shared technology as they moved from one project to another. An example of a state law was how the project members organized themselves into individual teams and implemented items from the Product Backlog.
Leadership
When I was a child, my father decided to teach me to swim as his father had taught him: by tossing me into a lake where the water was over my head. After watching the bubbles come up for half a minute, he dove in and pulled me out. I didn’t learn to swim that day. In fact, I learned to avoid even trying for the rest of the summer. With my children, we have adopted a more gradual approach of coaching them to take on greater swimming challenges from a few seconds of dog paddling through the point where they can swim back and forth across an Olympic-sized swimming pool.
Leadership in an Agile organization has a similar challenge. Agile organizations need to grow leadership at every level but find the approach between micromanaging teams and throwing them in over their head that will bring about success. Both of those extremes will lead to failure.
Agile Leadership
In my work, I’m frequently asked to revisit studios I’ve worked with in the past. The visits fall into two categories. The first category is where the studio wants to expand training and coaching for new or promoted employees. The second is where the studio wants a primer as another attempt at adopting Agile.
It’s a bit discouraging to revisit a studio where a previous Agile adoption failed, but there is usually a consistent reason for the failure. The reason is usually in the area of leadership support. An Agile transformation begins and survives only with that support. Leadership can support or destroy an Agile transformation in a number of ways.
Growing Trust and Transparency
Trust and transparency go hand in hand. When no trust exists between leadership and development, then there is no motivation to be transparent. Developers will hide bad news to avoid blame.
To grow transparency, to better react to emerging problems and value, we have to grow trust. Growing trust takes time, but destroying trust can take minutes.
Sticking to Values and Principles
When pressure builds to hit an untenable schedule, a common practice is to abandon doing things “the right way” and go back to what was done in the past, such as
Reduce testing and validating that Product Backlog Items (PBIs) meet a Definition of Done
Impose crunch time
Assign scope to teams instead of letting them commit
Abandoning refactoring and other practices that maintain quality
Leaders can be judged based on how they adhere to their principles and values under pressure. Do they protect the team and do the right thing for the game, or do they bend to the pressure of certain stakeholders?
Anyone leading an Agile transformation needs to understand the principles and values of Agile and lead based on those and their own principles. This doesn’t mean following practices by the book, but understanding the reasons why those practices exist.
Studio Leadership
Studio leaders such as Gabe Newell, Ilkka Paanenen, and John Rowe demonstrate the attributes of good studio leadership:
They create the vision and strategy of the studio and establish its culture.
They live the values they extoll; for example, growing trust from the top down by demonstrating it.
They clearly set the limits of how much authority is given to their teams.
They provide mentoring studio leadership.
They engage with developers, understand their challenges and how they work, and inspire them.
Experience
One of the signals of whether a studio will successfully adopt a change is how much leadership engages with the necessary work. I’ve seen the founders of studios attend a full week of training and be the most engaged people in the room. I’ve also seen studio leaders completely ignore the investment. It seems logical that if you’re going to invest in changing how every developer works in your studio, you should know about it.
Discipline Leadership
The responsibilities of game development leaders (lead programmers, lead artists, lead designers, and so on) change as teams adopt Agile:
Design and planning: Leads still guide the design (gameplay, technical, concept, and so on) for their discipline in concert with the other disciplines and oversee how the design is implemented.
Development allocation: Leads will estimate how many people in their discipline are needed on the project, what areas they will work on, and approximately when they will work on them, but these will only be forecasts. The teams will slowly take over the responsibility of identifying areas of need on a per-Sprint and even Release basis.
Task creation and management: Leads no longer break down work into tasks that they estimate, assign, and track. Teams manage this themselves. Leads still participate in Sprint Planning and helping members of their discipline improve their task identification and estimating skills.
Review and promotion: Although leads may continue to review every member of their discipline on a regular, usually annual, basis, the performance of the team becomes a more important part of their information for the review (see the “Reviews” section in this chapter).
Mentoring: Leads work with less experienced developers to improve their quality and productivity. The lead role shifts from managing primarily through project management tools to one where they “go and see” what is occurring with each developer as frequently as possible (see the later “Mentoring” section).
Team self-management and organization challenges the lead role definition. It’s difficult for many leads to give up making detailed decisions for teams on a daily basis and allow them to risk failure, even for smaller challenges. However, the benefits of growing self-management becomes apparent as some of the more mundane management duties of a lead, such as task creation, estimation, and tracking, are taken over by the team.
For example, a project staff of 80 developers generates and tracks approximately 1,200 tasks during a three-week Sprint (10 teams × 8 people × one task per day ×
20 days per Sprint). This is an overwhelming volume of detail for any group lead to manage and draws her time away from the more valuable leadership duties of her role.
Promotion or Punishment?
I’ve often felt that promoting someone to a lead role was part reward and part punishment. We want to reward artists who create assets quickly, so we promote them to lead artist with a salary increase. At the same time, we tell them they can’t make much art anymore, but must now estimate and track the work of other artists, a job they don’t enjoy as much.
Instead, I would rather have the lead artist continue to make art and teach other artists how to make better art faster, too. For example, using a “verification column” on a task board (see Chapter 8, “User Stories”) is a useful way to create frequent opportunities for mentoring.
Director Roles
The game industry is filled with director roles, such as art directors, technical directors, and so on. Usually these roles are given to members of a discipline who show the greatest level of craftsmanship but who also have authority over the work, rather than a group of people. Often these roles exist to oversee and approve or disapprove of the work being done in their area. Scrum Teams need to adjust their practices to meet the needs of these roles, such as described in Chapter 13, “Agile Art and Audio.”
Mentors
The most important role of the lead is to mentor developers to improve how they work. An example is when lead programmers pair with associate programmers to teach them how to improve their coding and design practices.
Note
Junior programmers often implement simulation solutions that are far too expensive in the CPU resources they consume. I recall one new programmer who was tasked with implementing a wind effect. He started implementing a complex fluid dynamic engine that used 90 percent of the CPU time to simulate thousands of air particles. A lead programmer intervened and showed him a few tricks to introduce a good effect in a few hours that required hardly any CPU time.
Scrum creates opportunities for leads to continue working on games and lead by way of example instead of through a spreadsheet. Rather than spending half a day with a tool creating and tracking tasks, he or she interacts with people working one on one.
Reviews
Another critical role of leadership is to provide career support for the developers in their discipline. In studios that employ a matrix management structure, this takes the form of a yearly management and salary review. This reinforces discipline-centric performance over team-centric performance.
For example, if artists are evaluated on how productive they were creating assets over the past year, then they focus on faster asset creation to improve this metric. As a result, when a teammate interrupts the artist about a game problem, it reduces the number of assets that person creates; the artist then tries to isolate him- or herself to reduce these interruptions for the benefit of a better review. This is not a good dynamic.
Leads in Agile environments have introduced frequent team-based peer reviews to supplement, if not replace, the yearly review process (see “360 Reviews” in Chapter 19, “Coaching Teams for Greatness”). This allows feedback about teamwork and cross-discipline collaboration to be introduced. Individual lead roles for each discipline are described in greater detail in coming chapters.
Servant Leadership
Robert K. Greenleaf (Greenleaf, 2002), who coined the term “Servant Leadership” wrote:
“The servant-leader is servant first. It begins with the natural feeling that one wants to serve. Then conscious choice brings one to aspire to lead. The best test is: do those served grow as persons: do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants? And, what is the effect on the least privileged in society; will they benefit, or, at least, not be further deprived?”
Servant leadership can seem like the antithesis of what leadership is to new leaders like I was 25 years ago. The promotion to leadership can be seen as receiving power over people, but, in fact, it’s the reception of responsibility to empower others. There are many attributes of servant leaders. The following six have stood out for me in the past:
Listen: Servant leaders need to hear the group and to clarify its needs. They often need to silence their own inner voice (agenda) first.
Are systems thinkers: W. Edwards Deming said, “A bad system will beat a good person every time.” This is true. Servant leaders should start with finding what led the system to beat someone, rather than blame them. They need to be a student of system thinking and to continually explore better ways of working.
Care for people: No one will give their best creative selves to a leader who doesn’t care about them. Servant leaders know about the lives and drives of their people and stay connected to them. They care about the growth of their people, even going so far as to mentor their own replacements.
Expect greatness and mistakes: Bill Gates was quoted as saying he tried to hire people smarter than him and get out of their way. I’ve always found this to be a formula for success, but it doesn’t happen unless you allow people to make mistakes along the way. There is no better teacher than failure.
Have foresight: Servant leaders have enough experience and the focus to look into the future and help their team avoid the potholes through coaching and powerful questions. This teaches their teams to develop their own foresight.
Build community: Servant leaders help grow the chemistry of the team and facilitate independent interactions (rather than jealously guarding their role as the communication hub). Steve Jobs famously designed the Pixar workplace to force the various disciplines to cross paths and interact as frequently as possible. This philosophy went so far as to include the placement of bathrooms.
People First
“Understand that people are people, and that people are ultimately our job. Our job is people first. Focus on people and make sure they have everything they need.”
—Grant Shonkwiler, Commander & Shonk, Shonkventures
Systems Thinking
In any organization, many interrelated and interdependent parts all influence each other, often creating feedback loops that build in a positive (virtuous cycle) or negative way (vicious cycle).
An example of a vicious cycle is when we stop practices of testing and refactoring when schedule pressures build. As shown earlier, this leads to debt, which grows in time and causes additional delays and further stress.
Taking these interconnected relationships into account is part of systems thinking, which is a useful tool in building virtuous cycles that build quality, speed, and engagement.
Turning a Vicious Cycle into a Virtuous Cycle
Sketching out feedback loops is very useful when approaching a systems thinking model. For example, I often see the cycle occurring in Figure 20.1.
Figure 20.1 The vicious cycle of distrust
This vicious cycle increases distrust between management and development as each side games the other to protect itself. Less work gets done, and quality suffers.
A significant role of leadership is to identify these vicious cycles and find ways to turn them into virtuous cycles. We do this by changing the vicious cycle of distrust into a virtuous cycle of trust. The greatest opportunity to begin this is in the Sprint Planning and Review meetings and to reinforce it during the Sprint.
Building Trust in Sprint Planning
Building trust in Sprint Planning is simple enough: Let the team refine the Sprint Goal by selecting the work it feels it can accomplish. Leaders must resist the temptation to push more work on the team because they distrust the team and fear they are padding. The team might be padding the schedule because it distrusts the leaders and expects the push. Building trust takes time and courage.
Teams build trust by challenging themselves. As mentioned in previous chapters, teams that achieve their Sprint Goals every Sprint usually are protecting themselves. Planning even two weeks of work can be uncertain. Teams and leaders that trust one another don’t worry about the occasional overcommitment.
Building Trust in Sprint Review
Leaders must trust that the team has done its best to accomplish what it has in the Sprint. If a team has run into problems, focus on solving those problems or improving practices, not blaming the team.
Teams build trust with leaders through transparency. By sharing not only what went right, but what went wrong and being accountable for their work, they build trust with the leaders.
Building Trust During the Sprint
As a leader, the hardest thing for me when adopting Scrum was to leave teams alone during a Sprint. Previously, half my day was spent walking around and directing people and solving their problems. The problem with this was that it destroyed a sense of responsibility at the development level. They thought, “Why should I worry about solving problems if Clint is going to tell me how to solve them anyway?” It put a lot of stress on me and disengaged a lot of developers.
After we adopted Scrum, I forced myself to stop micromanaging people. It was hard at first, and, lacking the purpose I previously had, I spent more time surfing. For a while, people thought I promoted Scrum so that I could surf more.4
4. We even made a video mocking this: https://youtu.be/UT4giM9mxHk.
As trust builds, developers will seek out leadership as needed for technical and dependency issues and questions. Leadership becomes more of a support structure. The vicious cycle then becomes a virtuous cycle, as illustrated in Figure 20.2.
Figure 20.2 The virtuous cycle of trust
Seeking Out Systems
Systems exist throughout the studio: production feedback loops, departmental issues, stakeholder communications, and so on. Books such as The Fifth Discipline (Senge, 1990) are a great resource to explore them further.
Intrinsic Motivation
In 2009, the book Drive 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 in the book 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. The following sections cover each item in the preceding list in more detail and how Agile values and Scrum practices support them.
Autonomy
The purpose of self-organization is to give the people closest to the work autonomy in taking greater ownership, as they 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 manages its membership and the practices it uses to create an increment of the game.
Mastery
By allowing the team the freedom to decide “how” it implements a Sprint, it explores better ways of working. When our level artists had the freedom to explore new ways of creating levels, they eventually found methods that reduced level creation time in half.
Purpose
Teams that are formed around the skills necessary for a feature area are far better connected to the purpose of their work. When your Sprint Goal is to demonstrate an improved game and everyone essential to accomplish it shares that goal, there is no confusion about your purpose.
Leaders cannot force developers to be motivated. They must find it within. The role of leadership is to help create the conditions for intrinsic motivation to flourish. 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 reinforced quickly and that mistakes are not punished but initiate a conversation to highlight what valuable thing we learned from the experience.
Flow
I discovered computers when I was 14 years old. That might make me sound like a late bloomer, but back then, there was only one computer in our high school.5 This big, noisy, slow clunker of a machine sat alone after school hours, and I was allowed to play with it. Rather than a screen, it had a teletype that shook while it slowly pounded out text. I hunched over that teletype working on my first game for hours every day.
5. And I had to walk uphill in the snow to use it.
For the next few decades, the focus of writing code addicted me. I loved it. I lived for it. What I was feeling was later coined flow.
The concept of flow was originated by psychologist Mihaly Csikszentmihalyi, who wrote in 1990 that “I developed a theory of optimal experience based on the concept of flow—the state in which people are so involved in an activity that nothing else seems to matter; the experience itself is so enjoyable that people will do it even at great cost, for the sheer sake of doing it” (Csikszentmihalyi, 1990).
What Csikszentmihalyi’s research showed was that the state of flow is not only enjoyable, but also extremely productive. Most game developers have experienced it.
It turns out that flow can be created and sustained (in the “zone”) by working on things that challenge one’s level of skill, but not too much. Figure 20-3 illustrates this zone of flow.
Figure 20.3 The flow zone
When challenges are too high for our skill, we get anxious and stressed. We get out of flow until our skills rise to meet those challenges or the challenges are offloaded. When the challenges fall below our level of expertise, we get bored and need a greater challenge to get back into the flow.
Internet Filters
Studios often install filters on Internet traffic to limit access to social media or other sources of distraction on the Internet. This is done because managers see developers spending time on the Internet, rather than working on a game.
These filters are another case of treating the symptom instead of the cause. A typical cause is that the developers are either bored or frustrated: They are not in flow. Finding ways to challenge them at the appropriate level is a better solution.
Helping developers find flow in their work involves finding the appropriate level of challenge while they increase their skills.
The Essence of Flow
“One source of frustration in the workplace is the frequent mismatch between what people must do and what people can do. When what they must do exceeds their capabilities, the result is anxiety. When what they must do falls short of their capabilities, the result is boredom. But when the match is just right, the results can be glorious. This is the essence of flow.”
—Daniel H. Pink (Pink, 2013)
The following sections provide tips for helping creatives find flow.
Finding the Right Challenge
The earlier “Intrinsic Motivation” section describes how mastery, autonomy, and purpose motivate creative people. Developers want to improve their skills and have a vision for what they are working on.
Rather than trying to discover the appropriate level of challenge for each developer, leverage autonomy to let them, with their team, discover it for themselves. By establishing a vision with teams, they find purpose. As a team, they support one another to find the right challenge. When a team member’s challenge is too great, the team supports that person. When a developer, for example, is challenged too little, he or she can help another or the team can take on more challenging work in its next Sprint.
Increasing Skills
Mastery, as another intrinsic motivation, is the desire to improve one’s skills. The best studio cultures are the ones that embrace learning. They spend time and money to grow knowledge. Rather than worrying about investing in people who may leave, they create a culture where people thrive in an environment they don’t want to leave.
Practice: Wednesday Pizza Topic
Growing knowledge and skills should be an essential part of being a game developer. Unfortunately, the pace and urgency of work can make that growth less of a priority. A great practice is to set aside time for learning. Sometimes it can be done for just the cost of several pizzas.
Wednesday Pizza Topic is a practice where a developer presents a topic to a group of other developers every Wednesday night, over pizza. The format can be whatever the presenter wants, but interactivity and demonstration are always encouraged. The only overhead is to have someone facilitate the practice by
Scheduling the space
Organizing and promoting the future presentations
Ordering the pizza
Here are some tips for these types of learning sessions:
Sessions don’t have to be on Wednesdays or after work. Lunch sessions work, too.
We found Wednesday to be the best day because it breaks up the week, and more people can attend during this less busy time.
Sessions can focus on a single discipline such as technical topics for programmers or art topics for artists or cross-discipline topics, which are excellent.
They don’t have to apply to game development directly. A designer who had a film background ran sessions where he analyzed popular films.
What used to challenge a developer will no longer be a challenge as his or her skills increase. Helping developers find greater challenges and grow is an essential part of leadership.
Studio Coaches
A useful practice outside the game industry is to hire Agile coaches (full time or consultants) to come in and work with teams and leaders to help improve their Agile adoption. Having a good coach help an organization navigate its transformation can be very valuable and save years of effort exploring better ways to work and grow self-organization.
Studio coaches
Coach at every level of the organization from development to CEO
Coach Scrum Masters and Product Owners
Coach developers on improved practices that other teams have explored
Coach leadership on their role in improving self-organization
Are relentless in learning more about improved practices and coaching techniques from outside the studio
This practice has a number of challenges, as well. I’ve found that the ratio of good coaches to people who call themselves coaches (anyone can) is low. Coaches with experience and training (such as a Certified Scrum Coach) are usually booked for a year or more. Also, someone who comes from the outside of your organization doesn’t know your culture very well and isn’t trusted at first by the people he or she is coaching.
This practice is more of a problem in the game industry because very few coaches have made a game in the past. As earlier chapters have discussed, Agile game development best borrows from a set of different frameworks. Many coaches prefer their own “brand” of Agile.
The best approach I’ve seen is to “grow your own” coach. Very often a team Scrum Master demonstrates good potential to increase his or her role into a studio coach, working with all teams and helping the studio improve as a whole. This doesn’t have to be a full-time role at first. It requires an investment to train this person by having him or her attend courses that focus on coaching.6
6. I recommend the Advanced Scrum Master (A-CSM) courses through the Scrum Alliance, which I also teach.
Exception to the Rule
Often when an external coach visits, people give that person more weight than an internal coach. I saw this when Mike Cohn coached us and see it when I visit studios. An external coach can use the same words said before, and people will treat it as a new revelation.
Shifting Roles
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 (see Figure 20.4) from the book Large-Scale Scrum: More with LeSS (Larman, Vodde, 2017), which illustrates the shift.
Figure 20.4 The focus shift (from Large-Scale Scrum: More with LeSS (Larman, Vodde, 2017)
The figure illustrates the shift of focus for the Scrum Master over time. When teams first form, a Scrum Master’s focus is on the role of the Product Owner and the team practices. Over time, as the team becomes more self-organizing, the Scrum Master’s focus will shift to coaching the team on improved development practices and the organizational issues that are impacting team performance.
Large-Scale Scrum: More with LeSS
As teams improve, impediments from outside the team become more pronounced and impactful. For example, upper management might be behaving in a way that impacts team commitments and the quality of their work by interrupting them mid-Sprint. As a result, the Scrum Master focuses more on coaching the organization outside the team and on development practices used at every level.
Experience
I compare a Scrum Master to a soccer coach. Professional soccer coaches don’t do much during a game. I compare this to my son’s soccer coach. He worked like crazy running along the sidelines yelling “kick and run!” A new Scrum team, like a team of little kids playing soccer, needs a fulltime coach, but over time the team learns how to coach itself through many situations. If after years of doing Scrum, a team needs a fulltime Scrum Master, it either has the wrong person in that role, or a whole lot of studio impediments aren’t being resolved.
Organizational Impediments: The Level Production Battle
One impediment 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 that required a single level. All other levels were being produced by a level production team, but because we required a unique level, we decided to build it ourselves.
After a few weeks of production, our level artists found that building the level in the Unreal Editor, rather than the studio standard of 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 and began directing the level designers on our team to return to using Maya. When our designers pushed back, their jobs were even threatened!
We (the Scrum Master and I, as the Product Owner) 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.
Impediments Caused by Studio Culture
Studio culture can often impede improvements. There are many reasons, including the following:
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. Most game developers play games and have great ideas about how to improve the game they are working on.
Executives can override development on a whim and destroy trust.
Scrum Masters, who usually have little authority at this level in the studio, must use their organizational coaching skills to overcome these obstacles.
Adoption Strategies
The strategy for rolling out Agile to your project or studio has to be carefully considered. Transitioning an entire project is challenging. A bottom-up or beachhead approach proves that Agile practices introduce beneficial change with less risk. However, this approach takes more time.
This section addresses strategies and specific tools and practices for studios to use to manage adoption.
Beachhead Teams
During World War I, the major combatants fought battles on vast front lines. Offensives were launched along these fronts in massive attacks. Because of the ever-increasing lethality of twentieth-century weaponry, these attacks were often ineffectual and resulted in nothing more than heavy losses in the attacking force. The war became a series of deadly stalemates and attrition. Eventual victory came to the side that could withstand more losses than the other.
Battles in World War II were different. They were often marked by the penetration of a small area of the front by a focused attack. Large units poured into the breach, taking advantage of the confusion and disarray of the opposing army. Offensives such as the Battle of France and D-Day are examples of this strategy.
A similar approach of introducing Agile provides an effective way of overcoming the well-founded concern about large-scale change. Small teams first experiment with iterations to increase studio knowledge about its benefits before it is rolled out to a larger group. These teams are often referred to as beachhead teams. If a beachhead team is able to establish a foothold and find success with Agile practices, it encourages other teams to adopt them.
Beachhead teams have an improved chance of success for a number of reasons:
They can be staffed with people who are open-minded about trying it.
One team is more easily coached than a dozen. Teams new to Agile will have many questions.
They can take on noncritical features at first, which puts less pressure on them to get it perfect the first time.
This seems like stacking the deck in Agile’s favor, and it is. It’s similar to planting a seed in a garden; its germination period is when it is most vulnerable. Conditions have to be carefully monitored during this time. Even if everything is done right, the plant might not grow. If the soil is the wrong type or if there is not enough sunlight or moisture, no amount of care will allow it to grow.
The same idea applies to the beachhead effort. Agile may not “take” in the studio. The soil (culture, management style, and so on) might not be fertile for it. In this case, it’s better to see the experiment fail with one team than a dozen.
If a beachhead team is successful employing Agile and the studio wants to increase its use, there are three methods to use: split and seed, split and reform, or cross-team coaching.
Split and Seed
In the split-and-seed method, a successful beachhead team is split up to “seed” other teams that are starting Agile. This enables the most rapid deployment of Agile experience throughout the studio. About eight teams can be seeded this way. Figure 20.5 shows what this looks like.
Figure 20.5 Split-and-seed strategy
The drawback of this approach is that a successful team is broken up. Breaking up such a team is likely discouraging to the members. When random people are grouped, it takes time for them to form a strong team, if it happens at all. The other disadvantage is that not all the members of the original team will be effective coaches for the newly formed teams.
As a result, a good team might be replaced by half a dozen or more that aren’t nearly as effective. It can make the beachhead result look like a fluke. Therefore, this approach is not recommended if a more gradual adoption of Scrum is possible.
Split and Reform
In the split-and-reform strategy, the beachhead team splits into two, and each team brings in new members. This results in a slower adoption speed than the split-and-seed approach, but it enables each half of the original team to stay together.
This strategy, illustrated in Figure 20.6, is a compromise between the number of teams created and the desire to allow teams to remain together.
Figure 20.6 Splitting the beachhead team into two teams
Although not as traumatic as split and seed, this approach still splits up a successful team and can result in dysfunctional teams. The old guard from the original beachhead team might exert more ownership of the process, which inhibits ownership and commitment from the new recruits.
Cross-Team Coaching
A third solution is to leave the beachhead team in place and have it coach other teams transitioning in a number of ways:
A member of the beachhead team serves as a part-time member of a new team. He commits 50 percent or less of his time to each team.
A member of the beachhead team becomes the Scrum Master on one or more new teams.
A member of the beachhead team attends a new team’s Daily Scrum, Sprint Planning, Review, and Retrospective meetings, offering advice and coaching whenever the team has questions about Scrum practices.
This cross-team solution, illustrated in Figure 20.7, will subtract some time from the beachhead team’s Sprints, but the team will recover it over the following several Sprints as the new teams come up to speed on the practices, needs less of members’ time, and eventually replaces them.
Figure 20.7 Cross-team coaching
The number of new teams transitioned to Agile this way is limited to how many members of the beachhead team are suitable coaches and how much time they can spare.
In most cases, cross-team coaching is the best method of deploying multiple Agile teams from the beachhead team. It enables members to retain a successful team and deploys Scrum quickly throughout a project or studio.
Coaching Lesson: Don’t Adopt Major Changes Before the First Deployment
When a studio contacts me to schedule training or coaching teams on new practices, I ask it where the team is in development. If the team is close to deploying the first version of a game (within six months), I suggest the studio defer the training until after the team has deployed and things have settled down. The reason is that teams under pressure tend to revert to the “old ways” of working and the time spent training is wasted.
Full-Scale Deployment
Some studios desire a companywide or projectwide deployment of Agile. This presents more risk to the studio, as any major process change would, but if done properly is the fastest way to roll out Scrum. This section discusses the areas of risk and an overall strategy to reduce it.
Transition Planning
Full-scale deployment has to be planned more carefully than the beachhead team experiment. The larger the number of people transitioning, the more challenging it is to communicate and sustain the vision for why change is taking place and to create the conditions that enable them to start using Scrum quickly. This is the goal of transition planning.
Note
Transition planning is also needed after a beachhead team has proven successful and a larger number of teams are deployed from it.
First, a transition team is formed to establish the initial team organization, federal and state laws, and a Product Backlog.
A transition team should consist of the following:
Product Owner
Scrum Masters
Studio executives
Discipline leads
Have at least one person become a Certified Scrum Master (CSM).7 This provides an exposure to Scrum practices and principles to ensure the team starts on the right path.
The next step is to establish roles and definitions. This is best done in a meeting with all the executives, stakeholders, Scrum Masters, and project leads that form the transition team that is responsible for the transition. The CSM or a Scrum coach facilitates this meeting.
The Product Owner and stakeholders for the project and Scrum Masters for the teams are identified. They must all be well versed in the duties and responsibilities of the Product Owner role.
Note
Product Owners should be considered fulltime on any project of three or more Scrum teams. Ideally, they should attend a Certified Product Owner (CPO) course.
The studio executives discuss their expectations and roles with the group. They must be aware of the principle that teams are committed to work during the Sprint and that all changes in priorities to the project should occur outside the Sprints themselves.
This transition team should help the Product Owner create an initial Definition of Done. Does it mean that each story must run at a minimum frame rate on the target platform? Does it have to run on the development platform? The transition team needs to establish the baseline definition with the expectation that it will improve over time.
The First Release and Sprint
The next step for full-scale Scrum deployment is to prepare for the first release for each project. This begins with establishing an initial Product Backlog, Release goals, and a Release plan created in a Release Planning meeting (see Chapter 9). This meeting is conducted by the transition team or with the entire project staff, if it’s not too large.
After a Release plan is ready, the transition team will meet with the entire project staff to discuss the goals of the release. Leading up to this there should be a number of meetings with the teams to educate them about the practices and goals of Scrum.
The goals of the first Sprint should be modest to establish a cycle of success. The first Sprint will reveal a lot of problems with the existing studio practices and the team’s adoption of Scrum.
Tip
Management should be careful not to go too far promoting Scrum. The team will be sold by the results. Overselling Scrum will turn some developers off. The best thing for management to do during a Sprint is to support the teams by helping them address every impediment they can’t solve themselves. There will be many at first. When the teams see management being facilitative, it will sell them on Scrum more than any entreaty about its benefits.
The following are the principles and practices that team members need to understand in preparation for their first Sprint:
They are committing to Sprint goals as a team, not as individuals committing to their own tasks. The entire team will succeed or fail on this basis. Overcommitting is not a great danger, because they can renegotiate with the Product Owner during the Sprint. Teams new to Scrum are more likely to underestimate their work.
Commitment is reciprocal. Management will not change their goals or the Sprint review date without a Sprint reset.
The Definition of Done must be clearly understood between the team and the Product Owner. The functionality delivered at the end of the Sprint must reflect this definition.
The rules of the Daily Scrum are understood.
The purpose and utility of the burndown chart are understood.
Experience
Iterating on any change within one to three weeks is challenge enough for some teams!
Following the first Sprint, the Scrum Masters will need to set aside several hours to run Retrospectives for the teams and then meet with the transition team to discuss the results.
Establishing the Product Backlog
A goal for the first release should be to refine the Product Backlog. This usually includes the following:
Discussions with the publisher and license holders to establish a vision for the game
Concept and design work to refine the vision
Infrastructure work and risk identification
All of these elements are used to create a backlog and prioritize the stories within it.
Tip
It’s easy to go too far and create a Product Backlog that is too finely detailed and unwieldy. The Product Backlog should be large enough to support several releases of stories, with detail decreasing with priority, yet not so large that the burden of maintaining it is too great. For a console game, 300 to 500 stories on the Product Backlog is a good target. For an iPhone game, probably 100 to 200 stories are enough, but your mileage may vary.
What Good Looks Like
The chapter started with describing what good looks like at the extreme end of self-organization: Studios built on the principle of self-organization have dominated their sectors. But they are merely examples that self-organization is not impossible, not patterns to be duplicated.
Self-organization can benefit at every level of adoption:
Teams that organize and manage their own Sprint Backlog usually do a better job than teams that are handed a set of tasks estimated by leads.8
8. https://docs.broadcom.com/doc/the-impact-of-agile-quantified
Teams that have some control over their membership usually do a better job than teams that are organized by a resource plan.
Developers who have some creative input over their work are usually more engaged in that work than developers who do not have input.
Leaders are necessary to grow self-organization. They exist to serve the teams and get out of the way, when necessary, extending trust and understanding that failure is a necessary part of making something that’s never been made before.
Summary
Exploring roles and team structures is an ongoing process. Teams must use the retrospective practice to find ways to improve how they work together and with the leaders of the studio. Allowing teams to take ownership and authority over some of the daily aspects of their life leads to their being more likely to take responsibility for their work. This doesn’t happen overnight. It takes years in many cases and will create head-on collisions with studio leadership culture. The results are worth the effort.
Additional Reading
DeMarco, T., and T. Lister. 1999. Peopleware: Productive Projects and Teams, Second Edition. New York, NY: Dorset House Publishing.
Greenleaf, R. K. (2002). Servant Leadership: A Journey into the Nature of Legitimate Power and Greatness (25th anniversary ed.). New York: Paulist Press.
Katzenbach, J. R., and D. K. Smith. 2003. The Wisdom of Teams: Creating the High-Performance Organization. Cambridge, MA: Harvard Business School Press.
Laloux F. 2014 .Reinventing organizations: a guide to creating organizations inspired by the next stage of human consciousness. Brussels, Belgium: Nelson Parker.
Lappalainen, E. 2015. The Realm of Games. Jyväskylä Finland: Atena Publishing.
Larman C. and Vodde B. 2017. Large-Scale Scrum: More with LeSS. Boston, MA: Addison-Wesley.
Pink D. 2013. Drive: The Surprising Truth About What Motivates Us. New York: Riverhead Books, U.S.
Senge PM. The Fifth Discipline: The Art and Practice of the Learning Organization. New York: Doubleday, 1990.
Takeuchi, H., Nonaka, I. 1986 The New New Product Development Game, Harvard Business Review, pp. 137–146, January–February.
The Greenleaf Center for Servant Leadership; rev Edition (September 30, 2015).