... the Scrum organization and its roles are in place. Development Teams are working effectively and autonomously on building product. The teams are cross-functional, 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 organizational 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 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. 
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 Development Team 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  has shown through research 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 kaizens 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.
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.  Spotify has several structures in place called tribes, chapters, and guilds that provide a natural place for various flavors of cross-team fertilization.  In Siili Solutions in Helsinki such groups are called tribes. Progress Software 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, p. 228.
 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 1 November 2017).
 —. “Situated learning.” Wikipedia. https://en.wikipedia.org/wiki/Situated_learning (accessed 1 November 2017).
 Henrik Kniberg. “Spotify Engineering Culture Part 1 (Agile Enterprise Transition with Scrum and Kanban).” Youtube.com, https://www.youtube.com/watch?v=4GK1NDTWbkY (accessed 13 June 2017).
Photo from: PublicDomainPictures.net, http://www.publicdomainpictures.net/pictures/220000/velka/monarch-butterflies.jpg), (under CC0 1.0 license).