Valve's Culture, Self-Organization and Scrum

“If you don’t like change, you’re going to like irrelevance even less.” 

- General Eric Shinseki

Several weeks ago, Valve's New Employee Handbook was posted here.  The handbook's release has led to a number of discussions about the merit of The Cabal (what Valve calls their process) and their work environment.   For me, it's hard to argue with success and everything I've read about Valve being a great place to work.

Since first reading about The Cabal in 1999 and attending a few GDC sessions since, I've been inspired.  That inspiration helped lead me to agile thinking.   I felt there was a connection with agile and the kind of place, like Valve, where I wanted to work.  A place where rigid process and hierarchies were considered a mismatch to creative development.

Valve's handbook states this belief near the start:

Hierarchy is great for maintaining predictability and repeatability. It simplifies planning and makes it easier to control a large group of people from the top down, which is why military organizations rely on it so heavily.


But when you’re an entertainment company that’s spent the last decade going out of its way to recruit the most intelligent, innovative, talented people on Earth, telling them to sit at a desk and do what they’re told obliterates 99 percent of their value. We want innovators, and that means maintaining an environment where they’ll flourish. 


Self-Organization
The handbook goes on to describe the role of an employee in this environment.  The criticisms I've heard about The Cabal often say "you need the right kind of people for this to work".  I agree, but I think that the potential pool of such people is larger if you provide mentoring to help the transition into such an environment.  The handbook acknowledges this as a challenge:

There are a number of things we wish we were better at:

• Helping new people find their way. We wrote this book to help, but as we said above, a book can only go so far. 
• Mentoring people. Not just helping new people figure things out, but proactively helping people to grow in areas where they need help is something we’re organizationally not great at. Peer reviews help, but they can only go so far. 

This is a common challenge in any studio that is attempting to improve self-organization.  People have to unlearn a lifetime pattern first imposed in our public education systems, which train children how to work in a task-driven top-down hierarchical organization.  It's an even greater challenge for a studio that has been hierarchical, since it threatens the status quo (more on this later).

Self-organization and hierarchies aren't mutually exclusive.  Gabe Newell leads Valve; it's not a pure democracy, but Valve doesn't have many layers between him and an artist creating texture maps.  Nor is the artist being handed a list of texture maps he or she is assigned to create during the week.  The artist is expected to be a professional and is treated like an adult by being allowed to be personally accountable.  What self-organization does is to flatten hierarchies and reduce the number of lines of communication between people that need to communicate.

Scrum and The Cabal have the same goals

Scrum is a framework for iterative and incremental product development based around self-organizing teams.  Team size, sprint durations, Scrum roles, etc. are meant to foster self-organization.  Every 2-3 weeks, the team to inspects their work and practices and seeks ways to improve both.  The roles provide for clear interfaces and areas of ownership.  The benefit is that after awhile, every individual should find motivation in seeking these improvements.  This motivation builds on itself, accelerates and leads to a better working environment.  

Good working environments and profitability aren't exclusive.  While Valve enjoys the highest retention rates of almost any company, it also makes more profit per employee than even Google or Apple!

The goal of Scrum adoption is not to "do Scrum perfectly" but to establish a framework that will lead to such a culture.  It's been referred to as a starting script for self-organization.

Why is it so hard then?

So why do few companies ever achieve similar cultures?  Why is it so challenging for organizations that adopt the Scrum framework to become like Valve?  This is the big question.  There are many different explanations and reasons for this I've read from "people mostly suck" (a comment I saw today) to "Scrum sucks".  Both are simplistic and wrong.

I believe it mostly lies in cultural resistance.  As mentioned above, an organization that grows in a hierarchical pattern, resists the adoption of self-organization.  This applies to managers as well, who see their value tied to a command-and-control structure.  Even in the face of studio extinction, these forces resist change.  I once heard the comparison of a manager resisting change in a failing studio to that of the Titanic passenger with the finest cabin refusing to evacuate!

Resistance comes from developers as well, who focus on their tasks and discipline and leave accountability to their bosses.  This feels safe, especially in a culture that hands out blame like candy during Halloween.

Valve had the benefit of being founded with the principle above and maintaining it.  It doesn't hurt that Valve is self-funded and somewhat isolated from external customers.  It also doesn't hurt that they own their I.P.  But this doesn't mean the path to self-organization is impossible to move to from a hierarchical culture.  It's definitely hard and it takes time.

There is a revolution taking place in how we work that may take a generation to become common place.  We have more examples every year that show us how to get there and what the benefits are.

Kanban for Social & Mobile Game Teams, Part 1

Many social game teams (or MMO or mobile game teams) deploy new features once or twice a week.  For them, Scrum is more challenging to adopt because 2-5 day sprints are too short and there are often frequent interruptions to their work.  These impede the team's ability to commit to a valuable sprint goal.

For these teams, kanban is a more suitable approach.  I've used kanban for years (see links below) and have worked with many teams adopting it.  With the growing popularity of social and mobile games and their platforms, kanban has become more established.

Kanban has the following advantages:

• It's easy to deploy.  You start by visualizing your current workflow.  No new roles are needed.
• Deployment of features is continuous, which matches the needs of many live games.
• It helps lead you to many continuous changes through daily inspection.

Here is an example kanban board:

If you've used a Scrum task board, you can quickly understand a kanban board.  The immediate difference you'll notice is that the kanban board has more columns.  This is because it's capturing a more predictable flow of smaller features that live games typically deploy.   For example, let's say we want to add a button which tweets a player's status in the middle of a game (by the way, I'm not a big fan of such features).  The designer specs out the button and it's behavior, it's then implemented, tested and deployed.   While this is happening, a card which represents the "Tweet Status" feature moves from left to right through the workflow.  Kanban doesn't "say" that's the best way of developing such a feature or not; we're just visualizing it. 

The other thing you'll notice is a couple of columns called "done" and the numbers at the top of most columns.  The columns labelled done are little holding buffers that we use to handle the variable amount of time for each step (e.g. some buttons take longer than others to create, so we let a little bit of backup occur so the next developer down the line isn't waiting around).  The numbers, called work-in-progress (WIP) limits, will prevent too many things from piling up.  When too many things get into the flow, there's a point at which development really bogs down (think of a Southern California freeway at rush hour).  WIP limits and a few judiciously placed buffers help things move smoothly and quickly through the flow.

The next article in this series will describe kanban's use, the blending of kanban and Scrum practices and where it makes sense.  We'll look at how to use lean practices to improve flow and handle emergencies.

Some links to previous videos, chapters or articles about kanban.
http://www.gamasutra.com/view/feature/3847/beyond_scrum_lean_and_kanban_for_.php
http://www.youtube.com/watch?v=dH7HipySK0I
http://www.infoq.com/presentations/kanban-video-game-dev
http://tinyurl.com/agdbook (chapter 7)

Answering the right questions

Someone recently asked how programmers and designers might communicate daily impediments if the programmers feel the designers either can't understand their impediments nor contribute to their solution.  

Designers aren't usually going to jump in and suggest a code fix, but if the programmers feel that the impediments are mainly code issues, I sense another potential problem.

The greatest challenge in making games is "finding the fun": exploring mechanics and isolating the core gameplay that will draw players.  This creates daily challenges of "how to get there".  When the primary challenge becomes how to write the best architecture or how to create the most optimized physics, then the focus is on the plan, not the game.

David Jaffe said something during the last IGDA Leader Forum that stuck with me.  He said that when developing Twisted Metal, they didn't create vehicle physics.  They created a player object that acted like a hockey puck and then pasted some vehicle models in.  Their focus was on creating the gameplay and let the player fill in the "fantasy of driving a vehicle".  

Our arcade racing games always suffered from a tug-of-war between the vehicle simulation physics and gameplay.  We should have let gameplay lead the vision.  This doesn't mean that designers have the only important work.  It means that every discipline is focused on delivering core value.  Design asks the questions and the entire team seeks the answer….daily.  Seeking those answers should create frequent, meaningful conversation.  If it doesn't, I suspect the team is answering the wrong questions.

Why we should stop saying "vertical slices"

The other day I came across the this blog post by Ron Gilbert called The Vertical Slice in which he rails  against the creation of vertical slices.  The following quote struck me:

"Vertical slices might work in a medium where you start at the beginning and grind though in a fairly linear fashion and what comes out is 90% complete.  Maybe writing a novel works this way, but making movies and games do not.  They are an iterative processes.  You build foundations and the build up from there."


I love his image of the Mona Lisa's vertical slice.   But Ron is using a different definition of vertical slice than I've always used.  To me a vertical slice means is that we develop a feature to the point of knowing its value and use that knowledge to adjust the plan.  The point being that the plan won't tell you how fun something is: the game will.

Ron's definition is that vertical slices emerge from a plan that defines all the slices up front.  This might be a better approach from an engineering point of view over waterfall (fixing bugs along the way, etc), but  it abandons the benefit of iterating on a plan with a working game.  It doesn't surprise me that he's against that.

So maybe we should stop using this confusing phrase.  Maybe we should call it a "game increment", or something.  I'm open to suggestions.

By-the-way, here is how portraits were iterated on:

Do a Google image search on "unfinished portraits" and you'll see a lot of these, all with the heads nearly completed and little else in the portrait done.  Can you guess why?   It has something to do with prioritizing risk, and stakeholder value....things often spoken about in agile circles centuries after this was painted.

Also, da Vinci iterated on the Mona Lisa as well.

Announcement: Scrum Essentials Tutorial at GDC 2012

I'll be giving a tutorial at GDC 2012 called "Scrum Essentials":

Attendees will learn about the full cycle of Scrum development, its principles and not the hype. They will leave knowing how Scrum works and will be able to begin its introduction at their studio and communicate expectations. They will be able to identify the patterns of successful and unsuccessful Scrum adoption, which Scrum practices should be changed to fit their game development process, and which practices should be preserved to achieve full benefits.


Rather than being a slide-driven lecture, the course will be focused on a combination of lecture, small group exercises and the simulation of Scrum by creating games throughout the day.  You won't leave being experts on the rules and practices of Scrum, but thoroughly exposed to the principles of Scrum and the values of agile.

More on specialization

My recent post on specialization has ignited a bit of argument with people on one side saying that I've "come out against learning" and specialists who didn't like my use of their UI/database specialties as a poor example (if I die in a suspicious UI/database related incident, my post is to blame).

The point of the post was that we should encourage "multi-learning" or more cross-specialization without seeking to homogenize all specialization.  The point of the "anti-specialists" is that a graphics programmer should learn more about physics programming.   There are benefits, personally and professionally, to doing this.  There are common solutions in both and insights that crossing boundaries can create.  I agree.

On the other side, many deep specializations take, as Malcolm Gladwell wrote, over 10,000 hours of practice and an innate skill to achieve mastery.  I use the example of musicians because as a untalented amateur musician, there is no way I am going to become skilled enough to even write 10% of the music that a game needs.  However, having worked side-by-side with them and learned their workflow, I can still help them do their job.  Having learned about mixing and composition a bit, I have widened my world and appreciate game sound tracks a bit more.

We often specialize far too much.  For example, some studios have specialized QA to the point where a programmer just has to hand off barely compiling code and someone else integrates it.  QA should be the more the responsibility of everyone creating the game.   Everyone on the team should care about quality.  It shouldn't be a role.

We should also learn more about every surrounding role, every day.  We each shouldn't be just a specialist cog in a development machine.  We should be "game developers" first and [fill in the blank] specialists second.  How many games have you seen or worked on where its apparent that one area of specialization dominated and ignored the rest of the game?

Scrum prohibits all specializations?

A recent conversation about a team staying together long-term, etc prompted me to ask: "what if the team no longer needs a musician?"  The responses stunned me.  Some insisted that the role "musician" is not part of Scrum and that they are not part of the team.  Everyone should learn to make music, write code, create art, etc.

Now, I understand that Scrum has been applied mainly to software products and that the elimination of "specialties" means that the database programmer, UI programmer and QA engineer should, ideally^[*], be able to perform each other's roles equally.  This is valid.  But the idea that that this extends to separate functions such as music, programming and drawing makes no sense.

In "The New New Product Development Game", the landmark 1986 Harvard Business Review article that first coined the word "Scrum" for product development,  authors Takeuchi and Nonaka observed the benefit of cross-fertilization and multifunctional learning across specializations.  These principles directly apply to mixed teams of artists, musicians, designers and engineers working together to create better solutions than using a "relay race" of handoffs.  E.g. If I share a sprint goal with a musician, I become aware of their workflow and needs.  I can help them solve a technical problem with the audio code and they can make the game sound great.

You can be sure that in my book and courses, I don't teach that functions should homogenize on a team.  There is a role for a musician on a "Scrum team".  It's called a "team member".

^[*] I've added the term "ideally" after posting this the first time.  The reason for this "ideal" overlap of specialization is to promote multi-learning across all specialties.  The goal is to have a shared understanding of each other's roles so that the team can continually improve how they work together but not to homogenize all specialization.