When I was a QA/IT Process Director at a Chicago-based insurance firm, we performed a re-hosting of our entire end-to-end system, and at the time our technology was dated. We had a non-RDBMS database so we couldn’t do searches on it using SQL. We also had various types of automation attached to it, but a lot of this automation was application-by-application because these applications didn’t talk to each other.

As a team, one of the core problems we faced was how to help the multiple development teams come together and coordinate in a way that worked for everyone. We were very experienced in supporting teams in isolation — which worked well in our old model — but when we embarked on the re-hosting project, we now had an integrated system. The challenge centered around how to have dedicated teams while at the same time having an overall view of the quality of the system.

This was the first time in my career that I came up with the idea of integrating a Community of Practice (COP), a recurring, guild-like meeting for the entire QA team to come together regularly to understand the organizational-wide QA vision and share best practices. Our teams had become busy and were each responsible for their own area of the business, but we knew we had to figure out a way to bring the teams together to share in learnings and to ensure that our integration was successful.

This is a great article that goes into the origins and goals of COPs further.

The notion of COPs may be relatively new, but the surge of Agile has driven its growing relevance in recent years. In today’s QA paradigm, many leaders are losing direct reporting responsibility of their teams. In many ways the job of the QA leader has moved from being a line manager who is responsible for the execution of the work to a “servant-leader” who sets strategic direction and owns the quality of the practice. They still have operational responsibilities, but there is now an added onus to develop, nurture and bring teams together, especially as self-organizing, distributed teams become the norm. The QA leader of today has to think not only about the work of today but, more importantly, the work of tomorrow.

The formation of COPs is essential in keeping QA professionals connected, dedicated to the mission, and responsive as both individual Scrum teams and the larger QA discipline. When done well, COPs can be vibrant and central to the vision of the discipline.

Related Reading: Build Your QE Team for the Future

So how can you build your own COP? Here are a few quick tips:

• Determine Your Cadence: Know when and how often your teams will come together and ensure that that time is protected and defended. Attendance at the COP should be mandatory.
• Identify the Themes: Each COP meeting should have a focus or theme. For example, you can review lessons learned from a past software project, new trends and technologies, or dive deeper into the practice’s overall vision. Having a meeting regimen is critical.
• Remain Ahead: In addition to sharing lessons learned and holding post-mortem like discussions about projects, make sure to keep your COP thinking ahead. This means reviewing things like how the competitor landscape is shifting, what’s going on at the business strategy level, how different technologies will affect their jobs and so on. Build a culture in which your teams are focusing on both present and future.
• Pass the Baton: Assign team members to present or spark conversation during meetings. Give them a chance to speak in front of their peers. Normally other teams don’t get to see other teams present unless they are in an agility at scale model. Therefore, your COP is a great forum for passing the baton and giving all team members the chance to present and learn from another.

When done well, COPs can have tremendous impact on the larger QA discipline. Perhaps most significantly, COPs positively impact the quality and efficiency of the operation. It’s easy to lose a lesson learned from one Scrum team to the next. Generally, Scrum teams develop at their own pace and in their own way and, therefore, lessons are kept inward. The ability to disseminate lessons and best practices more widely makes teams more portable and likely to integrate smoothly. All of this leads to fewer problems at the integration stage and faster movement through bottlenecks and blockers.

As QA leaders, we need to be acutely focused on continuing to cultivate the skill sets of our teams for not only today, but for the team we need to have in the future. A COP is one small but important step we can take in ensuring that our teams continue to learn and grow together.

Interested in spinning up a COP within your team? Drop us a note here, and we will connect you directly with our Chief Engineer Walter McAdams who can give you some immediate tips for getting up and running.