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.

Roles

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.

Artifacts

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.

An Agile Community of Practice Starter Kit

As I describe in my article An Agile Architecture Community of Practice, a very mature Community of Practice has mechanisms that represent that the community has come to agree upon, over a long period of time.  Those standards and working agreements need to mature over time as well…but what if you’re starting a new Community of Practice(CoP) from scratch and you’re NOT mature yet?  Where do you start?

To me, the healthy starter kit for a CoP is comprised of the following:

• The Community forms around an ” improvement interest” or effort that spans across multiple teams(Release Train, Product Group, Nexus, etc), that is scoped according to improvement domain, and also possibly according to organizational domain, geographic domain, and or product(system under development) domain.
• Roles: The following positions or roles need to be initially filled:
  • Community Agile Coach
    • fulfilled by an Agile Coach (and/or Scrum Master), absolutely required position, also good to have a “backup” at all times as well.
  • 2 Community Coordinators
    • Both of these coordinators must come from Scrum Development Teams*
      • * Exception:  if the community “improvement interest” is a topic whose “home base” is not on a Scrum Dev Team, then this requirement is waived.  For instance:  Scrum Master CoP, Agile Manager CoP, Agile Executive CoP, are not home based in Scrum Development Teams
      • The coordinators are responsible for ensuring the “communication mechanisms” below are bringing maximum value to the community.
  • 2-4 Subject Matter Experts
    • These people are the people that are most passionate about the subject that the community is formed around.  They typically already share their knowledge across their teams and/or organizations, and are looked up to widely across the Scrum Teams/and or org.  Ideally they come from Scrum Teams, but this is not a hard requirement, and sometimes difficult to fulfill in orgs that are relatively new to Agile.
  • 1 Management Supporter(optional)
    • This is optional, and should only be fulfilled if you can find someone with good Agile behavior(preferably someone with at least one Scrum or Scaled Scrum/Agile certification, preferably both), and communicate to this person that, in the community, they MUST act as a servant leader to the community, and must let the other roles run the community without too much influence or direction coming from the Management Supporter.  The management supporter might be more directive outside the community activities, but not through the community mechanisms.
• Artifacts: The following artifacts are required:
  • Community Improvement Backlog
    • Unlike the Product Backlog in Scrum, this Community Improvement  Backlog (CIB) contains Community Backlog Items (CBI’s) that only represent “improvements” in the community’s “improvement interest.”  There may be Product Backlog Items that represent work on the Product under development that come out of a community’s efforts, but those will land on a particular Scrum Team’s plate(even if the item applies across several teams).  Remember, bring the work to the (already existing) Scrum Teams and put it on the Product Backlog!  The CB only holds community improvement ideas, not product development work.
    • Obviously, this artifact only needs a couple of items on it to start.
  • Community Working Agreements
    • Agreements about how your community will operate.  (This is the CoP version of  the “Team Working Agreements” in Agile)  The people who fulfill the above roles(the “role players”) are responsible for ensuring this happens.  Many of the other things listed here in this blog post could be your starter set for CWA’s(Roles, Artifacts, Events, Communication Mechanisms).
    • TWA #1 should be something like “In everything we do as a Community, we try to honor the Agile Manifesto.  So, we value individuals & interactions over processes and tools, we value responding to change over following a plan, and we value executing improvement experiments over endless theoretical discussion and “analysis paralysis” about how to go about improving.”
• Events:
  • Meetings at least 3X a month, including at least one meeting open to the public. (Some meetings are best held more privately among the role players in the community, to help coordinate all efforts, public and private)
• Communication Mechanisms:  The following comm mechanisms should be established from the beginning.  The Community Coordinators are responsible for ensuring maximum value is continuously obtained from these comm mechanisms.
  • Synchronous “push” communication for spontaneous collaboration:
    • If everyone is highly co-located, then the mechanism is “Talk to each other”
    • If not, then this mechanism is something like an “always on” videoconferencing system, but also could be a chat room (think Slack or HipChat)
    • Email is a very poor form of this mechanism, but if you can’t get something like the above, then an email list may be the best you can do right now.  (IF that is the case “Find a better Synchronous Communication mechanism” should be high in your community’s improvement backlog)
  • Asynchronous “collaborative” communication for longer lived communications
    • A wiki (something like a Confluence or MediaWiki)
      •  At a minimum, your wiki (and it’s sub pages) should document
        • Your Community’s mission/interest
        • Your CB or a link to your CB (possibly kept in another tool, but a wiki is ok for this purpose too)
        • Your CWA’s
        • The description of the current position holders
        • Info about how to get onboarded to your community’s communication mechanisms.
    • Last resort:  If you can’t get a wiki, an “opaque” document repository mechanism (such as Sharepoint, Google Docs, Dropbox or your code repository)  can be used to keep documents that the community can use, store, and access.
    • (optional) A “work board” for more tactical coordination and possibly the Community Improvement Backlog.  (Something like Trello, a wiki, or your favorite Agile life cycle tool if you can get your company to give you a separate project area for your efforts)  If you can’t quickly get this, this might be a CBI.

The above is the basic starter set to get a Community of Practice started.  Something not mentioned above is the intended audience for the community.  The community is led by the role players, BUT the beneficiaries and implementers of the improvements are generally the “grass roots” members of the community, such as members of your Scrum Development teams.  Said another way, there is a vital implicit role in a Community of Practice, that of  the “target audience” for the community’s efforts.  When the community has “public” meetings, or other communications sent via public communication channels, the target audience benefits greatly from the improvements made by the community.

For me, there are always at least 3 CoP’s that are needed in every environment where multiple Scrum or Agile teams work together closely on a product (aka system under development).

1. Agile Architecture Community of Practice
2. Agile Testing Community of Practice
3. Cross Team coordination Community of Practice (This one often already exists in your scaling framework, such as Scrum of Scrums, Nexus Daily Scrum, Nexus Integration Team, System Team, and there are many other examples)
   1. These practices are really just narrow CoP’s that focus on “Coordinating the flow of work to maximize the value delivery of frequent software releases”

At this point, you may be asking yourself “Why this many roles and structure just to get started?”  Here’s the reason:  Until you have the “minimum viable practice” in place, you should not start a Community of Practice.  You are creating a C-O-M-M-U-N-I-T-Y.  With any fewer than the above roles, artifacts, events, and communication mechanisms fulfilled, you won’t likely have a chance of creating a long running effort that is sustainable, productive, and beneficial over a longer period of time.  If you can’t convince the above handful of people to take a leadership role, then you have more work to do and more support to gather before starting.

For some more info on CoP’s, see this follow on article:  More Aspects of Agile Communities of Practice

The emphasis for your community should always be on “executing improvements” over having endless “how we run the community” process discussions or “how we should go about improvement X” discussions.  Remember, “individuals and interactions over processes and tools.”  🙂