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.

Homebrew build status traffic light

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.

Accountability vs. Responsibility

[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?

What makes a good “visionary”?

[Cross-posted from Gamasutra]

There is a lot of talk about the visionary for a game, the person who creates and guide the vision through development.  Who is the visionary and what do they need to do to make their vision come to life?  I’ve been a project manager…not a product visionary, but I’ve worked with great visionaries and poor visionaries.  These are my impressions and questions:

The role of a visionary on a creative project is an essential and demanding one.  Many companies that consistently produce great products owe much of their success to their visionaries;  Apple has Jobs,  Pixar has Lasseter,  Nintendo has Miyamoto, etc.  But visionaries are nothing without talented teams to realize their vision.  Vision needs to be communicated, reinforced, inspected and adapted to the emerging reality of the game.  This is the visionary’s fundamental responsibility to the team.

A visionary must be demanding. They have to:

• Unflinchingly question and test their vision early against the actual game.
• Not allow work-in-progress (partially completed or unproven work) to drag out too long.
• Call out substandard work immediately.
• Ensure that the stakeholders are aware of progress and are able to safely air feedback.
• Own a black turtleneck sweater

Successful visionaries have often been described as demanding, uncompromising, even brutal in their rejection of work that does not fulfill their vision.   Lasseter resets movie projects late in development because the story or character aren’t right, Job's throws tantrums when a design isn’t intuitive and Miyamoto cancels games that don’t "find the fun fast".  These are all examples of strong reactions to an emerging product that doesn’t live up to a vision.  Does this mean that a visionary must be a tyrant? I hope not.   There are as many different styles than there are personalities.  The key, it seems,  is to maintain integrity to a vision and to “course correct” towards the best game. 

Good visionaries should be willing to compromise because no vision is perfect.  Compromise is necessary to refine a game or to react to the unexpected, but compromise seems to go bad when the integrity of the vision is the thing being compromised: when the visionary assumes that some poor-performing part of the game "will be fixed later" or a bad mechanic "will be fun someday"; if the story-line isn't working, if the animation doesn't look right or if the system is sluggish, the visionary must demand correction.  However, when the visionary is afraid to hurt the team's feelings or needs to hit an arbitrary milestone date, then the wrong game is created and the team must eventually face the mad scramble to cobble something together when time runs out and a vision is sacrificed for a ship date.

Things we know:

• Black turtleneck sweaters aren’t enough.
• Methodology can’t automate the role.  Games will never come from an assembly line.
• Vision, alignment, talent and leadership are all necessary elements of any great game and can’t be separated. 

Questions:

• Do visionaries have to be mentors?  Some of the best visionaries work with creators to demonstrate how to best work.  I’ve read about Lasseter sitting down with individual animators to teach them how to animate the eyes of a particular character.  Not all visionaries do this though.
• Do visionaries need a big job title?  It would seem they do in most cases, but it is it absolutely necessary?
• How thin should they be spread?  Can vision be taught?  Pixar production is limited to how many visionaries they have working for them.  Brad Bird couldn’t even take a few days of vacation before he was recalled to head up Ratatouille.  Steve Jobs’ illness has everyone wondering whether Apple will tumble when he leaves.
• How does a studio identify and handle a poor visionary?  It’s easy to promote the wrong person to the visionary role, but hard to remove them.  A bad vision will kill a game or even a studio.  A bad visionary will blame the team and not the vision.