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.

We held our second code review this Friday. Two months between holding code reviews is a little long, but we’re still working out the process. Some things to remember for next time:

• Prepare for the code review ahead of time. This code review was being held towards the end of the Sprint, so the afternoon before we got it arranged. Some review is better than none, but the code review ended up being more of a code walk-through.
• Adding a static analyzer like Checkstyle really helps with keeping the code clean. Since the developers had spent a good bit of time working down 150+ Checkstyle warnings to 9 there were very few basic defects, like one character variable names, or really long methods.
• Figure out a better way to do followup. After 90 minutes we had a number of items to fix, but since they were handwritten notes by all the participants it will be a bit difficult to check up on. We may get a chance to use a tool like Crucible the next time around.
• Next time don’t even hold the review until all the classes covered have tests. Two of the reviewed classes had zero test coverage.

On the positive side we found quite a few subtle defects in 90 minutes from cut and paste errors to iterating over collections that only had one item. I think the three of us were all in agreement that having new pairs of eyes on the code was really helpful in catching some things.