A New Agile Guild Model
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?
In short, simple sucks — and it sucks exponentially as companies grow in size. Large companies will often create an architecture team, or a team around some other skill such as UX. At first it sounds like the right thing to do. Create a team that can focus on a platform or a skill so they can rally around a mission and provide guidance and support to the rest of the company. Unfortunately, that centralized approach causes siloing, bureaucracy, and a loss of context from the software teams who consume the platform or skill.
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.
Typical guilds live and die by the participation and motivation of their members.
The Typical Guild Model
Most agile companies (especially ones practicing scaled agile) have guilds that focus on a specific competency. The guild members are completely decentralized — meaning they work on separate teams, report to different managers, and are deeply familiar with the product and customers that their feature teams focus on. According to Scaling Agile @ Spotify, these guilds only organize “to share knowledge, tools, code, and practices”.
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.
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
Yodle has guilds that focus on QA, web development, UX, and is forming a new platform guild. The major difference between these guilds and the way most companies typically structure them is that these guilds are both centralized and decentralized — meaning guild members are still embedded in different feature teams, but their managers are centralized up to a guild leader who owns the mission and vision for their respective competencies (rather than having their manager be the feature team manager).
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.
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?
Yodle’s guild system evolved in parallel to Spotify’s, when there wasn’t a playbook to go off of. But the answer to why they evolved differently mostly comes down to accountability. Typical guilds live and die by the participation and motivation of their members. Everyone in the guild has two jobs, and if things get hectic, the guild responsibilities are more likely to slip. On top of that, there isn’t a great way to reinforce active participation. If a guild member is an asset to their feature team, but doesn’t do much with their guild, should they receive a poor end of year assessment? Probably not.
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?
First of all, the software organization will need some additional headcount to support the managers. Some of our guilds have one central driving manager, while others are large enough to require two layers of management.
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?
There is lot more that goes into running guilds with this structure— far too many details to fit into this article. But it’s still worth summarizing the detailed decisions into three tenets: Awareness, Adaptation, and Vigilance.
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
