Image for post
Image for post

Agile guilds have gained popularity in the last few years as many prominent companies (chiefly Spotify) evangelize how they keep software development teams from siloing.

If you’re unfamiliar, a guild is a group of people who work on different feature teams and meet with some frequency to discuss a specific competency. Feature teams are multidisciplinary teams that are organized to create a product or features in a product. For example, a software department may have an architecture guild rather than having an architecture team. The difference being that an architecture team sits together and primarily interacts every day with each other, while an architecture guild’s members sit with different feature teams and focus on the goals of that team, while also having a focus on architecture.

Centralized teams…inevitably build things in a black box that developers don’t actually need.

Sounds complicated right? Why not keep things simple?

Centralized teams create products too. The platform or service they provide is their product, but because they’re disconnected from the teams that they’re supporting (the feature teams), they inevitably build things in a black box that developers don’t actually need. They focus on their own priorities rather than their customers’ priorities and build things that are too generic.

Feature teams will start to feel like these centralized resource teams are distant and difficult to get value from. They have to spend a considerable amount of time remembering that these teams exist and that they need to coordinate with each of these teams in order to build anything. Even worse, they may start to create their own solutions or make siloed decisions because they’re not getting the response times they need from the competency teams.

Image for post
Image for post

Typical guilds live and die by the participation and motivation of their members.

The Typical Guild Model

This construct has worked well for many companies. Feature teams still have access to services that would classically have been provided by centralized teams — in fact they now have greater access, with less effort, and with more perspective because they are sitting next to the person who provides it and are in standup meetings with them every day. The individual guild members still have their centralized competency specific mission and now have the added benefit of seeing how that mission is realized by seeing the impact of their work first hand.

Image for post
Image for post

Having a central guild leader who is accountable has made it easier to track progress towards the guild’s mission…

How Yodle’s Guilds Work

For example, Cristopher Stauffer is a senior director of engineering who runs our QA guild. He and his management team set the mission, vision, and overall strategy for test and QA empowerment at Yodle. The developers who are members of the QA guild officially report through Cris’s management team. However, they do not sit or work day to day with the QA guild management team. Rather, they are embedded in feature teams, work on stories from the feature team’s backlog, and are a part of all of the feature team’s ceremonies.

Image for post
Image for post

By starting with the centralized approach he and his team were able to foster quick and significant change.

Why fix it if it ain’t broken? What’s the point?

This isn’t to say that the typical guild model is bad. We actually have several guilds that use that model, such as our scrum master’s guild. We use the alternate model for areas where we want a stronger more consistent focus.

Having a central guild leader who is accountable has made it easier to track progress towards the guild’s mission and has led to higher quality, while still giving feature teams the room to have full control and accountability over what they produce. When Cris Stauffer created the QA Guild at Yodle, there was a deficit in testing and automation. By starting with the centralized approach he and his team were able to foster quick and significant change.

Having guild members report to guild managers has made them focus on the guild mission, while still allowing them to learn the real needs of their feature team. It also has allowed the members to effectively bring feedback and ideas back to someone who can make sweeping decisive changes. Additionally, it allows guild managers to work with guild members to create customized goals and strategies on each feature team to advance the competency’s goals (for example, each QA guild member is responsible for creating a custom strategy that helps their feature team get to the next level of testing and quality and those guild members are measured by their managers based on their ability to execute that strategy).

One of the other big benefits is is that this structure makes it easier to work on central projects and infrastructures that can benefit the whole software org. The guilds are getting better feedback from their end users (the feature team developers) so the end product will be better than a completely centralized approach, but they are centralized enough to coordinate larger projects and make the time to actually work on them.

What’s the Catch?

Additionally, the guild managers have to solicit feedback from all of the feature team managers so that they can accurately assess the impact their guild members are having.

Lastly, we need some superb and well rounded people to actually be the guild members. It’s a tough job because they need to be competency experts, they need to disseminate information and mentor other developers, they need to be influential enough to move the needle, and they need to learn as much about their feature team’s product as they need to learn about their own guild’s mission.

On the flip side, this makes the other feature team member’s lives easier because they don’t have to worry about coordinating with an outside team and they don’t have to formulate their own UX or QA strategy, because there is someone who’s role it is to focus on that.

…we must be vigilant. A guild and its members must always be pushing for the next level.

What Else?

At Yodle, a lot of effort goes into making sure that everyone is aware of the various guild missions and how those missions are being executed. This includes everything from training, to demonstrations, to newsletters that are posted in bathroom stalls (Yes we do that, and yes they are as entertaining as they sound).

We also put as much effort into making sure that the guilds are as aware of the feature team’s goals as the feature teams are aware of the guild’s. Adapting the core mission to each feature team ensures maximum impact and creates a feedback loop that allows the guild to adjust its mission as the organization evolves and grows.

Finally, we must be vigilant. A guild and its members must always be pushing for the next level. The next level of quality, the next level of technology, the next level of UX. They can never be too comfortable where they are. It is healthy to move guild members around to different feature teams every year or so. It is healthy to hold them to strategies and progress — it is through this vehicle that every competency improves proportionally.

2019 Update: Check out how I’ve evolved the guild concept at Policygenius with my latest article

Written by

Writer, software developer and all around thinker of wacky thoughts. Head of Software Engineering at Policygenius.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store