The P4 DevFramework supports several different macro processes in product development:

The knowledge- and maturity-based milestone process

This involves learning on the basis of development samples (e.g. prototypes). It is important that the knowledge gaps are identified first and the development patterns (samples) are planned accordingly and not vice versa. This hybrid of the classic and pragmatic-agile approach evaluates product development at the milestones as a whole, not for individual functions or components. The danger with this approach is that large bundles of functions are brought to market maturity, with the familiar problems of long development times and the resulting delay in market feedback.

The iterative knowledge- and risk-based development process

Here, the maturity of the functions and the development risks of the parts of product development are assessed cyclically in a fixed iterative rhythm and the further planning of the process is derived directly from this. Functions are deliberately developed in versions (feature sets), starting with internal feasibility studies for the initial marketable MVP. Further functions are deliberately developed later and brought to market as application versions after feedback has been received from users.

The following section describes a hybrid process that can be observed in many cases; the two options presented above are then discussed in more detail:

The semi-agile milestone process

When transitioning from traditional to agile working methods, the basic idea and hope is to retain the milestone process and only use agility within the phases, i.e. between two milestones. In fact, this is an approach that we often use at the beginning so as not to overburden the organization with too much change. The contents of the milestones and checklists remain the same.

The macro process is retained and only the micro process is made agile. This has the following advantages and disadvantages:

• Advantages
  • Iterative approach can be implemented to a limited extent at team level
  • Decision-making bodies and processes remain the same, so the existing organization is not overburdened
  • The interfaces to other initiatives and departments remain the same
  • The milestone checklists help to ensure that nothing important is forgotten
• Disadvantages
  • Decision-making bodies and processes remain the same (yes, this is also one of the biggest disadvantages: Too little feedback creates change inertia)
  • The initiative can only move as fast as the milestone plan envisages, but no faster. On the other hand, there is a lot of pressure due to tight milestone deadlines
  • The milestones and checklists often do not fit

For the reasons mentioned above, we are convinced that the agile milestone process should only be an intermediate step towards true agile product development, in which both the micro-process and the macro-process are carried out in an agile manner.

The “Stacey matrix” (according to Ralph D. Stacey), which categorizes “simple/simple”, “complicated” and “complex” projects, is often used to understand agile and classic methods:

     

Milestone-driven agile approaches are suitable for “complicated” projects, as the milestones reflect past experience. Truly complex problems and projects require more flexibility.

Reuse of the checklists

Despite the limitations mentioned above, we believe that the milestone checklists can still be used well. However, they must be adapted to the current product development, as the elements of the checklists can have the following properties …

• Points are required
• Points are not required or do not fit the context
• Points are needed sooner or later (this also has a strong influence on the required experts)
• Points are required in a modified form
• Points are missing
• Points are missing whose existence is not even known at the beginning

The above list shows that the checklist items in complex environments cannot be defined in advance for all product developments. They must therefore be found, defined or adapted along the way.

The fully agile process with “living” checklists

The known and stable checklist items can, for example, be defined as a definition of done for a prototype maturity level. Other points that need to be considered and that were only discovered during product development, for example, can be added as acceptance criteria for prototype/sample backlog items or knowledge gaps.

We propose two different approaches for implementing end-to-end agile product development:

1. The design thinking macro process with prototypes for specific purposes in the various phases.
2. Set-Based Concurrent Engineering (SBCE) from Lean Product and Process Development (LPPD) according to Dr. Allan C. Ward.

Design-Thinking as the agile macro process

At first glance, the design thinking macro process looks relatively similar to a milestone process with maturity levels. The big difference is that several prototypes are built in each phase to answer specific questions (knowledge gaps). However, as the questions for different product developments can vary greatly (e.g. from new materials or manufacturing technologies to completely new business models and business processes), these must be created anew for each product development. This is represented in the P4 framework by the knowledge gaps as separate backlog item types. Knowledge that is to be reused is mapped as a constraint in the non-functional requirements. These are called “Quality Attributes & Constaints” in the P4 framework.

 

Based on the design thinking macro process, we have named the prototypes in alphabetical order (B to H) in the P4 Dev framework. What is important in this approach is that, in contrast to classic development processes, the concepts are allowed to diverge for longer, i.e. more time and effort is invested in learning and getting to know concepts, including unusual and non-obvious concepts and technologies. This is similar to the second model, which is based even more consistently on the reuse of knowledge.

Knowledge-based Product Development as the agile macro process

“Knowledge-based product development” is built up via the points still to be learned (knowledge gaps), not by defining a solution within the design space and then testing it. This is done by consistently exploring the limits of a design and then combining and balancing it with other, competing requirements.

This sounds very time-consuming, but it has a massive advantage:

The knowledge of design limits can be reused and combined to quickly generate new product variants. This knowledge represents the wealth of experience of a development organization.

To this end, the knowledge acquired must be suitably documented so that engineers of the next generation can also reuse it.

Prominent examples: Wright-Brothers, Toyota Product Development System (TPDS), NASA Apollo program, USAF P-51 Mustang, Harley-Davidson.