Skip to main content
Scrumagic
Start free Dashboard
Learn Scrum

Communities of practice: sharing craft across teams

By Scrumagic Team Last reviewed 5 min read

In short

A community of practice is a voluntary group of people across teams who share a concern or a craft, such as testing or Scrum Mastering, and learn from each other regularly. It spreads good practice without a central department. The SBOK's Scrum Guidance Body plays a related role in a more formal way. This post explains what communities are, how to start one, a worked example and why they fail.

A cross-functional team has no room for a department of testers, a department of designers and a department of database experts. That is the point. But the individual testers, designers and database experts, scattered across ten teams, lose something: colleagues who do exactly their craft, who can say "I solved that last month". A community of practice puts that back without recreating the silos.

What it is

A community of practice is a group of people who share a concern, a set of problems or a passion about a topic, and who deepen their knowledge and expertise in the area by interacting on an ongoing basis. The idea comes from studies of how people learn in groups, and is used widely in organisations.

The LeSS framework describes them clearly. They are rooted in self-organisation and do not appear on an organisation chart. Participation is voluntary: people engage because they have a passion to learn or contribute. An organisation cannot form them the way it forms departments or projects, but it can promote them and provide support such as facilitators, infrastructure and budget. A community needs an informal leader, a coordinator who emerges from the group because of passion for the subject, and the organisation should support such coordinators while being wary of making the job full-time, because a coordinator who no longer practises can lose touch with the craft.

The Scrum Guide does not mention them. It does say that the Scrum Team is cross-functional and self-managing, that Developers hold each other accountable as professionals, and that Scrum Masters coach the organisation. A community is a good vehicle for each. The SBOK® Guide has a related but different device, the Scrum Guidance Body: an optional group of documents or experts who define organisational standards and capture best practices across Scrum projects, acting in a consulting role without making project decisions.

How it differs from other groups

Community of practice Scrum Team Department Scrum Guidance Body
Purpose Learn and share a craft Deliver the product Manage a function Set standards and advise
Membership Voluntary Assigned Assigned Appointed
Authority Influence only Decides how it works Line authority Advisory
Time A few hours a month Full time Full time Part of a role
Output Shared knowledge, good practices Increments Variable Standards, guidance

The key difference is authority. A community has none. It spreads practice by being useful, and not by instruction. That is its strength and its limit.

What communities do

Share solutions. "How are you testing the payment provider?"

Set practices by consent. A testing community can agree on an approach the teams adopt voluntarily.

Teach. Short sessions on a technique, often led by a member.

Hold standards together. Coding conventions, design patterns, accessibility rules.

Help newcomers. A place to ask.

Solve shared problems. A common tool issue, a recurring defect type.

Build identity. Specialists on cross-functional teams may feel isolated, and the community gives them peers.

The Scrum Masters of an organisation often form their own community, and a good one becomes the place where impediments seen by several teams are named and carried to leadership.

Starting one

  1. Find the energy. Start where a handful of people already want to talk.
  2. Name a topic. Narrow enough to matter: "testing", "Scrum Mastering", "accessibility".
  3. Let a coordinator emerge. Someone who cares and has the time.
  4. Set a rhythm. An hour every two weeks, or a monthly longer session.
  5. Make it useful at once. The first session should leave people with something to try.
  6. Keep it open. Anyone interested may join.
  7. Provide light support. Time off from the team to attend, a room, a channel.
  8. Review it. Is it still useful? If not, change or end it.

A worked example

This is an illustrative case. An organisation has twelve Scrum Teams, each with one or two people who do most of the testing. They feel they are on their own, tools differ and quality varies.

A tester posts a note: "anyone want to meet on Thursday to talk about test automation?" Seven people come. They agree to meet every two weeks. The first session compares tools and finds that four teams use three different ones for similar needs. The second demonstrates a pattern for testing a payment provider, which two teams adopt that week.

After three months, the community has twenty-two members, a shared channel and a wiki page of agreed practices. It holds a half-day gathering twice a year. It proposes a standard for flaky test handling, which most teams adopt voluntarily because it is sensible. The defect rate across teams falls. The organisation gives the coordinator four hours a month to run it.

The community did not report to anyone and it changed the quality of twelve teams.

Why they fail

  • Forced membership. Required attendance kills energy.
  • No topic of real interest. If members do not gain, they leave.
  • A full-time coordinator who drifts from the work. LeSS warns of this.
  • Management by mandate. Turning the community into a source of mandatory standards makes it a committee.
  • No time. If teams do not let people attend, it withers.
  • Too big or too formal. Rules and agendas drain it.
  • No link to real problems. A talking shop with no effect.
  • Neglecting the Scrum Masters. A community of practice for Scrum Masters is one of the most useful, and often the first to be left out.

Two perspectives

Neither source prescribes this, so practice varies.

Scrum Guide

The Scrum Guide makes the Scrum Team cross-functional and self-managing, has Developers hold each other accountable as professionals and Scrum Masters coach the organisation, and does not mention communities of practice.

SBOK®

The SBOK® Guide describes an optional Scrum Guidance Body of documents or experts that sets organisational standards and captures best practices across Scrum projects in an advisory role.

Same thing, different words

  • Community of practice (practitioner term) ~ Scrum Guidance Body (SBOK), in part

A community is voluntary and informal, while the Scrum Guidance Body is an appointed advisory group. They can coexist.

How to practise it

Ask the people in your organisation who share a craft whether they would meet every two weeks, and offer to host the first session. In the simulator the Developers have different skills, and the benefit of sharing across them is part of what a community of practice formalises.

Sources

  1. Communities of practice, LeSS Company. Read on 14 October 2026.
  2. Community of practice, Wikipedia. Read on 14 October 2026.

SBOK® is a registered trademark of its owner. Scrumagic is independent and is not affiliated with the owners of SBOK®.

Share this post Link copied

Nothing opened? This computer may have no email program set up. Write it in Gmail or use the copy button and paste the link into your email.

Keep reading

  • Scrumagic 5 min read

    Phase 4, Review and Retrospect: the two steps, one by one

    The fourth phase of a Scrumagic run closes each sprint with two steps: the review, where the developers demonstrate the increment and the Product Owner accepts or rejects each story, and the retrospective, where the team commits to improvements. This post walks through both: what you see, what happens, what you decide and what it produces, with no spoilers.

  • Learn Scrum 6 min read

    One Product Backlog for several teams

    The Guide says teams working on one product share one Product Backlog, one Product Goal and one Product Owner. In practice that raises questions: how can one person order for eight teams, how do teams pick items, and do they need their own lists? This post sets out the rule, the SBOK's roles for large projects, workable arrangements and a worked example with four teams.

  • Scrumagic 5 min read

    Phase 3, Implement: the three steps, one by one

    The third phase of a Scrumagic run is the sprint itself, compressed to a representative day. It has three steps: keeping the board moving, the daily standup, and refining the backlog when a change request arrives. This post walks through each: what you see, what happens, what you decide and what it produces, with no spoilers.

  • Scrumagic 5 min read

    Phase 2, Plan and Estimate: the five steps, one by one

    The second phase of a Scrumagic run turns the top of the backlog into a sprint the team can honestly commit to, and it repeats for every sprint. It has five steps, from checking the stories to freezing the sprint baseline. This post walks through each: what you see, what happens, what you decide and what it produces, with no spoilers.

  • Scrumagic 5 min read

    Phase 1, Initiate: the six steps, one by one

    The first phase of a Scrumagic run has six steps, from the vision and charter to the release plan. It is the free part of the product. This post walks through each step: what you see, what happens, what you decide and what it produces, with the matching Scrum ideas and the SBOK process names, and no spoilers.

We use analytics cookies to see which pages help and which don't. Scrumagic works the same whichever you choose, and you can change your mind any time from "Cookie settings" in the footer. Privacy Policy.