Tuesday, January 26, 2010

No applause, just throw money

I have an aversion to the applause that occurs in some iteration showcases (aka sprint reviews) on agile teams. The showcases are the meetings at the end of an iteration where the team shows working software to project stakeholders. Unfortunately, many teams end up displaying PowerPoint presentations instead or in addition, but that's a topic for another post.

I once witnessed a team that had 2-week iterations and held a 2 hour review at the end of each iteration. Each team member presented what he had worked on and accomplished over the course of the iteration. First of all, two hours was too long for this team for a 2-week iteration. They simply did not produce enough demonstrable working software to warrant a two-hour meeting. Worse, they often resorted to presenting partially completed stories - another problem, but again, fodder for a future post.

Having each team member speak and present his accomplishments might have been a good thing for that particular team. It can provide a similar social pressure that stand-up meetings provide - nobody wants to stand up and say they didn't accomplish anything, so each team member strives to deliver demonstrable value. The problem I had with this particular team was that the norms established that everyone applaud each person after his little piece of the presentation. Not only was the applause time-consuming, it was gratuitous. Folks in the meeting applauded simply because they were expected to, not because of any remarkable achievement.

In some cases, the team member didn't really accomplish anything of note on his own and the applause was simply out of place. It is as if my dog takes a dump in the middle of the carpet during a party and the crowd rushes up to pet and praise him, and offer him doggie treats. Clearly, this confuses the dog.

Though applauding every presenter is certainly overkill, I argue that applause at the end of an iteration showcase should be eliminated (or better, never started in the first place). In any case, it should never be de rigeur, and should never be instigated by an outsider who may have no clue as to whether the team really accomplished something special.

Applauding showcases for mediocre or even poor iterations can have a deleterious effect on motivation. Consider this possible thought going through a team member's head: "They applauded for this crap? They have no clue what we're doing".

We have a habit of rewarding performance. If my kids come home with straight-A report cards, I heap praise on them. If a see a C, I begin my own inspect and adapt cycle at home. But in report cards, the grades are clear, and are mostly objective. That is - the "A" reflects a large number of assignments, tests, and projects, and the teacher assessing the outcome has a substantial pool of similar production to compare against. Outcomes of iterations/sprints, on the other hand, are hardly objective, and are not comparable to other teams' output. It is truly only the team members who know, in their collective heart of hearts, whether they really deserve applause or not.

So my suggestion: omit the applause until the code gets into production and the customers' rave reviews start flowing. That's when the party should start.

3 comments:

Antonio Terreno said...

I don't know, actually lately here we applause for every single story point signed off...
It has been so contagious that now a whole floor (50+ people, working in other teams) applause every time and cheer the other teams.
This environment used to be very silent, it adds quite a lot of fun, I am pretty sure it's having a positive effect on the whole client company.

Adrian said...

Sounds like a cool environment Antonio. I like it.

I think a key aspect that makes it different from the environments I've described is that the clapping is team generated. I once worked with a team that used a gong that they used to signal story acceptance - similar to clapping in your environment.

Another distinction here is that story points signed off is success, and the clapping is warranted and timely. But every iteration is probably not a success on the whole.

Let me go back to my unfortunate dog analogy. Clapping at the end of an iteration is like waiting until the end of the week to reward your dog for the collective behavior exhibited during the week. Your post points out that more direct rewards - close to the point of delivery - are useful. I agree.

Thanks for contributing to my thinking on this point.

Steve Moyer said...

I've hit the gong and I've been there for the clapping. I agree on both counts.

I think showcasing on a person by person basis is flawed in the same way as doing standups person by person. Showcases should show completed stories, highest priority first. Standups should tell us about stories in progress, highest priority first.

When teams go around the room in environments like this it usually feels to me like they might as well just turn to the highest ranking manager in the room talk directly to them. If they did this outside of a meeting setting it would be more efficient as it wouldn't waste everyone else's time.