Communities of Practice (CoPs)

Not so long ago most traditional organizations had their engineering department organized by functions (business analysts, programming, testing/QA, and build). Although this slowed us down from delivering a potentially shippable piece of work and a time boxed iteration because of the handoffs between the functions, it did allow for greater collaboration within those functions to evolve their competencies and knowledge more easily.

As traditional functional departments are being reorganized into the cross functional teams to deliver more rapidly people within these functions/capabilities are dispersed across the organization which makes it hard for them to collaborate to leverage proven practices let alone evolve time. To remedy this organizations establish Communities of Practice (CoPs). A CoP is the means to foster social learning that occurs and shared practices that emerge and evolve when people who are distributed throughout an organization and have shared passion and expertise to collaborate to evolve these practices.

In many ways a CoP is a collection of people who share a craft or profession who have banded together to ‘learn’ from each other to develop themselves and often even the organization. CoPs are also known as Communities of Excellence (which should not be confused with Centers of Excellence, discussed later), Interest Leagues (not to be confused with The Justice League) or even guilds. We’ve seen CoPs focused on agile software development, testing, architecture, management, coaching, business analysis, DevOps, and many more.

This article addresses the following topics:

• Why CoPs?
• Forming a CoP
• Workflow of a CoP
• The Structure of a CoP
• CoPs and Other Teams

Why CoPs?

There are many skills and experiences to learn from each other throughout the organization. Establishing and participating in these groups will give us a conduit to leverage this knowledge across the organization. A CoP forms when people recognize the need to help one another learn a topic. This falls into three major areas:

1. Sharing techniques with one another. The Continuous Improvement goal diagram below captures many process improvement strategies, including strategies to share improvements or strategies. CoP members will often share techniques with one another through face-to-face conversations (perhaps a lean coffee session), chatting in discussion forums, practitioner presentations (such as a lunch-time presentation).
2. Supporting one another’s learning. The goal diagram also captures several strategies that CoP members may choose to employ to support one another, in particular coaching and mentoring. Although a Center of Excellence (CoE) within your organization may officially be responsible for coaching and mentoring, and for most of the potential activities captured by the goal diagram, you will often see members of a CoP doing this as well in an informal manner. This is particularly true when no CoE exists for a given topic.
3. Capture techniques. Some CoPs will choose to start capturing the techniques and strategies that they learn and share with one another, typically in an informal manner using either a wiki or documentation repository such as Microsoft Sharepoint. 

Clicking the diagram opens the interactive DA Browser where you can learn more about all goals, decision points and options of DA.

As you can see the Continuous Improvement goal diagram above captures far more than just the activities that a CoP may choose to perform. This is because CoPs are one of several strategies that you may choose to adopt to promote continuous improvement within your organization.

Workflow of a CoP

It is common for a CoP to meet regularly as a group to discuss common challenges, frustrations, and ideas to improve on these. Out of this is usually a backlog populated with experiments to try to improve on these challenges are frustrations. Some of these meetings turn into working sessions where they flush these experiments out to begin using them. The feedback from running these experiments are discussed in a follow-up meeting to determine whether it makes sense to tweak (inspect and adapt) or to focus on another experiment to solve that particular challenge. The regular CoP meeting serves as a feedback loop to allow the group to continually build on the learning. New practices emerge, practices refined, new tools emerge, new configurations, and the basis of continuous improvement. The results of these meetings feed into other learning mechanisms such as lean coffees, lunch and learns, book clubs or knowledge bases.

Forming a CoP

CoPs are typically formed via two strategies:

• Ad hoc. The first, and most common, is in an ad-hoc manner when practitioners realize that they have a common interest in learning and decide to support one another in doing so. The group will typically start meeting physically, perhaps in your cafeteria or cafe, or perhaps one of your meeting rooms. When it becomes clear the CoP is needed, the next step is to start putting internal support mechanisms in place such as discussion forums.
• Supported. The second strategy is when an existing Center of Excellence (CoE) around a topic decides to support a CoP around the topic that they are tasked to support within your organization. For example, an Agile CoE may decide to start up an Agile CoP, an Agile Business Analysis CoP, or an Agile Architecture CoP. An architecture CoE may decide to start up an Agile Architecture CoP, a TOGAF CoP, or a Microservices Architecture CoP.

The Structure of CoPs

Structures of CoPs tend to be fairly fluid, with a leadership team initially composed of the most experienced members who work together to organize and support the overall effort. However, you usually want a balance of distribution of experience. If it is only comprised of the most experienced members you lose the chance of new innovative ideas/concepts/practices. If all/most are the most experienced they tend to defend the existing practices/ideas as they likely were the ones that brought them to the org. They should have a set tenure to allow for continuity. Then you can replenish it with new people ideas annually or semi-annually. The CoP leader, if there is one, typically emerges from within although sometimes that person is assigned at first if the team has been created by a CoE.

Membership in a CoP is voluntary. As a result members will come and go as they see fit and participate as much as they are willing to or have the time to. A given individual will be a member of zero or more CoPs, and our advice is to be a member of at least two CoPs: One for your current focus and one on the topic of what you hope your next focus will be.

CoPs and Other Teams

CoPs have close relationships with, and overlapping membership with, two other types of teams:

1. Centers of Excellence (CoEs). A CoE is a group of people with specialized skills and expertise whose job is to provide leadership and purposely disseminate that knowledge within your organization. The primary difference between a CoE and a CoP is that a CoE is often purposefully created by an organization with funded members whose full-time job is to coach, teach, and mentor people. CoEs may also take on internal certification of people within your organization. CoEs are often created to support an organizational goal (such as an agile transformation) for a short period of time, perhaps several months or a few years, and then disbanded. CoPs, because of their voluntary nature, often last much longer and may be the end result of a CoE once its official funding disappears.
2. Work teams. Very often there will be work teams within your organization whose purpose is to perform the some or all of the work activities supported by a CoP. For example, your organization may have an Enterprise Architecture (EA) team (or simply an architecture team) whose actual purpose is to evolve and support your EA strategy. In parallel you may also have an Architecture CoP helping people to learn and share architecture skills. Similarly you may have a Data Management team and a Data CoP, a Portfolio Management team and a Management CoP, and many others. Note that a CoE is a type of work team.

The diagram below shows an example of how people can be a member of several teams at the same time. Note that the diagram uses UML notation, in this case a line with a diamond on it, to indicate that someone is part of, or more accurately a member of, a team. We see that Betty is a member of the architecture and agile CoPs, the Architecture Owner on delivery team A, and a member of the Enterprise Architecture team. Fred is a member of the Agile CoE, the agile coach for both delivery team A and B, and a member of the agile and testing CoPs. Barney is a team member on delivery team B and a member of the agile and testing CoPs.