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

22172Re: Self organization. How?

Expand Messages
  • Zak Jacobson
    Jun 26, 2007
      --- In scrumdevelopment@yahoogroups.com, "unmesh_joshi"
      <unmesh_joshi@...> wrote:
      >
      > Hi,
      >
      > Self organizing teams is heart of scrum. But I am not sure if self
      > organization without some guiding principles is possible.
      > It is reflected in org pattern "Developer controls process". But what
      > do you think are pre-requisites for development team to be considered
      > fit for self-organization?
      > I will like to know if there is any literature available that
      > discusses practical examples of self organization in more details.
      >
      > Thanks,
      > Unmesh
      >

      Hi-

      I have a similar question...

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

      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?

      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.

      Thanks for any insight-
      Zak
    • Show all 16 messages in this topic