A while ago I have been asking the community at Agile Uprising for some hints on how to setup communities of practice. I felt like I would need some support. I had a rough idea what I would want to achieve by establishing communities, but I was lacking the idea how to get there. The attention to the request was really good and I received a lot of hints all around the topic. Anyhow, they left me with the feeling, that I would have to take action to run experiments. I had to learn and find out by myself how communities of practice would work best for me. I did so. This is a summary of my journey to Communities of Practice.
How to Implement Learning?
The idea of setting up communities of practice sparked off from thoughts about learning within development teams. While being driven by functional product backlogs, I often heard complaints, that the teams would suffer from missing time to drive learning. This was targeted more towards technical and social skills rather than user needs. Training on the job did not really work for them. They were aiming for minimal viable products, which provoked working with existing means rather than engaging with opportunities for the future. This made the team feel like missing out the future. Indeed, this has been bad for the organization as motivation and innovation was constantly going down.
Measuring Learning
My first attempt to come around missing improvement – which I was running for a while – miserably failed from my point of view. I had tried to establish improvement buffers in our agile planning tools. Similar to buffers for bug fixing and refactoring, improvement buffers were meant to give autonomy to a team to decide when and where the would need time for learning. As said, it miserably failed. Other than bug fixes, learning was not really measurable. The visibility of progress and thereby missing transparency on success put questions on when and what to consider. In the end the buffer was used to improve quality and output from increased velocity, but not to foster learning.
Objective: The Black Belt
I started to think about ways to unlink improvements and learning from the day-to-day activities in a development team. Still, I wanted to maintain the functions and values of a team. It was more the ideas about training or coaching of best practices, which led me to the model of Communities of Practice (CoP). A colleague of mine was telling about an idea of establishing communities of practice as kind of black belt groups. When I heard that all members were asked to work towards improving their skills beyond the needful, I was convinced that CoPs were the way to go.
Managed vs. Self-Organized Groups
After taking the decision to set up communities of practice, I was missing out a good idea how to start. Engagement seemed to be pretty relevant and so I was concerned, that the start had to work out. I started to talk to various people from the teams to understand what they would be looking for. They did not lack of ideas, what they would have liked to address.
Anyhow, I was getting to the point that I did hard to distinct between teamwork and communities of practice. That has been the time when I have been reaching out for the Agile Uprising community. Could I count on communities of practice to be self-organized or would I have to establish leads? Would people start to collaborate because of a common interest or would everyone run for the personal concerns? Would communities of practice start to develop a own structure outside of the planned organization based on behalf of the interest of few people? My concerns turned out to be ridiculous. But at that time I was not sure where it would take me and my teams.
Start Now!
In the end it has been the Agile Uprising community and my colleague, who convinced me that we would have to start. Without start no experience, without experience no learning, and without learning no right or wrong. At that point we had setup few communities already, which were supposed to tackle concerns on quality, security, and architecture. Those communities were mainly engaged in understanding and learning. They were supposed to support the teams in taking the right decision. But they have not been meant to implement solutions by themselves. Anyhow, the topics by the teams were not classified that easily. Cross cutting concerns asked for joint effort as well.
Clash of Teams and Communities of Practice
Again, the differences in the nature of a community of practice and a development team had to be questioned. If both would take care for implementation, there would be a clash between the efforts spent in the development team and efforts for implementations done in a community of practice. It even would be questioned who would be in the lead. It was obvious to me, that there could be only one backlog and that had to stay with the team. So we defined the rule, that a community of practice would not be allowed to contribute to the code base by itself.
The Learning Community
The definition of ownership for a backlog and the code base turned out to be a perfect criterion. It separates implementation in teams from learning in communities. Whenever a community comes up with something, they see as relevant to be implemented, they must find a team, which sees the urgency to accept the topic in their backlog and which will drive priority. This sounds like a hard deal on the first hand side. But, it turns out to work pretty good if you consider, that team members run the communities of practice on their own behalf. Every topic handled in a community has the origin in the urgency derived from the teams. That’s closing the loop – check.
Alliance for Action Plans
In the end we still have been facing the issue, that some problems require joint actions across teams. As communities of practice have been dedicated to learning, it was not the right place to align actions. The alignment of actions was missing some dedicated format.
While individual teams had some very good ideas how to improve, they have been lacking the eligibility to address it with other teams and to claim capacities. I started to ask them to sit together and discuss, how joint actions could look like. And to make it more formal and more attractive for the teams, these kind of meetings got some special notion by calling them Improvement Coffees. Now, whenever I find someone with a topic, which requires some alignment across teams, I ask this person to create an invite for an improvement coffee.
Improvement Coffees
The purpose of an improvement coffee is to bring people from different teams together. They are supposed to start a loose discussion on a hot topic, where everyone could bring in ideas and views. This creates a common sense of urgency for the topic.
As a next step this group is been asked to align on a common action plan, which is supposed to be introduced in the irrespective teams, and finally put together in a joint action plan. Improvement Coffees are temporary thereby. As soon as an action plan is in place and implemented, there is no need for further coffees on this topic. Space will be freed up for new Improvement Coffees.
Information starts Flowing
I am still considering some infrastructure to make communities of practice and improvement work properly. This infrastructure is really relevant. It makes the whole process more formal and thereby people start to believe in the mechanics step by step. Most important is a central board in our Wiki, where everyone can find information about the instrument of communities and coffees and the listing of all current and planned sessions. The list is maintained by all people in the department.
Everyone, who has a problem or idea, can add it to the list. Every item in the list has a status (planning, active, pending) and an owner, so everyone can see to whom to turn to in case of questions. In our internal newsletter, we are providing an update on the activities once per week, which gives everyone in the organization a chance to know the current improvements and areas of learning we are striving for. It makes the value tangible.
Interest is Growing
After advocating communities of practice and improvement coffees for some weeks now, I start to get active feedback. I do not need to run after people anymore to have their interests entered in the list of communities and improvement coffees. Finally they also start to advertise their interest in the department. As participation is voluntary, they need to engage others, which requires activation. I have also been thinking about assigning a buffer of 5% to 10% of the overall capacity to the teams, which they can dedicate to work on communities and improvements. For now it turned out not to be necessary, as interest is a driver on ist own.
The lifecycle of learning – when to start and when to stop
Once per month we started off to facilitate a general dev talk. In there we review the status of the communities of practice and improvement coffees. We have found out, that few improvement coffees were addressing issues of higher interest, which required some sustainable follow up. They have been turned into communities of practice.
We also have communities of practice in place, which do not really take off. With them, people do hard to define the areas of learning. We still tend to make them a forum for encouraging joint action plans.
We have created improvement coffees for some of the actions plans, which turn out to work better for those groups. Presumably these communities of practice can be closed again after a while, if they turn our to be buckets for actions instead of areas of learning.
Irrespective where we start, there seems to be way forward. Things start to balance out. It feels like we are on the right way to have people in teams, which establish a lifecycle of learning based on the ideas of communities of practice.
It feels really good, that the members of our teams are taking on communities of practice and improvement coffees in their own interest now. Thank you, I love you for doing so!
English