lixo.org

Good old The Mythical Man-Month. Here’s Fred Brook’s description of one of the roles I am identifying and quite often find myself in lately:

The Toolsmith: File-editing, text-editing, and interactive debugging services are now readily available, so that a team will rarely need its own machine and machine-operating crew. But these services must be available with unquestionably satisfactory response and reliability; and the surgeon must be sole judge of the adequacy of the service available to him. He needs a toolsmith, responsible for ensuring this adequacy of the basic service and for constructing, maintaining, and upgrading special tools — mostly interactive computer services — needed by his team. Each team will need its own toolsmith, regardless of the excellence and reliability of any centrally provided service, for his job is to see to the tools needed or wanted by his surgeon, without regard to any other team’s needs. The tool-builder will often construct specialized utilities, catalogued procedures, macro libraries.

You don’t usually see “Toolsmith” in a business card (I reckon I’ve never), but I am starting to recognize it as a very distinct role in agile teams. More often than not, collective code ownership makes this role distributed across the team, so everyone ends up taking care of the development environment, and the point of this post is to bring this forward for discussion. I see the collective ownership of the tools and development environment as a good thing, but not necessarily in an ad-hoc way as I see in most projects I’ve worked on.

It’s important to keep in mind that the development envinroment for a project is, essentially, a system in production. It needs just as much attention and support as any other production system, and it’s fairly easy to spot the lack of it: painfully long and quite often broken builds, continuous integration systems not properly set up, manual steps sprinkled over any otherwise automatable task, inconsistent settings and software setups in the developer workstations and a list with several manual steps to set up a new one.

I came to the conclusion that every single step added to any continuously repeated task during the development process adds not only a burden to the developers, but increases the chance of failure massively. If the only thing you have to do in order to make sure you can check in your code into continuous integration is run one build script, there’s not much you can do to screw it up except not running it. Add another couple of steps to that, and the chances of something going wrong increase exponentially.

The difference between:

run build

And:

clean-database
start-webserver
run build

Is that you get a false negative every time you forget to clean-database or start-webserver. And you have to run it all over again, this time blaming yourself for being such a git. By this point, your attention span is gone and you’re thinking about a trip to the coffee machine. If this is currently happening on your team, you need a toolsmith.

I think retrospectives are the most informative and fun kind of meeting you can have with a bunch of software developers without involving large amounts of some kind of alcoholic beverage. Okay, maybe seconded by giving them a huge set of Scalextrics.

When doing retrospectives, the facilitator often chooses to do what’s called a ’safety check’. It’s about trying to get a feel for how much confidence there is in discussing the current topics with everyone else in the room. The facilitator gets everyone to write a number from 1 to 5 on a post-it note, anonimously, and sticks them up in a wall or whiteboard, tallying up the results. Usually, a safety level of 1 means ‘I don’t feel safe here, I’ll nod and agree to what everyone else says’ while 5 goes something like ‘I feel I can talk about anything and anyone in this room freely’, and that is a very important measure to have as it can completely change the discussion. Sometimes, asking a one or a few team members (project managers, for instance) to step out of the room can improve confidence, and everyone’s happy.

But what about the other measurements that may affect the effectiveness of a retrospective and work in general? My colleague Tim Mackinnon (get a blog!) brought a very nice idea to one of our monthly meetings this week: using the same mechanism to scale how much fun, productivity and enthusiasm people are having at work. If I had an equivalent of MS Paint on my Mac, I would amaze you all with my drawing skills, but for now, picture this: you draw as many axes you want on a whiteboard, ideally three or five, as choosing an even number can look a bit confusing. Each axis represents some measurement you want - fun, safety, productivity, effectiveness, collaboration, you name it. And get everyone to tick their level on those, preferrably anonimously.

I’m still yet to be a facilitator on a retrospective, but I’ll be definitely trying this out.

Oh, and if you’re interested in the subject, make sure you’re subscribed to Pat Kua’s blog. He has some very interesting thoughts on timelines and other retrospective tools.