More Aspects of Agile Communities of Practice

This is a follow up article to my article about An Agile Community of Practice Starter Kit.  I wanted to share some details on other aspects of CoP’s.

Scope and Nature of a CoP

The scope of an Agile CoP can be of varying sizes and types. The most typical are (most frequent, to less frequent): Organization wide, Localized to a set of teams(Train, Product Group, Nexus, etc), Geographical location, and Organizational department. Organization wide CoP’s tend to be more educational and inspirational in the theme of their activities, while CoP’s localized to a set of teams tend to be very operational in nature. But truth be told, a single CoP can have all 3 of these themes in flight at any one time, only one of those themes in flight, or they could evolve from one to the other, etc.

Educational themed events include webinars and other similar education events, and even providing access and funding for people to attend training or conferences in the community interest. Another educational themed event could be a book club or a study group for achieving industry certifications.

Inspirational themed events includes meetings and other events that are meant to inspire people in the community interest. Some examples:

  • An event to inspire attendees to develop a set of skills in the community interest
    “We’re looking for employees who are interested in being Scrum Masters”.
  • An event to inspire community members by allowing attendees to be inspired by the success stories from others who have skills in the community interest.
    • “In today’s session, we’ll have 3 Product Owners talk about the very different ways the 3 of them go about Product Backlog Refinement, and all 3 ways are highly successful for their respective teams. We’ll wrap up with how the principles for all 3 are the same, even though the practices are quite different.”
  • An event to inspire community members towards personal development in their community interest.
    • “In today’s session, we’re going to talk about a myriad of ways to develop yourself personally as a programmer, as well as some examples to give to your reporting manager so these ways can be included in your quarterly talent development goals. We’d also like to hear some of your ideas on this topic!”

Operational themed events include meetings where inflight product development work or impediments are being discussed. Some examples:

  • Scrum of Scrums
  • Scrum Master Sync (this and Scrum of Scrums are actually different)
  • Nexus Daily Scrum
  • Product Owner Sync
  • Meta Scrum
  • Program Increment Planning (yes, this is actually a very operational Community of Practice if you think about it!)
  • Internal Open Source Component Rollout (Internal Open Source Communities are a great way to preserve shared code without having to use component teams)
  • Internal Open Source Component Brainstorm Session
  • Architecture Advancement Meeting
  • Tiger Teams (these are usually short lived Communities)

Work efforts as a result of Community Improvement Backlog Items

One thing to keep in mind about operationally themed events and communities is that all work on the system/product under development still happens on Scrum Teams. Think about production code. If production code is to be written as a result of a Community effort, a Scrum Team must do that as part of their Product Backlog and/or Sprint Backlog. Any other type of work or improvement that doesn’t require production code can be done in a group of motivated like minded community members, or can also be done as part of a team’s Sprint Backlog. As long as it’s not production code, you have total flexibility in how you organize that non production code work.

Regardless of their scope or theme of events, CoP’s should have regularly scheduled retrospectives, regularly scheduled public meetings, and probably also need regularly scheduled private meetings(usually limited to role-players only, but could be other sets of people). As I said in my /CoP starter kit article, a CoP should also have a bunch of Community Working Agreements, a Community Improvement Backlog(CIB), and official communication mechanisms(formal and informal). All of those things still apply of course, regardless of the scope of a Community.


Community Coordinators(CC)

The coordinators act as the organizers of the CoP, and the main facilitators. One of the principles of a CoP is that you want to build an organization that is more bottom up than top down. Many organizations are coming from strong top down hierarchies. As such, the coordinators must come from the Scrum Dev Teams. You definitely want 2 of them to ensure continuity, and in case they get themselves on the critical path on their Scrum Team or take vacation, etc. At first, they could serve a 3 month term, but once the CoP has been in existence for about a year, you could experiment with a longer term if the community decided to change that agreement. Ideally, at least one of them is more junior, and there is no requirement that the CC be deeply skilled in the community interest. (Remember, there is a different role for skill depth: the SME’s) We’re focused more on people who will inspire community involvement and will responsibly handle community logistics/coordination (aka “social butterflies” and “workhorses”).

When you are bootstrapping the community, give some attention to trying to find a couple of good choices for the initial CC’s, and if they agree to take the role, it is theirs! After the bootstrap, going forward, elections are held halfway into the term of the current position holder so that a nice transition of responsibilities can happen. CC’s should give special consideration to the fact that someone else will likely hold their role soon, and that someone else might completely change direction from the practice or style that you preferred when you were the position holder. To the extent possible, any community formality of any kind should be kept lightweight, easy to transition, and likely to have a long life. This helps ensure smooth continuity rather than volatility in how the community operates. To the extent possible, the CC’s should encourage bottom up self organization of the community. They should also obtain feedback from the community, but if guardrails or executive decisions are needed, the CC’s have the final say over all other positions in this community. Also worth noting that this community likely operates in a wider context (usually a company/org), so all company policies and company leadership roles must be respected or the community faces the prospect of being shut down. The community should feel free to (respectfully!) challenge the status quo of the wider context to increase value delivery, but only respectfully and diplomatically. Bottom up self organization does not mean your community “runs” the company. Role playing note: While not encouraged, only one of the CC’s may hold another position in the same community, and when they play dual roles, they must always clarify which role their input is originating from.

Management Sponsor(MS)

The management sponsor helps get funding and other logistics approved for the community. Ideally, but not absolutely required, the MS is a fairly high up leader in the organization that oversees the community interest. This role is also optional, as a strong community in an organization that empowers communities might not even need a management sponsor.


Community Working Agreements

Your community will likely have some “Community Working Agreements”

Example CWA’s: (We agree that…)

  1. The community has 2 “Community coordinators”(CC) who serve 3 month terms.
    [The CC role’s mission is to incubate and inspire self organizing improvement efforts that further the “community interest.” They generally do this via ensuring that logistics flow smoothly and that benefits(improvement value) from “individuals and interactions” are maximized in the community.]
  2. CC’s must also be Scrum Dev Team members.
  3. It is strongly discouraged to have a CC who resides on more than one Scrum Team. (too much multi-tasking, and residing on two Scrum Dev Teams is weak Scrum practice anyway)
  4. Elections for all positions are held half way into the current term to help provide continuity and orderly transition to the new position holders in the community.
  5. A maximum of one CC can also hold another position/role in our community.

Hopefully you now have a better picture of some other aspects around CoP’s.

One Response

  1. […] More Aspects of Agile Communities of Practice […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: