How Do You Start an Agile Community of Practice?
First of all, there’s a fantastic book by Emily Webber that goes into important detail while still being a short read: Building Successful Communities of Practice: Discover How Connecting People Makes Better Organisations
Recently, I was asked to share my experience in building Communities of Practice and talk through the details at the Scaling Agile meetup group in Columbus, Ohio.
Just Get Started
In the spirit of being agile, my suggestion is to just schedule a monthly event, invite everyone and buy some food. This blog post will talk about some of the important logistics and strategies that have worked for me, but ultimately we just decided to jump in and figure it out. First, I recruited some volunteers to help, then we sent emails, put up posters, booked a large room and ordered some pizza.
The Volunteers
The volunteers may be a tricky thing to figure out in your organization. For us, there was about a dozen, maybe 14, really obvious people who were the most passionate agilists in the company. This was a combination of scrum masters, managers, coaches and just passionate developers who were already meeting occasionally on their own to discuss agile topics. We made sure this group had decent coverage over the different big projects, platforms and programs throughout our technology organization. I called this group our Agile Community Leads. And while other organizations I know of go through an interviewing process and shuffle people in and out of this sort of group over time, ours has remained fairly consistent, perhaps only adding a few people here and there. This group of people have full-time jobs, so we meet over lunch on Mondays to work on a backlog of things we’ve decided to do for the good of the organization and, obviously, spend time every month planning the next Community of Practice meeting.
We decided to use an Open Spaces format and evolved and honed our process over time. But before I describe how we structured the meeting and dealt with details, let’s confirm why you want to do this.
Why build a Community of Practice (CoP)?
You may find your reasons are similar to ours. But like any process or framework, you’ll need to think about why from your own perspective and apply these ideas differently to best serve your own needs. We were in the middle of our agile transformation (a few years in), with some great pockets of teams and teams of teams truly being agile and doing it well. Others in our organization still struggled, wondered why it mattered or were hung up on the mechanics. These are the reasons we wanted to build a community around agile:
- Learning and sharing. People improve their craft by sharing freely with their peers, asking questions, expressing their concerns and just being curious
- Adoption. By bringing people from different areas of technology and backgrounds together, we were hoping for serendipitous interactions and people sharing their success stories personally with those that haven’t yet experienced it.
- Culture. Just holding a monthly meeting like this creates psychological safety between teams that might not normally talk and share. It also makes it OK to learn and experiment in general, exploring the agile and iterative mindsets.
- Impact and voice. We also wanted every single person in the organization to know that they can bring new ideas or challenge existing ideas, be heard and even impact the way our technology organization works.
Format of the CoP Meeting
We chose to use an Open Spaces format. (More here on wikipedia and Martin Fowler and the book.) There are many ways to run an open meeting among dozens or even hundreds of people. We chose Open Spaces because it creates the exact kind of interactions we wanted: focused only on the things that the participants want to discuss and small, focused breakout groups exploring the different topics in an unstructured way. It’s one of a number of similar formats: Lean Coffee, Unconference, and World Cafe. Another option is to host your own Ignite Event. Pick a format that works for you, but we found less structure was better.
We scheduled a 1.5 hour Open Spaces meeting over lunch once a month on a Thursday. So what is the Open Spaces format?
There are four principles and one law that make the event work.
- Whoever comes are the right people. Open invite, accommodating for those that want to contribute and learn.
- Whatever happens is the only thing that could’ve. Go with it, don’t try to control it.
- When it starts is the right time. Allow the group to flow with their own creativity without a strict agenda.
- When it’s over, it’s over. If a conversation is over, just move on. If people want to continue, they can make plans to continue.
- The Law of Two Feet says you are in control of what you learn and participate in. If you’re not learning or contributing, move to another subgroup. No judging.
The Agenda and Flow of the Meeting, Roughly
We used a room that held about 100 people. We’d have the chairs set up in two or three concentric circles, with paths allowing space to get into the center of the room. The room was big enough we needed a microphone.
To start, provide a brief intro with announcements and review the basic principles and law of two feet (above). We also invented an “agile mission statement” that we reiterated at the beginning of every meeting, to remind everyone why we were there. Our announcements would also include any follow up from action items that came out of previous meetings that perhaps have led to change. You might even consider asking the group if they’ve learned anything from prior meetings, applied it and have any short success stories to share.
During the intro and for a short period of time, you need to let people get some food! We’d often buy pizza (using a fun pizza math algorithm based on the number of calendar invite accepts we got the day before the event). After a short while of letting people get food and mingle, we’d start asking for topic suggestions. One of our volunteers that help organize and host the meeting writes down all the suggested topics on a whiteboard, big enough for all to see. We found some gentle nudging and suggesting helped people get creative. Ask questions like “What questions or challenges do you have about how your team is experiencing agile?” or “What’s not gone well for you recently?” or “What’s something you’ve heard about that you’d like to learn more of?” and even “What’s something you’ve heard people say they dislike about agile?” We’d switch up these kinds of questions to get people to share experientially about their successes and failures and encourage discussion topics based on that.
As facilitators and hosts of the meeting, you should be aware of just how many parallel conversations in break-outs your room can accommodate. And you should prepare in advance for that number of break-outs. We discovered we had a maximum of 8 different subgroups that could be far enough apart from each other and still be comfortable. So, we’d have 8 easels and large format sticky post-it notes ready around the outside of the room. We’d write the numbers 1 through 8 on the top center of each pad so subgroups know where they’re going later. Sometimes, we’d only get 8 suggestions and there was no need to vote. Sometimes, we’d have a lot less people show up and we’d guess that maybe only 4 or 6 break-outs made sense. Use the audience size and your intuition to guide how many groups you need and how to do your group voting.
We started early on doing a “single clap” voting technique, and to my surprise, it worked really well! After you’ve collected enough topics, quickly introduce your voting technique to the group and explain how it will work. Our groups were always too big to handle the chaos of a traditional multi-vote or multi-dot strategy, because it just takes too long. So the single clap method is really simple and accurate enough — it just works. You tell everyone they can vote for as many topics as they like but can only clap once. And for each topic, do a quick 1..2..3.. clap and make some indication on the whiteboard next to the topic of how the group feels about it. High, Medium, Low or Smiley, Meh, Frown — whatever works. Once you’ve narrowed the list down to a manageable number, put numbers on them and ask the group to decide what topic they’re most interested in discussing and to move themselves and their chair over to the easel with their topic’s number on it.
If someone is interested in facilitating a break-out group, let them. But we’d also make sure one of our volunteers and Agile Community Leads were in each group to step up and facilitate if needed. The goal should be to keep the conversation as fluid and natural as possible. The person who submitted the topic is a great place to start the conversation. The facilitator should ask questions to keep the conversation flowing and do their best to take notes of important points, questions, nuggets of knowledge and any action items or sticking points the group wants to surface.
If your intro plus topic submission and voting takes approximately 30 minutes, you should have at least 45 minutes for break-out conversations, which leaves 15 minutes for a simple wrap up conversation. Remember, if you’re not getting value out of your group or contributing, you can switch groups. Some people like to bounce between multiple groups during CoP meetings.
One of your volunteers should have the role of timekeeper so you can alert the group as they’re approaching the 45 minutes allocated for discussions. When it’s time, ask everyone to turn their chairs and face inward so you can spend some time reflecting before closing the meeting.
We’d often have a different volunteer facilitate this sharing session at the end. Instead of trying to ask each group to summarize everything they discussed, which can be overwhelming, rushed and not as valuable, we’d ask the larger group for individuals to volunteer anything personal that they’ll take away from the meeting. It can be a feeling, a fact they learned, a technique or idea they found interesting or just someone new they met.
Closing the Meeting
As we closed each meeting, we asked the group for feedback using a very simple technique I really like. We put up a large piece of cardboard that we reused each meeting near the exit door of the meeting room. Before we start the last 15 minutes of sharing, we remind them that we’d like feedback and to grab sticky notes to share with us. The big board looked like a simple graph with two axes, along the bottom with a big arrow from left to right was labeled “Value I got from today” and along the left side was a big arrow from bottom to top labeled “Likelihood I’ll return”. We made a 3x3 grid and asked our audience to place their feedback in any of the 9 boxes to help us understand what they liked and what we could improve. And we’d say “You can just put a blank sticky on our feedback board or you can write a message about anything you’d like to tell us” — and this feedback technique was really helpful as we worked to improve things over time.
Some of our volunteers would stay to collect all of our materials and clean up. We’d roll up all the notes from the subgroups and later take pictures of them and post them to Confluence. The great thing about confluence is you can call out the individuals who participated heavily in the break-outs so the conversation can continue or others can chime in and help fill in the gaps later if the notes didn’t quite capture everything discussed. Some groups even meetup again later to keep conversations going or refer back to these pages to share with their teams.
What about the Agile Center of Excellence?
There’s a longer story to tell about how our Agile Community of Practice set the stage for building an Agile Center of Excellence (CoE). Perhaps I’ll write about this in a future blog post. But I’ll share a few short things that relate more directly to the CoP discussion above.
Often, in the course of our Agile CoP meetings, there would be an action item raised or challenge presented by the group that required a decision to be made. The knee-jerk reaction people often have is “we should bring this to management”. But instead, what we did was create the Agile Center of Excellence that would be directly connected to the community and facilitate a conversation with management, but ultimately be responsible for the point-of-view around agility for the organization.
When I draw pictures on whiteboards of CoPs and CoEs I always draw three concentric circles with a dashed line circle between two solid ones. The outer is the Community of Practice, the wide open circle to which everyone is invited to bring conversation, knowledge and questions. The inner cirlce is the Center of Excellence, the heart and centralized point-of-view authority for the organization. The middle dashed line is the informal set of Agile Community Leads that help keep the community alive and facilitate and raise issues to the CoE. These Community Leads are also the communication vehicle back to the teams when the CoE needs to declare new guidelines or recommendations for the organization to consider practicing.
I try really hard to avoid using the word “governance” when discussing a Center of Excellence. In the same way you might recognize that a Scrum Master should not dictate to the team how to operate but rather guide and coach the team as a servant leader, I believe the same is true for the Enterprise Agile Coach and CoE that works with all teams. There is however, a sensitive and important concept that there are deliberate recommendations and guidelines we’d like teams to follow when possible.
There is an analogy I believe Google uses: the processes, techniques and the ways a team operates are like a wide river. There is a lot of flexibility in how they are empowered, but it recognizes there are river banks (curbs of the road) that are out of bounds. But the river is very wide, meaning much experimentation is possible and encouraged. Teams that are either just beginning agile or do not have a strong/contrary opinion should stick to the center of the river where the water is deepest, where the greatest support, tools, techniques and deepest experience lies. These are the recommended skills and topics where our coaches are most learned and can actively support teams. Meanwhile, if a team wants to explore with a technology, practice, process or technique outside the deep waters, they may— because these explorations may uncover new ways of working that become our future guidelines and recommendations.
I hope you find ideas here that help your organization start experimenting with an Agile Community of Practice. If you have questions, please let me know at brian at practical agilist dot com.
If you enjoyed this, please clap and share. It means a lot to know my work on this blog is read and used by agilists out there in the world.
Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the practices and frameworks of the agile universe into easy to understand and simple common sense. I offer fractional agile coaching services to help teams improve affordably. See more at FractionalAgileCoach.com
How well is your team “being agile”? Our self-assessment tool focuses on 24 topics of modern ways of working including the Agile Manifesto and Modern Agile basics, XP, Design Thinking, Lean, DevOps, and Systems Thinking. It comes with deep links into the Practical Agilist Guidebook to aid continuous improvement in teams of any kind. Learn more at MakeTeamsAwesome.com
The Practical Agilist Guidebook is a reference guide that gives easy to understand advice as if you had an agile coach showing you why the topic is important, what you can start doing about it, scrum master tips, AI prompts to dig deeper, and tons of third party references describing similar perspectives. Learn more at PracticalAgilistGuidebook.com
Follow me here on Medium, subscribe, or find me on LinkedIn, or Twitter.
