How communities of practice (CoPs) can assist scaled-up agile
Agile teams are being increasingly used in business, and have their foundation in agile software development. Agile software development encompasses a set of methods and practices in which solutions evolve through collaboration between small, self-organizing, cross-functional teams and their customers. The methods and practices are based on the values and principles expressed in the Agile Manifesto.
But can more be done with agile teams? The authors of a recent Harvard Business Review article, one of which is Jeff Sutherland, a cocreator of the Scrum form of agile, ask:
What if a company were to launch dozens, hundreds, or even thousands of agile teams throughout the organization? Could whole segments of the business learn to operate in this manner? Would scaling up agile improve corporate performance as much as agile methods improve individual team performance?
From studying the scaling up of agile in a wide range of companies, the article authors say the answer is yes, and that there can be substantial benefits in doing so. But they also alert that to make scaled-up agile work, changes across the organisation will be needed to ensure that the agile teams are effectively supported. Initially:
- Rather than issuing top-down plans and directives, the organisation’s leaders should lead agile by being agile.
- To get agile rolling, two essential tools should be used: a taxonomy of potential teams and a sequencing plan reflecting key organisational priorities.
Then, once the number of agile teams has been expanded, the authors recommend that companies constantly push for greater change in at least four areas:
- Instilling agile values and principles throughout the enterprise.
- Innovative product and process architectures.
- Acquiring star talents and motivating them to make teams better.
- Modifying funding procedures to reflect the dynamic nature of agile development.
Knowledge management and scaled-up agile
Further to the desirable organisational changes identified in the Harvard Business Review article, a recent master’s thesis1 alerts that agile methodologies were originally developed for small teams and small scale companies, with the application in larger settings considered troublesome in terms of project management, and in particular with regard to knowledge sharing across teams.
In response, from an examination of the literature, the thesis identifies communities of practice (CoPs) as offering a range of benefits to scaled-up agile organisations:
CoPs act as a mechanism for capturing and sharing tacit knowledge by letting people from different departments discuss common interests. This leads to a quick spread of best practices throughout the organization, it decreases the learning curve of new employees, and stimulates pools of knowledge. Thus, CoPs have have the potential to increase organizational performance by stimulating contribution of individual members on their own terms.
CoP design principles
Nine design principles for the scaled-up agile organisation CoPs are identified:
Design principle 1. The community must encourage an open and transparent culture which stimulates active involvement in the community. The open culture ensures participants are intrinsically motivated to contribute to the community and creates a welcoming atmosphere.
Design principle 2. The community must provide for an interesting and relevant agenda, so that participants know whether the meeting is going to be relevant for them and ensures that something is actually happening.
Design principle 3. The community should have a open access online platform as a data repository and online meeting place. It allows for distributed and time-limited teams to cooperate in an orderly fashion.
Design principle 4. The community should appoint all the appropriate roles needed for their success and educate these people accordingly. Light-handed management helps the community focus on their domain, maintain relationships and develop on its practice.
Design principle 5. The community should recognise multiple participation levels with fluid boundaries, so that participants can move freely through the levels and feel like a full member at every level.
Design principle 6. The community should host a kick-off session where the domain and scope of the community is determined and the strategic intent to be examined, so that participants will be able to recognise their skill set in the community and feel personally connected with the community, which leads to increased individual contribution.
Design principle 7. Start from existing premature communities, so that communities can leverage the existing resources and do not have to start from scratch.
Design principle 8. The community should maintain a suitable rhythm, so that the members stay interested as the agenda is always full but not get bored as they would if meetings were too often.
Design principle 9. The community should recruit from different departments and use … [introductory] internships, so that there is a wide variety of members and members know what they are getting into.
Three management principles were also identified:
Management principle 1. Employees should be allotted company time to dedicate specifically to the development of the community in the organization.
Management principle 2. CoP contribution can … be incentivized by implementing a form of reputation management.
Management principle 3. A community should be designed such that public and private dimensions are interrelated, meaning that community members should also meet outside the official meetings and discuss relevant matters in personal time.
- Buth, G.J. (2017). Cultivating communities of practice as key enablers for knowledge sharing in scaled agile organization. Eindhoven University of Technology. Master’s Thesis. ↩
Also published on Medium.
Bruce: I fear the article conflates Agile (as in the methodology) with agile (as in the adjective). The masters thesis references makes no mention at all of Agile. Understanding CoPs, as opposed to product or service lines, they certainly do enhance co-operation, knowledge sharing and innovation. And the key to their existence – and sustenance – is a clear demarcation of their domain. They operate best at the crossroads of organizational structure and knowledge taxonomy, allowing people in unrelated structural entities to participate in the ‘development’ of specific K domains. I’m not at all sure if the Agile methodology fits the spirit and purpose of CoPs, and visa versa.