Tea-Driven Development

Estimate: an approximate calculation of quantity or degree or worth

Commitment: the act of binding yourself (intellectually or emotionally) to a course of action

• Estimates are not commitments.
• Plans based only on estimates are bad plans.
• Commitments based only on estimates are at best foolish, at worst dishonest.

Estimates are certainly a useful tool for making realistic commitments, but there are many others too that are equally, if not more, useful. Working at a sustainable pace, measuring data about past performance, and facilitating the genuine consensus of the whole team when committing are the way to make plans that can actually be achieved.

A few weeks ago I bumped into Chris Matts and thanked him for the ‘Real Options’ session he’d lead at SPA last year. I promised write up this little story about what I took out of it.

When I got back from the conference, my team were at a point where we had to chose between two competing technologies to build something. Looking at the two options, we really didn’t know which one to go for: they both had advantages, and at that time they were both unknowns to us. Wearing my new ‘options thinking’ hat, I realised that we didn’t need to choose at this point: in fact, making a punt right now would be downright irresponsible: we didn’t have enough information to make the decision properly.

So instead of using my ‘gut feel’ to pick one of the competing options like a real hero would, I did a much more pragmatic, but less intuitive thing: I decided we would do both, until it became clear which one was the right one to pick.

We were lucky that our constraints at this point were time, rather than cost, so we could afford the luxury of having two streams of work going on in parallel, knowing that one would eventually be thrown away. Obviously the hidden deliverable even from that throwaway stream would still be a developer or two who understood the problem domain really well, and with a new technology in their toolbox to use in the future.

A week later it was much clearer which of the options we should pick, and the other workstream was stopped. And everyone lived happily ever after

Update: If you want to know more about real options, read Chris’ article on InfoQ here.

I’m just back from this year’s XP Day, London. Thanks to everyone who came and packed out the room to hear Rob and I talking about our experiences evolving our team from Scrum to Kanban. The slides are here.

There’s also a great transcript of the talk here on Tom Hume’s blog. Thanks Tom!

A while back, I asked the Cucumber team for the ability to call in the steps of one scenario from another.

The canonical example of this is the ‘log in’ scenario:

Scenario: User logs in
  Given there is a User whose username is "matt"
  And I follow "log in"
  And I enter "matt" in "username"
  And I enter the User's password in "password"
  And I press "Log In"
  Then I should be logged in
  And I should see the text "Hello matt"

Phew. Now obviously I don’t want all this noise in the scenario every time I specify behaviour that requires a logged in user. I want to write something like this:

Scenario: User views their dashboard
  Given I am logged in
  And I follow the "dashboard" link
  Then I should see "This is your dashboard"

Thanks to the fabulous creativity of the Cucumber community, this is now possible. It’s also highly recommended, as it’s a great way to help you keep your step files tidy and DRY of excess duplication.

Given /I am logged in/ do
  Given "there is a User"
  Given "I follow \"log in\""
  Given "I enter \"#{User.first.username}\" in \"username\""
  Given "I enter \"#{User.first.password}\" in \"password\""
  Given "I press \"Log In\""
end

I’m doing this more and more now - writing simple ‘building block’ steps and assembling them to make steps that read nicely and make sense to the stakeholders.

Pair programming brings a great many benefits to a team that’s truly mastered it.

Those of us who are lucky enough to have experienced working on a really effective XP team know about that almost magical thing that starts to happen when the barriers between different members of the team break down, egos and code ownership are cast aside, and the team starts to evolve the codebase as one, mighty, coding machine. It’s truly a joy to be a part of, or even just to watch.

Continue Reading »

Last weekend I was at CITCON Europe, a great opportunity to meet some of the leading minds in the agile software movement. One intriguing new term I heard a few times was “value fetish”. Let me try to explain what I think it means, and discuss the implications for agile teams.

Continue Reading »

One of the several great things about working for my current client is that their high public profile means it’s reasonably easy to get interesting people to come and visit us from time to time.

Last week the mighty Martin Fowler dropped by to talk to us.

Continue Reading »

I facilitated our regular end-of-iteration retrospective last week, and although the feedback from the team was positive, I was left with a feeling that something wasn’t right.

With our second major live release looming large on the horizon, I focussed the session on the theme of ‘Success’. My aim was to give the team a blueprint for a successful iteration to keep in mind when things were tough, and to help ensure that we were all pulling in the same direction by agreeing as a team what constitutes success for us.

Continue Reading »