Collaboration is the key to successful agile product development. A community of practice is a technique that helps us achieve this.
Inspired by the Agile Conference in Orlando in July I visited the Kennedy Space Center close to Cape Canaveral to marvel at good old Space Shuttle Atlantis. Watching the videos on how complex her mission was, starting from the first ideas of building a shuttle rather than a rocket up to getting her a flight ticket on a 747 back to Cape Canaveral!
https://www.youtube.com/watch?v=mtlW-45efw8
To me this is an excellent example of collaboration between many teams and parties to accomplish a complex mission. Hundreds of specialists work together. This can inspire large software teams, with many people, how to achieve a shared goal. The mission of good old Atlantis was very clear and precise. It was tangible for everybody. Every child is able to understand this while seeing the man in the moon. A common shared vision is the fuel to collaboration.
Mission
So the most important thing that we have to have before we can think of any technique for collaboration is a clear mission and vision. This goes before any method, practice or feature. Such an enormous mission as the space shuttle gets many people to collaborate. Maybe the next generation of spaceship will be developed by Scrum.
When many Scrum teams are working on a software product, they need to be aligned seamlessly, just like for a mission to space. So the first question should be “What are we building? What is our Mission?”. Not every mission has the clarity Atlantis had.
The second step is building a piece of working software. This is where the features come in. Integration of complex software between many teams spans technological aspects like architecture and testing. Dependencies between requirements that are developed by different teams have to get planned, so they do not cause constraints and impediments. Handling complexity of the dimension of Atlantis is demanding more from everybody than just sitting and waiting. Pro-activity in the name of the mission is what we need.
Collaboration
We want Scrum Teams to do this collaboration in a self-organizing fashion, to keep them in a state of accountability. Within a team it usually is not very hard to achieve a certain level of self-organization. We come across much more difficulties in communication between more than one Scrum teams. There seems to be a vacuum between them in many companies. A lot of this is created by the usually co-existing hierarchical management structures that have team leads and business units, sometimes still project managers. This leads to a stance in employees that it is their job to do the coordination between teams. Usually these managers were responsible in times before Scrum was initiated. Their duty was to resolve dependencies and prevent conflict. Now we expect the teams to organize it themselves.
Multi-Scrum-Teams do Scrum-of-Scrum meetings for coordinating their work, usually as a daily meeting. This meeting is not designed to solve problems, merely to identify issues. Teams find this mechanism too weak for collaboration on special technical details. Stronger mechanisms are needed.
Community of Practice
A technique that has become popular for working groups on demand is the community of practice. According to Wikipedia http://en.wikipedia.org/wiki/Community_of_practice
“A community of practice (CoP) is, according to cognitive anthropologists Jean Lave and Etienne Wenger, a group of people who share a craft and/or a profession. The group can evolve naturally because of the members' common interest in a particular domain or area, or it can be created specifically with the goal of gaining knowledge related to their field.”
Etienne Wenger in his book “Communities of Practice: Learning, Meaning, and Identity” describes a “Practice is, first and foremost, a process by which we can experience the world and our engagement with it as meaningful.” This brings us back to our mission.
Community on the other hand is a social aspect that presumes relationship between the members. Belonging to a group means acknowledging each other as participants. This is more than a job title.
Wenger, E, McDermott, R & Snyder, W.M., Cultivating Communities of Practice, HBS press 2002
Stages
In Communities of Practice: Development Stages by Etienne Wenger the stages of a CoP are described. As stated here, a CoP is like a living organism that grows and goes through transformations. He points out stages that can be observed, but should not be taken too literally.
Looking at these stages shows that the engagement and commitment of the members should drive the CoP and not the structure. This presumes a culture of openness in an organization. Employees only know themselves what they feel drawn to most.
Implementing Communities of Practice
To form a community of practice usually the thought leaders in that domain will initiate these. Important here is to enforce openness.
How to form a CoP: Community of Practice
Members of the CoP join in because of shared vision and mission. The result will be a learning experience in a certain domain of knowledge.
Successful Example
Spotify is a startup that has reached a high level of agile maturity on team and enterprise levels. On Agile2014 Ivarsson and Lindwall presented in "Leadership at Spotify" their way to coordinate special knowledge across teams, that works well for them. Mutual engagement in their team called squad, as well as in a chapter. The chapter is a community of practice in special domains like User Interface, Product Ownership, Architecture, Tools, Testing or other that spans multiple teams.
Cross-Functional Teams
The question frequently asked here is, how these specialists in CoP’s go together with cross-functional teams where we aim for generalists. A way of looking at it is the idea of a person with T-shaped skills (Wikipedia) where a single person likely will have a specialization in one area, while at the same time be able to apply knowledge in other areas in less depth. The idea of a brilliant developer that is a generalist in each domain a team has to cover is not a realistic model.
Culture Traps
In a company I met a team lead that was a very skilled and interested architect. He was the Scrum Master of a team at the same time. Because he was put into the job description of a team lead, he was never asked on issues of architecture. His company had serious problems on the side of architecture. A closed architecture team in the name of agile decided in a closed group how to solve the architecture problems of the company. In a more open culture with communities of practice that are opened to everybody in the company, he could get himself engaged in the special interest group for architecture.
Conclusion
A community of practice is a great technique to enhance collaboration across multi Scrum team environments. As with all practices applied in the agile context, care has to be taken to keep people and interactions over processes and tools.
Inspired by the Agile Conference in Orlando in July I visited the Kennedy Space Center close to Cape Canaveral to marvel at good old Space Shuttle Atlantis. Watching the videos on how complex her mission was, starting from the first ideas of building a shuttle rather than a rocket up to getting her a flight ticket on a 747 back to Cape Canaveral!
https://www.youtube.com/watch?v=mtlW-45efw8
To me this is an excellent example of collaboration between many teams and parties to accomplish a complex mission. Hundreds of specialists work together. This can inspire large software teams, with many people, how to achieve a shared goal. The mission of good old Atlantis was very clear and precise. It was tangible for everybody. Every child is able to understand this while seeing the man in the moon. A common shared vision is the fuel to collaboration.
Mission
So the most important thing that we have to have before we can think of any technique for collaboration is a clear mission and vision. This goes before any method, practice or feature. Such an enormous mission as the space shuttle gets many people to collaborate. Maybe the next generation of spaceship will be developed by Scrum.
When many Scrum teams are working on a software product, they need to be aligned seamlessly, just like for a mission to space. So the first question should be “What are we building? What is our Mission?”. Not every mission has the clarity Atlantis had.
The second step is building a piece of working software. This is where the features come in. Integration of complex software between many teams spans technological aspects like architecture and testing. Dependencies between requirements that are developed by different teams have to get planned, so they do not cause constraints and impediments. Handling complexity of the dimension of Atlantis is demanding more from everybody than just sitting and waiting. Pro-activity in the name of the mission is what we need.
Collaboration
We want Scrum Teams to do this collaboration in a self-organizing fashion, to keep them in a state of accountability. Within a team it usually is not very hard to achieve a certain level of self-organization. We come across much more difficulties in communication between more than one Scrum teams. There seems to be a vacuum between them in many companies. A lot of this is created by the usually co-existing hierarchical management structures that have team leads and business units, sometimes still project managers. This leads to a stance in employees that it is their job to do the coordination between teams. Usually these managers were responsible in times before Scrum was initiated. Their duty was to resolve dependencies and prevent conflict. Now we expect the teams to organize it themselves.
Multi-Scrum-Teams do Scrum-of-Scrum meetings for coordinating their work, usually as a daily meeting. This meeting is not designed to solve problems, merely to identify issues. Teams find this mechanism too weak for collaboration on special technical details. Stronger mechanisms are needed.
Community of Practice
A technique that has become popular for working groups on demand is the community of practice. According to Wikipedia http://en.wikipedia.org/wiki/Community_of_practice
“A community of practice (CoP) is, according to cognitive anthropologists Jean Lave and Etienne Wenger, a group of people who share a craft and/or a profession. The group can evolve naturally because of the members' common interest in a particular domain or area, or it can be created specifically with the goal of gaining knowledge related to their field.”
Etienne Wenger in his book “Communities of Practice: Learning, Meaning, and Identity” describes a “Practice is, first and foremost, a process by which we can experience the world and our engagement with it as meaningful.” This brings us back to our mission.
Community on the other hand is a social aspect that presumes relationship between the members. Belonging to a group means acknowledging each other as participants. This is more than a job title.
Wenger, E, McDermott, R & Snyder, W.M., Cultivating Communities of Practice, HBS press 2002
Stages
In Communities of Practice: Development Stages by Etienne Wenger the stages of a CoP are described. As stated here, a CoP is like a living organism that grows and goes through transformations. He points out stages that can be observed, but should not be taken too literally.
- Potential: Loose network of people with similar interests and needs
- Coalescing: Members come together and launch a community
- Maturing: It forms an identity takes charge of its practice and grows
- Stewardship: The community is established and acts as the steward of its domain
- Legacy: The community has outlived its usefulness and people move on
Looking at these stages shows that the engagement and commitment of the members should drive the CoP and not the structure. This presumes a culture of openness in an organization. Employees only know themselves what they feel drawn to most.
Implementing Communities of Practice
To form a community of practice usually the thought leaders in that domain will initiate these. Important here is to enforce openness.
How to form a CoP: Community of Practice
Members of the CoP join in because of shared vision and mission. The result will be a learning experience in a certain domain of knowledge.
Successful Example
Spotify is a startup that has reached a high level of agile maturity on team and enterprise levels. On Agile2014 Ivarsson and Lindwall presented in "Leadership at Spotify" their way to coordinate special knowledge across teams, that works well for them. Mutual engagement in their team called squad, as well as in a chapter. The chapter is a community of practice in special domains like User Interface, Product Ownership, Architecture, Tools, Testing or other that spans multiple teams.
Cross-Functional Teams
The question frequently asked here is, how these specialists in CoP’s go together with cross-functional teams where we aim for generalists. A way of looking at it is the idea of a person with T-shaped skills (Wikipedia) where a single person likely will have a specialization in one area, while at the same time be able to apply knowledge in other areas in less depth. The idea of a brilliant developer that is a generalist in each domain a team has to cover is not a realistic model.
Culture Traps
In a company I met a team lead that was a very skilled and interested architect. He was the Scrum Master of a team at the same time. Because he was put into the job description of a team lead, he was never asked on issues of architecture. His company had serious problems on the side of architecture. A closed architecture team in the name of agile decided in a closed group how to solve the architecture problems of the company. In a more open culture with communities of practice that are opened to everybody in the company, he could get himself engaged in the special interest group for architecture.
Conclusion
A community of practice is a great technique to enhance collaboration across multi Scrum team environments. As with all practices applied in the agile context, care has to be taken to keep people and interactions over processes and tools.