That Calm Before the What?

Today was an oddly relaxing day at work. Tomorrow will be the last sprint demo of the year, and my team and I are pretty confident about the results.

However, it’s always a strange feeling you get so close before the finish line. You half expect something big to show up and show its nasty face, just like it happened last time – and that wasn’t a great experience.

But today I realized there are a few things you gotta learn to stay at least half relaxed through the whole Scrum thing. 

First, I’m sure that no matter how well everything is going, you always expect something big to happen at the very last minute. We had three bugs popping up in the last 48 hours and dealt differently with each of them:

  • The first one was fixed by a developer yesterday evening and had unforeseen consequences. Basically, the original bug was fixed, but in its place a new bug appeared. Since the developer is on annual leave for the rest of the year, we decided to roll back the changes and get back to it in 2010. The original bug really was an edge case „only-happens-when-somebody-screws-with-security-settings-anyway“, so it seemed like the right call to get everything back to how it was before and tackle the problem with fresh energy.
  • The second bug turned out to be an already known bug in slightly different clothes, so we could move it to a different team’s queue and just check it off our to-do-list.
  • The third bug was brought to our attention by someone from another Scrum team and that one was also moved to the queue of bugs to fix in the new year. It actually was something left over from the sprint before this one. Plus, another developer on my team was smart enough to whip up a small test project and realized that it actually was a bug in the standard Silverlight control, and not in our code, so the solution might be to just file a bug report with the Silverlight guys.

What I’m trying to say is that the first thing I tried to find out about each problem is whether it would affect the sprint demo. In each of these cases the answer was „no“. Yes, some of these bugs need fixing, but none of them were critical and rather than letting panic reign the day before the demo, we decided to just keep our cool and assess the importance of each bug.

And yes, each bug fixed is a good thing. But sometimes, a bug hastily fixed in time for a demo is no good at all. We learned our lesson the hard way four weeks ago and we all agreed we would never make that mistake again.

So I’m still crossing my fingers and hope that we didn’t miss anything big. And I realized that I need to get used to the feeling to be afraid to have missed something. Apparently it doesn’t go away. However, if you learn how to deal with it, it’s not that bad. First, accept that this is how you feel if you care for what your team has done. Second, let go of the little things. There will always be bugs. But, if you’ve done a good job, there will be less.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert