Wednesday, October 30, 2013

Defining Done

At the end of every sprint, a team must deliver a potentially shippable game that achieves a “definition of done”.

What does “done” mean at your studio?  When I ask this question in courses, we often share some anecdotes and definitions such as:
  • “It compiles on my machine.”
  • “I’ll know it when I see it.”
  • “It’s 90% complete”
  • “It’s coded” (or “it compiles”).
  • “You can see it in the game.”
  • “It’s first pass” (out of an undetermined number of passes)

There are all sorts of unique “cubicle level” definitions that each developer or group defines and one or two “project level” definitions that are honored occasionally over the course of a project (usually following lots of crunching and hacking).
One of the initial challenges in adopting agile is defining a more frequent and universal “definition of done”(DoD).  As with all agile practices, it’s emergent; Teams inspect and adapt the game and their work and continually improve the DoD.

Non-functional Requirements
A DoD is derived from a set of  non-functional requirements.  These are attributes of the game that are not unique features, such as:
  • The game runs at a smooth, playable frame-rate
  • The game runs on all target platforms
  • The game streams off disc cleanly
  • The game meets all Facebook API standards
  • The code meets the coding standards of the studio
  • The assets are appropriately named and fit within budgets
  • All asset changes must be “hot-loadable” into the running game
  • …and so on

Some of these requirements start out as user stories.   If the game is running at 10 frames-per-second, we’ll want to do some work to get it there and then ensure it stays as part of a DoD.  An example of that story might be:  
  “As a player, I want the game to run at 30 frames-per-second, so it doesn’t suck” 
This is a good early story to introduce (IMO, any game that runs at 15 fps sucks).

Creating a Definition of Done
Non-functional requirements aren’t a definition of done, since they are not a specific checklist of things for the team to do.  A DoD for the story above might start out with someone playing the game and telling the team if there are any lags.  Later, the team might automate this testing so that the game plays itself (all levels and missions) overnight, logging the time for every frame and pass/failing against a metric such as “the game must run at 33 milliseconds or better for 90% of the frames”.
While it might be tempting to create a massive DoD when a team starts using Scrum, it’s counter-productive because it’ll end up being ignored or gamed.  It’s best if teams build up the definition over time as they hold retrospectives and improve their practices.

Multiple Definitions of Done
Because potentially shippable doesn’t always mean shippable, there needs to be more than one DoD, including “done done”, which translates to “shippable” or “releasable”.  I’ve seen teams come up with four or more DoDs, which cover anything from “prototype done” to “demo-able done” to “done done”.  These identify the quality and content stages that large features, which take longer than one sprint to be viable (called epics), must go through.
I’m OK with one extra “done done” definition, but beyond that I prefer teams to use acceptance criteria for the progress of epics.

I’ll write about these acceptance criteria soon.  For now, I’m done with done.

Monday, October 28, 2013

Potentially Shippable

“At the end of every sprint, a game must be “potentially shippable”

Agile pundits use the phrase “potentially shippable” a lot, but don’t always agree on what it means.  
To me, it depends on the deployment cycle of the game we’re making.  Some games are deployed every sprint and “potentially shippable” for such games means they are ready to ship.  That’s easy!
Other games don’t release every sprint, perhaps releasing once every few years.  Requiring these games to be fully shippable every sprint is unfeasible for a few reasons:
  •  Games often have large minimally marketable feature sets (content and features) that take months to prepare.  Think of a sports title, with all the stadiums, teams and game features.  An NFL game with only six stadiums that only had running plays implemented wouldn’t sell very well!
  • First-party approval processes take weeks to pass.  Sony, Microsoft nor Apple would enjoy running your game through their testing group every few weeks.
  • Major features take more than one sprint to achieve a marketable quality.  Try shipping an FPS with two weeks of effort spent on online multiplayer!

This difference between potentially shippable and shippable leads to multiple definitions of done, each of which is a checklist of activities that developers need to perform every sprint.  These activities might include ensuring that the game runs at an acceptable frame rate, it doesn’t crash and the code has a high level of quality, etc.  The goal is to reduce the debt of unfinished work throughout development to a predictable level.  The reason is that debt (bug fixing, polishing, optimizing) grows with interest over time and can derail the best of plans.  For example, if your game has to stream levels off a disc in 40 seconds or less, wouldn’t it be best to test this before you’ve created all your levels?  Have you ever been on a team that discovered they had to chop half the textures out of their levels a month before they were supposed to ship?  I have, and it wasn’t fun!  Having such a test as part of a definition of done is a good idea.
My next blog entry will cover the definition of done and how it guides the creation of potentially shippable builds and evolves as the team’s development practices mature.

Friday, October 18, 2013

An Introduction to Situational Leadership

Imagine you are the leader of a team of developers creating a new mobile game.  The team has worked well together, but recently you’ve noticed that two of the senior members are butting heads.  Today, they are really getting into it, arguing in front of the rest of the team.  You can tell that this is having an impact on the morale and effectiveness of the team.

Do you:

  • Meet with both of them and tell them how they can resolve their conflict and make sure they do it?
  • Speak with them separately about the problem, and then get them together to discuss it.  Encourage them to work better together and support their attempts at improving collaboration?
  • Talk to them separately to get their thoughts, then bring them together and show them how to work out the conflict between their ideas?
  • Tell them you are concerned about the problem and the impact of it on the team, but give them time to work it out by themselves?
Which is the best answer?  It depends on the team.  Teams have different levels of maturity that must be matched with a leadership style best suited to it.  By “maturity”, I don’t mean how grown-up they act; we game developers don’t usually care much about that.  In this context, maturity means the skills the team applies to work out problems among themselves and their performance as a team.  We want teams with high levels of maturity because they are more effective and enjoy working together the most.  This is where situational leadership comes in.

Situational Leadership Theory

Developed in the late 1970’s by Paul Hershey and Ken Blanchard, Situational Leadership is a set of principles that help guide how leadership is applied to teams of differing maturity levels.  They defined four leadership categories:

  1. Directing - A leader defines roles and tasks for developers and the team.
  2. Coaching - A leader still sets the direction for the team, but coaches the team in the how roles and tasks are determined.  Allows the team more freedom in tracking their work.
  3. Supporting - A leader allows the team to make decisions about roles and tasks, but still shares in decision-making and progress monitoring.
  4. Delegating - A leader is involved in decision making and progress monitoring, but the team is fully self-organizing in their roles, practices and work.

The goal of a leader is to help teams adopt higher levels of maturity and change their approach to leading from directing through delegating:

The Situational Leadership Model

This is just a model, not reality, but it is an effective model to help guide leaders to apply different standards to different teams, just as a parent applies different parenting principles to a teenager than they do a toddler;  at least I wish my parents had.

Situational Leadership Applied

Take a look at the answers to the question raised above and see how each of them might apply to teams at different maturity levels.  A newly formed team will most likely need the directing (S1) category applied, while others that have been together longer and are working well can have later categories applied.

The challenges to this are identifying the maturity level of the team, including what model to use, and coaching teams to reach higher levels of maturity.  Future articles will address those topics.