understanding the pattern

undermining the hierarchy

I’ve worked in many organisations that claim to be using commonly known ideas in agile to solve their problems. Ten years ago, the pattern I saw most was the scrum of scrums. These days, it’s “The Spotify Model.”

It turns out though, that although these ideas may be commonly known, they’re clearly little understood. Thankfully so in many ways, as this is why the role of scum master and agile coach exist. We are here to help explain these ideas in the context of the organisations we work with and to guide our clients to achieve the most they can by employing them.

I often saw scrum of scrum meetings that really didn’t deliver the value that was expected. Although teams ran their Daily Scrum meetings first, they would still need a meeting between the people who knew stuff and the person / people who were going to the scrum of scrum meeting. Instead of sending the person who knew stuff, the attendee would take a brief (usually without any notes) and try to coordinate with the other teams working within the same programme of work. Rarely did this scenario lead to any collaboration because no one in the meeting had the right knowledge or context to facilitate collaboration.

I tried many alternatives to solve the problem of coordination and collaboration between teams.

If multiple teams were producing different increments towards a shared goal, I would invite anyone who was contributing towards or had knowledge relevant to that goal. This meant the only people who took time out of their day were those who would directly benefit from the meeting. All the knowledge and understanding required to solve the problem was in the room. If a blocker was raised, it would be solved quickly, or a plan was created to work towards a solution. Those who attended loved this; those who no longer had to represent something they didn’t understand had a reduction in their stress levels, and everyone else gained time back to work on something valuable instead of standing around getting bored.

In one organisation, the development teams had technical leads. This person would go to all sorts of middle management meetings to provide technical insight during conversations about the direction of the product. At points, it was required to integrate the different components together. (I won’t get into the right or wrong of this approach. It was the one they had, and we were working to make it as effective and efficient as possible.) The scrum of scrum meetings would start when we realised we needed greater visibility between the teams, and the technical leads and the POs would attend it. We would have as many as two a day to as few as one a fortnight, depending on what was happening and the coordination required. The meeting had its own work visualisation board so everyone within the programme could see how work was progressing. When the meetings became unnecessary, we stopped them. It was a tool we used when we needed to use it and not a burden for the sake of a maturity checklist.

The final experiment I tried was to bring all members of the same discipline together regularly but infrequently. All of the engineers would meet together once a month. All of the designers would meet together once a fortnight. All of the POs, all of the scrum masters, etc. This allowed the disciplines to coordinate on work that was in play or upcoming and share the insights and learnings of recent times. One person would talk about a technique they had been experimenting with in their team and the pros and cons they had experienced. In the next meeting, someone from another team would discuss how this had inspired them and the outcomes of the experiments they’d run that had built on those ideas. Over the months, this would lead to a practice being standardised across the teams without the need for any outside management.

Over the years, as the scrum of scrums became less popular and people started talking about the spotify model, I could see that this was the same pattern I had used in my last example. People would work to deliver the desired value in their team (or squad) and then work to improve how they delivered that value with their colleagues in the same discipline (or guild). If nothing else, it suddenly made sense why the word guild had been used to describe that particular grouping. Traditionally, trades and professions would have guilds that dictated who could work in that field and how. These spotify guilds were for each field to create and iterate upon the standards for their discipline within the programme or organisation.

Unfortunately, just as I saw many disastrous scrum of scrums, I now see many disastrous guilds. Understanding this fundamental pattern is foundational to understanding how we move an organisation from hierarchical to networked.

The coordination and collaboration between teams are how we achieve self-organisation and self-management and remove the need for the middle management layer to deliver value. That in no way means that there aren’t still important functions that middle managers may be required for. It means that teams can move quickly and experiment on how to deliver the best value as quickly as possible because they do not have to have conversations abstracted through representatives who have been briefed and don’t have the full knowledge and understanding that would allow for faster and more accurate decision-making.