Favour Teams with broader Solution Accountability

Description

Teams with broader solution accountability, i.e. the capability to operate in as many parts of the system under development as possible, are beneficial in a scaled environment.

Rationale

In the development of large products, it is very difficult for individuals and teams to have a whole system understanding, hence the tendency of many companies to create teams with specialised knowledge. And the consequence of this is a reduction of accountability for the teams, which leads to suboptimal design decisions, conflicts at the interfaces and increased coordination effort.

In large product development it is essential for teams to be able to make decisions from a global perspective rather than a local one: a global optimum in a complex system is not the sum of local optimums! Local optimisations might play against each other and pull you away from a global optimum. Hence the need for teams to understand the whole context of what they are working on: act locally, but think globally.

Furthermore, everyone should be involved in thinking and implementing: don’t split out discovery, innovation, delivery, operations, … across separate teams, ensure teams are involved in all activities. In other words: don’t just implement a new version of Taylorism, where some people do the thinking, and others just have to implement their ideas!

Unfortunately, there is pressure in organisations directed towards improving the local efficiency of each team (local optimisation), and it is often guided by some combination of product and organisation structures and, more in general, governance ideas that have more to do with Taylorism than modern collaborative work. For example, departments politics, knowledge silos, ...

This leads to some consequences:

• Teams might excel in their local environment, yet the overall product does not work, as the contributions of each team are not compatible with each other
• Integration of the contributions of each team happens in later ‘phases’ of development. Hence they are on the critical path
• This also results in late learning and slower feedback loops, thus reducing the adaptation capabilities of the organisation
• Because of their limited understanding of the system, teams might implement parts that are already available somewhere else in the same part of the organisation
• As teams have a limited system understanding, collaboration is increasingly difficult because of the localised knowledge of each team
• The effort for coordinating such teams increases - be it self-managed coordination or via dedicated coordination roles - requiring more structure and hierarchy, thus moving in the opposite direction of what agility suggests. Everybody is busy, yet progress is very slow
• With the reduced view of the purpose and the lack of visibility of the overall progress and of how individual contributions support reaching the common goal, motivation is likely to suffer

Therefore, it is very important to create teams trying to maximise the system understanding available in each team. This should be one of the criteria used to form the teams, but system understanding needs to be nurtured in the development organisation. This requires the implementation of initiatives to promote learning:

• Teams involved in discovery and drafting of the Backlog
• Common design sessions
• Shared Sprint/Release Planning and Reviews
• Cross-Team Pair/Mob Working
• Cross-team self-managed collaboration during the iterations (especially for significant architectural changes)
• Continuous Integration and Continuous Delivery
• Common Product Increment
• Presentation/training of technical and domain info
• Knowledge-sharing initiatives like open spaces
• Communities of practice

To implement a complex product involving several teams, there is the need for learning about the whole system. We suggest this learning should be preventive rather than fixing the implementational problems resulting from the absence of such knowledge.

A single team agile has, by definition, broad solution accountability because they are accountable for the whole development, and it is one of the motivators that make this team successful.

This characteristic needs to be kept as much as possible when scaling to multiple teams, despite whatever organisational pressure might push in a different direction: at scale, it becomes harder to implement: the larger the organisation, the more difficult it becomes to have teams with a broad system understanding and ensure empowerment over the whole system (in XP: Collective Code Ownership).

In his 1971 article, Winston Royce notices the issue with late integration (, page 2).

• Poor/locally optimised design decisions
• Motivation (reduces purpose)

Involving “Delivery” teams in the end-to-end value stream (idea to operation) work has many benefits:

• Reduces waste (relearning) and Lead Times caused by hand-offs
• Reduces waste caused by building the wrong thing
• Provides shared context and improved business understanding
• Increases team empathy for users, customers and stakeholders
• Increases team passion and buy-in to the Product
• Increases the creativity and innovation of designs whilst keeping them more practical for implementation and operation
• Provides essential feedback loops to design decisions

Related Principles

• Maximise team empowerment and localised decision making
• Product solution architecture is driven from within development teams
• Favour teams with maximised cognitive diversity