22173Re: Self organization. How?
- Jun 26, 2007Hi,
> Let's say you are working in a company that is adopting Scrum. YouUltimately that is up to the team to decide, but I see you're looking
> are in the middle of a multi year project
> on a team of 25+ developers. You've been "doing Scum" for several
> months but it's just not clicking with this large team. Team size has
> been identified as an issue in the Retrospective. The team wants to
> split up into smaller teams but is having trouble seeing how.
for options for the team, which is exactly what I see the SM should be
First of all, I think it would be good to keep in mind that the team
structure need not be permanent. If necessary, the teams can
reorganize every sprint. Also, if the cost of splitting up is too
high, stay as one team even if it has its own drawbacks.
I've seen suggested that the teams should try to find logical
functional splits to minimize decoupling between teams'
responsibilities. It could also be logical split between stories
within one sprint. You might want to trial different team
configurations, and see what works and what not. Encourage the team to
test organizations and then tune based on practical experience. Some
ideas need iteration to get right (they tend to be the more difficult
> What issues might arise if 3-5 teams share a product owner and aYou might want to consider having a separate SM for each team. That
> ScrumMaster? Would it be best to have a PBL for each team or is it
> light weight enough to share a PBL? Would it be best to have separate
> scrums, planning meetings, reviews and retrospectives?
way they can have "local" SM presense.
I would not recommend separate sprint planning meetings (the first
part with customer), reviews and retrospectives. Those important to be
held as the whole project team. The second part of sprint planning and
daily scrums would be specific to each team. And then there would be
the Scrum of Scrums to which each team would daily send their
representatives to keep the teams communicating.
For some reason I recall that Henrik Kniberg did discuss the issue of
how to do sprint planning with multiple teams, but I can't find the
topic with a quick browse of his excellent Scrum and XP from the
since it's just such a good read :) ). Maybe you have better luck.
Anyway, I think it went something like this. In the first part of the
sprint planning meeting, the project team would discuss the top
priority items and each team would then select (in co-operation with
other teams and the product owner) stories for themselves. After each
team is fully committed, they would do one more discussion round
whether this split would be okay, or they should do some shuffling
around. This shuffling might include either stories or people
transferring between the teams.
Anyway, this is a very interesting topic, so I would gladly read
practical experiences from other people who've solved the issue in
> Another challenge is silos of knowledge. With one large team, therePose this as a challenge to the team and ask them how they would solve
> are "go-to guys" for specific features. For example, one developer
> practically owns the data access layer. This makes it difficult to
> see a logical way to form the teams because this developer "needs" to
> be on all teams. An obvious solution is pair programming to spread
> the knowledge. Are there any other possible solutions?
the situation. Ask what they would do if this one person is sick or
otherwise absent? How are they going to ensure that they can still
complete their spring commitments. It _IS_ their responsibility as a
self-managing team. They might suggest sharing knowledge through pair
programming, or sharing the person (and the possible deputy) between
teams based on greatest need in each sprint. It's really up to them.
Actually, maybe you could make this "silos" thing a topic in one
retrospective, and have them work out a strategy and actions to handle
it. Of course, start up with a question "do you see <this and that> a
risk or a problem for you in the future?" :). If they think it's not a
problem, pose situations where the risk could materialize (like the
ones I gave above) and maybe they can see the risk (or you realize
through the discussion that they already have mitigated the risk).
As to possible solutions, some have mentioned that Dojos are a good
way of sharing the knowledge. Could be. :)
> Another wrinkle... There used to be 3 teams that were not selfPossibly very true. You replaced one problem with another challenge.
> organized. They were organized along architectural boundaries. This
> added a lot of dependencies between teams because a story had to be
> split across 2 or 3 teams. Combining the teams into one "solved" that
> problem (or did it just mask it until now?). Some people think that
> splitting up in to smaller teams might lead to the same issues.
Try to find a new solution that works for both. :)
Hope any of this helps,
Process Improvement Manager
SYSOPENDIGIA Plc., Finland
- << Previous post in topic Next post in topic >>