The myth of “Scrum of Scrums”

There are a lot of myths about Scrum and Agile in general.

The most commonly found both by googling and in reality are:

• Agile Teams do not plan
• There’s no documentation in Agile development
• Agile development is not predictable
• Agile Teams do whatever they want
• BTW, Agile Teams do not work hard, but just play around
• Agile is only for small companies developing web applications

Ever heard anyone saying that?

I bet you have.

However having the discussion about scaling Agile (and Scrum in particular) got more and more attention, yet another myth emerged:

• When you scale Scrum to more teams, you handle dependencies and coordination among teams with Scrum of Scrums

I think there’s hardly anything more dangerous and harming for both Scrum and large companies willing to adopt Agile SW development.

Actually dependencies are handled in Scrum by actually eliminating or at least minimizing them. That is done in many dimensions and here are 5 key things you cannot miss:

1. First of all development teams must be cross-functional, meaning that they have all needed competencies to transform a product backlog item in a potentially shippable product increment. This is complemented by adopting a collective code ownership, where anybody is allowed to touch any line of code needed to deliver a product increment at the end of the sprint: otherwise you constrain your team with a lot of dependencies from outside
2. Backlog items shall be in the form of end-to-end User Stories, cutting the system through all layers from front-end to the back-end to produce a potentially shippable piece of function: a component based development produces instead a hell of dependencies
3. User Stories shall be INVEST, where the I stands Independent, so that they are easier to work
4. In a scaled Scrum approach the Product Owner Team develops a unique Product Backlog to feed all development teams and ensure that they are as much independent as possible so that they can move fast with little need to coordinate with each other
5. Scrum teams plan together so that residual dependencies are detected as early as possible

If all that is implemented and being impossible to foresee everything in advance, you will use the Scrum of Scrum as a mechanism to manage coordination needs which pop up during the sprint.

It’s not a meeting of Scrum Masters to report some kind of status, but a possibility for a person who got a problem to rise up her hand and get fast help and support from other teams.

BTW, if you think about, the acronym is SOS.

So it is not meant as the umpteenth coordination structure, but more as an emergency procedure to adopt when some team has put or is going to put something on some other team’s feet.

Otherwise, if any possible effort to minimize or at least reduce dependencies in advance is not taken, you will put so much overhead on your teams, that will basically kill their velocity and productivity.

On the other hand, if you’re not able to implement real Scrum with only one team, how can you succeed in scaling it?

You’d better run your projects in a traditional way!