Remember, back in grade school, when we used to get snow days? That is, when there was so much snow that they announced over the radio that school was closed for the day and — even better — we got to spend all day playing in the snow? Remember that year when we had so many snow days that we had to stay in school a couple extra days at the beginning of summer to make up for them while kids from other schools got to start vacation? That kind of sucked.

On agile teams — even experienced ones — I often seen people take snow days. Sometimes the estimates were simply too conservative, and sometimes all the remaining development tasks get blocked by external dependencies. Either way, team members find themselves with no open tasks to complete days before the end of the iteration and, instead of going to the team, the project manager, the tech lead, or the team customer to ask what they should work on next, they take a couple snow days. Of course they come to work and of course they do work, but they often spend the snow days on interesting but low priority tasks.

Mike, for example, does not get the data specs for the XML task from the folks in accounting, so instead he decides to fix an annoying font issue in the order screen. It’ll be a quick fix, he thinks, but the font issue turns out to be bound up in a larger issue with the screen so he starts refactoring and updating unit tests. Before he realizes it, Mike has sunk two days into a defect that was not in the iteration and is so low in the feature catalog that it probably would not be queued up for another three months. Meanwhile, Jane is behind on her work on the invoicing engine. She could have easily handed a couple days worth of tasks off to Mike. Instead, the team completes the iteration a couple effort days short and without either the invoice enhancements or the new accounting feed. The customer is not thrilled. The team is not happy with its performance. The team takes on additional work in the next iteration to make up for it and everyone puts in a little bit of overtime. It is a big deal.

Snow days are dangerous for two reasons. First, they produce waste, simply because whatever was worked on during the snow day most likely was not the next item of highest priority to the team customer. Second — as is the case in my example above — snow days can threaten the sustainable pace of the team. Even a handful of snow days can keep the team from hitting a high-profile release date. And even an agile team can find itself scrambling to make up for those ill-spent snow days as the deadline draws near.

Team members and project managers must be on guard against snow days. It may seem like a rather innocent transgression, but unlike the snow days of our childhood most snow days on agile teams need to be made up sooner or later.

Leave a Reply

To prove that you're not a bot, enter this code
Anti-Spam Image