Communities of practice are domain-based around the roles within our Agile framework and every role has the opportunity to form a community of practice. Notice the word “opportunity.” We want them to develop, grow, shrink, and dissolve organically. As the role matures, the need for the community may diminish but spawning them back up again when needed should be easy.

As noted by Etienne Wenger, a community of practice is not a community of “interest.” The community of practice is not designed to be a show-and-tell or a lunch-and-learn but should be rigorously defended as the place practitioners go to improve how they perform their role in the framework.

Communities should also not be made mandatory by leadership but allowed to be self-managed by those who are actually practicing the role. Managers will still play an important role by establishing a vision and road map for the role, supporting the needs of the community, and ensuring members have been allocated time to participate in the community. Here is a previous post as an example of the vision I set for the Scrum Master CoP.  If people are not showing up to a community it may mean that the role vision is not very compelling or the topics the community is working on does not interest them.

Thinking of starting up communities? With our coaches @salhir and @mark4ro, here are the steps we took to get them started:

1. Invite the current role practitioners to a kick-off session to provide context. During this meeting, share why this community exists. The context we emphasized for our communities was ownership and continuous improvement of their roles and the relationship of their role with other roles in the Agile framework. Share the role vision from the manager if they have it prepared in advance.

2. Identify current pain points while practicing the framework. Retrospectives are a great source for this material. This is usually a very easy session to get started as most people have a list of things built up to share. Use this time to get every thing out on the table and to get the community feeling comfortable with this venue being a safe place to share.

3. Convert pain points into topics of value and prioritize. Turn the list of pain points into topics of value by filtering out anything that may not link to a work product or activity in the framework. Prioritize the topics by asking “what topic will provide the most value right now?”

4. Establish a meeting cadence.  Let the topics of value be the guide. If there are important and priority topics to tackle the community may want to meet frequently but as the community starts tackling these topics they may be able to meet monthly or quarterly.

5. Select a representative.  Have the community self-select a person to represent them to the other communities. Many topics of values emerge that impact multiple roles. We call this group of representatives the Integrated Community of Practice and I meet with this group for 30 minutes every week. We discuss the cross-role topics of values and also escalate any organizational impediments through this group.

6. Regularly work the topics of value. Return to step 2.  The community begins working on each topic of value to determine what process improvement, if any, is necessary. Each topic of value may result in three actions to the framework: add guidance, remove guidance, or propose a change to a process standard in framework. Communicate any changes to all practitioners or other communities of practice as necessary.

NOTE: Process standards define the roles, work products, and activities of our Agile framework and should be considered the baseline methodology for product development. They change VERY rarely. Adding guidance states “how” to perform within your role. Guidance can be templates, patterns, or practices and can change quite frequently.