When a team is small, knowledge moves in conversations. Everyone knows who to ask. Once you have several teams, or your own developers plus a hired team, those conversations stop. The same problem gets solved twice, standards drift apart, and a new person spends weeks finding out how things are done.
A community of practice is a simple fix: people who do the same kind of work, such as QA, backend or business analysis, meet regularly to share what works and agree on shared standards. It works if it has an owner, a goal and paid time. Without those, it becomes one more optional meeting that people stop attending. We learned that the hard way.
People are still the main source of answers at work. In the Stack Overflow Developer Survey 2026, 71.9% of 14,462 respondents named coworkers or teammates among the sources they use most for work questions, ahead of code repositories (62.7%) and internal documentation (60.1%). The same survey asked how often people discover important context only after they have started or finished a task: 12.1% said very often and 23.4% often.
Help from people also makes the job easier. In the survey’s work section, supportive teammates, managers or mentors were the third most common answer to what made the job easier in the past six months, at 17.2%.
Finding information wastes time. Atlassian’s State of Developer Experience 2025, a survey of 3,500 developers and managers, lists finding information about services, docs and APIs among the top time-wasters, and 63% of developers said leaders don’t understand their pain points. A community of practice is one way to hear about those pains directly.
The last one matters more than it looks. Natalia Chistyakova, our Lead Scrum Master, said when this article first ran: “The emotional component of Communities of Practice is the opportunity for developers to feel that they are not alone in the challenges and difficulties of their project.” She called it crucial for remote work and for projects without many specialists of the same profile.
| Community of practice | Project team | Training course | Committee | |
|---|---|---|---|---|
| Who | People with the same skill, from different teams | People with different skills on one product | Learners and a trainer | Appointed members |
| Goal | Better standards and shared know-how in one skill | Ship the product | Learn a set topic | Approve or decide |
| Output | Standards, checklists, templates, mentoring | Working software | Knowledge in people’s heads | Decisions |
| How long | Ongoing | Until the product changes hands | Fixed | Until the question is settled |
We started our communities on a volunteer basis and asked team leads to run them on top of their work. That was a mistake. One leader can’t carry a community alone, and offering people a chance to share wasn’t enough. A community needs resources: someone whose job includes running it, time to work on community ideas and a way to put those ideas into practice.
What fixed it was handing management to our Scrum team. Scrum Masters set up the concept and the structure, planned the work and chose the first priority tasks. From then on, the communities met regularly and their work turned into changes the teams used.
We ran four communities: Scrum, Backend, Business Analysis and QA. Our co-founder Alexander Rocket explained why they matter for client work: “The Community of Practice is the Dedicated Team’s key component. The more well-developed internal competence we have (for example, BA or QA), the more competitive we are and the better service we offer to customers.”
Here are the goals our communities set for one month in July 2022:
| Community | Goal for the month |
|---|---|
| Scrum | A shared understanding of customer-oriented service for the whole team |
| Business Analysis | Standard processes for working with the customer, to raise service quality |
| Backend | Updated standards for the first stages of a development project |
| QA | Updated standards for bug documentation, to raise testing quality |
Some results came fast. The Scrum community introduced a new way of working with customer expectations. The Business Analysis community wrote development standards for projects and a standard interview for business analyst candidates, then moved on to the discovery process.
Three principles kept it going. Participation is voluntary, but following the standards the community agrees is not, and everyone attends the monthly results meeting. The company pays for all community tasks and meetings. Nobody hands out tasks: each community decides what to improve in its own area.
Measure what the community changes, not how many people attend:
Our posts on setting up QA on short-term projects and on managing long-term projects show the kind of standards a QA or delivery community ends up writing.
If you work with a vendor, ask how its specialists share knowledge across projects. In a dedicated team, the business analyst, QA engineers and Scrum Master bring the standards their communities agreed to your product.
The same goes for planning. A budget shows how much of a build is analysis, design and QA rather than code. Our project estimate turns your brief into user stories, and every hour traces back to a story you confirm, priced at our published rate of $39-55 an hour. To see that split for your own product, run your idea through our project estimate.
A group of people who do the same kind of work, such as QA or backend development, from different teams. They meet regularly to share what works and agree on standards everyone uses.
Someone whose job includes it and who isn’t judged on its content, such as a Scrum Master or delivery lead. Leaving it to volunteers on top of their work usually fails.
A weekly working session and a monthly meeting to show results worked for us. Set one goal a month, tied to the quality of code, process or client work.
Attending can be optional. Following the standards the community agrees should be mandatory, or the work changes nothing.
Carefully curated content for resourceful Devs, CTOs, and PMs. No spam.