How to set up a Testers Guild

Question

In our organization we plan to set up a Testers Guild: a group of test professionals, that work in different Scrum teams. We have about 10 teams across the organization. Most teams have one tester on 5-6 developers.

The Testers Guild should be a real-world and on-line forum, where the test engineers of the different teams meet to share experiences and tips and tricks. I want to avoid, that the Guild is only an informal chat group.

I think, that would not last long and it will have little value for the team members and the overall organization.

1. What is on the agenda of other Testers Guilds out there?
2. What activities do you do?
3. How many times do you meet?
4. How do you keep things interesting over time?

---

UPD #1

Thank you all for your answer! We will soon have our first meeting with the members of the guild and all your suggestions will sure be very helpful.

Answer 1

For a QA guild I would consider some of the following:

• Book clubs
• Brown Bags
• Lunch and Learns
• Demos to non-guild members
• Rewards, awards and presents
• Internal Testing Conference Day
• External Conference Group Outings
• Bi-weekly meetings on topics of interest
• Mugs, hats. t-shirts, etc. with QA guild on them
• Slack channels within the existing workspace (or whatever IM tool)
• Bullet points that get longer and longer just to see if you are reading this
• Humor

As you've already sensed though, without considerable effort, this group will 'fade' over time. In my experience, it essentially requires one or two highly motivated individuals to keep the effort going as "everyone should pitch in to keep it going" just doesn't work. Even if those individuals don't present all the time, they need to have the energy to see out other presenters.

Note: My most recent experience included setting up a testbusters_guild slack channel!

Answer 2

Virtual Knowledge Area teams:

We have been experimenting with setting up Virtual Knowledge Area teams (e.g. communities/guilds) as actual Scrum teams. The team consists of specialists or people who like to get deeper knowledge in the teams' topic area. They have a Product Owner, a person who creates a backlog and has the final say in prioritization of the virtual team's backlog. The team has a Scrum Master, one who facilitates the process.

The first session(s) the team fills out the Working Agreement Canvas. This gives them a mission and real purpose. Instead of just being an informal chat group, also if you publish the teams' canvas the rest of organization can see what they can expect of the team, and maybe even put stuff on their backlog.

I tend to spend around 10-20% in my virtual team. We block a morning each week and run two-week Sprints. As our time is limited for this team, we keep the Scrum events short as well.

• 1-hour max Sprint planning: E.g. set a Sprint goal, make stories clear and order the backlog. (We aim for 30 minutes)
• Sprint:
  • We work together on the Sprint backlog items in the blocked mornings or what is left of it after the Sprint events.
  • Depending on the plan, people work individual some hours on the backlog items every day as they see fit.
  • We tend to skip the Daily Scrum, although in some cases the team does meet regularly to sync. In some cases, we take a couple of minutes during the Scrum of Scrums with relevant members to go over the backlog.
• 15 min max Sprint review: We discuss our results and close the Sprint.
• 1-hour max Retrospective: Resulting in one Kaizen for the next Sprint. (We aim for 45 minutes)

I think you should feel free to let the team evolve into something different than Scrum. But Scrum is a nice starting point, everyone knows it, building a backlog together gives real purpose, retrospectives tends to optimize the teams limited time.

Some learnings:

• People should not be in more than one virtual team, next to their full-time Scrum team.
• The virtual team should try to delegate work to other real Scrum-teams, instead of trying to work in parallel.
• Make pairing appointments with team members, as it is much more effective to keep focus, motivation and really getting stuff done. We often book a meeting room for some hours to work in. For example, migrating teams from one tool to another after we did research and agreed on a new way of working.

Open Fridays:

We also experiment with Open Fridays. No regular work, just learning, collaboration and sharing.

• Pitch ideas you want to research, work-on or experiment with.
• Make groups
• Work together
• Share the results at the end of the day

This could be a more non-formal way of bringing like-minded people together without disturbing their regular teams' workflows.

Answer 3

What kind of 'clicked' in one of my last companies was when we made special test squad teams (3-4 people) with great titles like 'QA Ninjas'.

These were supposed to be 'earned' with clearly visible process improvements and creative technical or non-technical solutions. It was 'fueled' with great recognition, quarterly monetary/rewards, based on all QA + scrum team votes.

What 'glued' the team together was an informal QA book club, publishing articles, weekly catch-ups over coffee, sharing ideas, monthly meetups, small parties/celebrations, and quarterly one-day trips together.

All of this partly happened because of 2 highly energetic and influential senior QA folks who sold the ideas for funding to senior management, and created a kind of synergy in the overall QA team to get it going.

Overall, it worked well and was proved to be a win-win-win solution for QA folks, scrum teams and management.