Cluster – P4-Dev Framework

Each Cluster consists of several Teams and divides the Organization into related and consistent Value Streams. The Clusters are responsible for the various Systems, Applications and Products for specific Markets .

Many different competencies are usually required for the implementation of extensive and complex systems. In order to work together on such a project, a single Working Team with a maximum of 10 people is usually not enough. The cooperation between the Teams has to be regulated and areas of responsibility have to be defined. To achieve this, teams are brought together in a higher-level organizational unit. This overarching organizational unit is called the P4 framework Cluster . A Cluster has system responsibility for one or more related systems (or products), for a product area, a platform or large module.

By scaling the Scrum roles to the Cluster level, there are …

a Cluster Product Owner (CPO) representing the Team Product Owner ( TPOG ),
a Cluster System Engineer and the Team System Engineer Group (TSEG) as representatives of the Working Teams of the Cluster and
a Cluster Scrum Master representing the Team Scrum Master ( TSMG )

The three roles of Cluster Product Owner, the Cluster Scrum Master and the Cluster System Engineer form the Management Circle of the Cluster (see also the next paragraph).

Roles & groups

In order to organize the cooperation, in addition to the Teams, various groups are formed that regulate the three different areas of responsibility. The groups are formed on the principle of overlap from members of the Working Teams. In order to clearly regulate this dual affiliation, the working hours for working in the group are determined centrally. From the outset there is a clear agreement on when and how long the group will work together (Cadence).

There are the following groups according to the three areas of responsibility:

Market and Business: The Team Product Owner Group (TPOG) with the Cluster Product Owner (CPO)
Technology and architecture: the Team System Engineer Group (TSEG) with the Cluster System Engineer (CSE)
Processes, infrastructure and culture: the Team Scrum Master Group (TSMG) with the Cluster Scrum Master (CSM)

Cluster Management Circle

The Cluster Product Owner, the Cluster System Engineer and the Cluster Scrum Master form the Cluster Management Circle following the principal of separating powers. They support and complement each other in the decision-making of topics that reach their level or have been escalated to them by one of the three groups. According to the principle of local decision-making, most decisions are made at the Cluster or Team level and only a small proportion escalate. These constructs effectively prevents “lonely individual manger decisions”, because decisions are previously examined and discussed from all three directions, and thus effectively balanced.

The Cluster Management Circle forms an interdisciplinary group of managers who, like all other groups and teams, hold daily or weekly Sync meetings and Retrospectives.

Team Setups und Team Collaboration Models

Teams that work within the Cluster often deliver partial results and intermediate products to each other. To make this transparent for everyone, the Team Setup describes which people work in which Team and how the teams work together. The following options are available for this:

A Team receives an artifact as a supply (Knowledge, work results, Samples or Modules)
A Team receives a service (e.g. an EMC or acoustic measurement)
A Service/Expert team lends a person to another team for some Iterations (full-time at the Nucleus or part-time as Extended Team Member)
Two or three teams share Extended Team members
Two closely cooperating Teams can collaborate in the following ways (e.g. two Feature Teams working on the same Application or two Module Teams working against a complex technical interface)
- They pull their Team Iteration Backlog from the same Team Backlog and may have the same Team Product Owner,
- You have a Joint Team Sync one or more times per week,
- They do the Team Planning, the Team Backlog Refinement, the Team Review and/or the Team Retrospective together.

The collaboration model between two teams can be discussed and agreed in a playful way with the Team Collaboration Poker.

Workflows & Value Streams

Value Stream Maps describe the different areas of responsibility and delivery objects. For this purpose, the P4 framework uses the SIPOC description from classic organizational development. (Supplier >> Input >> Process >> Output >> Customer).

Example Value Stream

This example of a medium-sized organization shows the teams and the Value Stream (aka Workflow) visualized by arrows. The arrows in front of the teams indicate the planning, analysis, refinement and prioritization activities that take place before the teams start to work on work packages. The arrows from the teams' results to other teams indicate deliveries.

Application Teams work closely with the customer/user (not shown here). From this, a majority of their own backlog items are created. If several teams have to work on customer requests, the Team Product Owner of the Application Team takes these requirements to the Team Product Owner Group (TPOG). Application teams deliver their work results to customers in the form of released products (or applications).

Module and Platform Teams deliver their versioned and tested modules and platforms to feature and application teams.

Service Teams support other teams by delivering their services.

Note: The image above is interactive. Each element can be clicked on. To do this, it must be opened in a separate window by clicking on it.

Further suitable links: