Re: Self organization. How?
- 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 firstname.lastname@example.org, "Evan Leonard" <evan@...>
> If you have 25+ people on one team right now, why do you need to
> to 3-5 teams?retrospective?
> 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 asingle
> product backlog, but when the PO comes to the planning meeting forone of
> the two teams there should be a set of work prepared just for thatteam to
> pull from.PO for
> Ideally there would be one PO for the product backlog and another
> each of the team backlogs, and it would be the POs responsibilityto
> coordinate all the work. However one human may fill more than oneof those
> roles. Same for Scrum master, ideally there would be three, butagain one
> human may fill more than one of those roles. The important partis to
> recognize that the are separate roles with separateaccountabilities. You
> might find it beneficial to write those accountabilities out sothey're
> clear. Then you can empirically see when it becomes more workthan one
> person can handle.should be
> Also, as for technical boundaries, the work given to each team
> "done" by that team. That includes integration with the otherteam's work
> as well. I would suggest a single continuous integration systemthat 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, otherwiseits not
> "potentially shippable".Stories. Do
> As for what work we give each team I highly recommend using User
> not break down the work into technical components and sub-components. Break
> the work along user facing functional lines. Look into Mike Cohn'sbook on
> User Stories.
> I hope that is helpful.
> Evan Leonard