Goals in a typical Sprint:

• One Sprint goal provides a focus.
• Each backlog item is another smaller goal.
• Each day a developer commits to a small task based goal for that day.

Plenty of goals. Unfortunately we’ve also adopted an idea of interim goals on our 30 day Sprints. The idea started out as a device to help teams new to Scrum make sure they didn’t set off on cruise control and then scramble at the end of the Sprint. The idea was with an interim goal the team would make sure to jump in and work hard right away.

I think the whole interim goal was an OK experiment, but I also think it might work just as well to do 2 week iterations. The point was to use them while teams got up to speed. After everyone is used to working within a Sprint they don’t serve much of a purpose.

Today on a project after we made the interim goal it was suggested that we have an interim interim goal between now and the end of the Sprint. Two of the developers bluntly said no and eventually the whole team shot the idea down. Their snappy comeback involved just asking how that was going to add value. This is always a good question.

The whole point of a self-managing, collocated team meeting in a standup to sync at least once a day is that if some coordination needs to happen it can take place ad-hoc. Creating a goal around it and taping it to the wall doesn’t add any value.

You’re called in to help troubleshoot a problem. You get very little background. They worship you’re technical abilities and figure you can fix any problem in a few hours. The reality is they may have a problem you’ve never seen before and that you can’t fix in a few hours or maybe even a few days.

Another reason I don’t miss the professional services world quite so much.

Transparency or inspect and adapt is central idea in Scrum. When you start breaking windows on a project you get:

• A developer had 2 hours for actual coding and 14 hours for defect resolution on a single feature. When prodded the developer admitted that they really didn’t expect any defects, but the actual coding would probably take about two days along with some needed refactoring. Rather than explain that this simple feature would take over two days of coding because it involved a lot of design changes the choice was to hide the work in defect resolution. My reading, not knowing better, was you were going to slam some crap code in about 2 hours and then you expected a lot of defects. Instead this developer was doing the right thing, but not letting the product owner really know what was going on. The developer felt like they needed to have some buffer time to maintain the quality of the code, but they felt guilty trying to explain that to the product owner and Scrum Master.
• Product owner only informs management that a decision has been made on running a 30 versus 35 day iteration. The team has to find out about the decision days later from their own management chain. Self managing teams have a really hard time when important decisions take place without their input and even then decisions are only slowly leaked out.
• On some teams they don’t have impediments anymore. They still have them, but they’ve assumed that no on will act on the problems so they just take them for granted. Thus they may be waiting on someone so they can move forward, but they don’t even bring it up and suffer in silence.

As with many techies I did some tech support for myself and relatives over the weekend:

• Setup my in-laws backup solution to an external hard drive and did their first full backups. This took some time just because backing up about 200GB across two machines isn’t that fast.
• Setup a wireless network for my in-laws. Super simple since they just bought an Airport Express at a garage sale. Plug it in, and do a reset and we’re done. Five minutes tops.
• Finally upgraded from WordPress 1.5 to 2.0. Not much in the way of a difference, but at least I can feel a little more secure I’m not open to a host of security bugs.

At midnight I may celebrate by writing Hello World in Haskell.

As a bonus Xmas gift this week, I completed my part of a code review of a developer’s code before heading out Friday. The code review primarily covered a JSF backing bean/controller and a corresponding test case. Even though the tests had mostly been written after the test case was just a joy to read:

• Clear test names.
• Only 2-4 lines of code for most of the tests.
• Thorough testing of negative conditions like <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">

  1	testDuplicateRefundsOnlyCountOnce()

  </div>

  .</li>

  • 99% unit test coverage according to Clover.</ul>

  The only thing I was able to catch was a

  1	printLines()

  method that had been used when writing the tests to output something to the console. The method was still hanging around and didn’t actually do anything because the

  1	System.out.println()s

  had already been removed.