The agile movement is often criticized for being too dogmatic in its principles. Many of these principles cannot be upheld in the context of several teams and within large organizations. This has often been demonstrated in the past during practical implementation, which is one of the main criticisms of “agile purists” of agile scaling frameworks that seek to solve this problem. Pragmatic Product Development therefore deliberately tries to strike a balance between “as agile as possible” and “as structured as necessary”.
The following table lists and compares the different attributes of the classical, agile and pragmatic approaches:
| Attribute | Agile | Classical | Pragmatic |
| Management responsibility: | flat hierarchy, responsiblities split to PO, SM and Working Team | Singular hierarchy and responsibility to a single manager | Three clear areas of responsibility (Trinity of management) |
| Teams: | x-functional | functional groups (silos) | Application & Feature Teams are x-functional, Modul- und Plattformteams where practical and possible. Service- und Expert-Teams are still organized functional. |
| Dedication: | 100% dedication | High fragmentation: multiple projects per person | As much dedication as possible and practical: Nucleus (full), Extended member (partial), Supporter (low) |
| Specialization: | Generalists | Hyper specialists | Generalists and experts depending on team flavor and needs |
| Structure and frameworks: | Ideally no framework | Framework and structure define teams | Framework with guiding principles for team structures, value streams and the flow of work. |
| Team co-ordination: | Dailies are daily | on demand or weekly | Nucleus syncs daily, Extended members join Team sync one day per week per 20% assignment |
| Process: | no/low process | Precisely defined and heavyweight process | Minimum viable process by suitable Definition-of-done. Required documentation is part of the System increment and the Application release. |
| Progress: | Feature-driven (functionality) | Plan-driven (task and time) | Learning-driven: Turns Knowledge Gaps into Usable Knowledge and Documented Decisions |
| Frontloading: | minimal upfront planning | heavy planning & requirements elicitation | Limited to what we know (hypotheses), options, and what we don’t know (Knowledge Gaps) |
| Product maturity: | Potentially releasable features | Fixed planned maturity (Milestones) | Content-based maturity based on completed Features and open Knowledge Gaps |
Based on our experience, Pragmatic Product Development balances the principles of Lean and Agile frameworks with the requirements of larger organizations, especially physical product development (similar structures, regulated processes, dealing with experts and shared test labs).
What is missing in agile frameworks and how does P4 deal with this?
Agile frameworks such as Scrum deliberately do not define all practices. These are to be added by the organizations and teams depending on the situation. Compared to classic, project- and plan-driven approaches, the following practices are missing:
- Risk management: There is no explicit risk management in Scrum, with the exception of risk consideration when prioritizing Backlog Items. In P4, explicit risk management is recommended for product development (so-called implementation risks) and product use (product risks).
- Employee education and training: In P4, this is considered as part of Retrospectives and activities are presented in the Improvement Backlogs.
- Change management: In fact, there is no explicit change management in agile approaches, as constant changes (extensions, deletions, and adjustments) are assumed from the outset. One could also say that working on the backlog represents permanent change management.
What is missing in traditional approaches?
- Focus on value creation: The value of a plan-driven project is usually anticipated by the fact that the project was started in the first place. This limits the definition of value or business opportunities to the program and portfolio level, as the scope of the project is usually predefined at this level.
- Opportunity management: During a plan-driven project, opportunity management is usually not practiced alongside risk management. Here, too, it is usually assumed that this was considered at the program and portfolio level before the project started.
(Picture from pch.vector on freepik.com)
Next article: “If it has to be a project …” | Back to FAQ | Home