Multi-team Scrum vs Multiple Scrum teams

Difference

“Multi-team Scrum” is different from implementing Scrum for each team and then implementing a co-ordination mechanism on top of it (e.g. Scrum-of-Scrums etc.). Not only these "multiple Scrum teams" usually lack the holistic product view, they often suffer from local optimisations at different levels. Worst of all, the additional layer of co-ordination creates complexity, unnecessary checkpoints/meeting and hand-offs - waste, to put it gently.

Benefits

The multi-team Scrum brings out the benefits of Scrum to multiple teams. It strikes the right balance and finds the sweet spot between two extremes of prescriptive-ness. i.e. It does not define a rigid process (like Rational Unified Process or RUP) nor does it leave it to total experimentation (like Learning Organisation, for example). The balance between these two extremes allows people to define their own processes and tailor them up as and when needed while providing enough scaffolding to make sure the underlying principles are not violated. These underlying principles are driven from years of studies and experimentation and are in exact accordance with Lean and Agile principles.

We should aim for...

We should strive for “multi-team Scrum” as opposed to “multiple Scrum teams”. Read Large-Scale Scrum is Scrum for more details and also watch Craig explain it in a quick 8 minute video.

Adoption

A quick note about adoption. Implementing a multi-team Scrum is non-trivial but so was implementing plain old Scrum too. However, as Peter Senge said, “The easy way out usually leads back in”. A holistic, systems-thinking approach and the capability of an organisation to be able to turn a dime for a dime requires time and perseverance to implement. As someone said: 

Transitioning a multi-team product development team to Agile/Lean/Scrum takes perseverance, humility and patience. 

More meetings? No, on the contrary, multi-team Scrum strives to keep things nimble and avoid waste that is so prevalent in big organisations. At the end, we want to BE agile, play the product development game and have fun while doing it.