If you then work in a highly scaled environment with many, more or less dependent products, there are also the so-called PI planning meetings. All of these meetings are well defined with an agenda, a clear objective, a moderator and a fixed group of participants. Important prerequisites for good meetings. Nevertheless, it happens again and again in everyday project work that those involved find these important meetings to be time-consuming. Why is this the case? And how can we turn meetings back into the value-creating synchronization points that they are intended to be? We have addressed this question in our internal Best practice exchange "Scrum Lunch" was followed up.
Five core problems of agile meetings and how we can solve them
Both the client, the product owner and the development team are united by the basic need to be able to use the time for development and to develop value-adding features. The development teams are aware that in the medium term enormous impact on precisely this development of new features if meetings are not held at all. Development can then be limited to misunderstood requirements and assumptions, blockers are not identified and eliminated as quickly, or the team does not set Wrong priorities in the processing of its tasks. This means that in the medium term there is less time for development and, in the worst case, "the wrong thing" is developed. The consequences are not only Additional expensesbut Frustration on both sides.
If clients or product owners see agile meetings as a burden and no longer perceive their added value, this usually has to do with fundamental problems in the project setup. And they can be solved.
In our best practice exchange we have Five core problems identified that reduce the effectiveness of agile meetings and approaches were found, how to fix them:
In fact, there are projects that are too simple for Scrum. If the requirements for the product are clear, the technological solution is not a challenge, the time frame is manageable and the team is very small, then an approach like Scrum is simply the wrong approach. The time for the meetings is then disproportionate to the implementation time and the synchronization brings no added value.
What you can do: The Cynefin Framework can help you choose the right project management approach from the outset. You don't have to do without agile elements entirely. Review and retro, for example, are the drivers of the learning process and can also be a great help in a less complex environment.
If the project environment is characterized by many functional and technical dependencies, complexity increases rapidly. Dependencies require a High coordination and coordination effort. This slows down the project and at the same time potentially leads to more misunderstandings. Avoiding meetings in this situation only exacerbates the situation.
What you can doIt is important to check whether functional and technical dependencies between the systems can be reduced. The Structure of the system and the Editing the feature teams should include as few interfaces as possible and only as many as necessary. In other words: the intersection between the microservices of a system must be chosen correctly (e.g. using domain-driven design) and the teams can then be assigned to the systems appropriately (see also (Inverse) Conway's Law).
Of course, the world is not ideal and we cannot always devote 100% of our time to just one project. Day-to-day business or other very urgent projects force us to Capacity to be divided between several topics. However, if the majority of the project members can only work on the project with split capacities, then the meetings become a burden and organization becomes extremely difficult.
What you can doThe first question in this situation is: Can't tasks be better distributed in order to have fewer team members with more capacity in the project? And if someone with very little capacity is indispensable for the project, does he then have to be deployed as a permanent team member or are there not alternatives? If there is no solution in sight, the focus on the actual purpose of the meetings and alternative solutions for synchronization, planning, estimation, learning from the result and the process are sought.
The number of participants in agile meetings is too large
Too many participants always means that not everyone pays the same amount of attention to the respective contribution. This means that the benefits of the meeting are actually limited for them. This should not be the case. It is therefore important to find solutions quickly in order to avoid frustration.
What you can do:
- Is the feature team too big? Teams with more than seven people should shared become.
- Are there participants with special tasks (e.g. Ops or Testing) who are not involved in feature development? If so, the backlog refinement, for example, could be a Multi-stage process on. The first step is to create an overview of the features in the backlog. Everyone should get this. Colleagues with special tasks do not need to be involved in the "kneading" of the individual user stories.
- Does the customer/product owner have too many products? Then they should be relieved of all meetings that are optional. In most cases, optional appointments in the calendar are still perceived as an obligation. In this case, it helps not to invite the product owner at all and to schedule all meetings in the Project WIKI transparent.
- If scaling is carried out using a framework such as SAFE (Scaled Agile Framework) with huge PI meetings? Product Increment (PI) meetings are there to make interfaces transparent and to coordinate them for the next release. If the product domain is very large, these meetings will also be large. Ideally, the developers should be present at these meetings. However, they can be streamlined if only one Part of the team participates. This requires the teams to be very Good preparation and is therefore Good for quality.
- If the meetings cannot be reduced in size and the relevance of the topics cannot be clearly defined in advance, e.g. via the role of the participant, then you can also use a OpenSpace approach choose. An example: In the case of the backlog refinement, all user stories are briefly presented. The developers then decide which ones are particularly relevant to them and which refinement they would like to take part in.
Agile meetings do not achieve what they are supposed to
If the purpose of the respective meeting is gradually lost sight of, it can happen that it is misappropriated becomes. Then, for example, a daily is often used to discuss technological details. It becomes too long and not every team member can make a contribution. And although the time is overrun, synchronization falls by the wayside.
What you can doIt is an ongoing process of refocusing in order to be able to use the meetings properly. The Agile Master (or Scrum Master) is constantly required to take countermeasures here. In our example, this also means that the necessary space for discussing technological details is created elsewhere.
We answer the initial question "Do we need all these agile meetings?" with a clear "yes". If the meetings are more of a burden than a benefit, we need to take a very close look at the causes. Then the right adjustments can be made to get back on track in an agile way.
More about agile project management
