22185Re: Self organization. How?
- Jun 27, 2007
>>>> Another wrinkle... There used to be 3 teams that were not selfHi,
> 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
I recommend reading Organizatinal Patterns of Agile software
development by Jim Coplien and Neil Harrison. There are lot of
scenarios discussed in that book.I think trying out some of the
Organizational Patterns can help in your situation. Splitting the
team across architectural boundaries is good thing to do (Thats what
Conway's law is about). You probably need to use Function Owner and
Component Owner, Named Stable bases and Incremental Integration
Following is a link to (somewhat older) version of patterns
--- In firstname.lastname@example.org, "Petri Heiramo"
> > Let's say you are working in a company that is adopting Scrum.
> > are in the middle of a multi year projectseveral
> > on a team of 25+ developers. You've been "doing Scum" for
> > months but it's just not clicking with this large team. Teamsize has
> > been identified as an issue in the Retrospective. The team wantsto
> > split up into smaller teams but is having trouble seeing how.looking
> Ultimately that is up to the team to decide, but I see you're
> for options for the team, which is exactly what I see the SMshould be
> doing. :)team
> First of all, I think it would be good to keep in mind that the
> structure need not be permanent. If necessary, the teams canteam to
> 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
> test organizations and then tune based on practical experience.Some
> ideas need iteration to get right (they tend to be the moredifficult
> > What issues might arise if 3-5 teams share a product owner and a
> > ScrumMaster? Would it be best to have a PBL for each team or is
> > light weight enough to share a PBL? Would it be best to haveseparate
> > scrums, planning meetings, reviews and retrospectives?to be
> You might want to consider having a separate SM for each team. That
> 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
> held as the whole project team. The second part of sprint planningand
> daily scrums would be specific to each team. And then there wouldbe
> the Scrum of Scrums to which each team would daily send theirof
> representatives to keep the teams communicating.
> For some reason I recall that Henrik Kniberg did discuss the issue
> how to do sprint planning with multiple teams, but I can't find thethe
> topic with a quick browse of his excellent Scrum and XP from the
> Treches article
> 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
> sprint planning meeting, the project team would discuss the topwith
> priority items and each team would then select (in co-operation
> other teams and the product owner) stories for themselves. Aftereach
> team is fully committed, they would do one more discussion roundthere
> 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
> their projects.
> > Another challenge is silos of knowledge. With one large team,
> > are "go-to guys" for specific features. For example, onedeveloper
> > practically owns the data access layer. This makes it difficultto
> > see a logical way to form the teams because thisdeveloper "needs" to
> > be on all teams. An obvious solution is pair programming tospread
> > the knowledge. Are there any other possible solutions?solve
> Pose this as a challenge to the team and ask them how they would
> the situation. Ask what they would do if this one person is sick ora
> otherwise absent? How are they going to ensure that they can still
> complete their spring commitments. It _IS_ their responsibility as
> self-managing team. They might suggest sharing knowledge throughpair
> programming, or sharing the person (and the possible deputy)between
> teams based on greatest need in each sprint. It's really up tothem.
> Actually, maybe you could make this "silos" thing a topic in one
> retrospective, and have them work out a strategy and actions to
> it. Of course, start up with a question "do you see <this andthat> a
> risk or a problem for you in the future?" :). If they think it'snot a
> problem, pose situations where the risk could materialize (like theThis
> 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 self
> > organized. They were organized along architectural boundaries.
> > added a lot of dependencies between teams because a story had tobe
> > split across 2 or 3 teams. Combining the teams intoone "solved" that
> > problem (or did it just mask it until now?). Some people thinkthat
> > splitting up in to smaller teams might lead to the same issues.challenge.
> Possibly very true. You replaced one problem with another
> Try to find a new solution that works for both. :)
> Hope any of this helps,
> Petri Heiramo
> Process Improvement Manager
> SYSOPENDIGIA Plc., Finland
- << Previous post in topic Next post in topic >>