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

22185Re: Self organization. How?

Expand Messages
  • unmesh_joshi
    Jun 27, 2007
    • 0 Attachment
      >>>> 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.
      Hi,
      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
      patterns.
      Following is a link to (somewhat older) version of patterns
      http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?
      FunctionOwnerAndComponentOwner

      Thanks
      Unmesh


      --- In scrumdevelopment@yahoogroups.com, "Petri Heiramo"
      <petri.heiramo@...> wrote:
      >
      > Hi,
      >
      >
      > > 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
      > problems).
      >
      > > 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
      > (http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf,
      > 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