First up, this post has come about through a discussion I had with a group of other coaches, so thanks to The People's Popular Feed crowd - Steve, Pradeep, Bob, Carl, Gaya, James, Elvira and Tony for the spark.

We all know the Spotify model - squads, tribes, chapters and guilds. It's a great model and many of us have tried to implement it in other organisations. In my experience though, most of those implementations fail, particularly around chapters and guilds. One of the first things we tend to do as coaches is set up guilds. We need a way of getting people to share information across organisational silos and guilds are a great way to do that. Trouble is, it's almost impossible to keep a guild running in many organisations without someone pretty much full time cajoling and pleading with people to attend. Without someone who is willing to make the guild their life's work, they quickly fizzle out. 

It shouldn't be that way. A guild should be self sustaining. The members should be there because they are interested and see it adding value, not because George, the guild master badgered them into attending this week's meeting. So why, when they are so good in theory, are they so hard to keep running in practice? I have been giving this some thought recently (while sifting through the wreckage of another dead guild) and came to the conclusion that it's because we are doing things backwards.

We are trying to use guilds to create an agile culture. The reason guilds die though is that there isn't an agile culture based on learning and information sharing to support them. The things a guild does are not valued by the organisation so the organisation does not support the guild. One of the most frequent questions I get asked by people attending guild meetings is "is there a time code I can book this to because my PM won't let me book it to the project? ".

The PM doesn't see learning and information sharing as relevant to their project so doesn't want to absorb the costs (another problem with projects). If everyone has to be fully recoverable, this means people need some other code to book to and guess what? There isn't one. The organisation as a whole doesn't value learning and information sharing so there is no guild time code. People might want to come but can't on work time. So the guild shifts to after work or lunchtime and attendance falls away even more because, let's be honest, who wants to talk about work after work? Guilds need an agile culture to thrive. And in its absence they wither.

So why did Spotify have such success with them? It's because at Spotify, the culture came first. They had a good agile culture that valued learning and information exchange and one of the learnings they came up with was that they needed a way to transfer information between disparate groups. So guilds and chapters were born. They emerged from the culture. They weren't used to create the culture. Culture comes first.

The Spotify guys realised this ages ago. The first thing they tell you when they do a presentation on this is that there is no "Spotify model". There are a set of things they do at the moment that work for them but that will change as the organisation changes. Guilds, chapters, tribes and squads emerged from their culture, not the other way round. If you just try to apply what Spotify is doing now to your organisation, it will likely fail because you don't have the culture to support it. Culture has to come first.

What we need to do is build culture first. Get the organisation to value learning, information exchange, continuous improvement and all that. Then we won't need the Spotify model. Your organisation will evolve its own. It may evolve into guilds and chapters but it might not. There may be other structures that work better for it.

So maybe, rather than set up the traditional "Agile guild", maybe we need to set up something much more work focused to start with. A program problem solving forum or something like that. Attended by all the groups that make up the program. Something that can show a direct benefit of sharing information between all the groups. If they see a benefit, they will support it. The PM will give you a code to book time to because it is benefiting them. If you can show a benefit in one type of information sharing, expand to others, show that they have benefit as well. Build a culture that desires learning. Build a culture that thrives on exchanging information, not hoarding it. Take leadership on the journey. Show them that sharing is better than hoarding for their business. Then, guess what? You don't need to set up an agile guild, because either one will form itself, or something else will form that does the same job.