Agile Guilds for Quality Management in the Enterprise Environment | David Tzemach
Updated: Jan 12
I believe that as an expert in your field (or when you aspire to be one) you want nothing to hold you back from learning new things and growing both your technical and personal skills. I also believe that as an expert, it's your obligation to share your knowledge among colleagues so they can learn and grow themselves.
In the past, the best way to promote personal development was to send your employees on training courses, visit conferences, use training sites and share their experiences with one another. These are all great ways to personal development for your employees, but most of them are by external sources that are not directly related to the organization (or to the day-to-day working hours).
Although external sources are great, I really think that is not enough. To show your employees that you are serious about their personal development, you should also give them a real opportunity to develop themselves during working hours.
I think the solution is to establish frameworks within the organization that allow people to regularly to meet and share their knowledge.
This type of framework is known in the industry as a professional circle, technical forum and in the last few years as Guilds. A Guild is a dedicated community that has a common interest with the goal of allowing its team members to become better craftsmen. Guild members collaborate to share their knowledge, experience, practices and tools. Some examples are a Product Owner Guild, a Scrum Master Guild, a Tester Guild etc.
Feature Teams Vs. Guilds
Before we dive in into the Guild model, it is important to clarify that Guild members are a group of people who work on multidisciplinary teams that are organized to create a product or to deliver value. For example, in the Scrum environment, we may have a quality tech lead team rather than having a quality tech lead guild. What differentiates the two, is that a quality tech lead team sit together and interact with each other all day every day, while a quality tech lead guild's members are spread among different Scrum teams and work on the goals and tasks of that team, while also having a focus on quality.
A common practice is to create teams that focus on dedicated skills such as infrastructure, automation frameworks, UX etc. At first, it may sound good, create a team with a group of experts that focus on a specific platform or technical area of the product so they can provide support and guidance to the rest of the team that needs their help.
I am not saying that this practice will not work or that it is less efficient than other options. However, in my experience, this centralized approach leads to flow bureaucracy that makes it harder for feature teams to consume the services, platforms, and tools created by those centralized teams.
Remember, the centralized teams create their own products. The services, platforms, and tools they provide are their product, but because they are separate from the teams they are supporting, they might build things that no one really needs or that are too hard to consume.
It is important to understand that centralized teams have their own backlogs, prioritization, and goals that in most cases do not reflect the same priorities and goals of their consumers. This leads to the flow bureaucracy, as feature teams find it hard to get the responses and resources from the centralized teams, which leads to increased frustration, and bottlenecks in development.
Because of the flow bureaucracy, feature teams start to create their own solutions, though they should consume them from the centralized team created to provide them. They may make other technical decisions just because don’t get the response times they need for their day-to-day efforts.
Guild Models
When creating guilds, it is important to distinguish between two major guild models. These models are known as the “decentralized” and “centralized & decentralized” guilds:
Decentralized guild model
The decentralized guild model is based on team members that do not exclusively belong to the guild. Though they are part of the guild, they still work on separate teams with all that implies, for example:
They have their own manager, which they report to.
They have day-to-day tasks like all the other team members.
They must be familiar with their team’s product.
They have other team members, which they work with to achieve the team goals.
Centralized & Decentralized Guild Model
This guild model is similar to the decentralized model with one major difference. Guild members still take an active part in their own teams, but they report to the guild managers who set their goals, visions and mission statement, rather than having their manager be the feature team manager.
The quality tech leads (QTL) who are members of the quality guild officially report to the quality architect, who is head of the guild. However, each one of them is embedded in their own development team where they collaborate with other team members, participate in their meetings, work on stories and generally act as an equal team member.
This guild model has some of the advantages over the first model. Decentralized guilds live and die by the motivation of their members, who can decide how they will use the knowledge they gain as members of the guild or whether they want to participate in guild activities. This is all about the commitment and accountability for the guild, as there is no real way to reinforce their active participation.
In a decentralized guild, each team member has two different jobs. This simple fact guarantees that in any shortage of capacity, the guild responsibilities receive the lower priority and are abandoned.
When using the centralized & decentralized guild model, we have a guild leader who is fully accountable for their guild, including keeping track of guild activities, determining goals and ensuring that each team member works towards the guild's mission.
Having a guild manager also allows its members to gain the support and guidance they need to promote continuous improvement processes. In addition, guild managers allow their teams to focus on the guild mission, while still allowing them to learn the needs of their teams, gain their feedback and determine the strategic plan to bring them real value.
Creating a World-Class Quality Guild
This section reviews some of the core aspects of guild creation by telling the story of Tom, who was one of my clients and a dear friend.
Where does our story begin?
Tom was the quality director in a leading enterprise software company that was in the middle of their Agile transition. As part of this transition, the company had a severe degradation in the quality of their deliverables, which led to frustration of the main stakeholders. As the quality director, Tom had tried for over a year to change this. He failed, as he did not have the ability to handle the 60 Agile teams and their managers that managed the development efforts.
What were the challenges that we had to resolve?
When I was invited to help with this problem as an external consultant, the first thing I did was to talk with Tom to gain information and figure out the big picture and the real scale of the problem (from Tom’s point of view). After a few sessions with Tom and other key stakeholders, we determined that there are three major challenges to address as part of the solution:
C1: A limited ability to affect – It makes sense that one person (good as he might be) will not be able to lead and promote quality processes when he needs to work with so many development teams and stakeholders. Tom’s inability to make a real change within the organization led to one obvious result, frustration and the loss of motivation to keep pushing.
C2: Agile transition without focusing on quality – An Agile transition can lead to a massive degradation in quality if this area is neglected. This is exactly what happened in their case, including all the classic problems such as:
Lack of integration and collaboration across development teams.
Failure to adopt the core practices related to Agile testing.
Epic failure in the process of integrating testers in their new Agile teams.
Lack of quality practices leading to mini-waterfalls within the sprints.
C3: Objections of Development Teams – One of the interesting things that Tom said to me was about the objections of the development teams to his vision, because he had never been part of their team and therefore could never understand the day-to-day pressure and challenges the team has.
The steps we followed as part of the guild creation
Based on the information I gathered from Tom and after a few more meetings with key stakeholders, we decided with management to create a quality guild (following the centralized & decentralized model) that will be led by Tom. These are some of the key principles we followed.
Recruitment of guild members – The first problem was that we could not find any suitable members within the organization. Therefore, we invested months in external recruitment.
Definition of the roles and responsibilities (R&R) – Due to the cross-impact the quality guild has on the organization, it was important to determine the roles and responsibilities of its members. After some thoughts, we decided that each team member will possess the title of "Quality Tech Lead". Each QTL will have a specific area of responsibilities that they will own as part of the day-to-day work with their teams. This is how we defined their role:
Actively participate in team Scrum meetings.
Act as a quality consultant for the team.
Assure compliance with applicable organization quality policies, standards and procedures.
Perform root cause analysis (RCA) with the team and hold lessons-learned sessions.
Initiate and drive the adoption of technology, product and process improvements throughout the software delivery lifecycle.
Finding the right teams for the POC – In theory, we know that our solution can be perfect for the organization, but nothing comes free and we had to work very hard to find the right teams to take part in the POC. To choose the best candidates, we had to ensure that they all understand what we intend to do and how they will benefit from it.
Definition of the guild goals and vision – Below, are some items from the presentation we made in order to demonstrate what the quality guild would provide to the organization and especially for the teams taking part in the POC:
Creating quality focal points within the organization.
Promoting the Agile testing mindset and continuous testing (instead of the mini-waterfalls and bad testing practices).
Implementing quality policies, standards, and procedures (quality projects, hardening, readiness etc.).
Increasing transparency of our team's quality work (quality initiatives, KPIs and designated dashboards).
Training & mentoring designated teams on testing and quality practices (ET, RBT, SRM, BVA, etc.).
Helping the organization adopt a quality culture (prevention focus, continuous improvement, collaboration etc.)
How is it going to work?
The guild model that we established at the time was new and followed a type of management that our team had never seen before. To ensure that everyone really understands this change, we had to communicate the work interfaces between the QTLs and their teams:
QTLs physical location – The guild members (QTLs) sit with their teams.
Taking part in team activities – QTLs will take part in their team activities such as planning sessions, design meetings etc. Furthermore, to be a real part to the team, they are also asked to participate in the team retrospectives and to present at each review meeting the overall progress of the quality projects.
Dedicated to their teams – To ensure that each QTL makes a real change and to promote continuous improvement, it was decided that each QTL will be dedicated to their team until the team is mature.
Mastering their team’s products – QTLs provide the best value when they understand the products and the technological environment of their teams. To achieve this goal, each QTL had a full training cycle before starting to promote guild activities.
Direct Management – One of the most important things that we had to define is that the QTLs are managed by Tom and not by the team’s manager. This allows QTLs to create positive tension between them and their teams related to the quality agenda. In addition, we want to let our QTLs provide more services. To do this we made it clear that Tom is the one to prioritize the QTLs work, but the teams can still add their own quality items (e.g. creation of a new process, mentoring of team members etc.).
Where do we cross the line?
Before starting the guild work, we had to make sure that every stakeholder involved in the project knows the boundaries and expectations from the guild. Below are some of the items we presented in the project kick-off meeting:
Project Kick-Off
Now that we have closed all the loose ends, we can officially start the project and assign the guild members to their teams. To ensure that this new model is working, we created a completely new infrastructure to support it. Below are some of the measures we used:
We created dedicated KPIs to track and adjust the process.
Tom, the guild manager, worked closely with each QTL to ensure they are focused on their goals and tasks.
We set weekly meetings with each QTL and their team manager to generate continuous feedback loops.
We created web dashboards accessible to anyone who has an interest in the project.
At the end of each quarter, we set a meeting with the key stakeholders to review what we achieved (and what we have not).
Things I Learned Along the Way
Below are some of the insights which I hope will contribute to your efforts when establishing guilds in your own environment.
Support from management is key
Like any other initiative, before you start building guilds in your organization, it is important to have support from management. I highly recommend that when you introduce this model to management, you will be able to:
Explain how the organization will benefit from using guilds.
Describe the plan to create and initiate the guild model.
Explain the concept of guilds and the different models for implementation.
Explain how this model will influence (positively and negatively) the development teams involved in the process.
Involve all people in the guild as active contributors
Regardless of the guild model you are using, it is important to involve everyone in the guild as active contributors and not as silent participants. One way to do this is to ensure that each guild member has the opportunity to present a tool, idea or anything else that contributes to the guild agenda.
Any guild member can become an active contributor. As professionals, it is a basic assumption that they can take ownership of a guild session, organize it and contribute.
My experience so far is that this concept works great. Of course, you cannot expect that each session will be at the highest level, but the important thing is that each team member contributes without the need to rely on a single person to organize every session.
Ensure that the guild has the right people
It is important to add only the right people. But who are the right people? Well, before I add a member to my guilds, I try to follow three basic rules:
The candidate must want to take part in the guild. They should never be part of the guild just because someone told them that they must.
The candidate should be accountable and committed to the guild activities and take an active part in knowledge sharing.
The candidate should have skills and expertise that are relevant to the vision and goals of the guild.
Ensure that your organization is ready
In some cases, the answer is that it's simply not the time for guilds as the organization has not yet gained the maturity. Perhaps there is no real capacity for team members to participate, or maybe they just do not want to learn. If that is the case, don’t enforce the use of guilds. Wait for the right time as there is no second chance for a first impression.