...the Scrum organization and its roles are in place. Development Teams are working effectively as Autonomous Teams to build product. They are Cross-Functional Teams, and the expertise in individual teams grows only through the insights that each team gains from its own work.

✥       ✥       ✥ 

Core competencies are a crucial element of enterprise value that cuts across development organization boundaries. While Scrum focuses on improving the process and improving the product, it’s crucial to invest in the people who do this work and in their skill sets that support enterprise needs in both of those areas.

“Empowerment” and “self-managing teams” are often rallying cries for organizations transitioning to agile approaches. But empowering a team can insulate it, and cause it to form its own boundaries and to decrease sharing of information, including long-term insights that may contribute to enterprise-wide domain knowledge, business acumen, or strategy (see “The Limits of Participatory Management” in [1]).

Knowledge relationships form a lattice structure in any non-trivial human organization. Yet most formal organization structures (including organization into Scrum products and organization of Scrum products into Scrum Development Teams) are hierarchical. Peter Senge quotes Bohm, noting that hierarchy is antithetical to the dialogue that lies at the foundation of organizational learning ([2], p. 288).

People enjoy mastering their skills as individuals, but such skill development can go only so far for individuals working in isolation. Cross-fertilization and broad diversity in ideas, technologies, and cultures lie at the root of innovation (see “Liquid Networks” in [3]).

Therefore: 

Create ad-hoc “birds of a feather” groups for each area of significant enterprise core competency or developer interest, where interested parties can trade notes on technologies, domain knowledge, and processes that are key to enterprise advancement.

In the spirit of self-organization, each team—or maybe each team member—makes an autonomous decision about whether to join the community or not. However, a team does not get a voice in the community without also agreeing to abide by the decisions of the community.

✥       ✥       ✥ 

Such groups can also be good loci of personal and career development, and can provide an outlet for the people-management talents of a traditional management-heavy organization that transitions to Scrum. Managers manage people; Scrum Teams manage product.

Along with autonomy and a sense of transcendent purpose, Pink (in [4]) has highlighted research showing that a sense of mastery is a key enabler for team achievement and well-being. Birds of a Feather are local communities to hone organizational excellence, with the potential byproduct of increasing individual effectiveness. Such teams become loci of Team Pride and the potential for feeding the sense of mastery that motivates team players. Such fora have taken on many forms under many names over the years: birds of a feather, guilds, quality circles, communities of practice, and others.

This is not matrix management. The birds-of-a-feather organizations are not loci of product control nor, in fact, should they be entwined in any kind of externally applied control. All such organizations are self-managing. The best of these organizations form spontaneously around the enthusiasm for some core competency. In some cases, for the formation of such groups, encouragement from ScrumMasters or Product Owners may be necessary. In all cases, these groups should agree to an informal charter that supports their existence and should periodically review whether they are adding value to their constituency, to the company, or to the community. Leverage managers (Involve the Managers) who can provide support and organizational commitment to broaden the scope of influence of such groups across development teams, products, or entire organizations and companies.

As in a neighborhood, our actions affect one another by virtue of our common location and resources—so too with Birds of a Feather groups. However, it should be emphasized that Birds of a Feather groups normally have no mandate to implement proposed improvements; their main roles are to help everyone become better informed and to remain better aware of improvement ideas, experience, expertise, suggestions, and efforts across the enterprise. Individual Scrum Teams retain the mandate to try new kaizen (see Kaizen and Kaikaku) and to assess their effectiveness.

Don’t neglect business-domain knowledge as a key opportunity for professional growth among developers. Technical knowledge is often available as a commodity, but key business competencies may be hard-won and often are available only through scarce resources. What’s more, the payoff is high from developers being able to understand the business. Richard Gabriel reports that at his company, Lucid, the engineers were better able to relate their work to a corporate balance sheet than the business people could.

If your organization is too small for separate Birds of a Feather groups to make sense, join some local meet-up groups instead. Do that anyhow.

In 1991, Lave and Wenger introduced the concept of Communities of Practice [5] to describe the theory of situated learning which, in short, is about individuals acquiring professional skills through social co-participation (from Wikipedia [6]). Spotify has several structures in place called tribes, chapters, and guilds that provide a natural place for various flavors of cross-team fertilization (as related by Henrik Kniberg [7]). Siili Solutions in Helsinki calls such groups tribes. Progress Software in the United States used such a group to select a single defect tracking tool for all teams to use, so that everyone in the whole organization knew where to find and report defects.

[1] Charles Heckscher. “The Limits of Participatory Management.” In Across the Board 54, Nov./Dec. 1995, pp. 16-21. Published by The Conference Board.

[2] Peter Senge. The Fifth Discipline. Doubleday, 2006.

[3] Steve Johnson. “Liquid Networks.” In Where Good Ideas Come From. New York: Riverhead Books, 2011, Chapter II.

[4] Daniel Pink. Drive: The amazing truth about what motivates us. New York: Riverhead Books, 2011.

[5] —. “Community of Practice.” Wikipedia. https://en.wikipedia.org/wiki/Community_of_practice (accessed 5 June 2018).

[6] —. “Situated learning.” Wikipedia. https://en.wikipedia.org/wiki/Situated_learning (accessed 5 June 2018).

[7] Henrik Kniberg. “Spotify Engineering Culture Part 1 (Agile Enterprise Transition with Scrum and Kanban).” Youtube.com, https://www.youtube.com/watch?v=4GK1NDTWbkY, February 2017 (accessed 28 January 2019).

Picture credits: Shutterstock.com.