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”.
Godfather II Kiss of Death Scene and Billy Madison - YouTube
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.
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:
Merge the development branches
Fix the merge-caused bugs
Optimize, polish and debug for release quality
Send to QA
QA does their regression tests
If bugs are found, return to step 3
If quality is good, submit
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:
Automated gameplay testing
Blessed build indicators
Form a stability team
Most of theses practices can be found in my latest book Gear Up!
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?”
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.
I’m slightly embarrassed to admit that the mobile game I play the most is Solitaire. Solitaire is a great game to play when you are waiting to board an airplane or when trying to fall asleep in a hotel. I do both of those things quite often.
The first mobile Solitaire game I played had great graphics and some good features. It also did a few things that annoyed me such as having slow animations when “undoing” moves and not having a feature that quickly completed the hand once all cards were exposed (a Solitaire hand is "solved" once all cards are face up),
Then one day, after Apple upgraded iOS, the game just kept crashing on startup. This kept up for a few days. Because I was traveling that week, I was having some serious withdrawals. So I ended up trying a few competitive Solitaire games and finding one that not only worked with the latest iOS, but also had fast undo animations and the autocomplete feature. I ended up buying that game and never going back.
By chance, I ended later ended up working with the studio that made the original game and was able to meet the small team that was supporting it.
It turns out that the team were unaware of how the market perceived this very profitable game of theirs or what the competition was doing. Part of the problem was having a very deep feature development pipeline that didn't respond to change very well.
It was an eye-opening experience that such a simple game could suffer from the problems that larger games could as well. The mobile game market can be very fickle. Crashes, exploits or the emergence of a similar game doing something better can change you market overnight. You need to be able to have some bandwidth set aside to deal with them. Plan on change!
There seems to be some confusion that using Sprints or a Kanban is a competition of sorts with "one being better than the other". Might as well argue whether a hammer is better than a saw.
Sprints are more suitable to complex problems that a cross-discipline team will swarm on to solve. Complex work has "unknown unknowns" that require experimentation and defy planning and estimation. The time-box is a limit of time that is established to touch base with the business side and to replan our next move on a complex mechanic.
A Kanban, a way to visualize a lean flow, is used for complicated work. Complicated work has "known unknowns", like creating levels and characters for a game with established mechanics. The variations are manageable. It is more predictable and uses hand-offs of work through a flow.
Using Sprints to manage complicated work results in batched work and an artificial division through sprint planning and review. It hides discipline inefficiencies and leads to split stores which create no value individually. Imagine the cost of buying a house if every one was a custom concept home built by a guild of craftspeople.
Using a Kanban to manage complex work results in turbulent flow that either creates inefficiencies and a lack of transparency or artificial deadlines to call things "done" when they really aren't. Kanban doesn't handle the back-and-forth of exploration very well. This creates debt and can limit the creative potential of a game. It's why we don't use an assembly line to design a new car.
I often see Kanban used for complex work because there is still an "upfront planning" mindset that thinks a new uncertain game mechanic can be broken down into bite-sized discipline centric steps and pushed though the teams. Sprints are abandoned because the developers cannot be trusted to take larger goals and break down the work as they see fit.
Choose the best tool for the work. Wielding a hammer with great skill to cut long pieces of wood into smaller ones isn't as useful as using a saw.
In 2002, GM engineers discovered that the ignition switches on some low-cost cars had understrength springs. As a result, a heavy keychain or knee-bump could switch the ignition for those cars off.
It was considered a rare occurrence and not exceptionally dangerous.
Before the defected part was recalled in 2014, it was blamed for over 120 deaths. Many of those who had died were young; parents had bought the low-cost cars for their children, considering them safe.
The systemic reason for GM ignoring the severity of the problem was that the engineers who designed the ignition switch were not familiar with how the ignition switch impacted other components of the vehicle. They weren't aware that switching off the ignition disabled the power steering and airbag deployment circuits. Disabling power steering and airbag deployment was a deadly combination.
Unintended component interaction is why I discourage the creation of most component teams. Graphics teams, physics teams, audio teams, etc. all sound efficient and they are efficient in creating graphics, physics and audio systems, but the cost of late integration and the emergent systemic problems is too great. Players want games, not components, but at least our mistakes don't kill them.