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.


Paul Motion said...

Good article Clinton. Having just moved out of games and getting insights into different software development disciplines, it's interesting to see all that I've taken on board from the games industry can be taken into different areas and software development industries

Clinton Keith said...

Thanks Paul,

Right. I think game development highlights the same issues in other industries because of the greater separation of disciplines and how apparent the problems of such dependencies are.

Best of luck in your new career!


Daryl R Wallace said...

This is extremely well thought out and demonstrates a deep appreciation of the agile dynamics that drive x10 productivity gains. My only addition would be to draw attention to the manager's changing role since you've effectively taken many of responsibilities away, what would you see as the most important things that the manager should be focusing on? The expectations appear to be that agile managers metamorphose into a coach/mentor, team collaboration support and external team representation where needed but mostly vision alignment. Would you agree?

Clinton Keith said...

Hi Daryl,

Thanks for the comments and yes I agree. I left out that part for a couple reasons. First, it deserves a lot of discussion and I ran out of time. Second, the role of manager on a game team can vary widely. For leads, such as one leading an architecture, they do exactly what you listed. For others, such as producers, it's a situational thing. Some producers are simply task herders and have little place among the team with those responsibilities and skill sets. Most others organize dependencies and more content production scheduling, which is still very valuable for an agile team.

Hope that addresses your questions.