Favour Teams with broader Business Domain Competence

Description

At the core of agility, the basic idea is to adapt our development to deliver customer value more effectively and quickly. Therefore, the organisational form should be designed to support this mode of operation.

This means two things:

1. Team membership is independent of organisational structure. Teams are shaped around Customer Value rather than within organisational departmental boundaries. A team should contain members from across the organisation, with the combination of skills required to create value for customers. This means the typical structure “per departments”, where every department delivers a part of the product, is not suitable to provide value, and the organisation should instead be organised in Teams that are capable of delivering working functionality for the Customer, where “working” in this context means from the conception through the implementation to the validation and the packaging needed to create a deliverable product
2. It is important to create Customer Value for the actual customers for that Product, so the Teams must understand the Business Domain and be empowered to take decisions in that domain. Many companies instead opt for Teams that deliver to other organisational departments (so-called “internal customers”): this hides the actual customers from parts of the organisation and impedes delivering real customer value (Denning, 14-17). The goal of adequately organising Teams should be to create “Feature Teams”, i.e. Teams that are capable of delivering end-to-end functionality to actual customers, hence reducing drastically the need for coordination among Teams, which is the primary driver of a heavy project management infrastructure and the major cause of slowness in decision making.

Customers don’t buy a part of the product but the whole product. This seems obvious, but it is essential to remember. Teams that depend on other teams will have limited impact and will be slower to deliver value due to handovers and wait-time.

This also connects teams to their impact and purpose, significantly increasing engagement.

In real-world scaled agile implementations, there might be exceptions - e.g. be some teams building reusable components which are orchestrated by other, more customer-centric teams, but most teams should be customer-centric.

Rationale

Probably the biggest challenge in creating an agile product organisation is to move away from the line/department based and towards a customer-centric feature-teams based organisation.

This requires a lot of perseverance from the management team, time and a good amount of self-reflection capability. But without this change, there is no significant benefit in implementing agility. While implementing the agile technical practices might help locally, in large scale product development, the primary source of dysfunctions is in the coordination overhead needed to ensure the whole development organisation is aligned and synchronised.

• Are teams involved in all phases of product development: ideation, discovery, ..., constantly interacting with the stakeholders to implement a product vision?
• Do teams deliver value for end users or, instead, mostly deliver artefacts to other parts of the organisation for additional processing?
• The teams will often reference “their” customers, end users, … and there will be a noticeable sense of purpose and motivation to achieve results.

Related Principles

• Favour Teams with broader Solution Accountability
• Maximise team empowerment and localised decision making
• Organise around value streams
• Favour teams with maximised cognitive diversity