Communities Of Practice

The Prelude:

Our teams include a mix of functions.  We used to think the all code-programmer team throwing something over to an all Quality Assurance (QA)-tester team when they are done was good.  It wasn’t. We instead elected to have a mix of QA and Developers on the same team.  If possible we had a technical writer, a designer, and surrounded the team with availability to subject matter experts for security, architecture or whatever the need was.  This re-mix of a team met with resistance in some places because ‘my people’ and ‘your people’ wasn’t as neat and clean as it was on paper.  Especially when we took these teams and co-located as many of them as we could.  This is what we found:  Feedback was Quicker as we created software. We aligned our expectations on what we needed to deliver and how. We had many eyes with many perspectives examining and contributing to make the solution better.  Many times we were able to deliver more of the solution – than just a piece of it.  We learned more of everything it took to get that solution through the organization and into the customers hands.  This also meant we could improve the organizational processes and tools as we went. There were also the difficulties…  some teams matured faster than others, skipped or adopted practices without sharing the best of them across the other teams.  Sometimes it might have felt like a role was isolated or not supported within a team.

The Practice:

Abbreviated as COP – a Community Of Practice targets something specific.  This can be more persistent and dedicated for a role such as a QA or Dev COP, or spin up and only occur when needed such as a Database COP.  A scrum master and the program lead or subject matter expert can form an effective effort in establishing one in any program.   For the more persistent role-based COP, I will often hold this at a regular fixed interval.  Some organizations may prefer weekly or once every two weeks in order to:

  • Discuss and Decide
  • Learn
  • Coordinate

Continuous improvement for quality and best practices for the role across all

  • Teams
  • Technologies
  • Features

The meeting content and method can change from time to time – the intent to grow this role or domain knowledge remains the same.

As a Working Session

This time is used to address a particularly large program problem. Remember,  in-sprint work will often rely on cross-team communication as well.  So a working session might be appropriate.  Here are some examples:

  • All testers moving test cases from one tool to another.
  • A demonstration or ad-hoc testing of a feature together.
  • Regression testing – handing out tests and recording bugs on the spot.   Perhaps a good old-fashioned ‘bug-stomp’.  (Usually I  invited developers here too.  The same could be done on a team level)

Discussion and Decision

This might be a role retrospective, communication for a process change, or sharing of a teams specific problem/decision.  If for instance a program was adopting a process change for the first time I might solicit and list some good and bad practices, generate some examples, and afterwards post these as a wiki.  Any decisions might not need consensus, but I certainly wish to get everyone’s input and involvement.  Decisions by the group should be noted, as well as some reasons.  We are not only developing some training material for anyone new to the program, but lightly remembering why we tried something.  We want continuous improvement, so if in the future these reasons no longer apply we can again ask the question.  We WANT to move forward and get to something that is actionable.  Agile Scrum when done correctly is active!  These decisions aren’t necessarily set in stone, they do however help guide us for the moment.  Good empowered teams naturally try to improve tools and processes.

Coordination and Learning

Empowered teams are actively learning.  If across the program the we are actively adopting a new tool, technology,  best practice,  process improvement, and simply wish to share a learning experience, the COP is a great place to do this.  It can also be a place to foster shared leadership.  Different members of the COP might take turns presenting or leading the group on particular topic.   Teams will often exhibit this shared leadership behavior from time to time.  Even visiting SMEs can have a chance to teach. This might be an opportunity to set expectations for the next sprint.   This helps grow responsibility for people within the role especially when there are so many responsibilities to be .  It is a chance to level up.  Aside from the day to day sprint activities, what additionally enables us to make the program better with the perspective that this role brings to every one of the teams?  Examples might be:

  • Test Driven Development
  • Best Practices
  • Security
  • Automated Testing

Usually a wiki or a shared OneNote sufficed to keep track of useful information. Some meetings were even recorded as future training sessions. Any whiteboard drawings might be replicated or photographed for purpose of teaching, improving upon, or communicating outward.


  • Give everyone some individual support.  How can they grow? What might be their next role in helping the program?  What are their concerns?  How can I help?
  • Have some fun!  Someone said I cannot look at the sun, but by it all things are seen.  It is often when we are not directly working on something, and instead allow a bit of time for creation, risk and innovation – these endeavors will help the program in the long run.  A bit of ‘lightening up’ now and again before getting back into the trenches helps the team form and do their best work.
  • Thinking ahead.  Pull everyone up just a bit.  It is usually harder to learn when your head is down.  Too much activity might point to an unsustainable pace.
  • A visit? How close can we get to a customer or a remote site?
  • A Sense of Balance.  I ever ask of myself – am I distracting or am I enabling?  Is everyone so buried this particular week that actually cancelling would be wise?  Cancelling a meeting was something I did not want to fall into the habit of doing, but at times made perfect sense based on need of the program.  Here I questioned a simple timing mechanism and am stressing the ability to be flexible.
  • Tactics for involvement such as a round robin, rotating topic presentation, asking for a group list of top concerns and letting everyone have two votes for which priorities to pursue as a program, a ‘fist of five’ for confidence in the product, or a completely different activity (volunteering in the community) to bring them together as a specific team.

Make it your own!   You are a there for a reason, with the qualities and leadership you bring.  Stressing what was next, to go after, often relied upon some timing and maturity of the program.   Knowing how to manage growth is often one of the hardest things any organization can do.  Different areas of capability, scale, new skills, using a tool differently, or even discarding a process that wasn’t working.  Higher quality in software is not always an immediate speed boost in the velocity of our teams.  It is however a long term speed boost because we make less mistakes and wrong turns.  Keeping architectural concerns or a roles growing strong across several teams can be a challenge; a COP can help.

4 thoughts on “Communities Of Practice

  1. Great post! I have long been a fan (and often organizer) of company communities of practice and it’s great to read how it’s been working for you. Have you ever had a community fizzle because everyone felt they were too busy to get together? If so, did you get past it?

    Speaking of communities of practice, I’m also a volunteer editor of the blog for the Project Management Institute’s (PMI) Agile Community of Practice. I would love to republish this blog post there. If you are interested or would like more information, you can contact me through my own blog. Just click on my photo with this comment. It will take you to my blog where you can find my contact page.

    • Liza, I’ve known a great editor to be worth their weight in gold. You are more than welcome to repost. Ever. We all want to help as much as possible. Thank you for your appreciation. The CoP can be work, and I would love to continue to see the feedback (& link to the repost) from PMI. PMI’s Agile CoP is itself a GREAT example of a community of practice! As for the fizzle… Expect it. It is always something to guard against. There may be different motivations for volunteers. Recognition is certainly one. There are also some weeks when the team is busy and I might cancel, but not twice in a row. I worry about the lost opportunities and the cadence we have set aside. There is no perfect timing but keeping the meeting away from the very end of the sprint always helps. Since the CoP agenda is malleable, the CoP can also be used as a working session to enable the teams. Teams *CAN* often be busy, which lets me consider sustainable pace, and even a chance to look ahead or level up within the role. I like to share the leadership within the CoP as well, and use it as a place for growing our talent, skills, responsibilities, or highlighting our decisions and challenges. There is so much vast expertise and area to cover within the role that we have the individual opportunities for specialized areas of responsibility. As an example for QA – Who can help everyone coordinate performance testing? Who is coordinating training materials for on boarding? Who can help coordinate security testing and keep up on current security issues and training? Who can take this wider and see if the company best practices actually industry or world class best practices? Solicit future agenda from the CoP itself (take it to the team). If the CoP is becoming too much work, then it may be time to share that facilitation with someone who has some new ideas, maybe invite guest speakers, or take the community to visit the customer site. Each leader often comes with their own style. I always make the CoP visible, part of our continuous improvement initiatives, and ensure it is support by the program. It is also great place to recognize the hard work and achievements of a role and an excellent way to communicate across the teams. -E.

  2. Great to see that your post will be share with our Community, Ed: PMI Agile CoP indeed is growing in numbers: And we are trying to help bring more value to members. At times, yes it does fizzle. But you’ve got a great point. In fact I am planning to speak about the story of CoPs at Agile2013 in Nashville, TN
    I would really appreciate if we can connect and get your views/thoughts on this.
    Please let me know.
    Sameer @Bendre

    • Sameer, I’ld be happy to connect. Take what is useful and leave the rest. Though smaller scale; I’ve been leading, sharing, and growing a CoP almost every week over the past couple years. Through two different organizations I have found it as rewarding as it is challenging. Helping those next leaders and having the chance to learn myself is what keeps me engaged. I will admit that a certain type of tenacious creativity is a must have. When coupled with desire to enable others, a group can do more than succeed and grow, you will eventually see some of them give back to role and profession.

Please 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