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.

Wednesday, October 18, 2017

Agile game development training course is now free

The "Agile Game Gems" video training course is now available for free.

This 48-minute course is a useful resource to introduce and refresh game developers on the purpose and vocabulary of agile game development.

I will be using this course to prepare students for my training cso we can better hit the ground running on adopting and improving agile. 

Links for the course's reference material are linked to in the video's description.

Tuesday, August 15, 2017

Mobile Game Lesson - Rapidly Responding to Change

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!

Thursday, July 13, 2017

Why a "Scrum for Video Game Development" Course?

What areas does a Scrum for Video Game Development course cover that others don't?

Plenty. Video game development has unique challenges that other industries do not.  For example, death-march-crunches are harder to avoid.  Mainstream app development can manage crunch by managing technical debt and scope.  Video game development has more varieties of debt (art, tech, design, content production) that have to be managed differently. We cannot just cut content production for schedule reasons and ship four hours of single-player gameplay to meet a schedule. This requires a different approach.

We discuss this and many other game-development-unique approaches in my interactive workshops.  I invite you to bring your questions or challenges to discuss. We'll share what many studios have discovered through experimentation and practices that were captured in my more recent book: Gear up! Advanced Game Development Practices.

Typical areas of discussion include:
Come join the next Scrum for Video Game Development course and bring your questions and experience.

Wednesday, June 21, 2017

Sprints or a Kanban?

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.  Anytime someone gives a blanket statement that "one is better than the other" it means they misunderstands both.

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.

Saturday, June 10, 2017

Department Silos Can Kill

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.

Wednesday, June 07, 2017

It's not about open space vs. offices

There's an endless debate about what office configuration is best.  After working with hundreds of teams over the past decade as a coach, I have the answer:

There isn't a best configuration.

The debate should be about how we can improve effectiveness as a team.  We need to communicate quickly, across disciplines and also get into the flow of our work.

Think of a team having a nervous system.  To much noise can be like a convulsion.  To little communication can be like paralysis.

Experiment.  Explore.  Regularly decide as a team how you can improve your effectiveness by tweaking your space.

Saturday, June 03, 2017

Fighter Aircraft and AAA Games

When I worked on fighter aircraft, I witnessed the harm that a lack of communication caused.  The shining example was the F-22, which had contractors in over 30 states working (to spread congressional support) with classified protection in place.  If I wanted to speak with an engineer who wrote the firmware for a board I was working on, there was a week's delay in arranging the call on a scrambled phone line with a security officer present to ensure we spoke about nothing too specific.

That was a joy.  It's no wonder the F-22, which was so late and expensive to build and maintain, was cancelled after a small fraction planned were built.

Fast forward 30 years and I'm working with a publisher on a large franchise game that has six studios and hundreds of developers working on the next iteration.  There are language and time-zone barriers, and most of the studios are organized by discipline silos that have limited communication locally.  Because it's a billion dollar franchise there are armies of project managers pumping out reams of documents that lay out a clockwork plan, defined to the hour level, about how the project will be executed.

It's the same as previous iterations, where the plan eventually fails to execute and a lengthy period of crunch and feature compromise is hit at the end.  Just like the F-22.

Large games and government projects can work.  They require breaking down silos and educating everyone about the entire system, not just their part.  We want to, as General Stanley McChrystal puts it, "fuze generalized awareness with specialized expertise".  We want hundred of people making the right decisions for the whole, rather than relying on just a few.

Agile can help, but too many times we see cross-functional swarming teams formed under rigid hierarchies of management that results in these teams working on their "parts" with a limited "need to know" about what the others are doing.

It takes a much deeper organizational change than with just development.  It's not a development problem alone.

Friday, June 02, 2017

London Agile Game Development Course with Scrum Master Certification

Boost your game team's effectiveness by joining us this July for the first London course by game development veteran and author of Agile Game Development with Scrum.

This two-day course gives participants hands-on experience applying Scrum to video game development.  It puts theory into action through extensive use of exercise and a project simulation. All exercises and discussions are specifically tailored for those working in video game development and for all levels of agile experience.

As an agile game development coach who has been making video games for 25 years, Clint can navigate you past the hype and myth of Scrum and agile and help your teams eliminate waste, crunch and practices that hold them back.

This course will make extensive use of Clint's latest book Gear Up! Advanced Game Development Practices, which contains over 90 proven practices to gear up your team for higher productivity and purpose.

Following completion of the course, attendees will receive a two year membership in the Scrum Alliance and be eligible to take a multiple choice test of their Scrum knowledge to receive their Scrum Master Certification. 

To learn more about this course, please visit the registration site.

Recommendations from past attendees
“Clinton is one of those trainers that has a special knack for sharing his expertise in a way that is clearly understood. The training he gave was clear, concise and actually a fun way of learning. He clearly demonstrated his knowledge of the industry and the frameworks we are working with. I would highly recommend his training to anyone and look forward to acquiring a deeper skill set from his courses in the future.” - Dave Collins

“Clinton is a very dynamic and entertaining instructor that can captivate an audience’s attention.  Having an interesting instructor that can also be funny and do a lot of group activities is essential when having to be in a class for 7 or 8 hours.” - Shirley Stevenson

"Clinton is a very switched on, genuine guy, and I strongly recommend his ScrumMaster Course to anyone who is looking to improve the productivity of their teams with Agile Scrum.” - Kim Sellentin, Blizzard Entertainment

Clinton has a lot of experience with general game development and is a pioneer with implementing Scrum in game development. His stories were not only interesting but served as a great way to show how Scrum is being used in the real world. He has worked with some big studios including CCP (creators of Eve Online) and Bioware. This gives him both credibility and a great insight into how large companies have made successful games using Scrum.  - Alastair Doulin

Monday, May 29, 2017

Scrumming without Agility

I recently encountered a team which was practicing what they called Scrum.  They had two week sprints and met every day. However, their manager pointed out that Scrum was useless to them because they were implementing a graphic architecture, which wouldn't make it into the game for six months.   They "needed to be left alone" for the duration.

It was true that Scrum wasn't helping.  The group of people working on the architecture were all working on independent tasks. They had nothing to talk about throughout the day and didn't commit to a shared sprint goal, so there was little feeling of "team" among them.

As I asked around, I found that those dependent on the graphics architecture felt that this group usually delivered their work late and what was actually delivered wasn't exactly what they'd asked for.  As a result they were impacted through crunch and the game's quality was compromised.

The architectural manager had never heard this.  That was an interesting "tell".

Asking around further, I found that the graphics architectural work was driven by detailed requirements from the artists and designers written at the start of the project.

Now the picture was becoming clear.

When planning starts with high detail, we often create a push system that drives many behaviors throughout a development process.  It can create a vicious cycle:
The vicious planning cycle

Detailed designs lead to detailed specs, resource allocations and task assignments all driven by a comprehensive schedule.  This is usually described as a push system, where work is defined up front and pushed through development.  When something is inevitably late, there's a pileup somewhere which leads to problems.  After the game is shipped, management decides that more detailed planning is needed next time and the cycle gets more vicious.

Agile is a pull system where the work is pulled towards a vision of what we want in the game and what the game is telling us.  We measure what's pulled into the game and adjust our plans based on the pace of that and what the needs of the players and developers are.

Scrum wasn't doing them much good. We needed to look at how it was being used.

The organization of the graphics group looked like this:

  • The manager pushes the vision through a schedule of assigned tasks
  • The manager owns the schedule
  • The team is a group of developers which execute assigned tasks
  • The manager coordinates cross-functional dependencies
  • The manager solves cross-fucntional problems
  • Integration is painful, which leads to its deferral  (which makes it even more painful).
Pulling work into a swarming team

Contrast this with the way a cross-functional Scrum team should work:
  • The team executes based on a shared vision that pulls iteration goals in.
  • Work is planned by the team based on those iteration goals.
  • The team owns the short-term schedule (iteration)
  • The team can address most dependencies and problems themselves
  • The team consists of people who can address each other's problems through swarming
  • The game or architecture has frequent integrations to test the emergent value and address risk.

Moving from Push to Pull
Push systems have been largely discredited even in manufacturing industries, which have far more predictability than game development, but push is still prevalent in many software development companies as well as game development.  There are many cultural reasons it sticks around, such as:
  • Silo'd discipline structures
  • Lack of trust
  • Management by fear
  • The myth of up-front planning
These don't go away overnight with the wave of a wand.  They melt away slowly through the slow application of agility:
  • Breaking large cycles of integration, test and validation (e.g. 6 months in this case) into shorter ones.
  • Iterating against player goals, not architectural goals, as much as possible.
  • Breaking large detailed designs into prioritized outcome-based goals with shorter-term details.
  • Replace documented hand-offs with face-to-face conversations.
There is a slow transformation away from managing for components to managing for player outcomes that doesn't occur overnight, but this transformation can begin immediately and the benefits can be seen every iteration.

Thursday, May 04, 2017

Gear Up! - A Leadership Transformation Story

This is a story about how effective vision for change can be made collaboratively  among leaders.  The practices used are documented in my recently released book (coauthored with Grant Shonkwiler):

Gear Up! Advanced Game Development Practices

By Clinton Keith

I recently visited a studio that had created a new game and was transitioning to live support for it, adding features and content on a regular cadence. They were struggling with establishing roles and process for this transition and although they had strong leadership in place they wanted help coaching the transition.

I spent three days with this remarkable group facilitating practices captured in my new book “Gear Up!”.  The first days consisted of learning about them by speaking with individuals.  As an outside coach, the key is to ask questions that are neutral and result in hearing what is important for them to communicate.  Powerful questions (page 76) provides some useful guidelines for this.  Typical questions asked were:
  • If you could change one thing, what would that be?
  • What things waste your time?
  • What's best about this group?
  • What is a real challenge here for you?
This exposed some divergent and shared opinions about responsibilities, process and where improvements should be made.

On the second day, we convened offsite in a small Remote Meeting Space (page 73).  The first step was to set the stage for the meeting, to establish goals, make a working agreement and air concerns.  Next I asked them to create a Premortem (page 59) that would reveal a set of shared and individual concerns about their game and studio.   These included:

  • A competitor game releasing a similar feature earlier
  • Late changes from the stakeholders
  • Key developers leaving the studio
  • Major quality problems discovered after deployment

They then prioritized those issues by impact and probability using a Risk Matrix (page 63) and began asking the Five Whys (page 94) on the highest priority concerns

Next we took a look at their existing process by creating a flow map using Visualize Your Feature Workflow (page 66).  Since such a flow is rarely mapped graphically, there is often a disconnect among a leads group about how their process works.  As a result, the big benefit of this  exercise was the discussion during mapping.

Following this, we discussed changes to the flow to address two things:

  • How to reduce the time, from concept-to-deployment, of the process flow for new features.
  • What changes might be effective in addressing the root cause failures they identified earlier.

Having created a new process flow map, we discussed roles and responsibilities.  A favorite of mine, similar to a RACI map, is the SRF map (page 70).  A SRF map identified the roles that sign off on, are responsible for or facilitate any activity in the process flow.  Again, the conversation among the leads is the most important part here and the facilitation by a coach can help them converge to agreements about the roles.

The last step was to test the updated process by throwing use case scenarios at it using the Table Challenge (page 28) practice.  These challenges were derived from the premortem and risk assessment practices.

Finally, the team committed with each other to hold retrospectives at a regular cadence and to review their throughput and the SRF map as part of the discussions on improving their product development flow.

As with the other practices in the book, these three days engaged conversation across the entire group creating a shared vision and vocabulary that is essential to implementing lasting and effective change.

Learn more about advanced practices.

Tuesday, May 02, 2017

The Story Behind Gear Up!

Gear Up launched today! years almost to the day since my first book.   What took so long?  Well, cranking out 250 pages of text, illustrations and doing most of the proofreading on my own took years.  I'm proud of the result, but it was a "check off the bucket list item" thing at the time.

This book was different.  First, let's visit its origin.

Developers always ask me “we’re having problems doing X with methodology Y, what should we do?”. My first answer is always “What have you tried?”.  I ask this because the best solutions usually come from the people doing the work and experimenting with new practices, not following so-called “best practices”.

“Best practices” implies there are none better. Practices will always change as do our players, technology and markets. This leads to experimental practices, where teams explore ways of adapting to change and improving how they work together.

Thinking about that original question, I think of all the experiments I’ve seen developing games, training and coaching at over 100 studios over the last decade.  I thought that if we could share these as a reference, it might spark that sense of experimentation with many developers.  Experimentation is key not only to creating great games, but creating great teams.

I had a GDC workshop coming up, so I decided to make it about such practices.

The "Shonk" and I sporting our
Rugby jerseys at GDC
The effort hit gold when I started asking for other developers to tell their stories.  One such developer was Grant Shonkwiler, a producer I’ve known for years who has worked on dozens of titles at some of the more renowned studios.  Grant started pumping in practices and ideas for the collection faster than I could keep up.  As a result, the workshop evolved to be a collaborative exercise in discussing and sharing advanced practices, or experiments as we liked to call them.

While collecting these practices, we established some criteria for what makes a practice “advanced”:
  • Experimental - Expressed as something we are doing to solve a specific problem. If it doesn’t solve it, we stop doing it. Implemented with the idea that it will be eliminated or someday replaced with something better.
  • Incremental - Not so large that we don’t see the benefit, at least in an iteration or release cycle of a few months. They can be validated quickly
  • Flexible – Not too specific so as to be adaptable to differing needs
  • Collaborative - Not imposed. Demonstrates consideration, and respect. 
  • Radiative - Visible. Creates transparency. There is sometimes an electronic solution, but they are only recommended for distributed teams
Following GDC, our little group grew to dozens and our collection grew to book-sized proportions which led us to publishing them.  As with the practices, the book is an experiment.  We expect the collection to continue growing, which is why it’s on LeanPub for now.  First, we’ll inspect what the industry says about our effort and adapt it from there.

This experience was a joy.  It felt like being on a team again, which I have sorely missed.  Maybe the next book won't take seven years!

If you are interested in learning more about the book, please visit

- Clint

Monday, April 17, 2017

Certified Agile Leadership course in San Diego April 25-27

The key to successful agile adoption and growth lies not only with developers, but studio leadership as well. We all know that cross-discipline teams iterating on features creates a benefit, but to achieve the far greater (and rarer) reward of developer engagement and motivated productivity, you need deeper cultural change.  This requires a shift in the mindset of leadership.

The Certified Agile Leadership (CAL) course provides this shift.  It distills the experience and wisdom of decades of experience applying agile successfully and leads to true leadership transformation.  In taking the course, I personally found that not only were my leadership approaches transformed, but it altered how I engaged with family, friends and my own life.

I will be joining the CAL course being taught by my friend and occasional co-trainer Peter Green In San Diego on April 25th through the 27th.  Please join us!

Thursday, January 05, 2017

Advanced Agile Practices Workshop at GDC - Free book

Announcing the “Advanced Agile Game Development Practices” workshop for the 2017 Game Development Conference on Monday February 27th, 2017:
Agile practices are no longer considered experimental, but mainstream, yet many still struggle with them. In this workshop you will learn and share the successful practices and techniques that agile studios have created over the past decade of it's application.
This workshop is intended for game developers, who have used agile practices to share what has worked and what hasn’t with other game developers.

Update: Attendees to this workshop will receive a free copy of the draft of my next book.

Wednesday, January 04, 2017

Game Play-Throughs During the Sprint

Regular team play-throughs of the game can add a lot of value through improved focus on the sprint goal and increased cross-discipline collaboration.

During the sprint, when the game is in a state where progress can be seen by the team, they hold a play-through of the areas related to the sprint goal.  Anyone can take the controls of the game, but usually it’s not the Scrum Master.  
Depending on the state of a feature or mechanic, the developer who is directly working on what is to be played may show it, but it’s preferable to have someone less family drive the play-through.  This shows areas of where the player interface might be confusing.  
During the play-through, anyone on the team can suggest improvements or identify problems to be fixed.
The duration and frequency of play-throughs can vary.  If they are short, they can be done daily but longer ones once or twice a week work too.

Coaching tips

If the team has nothing to show half-way through the sprint, this is a great opportunity to ask them if there is any way to demonstrate progress earlier.  Earlier play-throughs create more opportunity to take advantage of emergence and to avoid late-sprint crunch and compromise.
Additionally, you may want to invite a senior designer or art director to listen in.  This creates the opportunity for feedback (after the play-through) among the disciplines.   Make sure that people outside the team understand that the play-through is not an opportunity to change the sprint goal.
I've always found that play-throughs held just before the daily scrum or at the end of the day are best (for different reasons).  Experiment!