Exploring 'Done' and Pairing
Today's challenge was a two-part discussion.
Part One: How do we define "done" when talking about story cards?
We've had our share of challenges dealing with cards that were put in the "done" stack, but were not considered done by all members of the team. This is an issue that seems to be common with agile teams: how do you know it's done?
I borrowed a bit from Retrospectives (which we'll be doing later today), laid out the framework for our discussion, and asked the team to start throwing out items that would help us to qualify cards as done. After we had about 20 items on the board, we talked about them to make sure that all team members had a clear understanding of what was meant by each one. We then went through two different mechanisms to determine which ones the team felt should be included in our initial definition of done: registering preference/priority by putting dots by the ones they chose; using thumbs up/thumbs down to vote.
At the end of the process, we had 10 items, as follows:
- Acceptance criteria are met
- Automated tests, including unit tests, are written, checked in, run, and passed
- Code is paired on or reviewed
- Code is checked in to the repository
- Customer approves it (Gary or Doc)
- Automated scenario tests for acceptance criteria are written, checked-in, run, and passed
- Documentation is produced and/or updated for behaviors and user guides
- Project builds without errors
- Code is clean
- Procedures are documented
Clearly, this will be iterative and evolutionary. Regardless, I, for one, feel much better knowing that we now have initial agreement on where we begin. From now on, all cards will be evaluated against at least these criteria to determine if they are done. It's no longer guesswork, shared understanding (although there is some), or arbitrariness.
Part Two: Pairing
As a result of attending Agile2007 and my experience here at Dovetail Software, I was feeling uncomfortable. The discomfort stemmed from my perception that my team was not clear about what we're doing regarding pairing. Yes, there's pairing going on. It's not consistent, the changes of partners is sometimes-yes-sometimes-no, sometimes pairs stay together for a full iteration or more, and I'm convinced that we're losing some of the learning-value of pairing in the process.
My understanding - and belief - is that all members of the team will benefit from more frequent changes of pairs. Knowledge and skill will thereby get passed around, and the resulting increase in quality and productivity will benefit all. I don't see that happening yet. So I asked for a discussion.
First, I shared Arlo Belshee's paper Promiscuous Pairing and Beginner's Mind. Arlo presents the results of various experimentation that his team did, including being rigorous in their use of metrics. I recommend the paper to all. We talked about how much of each day should be spent pairing, how long each pair should stay together, the use of ping-pong pairing, and other topics.
Unfortunately, the first topic - "done" - had taken 90 of our 120 minutes, so this discussion had to be very focused since I'd committed to ending on time.
I'll jump right to the net - we agreed to practice ping-pong pairing for one full iteration, in order to learn from the practice, and to shoot for changing pairs at least once per 24 hours. There's clearly more to discuss.
