What is a Community of Practice?
Table of Contents: Definition – Core elements – Benefits and examples – Origins and failure – Questions from the field – Notes
Community of practice – learning from each other’s experiences
In many organisations, several software development teams work simultaneously on similar challenges: they define requirements, automate tests, discuss architectural decisions, improve deployment pipelines, facilitate retrospectives or look for ways to reduce technical debt. This often yields valuable insights, patterns and solutions. However, this knowledge often remains confined to the respective team, within individual minds or scattered across various documents.
The result: teams end up solving similar problems multiple times, best practices are shared only by chance, and new colleagues take a long time to find existing knowledge based on experience. At the same time, there is a growing desire to learn from one another across team boundaries, without restricting the self-organisation of individual teams.
One possible response to this challenge is a community of practice – an approach that has long been widespread beyond the field of software development. It brings together people who share a common field of practice, a common interest or similar professional challenges. Within it, participants regularly exchange experiences, questions, methods and solutions, learn from one another and continue to develop their shared practice. A community of practice is therefore neither a traditional project team nor a formal organisational unit, but rather a social learning space in which practical knowledge is generated, shared and put to use.
The term was coined in 1991 by the social anthropologist Jean Lave and the learning theorist Etienne Wenger. [1] Their study of situated learning amongst Schneider apprentices in West Africa showed that the apprentices learnt less from their masters than from other apprentices and journeymen, through direct exchange and collaborative practice. This observation gave rise to the concept of the ‘community of practice’ – often abbreviated simply to ‘CoP’ – as a social learning space. In 1998, Wenger specifically applied the concept to the organisational context; this was followed in 2002 by a practice-oriented standard work, co-authored with Richard McDermott and William Snyder, which continues to serve as the basis for establishing communities of practice within organisations to this day. [2]
The three core elements of a community of practice
For a loose exchange to actually develop into a community of practice, three elements must work together. If any one of these is missing, the result will, at best, be a network, a meeting or an informal discussion group, but not a community of practice in the true sense of the term.
Domain
The domain is the shared topic that brings the participants together in the first place. This could be agile software development, requirements engineering, UX research, project management or the use of AI within one’s own specialist field. It is important that the domain is specific enough to enable genuine professional exchange, yet broad enough to allow for different perspectives and experiences. A domain that is too narrowly defined will quickly run out of steam, whilst one that is too broad will lose relevance to members’ day-to-day work.
Community
The community consists of the people themselves, their relationships with one another and their willingness to support one another. This is what distinguishes a community of practice from a mere knowledge database or an intranet article. Here, people ask questions, provide feedback, share even half-formed ideas and learn through direct interaction with one another. This level of relationship does not arise automatically; it needs time, recurring encounters and a certain degree of trust to grow.
Practice
Practice is what ultimately becomes visible and usable: the collectively developed experiential knowledge, the methods, tools, patterns, checklists and approaches to solutions. Unlike pure specialist knowledge, practice does not arise from theory, but through repeated application, discussion and refinement within the community. It is therefore the concrete result of collaboration, not merely its by-product.
Only when the domain, community and practice interact sustainably does what defines a community of practice emerge: a vibrant space in which knowledge is not merely managed, but jointly developed.
Benefits and practical examples
The benefits of a community of practice are rarely apparent straight away, but unfold over time, and on two levels simultaneously:
1. For individual members, participation means they no longer have to tackle every challenge on their own. Anyone grappling with a difficult architectural decision, an unclear requirement or a recurring testing problem will ideally find people within the community who have already thought through or resolved similar issues. This saves time, prevents detours and, at the same time, strengthens one’s own professional identity, as one sees oneself not only as part of a team but also as part of a wider professional community.
2. For the organisation as a whole, this exchange pays off in other ways: knowledge that would otherwise remain confined to individual teams or individuals becomes visible and reusable. Best practices no longer spread by chance, but via an established channel. New colleagues can tap into existing practical knowledge more quickly because they do not have to start from scratch, but can draw on established practice. And where several teams are independently solving similar problems, the effort required is reduced because solutions are developed once and reused multiple times, rather than being reinvented repeatedly.
Examples are the best way to illustrate what this might look like in practice.
Scrum Master or agile coach community
In many organisations, Scrum Masters or agile coaches each work within their own team, often without any professional exchange amongst themselves. A community of practice brings them together regularly to discuss facilitation techniques, deal with challenging team dynamics or try out retrospective formats. Because the role itself is often isolated within the team, exchanging ideas with others in the same role is particularly valuable; it acts as a source of professional support that one’s own team cannot provide.
Cross-functional community on AI applications
A topic such as the use of AI in day-to-day work now affects almost every department, though rarely in the same way. A cross-functional community brings together people from development, marketing, sales or support who, whilst having different use cases, share similar questions: how do you validate results, how do you deal with uncertainty, and which tools are suitable for which purposes? Particularly with a topic that is still in its infancy and rapidly evolving, a community is often quicker and more practical than any formal training.
Community of practice in agile scaling approaches
In larger, agile organisations, communities of practice are often integrated more formally, for example in the form of guilds or chapters, as found in the Scaled Agile Framework.
There, they bring together people with similar professional specialisms – such as all software architects or all test automation specialists – across team boundaries. The difference from a traditional community of practice lies primarily in the degree of organisational integration: a guild is often an explicit part of the scaling structure, whilst a community of practice in its original form remains more voluntary and informal. In practice, this means that the spirit is the same – shared learning across team boundaries – but the formal framework differs.
External professional community
Not every community of practice has to emerge within a single organisation. Particularly when it comes to specialised topics such as requirements engineering [3] or UX research, people from different companies come together, often via meet-ups, specialist conferences or online forums. The advantage lies in the greater diversity of perspectives; the disadvantage is the lower level of shared contextual knowledge. For companies, however, their employees’ participation in such external communities can still be valuable, as fresh knowledge flows in from outside and back into their own organisation.
How does a community of practice come into being, and what causes it to fail?
A community of practice cannot be introduced by decree. You can initiate it, provide it with resources and create the right framework, but whether this actually leads to a vibrant exchange depends on factors that can only be controlled to a limited extent. Anyone who manages a community as if it were a project – with fixed objectives, compulsory participation and regular reporting – runs the risk of destroying precisely what defines it: voluntary participation.
It usually starts with an initiator – someone who recognises a shared topic and brings interested parties together. Over time, this develops into an informal division of roles:
- Community Lead / Moderator – organises meetings and maintains the overarching theme
- Core group of active members – contributes regularly
- Occasional participants – follow discussions or join in from time to time
- Sponsor from the organisation – provides time, visibility and support without interfering with the content
It is crucial that these roles are allowed to develop naturally, rather than being defined from the outset. A role structure that is too rigid can quickly come across as bureaucratic and deters precisely those people who want to be involved out of genuine interest.
For this loose beginning to develop into a sustainable structure, recurring formats are needed, such as regular community meetings, Lean Coffee [4], Lightning Talks, Brown Bag Meetings [5] or Ask-me-Anything sessions. What matters is not so much the specific format as the regularity: a community that meets only irregularly loses its sense of connection, whilst too many or too long-running events make participation a burden. Good communities strike a balance here, often through trial and error and adaptation, not by setting things in stone once and for all.
Ultimately, whether a community thrives depends on a few clear success factors:
- A relevant, shared topic – without a genuine practical connection, any exchange remains purely academic
- Voluntary participation and intrinsic motivation – people get involved because they recognise a benefit for themselves, not because it is expected of them
- Psychological safety – even half-formed thoughts, mistakes or unanswered questions can be shared without being judged
- Tangible benefits – members realise that the community helps them find solutions more quickly or keeps them better informed
If these benefits are lacking, participation will dwindle, no matter how well-intentioned the format itself may have been.
It is precisely on these points that communities of practice most frequently fail in practice:
- Not enough time – participation takes place alongside day-to-day business, without any space being set aside for it
- Unclear purpose – nobody can say exactly what the community is actually for
- Excessive external control – as soon as management dictates topics or expects results, the voluntary learning space becomes yet another compulsory commitment
- Too much presentation, too little exchange – when meetings consist solely of presentations, dialogue falls by the wayside
- Rituals that fall by the wayside – without conscious nurturing, even a good start eventually loses momentum
The common thread running through most stories of success and failure is therefore the same: a community of practice works as long as the participants themselves have a reason to be there. As soon as this reason is missing or is replaced by an external factor, it loses its substance, regardless of how well it was originally set up.
Questions from the field
Here are some practical questions and answers:
What distinguishes a community of practice from a team or a guild?
A team works together on clearly defined tasks and outcomes, often with a fixed membership and chain of command. A working group is usually tasked with producing a specific outcome within a limited timeframe. A network generally brings people together in a more informal way, without the expectation of regular, practice-oriented exchange.
A guild, as found in scaled agile approaches, is closest to a community of practice, but is usually more closely integrated into the formal organisational structure. A community of practice differs from these in that it arises voluntarily, is not a formal organisational unit, and its purpose lies not in a specific project outcome but in collaborative learning and the further development of a shared practice.
Who can set up a community of practice?
In principle, anyone who identifies a common theme and finds others interested in it. In practice, it is often individual committed staff members who take the first step; management is less likely to do so. However, for the initiative to become a lasting success, it usually also requires support from the organisation – for example, in the form of time or visibility – even if this support should deliberately remain low-key.
Does a community of practice need to be moderated?
Not necessarily, but it helps. Without someone to organise meetings, prepare topics or at least provide the impetus for the next gathering, many communities fizzle out after the initial enthusiasm has worn off. Moderation does not have to be carried out full-time or permanently by the same person; often, the role is rotated amongst members of the core group.
How big should a community of practice be, and how often should it meet?
There is no fixed number that suits every community. Smaller groups allow for deeper, more personal discussions, whilst larger ones bring in more perspectives but also require more structure to prevent them from becoming unwieldy.
The same applies to the frequency of meetings: more important than a fixed schedule is that the rhythm suits the community and is actually maintained, as irregular meetings are one of the most common reasons why communities become inactive.
Can a community of practice also function online or across different locations?
Yes, many communities of practice operate entirely digitally, for example via chat channels, regular video calls or jointly maintained documentation. What matters is not the format, but whether there is genuine, ongoing exchange. For teams or locations spread across different sites, a community of practice is often the only place where people with similar professional interests actually meet on a regular basis.
How do you measure the success of a community of practice?
Purely quantitative metrics, such as the number of members or meetings, do not tell the whole story, as communities thrive on trust and informal exchange. More meaningful indicators include reused solutions, checklists or templates; practical problems that have been solved; a noticeably faster onboarding process for new colleagues; or simply feedback from members on whether they find their participation valuable. A combination of a few hard indicators and regular, honest feedback usually provides a more realistic picture than a list of KPIs alone.
Impulse to discuss:
How can a sense of equality be fostered within a community of practice when people from different hierarchical levels are involved?
Notes:
If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.
[1] Jean Lave, Etienne Wenger: Situated Learning, and infed.org: Jean Lave, Etienne Wenger and communities of practice
[2] Wenger-Trayner: Communities of practice – sustained learning partnerships
[3] How does requirements engineering work?
[4] What is Lean Coffee?
[5] What is a brown bag meeting?
And here you can find additional information from our t2informatik Blog:
Psychological safety – the invisible booster for successful teams
What parameters does self-organisation need
How does the MoSCoW Method work?