Re: [scrumdevelopment] splitting a team (was: Replacing a SM at an existing team)
- Hi John
I am not sure if I can answer your questions, because my coaching mandate at this company has ended, so I may not have all the details about what happened next correct. There were other factors, e.g. some vacations in the following sprint, so the teams were smaller still, and the people involved are still puzzling over whether they have understood all the causes and effects. So WIP - use results with caution.
Both the ScrumMaster and I advised the P-O on the split, first recommending against imposing the split, then if he is going to impose a split, then to tread carefully. 'Tread lightly' I think was good advice.
A team develops a team spirit: the cohesion which makes it effective as a team. Asking the team members to re-form themselves as new teams is asking them to reject themselves and that cohesion, which, in retrospect, I don't think is something you can/should expect a team to do.
I think it was important not to be seen as taking over the team or calling the self organization into question. The P-O did not assign roles in the team or assume an active role in directing the team, both of which he had wanted to do. He did provide an initial composition for the new teams, but left the teams free to rearrange themselves as they saw fit. So all he did was change the container, but did not reimpose traditional management practices, which would have been a disaster.
BTW - there is a case study for Guidewire on my blog. According to the study, Guidewire discoved the optimal team size for their company was between 3 and 6 people. So they set a rule: when a team reaches 6 people, it splits into two teams of three. (The ScrumMaster role rotates within the team every sprint). This becomes part of the context in which the teams function. Since presumably teams split often, it is something that they expect, plan for and deal with.
On 16.04.10 03:48, John Stoneham wrote:
On Mon, Apr 12, 2010 at 2:38 AM, Peter Stevens (calendar)
<peterstev@gmail. com> wrote:
> Eventually the PO insisted. He did take advice from his lame duck ScrumMaster and Scrum Coach on how to do it, but he did impose the split. (They started phasing out the ScrumMaster, I think, one sprint before the split). In the first sprint after the split, the team basically doubled its performance. Everybody found it to be a good idea and noone wanted to go back.
> A team is not well positioned to determine if changes in its composition will be beneficial. This may be a job for management.
So here's a point my team's been considering, given that we've just
hit 8 developers, the minimum amount I'd consider would be worth a
split. (We're looking at doing frequent-personnel- exchange feature
teams of 4.) I see a benefit in focus and communication efficiency but
a potential harm in whole-code-base knowledge and situational
awareness. It could help more leadership emerge, or we could see one
Having so much invested in this team and this product, I'm having
trouble getting an unbiased view. Right now I'm struggling for the
team to be able to make its own decision on this. (Management wants to
see the team split into O&M versus new development. I think that's a
recipe for disaster.)
What made your split a success? Why was the team resistant? How did it
happen in such a way that it was viewed positively?