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.

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.

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.

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?

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.

Have you ever used build light indicator  (a light, software utility or sound emitter) to inform the team about the current status of the build?  Our team found using one of these, in conjunction with continuous integration and automated testing,  to be a great help towards achieving 98% build stability.  I have a little hobby/side-project going to build a better one starting with a $30 toy traffic light (see picture) and embedding some Arduino electronics that will allow it to be easily setup and used.

What the lights mean:

• Green means the build is working
• Red means that it is broken
• Yellow means whatever you want.  The server is building or a test has failed, but we're giving you X minutes to fix it before the status goes to red.

I'll open source the hardware and software.  I might even sell a few at cost while I'm having fun making them.
Currently, the interface is an ethernet connection that uses DNS & DHCP to plug into your current network with little setup required.  The traffic light will appear as a server that accepts simple commands that change its state.  An optional audio cue will sound indicating a status change.

Potential future features:

• Data logging the events and overall build stability metrics
• Server page statistics (graph of stability, etc).
• Simple display for setup options.

Please send suggestions about what you'd like such device like this to do and how you would like to interface it to your build server software.

[Cross-posted from Gamasutra]



I read this great quote from Gabe Newell in this Gamasutra article:
“Yeah, nobody can ever say "that's not my job." Nobody ever gets to let themselves off the hook. If there's a problem, you've gotta fix it.”

It demonstrates a high level of accountability at Valve, not just responsibility. The words accountability and responsibility are used interchangeably, but they don’t mean the same thing and the difference is important for game development teams.

Responsibility is assignable and forward looking.  For example, as an artist, I might be responsible for creating a model.  As a programmer, I might be responsible for making the character jump.

Accountability is backward looking.  Both the artist and programmer should be accountable for the character correctly jumping over the model.  Unfortunately, a lack of accountability might lead both to ignore the problem as “not their responsibility”.

Accountability isn’t as easily assignable as responsibility.  It’s more intrinsic.

Focusing exclusively on the assignment of responsibility tends to tell developers that those making the assignments will take care of all the cracks that will happen between areas of responsibility.  A balanced approached of delivering a part of a game and being accountable for its fun of it is harder.

The hard part is how is to grow accountability in a studio culture.  How do you grow it in yours?