Chapter 18
Team Transformations
Although Agile practices are simple and easy to learn, its adoption challenges organizations, processes, and cultures. It can take years to overcome those challenges. Although each studio and team has its own pace of adoption and challenges, there are enough common ones to establish a rough road map.
The Solutions in This Chapter
This chapter reviews some of the team challenges presented by a move to Agile and discusses some strategies for helping organizations and teams adapt. These strategies apply to all Agile teams regardless of whether they are using Scrum or Kanban.
The Three Stages of Team Transformation
In the movie The Karate Kid, a boy wants to learn karate from an old master. The master agrees but only on the condition that the boy does what he is told. The master begins by having him wash and wax his cars, paint his fence, and sand his patio floor. The only constraint he imposes is that the boy uses exact motions for each chore. For example, when waxing the car, wax is applied in a clockwise motion with the right hand and removed in a counterclockwise motion with the left hand.
After days of effort, the boy is exasperated. He expected to be taught karate, not perform chores. When he complains, the master has him repeat the motions he was shown for the tasks as he throws punches and kicks. The movements used for the chores are the exact motions used to block such attacks; the chores were meant to teach them subconsciously.
The movie illustrates the first stage of martial arts competence: the apprentice stage. In the apprentice stage, the student focuses on the proper forms; in other words, he is learning the basics. The second stage is the journeyman stage. Here the student modifies the motions to leverage his strengths and offset his weaknesses. The third stage of martial arts competence is the master stage. Masters create their moves. They reinvent the art because they know the underlying principles.
Note
In martial arts, this progression is known as Shu, Ha, and Ri.
A similar progression of stages is seen with teams adopting Agile principles. Teams cannot master self-organization and continual improvement from the start. They need to establish muscle memory with basic practices in the apprentice stage; expand, add, and change them in the journeyman stage; and then take full control of how they organize and achieve their goals in the master stage.
Figure 18.1 shows the three stages of Agile adoption.
Figure 18.1 The road map of Agile adoption
Note
Apprentice, journeyman, and master stages are not guidelines but convenient labels that help identify typical milestones of progress with Scrum. Different teams have different pacing and will improve in different orders than what is represented by the road map.
The Apprentice Stage
In the apprentice stage, teams become accustomed to iterating on features and committing to their goals. They are challenged to deliver an improved version of the game that requires cross-discipline collaboration. They learn to step up every day as a member of a team committed to the goals and to report any impediments.
The team establishes a shared Definition of Done between it and the stakeholders. Adopting a shared Definition of Done puts pressure on individual skills, fundamental development practices, and the communal build process and pipeline. The new Definition of Done will almost certainly force changes and improvements. These improvements appear quickly and demonstrate the benefits of Agile.
Adjusting to Sprint Pacing
Many traditional teams don’t need to demonstrate their game to stakeholders very frequently. Often a demonstration is given every several months when a milestone is due. The work required to integrate changes made since the last milestone to fix errors and polish the game often requires the final few weeks before the milestone date.
When teams transition to Agile, the pace of producing a working game for demonstration to the stakeholders is accelerated. Now they need to show something at a more frequent cadence. The immediate problem is that creating a build now occupies a more substantial fraction of time. Teams can spend 50 percent of their time maintaining a working build. This overhead puts pressure on the practices used to commit and test changes to the game. Rather than abandoning Agile because iterating is costly, an Agile team finds ways to drive down the cost of iterating. Chapter 11, “Faster Iterations,” covers this topic.
Defining “Done”
Traditional project management does not fully burden developers with the responsibility of judging when a feature is complete. They merely need to accomplish tasks assigned to them on time. Agile requires teams and stakeholders to develop a Definition of Done that they agree upon. Establishing this definition challenges the apprentice team.
At first, this definition might only require a game to run without crashing. Later, a feature may be expected to run on a target platform at 30 frames per second. The challenge with the Definition of Done is that it causes new tasks to emerge during development. At first, teams might ignore these tasks; they think a successful iteration means that all the estimated tasks are completed at the end. It comes as a shock to them to learn that the working game is considered more important than task completion alone.
As the Definition of Done is refined and understood by teams, they will factor an amount of uncertainty into planning. If past efforts required 20 percent additional time for work not reckoned for, teams would leave that much slack in future planning sessions. This is covered in detail in Chapter 7, “The Product Backlog.”
Daily Scrum Challenges
The Daily Scrum is an essential practice of an effective team. Without it, teams would find it more challenging to manage their progress toward the best possible iteration. The Daily Scrum is a discussion among teammates ensuring they understand the state of the game, their progress towards their goal, and what is to be worked on next.
Daily Scrums are hard to get right from the start. Dysfunctions or misunderstandings about the purpose of this practice can prevent teams from achieving its full benefit. This section describes some of the common dysfunctions and ways to alleviate them.
Reporting to the Scrum Master
When the team members report to the Scrum Master in a Daily Scrum, rather than the team, it indicates that they view the Scrum Master as a manager, which creates a barrier to ownership and commitment. Team members may think it’s the Scrum Master’s job to solve all of their problems and tell them what to do. This is common with an apprentice team. The reason for this behavior is that people need to overcome a career history that allowed far less ownership. They don’t yet fathom or trust that their team takes ownership of the goal and controls the means to achieve it.
The Scrum Master can subtly discourage this behavior through several practices. For example, he can avoid eye contact with the person speaking in the Daily Scrum, which encourages the person to address the entire team. The Scrum Master should also pose critical questions such as “What problems could we have with achieving our goal?” or “What do you think we should look at next?” These questions drive teams to come up with solutions they own.
Tip
Sometimes not talking at all is the Scrum Master’s best tool. A few moments of uncomfortable silence will often produce some creative ideas. Silently counting to 10 or more gives his or her mind something to do while waiting for the team.
The Scrum Master can inadvertently reinforce this dysfunction. One way is by taking notes at the meeting. Excessive note-taking creates the impression that the task information the team is reporting is being recorded and tracked, which can create distrust. If the Scrum Master needs to record task hours to produce the up-to-date burndown chart, he or she should explain this to the team.
Not Reporting Impediments
Teams not reporting impediments either have none or don’t have a sense of ownership or commitment to their Sprint Goal. The latter is more likely.
The Scrum Master can do a few things to encourage problem reporting during the Scrum. One is to help teams understand that if they weren’t able to achieve the progress they had set for themselves at the previous day’s Daily Scrum, then they ought to report the impediments that caused this to the team.
Key questions help. For example, occasionally adding a fourth question such as “What threatens our achieving the goal?” at the Daily Scrum can help. The team members will begin to speak up, not for themselves, but for the team when they realize that their problems threaten the team’s success and therefore belong to the team.
Micromanaging the Sprint Backlog in Scrum
One of the most common areas where apprentice teams struggle is in learning to self-manage their work. A barrier to doing this is the insistence of the Scrum Master to use an electronic tool to do the job.
These tools are used to
Build the Sprint Backlog
Update the estimates during the Sprint
Display Sprint Backlog details during the Daily Scrum
Spit out the Sprint burndown
Apart from distributed teams, which may benefit from these tools, I rarely see them as positive for new teams. The tools are not at fault, but how they are used.
One of the primary benefits of Scrum is in the boost of productivity seen with teams that have a sense of ownership in how they run their Sprints. Teams with ownership are accountable for their shared commitment to the Sprint Goal. They enjoy their work more and continually explore ways to improve.
Sprint tracking tools can get in the way of that by
Not allowing an “all hands” approach to managing the Sprint Backlog: one mouse, one keyboard, one operator.
The practice of only bringing the data in the tool out once a day because there are not enough licenses, developers don’t want to learn the tool, or the extra effort isn’t worth it.
Limiting the team’s ability to customize the artifacts (task board, burn down, and so on).
Management monitoring the metrics of the Sprint (Sprint velocity, burndown), and even individual developer progress. Guess what happens when a developer or team is asked why their burndown is not diagonal enough?
Making the Daily Standup a status reporting meeting by focusing on individuals.
Even if the tool is used in benevolent ways, the team can suspect otherwise. In organizations that are trying to grow trust, this can be a subtle barrier.
Teams also need their Sprint Backlog to be “radiated” to them. Tools “refrigerate” the Backlog by storing it in the cloud or on a server.
When I point this out, I often hear from Scrum Masters that the tool makes it easier for them to do their job: tracking the Sprint and producing the burndown. I remind them that their job is to help the team build ownership and trust, not to manage them.
The Sprint Backlog is owned by the developers to help them organize and manage their shared commitment and forecast for achieving the Sprint goal. It serves no purpose external to the team.
Lack of Focus on the Goal
Sometimes teams focus too much on finishing the tasks they estimated in the planning meeting and not enough on what shows up in the game. As a result, all the tasks are accomplished, but the value of what was added to the game is limited: Progression stoppers prevent the player from completing a level, annoying bugs are not fixed, assets are missing, and so on.
The main goal of Agile is to add value to the game, but “finding the fun” can’t always be predicted. A lot of trial and error occurs during development. Tasks are volatile when the goal is as subjective as “finding the fun.” For example, an initial Sprint Backlog based on a goal to allow the player to navigate a complex environment may not anticipate all the character control issues that will typically arise. That doesn’t mean the team should avoid responsibility for them. Even if unforeseen work threatens lower-priority stories, the team should add the emergent tasks that the Definition of Done requires.
Scrum Masters encourage this behavior in several ways. One example is to embolden the team to change the Daily Scrum to focus more on the goal. Instead of going around the room to answer the three questions, the team could visit each story on the board and address the progress and issues for them, which focuses the work more on the stories themselves. Another useful practice is to conduct a short play-through of the game before a Daily Scrum, which focuses the team on the value added to a running game rather than progress against estimated tasks.
The team should be creative in exploring the practices of the Daily Scrum to improve the chances of achieving the goal.
Replacing the Daily Scrum with a Tool
I’m often asked by teams starting Agile, “Can we replace the Daily Scrum with a software tool?” My answer is always an emphatic, “No!”
As described earlier, the Daily Scrum is not merely a meeting to update task hours. The Daily Scrum’s purpose is for the team members to inspect their progress and make commitments to each other about the work needed to achieve their shared goal.
Understanding the purpose of the Daily Scrum takes a while for teams new to Agile. In the past, tasks were estimated and assigned to them by managers. How the tasks came together to fulfill larger goals was not their responsibility. Scrum turns that upside down. Teams are given total responsibility for the tasks and how to accomplish the larger goal, which requires a different mindset for the new Scrum team. It’s not a simple challenge; years of muscle memory must be overcome. This is why the Daily Scrum might seem wasteful at first. New teams think it’s all about the tasks and their estimates.
Tasks and estimates are critically important, but experienced teams don’t focus entirely on them. Their Daily Scrum is a beehive of activity that focuses on what everyone is doing to achieve Done and the emergent challenges to their shared goal.
The Journeyman Stage
The journeyman stage of adoption occurs as teams improve how they iterate and deliver value. Iterations are no longer mini-waterfalls with a design phase at the start and a test-and-fix phase at the end. These activities take place daily.
Journeyman teams take more ownership of their practices and process, identifying and solving impediments and examining the underlying assumptions of how disciplines work together. These changes focus on improving their craft and team velocity.
An example of such an improvement was with a team that created characters. The last stage of creating a character was to supply sounds at particular animation trigger points, such as a footstep sound during the walk cycle. One problem was that the animators were checking in all their animations to revision control late in the Sprint, which caused the composers to rush their changes in so the team could achieve its Sprint Goal. This rush didn’t lead to the best sounds added. The solution the team originally applied in their apprentice stage was to create a cutoff rule that all animations had to be checked in five days before the end of the Sprint. This allowed plenty of time to add the triggered audio, but it forced the animators to work on animations that might be needed for the next Sprint after the cutoff. Although this solved the immediate problem, it was a resource-based solution that didn’t improve velocity.
As the team’s experience with Scrum increased, it found a better solution, which required the animators to deliver each unpolished animation as it was created to the composers and then polish the animation after the composer attached audio. Although this might seem like a simple fix, it violated a deep-rooted artistic preference not to share an asset until its completion. In this case, and many others like it, a discipline’s bias was overcome to improve the team’s velocity. Journeyman teams build cross-disciplined trust and find ways of optimizing the entire cycle of development rather than parts of it.
Experience
Apprentice teams often create work to prepare for future Sprints such as writing small design documents or creating partial assets. Journeyman teams eliminate most of this by reducing handoffs and by chopping work into smaller batches of discovery. These changes arise as the barriers between disciplines are broken down.
Journeyman teams also use more long-term Agile estimating and planning practices such as release planning and story point estimation as described in Chapter 9, “Agile Release Planning.” They also introduce change to discipline practices, such as test-driven development as described in Part IV, “Agile Disciplines.”
Release Cycles
Journeyman teams improve releases, planning, and execution. As an apprentice team, they were challenged by the Sprint, but journeyman teams are accustomed to the pace of Sprints. They work with the Product Owner to plan and monitor releases (for example, they might use story point estimation; see Chapter 9). This gives them better tools for forecasting how much they can accomplish over a longer period than just a Sprint.
Team Co-location
Agile principles emphasize face-to-face communication whenever possible. The benefits of this are demonstrated best at the team level. When a team is spread across a studio, the overhead and problems that arise from a lack of easy communication are seen daily. Studies have shown that when teams reduce the physical distance between themselves, their performance increases in many ways (Van Den Bulte and Moenaert, 1998). Eventually, teams realize this and rearrange themselves to improve communication.
Experience
Often a studio’s physical arrangements greatly influence their culture. I typically see this in studios that are based on a number of floors in a building. When game teams or even disciplines are separated across floors, it can create a rivalry that significantly impacts collaboration and work.
Physical Arrangement
Teams that want to co-locate can have limited options. Sometimes an office is arranged with small cubicles that cannot easily be removed because of power and data wiring limitations. Team rooms or “bullpens” are less expensive to create than cubicle farms or separate office spaces, so teams lucky enough to influence the initial office space build-out can create an ideal location for themselves. Otherwise, they may need to adapt their current space by slowly remodeling it. Usually, having one team co-locate to judge the cost and benefit is best before a studio will allow all of them to co-locate.
What makes an ideal team space? There is no single solution. Sometimes teams can’t even agree among themselves about what makes the best space. On a cross-discipline team, the programmers might want windows while the artists don’t want light from the outside. It’s up to the team to work this out. These are some of the other issues teams need to consider when defining their area:
Is there enough wall space for a task board, information radiators (see the note “Information Radiators”), and whiteboards? Teams can never have enough wall space!
Is there enough “slack” in the space so that developers can pair up or gather around a monitor? For example, can a programmer sit with an artist to discuss a problem?
Is there space for meetings, such as the Daily Scrum or a play-through? Is there a development station available to conduct a play-through with the entire team?
Is the room off the beaten path? Will traffic through the area from people outside the team create disruption?
Are there rooms where people can have private conversations, conduct interviews, or read their e-mail?
Tip
Furniture is also an important consideration. My opinion is that mobile, modular, and adjustable furniture like that built by Anthro1 is best. Teams change and improve over time. The ability to regularly rearrange their space creates a big benefit.
Information Radiators
An information radiator displays information in a place where those passing by can see it. With information radiators, those passing by do not need to ask questions; the information simply hits them as they pass (Cockburn, 2007).
Concerns About Co-Locations
Before teams co-locate, members often raise concerns about the potential problems of co-location. Two of the more common concerns are covered in this section.
The first is that programmers (artists, designers, and so on) need to work in quiet isolation to focus and be effective. We can’t do this in a noisy team room with constant interruptions.
There are certainly more interruptions in a team room. Most of these are the point of the team room. When developers are trying to achieve individual goals, such as writing some code or creating an asset, interruptions often impede them from achieving that goal as quickly. However, Agile emphasizes the delivery of value integrated into the game, not the value of finishing “parts” that should join flawlessly because a document or Gantt chart states they will.
When a team is focused on achieving a common goal that requires everyone’s participation, fast access to other team members who can help progress is essential. For example, having an animation programmer build an animation system apart from the animators doesn’t make sense. They should be solving the problem together.
Noise and interruptions from outside the team are usually a source of unnecessary disruption. Teams should strive to eliminate things that distract them from their goals, such as public-address systems (DeMarco and Lister, 1999).
Experience
Every team that I have seen co-locate doesn’t want to return to isolation.
If I am not sitting with a group from the same discipline, then I won’t learn and collaborate with them as much.
This argument creates a barrier for teams who want to co-locate, but it does have some validity. One example of this was in a large studio where half a dozen AI programmers were spread out across three teams. This led to three incompatible AI solutions, each duplicating the effort of the others. Although having an AI programmer close to the designers and animators was beneficial, there still needed to be communication that occurred with the other AI programmers. Communities of practice, described in Chapter 21, “Scaling Agile Game Teams,” enabled this to happen. The AI community of practice met as frequently as necessary to share knowledge that benefited all their teams needing AI.
Release Dysfunctions
Teams can encounter some common dysfunctions as they start using releases, rather than Sprints alone. These are usually caused by the longer time frame and the difference between the Definition of Done for a Sprint and the more demanding Definition of Done for a release. Also, the release cycle can bring out vestigial waterfall behaviors that cause problems.
This section identifies symptoms of release dysfunctions and identifies ways to help the team cure them.
Hardening Sprint Used as a Dumping Ground
Hardening Sprints, described in Chapter 9, are a practice that teams should strive to minimize or even eliminate. The danger from hardening Sprints is that they become a dumping ground for work that should be completed during regular Sprints. Left undone, unfinished work interferes with progress and reduces team productivity.
Here are some warning signs that hardening Sprints are being abused:
Artists are postponing asset completion and leaving too many stand-in or missing assets in the game each Sprint.
Programmers are deferring bug fixes.
Designers are not tuning features for gameplay value.
Every Sprint should achieve a level of Done that includes much of this work. If this isn’t happening, then the Definition of Done needs to be improved to include it.
Tip
Frequent play-throughs during the Sprint can help the team focus on making sure its work is done.
Postponed Value
Apprentice teams often divide Sprints into phases, treating them like mini-waterfall projects. A similar problem can affect teams during releases. Early Sprints are considered “design Sprints,” whereas later Sprints are focused on debugging, tuning, and polishing for the release.
Velocity is used to measure the progress of a release and forecast its completion (see Chapter 9). This forecast assumes that the velocity trend will be a straight line through the remainder of the release. However, teams might experience a velocity drop-off toward the end. This is often accompanied by overtime, as teams compel themselves to achieve their goals. Teams are working harder, yet velocity seems to be dropping!
Figure 18.2 illustrates this happening over a four-Sprint release. The solid line shows the total story points accomplished during the release. The dotted line shows a subjective value of the game (the fun) from the Product Owner’s perspective (there’s no practical or easy way to measure this; it’s meant to illustrate a point).
Figure 18.2 Velocity and fun in a release
Ideally, because work is being prioritized by value, it should grow faster than story points. In the figure, story point velocity (slope of the dark line) increases quickly at first and then slows down at the end of the release. Value grows slowly at first—there isn’t much “fun” being added to the game in the first few Sprints—but the game becomes a great deal more fun in the last few Sprints.
What happened is that the team used a waterfall approach in the release, treating it as a single-phased iteration of the game with integration, debugging, and polishing at the end. This builds up unfinished work in the release, called debt.
Debt consists of the following:
Polishing or tuning work
Assets that are left out or built before the team knows what works best
Bugs that aren’t fixed
Developing large assets in parallel
Debt postpones the actualization of value toward the end of the release, much like a waterfall project defers it until post-production. Teams need to prevent this debt from growing so as to build value continually.
For example, consider a team with a release plan of creating a level that explores various mechanics. This level has many rooms that are each meant to offer different challenges to the player. A team might build the entire level using a phased approach. In the first Sprint, untextured modular parts are used for prototyping the level. In the next Sprint, design places AI and triggered events. Finally, in the third Sprint, detailed geometry is added. Polishing, debugging, and sound design are done in the final Sprint.
By creating a large level this way, the team is building a debt of work that has to be “paid off” by the end of the release. If any of these steps take too long, then the deadline drives the team to rush completion of the entire level or delay the release. This often leads to stressed teams and concerned stakeholders. Another drawback is that a polished experience won’t exist until the end of the release, so the value is not seen until the end. This allows for almost no gameplay iteration on the polished level.
A better approach is to create a polished and tuned section of the level every Sprint. If there are four Sprints in the release, each Sprint Goal might attempt to complete a quarter of the level each Sprint. For example, if your level has a medieval village, castle, forest, and fair, your team would finish one of them every Sprint. If the level is too large for the release, the team will discover it in the first Sprint, and the Product Owner could either reduce the scope of the level or delay the release date. Another benefit of this approach is that polished and tuned gameplay can be iterated on for almost the entire release.
Existing gameplay, tool technology, or rendering technology might not support an approach of vertical slices every Sprint, but this is a further argument for not risking an entire release to such uncertainties.
The Limits of Velocity
There’s been a lot of talk about abandoning the concept of velocity and the practice of using story points among coaches and trainers. Much of this comes from its abuse. Velocity is meant to be used to measure what a team has accomplished that meets a Definition of Done and to use that metric to roughly forecast what might be achieved in the future.
Unfortunately, velocity has been used to set fixed goals for teams, even on a Sprint-to-Sprint basis, and to compare teams to one another. Because velocity is based on relative estimation techniques, it isn’t accurate enough to do either, so teams end up cutting corners to achieve velocity-based goals, usually at the expense of quality.
I usually recommend that, outside of story-point estimation at the epic Product Backlog Item (PBI) level, that developers not be exposed to story points.
I’ve found that most teams that have reached the mastery level have abandoned the use of velocity for feature forecasting because they are better at managing debt and delivering value first.
Improving Iteration
Journeyman teams begin to accelerate the cycle of continuous improvement by altering practices. To do this, they must measure their velocity and focus on improving it.
Journeyman teams will introduce significant new practices such as test-driven development to improve the quality of code or continuous integration, which allows change to be propagated more safely and quickly (see Chapter 12, “Agile Technology”). The team will seek to improve iteration times in every area of development, through automated testing, improved tools, or team practices that move QA closer to the developers (see Chapter 15, “Agile QA and Production”).
Measuring velocity is critical for this to occur. Velocity and other measures of value create the empirical control system at the core of Scrum. Without empiricism, a process is like alchemy, where teams try to transmute work into success through paradoxical practices.
The Master Stage
The master stage is the final stage of Scrum adoption and is the goal of every Scrum team to achieve. Such teams do the following:
Self-organize: Master teams work well together. Great teams are based on chemistry and motivation. They trust one another and achieve a high level of communication. The team decides who joins or leaves.
Drive continual improvement: They take control of the rules. Management merely has to support their needs. These teams take ownership of their own performance.
Enjoy their work immensely: Work is a commitment to their teammates. They are all in it together, and everyone’s contribution and creativity are valued and leveraged.
Deliver the highest level of value: Master teams are often referred to as great teams (see Chapter 5, “Great Teams”), far outpacing other teams.
Experience
Developers on great teams have referred to their experience as a highlight of their career. I’ve been on two such teams in 20 years and have always sought to return to that state.
Master teams are hard to define, but easy to recognize. There is no formula to create them, but I have observed the following:
Independence and a sense of ownership: The team needs to feel that it contributes creatively and has control over how it works.
Leadership: There is often a natural leader on the team who communicates a vision between the team and the stakeholders and helps keep the team focused. This isn’t a lead position defined by a role but by actions.
A core expert: Not everyone on the team needs to be an expert, but on a master team there is often at least one core expert. This person supports the vision with brilliance that the team can rally around with confidence.
Team collaboration: Teams become great organically and evolve together based on chemistry and experience.
Proper studio culture: Studio cultures can either nourish such teams or prevent them from taking root and flourishing. Sometimes great teams will form in a highly dysfunctional culture, but they don’t last.
Great teams form independently of process. However, Scrum assists them based on the mastery of its principles. Team self-organization, Sprint Goal ownership, commitment, and a daily dose of visibility cultivate them.
Team Organization and Membership
Collaboration is a necessary element for master teams. A team of highly skilled developers who cannot collaborate cannot assume success.
Teams need to form carefully and have the ability to adjust their membership to enable them to improve collaboration and chances of success. At first, teams can’t do this on their own. Team formation needs to be facilitated by studio leadership early on by mentoring and encouraging the team to slowly take control and make the best decisions for themselves. Eventually, these teams become self-organizing and make decisions on their own.
Let’s examine how self-organizing teams adjust their membership.
Teams don’t change membership mid-Sprint. They hold off on such changes until after the Sprint Review but before Sprint Planning. There are two reasons for changing members. The first is to match the team to its goals. For example, if a team needs animation support for a coming Sprint but does not have an animator, it needs to have one join the team before it plans the Sprint.
The second reason for changing membership is to improve collaboration and commitment. This involves adding or removing a member to make it easier for the team to work effectively. Removing team members is challenging but sometimes necessary. Often, it’s a simple lack of chemistry or personality conflict. Chapter 20, “Self-Organization and Leadership,” explores this topic further.
At the start of a new release, a master team might substantially change its membership to accomplish a specific release goal. Usually, these teams retain a core of individuals. Building a chemistry of personalities that are effective together is far more difficult and rewarding than simply gathering individuals with the necessary skills. After a working chemistry is found, it should be protected and supported.
Major Practice Change
A characteristic of master teams is its ability to abandon or modify any practice while preserving the underlying values and principles of Agile development. Some master teams have varied their methods so much that what they are doing is barely recognizable as Scrum on the surface.
An example of this is the introduction of Lean practices as described in Chapter 10, “Video Game Project Management.” These practices eliminate Sprint Planning and Sprint Goals for teams creating production assets. These may seem like a gross violation of Scrum rules, but they aren’t. The Scrum principles of empiricism, emergence, timeboxing, prioritization, and self-organization described in Chapter 3, “Scrum,” still hold true.
Master teams make these changes relying on empirical measures, a sense of ownership, freedom, and a deeply embedded understanding of what the Scrum and Agile principles mean.
Experience
I’ve noticed over the past decade that the teams most successful in adopting Agile/Lean change a majority of practices over several years, but still maintain the principles. Teams that maintain the same practices “by the book” see minimal benefit beyond those seen in the apprentice stage.
What Good Looks Like
The benefits of master teams are unmistakable:
They have more creative input that is aligned with the game’s vision.
They are far more productive.
They enjoy working together.
They solve problems rather than expect someone outside the team to solve them.
Chapters 19 and 20 explore how coaches help teams grow and how leadership can spread that culture through an entire studio.
Summary
Every studio that adopts Scrum has a unique experience. The path from apprentice through journeyman to master is different. Some take a few years, others stall.
Additional Reading
Cockburn, A. 2007. Agile Software Development: The Cooperative Game, Second Edition. Boston, MA: Addison-Wesley.
Cohn, M. 2010. Succeeding with Agile. Boston, MA: Addison-Wesley.
Hackman, J. R. 2002. Leading Teams: Setting the Stage for Great Performances. Boston: Harvard Business School Press.