The evolution of process models
When discussing process models, one often gets the impression that there is a kind of war between the representatives of the models and that the representatives of the models act more like evangelists. My opinion is that every process model has advanced product development, at least in some aspects. Some characteristics of the process models build on each other and complement each other to a certain extent.
In this article I would therefore like to briefly introduce the different models and evaluate which aspects I think can be integrated into a modern approach.
Waterfall
Winston Royce, 1970.
Properties: Project procedure. Activity-based. Single pass. Product versions are created within projects.
Description: First simple model, introduces concepts for the subdivision of activities in development. The basic idea is that each artifact is created once for final use.
Comment: The model structures the process of development in a way that has not been described until then. It is a clear and simple model, relatively easy to understand but very idealized. (This is probably the reason why it became so widespread). As a Activity model it is unsuitable. Even Winston Royce introduced it in his publication, among other models, only as an ideal model, with the remark that it is not suitable as an activity model in real projects.
V-Modell
Barry Boehm, 1979. German government, 1991.
Properties: Project procedure. Activity-based. Single pass. Product versions are created within projects.
Description: Extends the waterfall model by the relations how and on which level artifacts are verified and validated. Each artifact is created once for final use.
Comment: Still useless as an activity model, since it is a waterfall at its core. The real value of the model lies in the relationships that allow for traceability by linking the test activities on the different levels to the respective specifications. The sum of the tests on the right hand side checks all specifications on the left hand side, which makes a completeness check possible.
Stage-Gate ®
Cooper, 1996.
Properties: Project procedure. Activity or maturity-based. Single pass. Product versions are created within projects.
Description: Extension of the waterfall with phases (stages) that are completed with a milestone (gate) and are intended to produce an increasing degree of maturity of the product. Each artifact is initially created in a certain phase. Artifacts are modified, if necessary, per phase by an explicit change management and released by the gate review.
Comment: Depending on the content of the respective activities within the phases, Stage-Gate is (still) a waterfall with milestones or the beginning of an iterative procedure. Stage-Gate is widely used in physical product development today. Especially the concept of gates promises a good controllability of projects on higher management levels. However, since the phases usually last several months and, in addition, gate reviews are organized depending on the availability of certain results, the possibility of controlling is strongly limited.
In the individual phases, various artifacts, such as prototypes, are planned, built and tested. The fastest possible creation of the prototypes thus becomes the highest goal, learning with the suitable prototypes takes a back seat. Deadline pressure leads to the fact that each prototype is planned only once, i.e. small waterfalls arise from the phases and iterations within the phases are not planned.
The gate reviews are prepared elaborately and are therefore usually not repeated, but gates are taken with “conditions”. Unfortunately, this often leads to late surprises (false positives, false confidence) and requires a complex change management. Especially for highly innovative projects Stage-Gate is too tough and cumbersome, in my opinion even for projects that can be planned well.
Unified Process
Kruchten, 1999.
Properties: Project procedure. Activity and maturity-based. Iterative pass. Product versions are created within projects.
Description: Extension of the stage-gate model by iterations of equal length within the phases. Awareness that specific activities have an accumulation in specific phase, but cannot be finished completely. Use of Use-Cases and the UML.
Comment: The introduction of iterations as a fixed rhythm, and especially the iteration reviews every 2 to 4 weeks, create a “sense of urgency” to be able to show something additional each time and thus the compulsion to take small steps. UP thus creates a truly iterative-incremental approach, whereby the prioritization of work packages should be strictly risk-oriented. Due to the frequent integrations and their tests, an (at least partial) automation of the tests becomes necessary. The integration of Use Cases and the UML as standard tools gives the process model a clearer structure, but on the other hand makes it less flexible.
As a project approach, UP lacks the element of team stability if this is not addressed by measuring the availability of team members and progress, and by considering the availability of team members as an explicit risk.
Agile/Scrum
Sutherland, Schwaber, 1995.
Properties: Project and team approach: A team describes its complete work, if necessary also on several products. Iterative-incremental procedure. Product versions are created in releases.
Description: Clear separation of responsibilities on three roles, clear priorities and focus by backlogs, time-boxed iterations, self-organization & pull.
Comment: Scrum as an agile framework represents only the most elementary process elements and deliberately leaves everything else out. This makes Scrum so universally applicable, but for a complete process description it must be supplemented with additional elements. However, the underlying paradigms and principles are completely new and different in the agile working world:
- Trust, respect and personal security instead of command and control
- Self-organisation and pull principle instead of central control
For a complete process model, a combination of Scrum and UP is suitable.
Scaled Agile/Scrum (Team-of-Teams)
SAFe: Dean Leffingwell, 2002. LeSS: Bas Vode. Scrum@Scale: Jeff Sutherland. Nexus: Ken Schwaber. P4-Dev: Oliver Schoenfeld, 2014.
Properties: Multi-team approach (long-lasting, stable teams). Several teams work on one (or more products). “Projects” change into product/application versions. These flow to the stable teams. There is at least one interdisciplinary Product Team, possibly several Feature Teams. P4-Dev also describes Module and Platform Teams and cooperating Expert/Service Teams. Product versions are created in releases. All this leads to a predictable working speed (velocity) through pull and self-organization.
The following extensions are introduced to scale the agile Scrum events to a higher level (Cluster or Programm):
- Targeted overlap
- Groups at the higher level, consisting of members of the teams (e.g. the group of Team Product Owners agree on the planning together)
- Cross-group roles, such as a “Chief Product Owner”, “Program Owner” or Cluster Product Owner
- Events where people from teams and groups come together (e.g. Scrum-of-Scrums, Cluster Retrospectives, Cluster Planning, Cluster Review)
- Measuring the performance of Teams, Clusters and the entire Organization to know how many product releases can be delivered and promised per time period.
- Clear prioritization by evaluating the benefits and costs of product releases and the containing features. Subordination of all other classical activities that influence the prioritization, such as budgeting, target setting, portfolio planning!
Conclusion
What elements can we integrate in a modern process model for an entire organization:
- Naming the activities and artifacts from the waterfall
- Traceability and completeness check from the V-Modell
- Milestones and growing product maturity from Stage-Gate
- Iterative approach, risk and architecture-driven approach, as well as artifacts (such as use cases) from the UP
- Transparency, consistent discipline, stability, self-organisation and pull for predictable performance with high quality from Scrum
It is integrated in the P4 framework.
Stage-Gate ® is a EU registered trademark of Innovation Management U3 und Product Development Institute Inc.