Why a Guild should never do Scrum...ever!

Picture this: any mid to large size company or organization midway an Agile transformation. Scrum is the chosen framework to help them become more Agile and any number of Scrum teams starting to take off and make good progress.

With this (growing) number of teams, dependency management between teams becomes more and more important. Just as the ever growing need to engage the rest of the (non-IT) organisation to follow the Scrum paradigm to help this company to be truly Agile and responsive to their market(s).

A way I encountered quite often to manage the dependencies between teams and at the same time scale up to the rest of the organisation is something that is borrowed from Spotify's Agile scaling solution: Guilds. At Spotify however they've not stopped there. But also introduced tribes, squads, etc. In short a full landscape of tightly aligned and loosely coupled Agile teams working together to become better at their business.

But back to our case: Guilds (or any form of 'team of teams' but let's call them Guilds for now) are introduced, easy. People with the same roles, skills, etc. form a group and discuss new solutions, cutting edge innovation, learn from each other, etc.

Ever so often as Guilds are introduced, also Scrum travels with them into the Guilds. Quickly a backlog is defined, items are identified, refined and before you know it, the Guild has its own sprints. Whoohoo! Scrum has scaled!

Hold on! So why is this a bad thing?

Let me explain. First of all: if you are in one Scrum team, you cannot be in another. How are you to keep focus? What sprint goal is more important? Who decides on the priority? So apart from all this practical problems, we also managed to add complexity.

The Agile principles are very clear on this topic, freely translated: don't add complexity!

That is food for thought: So, what is a good way to do this? Should we abandon Guilds? Well, no. Guilds are very valuable. That is already proven by Spotify and many other companies.

But the Guilds should stay away from the Scrum framework. The focus of Guilds should be on topics. Topics that are interesting to the Guilds and are not necessarily part of a sprint or sprints from the different teams.

Innovation for instance, or how can we contribute to the next step in the Agile transformation, or how can we improve our skills, or how can we learn from each other, or... etc. etc.

I started out that managing dependencies between teams is often solved by introduction of Guilds. That's also often the main reason that Scrum travels with the members into the Guilds. We see now that Guilds are not the solution for this particular problem. They serve another goal: cooperation, pollination if you want of knowledge and ideas, mastery.

I will not deny that Guilds help in one way or another the scaling of Agile, but it's still only a part of the way to scale Agile. For instance, the introduction of Guilds does not, by default manage dependencies between teams. What does, you might wonder? The answer is simple:

Teams manage dependencies between teams. How?

In any way that will work for your teams. Common sense and communication are at the basis of tackling this. Improving face-to-face communication between depending team members is key. The scaling Agile frameworks like Nexus, Less, etc. can help; a lot actually. The scaling Agile frameworks are an answer to these kind of scaling challenges. Working from a common backlog for instance, creating purpose, define a common goal, etc. are things that help improving communication and cooperation between teams.

Interested in finding out how that will help your organisation? I'd love to help. Contact me if you want to learn more.