... 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. Scrum indeed focuses on improving the process and improving the product, and it’s crucial to invest in 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. Yet empowering a team causes 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 ().
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 (, 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 ().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 ) 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.
This is not traditional matrix management. The bird-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, encouragement from ScrumMasters or Product Owners, for the formation of such groups, may be necessary. In all cases these groups should agree to an informal business case that supports their existence and should periodically review whether the group is living up to the business case.
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  to describe the theory of situated learning which in short is about acquiring professional skills by individuals through social co-participation (from Wikipedia ). 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 ). 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.
 Charles Heckscher. “The Limits of Participatory Management.” In Across the Board 54, Nov./Dec. 1995, pp. 16-21. Published by The Conference Board.
 Peter Senge. The Fifth Discipline. Doubleday, 2006.
 Steve Johnson. “Liquid Networks.” In Where Good Ideas Come From. New York: Riverhead Books, 2011, Chapter II.
 Daniel Pink. Drive: The amazing truth about what motivates us. New York: Riverhead Books, 2011.
 —. “Community of Practice.” Wikipedia. https://en.wikipedia.org/wiki/Community_of_practice (accessed 5 June 2018).
 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 13 June 2017).
Picture credits: PublicDomainPictures.net, image 214978 (under CC0 1.0 license).