On a multi-team project, it is possible for individuals to become isolated, speaking mostly to others on their individual teams. Good ideas are slow to propagate across the organization. Similar functionality is implemented differently by different teams. We put scrum of scrums meetings in place to reduce the impact of some of these problems, but those only go so far. An additional solution and one that is critical to the success of any large Scrum project is the cultivation of communities of practice.
A community of practice is a like-minded or like-skilled group of individuals who voluntarily come together because of their passion and commitment around a technology, approach, or vision. On a large project, these communities of practice are helpful for cutting across the boundaries of and pulling together individuals from the many crossfunctional teams. An example can be seen in the figure below.
The figure above shows communities of practice formed simply around various project roles. In addition, a sufficiently large project might have communities of practice form around technologies (a Ruby community and a .NET community, for example), around interests (mock objects, artificial intelligence, test automation), or around any thread of common interest to multiple development teams. A good example of a community of practice is the Virtual Architecture Team at Salesforce.com, as described by Eric Babinet and Rajani Ramanathan.
The Virtual Architecture Team (VAT) is “virtual” as it is made up of developers from every Scrum team. Members work on the VAT in addition to being on a Scrum team. The VAT owns maintaining and extending our industry-leading software architecture. They do this by defining the architectural road map, by reviewing architecturally significant changes to the code, and by defining standards to ensure consistent and maintainable code.
Communities of practice can span more than one project. For example, a community of practice around test automation may form and include members from multiple, completely unrelated projects. Because they span teams, communities of practice are a primary mechanism for spreading good ideas among teams and for ensuring desirable levels of consistency or commonality across a set of development teams. A community of middle-tier programmers might, for example, discuss and decide when would be the best time to upgrade to the latest version of application server software for a family of products. Discussions among members of an orthogonal test team would ensure consistent test tool usage and the sharing of good practices.
The most effective type of community of practice within Scrum organizations seems to be one that forms organically rather than by management request, although both approaches can be used for different purposes. Because self-organization is critical to successful agile teamwork, the formation of self-organizing communities of practice creates a powerful synergy. In this sense it is up to the organization and its leadership to create an environment in which communities of practice can form, flourish, and then fade away as they run their course. If you want communities of practice to form organically, you may need to provide some encouragement. Potential community members will need to know that it is OK—and in fact encouraged—for them to form communities. I’ve encountered a few situations where managers and executives gave their Scrum teams a great deal of leeway in self-organizing and were left wondering why no communities of practice formed. When I asked the team members about this, they told me they were under the impression that such informal groups would be frowned upon by management. Make sure your team members know that such cross-team communities are not only OK but encouraged.
Communities of practice are well worth the time and investment. The service they provide in aiding communication and coordination across a large organization or a large project is invaluable. If communities of practice have not yet formed in your organization, start one around a topic that interests you or is causing your organization pain. As that community begins to contribute to the organization, other communities are likely to form as well.
Additional advice on cultivating communities of practice and on specialized communities, such as improvement communities and the enterprise transition community, is provided in Chapters 4 and 17 of Succeeding with Agile.
Tags: large projects
Interesting post…
I have found “brown-bag-lunch” sessions as the most effective way of bringing these communities together.
Very interesting approach to handling these situations, which come about more often than many Agile shops probably admit.
A community approach like this can and should also happen in a Agile shop where you don’t necessarily have multiple teams working on the same project. In many shops the way QA handles the User Story is very different from one team to the next, the way the developers handle code are different, the way the Scrum Master and Product Owner runs their area is different.
One way this is probably more commonly handled is through the reporting structure. QA’s all report to one person, Developers all report to one person, Scrum Masters report to…..you get the picture. The downside to this approach is that while it ensures the “manager” is aware of the differences it doesn’t openly allow for communication laterally between team members. You might be a Scrum Master for one team doing things a certain way but could either help mentor or receive ideas from the SM on a different team.
A Community approach can strengthen individual team members in their roles AND strengthen each team working on a common projects.
In our shop, regular meetings with other Product Owner’s has been one way to handle this. It has been successful and met its purpose and intent. I do see value though in creating a more community approach which continually helps support and grow the PO’s in their roles.
Nice post Mike!
Hi Rajiv–
Brown bag sessions are particularly useful–especially when combined with the “Do Food” pattern (as described in “Fearless Change” by Mary Lynn Manns and Linda Rising).
Hi Jack–
In the Succeeding with Agile book, I discuss communities of practice in two ways. One is a technique for communicating among teams working together on a large project. This would be, for example, all the testers coming together periodically (e.g., the brown bags that Rajiv mentions) to talk about how the project is going. The second context is of having communities of practice that span the entire department (i.e., multiple projects). This would be all testers in the department talking even more broadly about issues that affect them.
Mike,
I have found our retrospectives so much better over lunch and drinks !!!
Compared to sitting in a conference room with a projector and the Scrum master taking notes and updating the spreadsheet.
BTW, After you mentioned it, I searched and found an interview with Lynda Rising on fearless change
For the benefit of your other readers- http://www.infoq.com/interviews/Linda-Rising-Fearless-Change
Hi Mike,
thanks for this post – great work! I would be really glad being a team member of an agile focused company, unfortunately I am following your blog only from theory.
Charly
Mike,
we started the community of practice idea within our firm a couple of years ago, and it has been very well received by our employees.
We organized them along requirements, quality, architecture and development/SDLC.
Our leadership actually initiated the creation of the COPs, but members were allowed to organize,determine objectives, and otherwise self organize.
our leadership is subsequently trying to turn it into more of an operational/management structure,but as the head of the development COP I’m trying to resist.
I would rather a community of practice act as a vehicle for passionate people to work together on work-related issues that are important to them. I also think members should be free to join or quit a community of practice according to interest.
Hi Jeff–
I agree with you that the best is a community of practice made up of people passionate about the issue they are working toward. And definitely one of the best ways to ensure that is to allow people to join or quit at will. In fact, one of the keys to a successful community is that participation is encouraged at multiple levels–there should be people who devote a lot of time and energy and there should also be people who dip in and out of the community.
A good way to do this is to have multiple ways of communicating–there can be weekly meetings for those with the time and passion to be involved at that level; there can be things like twice a year events where others can involve; there can be discussion boards for daily involvement, and so on.
Hi Mike –
This is an excellent post. I absolutely believe communities of like-minded people who willfullly come together to share and grow can escalate talent to new levels. I’ve lived it. I look at it like “mentoring”…..even if you don’t know alot – if you join a community you can learn very quickly.
Especially the “virtual” communities that social media has brought to us. Like Yahoo Groups, LinkedIN, PMI’s new “virutal Communities”. Even if you don’t have a group in your company…You can join with people from all over the world that are passionate about excelling. You can ASK QUESTIONS, other can share/mentor you with their experience.
Do you have any tips for us about “virtual” community success?
Thanks
Donna Reed
PMI Agile Community of Practice Rep, California
Hi Donna–
One of the best tips I’ve come across for communities of practice, whether virtual or physical, is to invite different levels of participation. People should be allowed to be very active or only moderately so. In fact, many of the online communities have “lurkers” who never contribute to the community but who draw much value from just listening. (And the hope is that one day each contributes when they feel comfortable doing so.)
Another tip I find myself giving often is to combine familiarity with excitement. There’s value in holding regular events (e.g., a virtual community with it’s monthly phone call and a guest speaker). But the community is kept vibrant by occasionally mixing it up and doing something completely new.
Thanks for joining the discussion here.
I think this diagram would be enhanced by the addition of the Product Owner / System Engineer role. On large projects you always have this constituency, and collectively they may often need their own Community of Practice.