Search

Wednesday, November 06, 2019

Sprint Commitment?

I recently finished the first draft of the new edition of "Agile Game Development." One of my reviewers commented that I still use the phrase "Sprint Commitment" after its removal from the Scrum Guide, but I left it in there.

One of the reasons that the phrase is no longer in the Sprint Guide is because it has often been weaponized to force teams to complete everything they'd estimated in Sprint Planning regardless of what problems emerge during the Sprint. This has resulted in teams compromising quality to get every feature in the game "done" by the end of the Sprint.

The Sprint Guide now uses the word "forecast" instead of commitment for Sprints, even though "commitment" is still a core value. I agree that forecast is an accurate way to express what the plan is, but I think we've lost something by dumping the word commitment.

It comes down to what we mean by commitment. Often forecast means "we'll get done what we get done," or better yet, "we'll do our best to get everything done, but we might have to drop some less important features." To me, commitment goes a step beyond that, but not so far to mean "we must do everything."

Commitment means doing our best to achieve a goal, but also being accountable as a team, when things don't go according to plan.

A good example is when you commit to picking up your child at daycare. You'll obviously do your best to be there on time, but sometimes things go wrong. Let's say your car breaks down a few miles away from daycare. Do you just say, "oh well, I tried my best"? No! You call your spouse, friend, and/or the daycare to let them know. You do this because you hold yourself accountable to pick your child up.

Similarly, if a team runs into problems with a feature in their Sprint goal, they need to hold themselves accountable. They need to raise the issue. They grab the Product Owner and discuss ways to address it. If they can't solve the problem themselves, they recruit the Scrum Master to help out. It still might mean the feature gets dropped, but the accountability results in risk being managed better.

Commitment is a core value for Scrum Masters to grow with a team. Sometimes the first step is to stop solving problems for the team and start asking them, "what should you do about it?"

Sunday, June 23, 2019

The Death of Projects

Game development used to all be "project-based" . Projects have discrete beginnings and endings  aimed at developing a game which was then released, completely debugged on a cartridge or disc. Following this, a team would then move on to another project. As a developers, I always felt a bit of sadness at shipping a game I'd worked on for many months and starting fresh from scratch on a new one.

With the spread of the internet in the 90's, PC games had the advantage of allowing upgrades and expansions after a release and a few developers stayed with a game for its entire life. Some popular MMOs have support crews fixing bugs or making sure the game keeps up with the latest OS changes many years after their initial release. Digital distribution platforms such as Steam have built upon the PC's strength of connectivity and openness to allow many developers access to popular online marketplaces with incrementally released games.

As consoles gained internet connectivity and local storage, we started seeing a similar adoption. Often, it wasn't a good thing for players. Day one patches became a way for game developers to push off bug fixes and optimizations. This forced players to wait hours for updates to be downloaded before they could play a stable and polished version of the game.

Mobile games have pioneered the live game model and open marketplaces by offering cheap or even free versions of their games, which are monetized through advertising or by selling add-ons which enhance the value of the game, etc. Console and PC games have been slower to catch-up with this model, but as players are becoming accustomed to the expectation of continual growth of their games, it seems the market is changing to adapt to it.

As games and teams transition to live models, the term "project" has less meaning. Schedules, budgets and feature specifications become more fluid based on the day-to-day key performance metrics rather than fixed up-front profit and cost projections (aka guesses) from a marketing group. Rather than the approach of stuffing every conceivable feature into a single release and hoping that some of those features will drive sales, many AAA game developers are approaching a "Games as a Service" (GAAS) model of releasing a Minimally Playable Game (MPG - a variation of the Minimally Viable Product approach) and keeping teams together to release add-on features based on how the market reacts.

The project approach may be coming to an end.

Friday, June 07, 2019

Sprint planning and estimation are not the same thing

I run 10-minute sprint simulations in my classes and notice something consistent. When left to their own devices, teams will plan out the sprint but not estimate much.

For a while, that bothered me.  Weren't they listening in the class?  Then it occurred to me: when I work on my own projects, I plan out what I hope to accomplish, but I don't estimate much either.

OK, so I don't have a deadline or contract with my own work and neither do my course attendees.  Maybe that's the difference.

But then again, we're talking about sprints, which are time-boxed. We know when they end.  We also know a sprint's input, the sprint goal, and the output, which are the new features added to an improved game. We typically forecast the future progress of the game by measuring the average output per sprint and multiplying it by the number of sprints remaining.

Planning a sprint is usually a discussion of what a feature needs to do and the work needed to implement it. This is often followed by creating tasks such as "model the character"or "rig the model", etc. This is a useful discussion which reveals questions with the goal and generates discussion.

In addition, teams will put often estimates on those tasks, usually in time. There are a number of typical reasons for this:

  1. It can further discussion by revealing misunderstandings about the effort and complexity of a task and help refine the goal. Many times I've heard large numbers being thrown out which revealed a misunderstanding of the existing tools or tech or a shortage of a certain discipline's capacity.
  2. Estimates are used to create a forecast of the work the team will commit to achieving with the Product Owner.
  3. Estimates are used to track team progress throughout the sprint.
I see the value in #1, but often see #2 and #3 being misused. This reflects back to the Scrum values of commitment and respect:
  • Commitment: This doesn't mean the team commits to a fixed amount of work. Work is often unpredictable and iterative. When we aim for a fixed amount of work every time, we often have to compromise quality to get there. Commitment is more about doing our best work to achieve a goal, but also committing to doing it with quality.
  • Respect: You can't respect those you don't trust.  Too many times I see teams being tracked using their own estimates and being punished if those estimates are incorrect. All this leads to is padding, disengagement, debt and compromised quality.
Try this
If you truly want to measure progress, measure just the output of the team. Let the team decide how to plan and at what level to estimate. It can take some courage, like when I finally had to hand over the car keys to my son for the first time. But as with him, I had to make sure he was first ready. That's my job as a dad. Similarly the job of coaches and leaders is prepare their teams for higher levels of maturity and self-organization.

Sure, some teams might not work well together and their output will show it. It's far better to coach teams on creating better value than creating better estimates.



Saturday, June 01, 2019

Reversing the Vicious Cycle of Excessive Up-Front Game Planning and Design

This causal loop should be familiar to most game developers.


It's a vicious cycle because it builds upon itself, resulting in a negative feedback loop that adds crunch and increasingly impacts the schedule, cost and quality of a game.

Creating a positive feedback loop, or virtuous cycle, which reinforces practices that build towards improved schedule, cost and quality without requiring heroics, is a major reason for having a value and risk-mitigation ordered backlog and a definition of done that teams deliver on every iteration.


The obvious challenge is that you can't just start by asking your stakeholders to establish a relationship and contract built on trust. That has to be built. An even greater challenge is the internal studio challenge of operating with transparency and with a focus on outcome, rather than discipline output.

This is a core aspect of what a Scrum Master or Agile Coach does and is a major topic in the Advanced Certified Scrum Master for Video Games Workshop in June.






15 Years of Agility

It was July 2004 and I was at my wit's end.

Two years previously I'd joined a startup game studio, called Sammy Studios. We were owned by a Japanese Pachinko game manufacturer called Sammy Corporation, which wanted to become a major western game publisher. They'd invested tens of millions of dollars in our startup and we were growing quickly...too quickly in fact and we were a chaotic mess.

I was just promoted to CTO. It was one of those promotions that have a clear underlying understanding that "you are being promoted to fix this mess or suffer the same consequences as your predecessor".

Desperation is a strong motivator. I'd run a studio before, but it was one that was far more stable. I started reading everything I could on the latest ideas in management. One called "Agile and Iterative Development: A Manager's Guide" by Craig Larman led me to "Agile Project Management with Scrum" by Ken Schwaber and Mike Beedle.

Scrum seemed like it might be a good fit for us, so I attended a Scrum Master course hosted by Ken Schwaber. The course was illuminating. It created a mind shift about not only how to make games, but how to coach an organization to better serve its more valuable assets: its people. It created a vision.

However, having a vision is not the same as implementing it.  Not by a long sho t. It turned out that standing in a circle for 15 minutes a day didn't transform us into an effective organization.  Quite the opposite, it created some negative reactions.


Even while we were adopting Scrum, we were mocking it.

But we persisted. We made many mistakes, but we adapted. We started to see the benefits of Scrum. They weren't what we'd expected: no miracles, but we did start to see teams managing more of their day-to-day work and starting to take more ownership over solving problems rather than leaving it to management.

However, after several years, Sammy Corporation decided to acquire Sega who wanted nothing to do with us. We acquired ourselves from them and renamed ourselves High Moon Studios.

A year later we sold the studio to Vivendi. They needed to spend a lot of their World of Warcraft money and we were happy to take it. Vivendi appreciated the benefits we were seeing with Scrum and started sending me to their other studios to talk about it. I also started to talk Scrum at the Game Developer's Conference.

Then Activision and Vivendi merged. During this time we were visited by the Activision scouting party that led the way for an executive review of the studio. Activision was mainly interested in Blizzard and looked at the other studios as baggage to discard if they couldn't help on their existing titles. During the scouting we were told to remove all evidence of agile from our walls if we hoped to survive the review. This and my experience visiting other studios convinced me it was time to move on. So in March 2008, I became an independent agile trainer.

Decades of office work did not prepare me for the life of a traveling trainer. The repetitive and predictable nature of my life disappeared, to be replaced with a life filled with airline chaos, packing and unpacking and entering studios where I knew almost no one.

Although I missed working on a game and seeing the same friends every day of the week, the experience of glimpsing the life of an average of 15 studios a year over the past dozen years has been illuminating. We're all much more alike than I would have guessed. We share many common problems. We all want to have purpose and release great games and enjoy making them.

The Golden Years and the Backlash

Scrum enjoyed (and suffered through) a period of time where it attained a fad status. Studios were embracing it as a miracle solution to their problems, much as we did. It wasn't hard to get work training game developers.

However, like us, studios realized that getting agile to work was hard. It required a cultural shift, which is never easy. Some main causes were:
  • Modifying the practices to fit a command and control culture. Scrum "managers" were assigning sprint work in tools and weaponizing various aspects of Scrum to micro-manage teams. 
  • Following the defined practices of Scrum without question and never modifying them based on  what the game and teams are "telling" you.
Many blamed Scrum for their failure to see success applying Scrum.  Just as Scrum is too simple to credit with success, it's also too simple to blame with failure.

One of my first experiences as a trainer was visiting a large studio in Montreal that was adopting Scrum. I was introduced to a junior producer who said: "we're staffing up from 20 to 200 in the next month to get a game out the door in 18 months. This game will run on an engine which has yet to ship a game."  "But", he added with enthusiasm, "we're going to be using Scrum!".

Back then, I found it difficult to say "Implemented correctly, Scrum will likely tell you very quickly that you won't be able to achieve that goal" because I knew I wouldn't be invited back, and I wasn't. Sadly, they struggled for 18 months, struggling to hide all the transparency that could have saved them the pain until the game was canceled. As expected, Scrum was blamed.

The gold rush of agile also produced a lot of brands of agile that went to war with one another.  Differing brands of agile, which diverged only in minor ways would accuse one another of being complete failures and that their brand was the perfect approach.

This seems absurd to me.
  • I've seen many different methodologies result in great games.
  • Unless the wheel of history has come to a complete halt, we'll keep improving how we make games and eventually look back on our methodologies we use today as outdated.
  • The very first value of agile is "individuals and interactions over processes and tools". This includes agile processes and tools as well. People are the main ingredient, not what brand of methodology you use.
More Pragmatism

Since I became an independent trainer in 2008, the industry has seen tremendous change.  Mobile, for example, has grown to dominate the industry. Mobile game development now spends most of its effort in live support. The player feedback loop has gone from years to weeks. This is fertile ground for agility. Feedback loops of weeks allow far more experimentation and transparency than a two year console cycle where your game has one change (maybe two with a day one patch) to capture market share.

AAA development practices are starting to look like mobile game practices: viewing games as an ongoing service and focusing more on adding post-launch value.

With more experience using a pragmatic approach to agile, we have far more success stories and a greater abundance of beneficial practices and approaches to apply agile to game development.

The pragmatic approach includes:
  • Adopting an agile mindset for all disciplines
  • Continually experimenting with improved practices
  • An executive-level understanding of how to work with agile development teams
  • Not getting stuck on following practices by-the-book
Going Forward

My job as a trainer and coach is much more interesting these days. Rather than giving the same beginner course over and over, I work with studios and teams that understand the basics and the principles up front so can focus more effort on addressing the specific needs of the studio.

But we still have a long way to go. 
  • Leveraging creativity and engagement through increased self-organization, trust and respect for developers
  • Relying more on the emergence of a game and a focus on iteration outcomes rather than a detailed schedule that drives output. 
  • Focusing on outcomes and managing debt to manage ship dates more reliably.
  • Improving practices to move quality upstream in the development chain.
I look forward to the next ten years. Change is accelerating and agility is still the best approach to staying on top of it.









Monday, May 27, 2019

Impact Mapping for Games

Advanced Scrum Master for Video Game Development Course, June 17-18 Denver Colorado

While working on a game, have you ever asked:
"Why are we making the player do this?  Why am I working on this feature? Why did we waste time modeling this section of a level in detail when the player doesn’t see it?"

Knowing the reasons for why we are working on something has tremendous benefits of engaging with our work and being able to contribute more creatively.

Impact mapping is a useful technique for doing this. It leverages the creative input of everyone on the team in finding the best way to achieve a goal as opposed to having a few people document a set of requirements that don't communicate that. It's also a good starting point to generate a product backlog and release plan.

The book "Impact Mapping: Making a big impact with software products and projects" is an excellent introduction to impact mapping, but it doesn't apply directly to video game development. However with a few variations, it can be very useful.

Impact Mapping for Game Development
An Impact Map asks questions
Impact mapping starts with identifying a goal for the game or a feature and then deriving purpose, incentives and finally implementation details to achieve the goal by answering the questions asked. The goal will be expressed, like a user story, as something that benefits the player in the game. This is the root of the impact map. Let's take a look at the questions the impact map raises by using PlayerUnknown BattleGround (PUBG) as a simple example:
  • Goal? This is the goal of the game or feature.  For example, the goal of PUBG is to win the game.
  • How? One or more ways the game's mechanics will serve the goal. For example, in PUBG you win the game by being the last player alive on the island. Note: other games might have multiple ways of winning the game...there can be more ways than one to achieve a goal.
  • Why? This level will list the incentive for the "how" mechanics. For PUBG, you become the last player alive by eliminating other characters and avoiding elimination yourself.
  • What? What dives into the specific features that will be worked on to implement "Why?".  For PUBG, this will include weaponry, combat, inventory, using sound, etc.
An Example of the Benefit
A frequent example I use in illustrating the benefits of including the team in understanding the purpose and reasons for a feature was from an experience with a racing mechanic team. When initially handed a set of requirements, such as complex police chase AI, it was clear that the team didn't have enough time to implement everything asked for.  So instead, we explored at the reasons behind requirements. 

The reason for police chasing the player was to incentive them to drive fast, which required the player to develop improved driving skills. When this was understood to be the purpose (rather than simply implementing the initial requirements handed to them), the developers found ways of implementing police that:

  1. Saved months of effort
  2. Focused on the player's driving skill, more than simply navigation
  3. Likely produced better results
This approach is a variation of the YAGNI principle ("You Ain't Gonna Need It"). By focusing on the outcome, you often end up minimizing the work to get there.  Think about the sets that they build for western movies.  Since old west towns aren't around anymore, they need to recreate them.  However, they don't create the entire town, but merely recreate by focusing on what the camera will see. This saves a lot of money and time.

Give it a try.  It can take less than an hour at the start of a release cycle and save you weeks of wasted effort.

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)