Monday, April 30, 2012

Valve's Culture, Self-Organization and Scrum

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

In the spring of 2012 Valve's New Employee Handbook was leaked.  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. 

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.

Update 1/19/14 - Valve has since posted the handbook on their website and the link above reflects that.