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

22177Re: Self organization. How?

Expand Messages
  • Evan Leonard
    Jun 26, 2007
      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 retrospective?

      As for how to run multiple teams, they each definately need their own planning meetings and retrospectives and backlogs.  There can be a single 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 to 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 they're 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