I am trying to find a way of reinventing the Scrum Master Community of Practice (CoP) in my organisation into more of a working group.

We often find that people are disengaged or expect a presentation. Lean coffee style format also doesn’t seem to generate enough change.

What we want to do is turn the CoP into a working session where we prioritise and actually work on topics all the SM’s together.

Does anyone have any ideas or formats or methods that are proven to work?

We generally have between 15-30 Scrum Masters who join the existing meet-up monthly. Each Scrum Master leads either 1 or 2 Scrum teams. Each Scrum team has a Product Owner. There are multiple products spread over multiple teams. It’s a huge telecom organisation.

  • A community of practice is usually used to share knowledge and experiences, not as "a working session" to prioritize work or take action. Are you looking for a community of practice? Or are you looking for a place for your Scrum Masters to identify, prioritize, and work on solving problems? Understanding your organizational structure would also be useful. How many teams does each Scrum Master work with? Are the teams working on the same product? How many teams per product? Is there a product portfolio? Understanding the relationship between Scrum Masters, teams, and products would be helpful.
    – Thomas Owens
    Feb 14, 2022 at 12:22
  • Ok I have updated
    – user32613
    Feb 14, 2022 at 12:38
  • 1
    I need to think about this a bit more, but my initial impression is that you have an XY problem. Your trying to solve a problem using a community of practice or working group, but my current thinking is that your current organizational structure is not one that would support getting all of the Scrum Masters together to form such a working group.
    – Thomas Owens
    Feb 14, 2022 at 12:58

2 Answers 2


Some suggestions:

  • External speakers
  • Senior management guests (e.g. CTO)
  • Maintain a 'top 5 issues faced by our teams' - use outputs from retros and regularly present the list to senior management
  • Have fun - provide snacks, ask Scrum Masters for the funniest thing that has happened to them recently, etc.
  • Go offsite, or to alternative settings like parks, etc.

Above all, make the meetings interesting and fun to attend. A community of practice is never going to be a priority for the Scrum Masters, they need to want to attend.


I don't believe you're trying to solve the right problem.

A community of practice and a working group are two fundamentally different types of groups. A community of practice is a group of people centered around learning and improving. A working group is a group of people dedicated to achieving specific goals or outcomes. In my experience, people self-select into a community of practice, while they are nominated (perhaps self-nominated) and selected into a working group based on their ability to help the group move toward the goals. Clearly establishing the purpose of the group is essential.

In an organization with multiple products, perhaps across multiple portfolios, I'd be hesitant about a working group for Scrum Masters that stretches across all of the products and portfolios. If impediments and improvements are being addressed in that way, it almost seems like ways of working are being pushed upwards from the team to higher organizational levels, reducing the ability of the individual teams to self-organize and self-manage around the work and their ways of working.

In some cases, it does make sense for Scrum Masters to work together. For example, if there are multiple teams working on the same product and there is more than one Scrum Master for these teams, then a collaboration session for the Scrum Masters to look for common impediments or improvement suggestions may be useful. However, since the teams are working on a common product, taking lessons from scaling frameworks like LeSS, Nexus, or Scrum@Scale may be beneficial. LeSS and Nexus both use a two-phase retrospective with the team-level Sprint Retrospective first followed by a retrospective for all of the teams collaborating on a product, while Scrum@Scale has a Scaled Retrospective that includes each team's Scrum Masters. The important thing is that the scope of these are limited to the teams that need to collaborate to deliver a single product.

My suggestion would be to look at these common scaling frameworks and how your organization aligns. If you have one Product Owner per Scrum Team, even when there may be multiple teams working on the same product, is that person really a Product Owner? Do you need multiple Scrum Masters for multiple teams working on the same product? From here, I'd look at your overall product and portfolio management and if there is a need to have some level of coordination between separate products within a portfolio of related products.

In my opinion, the better thing to do would be to follow some of Barnaby Golden's advice. Some examples of things that I'd consider valuable would be a book club, organizational-sponsored certification and study groups, outside speakers on Scrum and agility (bonus points for an industry-specific focus), sharing stories from each team about problems and how they were overcome. Instead of trying to make it a working group, make it a community of practice that people want to self-select into. If people want, but are unable, to self-select into the community of practice, figure out why and enable people to join.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.