Search

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.

Sunday, December 30, 2018

Improving Live Game Feature Flow

A studio I visited had a live mobile poker game that had been very successful. Money from in-game purchases of poker chips had been pouring in for years, but the competition had been heating up and revenues were slowly falling. The root cause of the problem was the success of the game. The might sound strange, but a successful game often hides problems. It’s human nature to tell yourself not to change anything when things are going well. Ironically, that’s the time when you should explore improvements: you make better decisions when it’s not an emergency.

The other reason success is so dangerous is that it leads us to splurge. For example, it’s easier to staff up by 50% when you’re making a lot of money. But all those new hires need something to do and often that extra work can slow things down. This was the main problem for the poker game. They had 160 people on the team and it was taking six months to implement major new features.

The six-month development cycle created problems:
  • Taking that long to determine if a major new feature will be successful in the market is a very expensive gamble. 
  • The competition that has shorter development cycles can beat you to market. 
Although the team was using Scrum to implement features, there was a lot of waste outside of Sprints that had to be eliminated (and a few challenges for the Scrum teams as well).

The first thing to do was to map the flow that an idea for a new feature went from concept to player delivery. Doing this exposed the following:
  • New feature ideas were huge. They were captured in 20-30 page documents. 
  • Because features were so large, they went through numerous revisions and reviews which took one to two months. 
  • It was easier to shoot down a revision because of the risk and cost of the feature than to approve it. 
  • It took time to gather all the principles for a review (at best twice a month). 
  • The Sprints were not addressing debt as well as they could have, which resulted in a lot of rework in subsequent sprints after a QA team found problems trying to validate builds for submission.
To address this, we implemented two main changes. One hard, one harder:

The hard change: Improving the “definition of done” with the Scrum teams to address debt. This required some automated testing, QA joining the teams and improved practices such as Test Driven Development. This was hard because it was taking for developers to change how they work and for teams to reorganize a bit. However, the benefits were easy explain, which made the coaching easier.

The harder change: Weaning management off of their need to make big gambles with major features, which led to the big design documents. The new approach was to create smaller experiments that could be tested with players and could inform product ownership enough to evolve better features.

An example of this would be a tournament feature for a single-player puzzle game. The original approach would be to design the entire tournament, with ladders and player ranking systems. This could take months and be subject to many design discussions before even the first UI element is created. The new experimental approach was to introduce a simple head-to-head mechanic where the game could experiment with how players could use the puzzle game in a competitive way. This greatly reduces risk as well, because a tournament that took months to develop would likely be a failure if the core of tournament play—the head-to-head mode—wasn’t fun.

This change in design culture took a while to optimize, but seeing the metrics of the flow improve became a motivational token for the leads and they embraced being part of the solution.

Ultimately, the business metrics saw a benefit from this new approach. The throughput of new features (albeit smaller, incremental features) increased from one every three to six months to every four to six weeks. Revenues started increasing. A side-effect of these smaller features was that the team could be smaller. Most of the team moved to other games and the poker team size was reduced to about 60 people.

Tuesday, February 13, 2018

Life Threatening Production Risk


I’ve been legitimately threatened with death by publishers twice in my career. These weren’t your run-of-the-mill “I’m going to kill you if you miss your milestone date” threats that publisher producers often make. These were Michael Corleone style kiss of death promises from publisher CEOs who probably “know who to call”.

I obviously avoided death but I also learned a few valuable project management lessons.

Many games face a set of constraints:
1. Hard deadlines set by stakeholders
2. A minimum amount of gameplay content that must be produced
3. Only so many people on staff that can build this content

The combination of these constraints isn't ideal, but an agile approach is best for tackling them. These are risks and the definition of a risk is that we don’t fully know the answer up front. The key is to not create a detailed plan that fully answers these unknowns but to execute to solve these risks as early as possible.

The First Lesson Learned
One of these games my life was threatened over was a console launch title. The initial plan was to ship with six cities. Since launch dates are fixed, we considered the production of those cities as the primary risk. So we prioritized creating a prototype city which came as close to “shippable quality” first. The goal was to understand how much it would cost to make cities and a game with at least 20 hours of gameplay.

This experiment told us we couldn’t build six good cities by launch.  We believed we could build three at best.

We were still a year away from the launch, but I still had great fear when I called our publisher to inform them that we couldn’t ship six cities with quality, that could only ship with three “good cities”.  To my surprise, they weren’t upset.  They just wanted assurance that we could still have 20 hours of gameplay.

This was the first lesson:bad news delivered early is not so bad. Not only was it easier for the publisher to absorb, but knowing we had to fit 20 hours of gameplay into three cities guided our designers towards creating more options for gameplay in each city: more shortcuts, more branches, etc. The publisher wasn’t fixated on six cities. Many times these numbers are guesses made early that somehow become written in stone later.

The Second Lesson Learned
Although our first prototype city taught us a lot, it wasn’t enough.  Six months later we had another choice:  we could ship three “crappy” cities or two good ones. Production costs and the difficulty of the actual console hardware became greater than we had assumed, even with a prototype city.  Once again, I had to make the call to publisher, this time a bit less fearful due to the experience from the last such call.

This time the reaction was violently worse.  We were mere months away from shipping.  The publisher had announced to the world that we were shipping with three cities.  They had also gone so far as to film scenes in these cities at great expense. For example, they had paid New York City to shut down Times Square in the middle of the night to film a scene for marketing. To say they were extremely upset is an understatement.  I briefly considered an escape across the nearby Mexican border.

We survived the threat and ultimately shipped a launch title that despite suffering quality impacts from stuffing 10 hours of gameplay into each of those remaining cities, was a hit.

That second lesson can be summed up as “bad news delivered late is less welcomed”.

Summary of What I Learned

  • Execute uncertainty away.  Don’t rely on the written plan solving risk. Building cities early revealed more truth than any design document could have.
  • Keep your options open. Decisions made later are often more informed.  Just don’t make them too late. By keeping the number of cities flexible, we could better balance quality and cost, but the late decision to cut the extra city was very costly.
  • Don’t confuse scope with quality. While six cities “sounds better” on paper than two, it came down to what you did as a player in the cities we shipped. I have no doubt that if we kept production fixed on six cities, the game quality and sales would have greatly suffered.
  • Death threats can be very motivating, but I don't recommend them.


Sunday, January 14, 2018

Continuous Delivery of Games

The traditional overhead of "getting a game ready to release" can take quite a bit of time and reduce how quickly you can release new features to your players and respond to what the market is telling you.

Take, for example, the steps a mobile game development team I recently visited goes through for a release every few months:

  1. Merge the development branches
  2. Fix the merge-caused bugs
  3. Optimize, polish and debug for release quality
  4. Send to QA
  5. QA does their regression tests
  6. If bugs are found, return to step 3
  7. If quality is good, submit
  8. If the submission is rejected, return to step 3 to fix it
This took a lot of time! As a result, the team could only release major features several times a year, often behind those of their competitors who captured many of their impatient players.


Continuous delivery is a series of practices that ensures your code and assets can be rapidly and safely released to players by delivering every change to a production-like environment and ensuring that the game functions as expected through painstaking automated testing.

As more games move to more continuous delivery, tools and practices for supporting the ability to deploy with less hassle become more valuable.  Examples are:

  • Feature toggles
  • Continuous integration
  • Unit testing
  • Automated gameplay testing
  • Blessed build indicators
  • Form a stability team
  • Integrate QA
  • Etc
Most of theses practices can be found in my latest book Gear Up!


Thursday, December 14, 2017

The Challenges of Using Story Points for Games

Story Points - The Challenges
Many game teams have used story points to measure items in the their product backlog.  There has been a lot of confusion, misuse and overuse of them.

Let’s look at some of these challenges

Using points for stories that multiple disciplines work on
Story points are meant to drive cross-functional behavior and to focus the cross-functional team on delivering increasing levels of value (velocity).  This is done by encouraging discussions about improving collaboration.

For example, if QA is a bottleneck, then the discussion turns to questions such as:
  • “How can we create functionality that doesn’t require so much QA effort?”
  • “What can the rest of the team do to alleviate this bottleneck?”
  • Etc.
Cross-functional story points are meant for complex work that is a bit unpredictable, such as developing a new mechanic or character behavior.  Teams swarm on complex work, iterating and fixing things daily.  It’s should be a true cross-discipline effort

If the work is more predictable, such as content production, then we can use functional-oriented points, or directly using time estimates with Kanban tools.  With such work, there is a flow of handoffs and we can level that flow by measuring each step (however we’re still trying to optimize the delivery of value for the entire flow, not individual steps).

Thinking story points are precise
Story points are meant to be a fast and efficient way to continually estimate and reestimate the cost of features (stories).  This helps us prioritize them and to foster conversations that don’t take up enormous amounts of time.

There is a prevalent myth that the bigger our plan, the more accurate it is.  In reality, it’s the opposite.  The better plan is the one that is frequently revisited as we learn more.  A hundred one-hour planning sessions held over two years produces better results than 100 hours of planning done up front.  Story points allow such frequent planning by being brief and focused.  An hour or two of backlog refinement every sprint is usually enough.

Translating story points to time estimates
Story points are often directly converted to time estimates.  There are a few problems with doing this:
  • Time estimates depend on who is doing which part of the story.  Any two developers can have a magnitude of difference in the amount of time it takes to complete something based on skill, experience and other factors.  Cross-functional stories don’t provide this information.
  • As rough, relative measurements, story points are not precise enough to convert to time.  This is a reason that we plan using time for a limited horizon, such as a sprint’s duration.  A story that takes 5 minutes to assign points to might take an hour to task out in sprint planning.
So what good are story points?
Story points exchange the illusion of detailed up-front planning (big documents, detailed schedules) with more frequent and brief planning sessions based on the emergent knowledge we gain over the course of developing a game.  We learn the true cost of making something fun based on execution, not documentation.

By continually updating a forecast based not just on promises made at the start of the game, but based on what reality is telling us during development allows us to better manage the outcomes.  Agile planning is better at hitting fixed dates with quality than any other approach.

The big challenge is adopting the mindset to use them correctly.  Too often our stakeholders are not aware of the power of such tools and want specific answers up front.  That’s the biggest challenge.