Bowling Scorecards - GREAT AGILE Practice

Intro

"Wait, are you crazy? Bowling and Agile?"

No, dear reader, I'm not crazy. The team I'm working in right now just stumbled over a new technique (not sure if someone else does it, just before people start complaining about copyright infringement) that really make our lives better.

We now have bowling scorecards for our repetitive tasks.

"Come again?"

Yeah, that's exactly what it is.

Building my Bowling Scorecard

Say we as a team agree that having good code coverage is actually an important thing (it's just an example, who cares about coverage or testing anyway?!). Then, after thorough investigation we find out that we have 20 classes with poor coverage. Cool! All we need to do is draw the following card:

Code Coverage

[MATRIX of 5x4 or 4x5]

You can check the picture of a bowling scorecard here (stolen from Stuart's blog): 

Every time someone completes the task outlined in the card they get to score a spare (one mark in one box). When they have tested it and committed it properly, they get the strike (another mark in the same box).

The scorecard is considered done when all the boxes have Strikes.

What's the purpose?

"Oh, so you track the number of tasks done. So? Big deal! I have a bug-tracking tool "XYZ" that does it for me!"

No, no, no! Bad reader! That's not what it is! It's not a bug-tracking tool!

The main purpose of the bowling scorecard (as very well said by Stuart - link at the end) is to remind us that we CHOOSE to change something that hurts and how far we are at it.

That's very important, since it's a very visual artifact. Every time you go to the wall looking for stories or moving a story you think: "Hmm... I might fix a couple of those and get some strikes myself!"

Before you know, the card is gone and you have a much better codebase.

Side-Effects

There are a couple of very interesting side effects for me.

The first one is that we get a very nice morale boost from the scorecard. Every time we get spares and strikes, the team feels more confident about the work we're doing. Finishing a whole scorecard has a major effect on team morale! We celebrate the end of it!

The second side effect we noticed is that since the spares (one mark only) are very visual (and unappealing since you want your strike to go as fast as possible), having many spares in the scorecard reminds you that you need to commit. That has a very positive effect, since we don't try to grab more than we can chew. Frequent commits have been discussed many many times before, so I won't even go into that area. Suffice to say we don't chew more than 3 or 4 at a time, except in very rare occasions.

Conclusion

The bowling scorecards might not be revolutionary, but they worked magic in our team. We really pay more attention to making the codebase better and pairs take turns at improving it between delivering business value.

You can read more about at the blog of Stuart Caborn, here. I couldn't put the link first, otherwise who would read mine, lol! Just go read his description! It's a lot better than mine! :)

Happy agile coding!