Loading ...
Sorry, an error occurred while loading the content.

22173Re: Self organization. How?

Expand Messages
  • Petri Heiramo
    Jun 26, 2007

      > Let's say you are working in a company that is adopting Scrum. You
      > 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.

      Ultimately that is up to the team to decide, but I see you're looking
      for options for the team, which is exactly what I see the SM should be
      doing. :)

      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 a
      > 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?

      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 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
      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 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
      their projects.

      > Another challenge is silos of knowledge. With one large team, there
      > 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?

      Pose this as a challenge to the team and ask them how they would solve
      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 self
      > 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.

      Possibly very true. You replaced one problem with another challenge.
      Try to find a new solution that works for both. :)

      Hope any of this helps,

      Petri Heiramo
      Process Improvement Manager
      SYSOPENDIGIA Plc., Finland
    • Show all 16 messages in this topic