Apologies for the delay since the last installment of this series – I’ve been pretty busy with work and moving country. 🙂
Daily Practices
Our daily practices worked out well, and were pretty simple, so I wanted to describe them.
The day would start at 9:30 with a team stand-up. People present would be the entire project team (the 10 devs, 1 PM, 2 BAs and tester), plus anyone we were also working with at the time (e.g. we would occasionally have iterations where a reporting specialist would work with us.) Also the department coach would drop in every now and then. The initial stand-up would last about 10 minutes, by going around the team one-by-one (we would stand in a circle) and people reporting what they did yesterday and any particular problems they hit. Deeply tech problems would be mentioned but not described heavily. Since we paired, often the first person in the circle would decribe the activity, and the second person would just say ‘What Bob said’, and that would be considered perfectly OK.
Lesson 4 : Keep your stand-up meetings short, and allow the whole team to talk about what they’ve been up to
After the main stand-up, the developers would remain for a brief ‘tech stand-up’. About 1 in 3 times we would spend time quickly discussing any tech issues that arose from the main stand up. With that over, we would do pair-up and story-distribution. This basically worked as follows:
– If a pair from the previous day were near to completion and/or had only just started pairing they would often stay paired and stay on the same card.
– The remaining people would pair up normally with a different pair and often with someone that they hadn’t paired with for a while.
– For any started, but incomplete, stories being worked on at least one member of the pair would always have worked on the story the previous day.
– If people remained after all started but incomplete cards had been distributed, new stories would be distributed according to priority set in the IPM.
– We would normally have one pair assigned to bugs.
If stories were completed in the middle of the day, we might iterate the above process with a few people on the team. For example, pair rotation could happen during the day, and new stories could be started during the day.
The important point that is not mentioned here is anything about ‘story ownership’. I’ve often seen projects where each story is ‘owned’ by a particular developer for a particular iteration. I really don’t understand the value in this and believe it to be the sign of either a micro-managing PM or a development team that doesn’t have internal trust. The developers should be jointly responsible for all stories in an iteration. If the iteration is running slow, it is the team’s, not an individual’s, responsiblity to pick up the slack where required.
I actually think ‘individual ownership’ is damaging. Consider the following:
– If there are people on the team that have specific knowledge about an area that no-one else has, it is the team’s responsiblity to spread that knowledge around – individual sign-up is not going to encourage the team to start picking up specialized tasks and so knowledge sharing is limited.
– What does individual responsiblity mean? I’ve heard of some projects where it means that if a story is running behind in an iteration it is that individual’s responsiblity to pick up the slack, if necessary by working weekends. This is terrible for team morale.
– Individual sign-up hinders pair rotation. Consider a story that takes 3 days to implement. If one specific person has to work on that card every day, a maximum of 4 people will work on that card. If the ideas above are used instead, 5 people could work on that card. This means more rotation and more common knowledge in the team.
– It doesn’t fit with prioritisation. The 2 most important cards in an iteration should be the 2 that are worked on first. If these 2 cards are both ‘owned’ by the same individual, one is likely to be pushed back in the iteration and therefore is less likely to be completed.
Lesson 5 : Don’t do individual story sign-up. Instead allocate stories on at least a daily basis, keeping priority stories up the stack, and pair rotation a continual activty.
Mike Roberts