Agile product development: How do you plan the unplanned

Agile product development is becoming increasingly important. Digitalisation is changing processes and circumstances at an unprecedented rate. Agile working has proven to be the ideal approach to keep pace with these dynamics. But: How do you approach long development processes in a constantly changing world? And how do you plan them?

‍

Why should I develop my product in an agile way?

Agility is increasingly important today as we live in an ever faster changing and more complex world. This is accompanied by complex frameworks and requirements that are themselves extremely dynamic. Agility stands for the attitude and ability to perceive this change and the associated changes, to evaluate them and to adapt to new requirements and circumstances in a short period of time. On the one hand, it is about being able to react flexibly and adaptively to new circumstances, and on the other hand, it is about being proactive and anticipatory.

‍

‍

‍

‍

But isn't that also possible with classic methods?

The method is not the issue. Just because you run a project using classic methods such as waterfall doesn't mean you can't adapt your plan - even if it's more cumbersome and slower. Conversely, implementing Scrum does not guarantee that you will reap the benefits of agile working. Ultimately, it is the attitude or mindset that matters most. Agile methods and tools promote this mindset and help to make it tangible and applicable.

In agile organisations, the focus is on four points:

• Adaptability: Adapting to new circumstances
• Response rate: quick response to change
• User centricity: iterative, small-step product development with regular and early feedback loops
• Attitude: Mindset and values based on transparency, appreciation, respect, self-organization and a feedback culture

‍

‍

‍

“Agility has nothing to do with haphazard. The big difference lies rather in the detail and adaptability of the plan. ”

‍

If everything is always changing anyway, how can I agile product­Plan development then? Do I even need a plan?

Agility has nothing to do with randomness. The big difference is in the detail and adaptability of the plan. In an agile environment, different planning horizons can be identified. The image of the onion is a good one: The product vision is in the outer skin of the onion. A medium-term development plan can then be derived from this vision, and iterated down to a daily plan. The lower the level, the more concrete the planning should be.

An example: If I know that I want to go international with my product at some point (vision), but I don't yet know when or in which countries the product will finally be launched, small-scale planning shouldn't counteract this vague goal. At the same time, concrete implementation is not yet necessary. However, you must not let your specific plans on a small scale get in the way of your vision. A plan is therefore extremely important, even in an agile way of working.

‍

Don't I need to have everything in the project already set up?

Empiricism plays an important role in agility - continuous learning based on experience. You should start with the awareness that you don't know everything. But you should use what you do know! In this way, you prioritise the requirements you already know and start with the most important ones.

By constantly inspecting and adapting, you will gain new insights and adjust your plan as necessary. It is important to be aware of the levels at which the plan needs to be adjusted based on new knowledge (see onion model).

‍

‍

‍

But doesn't this mean that I get lost in the "minutiae" and do all sorts of things that don't get me any closer to my goal?

Everything I do every day should contribute to the overall goal. Using Scrum as an example: My daily work should always contribute to the sprint goal - just as a sprint goal should contribute to the product goal or the overall vision. So it is important to have alignment at all levels of the onion.

Even on a small scale. Inspect and Adapt are therefore integral parts of Scrum. Through rituals such as Daily, Review and Retro, we regularly reflect, inspect the results and, if necessary, adapt the planning and working methods to bring us closer to our goal.

‍

And if my small goals don't align with the overall goal?

If the specific plans of the day's work, or even of an iteration, do not match the rough "roadmap" for my product, then usually either the rough planning at a higher level is not effective, the goal is not the right one, or you are developing past the goal.

For example, if I implement new requirements in the sprint based on user feedback that do not serve the overall goal, it could be that my product vision does not match the users' needs.

‍

Conclusion: Agile product development can be planned, but the understanding of planning needs to change. Understanding planning as a one-off task, completed before the project starts, does not work with agile work. Like the whole process, the plan must be dynamic and adaptable to new circumstances, learnings and requirements. However, it is important to never lose sight of the ultimate vision and to continually check your daily work for consistency.

‍