Search

Tuesday, May 07, 2019

The Evolving Role of the Scrum Master

Coaching a newly formed team that isn't familiar with agile can be a full-time job.  As teams grow, discovering ways to improve their performance and self-organize, their need for a coach diminishes. However, this doesn't mean the Scrum Master's job is done. 

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

As teams improve, impediments from the outside become more pronounced and impactful. As a result, the Scrum Master focuses more on coaching the organization outside the team and on the development practices used at every level.

Example Impediment - The Level Production Battle
One example illustrates the focus on development practice improvement and how an organization can resist those improvements.

Our team was working on a side mechanic for a game which required a single level. All other levels were being produced by a level production team, but since we required a unique level, we decided to build it ourselves.

After a few weeks of production, our level artists found that by building the level in the Unreal Editor, rather than the studio standard of using Maya, gave them huge benefits. While Maya is a fantastic tool, it wasn't a good match with the Unreal Engine (at the time). Our level designers were at least twice as fast creating level geometry (including iteration time) than the designers using Maya.

However, the lead artist for the game wasn't happy. They were directing the level designers on our team to return to using Maya. When our designers pushed back, their jobs were even threatened!

We (the SM and I (PO)) took the problem away from the team and to studio management. We used the production metrics and demonstrated that the quality of the level produced using the Unreal Editor was just as good. It wasn't easy to convince everyone, but we did. Eventually the entire studio went over to using the Unreal Editor.

Improving the Studio
Studio culture can often impede improvements.  There are many reasons.  Some examples:
  • Leads can feel their authority or position is threatened by change at the development level.
  • Process is considered written in stone and change is not welcome.
  • Developers don't feel they have permission or the responsibility to suggest change,
  • Executives can override development on a whim and destroy trust.
A Scrum Master, who usually has little authority at this level in the studio, must use their organizational coaching skills to overcome these obstacles.

Gratuitous Pitch
Learning these skills is one of the areas we explore in the Advanced Certified Scrum Master course in June.







Wednesday, April 24, 2019

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

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

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


Overview

After more than a decade of training and coaching game development teams on applying agile to their games, I've assembled an advanced course based on the patterns of success seen in the industry. These successes are largely based on effective coaching and servant leadership skills at the team and organizational levels. This course focuses on building those skills.
 
Through the A-CSM course, you’ll learn to:
  • Guide teams toward a focus on “finding the fun” and aligning on a shared vision of delivering fun effectively.
  • Build on your servant leadership skills to help teams mature and reach higher levels of accountability, ownership and engagement
  • Facilitate better dialogue between the Product Owner, Team members, customers, stakeholders, and executives.
  • Respond confidently when encountering resistance to change, lack of engagement, low motivation, and unavailability of key people.
  • Find way to influence change within your studio’s culture and overcome resistance to process change
  • Understand advance art and technical practices how teams can apply them without being an artist or programmer  yourself
  • Scale Scrum and Agile beyond a single team.
  • Distinguish yourself in the global marketplace. An A-CSM certification helps you stand out among the global Scrum community

Requirements

  • Anyone can attend
  • To receive the A-CSM certification, you must Hold a current CSM with the Scrum Alliance and have 12-months of experience as a Scrum Master (it is not necessary hold a certification during this experience) 

Monday, February 18, 2019

Our Three Stages Towards Improved Sprint Goals

Sprint goals are one of the most widely misunderstood artifacts of Scrum. They are often misused at first. We misused them and went through several stages as we improved how they were created.

Every 2-3 months, we'd establish a set of release goals, often in the form of "epic stories", that established a vision for the release. Doing this led us through three stages of how we created sprint goals:

Stage 1 - break the epic goals down into many development tasks to fill up our product backlog before handing it to the team. This required a lot of "producer-like behavior from the Scrum Masters managing the product and sprint goals.

Stage 2 - Have the teams become more involved in that breakdown. Release plans still had a lot of PBIs that looked like requirements derived from design decisions that were locked in at the start of the release. Sprint goals were still mainly a collection of requirements, but with a better definition of done.

Stage 3 - A shift to having a discussion at the start of each sprint about how we could move one or more of the epic stories forward in the sprint. Design decisions were spread out more evenly throughout the release. Sprint goals were usually a sentence about what the team forecasted could be played in the improved game at the end if the sprint.

An example of how this looks with an epic story:
"As a player, I want to engage in hand-to-hand combat with an enemy player"

Stage 1 - Write a document that described the hand-to-hand combat and break out a designed development order into a large set of sprint-sized PBIs with estimates for each. There wouldn't be much to see until the end of the release. Backlog refinement didn't happen because there was little to see in early sprints, so there was little to reflect against the release plan. Releases always ended with crunch.

Stage 2 - Work out a release plan with the team. There was still a a lot of task-like PBIs split out and design decisions were front loaded. But teams had more to show each sprint and started to hold backlog refinement sessions throughout the release. The end of the release was still a scramble to have hand-to-hand combat shippable.

Stage 3 - Don't create a release plan, but discuss with the team how we could move the hand-to-hand combat forward each sprint. Backlog refinement and sprint planning merged.

Stage 3 scared the devil out of management. It required a bit of trust established by a highly functioning team delivering high quality work at a consistent pace. Also, it was first attempted when we were given three months to do something very risky that should have taken six months, but it demonstrated the following benefits:
  • It focused the team on the player essentials. Sprint one implemented the controls and cameras of combat and not the polished animations. You can have fun and learn a lot with simple blends and placeholder reactions.
  • It reduced risk and cost by exploring the essentials first and postponing design decisions as long as we could responsibly postpone them. Very often design decisions made far in advance are more complex than what is needed and lead to waste. In this case, a high/medium/low hit detection approach was the simplest solution that worked well enough initially, but had the benefit of being tweaked over the remainder of the release.
  • It delivered early. We could have shipped it in two months, but took the extra two sprints to add elements beyond the release goal.
This approach is ideal for high-risk and uncertain work such as exploring new mechanics. As development becomes more certain, the level of planning can rise where the use of story mapping or Kanban becomes useful.  Additionally this can't happen overnight with every team. It requires highly functioning teams.

This wasn't isn't about doing things "right" or "wrong". We're always inspecting and adapting how we make games and must always assume there are things we can improve. As long as teams are doing that, they're on the right path.

Tuesday, January 01, 2019

Creative Motivation and Agility

In 2009, the non-fiction book “Drive” written by Dan Pink was published. The book summarized research demonstrating that creative workers are not motivated so much by financial incentives or other such explicit motivations, but by intrinsic factors.

The three primary intrinsic factors identified are:

  • Autonomy - The urge to direct our own lives 
  • Mastery - The desire to get better at something that matters 
  • Purpose - The yearning to do what we do in service of something larger than ourselves 

We want motivated teams. We want to be on motivated teams. We want to be motivated ourselves, but a studio’s culture and process can often prohibit it.

This is where the agile values and Scrum practices come into play: 

  • Autonomy - The purpose of self-organization is to give the people closest to the work autonomy in taking greater ownership, as the become ready for it, over more and more of their work. At first it might be how they plan and track their Sprint. Later, it’s how the team membership is managed and the practices they use to create an increment of the game. 
  • Mastery - By giving the team the freedom decide “how” they implement a Sprint, they are given permission to explore better ways of working. For example, when our level artists were given the freedom to explore new ways of creating levels, they eventually found methods that reduced level creation time in half. Note: the challenge to doing this wasn’t with them, but with the lead artists who had a problem letting their people do things “their own way”. For some reason they fought to have the less efficient level creation practices restored. 
  • Purpose - By forming teams that are aligned around a feature area of the game, rather than a discipline silo, developers are far better connected to the purpose of their work. It’s easier to understand if what you are doing helps improve the game when your Sprint goal is to demonstrate an enhanced feature or mechanic than to simply accomplish all the assigned tasks in a tracking tool that contributes to something you’ll see in the game a month or so later. 
This all sounds great, but it’s very hard to implement in a culture that doesn’t place a lot of value on intrinsically motivated developers. The signs of this are:

  • Developers are largely seen as “fungible”. E.g all animators are equally weighted on a spreadsheet or tracking tool, where skill and mastery could for little. 
  • The idea that more developers can be added to a team to make the team more effective. 
  • Management exists to define how developers do their work and to find and address the problems that arise. 
  • The purpose of what is being done exists in the design document and if developers want to know the purpose of what they are doing, they simply need to “read the doc”.
  • Etc. Etc. 
Another hard part is that motivation can’t be forced on developers. They have to find it within. The role of leadership is to help create the conditions for intrinsic motivation to flourish. I’ve worked with some developers that have been so beat up and burnt out by bad leadership that they refuse to extend themselves again. They don’t want to be disappointed again (what to do in these cases is the subject of another article).

Game development leaders should always be asking themselves: “how can I help improve upon these intrinsic motivators?” A core part of this practice is improving the feedback loops so that increases in autonomy, mastery and purpose are quickly reinforced and that mistakes are not punished but initiate a conversation to highlight what valuable thing we learned from the experience.

The ultimate joy, as a leader, comes from this cycle being taken over by the team. I’ll leave you with one warning: When your teams start outperforming your expectations, you might get promoted away from them; good leaders get recognized and are given greater roles.