Since the use of agile practices in physical product development, the question has arisen as to whether classic product development methods can or should be completely replaced, used alongside one another, or combined. Behind this is primarily the desire of organizations to retain processes that have already been introduced for the most part, or not to have to change them immediately.

Many organizations have implemented milestone processes (e.g. Stage-Gate®) in the past. Here is an illustration of this process:

Organizations have established their own variants and approaches, depending on the positive and negative experiences they have had. These are, for example …

• Pro
  • Clear decision-making by a defined committee
  • Recurring assessment of the status of a project or product development in terms of time, costs, risks and effort
  • The possibility to link success criteria and checklists to specific milestones (see picture above)
  • The possibility to change goals and requirements
  • The possibility to cancel projects in a defined way
• Con
  • The phases between two milestones are often very long (several months). Decisions regarding problems and changes in requirements are thus often delayed.
  • Activities and goals of different areas within milestones are completed at different times. In order not to make the whole project wait, milestones are often taken with obligations.
  • The phases, as well as their success criteria and checklists, are predefined and rigid. If these do not fit the current project, they must either be adapted at great expense or creatively circumvented.
  • Certain expert roles are involved late in the process for efficiency reasons, which sometimes fits, but not always.
  • The knowledge in the team is very low in early phases. Nevertheless, the urge to make technical decisions and thus complete phases quickly is very high. Better concepts and solutions discovered in late phases are then often discarded due to time constraints.
  • Risks are often only identified and documented. Measures are often not implemented due to time constraints.

Basic differences of the implementations of milestone processes

1. Milestones map the phases of a waterfall model: Cooper’s original Stage-Gate model has the following phases: 1. Idea Generation, 2. Idea Scoping, 3. Build Business Case, 4. Development, 5. Test & Validation, 6. Launch. An agile approach cannot be combined with a waterfall model, since the principle of the agile approach requires iterative and incremental development. Therefore, we will not consider this approach any further here.
2. Milestones represent maturity levels of the development: The maturity of the development is demonstrated by appropriate evidence, e.g., concept reviews, simulations, and prototype building and testing. This type of macro process is compatible with agile development.

The agile milestone process

Basically, the idea and hope is to keep the milestone process and only use agility within the phases, i.e. between two milestones. In fact, this is an approach that we also often use in the beginning in order not to overwhelm the organization with too many changes. The contents of the milestones and the checklists remain the same.

In this case, the macro process is retained and only the micro process is made agile. The following advantages and disadvantages result from this:

• Pro
  • Iterative approach can be carried out on a limited basis at team level
  • Decision-making bodies and processes remain the same (no excessive demands)
  • Interfaces to other initiatives and departments remain the same
  • Milestone checklists help not to forget anything important
• Con
  • Decision-making bodies and processes remain the same (Yes, this is also one of the biggest disadvantages: Too infrequent feedback creates change inertia)
  • The initiative can only get as fast as the milestone plan says, but not faster
  • The milestones and checklists do not fit (sometimes or often)

For the above reasons, we believe that the agile milestone process should only be an intermediate step to true agile product development, where both the micro process and the macro process are performed in an agile manner.

To understand agile and classical methods, the “Stacey Matrix” (according to Ralph D. Stacey) is often used, which categorizes “simple”, “complicated” and “complex” projects:

     

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

Reuse of the checklists

Despite the limitations mentioned above, the milestone checklists can still be used well from our point of view. However, these must be adapted to the current product development, since the elements of the checklists can be …

• elements are needed
• elements are not needed or do not fit in the context
• elements are needed sooner or later (This also has a strong influence on the experts needed in different phases)
• elements are needed in a modified way
• elements are missing
• elements are missing whose existence is not even known

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

The fully agile process with “living” checklists

The known and stable checklist items can be defined e.g. as Definition-of-done for a prototype maturity level. Further points to be considered, which were e.g. only discovered during product development, can be added as Acceptance Criteria of the prototype/sample backlog items or the Knowledge Gaps.

To implement end-to-end agile product development, we propose two different approaches:

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

Design Thinking as agile macro process

At first glance, the Design Thinking macro process looks relatively similar to a milestone process with maturity stages. The big difference is that in each phase, several prototypes are built to answer specific questions (Knowledge Gaps). However, since the questions for different product developments can be very different (e.g., new materials or manufacturing technologies up 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 a separate backlog item type. 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.

Following 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, even unusual and non-obvious concepts and technologies. This is similar to the second model, which builds even more consistently on learning the design limits and the reuse of knowledge.

SBCE as agile macro process

SBCE (“Set-Based Concurrent Engineering”) means that knowledge is built about the unknown, not by defining a point within the design space and then testing it, but by consistently exploring the limits of a design and then combining and balancing it with other competing requirements and concepts.

This sounds very elaborate, but it has a massive advantage:

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

For this purpose, the learned knowledge must be suitably documented so that engineers of the next generation can also reuse it. We call this “Documented learning”.

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

Conclusion

We are convinced that it is not sufficient for a truly agile macro process to only place agile iterations “under” an existing classic milestone process. This may be sufficient for a first step and for complicated projects, but not for truly complex projects. For this, the macro process must also be designed flexibly, with fast feedback loops, adapted checklists and according to flow principles (no batch decisions with stop-and-wait).

And last but not least: none of the processes discussed solves the problem that employees often work on several projects, prioritizing between them and switching tasks, and are thus heavily overburdened. This requires stable teams working on dedicated projects or stable teams working on a few projects prioritized by a team backlog. For more about this you should read the following articles:

The monopoly of projects, Projects don’t work in a resource limited system.

---

Further literature on design thinking: The Design Thinking Playbook

Further reading on Visual Knowledge and SBCE:

• Dantar P. Oosterwal: The Lean Machine – How Harley-Davidson …
• Allen C. Ward: Lean Product and Process Development
• Allen C. Ward: Visual knowledge for flawless design