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

22186Re: Self organization. How?

Expand Messages
  • unmesh_joshi
    Jun 27, 2007
    • 0 Attachment
      If I am understanding the problem correctly, it is like a single
      product backlog item covers various layers of architecture.
      e.g. Product backlog says "User should be able to log into the
      system with system user name and password".
      Because the architecture is such that you have a J2EE frontend
      system, a service layer (probably a web service), a legacy system
      (may be a mainframe system).. etc.
      So to say that we are "done done done" with this item, you need to
      have all pieces integrated and working.
      If you do not split the team along architectural boundaries, you
      need to have a big team including all the members having various
      skills (J2EE frontend people, a web services experts, mainframe
      experts etc). It will be very convinient to break the team and let
      each team have their own sprint backlog. But there should be a
      Function Owner who owns the whole end to end functionality and each
      team owns the component. The function owner will probably maintain a
      overall burn down chart, while each team maintain their own burn
      down charts. For integration, let each team have a "named stable
      base", a working component published for other team to use, every
      couple of days, with list of concrete scenarios working.I think this
      should work for you.

      --- In scrumdevelopment@yahoogroups.com, "Evan Leonard" <evan@...>
      > If you have 25+ people on one team right now, why do you need to
      go straight
      > to 3-5 teams?
      > How about trying two teams? Then evaluate that at the next
      > As for how to run multiple teams, they each definately need their
      > planning meetings and retrospectives and backlogs. There can be a
      > product backlog, but when the PO comes to the planning meeting for
      one of
      > the two teams there should be a set of work prepared just for that
      team to
      > pull from.
      > Ideally there would be one PO for the product backlog and another
      PO for
      > each of the team backlogs, and it would be the POs responsibility
      > coordinate all the work. However one human may fill more than one
      of those
      > roles. Same for Scrum master, ideally there would be three, but
      again one
      > human may fill more than one of those roles. The important part
      is to
      > recognize that the are separate roles with separate
      accountabilities. You
      > might find it beneficial to write those accountabilities out so
      > clear. Then you can empirically see when it becomes more work
      than one
      > person can handle.
      > Also, as for technical boundaries, the work given to each team
      should be
      > "done" by that team. That includes integration with the other
      team's work
      > as well. I would suggest a single continuous integration system
      that they
      > are both checking into the whole time. If that is not possible,
      they should
      > complete the integration work by the end of the sprint, otherwise
      its not
      > "potentially shippable".
      > As for what work we give each team I highly recommend using User
      Stories. Do
      > not break down the work into technical components and sub-
      components. Break
      > the work along user facing functional lines. Look into Mike Cohn's
      book on
      > User Stories.
      > I hope that is helpful.
      > Evan Leonard
    • Show all 16 messages in this topic