There are many misconceptions about how to understand agility in product development. There are those who think they can leave out everything except implementation: We don’t document, we don’t test, we don’t plan. There are also a lot of people who have unrealistic hopes for the adoption of Agility, e.g.:
“We can change anything at any time”
A very common misconception is that of “total flexibility”, i.e. in an agile organization everything would be flexible and changeable very quickly. From a distant perspective, this seems desirable, but closer examination would make it more like chaos. The truth is that even in agile product development, some elements should definitely be stable, and for good reason. This article will discuss which elements of the organization flexibility applies to and which elements are deliberately kept stable or long-lived in agile and pragmatic approaches.
Here is a tabular comparison first:
Teamsflexible, project-specific. Team assembly and disassembly phasesstableTeam, Cluster, Team-Falvor
| Process elements | Classical | Agile | Agile principles and elements |
| Long-term planning | stable | grob, flexibel | Vision and coarse plan via Epics |
| short-term planning | stable tasks | stable iteration goals | Iteration Planning |
| Scope | stabil, komplexes Change Management | flexibel | |
| Feedback of internal Stakeholders | selten, beim Erreichen eines Meilensteins | Frequent and regular (iterations) | Fast feedback, fail early and learn: Iterations, Sprints, Cycles |
| Feedback of external Stakeholders | even less frequently, at the end of the project | Frequent and regular (iterations) | Customer-centric, Customer-on-site & Time-Boxing: Iterations, Sprints, Cycles |
| Periods | Milestones for entire scope (flexible at the beginning, after initial planning these become hard deadlines) | stable iteration length | Time-Boxing |
| Meetings | flexible, on demand | stable recurring meetings | Cadence, Time-Boxing |
| Maturity levels | Stable across all projects: hard milestone criteria according to process definition | Stable and content driven: agreed quality (DoD) for ‘releasable features’. | DoD, Features |
| Product maturity during development | Stable: Late changes are not desired and often not possible. Elaborate change management as an instrument. | Increasingly stable: The hope is that with agility, late changes become always possible. In reality, however, only the effects of late changes are made transparent, which means that decisions on late changes can be made more consciously and better. | Transparency |
| Costs | Supposedly stable via milestone planning, often very unstable for complex projects | stable through stable iterations and stable teams; flexible due to flexible scope (= feature set). |
Agile Budgeting |
Why do we need stability?
Today’s business world requires a high degree of flexibility in response to VUCA (abbreviation for volatility, uncertainty, complexity, ambiguity). On the other hand, people need a certain stability in their social environment to feel secure. Agile and pragmatic organizational systems put people in the center, both the customers with their needs and the people involved in the product creation process, with all their working time governed by these processes.
For this reason, in agile & pragmatic organizational systems, the role, group and team structures, as well as the recurring events and meetings are rather stable. This means that they are definitely changed when necessary, but they basically change less frequently. One-time changes per quarter are normal, but as a basic rule, all changes should be introduced at the same time.
And how is flexibility created?
On the other hand, this means that flexibility arises within the so-called artifacts, i.e. the various backlogs, as well as the elements contained therein; by adapting the product features, the open questions (=Knowledge Gaps in the P4 framework), the prototypes and team goals, as well as their priorities within the backlogs.
Within the (stable) recurring meeting cadence, the content covered, or its priority and order, is also flexible. However, this requires a certain rethinking: If a new topic comes up, we do not immediately invite the necessary people, but consider in which recurring meeting we will take the topic. This enormously reduces the calendars of the people involved, especially those of the decision-makers.
Conclusion
The examples show that agile and pragmatic organizational systems and frameworks, such as P4-Dev, deliberately keep some elements stable in order to provide security for the people in the organization, to be flexible in terms of content.
Picture from freepik.com