We
added rolling ownership to our
pair-programming back in April 2008 and we've been using it since.
Rolling ownership enables as many people as possible to get
involved in delivering a story. When a new story is started,
someone volunteers to own it and another person volunteers to pair
in. They work on the story until lunchtime. After lunch, the pairs
swap. For each story in progress, the owner moves off the story
passing ownership to his morning partner and a new volunteer steps
in to pair. This rolling effect allows tacit knowledge of the story
to be retained across pair-swaps. When each person owns a story
they add their initials to the right-hand side of the card.
Repeated everyday, most, if not all, of the team play a part in
delivering each story. We've found that rolling ownership
facilitates shared learning and decision-making, helps spread
knowledge of the product around the team, and the pair-swaps and
shifting ownership keeps people communicating.
Tuesday, 20 October 2009
Rolling ownership of stories through the team
Posted by Simon Baker - Permalink
8 Comments
I wonder if swapping the stories mid day feels like too much multi-tasking though? Half day is not a very long time to really build a focus on something you are implementing?
I'm curious - how long does it take to complete an average story? I'm trying to get a feel for the size of your stories.
It feels my stories are smaller as I like to complete a story in a day.
That's a fair comment and it had crossed our minds before we tried it. But, it works for us.
So does that imply a team size of 2? - Based on "most, if not all, of the team play a part in delivering each story"
On average, less than 2 days. The only estimation we do is to ask "can we do the story in less than 2 days?" and if we can't the story is split.
Sorry hit return too soon (should pair on comments!)
Should have been team size of 4?
2 People before lunch
+ 1 person after lunch
+ plus 1 possible person the next day.
Team had 6 developers. If a story took exactly 2 days, 4 of the developers would've been involved. Using vertical slicing, the testers, product owner and designers would also have been involved throughout.
Within a team of 4, we tried swapping pairs after each 4 - pomodoro block. The point where we decided what the new pairing were doing next became an informal stand-up.
We also did find that pomodoro discipline, and pair swapping discipline tended to wane towards the end of the day, so we didn't usually meet our target of everybody pairing for 4 poms with everybody else.
I'm not sure how changing at lunchtime would work for us because we tend to get to saunter into work between 10 and 11, so the morning is a lot shorter than the afternoon!