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.

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.”  🙂

 

Leave a Reply

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

WordPress.com Logo

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

Google+ photo

You are commenting using your Google+ 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: