Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 20, 2014
arrowPress Releases
October 20, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Feature Boards
by Clinton Keith on 04/07/14 05:50:00 pm   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

A challenge in agile game development is managing cross-discipline teamwork where a wide range of skills is required.  As a result, following some practices and artifacts by-the-book doesn’t work as well as it does for software-only teams.  One of these artifacts is the task board.  These boards are used for teamwork transparency during an iteration and are a tool for the team to manage their day-to-day progress.  However, for a highly diverse game team, task boards are often modified.  This article is about one such modification, called a “Feature Board”.

Task Boards


A strength of the physical task board is that the team owns it.  A physical task board is always visible and requires no licenses and little training to use.  The only limitations are that it requires wall space and team collocation.  The photo above demonstrates some example modifications made by the team using it, such as adding columns for verification or colored cards for tracking different types of work (e.g. emergent work, bugs or impediments).

A problem that boards like this encounter is the lack of visibility of cross-discipline dependencies.  For example, let’s say a team is working on a number of player mechanics in an iteration, such as jumping, crawling and ducking.  There are three programmers and one animator among the team.  Halfway through the iteration, the programmers have the code working, but can’t fully test it because the animator is backed up with too much work.  Perhaps the animator is trying to work on all three mechanics at once or the task of animating one mechanic is harder than they thought, or there is a problem exporting the animations.  Creating awareness of these problems is one of the functions of the daily stand-up meeting and a mature team will address them, but sometimes a problem like this doesn’t surface until it’s too late in the iteration to do anything about it.  This is one instance where a Feature Board can help.

What is a Feature Board?

A simple Feature Board looks like this:


Instead of tracking tasks, a Feature Board visualizes feature development state.  The iteration (or Sprint) goal is on the left side and contains cards identifying features the team committed to implementing over the next 2-3 weeks.  The cards move around the board (not just left to right) during the iteration, depending on the work that is being done.  Each column on the board indicates the type of work being done on the feature at the moment.  The rows show which features are in progress and which features are waiting for work to be done.  As features are completed, they exit to the right of the board into the “done” column.  In this particular example, the features are prioritized in value.  Red features are the most important.  Green features are the least important and yellow are in-between.

How is a Feature Board used?

A Feature Board serves the team.  It shows them the state of each feature on a daily basis and leads to conversations that are necessary for a cross-discipline game team.

Take a look at the board above.  The board is telling us that the jump feature is having some coding done, while melee is getting some animation.  There are a few bug fixes that need to be done and one of them is being worked on by both a designer and programmer.
The board also raises questions.  For example:

  • Are the testers overwhelmed?  It looks like they have test work piling up.
  • What is the modeler doing?  Have they run out of work?
  • Why are lower priority features ready for test?  Why are they ahead of higher priority features?

The board won’t answer those questions, but quickly highlight them for the team to answer.

What are the benefits of a Feature Board over the by-the-book Scrum task board?

Feature Boards focus on feature progress, not task progress.
Too many times, teams get focused on completing tasks in any particular order and don’t worry about features being “done” until the end of the iteration.  Postponing “done” means features don’t get enough polish and tuning time.  As a result, teams release lower quality features.  Feature Boards focus the team on completing prioritized features over merely completing tasks in any particular order.

Feature Boards help balance cross-discipline teams.
Unlike software-only teams, a cross-discipline team of game developers can’t share as much of their work (e.g you really wouldn’t want me creating a texture or a sound for your game).  So it’s important to quickly identify problems with the flow of work.  Task boards don’t do this well;  They don’t visualize stalls and backups.  As a result, individuals end up solving problems by working on more things in parallel, leading to late integration, testing and tuning.  Feature boards show, dramatically and frequently, where the stalls are occurring, or soon to occur, which focuses a team's response.

Feature Boards help limit Work-in-Progress (WiP).  
In order to complete features sooner in an iteration, a team needs to work on fewer features in parallel and address issues or workflow problems that are stalling work or wasting time.  By separating the “In Progress” features from the “Waiting/Blocked” features, a team will see where work is piling up quickly enough to be able to do something about it.  Teams can even institute “WiP Limits” on the columns or rows to stop any new features being added when work is piling up too much.  This leads to different behaviors.  For example, when the team sees that testing work is piling up above, others in the team can help out.  There is no law of nature that says “only testers can test”.  By embodying WiP limits, Feature Boards can be a tool for encouraging such “out of the box” thinking.

“This looks like Kanban!  Why not just use Kanban?”
Some of these ideas come from Kanban (like WiP limits), but it’s not Kanban by-the-book.  While Kanban by-the-book is great for some work—work that is less exploratory, or follows a predictable flow of hand-offs from one discipline to the next—the Feature Board is better for teams that are working on unpredictable new features and “first-time” content.  Feature Boards fit best within a time-boxed iteration which has a lot of “swarming”.  “Swarming” means that there is an unpredictable flow of work between disciplines to create a feature and the feature will bounce around or iterate unpredictably before the fun is discovered.

Own It

The bottom line is that I don’t care what label you use (Kanban, Scrum, etc).  You need to find what works regardless of where it comes from and keep finding ways of making it work better.  That’s the agile mindset.

If you want to know more about Feature boards (such as what the feature cards or burndown charts used with Feature Boards look like), please follow my blog (http://blog.agilegamedevelopment.com)  where this article first appeared, for upcoming articles or my Twitter feed (http://twitter.com/ClintonKeith)


Related Jobs

Yoh
Yoh — Vancouver, British Columbia, Canada
[10.17.14]

Build & Test Engineer
Nix Hydra
Nix Hydra — Los Angeles, California, United States
[10.16.14]

Programmer
Nix Hydra
Nix Hydra — Los Angeles, California, United States
[10.16.14]

Game Designer
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[10.16.14]

Senior Sound Designer - Infinity Ward






Comments


John Flush
profile image
The problem we always faced while using these boards were it feels like a step backward. We have tools, we are in our IDE's with plug-ins to all the tools, (bug trackers, agile process management like Greenhopper (now JIRA Agile) or VersionOne) and then we have some cards pinned to a wall that duplicate the status and the summary information. We even made a tool that would help print our cards from our tools so we could put them on the wall... In the end the duplication was annoying.

My only suggestion is go all cards or go all tools and almost any shop that communicates up to higher management will need tools, or a layer of secretaries (or worse, project managers that do the same thing for $50,000 more) that help copy around the data.

We finally ended with going all tools and to facilitate stand-ups we have a board like view to the real data so we only ever have to update it once.

For those that like this idea and would rather go all board... try out Trello. 100% free and while it doesn't have horizontal groups it does everything else a board can do (pictures, attachments, comment logs, due dates, email updates for coordination throughout the day, etc) except in the cloud and on everyone's devices.

Clinton Keith
profile image
John,

Thanks for the comment. This raises a point for me that I might not have been to clear about.

The reason I push for physical boards for iteration tracking is that they are meant for the team ALONE. Once this data gets into a tool, I find management often can't resist using it to measure task hours, etc. and giving feedback to the team about those numbers.

The purpose of iterations is to allow the team a certain amount of time to own a goal. How they get there is up to them. This creates huge motivation and incentive, at the team level, to improve how they work and what they are working on; people act differently towards aspects of their life they own.

The metric we want management to focus on is the larger picture and the value being added every iteration. Hourly activity is poorly suited for this. For example, when we put pressure on developers to do their day-to-day work faster or longer, quality is the first thing that suffers. There needs to be a balance.

Additionally, electronic tools for daily management also promote the belief, in many organizations, that control can occur from a desk. Better leadership happens when management spends time with the developers. In lean circles, this is known as "gemba".

But, I don't blame the tools. I come from a tool dev background. It's a cultural issue that tools can help keep entrenched. Maybe not in your studio, but in many others.

Clint

John Flush
profile image
That is a good point that a lot of people don't see. Teams that have tried to shift to agile struggle a lot with this concept - that they own it and as long as they deliver in the right way it doesn't matter how they got there.

Barna Biro
profile image
I generally agree with John. Trying to mix many tools that kinda do the same thing, will many times just cause problems one could have avoided and never have to worry about ( + wasted time, etc. ).

@Clint, don't take this the wrong way, but I feel that your view on things is a bit idealistic / naive. In your visions ( at least, that's what I understood from your article and comment - sorry if that's not what you were actually trying to communicate ), every team member should, more or less, pretend to be a Team Leader / Manager. It's not enough that every individual should focus on completing the task he / she is assigned to as best and as fast as possible, but they should also keep track of ( "care too much about" ) the general project progress? To me, that sounds horrible and smells like disaster...

The entire point / purpose of having a Team Leader / Manager is to have a single person ( or a few persons if the project is really big ) dedicated to keeping track of the project and individual team member's progress and try taking the right decisions in order to meet deadlines. The Team Leader / Manager should guide development, should move people between tasks ( if needed to get crucial features done on time ) and if there's no other way, then even delay or cut features ( move them into future Sprints / Iterations, etc. ) + many more responsibilities.

Don't get me wrong... I'm not saying that team members should just "keep quiet and work" ( on the idea: "that's what you're paid for" ). They should, normally, have the freedom to express possible concerns or suggest alternative approaches or new features or whatever. BUT, having them worry / think about management-specific problems and general project and team progress IS WRONG. If a project is lacking a clear lead ( manager ) and everyone is let to pretend to be a leader, then you'll soon find yourself a lot of trouble!

Incompetent lead / management ( or the lack of it ) CANNOT be fixed with "Feature Boards" or tools ( electronic or not )... nor can it be fixed by making everyone a leader / manager. That being said, "Feature Boards" and different tools or approaches do have their place, but in order to actually benefit from them, one has to first have a "healthy foundation". No good will, most likely, come from embracing practices / solutions for the sake of embracing them ( or to be able to brag with some fancy words ) in an already "unhealthy environment" ( since you brought "agile" up... this is actually quite common in the so called "agile environment"... where everyone thinks they are "agile" just because they apply 1 out of 100 practices in their company - usually, daily SCRUM that yield no real benefits... it's just an excuse to waste time every day - or because they blindly follow some steps described in some books / articles they've read on the web ).

Quote: "You need to find what works regardless of where it comes from and keep finding ways of making it work better."

I can full-heartedly agree to that and that's what people should strive to achieve.

Clinton Keith
profile image
Hi Barna,

This article merely shares the work that teams have done on their own. There is nothing to prove or disprove here. I don't understand the point of your comments other than to communicate your own bias against agile.

After training/coaching at over 200 studios, I see two basic approaches. One is to grow creative intelligent people to take increasingly more control over their day-to-day work.

The other is to assume that they can't do this and to dust off the completely disproven scientific management (Taylorism) methods that assume we can't trust people and that we need to break down every bit of work and assign it to them. IMO, it's the worst thing that we do to some of the most creative intelligent people on the planet who flock to game development, only to leave a few years later.

Yes, you cannot apply a layer of agile practices over a command-and-control culture and assume some buzz-word fairy will sprinkle productivity dust on you. This article was not for those who assume that.

Yes, you need leadership and vision. This does not mean that developers can't translate a clear vision into 2 weeks of work on their own without being micro-managed. Why do people still have a problem with that?

The bottom line for me is that I have seen many studios that embrace the core values of focus, courage, openness, commitment and respect. They get it and they apply it well. This article was for them.

I have also seen studios/individuals that don't. They aren't ready for this. For them, they have a ways to go and I hope they do.

Clint

by-the-way, I take being called "naive and idealistic" as a complement. It places me in good company and separates me from the "burnt out and jaded" category, which I refuse to join even after 20 years in this industry.


none
 
Comment: