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+...fter+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.