Even though my last day at Vianet was last Friday, I’ve been coming in to entangle my personal internet in their tubes. There’s a lot of coordination back to the States to ensure everything is hunky-dory and I have found Skype to be invaluable, as well as the free connection in the office.

Looking over at the highly visible sprint burndown and release takeoff white board, I noticed that nobody had plotted story points finished for the week. Asking around it was discovered that 5 points had been finished. There is a very daunting 31 points remaining. Daunting because the team’s highest output in any week has been 13 points and that was with one extra developer (me).

Next to the status board is a very large white board on wheels, the sprint board. Taking a quick look at this it appeared the first, and therefore most important 13 point story, was still not finished. It looked stalled while the third 5 point story on the board had a task in progress. The 5 point finished story had been a lower priority still.

Not able to help myself, I asked why so many things were in progress, with so little finished. After all, the team was more than half-way through the sprint, 5 days down and 3 to go. There’s a holiday on Monday, cutting an extra day out.

By this time the team had started to gather around and look at the situation. They started to explain that all that was left on the first story was some functional testing, but it had been parked. The functional testing task had been parked because a fix was needed on the feature that would break the test.

The bug had been found by the Director of Business Development the day before. He is also the original developer for the company, and felt that it would take no time for him to fix it, or explain the fix to someone else to make. Trouble was, he was in meeting all day with the CEO and some others, so had no time to fix, pair program, nor let anyone know what the trouble was.

The Director wants to step away from development, something the team also wants. Our last retrospective walked through a feature the Director had been involved in developing, and which wasn’t exactly smoothly delivered. After this, the Director had decided he was through with coding and in planning informed the team he would not be available in this, or any other sprint, for coding.

The bug was found within the same feature which wasn’t delivered smoothly. It’s possible he felt he needed to take ownership and fix it. But he’s a director and really doesn’t have the time. Plus he is not a member of the development team, taking away their autonomy and ability to commit.

I started asking the team about this, and other things to draw out action. Do you think it’s fair that someone not committed to the sprint is holding you up? What have we stated we would do when a bug is surfaced within the sprint? How do you feel about finishing the work remaining with only three days left?

Finally, the team decided it was critical enough to stop the line and interrupt the meeting the director was currently in. He took some time to explain the issue to the team.

They were able to continue on with the functional testing, putting in some boundary tests explicitly for the trouble found. The test would continue to fail until the fix was in, but his ability to finish the task was unblocked. Testing would also be the sanity check for the refactoring needed to fix the problem. A re-estimate of the time needed to finish was made, some analysis done, and the line restarted.

Hopefully the team will be able to finish all the work committed to in this sprint. They were awfully close to counting in 13 more points for the first week, if it hadn’t been for this impediment. Maybe they will start to believe it is not just standing up and catch these things a little closer to when the issue is first discovered.