The P4-Dev framework describes a new type of organizational structure for companies that develop physical products. Together with its sister framework P4-Ops for operational business, it describes a holistic operating system for product creation in modern organizations that implement the principles of lean, agility and New Work. Version 1 has now been launched in German language. English follows within next weeks.
Pragmatic Paradigms, Principals & Practices for Development
The P4-Dev Framework (short P4) is based on the Scrum framework and extends this with additional levels in order to be able to represent organization sizes between 30 and approx. 1000 people (aka scaling). At these levels, new roles, artifacts and events are defined according to the Scrum principles. As an alternative to Scrum, teams can also use Kanban.
P4 is divided into the description of roles, artifacts and events:
- Roles: The description of the organization in the form of single roles, teams and groups
- Artifacts: The backlogs, the backlog elements and element types, as well as the different result types and products
- Events: meetings and their content
Many of the pragmatic principles and practices described are known from other systems and frameworks and are integrated holistically in the P4 framework:
- Toyota Product Development System: continuous flow of work and the pull principle
- Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), Nexus, Scrum @ Scale: Scaling agile teams
- The Lean Startup: Fast learning and adaptation with the market
- Design Thinking: Exploration of the problem and solution space by quickly generated prototypes
- Lean Product & Process Development (LPPD): Knowledge-based-development, Visible Knowledge and Set-based-design
- Theory-of-constraints and critical chain: The regulation of workflows by aligning them, and the optimization of bottlenecks (constraints)
Why another scaling agile framework?
Although there are a number of frameworks for scaling agility, they lack some elements that are particularly necessary for the development of physical products and complex systems. Therefore, we have added some essential elements into the P4 framework:
- The P4 organizational structure takes into account not only interdisciplinary (cross-functional) teams with responsibility for features, products or applications, but also teams supplying modules, components and platforms, as well as teams that provide special services or expertises to other teams . The high level of specialization in today’s system development makes the different types of teams necessary. In the P4 framework we call this team attribute the “team flavor”.
- In addition to the roles of the Product Owner and the Scrum Master, P4 introduces the role of the System Engineer, in which the responsibility for technology and architecture of a team is bundled. The System Engineer also represents his team’s technological expertise at the next higher scaling level.
- For the aspects of employee education within interdisciplinary teams, as well as the development and maintenance of domain specific tools, P4 integrates Communities-of-Practice.
- At the scaling levels (Cluster and Organization), groups are formed from members of the “lower” level. This overlap principle simplifies information flows between the levels. Events at the involved levels must be decoupled for what the so called Cadence provides a kind of “timetable” for the organization.
- The backlog structure and new Backlog elements support the development of physical products and represent a systemic guiding procedure. In particular, the concept of Knowledge Gaps enables structured knowledge-based development and iterative learning.
- The collaboration model of Nucleus, Extended Team, Supporter and Stakeholder integrated in P4 expands the basic Scrum model (people are 100% team members or not in the team) and thus supports the collaboration of experts with several teams. The collaboration is completely integrated into the events of the organization.
Extensions
In addition to the practices described above, proven and tested elements from classic models are integrated into the “P4 toolbox”, such as Requirements and Test Management, as well as Model-based Development from Systems Engineering.
Since P4 is a framework, other beneficial and deemed necessary practices can be integrated. However, it is essential to ensure that the P4 principles are observed.
What is different from the classic matrix organization?
A classic matrix organization usually consists of the specialist departments (the lines) and a project organization in which interdisciplinary cooperation takes place in many parallel projects. Each employee usually works on several projects at the same time. In large companies there is sometimes a third dimension, which divides the line organization into an international and a site-related line with the corresponding additional superiors (sometimes called “dotted line”).
In today’s working world, this “serving several masters” is often a problem, since most of the work is done in the projects, but the project managers are often less empowered and, in case of a conflict, it is usually the line managers who prevail. This is reinforced by the large number of line managers in the interdisciplinary project team, who are mostly driven by different goals, acting in different directions.
In modern agile frameworks, such as P4-Dev, the power relationships of the matrix are reversed: The team that is stable over time and in which an employee is located has the strongest “bond” and gets the most capacity of the assigned employee, ideally 100%. An employee only works for several teams in exceptional cases (aka Extended Team member). The type of team (in P4 called “team flavor”) determines whether a team works interdisciplinary with product responsibility, partly interdisciplinary with component/module responsibility or as a specialist group, e.g. as a service providing team of a certain technical competence.
The classic technical line merges into the Communities-of-Practices, in which experts exchange knowledge, where training takes place, and technologies and tools are maintained and further developed.
Teams working together on the same products organized in Clusters, similar to the “Agile Release Train”, the “Value Stream” or the “Program Level” in other agile frameworks. The overall organization consists of several clusters that are responsible for different product areas. This results in a high coherence of goals and responsibilities of the teams in the Cluster.
In P4 there are no projects, no project managers and no project teams. Contents of product development projects are presented in the backlogs of the Organization, the Clusters and the Teams. The classic projects most closely correspond to the system or application releases planned at the organization’s portfolio level.
Direct link to the P4-Dev-Framework.