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