The agile paradox: agile planning (part 2)

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 general conditions are clearly shared with teams and are perceived by them as helpful, this can actually stimulate creativity in how to best achieve the goal with the given resources - the prerequisite remains that the planning is not seen as a fixed, bureaucratic restriction in which no creativity is 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 - the central meeting for the continuous development and strengthening of the self-efficacy of teams. If you are interested in further developing the feedback & learning loops in your teams, arrange right here a free trial - we look forward to hearing from you!

Blog category

More articles on "scale agility"

View all articles in this category
Agile Spotify Model: Squads, Tribes, Chapters & Guilds Explained

Agile Spotify Model: Squads, Tribes, Chapters & Guilds Explained

The agile Spotify model with Squads, Tribes, Chapters and Guilds simply explained. Learn more about advantages, typical stumbling blocks and use cases.

Agility Health Radar: 13 most popular models measuring agile

Agility Health Radar: 13 most popular models measuring agile

Discover the 13 most popular Agility Health Radar models for agile KPIs. Optimize the health of your teams and projects with these tools.

Working Agreements: 10 Examples, Samples & Templates

Working Agreements: 10 Examples, Samples & Templates

Agile Working Agreements: 10 Examples, Patterns & Templates for Scrum, Remote Teams and SAFe. How to improve collaboration and strengthen teams!

The Scrum Master as Servant Leader: 8 Tips & Thoughts

The Scrum Master as Servant Leader: 8 Tips & Thoughts

Learn how to become a Servant Leader as a Scrum Master! 8 tips on communication, self-organization, and agile project management for your agile team.

Product Manager Performance Goals: 5 Examples & Tips

Product Manager Performance Goals: 5 Examples & Tips

Product Manager Performance Goals: Tips & Examples for SMART Goals, Levels and Development. Learn how to make performance measurable here!

What is a Product Owner in the Scaled Agile Framework SAFe? - Facts and Figures 

What is a Product Owner in the Scaled Agile Framework SAFe? - Facts and Figures 

What does a SAFe Product Owner do? We explain the role in the Scaled Agile Framework, tasks, responsibilities and the 6 types of Product Owners.

Scrum - what is it? Easily explained!

Scrum - what is it? Easily explained!

Scrum simply explained: What does agile working mean? We shed light on the roles (Product Owner, Scrum Master, Team), Sprint, Backlog and the success of Scrum.

Combine OKR & Scrum: This is how it works (workshops, sprint goal and cycles)

Combine OKR & Scrum: This is how it works (workshops, sprint goal and cycles)

Learn how to successfully combine OKR and Scrum! We'll show you how workshops, sprint goals, and cycles can interlock optimally. This is how agile working is done!

Agile at Scale: Comparing the 5 most popular frameworks

Agile at Scale: Comparing the 5 most popular frameworks

Agile at Scale: Discover the most important frameworks (SAFe, LeSS, DA, Spotify, Scrum@Scale) for agile scaling in the company. 5 principles & 6 steps.

Echometer Newsletter

Don't miss updates on Echometer & get inspiration for agile working