Search

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
  • 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 deferring it (which makes it even more painful).
Pulling work into a swarming team


Contrast this with the way a cross-functional Scrum team works:
  • The team executes based on a shared vision that pulls work.
  • Work is planned by the team
  • The team owns the short term schedule (iteration)
  • The team can address most problems
  • 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) into shorter ones.
  • Iterating against end user goals, not architectural goals, as much as possible.
  • Breaking large detailed designs into 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!

Wow...seven 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
www.AdvancedGamePractices.com



- 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.

Practice
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!