There are many misconceptions about agility in product development. There are those who think they can leave out everything except implementation: We don’t document, we don’t test, everything is changeable at any time. In addition, there are many people who think that there is no planning in agile product development.
“Today we are really agile and just do without planning!”
A very common misconception is that agile teams do not plan. In fact, the opposite is true: Agile teams plan more frequently and with more participants, but in a different way: activities that lie further in the future are only roughly planned, because it is accepted that changes will occur and new things will be learned that will change the plan.
Here is a tabular comparison first:
| Process element | Classical | Agile | Agile Principles and Elements |
| Long-term planning | stable. Attempts are made to keep promises of deadlines made under uncertainty. | Rough, flexible: Commitments of dates are made based on experience, sometimes conditionally and as a time period, e.g., most likely in the 3rd quarter of the current year). Or: Commitments are only made with enough slack time. | Rolling-wave planning |
| Short-term planning | stable via tasks | Stable about goals, but flexible in task planning | Iteration Planning |
| Planning the scope | stable, complex change management | flexible, especially for fixed deadlines for releases and deliveries | fixed time, flexible scope |
| Who plans | Project manager | Product Owner with the team | See the whole |
| Scheduling and commitments | by the project manager based on estimates of the individual project. Other projects are not taken into account. | Based on the actual work velocity of the team (Team Velocity) and the cluster, which also takes into account other projects | Commitments by evidence-based planning & velocity, see-the-whole |
| Frequency of planning | at the beginning of the project. Complex and extensive plans are rarely adapted | Regular planning of each iteration. Detailed planning: Iteration Planning. Rough planning: Cycle Planning. | Rolling-wave planning, Team-Sync, Team-Planning, Cluster-Sync, Cluster-Planning, Organisation-Sync, Portfolio-Planning |
Why are we planning?
Planning pursues two important basic needs:
- Forecast: When can we deliver it and what will it cost?
- Efficiency in implementation: When do we need which resources?
Classic planning assumes that it is possible to exactly define in advance what is to be delivered (also known as “scope” or extent), that the project manager can figure out relatively precisely how this can be achieved, and which experts and resources need to be involved, when, and with what effort.
Important planning criteria are…
- The size (scope and duration) of activities should be known in order to determine the effort to be invested at an early stage. Often fixed price offers are based on these effort estimates.
- The type and size of activities determines their earliest possible completion due to limited resources and processors.
- Timing of subcontracting between teams and organizations should be known so that activities can be planned, i.e. external resources should only be held at the time of subcontracting.
The problem is that in today’s VUCA business world (English abbreviation for volatility, uncertainty, complexity, ambiguity), it is often not possible to plan in advance either the scope of a product development or the processors/experts involved, especially when specialization is increasing and the roles involved differ drastically depending on the option being pursued.
How does predictability arise in agile approaches?
Predictability arises once by reducing the complexity of planning by thinking and planning in teams rather than in individuals. The trick here is not to put together a specially optimized team for each project or work package, but to give the projects and work packages to the most suitable (and available) team. This presupposes that the teams have been set up beforehand in such a way that both the different projects and work packages can be assigned to individual teams and that, on the other hand, the teams have as few dependencies as possible on other teams, i.e. that they can complete the projects and work packages without outside help. The art here lies in developing a team structure that enables these requirements to be met over a longer period of time, i.e., enables long-lived and stable teams.
Why stable teams?
Stable and self-organized teams have a tendency to improve themselves, because the team members form a “sworn-in” community on a purely human level and the work processes become established. After a familiarization phase (Tuckman Team Development, Cog’s Stages), a relatively stable, predictable team performance emerges, which in agile product development is referred to as “Team Velocity”. With this predictable team performance, it is possible to plan much better than with teams that have been put together specifically for a project and are therefore working together in this constellation for the first time!
Who plans and prioritizes, who estimates?
Principle of separation of powers: In agile product development, prioritizing and estimating effort are separated. The priorities and thus also the planning sequence are determined by the product owner. However, the estimates are carried out by the team of processors (working team).
The pull principle ensures that the working team does not systematically overload itself. The principle of “merciless transparency” ensures that the working team does not slip into comfort. The balance of these two principles should result in a sustainable and predictable working pace (aka Sustainable Pace, Velocity). However, a prerequisite for this is a certain stability of the teams over time, so that the working velocity does not fluctuate as a result of team structure changes alone (see “why stable teams” above).
Evidence-based planning principle: Based on the predictable work rate and the estimates generated by the working team, the product owner can make predictions of deliveries via the priorities in the team backlog and thereby make delivery forecasts.
Agile planning: what, how often and who?
Rolling-wave planning principle: “Rolling-wave planning” is the paraphrase for repetitive planning that is carried out in greater detail the closer the events are (the closer, the finer). Important advantages of this are that on the one hand the big, more distant things are not lost, but also not too much planning activity is invested in them. Especially in a fast changing environment this would be highly inefficient.
This type of planning is practiced at all levels of the organization. The following graphic illustrates which elements (left), how often (center), at which level, and by whom (right) planning takes place. The boundaries are different and blurred depending on the organization and the system/product to be developed. The top and bottom levels are quite clear: The product portfolio is planned at the top level of the organization, the individual tasks at the level of the people in the teams.
In order to be able to react to changes and to enable a flow-based system, the hierarchical time sequence of annual planning, quarterly planning, iteration planning and daily planning must leave sufficient slack or margin. This means that free buffer must remain at all levels to allow for improvements and unscheduled activities and to be able to react to delays. The size of this margins can vary greatly from team to team.
The content hierarchy during planning ensures that the “upper” elements are fully mapped by refinement into smaller lower elements. This is also provided, for example, in the OKR framework, which is currently receiving a lot of attention.
Mapping of the principles in the P4 framework
The P4 framework can deal with the frequent fact that individual teams are not able to deliver a complete product on their own. This is usually the task of clusters, which consist of 3 to 10 teams. In turn, the entire organization consists of several clusters, which manages, develops and, if necessary, manufactures the portfolio of all products.
- At the team level
- At the level of the value streams in a team cluster (especially when multiple teams are involved in product development)
- At the level of the organization
Organization level
Funnel: New ideas for products, applications, systems, functions, platforms, modules and services are welcome at any time and are roughly assessed in terms of their benefit and effort. The priority for further processing is primarily determined by the quotient: Priority = Benefit / Effort, whereby clear priorities should arise.
Refinement: Prioritized ideas are refined during the ongoing portfolio cycle and, if necessary, evaluated by means of punctures or studies in a team.
Planning of the next organization cycle: Based on the results of the previous organization cycle, priorities can be adjusted. The organization’s work rate from previous periods (aka “organization velocity”) provides the basis for the organization’s clusters (represented by the cluster system engineers) to pull only as many portfolio backlog items into the next org cycle as they can reasonably manage. This means that items that are highly unlikely to be worked on anyway will not be started. While planning the next org-cycle, inter-cluster dependencies and subcontracting are also considered.
Regular review and adjustment of the planning: While the organization cycle is running, changes to the planning are made in the organization sync if they result from knowledge gain.
Cluster level (value stream or system level)
Refinement: Prioritized cluster backlog items are refined during the current cluster cycle.
Planning the next cluster cycle: Priorities can be adjusted based on the results of the previous cluster cycle. The work rate of the cluster from previous periods (aka “cluster velocity”) provides the basis for the cluster teams (represented by the team system engineers) to pull only as many cluster backlog items into the next cluster cycle as they can reasonably manage. This means that items that are highly unlikely to be processed anyway will not be started. While planning the next cluster cycle, dependencies and subcontracting between teams are also taken into account.
Each cluster reserves a part of its capacity for unplanned, short-term things, as well as for improvement actions from the cluster improvement backlog.
Regular review and adjustment of planning: While the cluster cycle is running, changes to planning are made in the cluster sync as they arise through insight.
Team level
Refinement: Prioritized team backlog items are refined during the current iteration.
Planning the next iteration: Priorities can be adjusted based on the results of the previous iteration. The working velocity of the team from previous periods (aka “team velocity”) provides the basis for the members of the working team to drag only as many team backlog items into the next iteration as they can reasonably manage. This means that items that are highly unlikely to be worked on anyway are not started. While planning the next iteration, team member dependencies and their availabilities are also considered.
Each team reserves a part of its capacity for unplanned, short-term things, as well as for improvement actions from the team improvement backlog.
Regular review and adjustment of planning: While the iteration is running, changes to the planning are made in the team sync as they arise through insight.
Conclusion
The examples show that in agile and pragmatic organizational systems and frameworks, such as P4-Dev, planning is done differently and more frequently, and a larger number of people are involved in the planning. Especially on the team level, the planning activity is mixed with the content-related work, e.g., possible concepts are already being worked on during the planning, or the planning is adjusted during the work due to new findings..
Picture by pch.vector on freepik.com