Duncan Pierce duncanpierce.org

The morning stand-up meeting is one of the well-known features of XP (though oddly not a “practice”). A few years ago I worked for Connextra, one of the XP pioneers in the UK, and over the years I’ve come to realize there was an important difference about our stand-ups - something I haven’t seen anywhere else.

The standard stand-up meeting consists of a quick round-up of what everyone was working on yesterday, and what they expect to be working on today. Any important team news is also disseminated in the stand-up. Stand-up meetings are intended to be very short, which is why everyone stands up (you’d get tired if the meeting went on for a long time).

At Connextra we did things slightly differently, but it had very different consequences. We did the usual review of yesterday’s progress, and we talked about our planning board and the completion status of the stories on it. What we did differently was to examine the work we were continuing from the previous day, and new work to be started that day and talk about who would work on those things.

We paired up with the following goals.

• To pass on and update knowledge about the system. A person who had not worked on part of the system for a long time would work with someone who had worked on it recently to increase working knowledge in the team.
• To bring a fresh approach to “stuck” problems. When a pair had been working for a while on a problem that just seemed stuck we would rotate out one of the people and bring in someone new to look at it. Bringing in fresh ideas like this usually helped to prevent prolonged stalls.
• To apply specialist knowledge to difficult problems. For example, I often worked on “emergent phenomena” bugs like threading or resource allocation problems because I’m good at solving them. By pairing with someone who already has an understanding of what the problem is, we can solve it much more quickly together.
• To spread the tedium of some of the less interesting work around within the team. It depends on the system, but even the most exciting projects involve some pretty tiresome tasks. Sharing the burden across the team helps keep everyone sane and functioning normally.

What we got from this that other teams usually miss is a greater degree of team “ownership” of the project, and much more efficient use of our personal resources. We were also able to keep a stronger architectural vision of the system in place, because we were able to identify from the level of discussion in the stand-up what issues affected the system in fundamental ways, and resolve them collectively, rather than one or two people making significant decisions for the team.

Every other team I’ve seen so far tends to allow people to make personal decisions about what they will work on. We made team decisions, and this is something I encourage every team to do.