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: | no hierarchy | Singular hierarchy | Three clear areas of responsibility (Trinity of management) |
| Teams: | x-functional | functional 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).
(picture from pch.vector on freepik.com)
Next article: “If it has to be a project …” | Back to FAQ | Home