Apparently we’ve been running Type A Scrum as defined by Jeff Sutherland in a paper from Agile 2005. He’s divided Scrum into 3 types:

• Type A Scrum – Everything is done in the Sprint, but there is downtime of a week or two between each Sprint.
• Type B Scrum – You start to overlap the product backlog definition for the next Sprint into each Sprint resulting in no real downtime between Sprints.
• Type C Scrum – Jeff Sutherland’s nirvana where you have overlapping Sprints.

Our experience so far is that we have been running Type A Scrum with gaps between each Sprint. I’ve had a lingering question over whether this was supposed to happen which this paper helps answer. Since we’re in early adoption and getting everyone up to speed this is pretty much expected, but it will be nice if we can evolve into a Type B Scrum without the time between Sprints.

Had an interesting discussion with my brother this morning. He happens to be yet another software developer in the family. Out of five brothers four of us ended up in programming. Probably related to our Dad’s early experiments with kit computers like our first Interact in 1979.

Anyway he sees the world a little differently and he’s working on studying up for the IEEE Software Developer Certification. He brought up this idea of preferring 100-200 line methods or functions that can be followed fairly easy. The idea of having a more object oriented approach with lots of small objects and simple responsibilities he referred to as Spaghetti OO’s code. He finds it quite difficult to follow the logic in such code because it’s always jumping around and you end up having to know too much about the design up front.

I can’t say a particularly agree with him on this one, but it does capture a sense I get in digging into some large OO code bases where I have trouble finding my way. You know the kind where if you tried to draw out an end to end slice through the system you’d end up with a sequence diagram that circled around the room. The point being is you can still get really convoluted with any approach. These days I only have one hard and fast rule for any of my code or any of my developer’s code:

• Can I unit test it.

If I need to sacrifice a little OO purity, I’m OK with that. And I’m still far from being some OO god, so I probably pull some procedural hacks without even realizing it. Heck, I still think Struts is a reasonable web framework given the current options, and it has a pretty solid procedural feel to it.

I came across a possible mock framework for JSF from the Shale team. Since I’m about to try helping my folks with some JSF projects and getting them to do actual TDD, this may be a big help.

There’s been quite a stir over some documentation on MSDN about how to do TDD with Visual Studio 2005. Essentially it advocated writing all your tests first for a a particular class and then starting to implement the tests and get them to pass one by one. Sort of Big Design Up Front with Tests. Gee, might as well do a lot of UML diagrams and get the same effect. Basically what they were advocating was a TDD anti-pattern.

Anyway the community spoke up pretty quickly and loudly including Michael Feathers, Ron Jeffries, James Shore, and others. So it’s gone now and this is the Microsoft explanation.

Fairly impressive that this got changed so quickly.

I’ve been playing around with Ruby a bit as a break from things. Pulled down a nice Eclipse plug-in today, Ruby Development Tools. Basically covers everything but auto-completion and refactorings. OK, those are pretty big things, but it’s nicer than BBEdit and a Ruby plugin.

I really like the fact that unit testing support is built into the base language.