Few thoughts about Communities of Practice
Hello, my dear readers and followers!
Today I would like to talk about Communities of Practice (CoP). In the last month or two I have touched that topic many times under different circumstances: at work, meet-ups and in think tanks. In this note, I would like to structure and wrap up some CoP-related ideas and thoughts I have in my mind right now.
Let us start from the classic definition of Community of Practice as it is given in the Wikipedia:
A community of practice (CoP) is a group of people who share a craft or a profession… A CoP can evolve naturally because of the members’ common interest in a particular domain or area, or it can be created deliberately with the goal of gaining knowledge related to a specific field. It is through the process of sharing information and experiences with the group that members learn from each other, and have an opportunity to develop personally and professionally (Lave & Wenger 1991).
That isn’t the only definition you can find. For example, Aaron Davis shares and sums up more of them in his article Defining a Community of Practice.
So, where do we start?
When companies grow bigger and try to introduce agile culture or make one of its own scalable, they always face the need for alignment especially regarding architecture, use of technologies and other important questions. Product side of things also needs to correspond to company’s strategy, but it is much easier to achieve an alignment there since a number of Product Owners or Managers is usually lower than of Software Engineers, Analysts, and QA specialists and it is much easier to keep the whole picture in a CPO’s head.
Some companies try to introduce some new role or even several roles to put that in place, and I personally have nothing against that as far as it corresponds to agile values and principles of self-organisation and empowerment. You just need to remember how easy it is to cross that subtle line and steal a decision-making right from the Dev team members.
There are also companies who try to immediately establish Communities of Practice as a solution to that. And that is where things start to get complicated.
When a company provides the context, establishes the boundaries, sets the goals, pushes people to participate and enforces the decision-making process, it creates an old-fashioned command-and-control committee under a new shiny label. Of course there are many examples of successful CoPs implementation, for example, all-famous Guilds at Spotify or other companies who have openly shared their approach online (e.g. Yodle or Wix.com).
The problem I see here is that attempt to introduce “CoP” as a way to immediately fill that “gap” is a huge risk. If we just step aside and think about it for a moment, is it really possible to create a successful and passionate CoP with such top-down approach? One of the best things about CoP is voluntariness and willingness of its members and organisers to participate. And all these successful worldwide-known companies like Spotify, Netflix and others have come to such structure in the natural evolutionary process of corporate culture’s development.
Here are just a few problems you may face creating an “artificial” CoP:
- Lack of people willing to participate who will start to fall off.
- Lack of trust between the CoP members leading to conflicts affecting work in their main teams.
- Someone can try to use it as a stand for influencing others instead of achieving consensus.
- Failure to have healthy and productive discussions without an external facilitator.
These are the problems I have come up with while thinking about such “fake CoPs”. Surprisingly (or not) many people share my point of view and fears.
Earlier this week I got lucky to make sure about it once again at Liberating Structures Lab Berlin meet up. There we used some of LS to collect and discuss our fears and ideas about CoP. Six standalone groups of 5 to 6 people with a different professional background (Agile coaches, Software engineers, Entrepreneurs) mixed have unanimously come to these and some other points of concern.
As it is always with Agile, there is no silver bullet for the problem that these companies try to solve.
The best thing to do, I think, is to apply the same approach we usually try starting Agile transformations — start with people willing to volunteer for that. Find them, put them together and let them decide how to do it best way on their own. And, first of all — trust them and be patient. You and the company will not get results “right here, right now”, but if and when everything starts to work, the final result will be of such a high quality that you could not even expect back in the early days.
Once again thanks for reading my notes and please let me know what you think in the comments. You are also welcome to clap if you really enjoyed reading that article! I also invite those of you who haven’t done it yet to examine my lists of top Agile:
P.S. As you might have already understood from that article or if you follow me on LinkedIn or Facebook, I have moved to Berlin and started my new job as an Agile Coach @ N26. Will be more than happy to meet you at some local meetups or conferences and get to know in person.
