Cultivate learning between teams

Description

The role of leadership is to foster an environment and incentive for teams to share learning. Teams are the centre for knowledge generation. However, natural tribal instincts tend to drive a "Not invented here" culture, leading to reinvention and wasted effort. In addition, hard-won knowledge stays within team boundaries leading to relearning waste in other teams.

Leaders work to catalyse and support an environment that encourages and rewards learning and knowledge sharing as a successful part of the outcome of teams' work.

Rationale

Principle 11 of the Manifesto for Agile Software Development, "The best architectures, requirements, and designs emerge from self-organizing teams", makes it clear that knowledge is best created from within teams rather than imposed by an external domain expert. However, there is a clear need to create a shared purpose between teams to create a broader scope of "us" to include fellow teams to avoid a “not invented here” syndrome. If teams have discovered a good way of working, this should be shared with other teams. When it comes to factors such as “how to do end-to-end testing” or “having an aligned architecture”, there needs to be incentive, time and mechanisms in place to incorporate knowledge and practice into the collective team of teams "Transactive Memory".

The traditional management solution for creating alignment is to have special-purpose teams (e.g. an architecture board) which then impose their decisions on the value-creating teams. This strategy has a number of challenges. It undermines the autonomy and empowerment of teams and usually results in lower-quality solutions suffering a lack of feedback and learning loops, which teams then find hard to buy into. Instead, trust value-creating teams to make these decisions themselves but provide mechanisms and time so that teams can collaborate across team boundaries to create the necessary alignment.

Related Principles

• Create the environment for people to thrive
• Foster a high trust environment
• Maximise engagement
• Create clarity of purpose
• Create a Learning Organisation
• Favour Teams with broader Solution Accountability
• Favour Teams with broader Business Domain Accountability
• Self-managed Team of Teams
• Amplify Speed and Quality of Learning Cycles
• Use the Definition of Done as an enabling constraint
• Maximise the Scope of Product Increment
• Support autonomy with clear boundaries
• Technical leaders as coaches, mentors and community leaders
• Invest in quality
• Product solution architecture is driven from within development teams - Contending
• Self-managed teams - Contending
• Maximise Team autonomy - Contending
• Maximise team empowerment and localised decision making - Contending

Related Patterns

• Inner Source - shared code ownership across teams with open source patterns and culture for ongoing evolution.
• Group Design Workshops - cross-team and cross-discipline workshops to evolve design and evaluate experiment outcomes.
• Set-Based Concurrent Engineering across multiple teams running parallel experiments with collective learning.
• Communities of Practice or Community of Interest

Examples:

• Salesforce’s Virtual Architecture Team (VAT)
• Spotify’s Chapters (and partially guilds, when it comes to sharing knowledge, rather than creating alignment

These are effectively examples of Nonaka and Taceuchi’s Middle-Up-Down management described in The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation (Nonaka & Takeuchi, 1995)