Team Level: Collaboration within the Teams

The Team is the basic element of an agile organization and forms the home of employees.

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 and the Team System Engineer , who work out finished and inspectable results in each Iteration and ideally present a potentially deliverable system or subsystem 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.

The Working Team

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

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

Extended Team members take part in the Extended Team Sync (e.g. twice a week) and sit together with the Nucleus Team if 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 you can 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 in one team, the capacity for the other teams must decrease.

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

Supporters   work in their Service Team (team flovor “yellow”, see below), are visited by teams or visit teams on request. Supporters are usually planned by the Service Owner of the “expert team” and usually have their order cards on their own team board.

Stakeholders are people who are interested in the team results but do not work in the context of 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 skills or provide a service.

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 expertise 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.

Modules Team

Module Teams are responsible for Modules or Components. Complex systems are usually divided into Modules as units. Platforms or modular approaches 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 Modules in the Team System Engineer Group work together on the architecture of the systems

Application Team and Feature Team

Application Teams use the Modules to build concrete applications, ie system variants that may be configured for special markets. The requirements, definition, configuration, integration and testing of the applications are entirely the responsibility of these interdisciplinary Application Teams, who also assume system responsibility over the entire product or system life cycle.

Different system variants can be supervised and responsible by different Application Teams. If individual system variants are too complex for an Application Team, the Functions are distributed to several feature teams . It is important to determine which team, in what form, will carry out the integration. In most cases, it makes sense to organize yourself in an Application Team and several 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.

.

\r\n


Further suitable links:

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