Our blog articles are translated to English by machine and may not always be accurate - sorry for that.

If you understand German, we recommend to switch to the German version.

yearly planner

The agile paradox: agile planning (part 2)

Share on linkedin
Share on twitter
Share on facebook
Share on email

At first glance, agility sometimes seems contradictory. Managers in particular are faced with many contradictions. In this series of articles I will show you examples of this agile paradox and how it fits in the end.

Agile teams don't plan?

When introducing agile methods, many teams struggle with the fact that there are still framework conditions that seem to hinder their use of agile methods. A major blocker is often the topic of budget planning. Then it says “We are agile. We cannot say what we will do in the next six months !? ”

It is, of course, right that in an agile context, one does not build a clear roadmap for the entire financial year at the beginning of the year, which then only has to be implemented blindly. At the same time, it is highly unrealistic to be able to manage companies with limited resources completely without planning. How do you resolve this contradiction?

Focus on what is possible

Budget planning often sounds very final. But the key to success here is to understand the budget less as a restriction and more as an aid and orientation.

Annual planning should be supplemented by, for example, quarterly planning cycles. A quarterly analysis makes it much easier for teams to assess which topics they are likely to deal with. In these quarterly cycles, it is therefore important to give the teams a feeling of what resources they can count on when implementing the topics. There is usually enough scope within this framework to decide for yourself how these funds are used.

If these framework conditions are clearly shared with teams and perceived by them as support, this can actually spur creativity, how to achieve the goal as best as possible with given resources & #8211; The prerequisite remains that planning is not seen as a fixed, bureaucratic limitation, where creativity is not required.

Unplanned customer benefits

An essential question for managers in this context is the question of setting priorities: Is management concerned with adhering to its planning as closely as possible, or with creating the greatest possible customer benefit?

In an agile context, the second is of course the priority of the teams and hopefully also of the management. Because the management will also have hopefully set up the budget planning for the fiscal year in order to create the greatest possible customer benefit for planning based on the knowledge available at the time. If, within the sprints and the resulting feedback loops with the customers, better opportunities have emerged to create customer benefit, this would be a good argument to deviate from the planning.

example: ATaken a newly discovered customer requirement needs 10 T € more than planned in the budget. At the same time, however, there is added value of € 25 thousand for the customer, which he is willing to pay monetarily. Then, logically, that is an overall added value for the company. A decision not to take advantage of this chance of “deviating from the plan” should be difficult to convey to the teams (and at the latest the management).

This can also be the other way around: The first prototype already reveals that a product will not achieve its “planned” customer benefit. Should the product be developed further for the sake of planning, or is it left to the team to find better ways to use the resources?

Conclusion

Companies have limited resources and must plan them accordingly. That is why agile teams cannot avoid planning. Agility means freedom for the teams within a planning framework. The more unbureaucratic and closer to the team the planning cycles, the better. This enables teams to control the design independently.

At the same time, the fast learning cycles will always give opportunities to create better customer benefits than originally planned. Or to abandon certain topics due to the lack of customer benefit. A functioning agile planning manages to consider such opportunities deviating from the plan.

PS:

With Echometer we are developing a tool for agile retrospectives & #8211; the central meeting for the continuous further development and strengthening of the self-efficacy of teams. If you are interested in further developing the feedback and learning loops in your teams, agree here a free test & #8211; we look forward to hearing from you!

To the point

More articles

Want to get started?

Test team retros with Echometer for free & drive agile work in your organization.