Iteration Zero Team Charter

Simon Baker has a very good example of a team charter for an Agile project developed in Iteration Zero. It spells out how the team will do estimating, track progress, do TDD, implement continuous integration, and coding standards. This is the sort of example based template you can take and show your own team as a starting point. And apparently Simon also has very good whiteboard skills as evidenced by some of the pictures of his chartering mind maps.

The Agile Toolkit Podcast

It’s not the most updated technical podcast around, not the most polished sounding, and follows pretty much just an interview format, but I really like when the occasional new Agile Toolkit episode pops up. The host Bob Payne follows a simple format:

  • Attend a conference.
  • Corner as many good speakers as you can.
  • Get them to sit down for about 30 minutes and just talk.

Almost all the guests are from two conferences, Agile 2005 and No Fluff Just Stuff Northern Virgina 2006. The guests range from Bob Martin to Jared Richardson of Ship It!. I’m hoping Bob gets the chance to attend a few more conferences this year.

Sprint Without A Burndown Chart

I’ve been experimenting with leaving off a sprint burndown chart for the last two sprints on a project. Everything critical is tracked on a corkboard and I have a separate chart that shows where we are as far as moving content onto a new intranet. So far no one’s missed it.

Part of the reason for the lack of the burndown chart is that I no longer record the sprint backlog in Excel so I don’t get an easily generated chart. The other reason is I can’t see that it’s providing much value. Some Scrum Masters focus too much on the burndown and whether the team is above or below the line. The focus is on the artifact of the process and not what’s really going on with the team. If you hold daily meetings as a Scrum Master and you don’t already know about a real problem developing then you’re really not doing your job.

Release burndowns are valuable as a means of estimating approximately how many story points or ideal days the team is able to deliver for an average Sprint. Unfortunately until at least three Sprints are done this doesn’t tell you a whole lot either.

Ruby Versus Java Conventions

Having spent a long time almost exclusively coding Java since about 2001. I have some mental baggage when it comes to adjusting to Ruby. Excepting some tinkering in PHP and Python in the last five years I’ve primarily been living in an IDE with Java when I actually got to code.

I realize I have this bias, and I’m adjusting, but a small bug fix I submitted to RSpec shows that I still probably have more adjustment to do. The problem isn’t important, and in fact it was just a change to one line of code that was necessary.

The line of code was:

def method_missing(sym, *args, &block)
        if __is_sweetened? sym
          object = self
          calls = sym.to_s.split("_")
          while calls.length > 1
            call = calls.shift
            object = object.__send__(call)
            break if call == "be"
          end
          return object.__send__(calls.join("_"), *args, &block)
        end
        __orig_method_missing(sym, *args, &block)
      end

The important line is

1
break if call == "be"

. The context isn’t critical, but essentially it needed to add conditions to only break if the next element in the array wasn’t the strings ‘a’ or ‘an’. In my head I thought there was probably a nice clean Ruby way to do this, and heck Array has a lot of nice convenience methods, so I started there.

My first attempt came up as:

break if call == "be" && (calls.first != "a" || calls.first != "an")

I found the

1
first

method from Array and I liked that, but the rest of the conditional felt exactly like something I’d write in Java except it would have been:

break if call == "be" && (calls[0] != "a" || calls[0] != "an")

OK, time for a little refactoring for readability. Extract out the conditional to a method and give it a better name.

break if call == "be" && a_or_an_follows_be(calls)
...
def a_or_an_follows_be(calls)
  return (calls.first != "a" || calls.first != "an")
end

At this point I figured it was reasonable even if not probably the most Rubyesque. Luckily the new release of RSpec fixed this bug and I was able to see what they did:

break if call == "be" unless ["an","a"].include? calls[0]

Much more concise, I would have never thought of just using a simple two element array.

RSpec 0.5.14 Out

Yesterday I found a minor bug in RSpec 0.5.13. Today I got around to adding it to their RubyForge bugtracker complete with a suggested fix. Then I notice RSpec 0.5.14 just got released late tonight July 13, 2006. And there’s a release note on my bug being fixed:

1
* Sugar (underscores) now works correctly with should_be_a_kind_of and should_be_an_instance_of

The good thing is this is now a non-bug and RSpec appears to be pretty active right now.