Splitting Team?

The answer to your question is in the Scrum Guide: "Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage."
Your other questions:
- The most important attribute of teams in Scrum is self-organizing. You can organize a workshop in which the teams form themselves.
- If you have one Product, you have one Product Owner. He can manage several Dev Teams. When you have too many dev teams, so the PO cannot focus on value any longer, you need "Sub Product Owners" in each team, but you still have one PO who is accountable for the whole product.
- Ask the teams how they want to handle this. It is possible to have all the standups at the same time but different location, and afterwards you have a Scrum of Scrums where one dev team member of each team (with democratic legitimation) participates.
- Probably the velocity will go down, because the teams enter the forming - storming - norming - performing cycle again
- Ask the teams how they want to handle this. Inspect and adapt.
Have a look at the books by Larman and Vodde on scaling Scrum, there are some useful concepts there.

I'd like to get some feedback on this too.

For the scrum of scrums to work, do you need to split the original team into at least 3 teams (because a scrum team consists of 3 - 9 members)?

All the examples of scrum of scrums that i've found (as well as the scrum for the enterprise book) shows examples of 3 or more teams working in a scrum of scrums. Does this mean that 2 scrum teams working on a single product is not ideal?

> Does this mean that 2 scrum teams working on a single product is not ideal?

That's a very good question. If we were to consider the Scrum of Scrums to be analogous to a Development Team - albeit one at a larger organizational scale - then we would have a problem with the 2-team situation. In other words, if two teams each supplied one representative at SoS events, then we would have a Development Team analog with only two members.

This is a problem in so far as the SoS pattern frequently *is* considered to be such an analog, and the Scrum Development Team is often considered to be an appropriate metaphor for achieving agility at scale.

In my view this metaphor doesn't really hold. Certainly, the risks associated with having a Development Team of only two members are *not* the same risks that would affect a product with two teams. Hence I see no intrinsic problems in having a two team SoS.

Ian, thanks for the insightful answer.

Can you elaborate on the risks you've identified as being associated with 2 member dev teams and 2 member SoS teams?

> Can you elaborate on the risks you've identified as being associated
> with 2 member dev teams and 2 member SoS teams?

The Scrum Guide summarizes the risks as follows:

"Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment".

These risks are less applicable to a Scrum of Scrums, because the interactions that take place in order to create an increment must necessarily involve all team members. If the SoS becomes a bottleneck on such interactions, then teams are free to challenge that impediment, such as by rotating attendees.

The risk of a skill constraint arising is also less relevant at the SoS level, because we must consider the skills and availability of all team members in aggregate. One person might become sick or indisposed, thereby jeapordizing a small team's ability to meet the Sprint Goal. This risk is amortized across all developers involved in creating a product, and so it is proportionally reduced in the Scrum of Scrums.

The risks that *do* affect the Scrum of Scrums are principally those of failing to collaborate in order to provide a release. For example, teams will often guard their resources jealously and they will manoeuvre for relative political advantage. It is immaterial how many teams participate in the SoS; when push comes to shove, the SoS is not seen as being a "team" even though it is the essential conduit for release. The delivery of a valuable and potentially shippable increment can mean little in such situations.

The following is an article introducing the idea of the scrum of scrums.
http://www.scrumalliance.org/community/articles/2013/june/scrum-of-scru…

When our team grew beyond the recommended size we eventually split the team into two and then into three scrum teams. We tried the approach of the Scrum of Scrums but over a relatively short period of time we found it inefficient / unnecessary. At first, we found the scrum of scrums becoming a status meeting (sometimes for management). Everytime we tried to refocus the meeting and get true value out of it we found what was left was occassionally one team bringing up something that perhaps another team might be able to help with. Eventually we concluded that instead of having a scrum of scrums the individual that needed something from an indiviual from another team should just go talk with them. From this experience I've concluded that Scrum of Scrums may not be necessary to occur on a daily basis.

We found it important for all 3 scrum teams to work on the same sprint periods. So all 3 scrum teams started and ended their sprints every 2 weeks. At the end of the sprint, all 3 teams would come together in a single meeting and inspect what each other's team developed. This kept all team members up to date on what the other teams were developing while they were developing it. We also on rare occassions had Retrospectives with all three teams together. This gave opportunities for removing inefficiencies between teams and standardizing things like the definition of done.

Not that you asked about it...but if you're splitting your Scrum Teams you should also consider if they will be working off the same branch of code. I highly recommend staying on one branch to reduce the amount of merging/maintenance within source control. Even with 3 scrum teams we kept to a single working branch.