Category: Cluster Level

Cluster Backlog

Usable Knowledge

Cluster Backlog

29. September 201916. May 2020 Oliver Schönfeld

Each Cluster has exactly one Backlog for its area of responsibility and tasks , the Cluster Backlog. In its simplest form, it consists of elements of just one System development that all Teams in the Cluster are working on. In this case, the Cluster Backlog can be referred to as the System Backlog. If the Cluster is responsible for several systems, all backlog elements of the different systems are contained within the Cluster Backlog.

The Team Product Owner Group is responsible for and prioritizes the Cluster Backlog .The Team Product Owner Group consists of all Team Product Owners of the Cluster and the Cluster Product Owners. A large part of the Cluster Backlog is derived by the Cluster Product Owner Group and the Cluster System Engineer Group from the Portfolio Backlog by refinement in the Portfolio Backlog Refinements .

The other part of the Cluster Backlog consists of work and measures that the Cluster carries out to improve the quality of work and results, e.g.

Quality measures and improvement of the Cluster process (ie the Cluster Improvement Backlog)
Maintenance of the products, systems and Modules responsible for the cluster
Maintenance and servicing of tools and tools.

In order to make the working speed of the Clusters more predictable, the proportion of backlog items derived from the Portfolio Backlog should be relatively stable over time.

The Cluster Backlog is prioritized by the Cluster Product Owner.

In the Cluster Backlog Refinement , the Cluster Backlog Items are presented by the Cluster Product Owner and estimated by the Team System Engineer Group (TSEG). Since this consists of members of all Teams in the Cluster, this group is best suited for this.

In the Cluster Planning, the TSEG pulls as many Cluster Backlog Items into the Cycle as the TSEG believes due to the previous working speed of the cluster. This is the Cycle Backlog that represents the plan for the next cycle.

Work in cycles or in continuous Kanban mode

Clusters have the choice of planning, executing and controlling their work in a rhythm of fixed time units, ie in Cycles, or in a continuous flow, with each Backlog item individually going through the different states of the work process of the Cluster. This is made transparent on a Kanban board.

A Cluster chooses between Cycle-mode and Kanban-mode, depending on the product and how planning and approval are carried out. With a regular release rhythm, for example every three months, work in Cycles is recommended.

Cycle Backlog

The Cycle Backlog reflects the work of a Cluster for a currently running Cycle . The estimated work, ie backlog elements, is pulled into the Cycle Backlog by the TSEG at the beginning of the Cycle (pull) and thus scheduled for the next Cycle (forecast).

Cluster Kanban

If the Cluster works in Kanban-mode, it uses a Cluster Kanban Board instead of the Cycle Backlog. The first column corresponds to the Cluster Backlog and the last column to the status “Done”. All other columns are defined by the Team Scrum Master Group of the cluster, according to the internal Cluster work process.

\r\n

Further suitable links:

Events

Roles

Groups

Artifacts

Cluster Planning

Cluster Sync

Usable Knowledge & System Increment

Team Backlog

Portfolio Backlog

Integrated System Sample

21. August 201915. April 2020 Oliver Schönfeld

System-Inkremente sind Teil- oder Vollintegrationen von Systemversionen, die durch interne oder externe Tests, sowie (je nach Grad der Regulierung) durch Nutzer- oder sogar Markttests verifiziert werden.

System-Inkremente werden häufig auf Cluster-Ebene erzeugt d.h. durch die Integration von Teilprodukten der verschiedenen Teams eines Clusters.

Für das System-Inkrement hat P4 die Arten und Definitionen von Mustern aus dem Design Thinking Framework übernommen. Sie definieren damit auch die Reifegrade der Muster (Samples).

Der Reifegrad wird letztlich über die Art und Anzahl der Knowledge-Gaps definiert. Um Knowledge Gaps zu schließen werden Muster aufgebaut

Prototype	Name	Description
B	Base Prototype	for design space exploration
C	Critical Function Prototype	Need finding; feasibility; fail early
D	Dark Horse Prototype	The alternative; thinking out of the box
E	Emergent Prototype	Combining several Functions and ideas; iterative and incremental
F	Functional Prototype	Fully functional, but differs in (e.g. form-factor)
G	Gap Closing Prototype	Specific to close Knowledge Gaps or prove Hypotheses
H	Hindmost Prototype	Closest to series production

All Prototype can appear as iterating Prototypes, like G1, G2, G3.

\r\n

Further suitable links:

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

Organisation Retrospective

Team Product Owner

Team System Engineer

Team Scrum Master

Organisation Scrum Master

Portfolio Owner

Portfolio Architect

Working Team

Community of Practice

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

System Platforms & Variants

Portfolio Backlog

Systems & Applications

Organisation DoD

Organisation Improvement Backlog

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

Cycle Daily Meeting (Scrum-of-Scrums)

25. July 201911. May 2020 Oliver Schönfeld

Cluster Sync (scrum-of-scrums)

This event enables multiple Working Teams to communicate with each other in order to coordinate dependencies, disruptions, new findings and decisions, etc. with one another during ongoing work. The teams decide how often this is needed (e.g. daily or weekly).

The team representatives can be the Team System Engineers of the teams. However, other technical representatives of the teams can also be appointed.

The Cluster Sync takes place (usually in a semicircle) in front of the Cluster Kanban Board because the members move the Cluster Backlog Items in the Cluster Sync.

The three questions in Cluster Sync are:

What has my team done since the last Cluster Sync?
What will my team expect to do until the next Cluster Sync?
Where is my team blocked and needs support?

The structure of the Cluster Sync can also be used for the exchange of certain roles or expertise, for example a Cluster Sync of the Team Scrum Masters , the Team Product Owners, the testers, the designers, designers, etc.

Due to the shortness of a maximum of 15 minutes, the Cluster Sync is only suitable for identifying problems, but not for discussing or solving them. The required members can use the time after the Cluster Sync to discuss problems, while the unnecessary members can continue to work.

Visitors in Cluster Sync

Visitors who want to experience the Cluster Sync can participate with the permission of the members. The visitors are in the second row and only listen, unless they are addressed by an active member. Visitors can be:

The Cluster Product Owner
Members of other Clusters
Stakeholders

Extended Cluster Sync

One or more times a week, members of teams that work for several Clusters also come into extended Cluster Sync (similar to Extended Team Sync at team level). They answer their three questions accordingly …

What has my team done and achieved for this Cluster since the last extended Cluster Sync ?
What will my team expect to do for this Cluster until the next extended Cluster Sync ?
Where is my team blocked and needs support?

For the teams that work for several Clusters, it must be ensured that the extended Cluster Syncs of the Clusters take place at different times, so that the members of such teams also have the opportunity to participate. Within the Organization, a coordinated cadence of events enables minimal overlap and an optimal workflow.

Joint Cluster Sync

If two Clusters work very closely together, it may make sense to carry out a joint (joint) Cluster Sync one or more times a week. The representatives of one Cluster listen while the representatives of the other Cluster are doing their Cluster Sync and then the reverse is done.

Further suitable links:\r\n

Further suitable links:

Events

Roles

Groups

Artifacts

Team Sync

Cluster planning

Organization Sync

Usable Knowledge & System Increment

Cluster Backlog