Team

Specific types:Application/Feature Team, Module Team, Service Team
consists ofTeam Product Owner, Team Scrum Master, Working Team
Multiple are parts ofCluster
createsInspectable Result
works in Iteration

The Team is the basic element of an agile organization and forms the home of working people. Up to nine related Teams form a Cluster.

Most of the work takes place in stable and long-lasting Teams. Due to the stability or “longevity”, the teams are available in the event of problems even if the Application or Market Variant is not currently being revised (ie when the classic project teams no longer exist).

P4 adopts the basic structure of a Scrum team. It consists of a Team Product Owner , Team Scrum Master and the Working Team who works together to create value for the Stakeholders. The principle of the separation of powers creates clearly defined areas of role responsibility that complement each other in the Team.

The Team Product Owner is responsible for maximizing the value of the “Product” resulting from the work of the Working Team. How this happens can vary greatly depending on the organization and Working Team, as well as the experts working in them. The Team Product Owner is the only person responsible for managing the Team Backlog.

The Working Team consists of three to nine members plus the Team System Engineer, who work out finished and inspectable results in each Iteration and ideally present a potentially deliverable system or subsystem increment in the Team Review at the end of the Iteration .

The Team Scrum Master is a “Servant Manager” and is responsible for encouraging and supporting team work in accordance with the Scrum and P4 rules by helping everyone involved to understand the values ​​and practices.

Unlike Teams, Groups are mainly there to communicate and make decisions across different levels and teams. The simple principle applies: “Teams work, groups talk”.

The Working Team

In addition to the Team System Engineer, the Working Team consists of the so-called Nucleus Team: these are persons who work in this Team for a predominant part of their working time (> 80%), plus the Extended Team: these are persons who work in a few teams (between 20% and 80%).

Nucleus Team members sit and work together, coordinate their work in the Team Sync every day and have shared responsibilities as a team.

Extended Team members attend the Extended Team Sync (e.g. twice a week) and sit together with the Nucleus Team when necessary. This requires "slack" with regard to additional seats and workplaces in the team area. Extended Team members can work with a few Nucleus teams. The capacity that they provide for each team is planned at Cycle or Iteration level in the Team Calendar. The total capacity of each team member must never exceed 100%, ie if an Extended Team member is required more in one team, the capacity for other teams must decrease.

The members of the Nucleus and Extended Team make their work visible on the team's team board (also called Kanban Board, Task Board or Scrum Board).

The following roles are not part of the Working Team:

Supporters work in their Service Team (team flovor "yellow"). They are visited by teams or visit teams on request. Supporters are usually planned by the Team Product Owner of the Service Team (Aka Service Owner) and usually have their work items as Backlog Items on their own team board.

Stakeholders are people who are interested in the team results but do not work within this team. For this reason, members of other teams can also be Stakeholders. Stakeholders participate in a team's iteration review and provide open and transparent feedback.

Descriptions of Team types (aka “Team Flavors”)

Team types describe different lineups of Teams within the Organization, as well as their type of ​​responsibility.

Service Team

Service Teams provide a service or provide their expertises to other teams.

There are two types of collaboration with the other teams:

  1. Service: Teams commission the Service Team to visualize and manage their work on a Kanban board
  2. Resource provider: Individual members of the Service Team temporarily work as Extended Team members in the Module Teams or Application Teams.

Note: Classic organizations also divide their departments by skills. In the P4 framework, however, only the teams that really provide an internal service should work as competence teams. All other employees should be organized in Module or Application Teams.

Module Team and Platform Team 

Module Teams are responsible for versioned Modules or Components. Complex systems are usually divided into System Elements or Modules as sub-units. Platforms are often used, in which the Modules form the basic building blocks for combining and creating System Variants and Applications. Often you will find specific competencies in Module Teams that are only required for a certain Module.

When using and developing Modules, the definition of System Interfaces and their long-term stability and compatibility is an important criterion. For this, the Team System Engineers of the Module Teams in the Team System Engineer Group work together on the System Architectures.

Application Team and Feature Team

Application Teams use the Modules to build concrete Applications, ie System Variants that are configured for specific markets. They may also be called "Product Teams" when there is only one product that deosn't need to be configured on developement level. The requirements, definition, configuration, integration and testing of the applications are entirely the responsibility of the interdisciplinary Application or Product Teams, who also assume system responsibility over the entire product or system life cycle.

Different System Variants can be developed by different Application Teams. If System Variants are too complex for an Application Team, the Functions/Features are distributed to multiple Feature Teams. Then, it is important to determine which team will carry out the integration. In most cases, it makes sense to create one Application Team and multiple Feature Teams.

More Teams

In some organizations there are special Support Teams for the better separation of development topics and support and maintenance topics, which accept unplanned inquiries and work, clarify and solve simpler topics themselves. This shields the development teams from unplanned activities and enables better planning and predictability of the development teams.

.


Further suitable links: Team flavors vs Team Topologies

Events Roles Groups Artifacts
Team Planning

Team Sync

Team Backlog Refinement

Team Review

Team Retrospective

Team Product Owner

Team System Engineer

Team Scrum Master

Working Team

Community of Practice

Team Backlog

Inspectable Results

Team DoD

Team Improvement Backlog