Wednesday, September 30, 2015

The evil of tracking tools in the sprint

After 8 years of training and coaching teams I've noticed some very obvious patterns and anti-paterns.  One of them is the impact of bringing tracking tools into the sprint.

These tools are primarily used to:
  • Build the sprint backlog
  • Update the estimates during the sprint
  • Display sprint backlog details during the daily scrum
  • Spit out the sprint burn down
I understand that some teams, that cannot avoid being distributed, want to use such tools, but I rarely see them as positive for collocated teams.  It's not the fault of the tools, but how they are used.

One of the primary aims of Scrum is the boost in productivity seen with teams that have a sense of ownership in how they run their sprints.  Teams with ownership are accountable for their commitment.  They enjoy their work more and they explore ways to improve.

Sprint tracking tools can get in the way of that by:
  • Not allowing an "all hands" approach to managing the sprint backlog: one mouse, one keyboard, one operator.
  • The data in the tool is only brought out once a day because there are not enough licenses, developers don't want to learn the tool, or the extra effort isn't worth it.
  • The team's ability to customize the artifacts (task board, burn down, etc) are limited by what the tool can do.
  • The metrics of the sprint (sprint velocity, burn down), and even individual developer progress can be monitored by management.   Guess what happens when a developer or team is asked why their burn down is not diagonal enough?
  • Making the daily standup a status reporting meeting by focusing on individuals.
Even if the tool is being used in benevolent ways, the team can suspect otherwise.  In organizations that are trying to grow trust, this can be a killer.

Also, teams need their sprint backlog to be radiated at them.  Tools refrigerate the backlog by storing it in some cloud.

When I bring this up, I often hear from the Scrum Master that the tool makes it easier to do their job; tracking the sprint and producing the burn down or that there is no wall space.  It's often news to such Scrum Masters that their role is not to be efficient creating the artifacts, but helping the team build ownership and trust...or just tracking down solutions, like a portable task board.  I don't blame them necessarily.  Adopting a tracking tool for sprints are often an interpretation of how Scrum should work in an amber or orange organization.  Teams in these orgs who are new to Scrum might even want tools in the sprint so that the "Scrum fad" has minimal impact on them.

The sprint backlog is owned by the developers on a team to help them organize and manage their shared commitment and forecast for achieving the sprint goal.  It serves no purpose external to the team.  

Courage, commitment, focus, openness and respect aren't always easy to instill, but it can start with a bit of tape and some index cards.

Thursday, August 13, 2015

Tips for the Daily Scrum

When visiting a studio, I'll often ask to observe the daily stand-ups meetings.  It's the best way to sense where a team is and how to focus coaching time for the visit.  An effective daily stand-up meeting is an energetic swarm of committed team members that need to quickly synchronize their efforts and identify anything that is threatening their shared goal.

Some daily stand-ups (or daily scrums), aren't like this.  They are monotonous, manager-led and pointless to the attendees.  Teams here lack any sense of commitment or ownership and they eventually question the merit of the practice and perhaps even abandon it.  Unfortunately, abandoning the stand-up doesn't improve their chances of building commitment or ownership, which are principles of Scrum.  So I've compiled a list of pointers on ways to improve the daily stand-up meeting and improve commitment and ownership.

The stand-up is for the team.  This meeting is for the team to synchronize their efforts towards achieving their goal, not just as a status report.  If their are any "management artifacts" that need to be created (such as an update to a tracking tool), it should be done outside the meeting.

Anti-Tip: A sprint's commitment is on quality, not quantity.  If a studio wants a predictable amount of garbage, then taking over and running sprint meetings for the team is the best way to do it.

The rules aren't fixed.  The "answer the three questions" rule you read about in books is only the starting place.  Teams add questions, change the format, and do anything necessary to address their needs.

Anti-Tip: Make Scrum a process by fixing all the practices.  This will ensure that continuous improvements will cease.

It's about the commitment to the goal, not just the tasks.  Task tracking is critical, but work will arise on a daily basis that wasn't considered during sprint planning.  Teams need to react to this new work and balance it daily against their goal.  They need to inform each other about new developments and threats to their goal.  They should care about accomplishing the tasks, but they should care about the goal more.

Anti-Tip: Force teams to use task tracking software.  They'll measure success by completing tasks, not adding value.

The ScrumMaster must know their role.  ScrumMasters do not run the daily stand-up.  They facilitate them.  The difference is that the rules for the stand-up come from the team and the ScrumMaster ensures that those rules are followed.  If the team has decided that being late to the stand-up is not acceptable, they'll likely have a rule in place to chastise those who are late.  Paying $1 or singing a song is common.  ScrumMasters must not let them off the hook. 

Anti-Tip: When you solve all of today's problems for the team, they'll expect you to solve tomorrow's problems as well.

Respect the time-box and start time.  Some of the most effective stand-ups I've seen were five-minute "hurricanes of energy and activity".  The team shared what they needed to share and went back to work.  Stand-ups that take longer than 15 minutes are just wrong and need to be fixed.  Also, don't waste time by having a variable start time (based on who shows up late).

Anti-Tip: Ignore the time-box and see who shows up on time (& vice-versa)

Prefer a physical task board.  This is not always possible to have, but here is no electronic replacement that is equivalent.  A physical task board with cards allows everyone on the team to handle the tasks simultaneously at the same location.  It encourages team ownership.

... & Avoid projectors.  This might seem a bit redundant given the last point, but projectors used in a stand-up meeting should be renamed "conversation killers".  Projectors usually involve a software tool that provides information in a linear, one-at-a-time way with someone, unfortunately often the ScrumMaster, at the keyboard/mouse controls.  If defeats the non-linear, swarming-on-the-goal, value of the stand-up.  Software tools are often a critical part of project planning and tracking, but they have no place in a co-located daily stand-up.

Anti-Tip: Usually tools allow only one operator (mouse/keyboard).  When there is one operator in the meeting, guess what happens to the engagement levels for everyone else?

It's owned by the team.  The team picks the format and time of day of the daily stand-up.  Since they own it, it should run the same way, regardless of whether the ScrumMaster is there or not.  One simple test I recommend to ScrumMasters is to occasionally hide around the time of the daily scrum and see what happens.  If the team meets and runs the stand-up the same way as when you are their, you are doing a good job.  If they don't meet or stand around wondering what to do, they have some things to fix.

Anti-Tip: Standing in a circle answering three questions is a secret formula which leads to the magical process fairy flying overhead, sprinkling productivity dust on people.  These practices have nothing to do with team engagement through ownership.

(this post was edited from an earlier post)

Friday, May 22, 2015

Level of Detail for Product Backlogs

Replacing a 300 page design document with a product backlog filled with thousands of small user stories doesn't provide much benefit.  Responding to uncertainty, emergence and change requires a plan which is flexible, communicates the game's vision and doesn't try to document uncertainty away.

Games need a product backlog with a couple of hundred stories at most.  Upon hearing this, a question often asked is, "how do we encompass the scope of a large game in just a couple hundred stories?

The Level-of-Detail Metaphor

A useful metaphor to answer this question is the "Level-of-Detail" (LoD) technique often used in video games.  This technique reduces the workload of a renderer by selecting one of several versions of an object to draw based on how far it is is from the camera.  In the figure on the right, a distant boat will first use the low-polygon model on the bottom.  As the boat approaches the camera, it switches to using the higher polygon (or triangle) models above.  Ideally, as the boat approaches, you won't notice the models changing (old-popping).

The reason for  using LoDs is that graphics engines and hardware have limits on the total number of polygons that can be rendered at 30 to 60 times a second.  If you want to have hundreds of boats shown in your game, using LoDs is a common way to render them.

LoDs for User Stories

The same approach is used for the product backlog.  The figure below shows some example LoDs for user stories:

Just as LoDs allow games to show a full, complex world on the screen, the LoD approach to product backlogs allows you to encompass the entire vision for the game in one view.  Highly detailed documents or backlogs don't allow you to "see the forest through the trees" and, as with a forest, are easier to get lost in.

Level of detail is increased through the practice of splitting stories.  You'll find some examples there.

Thursday, May 21, 2015

Acceptance Criteria: or How I Learned to Stop Worrying and Love Conditions of Satisfaction

"Of course, the whole point of a 
Doomsday Machine is lost, if you 
*keep* it a *secret*!"  
- Missing acceptance criteria?
A definition of done applies to all product backlog items, but sometimes you need to define a set of important requirements that are unique for individual stories before they are worked on.  These are considered “conditions of satisfaction” for the product owner, or acceptance criteria.

Example: As a player, I want to see a Message-of-the-Day (MOTD) from the developer so that I learn useful things about the game.

Some acceptance criteria for this story might be:
  • The MOTD window may only take half the screen.
  • It’s only shown the first time someone starts the game during a calendar day.
Keep in mind that acceptance criteria shouldn’t be a huge list of design specifications.  These are a limited set of specific “must do” criteria that the team needs to know up front.

Types of acceptance criteria:
  • Specific functionality known up front (above).
  • Special, non-functional requirements (e.g. memory or CPU performance limits), for example “The game should have ten of these effects running with less than 2 milliseconds per frame cost on the target platform”.
  • A set of expected behaviors for a subset of features, such as needing persistence in saved games or needing specific tests for online gameplay.   
  • Known areas that will be incomplete.  For example, if you’re implementing a jump feature, but don’t have enough animation support (and have failed to get more), an acceptance criteria might say “some animation transitions will pop”.
Good acceptance criteria will:
  • Have a clean pass/fail, testable state.
  • Won’t dictate implementation details.
Who and When?
Acceptance criteria can be added to a story any time before, and during, sprint planning.  Usually they’ll be added in release planning, grooming and sprint planning with greater detail added as the sprint work approaches.  The product owner doesn’t have to be the one to identify them all, but should be present when they are captured.  I prefer to have the team there as well asking questions and suggesting acceptance criteria along the way.  One useful approach is to have a member of QA or a developer capture any acceptance criteria during discussions of the story, especially in sprint planning.

The Point
Acceptance testing will focus the team on the outcome as much as the means of getting there.  It allows the business side to build trust with the team and to improve how they communicate their needs.  When trust exists, the business is less likely to worry about the sprint and interfere.

Wednesday, May 20, 2015

Help! My Scrum Master is Running the Sprint!

“Hi, I had a question.  Our Scrum Master is acting like a manager, running all the meetings and assigning work.  This is what they did before Scrum.  I thought Scrum meant the team did this stuff?” - A developer

The values of Scrum apply here.
Scrum! Scrum! Scrum! Scrum!

The sprint is the team’s commitment to a goal.  True commitment to the game and continuous improvement requires a level of ownership, otherwise it’s an environment of compliance and people don’t engage as well with that.

The barrier to allowing ownership is fear.  I often hear the micro-managing Scrum Master’s fear of what will happen if the team doesn’t follow their leadership.  "They might fail!", they cry.   There is often an underlying suspicion that others on the team are not competent because they'll make mistakes.   The news is that competence doesn't mean you don't make mistakes!

Allowing teams to make mistakes and safely fail from time-to-time requires trust and courage.  Trust requires respect.  A lack of trust and respect is a cultural root of evil.  When I see locked supply cabinets, dictated core hours or time-sheets, web filters, people referred to as “resources” etc. I know that the true adoption of Scrum will be a bit harder.

How can this be done?
Courage is required
Shifting from a mindset of individual compliance to team commitment requires courage all around.  The Scrum Master and the team must summon the courage to take chances and fail every once in awhile.  Emboldening the team to find this courage is more challenging than micromanaging via a task spreadsheet, but it’s also more fulfilling.  It doesn’t happen overnight, but trust and respect can be grown.

Scrum Masters can start with some simple things:
  1. Silence yourself! Stop doing all the talking.  Learn to allow awkward silences.  The team will fill the silence with their own ideas and solutions.
  2. Ask questions, even when you know the answer.  Teach them to catch fish rather than giving them fish to eat.
  3. Be courageous.  Demonstrate respect and protect the team.
The development team assumes a part of this challenge as well.  It’s often hard for them to shift from being assigned tasks to accepting responsibly for planning and executing their own work.  Respect and openness among each other is critical.

For example: if an artist is having problems getting code to work with a model, the entire sprint goal is threatened, but the team's focus on their shared goal should guide them to solve this problem on their own.   There is no need to blame the artist for not solving their own problem.  There is no need for someone wearing a manager’s hat to assign an engineer to fix the problem.

Does this mean managers/producers should be fired?
Don't expect leadership to
be overthrown, but leveraged
An underlying fear from managers or producers jumping into the Scrum Master role is that they should continue doing what they've been good at in the past or they'll be let go.

In the ten years that I have been training teams to use Scrum, I haven’t seen this happen.  I’m not saying it never will, but most stories I hear reflect my own as a manager in a studio that adopted Scrum.

I found that as teams became more self-organizing, there was a growing part of my time that needed to be filled with other things.  Eventually, about half my day was freed up by not micro-managing.  This wasn’t bad because the work that teams took from me was never the work I enjoyed doing.  So, I joined a team as their product owner and ended up enjoying the work far more as I was closer to the game and the people making it.

This might not be the path for every manager.  Agile should lead a studio to ask what practices and roles are benefitting their games and the people making them and what parts are not.  Again, this can threaten the status quo, which is why a lot of larger, established studios have a harder time adopting agile.

"Now I can make cool movies about
monkeys taking over the world!"
The bottom line is that these values have to win out for you to have full success with agile.

Tuesday, May 19, 2015

The Scrum Values

The Scrum Values

  • Focus. Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.
  • Courage. Because we are not alone, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.
  • Openness. As we work together, we practice expressing how we're doing, and what's in our way. We learn that it is good to express concerns, so that they can be addressed.
  • Commitment. Because we have great control over our own destiny, we become more committed to success.
  • Respect. As we work together, sharing successes and failures, we come to respect each other, and to help each other become worthy of respect.

Saturday, May 16, 2015

The Art of Splitting User Stories

Splitting stories—the act of breaking up large stories into smaller ones—is as much art as practice.

The strategy of splitting stories is to split them as late as possible to fit in a sprint just before the sprint that will take them on.  Think of it as playing the classic arcade game Asteroids: you only want to break up the large asteroids when they are an immediate threat to you or when you've cleared out the smaller, more dangerous rocks…break up too many of them too soon and the resulting cloud of small asteroids will kill you.

Similarly, if you break up a bunch of epics into a large number of sprint-sized stories, the resulting backlog bloat will cloud vision and diminish your response to change.

There are a lot of good tips on how to split stories, like this one.  In this post, I'm going to suggest some of the more common splitting techniques used for video game development.

A couple goals exist for splitting stories:
  1. Each of the split stories should have some value to the user.
  2. The split stories should be able to be prioritized against one another.
Below are a few of the common strategies and examples for splitting epics along with some reasoning for them.  The examples illustrate single suggested splits, but aren't the only ways the epics could be split.

Split along research/prototype dependencies: 
Example: As a player, I want to react to impacts.
A suggested split:
As a designer, I want to know where an impact occurs.
As a player, I want to react based on the impact location.

Reasoning: The first story allows some research on collision physics and helps the team and designer experiment with different strategies. (e.g. would a simple strategy of having high, mid and low collision volumes be good enough, or do we need something more complex?)

Split along conjunctions:
Example: As a player I want to smash wooden crates and doors open.
A suggested split:
As a player, I want to smash wooden crates open.
As a player, I want to smash wooden doors open.

Reasoning: Do the simplest or most important first.  Also note that the first of anything is usually more expensive, so this makes it easier to see costs by sizing these stories individually.

Split by progression:
Example: As a player, I want to be coached on the rules of poker and ways I can improve my home game.
A suggested split:
As a player, I want the game to have some first-time user experience (FTUE) tips for playing poker.
As a player, I want the game to give me tips for improving my home game.
As a player, I want the game to evaluate my hand strength and suggest the next move.

Reasoning: This split details some of the "ways" the player can improve with a progression of stories that are a bit more specific.

Other splitting strategies include:
Split by acceptance criteria.  Acceptance criteria often make perfect stories themselves.
Split by discipline capacity.  E.g. if you don't have enough animation support, then you might have to split off a "Add polished animations to..." story for the next sprint (after you've done everything else to avoid this).

There is one consistent splitting technique that teams new to agile have a hard time avoiding.  This is splitting stories along component design or discipline effort.  Teams new to agile are used to breaking up features into a plan to develop all the “parts”, which will become useful sometime in the future.

Example: As a player, I want a third person camera that can transition smoothly between a loose camera in open spaces and a tight camera in small spaces that avoids collision with the surrounding geometry.  

A poor split would be:

As a programmer, I want to create a camera manager that will handle transitions between all future cameras.
As a programmer, I want to implement a camera collision system that will avoid camera collisions or occlusions from the surrounding geometry.

The reason these are poor splits reflects agile values and principles that building emergent, working software is better than following a never-perfect-yet-detailed plan which delays that emergence.  A better approach to splitting might be:
As a player, I have a simple polar camera that follows me around.
As a player, I want the distance between me and the polar camera to be based on how close the surrounding geometry is.
As a player, I want the the camera to have a collusion box around it to avoid going into surrounding geometry.
As a player, I want the camera to linearly interpolate its position as a rotate.

There are several advantages to this:
  1. The rest of the team gets a camera sooner.  This allows work and feedback to continue (rather than finding “something else” to work on in parallel).  
  2. Unless you are in the position of being 100% certain of the requirements of the camera system (something I’ve rarely seen on a team), there’s less of a chance that the system developed will need major rework.
  3. Emergent development will often save a lot of time by identifying what we don't have to build.   I relate a story of this in another article.
I’m fully aware that there are some out there rebelling at this idea.  They’ll say “just give me the spec, let me go into my office, put on my headphones, and bang out the camera system…it’ll be much faster”. This is a very common attitude from cultures with more silo’d disciplines.  It’s very hard to for such organizations to shift the mindset from one whose primary goal is to crank out components at the highest possible velocity, to one which cranks out features of the highest possible value.

This is not to say there aren't features that can be fully planned and executed without iteration.  The trick is to not fool ourselves into the belief that we can plan away uncertainty.