Scrum of Scrums

Certainly, but each team will need to agree on a common Definition of Done for the release they are contributing to.

A Scrum of Scrums is a suitable forum for release-level collaboration between multiple teams working on the same product.

This is quite common when we have to follow Distributed scrum. Multiple scrum teams can be spread across the world even though Scrum doesn't advocate this setup.

If that is the case the binding factor is the Continuous Integration that the multiple teams must follow.
My team has a robust Configuration Management process which ensures that everyone in any team is always looking at the latest revision of any artifact.

A scrum of scrums is usually the textbook approach that is recommended but recent studies show that a Scrum of Scrums is quite unnecessary and serves no additional purpose.

If there are issues to be sorted out then Scrum team members should reach out across teams immediately and this should be facilitated by the Scrum Masters of the respective teams.
Scrum of Scrums are unwieldy and ineffective and can never provide timely remedies to anything. At best they are forums for erstwhile managers to flex their muscles and go against the philosophy of transparency since only one person from each team usually participates and information loss is possible.
Secondly in a proper Scrum environment all members are equal and Scrum of Scrums creates a forum where the first among equals always attend it.

Scrum of Scrums are best avoided. Instead use a good collaboration tool and a good configuration management system which ensures transparency across teams and enables good communication.

> A scrum of scrums is usually the textbook approach that is recommended but recent studies show that a Scrum of Scrums is quite unnecessary and serves no additional purpose.

Can you please point me to these recent studies?

I've personally seen SoS be quite effective. The ones I've seen be ineffective were poorly executed.

Charles

It wasn't so much a case of poor execution as being a case of redundancy. Atleast that was the case in my experience. Most of the issues need not have waited for the Scrum of Scrums and we noticed that not having the Scrum of Scrums really didn't hamper anything.

>>>Can you please point me to these recent studies?
Yes I can if the Scrum trainer and coach whose training I attended and who mentioned this agrees to my pointing out the sources.

>>>I've personally seen SoS be quite effective. The ones I've seen be ineffective were poorly executed.
Can you please point me to any published case studies? I'm still learning Scrum and I would love to have the facts. Having all these opposing camps with different viewpoints can get quite irritating.

Here is an excerpt from an excellent book, based on the numerous and decades of experiences of the author (as good a case study as you'll get on this topic probably):
http://bit.ly/Hg48GT

Most people make the common mistake of making SM's the focus of a SoS, when it should be Dev Team member reps instead.

That book above is the very best book on Scaling Scrum that I've ever seen, best by far. (Companion book is of the same quality)

The first time I set up a Scrum of Scrums I messed it up. The problem was I didn't make the remit clear, and I didn't make a good job of getting executive sponsorship first. I fudged two quite separate concerns:

- The need for Scrum teams to co-operate so a release is successful
- The desire of Scrum teams to have a common forum for sharing tips, issues, and lessons learned

This lack of clarity was a problem, and the lack of sponsorship killed it. Attendance fizzled out even though I had resorted to bribing attendees with cookies. I ended up running a series of "best practice" workshops instead. It was all a bit of a shame. A good opportunity to establish a viable SoS was missed.

On the other hand, at my present client we have 2 SoS meetings a week:

- One is a 15 minute standup (Friday) that addresses release matters...what teams have done and are doing to contribute to the release; any impediments they have; and any impediments (or work) they are likely to be putting another team's way. I'd call that the "real" SoS. I expect it will be held more often as the client gains agile maturity.
- A one hour meeting (Tuesday) for sharing issues/concerns etc. I'd just call that a Scrum forum.

Unfortunately both are called "Scrum of Scrums". This did cause some confusion among attendees, but it has settled down now, and rather than unpick the matter I'm just letting it be. Both sessions are working and stable. Interestingly, the value is such that no cookies are needed for attendance, despite the fact that there has been no executive sponsorship in this case either.

Excellent anecdotes, Ian! You have inspired me to share a couple as well!

One product where there only two teams, and it was a brownfield app, I recommended that they not even do a SoS. I suggested instead that each team send a visitor or two to the other team's Daily Scrum every day. It also helped, though definitely not ideal, that the SM and PO for both teams were the same. I'd much prefer SM's and PO's only have one team. Anyway, the practice seemed to work very well. I should also mention that these teams did sometimes utilize the "after party pattern", as described below, so that members from the *other* team could participate and share cross team knowledge that was needed. http://www.scrumcrazy.com/SP-Daily+Scrum+Pattern+-+The+After+Party

Another product, green field, 6 teams, all teams brand new to Scrum. We essentially followed Larman's advice linked above, as well as Cohn's advice about having a 2 part SoS -- a 15 minute standup, followed by an optional 30-45 minute, sit down, working session. Note well that the focus is on cross team issues, NOT status or "yesterday our team did X", etc.
More info here: http://bit.ly/19eZnYz

In the beginning, with all of the unknowns, and being green to Scrum, I required them to send 2 dev team members(Dev teams were average size of about 5) to a *daily* SoS, that happened after the morning team DS's occurred. SM's and PO's were invited as optional, but they didn't participate in the standup portion (except for 1 SM, who acted as facilitator only). In the beginning, the daily SoS seemed very useful and helpful, but once some of the typical green field/bootsrapping obstacles were removed, it didn't seem as fruitful, and I knew this. I knew it would get very old in a hurry, so I purposefully let it get to a point where numerous teams were complaining about having to go every day, and send 2 members, etc. At that point, I sent all teams an email and said, (paraphrasing) "I've heard your complaints. Anyone with an opinion or interest in this topic, come to the SoS tomorrow and we'll discuss in the after party" Then, I essentially mentored them through a mini retro on the SoS. I first reminded them of all of the purposes of the SoS, and that there is no hard and fast rules on Sos's because they're not part of the Scrum framework. I did remind them of some proven practices, like making the Dev Team members the focus of the SoS, and focusing on team coordination issues. I then asked them to do some plusses and deltas about the current SoS. I then facilitated them to some new decisions that reflected what they think would be a productive SoS. They created about 7 new SoS working agreements, as well as a couple of new "After Party" working agreements. The net effect was that they cut the SoS down to 2 days a week, and down to a minimum of 1 Dev Team member (but no max). I then suggested, and they agreed, to try this for 2 sprints and then retrospect on it again. They retrospected 2 sprints later and made only a couple of minor tweaks, and from then on out, they owned the SoS, and they made very good use of it. Note that this product group also had CoP's, so much of the deep knowledge sharing happened there. The SoS was much more about organizational obstacles, cross team dependencies, and adapting the product DoD(which occured more often due to the green field dev). In my professional opinion as a Scrum Coach, it was VERY effective.

Sushilkumar -
You absolutely should start the Sprint for multiple teams working the same backlog at the same time. If the teams are co-located (or at least can get physically together on the first day of the Sprint), I have all teams in the same room planning their Sprint Backlogs at the same time. That way, when one team wants to select a Product Backlog Item, the other teams are right there to resolve conflicts. Likewise, when one team needs a special skill resident on another team, they are right there to discuss the tasks. Any planning issues can be resolved right on the spot. (By the way, any Release planning that you might need to do is best handled in a similar environment.)

The other posters are right about Scrum of Scrums; the initial planning on the first day is only the start an you need regular coordination to update all the team's plans based on what is really happening.

You didn't ask but I would also have all teams at a common Sprint Review and also Sprint Retrospective. That way, they can update the Product Backlog, Definition of Done, and other engineering practices together. They are all working on one product so they need to work together, even though they are broken up into smaller teams.

Scrum on!

+1000 to Mark's comments.

I should also mention this disclaimer that I have on my web site, on the page where I have my favorite Agile resources:

Warning: Scaling Scrum is not for people or orgs new to Scrum. The first focus should be on doing "single team Scrum". After that, when scaling, we strongly recommend getting Scrum Coaching help. The resources below, while all excellent, are dangerous in the hands of people new to Scrum. We realize this is a self serving statement since we provide coaching services, but we honestly believe it based on our own experiences of having to rescue companies from poor performing implementations. It costs much much less to get started on the right foot than to rescue an organization.

http://www.ScrumCrazy.com/resources

Thanks for the info.

My team does not have much experience scaling Scrum and we have the added constraint of our Scrum teams being distributed across the globe.

I will try and make a mention at our next SoS or retrospective but it has become the defacto std in our team only to have SMs and the PO and some other line managers hence it is not very effective. Some of the SMs are not even knowledgeable about Scrum and have been made SMs just because in their previous incarnation they were leads or architects.

It became obvious to me that we really were not having an effective SoS but the PO is the former SW Dev Manager and none of us have it in us to question his wrong interpretation of Scrum.
Add to this the fact that we have no Scrum coach.

I totally agree with your point that it is easier to learn things the right way at the very beginning.