I read Larry Osterman’s post on Measuring Testers by Test Metrics Doesn’t via The Best Software Writing Vol I. It reminded me of a failed experience from about a year ago on a death march project.

The scenario was simple enough. Our large project had been underway for 2.5 years and had been in defect resolution for at least 1.5 years (Death March). Thus we had well north of 1000+ defects and were constantly falling behind on getting them resolved.

Given this one of our senior developers suggested maybe utilizing an oft forgotten field in our Mercury TestDirector bug tracker might really motivate faster bug fixing. The field was

and wasn’t required so it was generally left blank. The suggestion was to bring it up at our daily stand ups and explain that going forward all the developers should fill this out on their new defects with real estimates.

Not a bad idea in principle. Developers have to estimate the time for their assigned bugs and then they’ll naturally want to fix the defects within that timeframe. Guilt and professional pride will help re-motivate the developers on this great death march. So here’s what happened:

• Developers started reluctantly putting in estimated fix times.
• Most of those times were in multiples of 8 hours since it was easier to estimate in days and historically many of the defects required a lot of negotiation since they were really requirement changes or clarifications.
• This was a death march project so no one felt all that guilty if they didn’t manage to hit some estimated fix time estimate.
• Everyone stopped filling out the field again within a few weeks because it wasn’t required.

So again it reinforced the lesson that trying to drive behavior with metrics is likely to be a failed effort. I still like metrics, but mostly as a source of feedback. Negative reinforcement with a single statistic tends to fail or lead to gaming the system.

Howard van Rooijen recently posted about a thread on the Scrum users group. In the thread by Ken Schwaber explains that:

I’ve been following the threads about type N, A, B, C and advanced Scrum. Although these may represent the engineering, personnel, and product management practices that an organization adopts as a result of Scrum’s inspect and adapt, they aren’t Scrum. I think we are mistaking the consequences of Scrum with Scrum itself.

What may be most destructive about these supposed extensions is that they will divert people from the real work of Scrum … seeing what is going on in their organization and going through the change process to become effective. And learning how to continually inspect and adapt to keep their organization’s practices optimal. Instead, people may think that all of these things that use the Scrum name are advances in Scrum, templates that they can mimic and then, amazingly, they are advanced development organizations, also.

We are running the danger of any small process. People want to make it bigger. Well, Scrum isn’t bigger. Each organization’s total ability to build complex products is certainly bigger, and hopefully continually evolving, but it isn’t Scrum.

Keep Scrum Simple.

Ken

Ken’s whole point is Scrum is designed to be a lightweight, barely there process. Trying to elaborate on it and define different styles sort of misses the point. Keep the process as simple as possible and let people figure out how to adapt it to their teams and organizations.

I think my greatest realizations of Scrum have been its ability to reveal organizational problems and bring them up into the light. Now, we haven’t been able to change all of them for the better, but we have been able to adapt.

We’re working through an organizational impediment on one of our Scrum projects. The developers on a project are being blocked from completing their tasks by lack of access to a development server. A policy exists that gives only one or two people in the organization access to make changes on the development server. Scrum has made this inefficiency readily apparent in short order. I expect tomorrow we’ll have worked out some form of solution.

Despite being an incredibly simple process that Mike Cohn can describe in a small diagram, Scrum is full of nuances. We’re constantly inspecting and adapting how we do things in Scrum and I don’t want to get caught up in which form of Scrum we’re using.

I’ve been running weekly 30 minute one-on-ones with all of my team for about two months now. With these meetings in place I go no longer than one week between giving and getting feedback from each employee.

Doesn’t sound like much. Like most managers I assumed I probably talked to all of my staff every week. What I often didn’t take into account is I didn’t always check in with everyone on a weekly basis. With the more self-directed employees or the slightly more introverted ones I only had brief discussions in the cube or hallways or maybe at the end of a meeting.

Turns out rapid feedback loops, even 30 minutes once a week, allow your employees notify you when things are a bit off course. Maybe they’re underutilized on a project or frustrated with a work situation. Maximum time to find out is one week on something like this. Sure, some employees will bring this your attention sooner, and they probably should, but having a regular discourse guarantees your employees have a chance to inform you.

In the last two weeks this feedback loop helped me become aware and fix two situations that were really demotivating several employees. There’s really nothing better than a re-motivated employee. So so far the one on ones are paying significant dividends.

Crucible, a code review tool from fine folks at Cenqua, is finally closing in on a real beta release. (Disclaimer we’re already use Cenqua’s Clover product.) I talked to Brendan from Cenqua at SD West 2006, and he explained that Crucible was supposed to be Cenqua’s second project after Clover. Turns out Fisheye was a lot more popular than they anticipated. Thus Crucible got pushed back.

It’s still not quite beta ready, maybe early next month, but it looks like it may really fit the bill for our needs with a simple lightweight code review process. It sits on top of Fisheye their CVS/Subversion browsing product.

Some nice features they bravely previewed for us:

• AJAX style commenting while browsing code for the review.
• Very simple workflow with email/RSS notifications.
• Nice defaults for the attributes. If my memory serves right there were only two types of severity to an issue in the code <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">

  1

  major

  </div>

  or

  1

  minor

  .</li> </ul>

  The really nice thing is it didn’t try to do anything more. Simple is generally better on features especially when we’re trying to have lightweight code reviews. I’ll probably post again on it after getting a chance to play with a future beta.

Walk before you run. So even in a TDD framework approach like Rails the concept of TDD is only approached and explained on page 169 of Agile Web Development with Rails. And even in a chapter on testing we begin with writing functional database style unit tests, and then functional style tests against the controllers. Finally, on page 169, we’re introduced to test driven development.

I don’t fault the writers of Agile Web Development with Rails for the approach and certainly not Mike Clark who has made important contributions to TDD and is extremely lucid technical writer. I fault the current level of adoption of TDD.

I think the authors made a reasonable assumption that many of their reader base wouldn’t be familiar with TDD. Thus you get through building the example application before you bring up the subject of testing. Since many readers come from backgrounds like PHP it is unlikely they’ve ever touched a unit test framework or tool before.

I still would have enjoyed if they blazed a trail and started out doing TDD. Just gone ahead and explained the approach in chapter one and then used it to build the example application. This would have forced a title change like Test Driven Development with Rails since the only books that cover the TDD approach up front have TDD somewhere in the title like Test Driven Development: A Practical Guide.

Maybe in the next few years we’ll see technical books that aren’t on TDD, that just use TDD in the examples by default.