Organizational Levels – P4-Dev Framework V2

Cycle Transfer within the Inter Cycle Week

18. August 201915. May 2020 Oliver Schönfeld

The Cycle is a kind of large iteration at the Cluster level , it could also be called a “cluster iteration”. The cycle is usually also used for the Portfolio level of the entire Organization . The Cycle consists of several Iterations , a preamble consisting of Cluster Planning and a trailer consisting of Cluster Review and Cluster Retrospective. Since these events take a significant amount of time, the P4 Framework provides for a complete week every quarter, which is referred to as an Inter Cycle Week. This approach does not confuse the iteration events, which always take place on the same day of the week.

The Inter Cycle Week is exactly between the Iterations of two Cycles and starts on the day after the Team Retrospectives, not on the following Monday. It ends the previous Cycle with a Cluster Review and a Cluster Retrospective (together with a Portfolio Review and an Organizational Retrospective if the Organization level also uses Cycles) and starts the next Cycle with Cluster Planning (with a previous Portfolio Planning, if applicable). The following picture illustrates this:

Legend:

CPL=Cluster-Planning, CRef=Cluster-Backlog-Refinement, CRv=Cluster-Review, CRt=Cluster-Retrospective

\r\n

Further suitable links:

Events

Roles

Groups

Artifacts

Team Planning

Team Sync

Team Backlog Refinement

Cluster Backlog Refinement

Cluster Review

Cluster Retrospective

Organisation Retrospective

Team Product Owner

Team System Engineer

Team Scrum Master

Cluster Product Owner

Cluster System Engineer

Cluster Scrum Master

Portfolio Owner

Portfolio Architect

Organisation Scrum Master

Working Team

Community of Practice

Team Product Owner Group

Team System Engineer Group

Team Scrum Master Group

Cluster Management Circle

Cluster Product Owner Group

Cluster System Engineer Group

Cluster Scrum Master Group

Organisation Management Circle

Team Backlog

Inspectable Results

Team DoD

Team Improvement Backlog

Cluster Backlog

Usable Knowledge & System Increment

Cluster DoD

Cluster Improvement Backlog

Portfolio Backlog

Systems & Applications

System Platforms & Variants

Organisation DoD

Organisation Improvement Backlog

Team Tasks

13. August 201914. May 2020 Oliver Schönfeld

Team Tasks are activities and actions that a Working Team plans and carries out in order to achieve Team Goals . Team tasks are part of the Iteration Backlog and are usually only crated and planned in the Team Planning event.

\r\n

Further suitable links:

Events

Roles

Groups

Artifacts

Team Planning

Team Sync

Team Backlog Refinement

Team Product Owner Group

Team System Engineer Group

Team Backlog

Inspectable Results

Team DoD

Team Improvement Backlog

Team Goals

13. August 201914. May 2020 Oliver Schönfeld

Team goals are the most used elements of the Team Backlog . They describe the goals and (interim) results of the team regarding a Feature, a Module or a Service , depending on the type and responsibility of the Team .

Generally speaking, the Working Team turns Team Goals into Inspectable Results.

Samples & Integrations (Backlog Item Type)

13. August 201914. May 2020 Oliver Schönfeld

Samples & Integrations represent all work that is required to develop, build and test prototype samples (whether virtual or physical). These Samples can be concepts, simulations, prototypical partial assemblies, virtual prototypes, rapid prototypes, up to pre-series samples, which may be tested in user studies. Samples & Integrations are created to close Knowledge Gaps through learning. For this reason, the samples are always deliberately planned in such a way that they can be generated and tested with minimal expenditure of time, so that Knowledge Gaps can be converted into Usable Knowledge. Samples that do not close any Knowledge Gaps will not be built!

\r\n

Further suitable links:

Knowledge Gaps

13. August 201914. May 2020 Oliver Schönfeld

Today, product developments very rarely start “on the green field”. Depending on the competence of the organization, certain things are already known and can be reused. The P4 framework describes all unknown things as “knowledge gaps”. The idea behind this is that product development can be considered complete once all knowledge gaps have been turned into Usable Knowledge and documented Decisions .

(Note for process experts: Knowledge gaps represent a new concept. They combine the idea of ”hypotheses” from the Lean Startup with the “knowledge-based” development of LPPD, the risk management of classic processes and the risk-based approach of the Unified Process.)

The Gap Map

The gap map shows, against the background of a suitable representation of the “system under development” and its context, the associated knowledge gap as a red post-it. Green Post-its visualize elements and interfaces that have not been changed or that have already been decided in the course of the project based on what has been learned .

The following things can be read on the gap map:

Areas with an accumulation of knowledge gaps require more attention
The sum of all weighted knowledge gaps results in the (remaining) effort of product development! The weighting or effort estimate is carried out by the implementing, interdisciplinary team, for example using planning poker .
Knowledge gaps are backlog elements at a high altitude and are broken down into smaller, executable elements by refinement. Knowledge gaps thus represent the content plan of product development.
Knowledge gaps enable easy risk management because they represent the product-related uncertainties. (Attention: Organizational risk management is also necessary)
When all red post-its have been changed to green post-its, product development is finished

Due to the simplicity and clarity, a gap map is an excellent means of communication between the team and the management.

\r\n

Further suitable links:

System Concepts, System Architecture & Capabilities

13. August 201911. May 2020 Oliver Schönfeld

System concepts describe possible solutions for system and product variants (applications = feature sets) and their requirements . System concepts implement the System Requirements within the restrictions (contraints) and balance the quality requirements (Quality Attributes)out. The P4 framework explicitly provides several System Concepts as solution options for the implementation of System Requirements in the system backlog. This means that several solutions to a problem may be identified and developed further (divergence in the solution space). The goal of product development is to only develop so many different System Concepts (in parallel or in succession) until some concepts are disqualified and ideally a clear favorite emerges. Depending on the degree of innovation in the development, this can be a very large number of concepts at first, or new concepts may even arise during product development.

In today’s product development, the concept of reuse and thinking in building blocks, product lines and platforms has become very popular. This is reflected in the P4 framework by the architectural aspect of this level. The requirements for the platform are contained in the ” Quality Attributes & Constraints ” (eg modularity, reusability, markets and applications).

The responsibility of the Cluster System Engineer is also the division of so-called capabilities into Modules, which are described as services in more complex systems. The basic idea is that certain Modules provide skills that can be used by other Modules.

\r\n

Further suitable links:

System Requirements & Functions

13. August 201916. May 2020 Oliver Schönfeld

Systems are described at the top level by System Requirements and Functions (features). Requirements only describe abilities or properties in the “problem area”, so they are still independent of concrete system solutions. The solution space is already limited by the Quality Attributes & Constraints .

Interfaces to neighboring systems in the environment and their properties are also specified here. For this a sogn. Context diagram created and used.

Functional System Requirements of the stakeholders are often written in the form of User Stories * and later specified using “Use cases“.

*) P4 introduces the term “Stakeholder Stories” in this context, since they are suitable for the specification of requirements of all stakeholders, not just the user.

**) Non-functional requirements (NFR) are not written directly into the system backlog in P4 (see Quality Attributes & Constraints )

\r\n

Further suitable links:

System Requirements on Wikipedia

Applications and Market Variants

11. August 201911. May 2020 Oliver Schönfeld

Applications and market versions are integrated, tested and approved products of the organization that can be sold in target markets to customers. They meet the requirements specified as a group from the Stakeholer Needs in the ” feature sets “. These are individually defined in the System Requirements & Functions as well as the Quality Attributes & Constraints (QA&C) .

\r\n

Further suitable links:

Marketable Systems and Applications

11. August 201914. May 2020 Oliver Schönfeld

Applications and market variants are the organization’s integrated, tested and approved products that can be sold to customers in the target markets. They meet the requirements specified as a group from the Stakeholer Needs in the ” feature sets “. These are individually defined in the System Requirements & Functions as well as the Quality Attributes & Constraints (QA&C) .

Suitable and further articles:

Practice Lead

11. August 201911. May 2020 Oliver Schönfeld

Practice leads are professional coaches or trainers within the organization who take care of expertise or technical discipline. They lead a community of practice , train their members and take care of the further development of the topic and the employees within the Organization.

In the transition from classic organizations, the former line managers can become Practice Leads.

\r\n

Further suitable links:

Events

Roles

Groups

Artifacts

Iteration

Cycle

Cadence

Community of Practice

Cluster Management Circle

Organisation Management Circle

Practice Backlog