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.