Flow my tears, the Scrum Master said (Part 1 of 2—Having Great Standups)

A Scrum Master has a tough job. He is supposed to help his team perform without actually diving into the work himself, for if he did, then when someone has an impediment, he would be busy and likely not have the broad context needed to solve the problem outside of his immediate work. Preserving a big picture perspective is important. Firemen don't leave the station without their Fire Captain. The Captain isn't allowed to enter the building and must stay in the fire engine (or near it) and coordinate his team via radio. (I've even heard that Fire Captains are literally locked inside the fire engine to prevent them from abandoning their post to rush into a burning building.)

Everyday, the Scrum Master's job is to figure out how to get the team perform better, which is much harder than developing code. The worst situation a Scrum Master can be in is have a team that isn't delivering software in a predictable fashion, and the team always claims that everything is going fine.

Day after day of standups where nothing interesting is spoken of, and sprint after sprint of missed sprint goals is enough to make a Scrum Master cry. If this is the case for you, then you need to fix this!

Here are some methods on "loosening up" a team so they share their problems:

• Ask questions about tasks which aren't progressing very well (a 1 day task going into its third day)
• Encourage risk taking and nontraditional ideas, activities and actions
• Figure out how to make it OK to "call uncle" so you know they need help.
• Don't immediately judge impediments: "That is too big to tackle, just live with it," or "that is such a small impediment when I know there are some really large ones that are holding us back."[1] The team is supposed to air impediments, not be told to air only the impediments the organization wants to handle.
• When an impediment is discovered, track them! Put them on a big visible chart of some kind. Don't try and be a "waiter" that takes their teams "orders." Unlike working in a diner, the cycle time of solving impediments takes more than twenty minutes, and usually up to 24 hours. Within thirty minutes after standup, no one remembers what happened though the person who brought it up will remember at standup the next day. The impediments should be visible in the team area so that everyone knows the status of them.
• Celebrate whenever an impediment is brought up. Usually an "atta-boy" will work.
• Acknowledge people in a public setting for exposing impediments.

For each day that your team reveals "no impediments" get worried because something is really wrong with the process. If they are consciously avoiding to reveal them to you, there is a trust issue. If they are un-conscious of their impediments and living with a lot of burden, then figure out how to change their perspectives. (I'll blog on this topic next.)

It's a tough life being a Scrum Master. You rely on those doing the work to tell you what ails them, and you can't help them if you don't know what the problems are. You can't be a Scrum Master if they won't tell you of their problems. You can't be a Scrum Master if they don't trust you to take their problems and treat them in a way that works both for the team and for the organization.

You can't solve problems that you don't know about.

If all else fails, embarrass them: Tell them you'll cry if they won't do their jobs and open up about what isn't working.

No one likes to see a Scrum Master cry.

[1] One time during a standup, I brought up two impediments, each of which were quickly judged by an attending manager as one being too hard, and the other too small when there were other bigger problems. These are signs of a reluctance to change. If an organization can't be bothered to fix small problems or is unwilling to do so, then the adapt part of Scrum is broken outside of the team's scope and that is a sad situation.

Good stories have Great titles

When you read a good book, you can quickly refer to it by its title: We, Animal Farm, The Left Hand of Darkness. Having a title saves you the time of recapping the plot in order to establish that you and someone else know what the story is about.

Every day, Scrum teams do a 15 minute standup during which they describe to their team how they've spent their development time. I've noticed that teams which have been coached to use the "as a user" format of stories (credited to Rachel Davies & Tim Mackinnon, promulgated by Mike Cohen and many others including my self), create an impediment by giving their stories ID numbers instead of titles. "I worked on client authentication" turns into "I worked on story 6933," and most of the team doesn't know what this is and often just lets the information fly overhead. Even if they were familiar with 6933, there is less information and more abstraction when assigning numbers, and it's hard to feel an emotional attachment when sharing this number to people ancillary to the team, such as stake holders or perhaps the product owner. These story serial numbers become an impediment to communication.

For a while I coached teams to save that first line for the story title. It's easy to forget though and violates the principle of "once and only once" since the portion of the "as a user" format already contains that information. As a second measure, I coach them to underline the key words on the story card. But teams still end up adding an ID number, and in the heat of giving standup, it's actually hard to parse all the words though easier to rattle off the ID prominently displayed in the upper left-hand side of the task card, so I sometimes end up wasting my breath by saying the number.
Today I was writing some new stories and struck upon something that made felt right:

WHAT I WANT
so ROLE can BUSINESS VALUE

For example:

I've been using this format on my last two projects and have been very happy so far. I like how the story title has the important element coming first: What I Want.

Give it a try, and tell me what you think. I'd love to here your comments. Let's not try to describe Animal Farm by giving it some meaningless number, unless we're talking about 1984.