Even if everything did become predictable - imagine if, in the future, we got to the point where a product owner sent her product vision via Bluetooth directly and visually to the developer's brain. No more noise, no more misunderstandings, everything exactly as intended. But even then, you want to retain freedom to change your mind. To say during a demo, "Hmm, now that I see it this way ... maybe it does work better another way." Not because you don't know what you want, but because you learn by doing, seeing and feeling what works.

The illusion of control

I remember well how I once started as a project planner on a large, complex program. We were working with multiple tightly interwoven Microsoft Project plans that were linked together. Wonderful technical piece of art. Everything neatly worked out and dependencies clearly and tightly defined. But after just one day, reality was different. Tasks shifted, priorities changed and people were unavailable. Maintaining the plan became a full-time job in itself. And for what? Right: to report, be accountable and make others feel like we had everything under control.

 But real control we didn't have. What we were mainly doing? Maintaining the system.

Agile takes a different path. It recognizes that projects are organic and dynamic. And that change is not the exception, but the rule. Instead of putting energy into controlling every variable, we focus on adaptability and rhythm. Agile leaves room for the fast-changing nature of work and collaboration.

What is predictable

There is one crucial factor that is predictable though: the effort of a team. Or rather, the effort a stable team can put forth.

When a team works together, knows each other, and is given time to get into a good rhythm, something very valuable becomes apparent: a form of reliability. Not in the sense of "they always deliver exactly this or that," but in the sense of: it gives insight into what this team can carry on average. Velocity, capacity, burn rate - call it what you will. They are indicators of effort and you can build on that.

And that is exactly what Agile leans on. Not on predictability of content, but on predictability of capacity. Not on certainty about exactly what will come out later, but on confidence that the team is doing the right thing along the way - and is agile enough to adjust when necessary.

Agility requires trust

So Agile doesn't say, "We know exactly what we're going to make." It says, "We have a way of constantly learning what is best to make - and we have a team capable of doing that." This is a substantially different attitude.

Agility is not letting go of all frameworks. It is choosing different frameworks. Frameworks that fit a world where change is the rule. Instead of seeking false security in content, we seek reliability in process, in rimte, in people. That requires trust - in the team, in the ability to learn, and in the process itself.

About Merijn Sluis

This blog was written by Merlijn Sluis, Agilist at Valid. With over 25 years of experience in projects, transformations and organizational issues within a variety of companies and industries, he guides organizations in achieving sustainable Agile transformations.
Merlijn focuses on increasing agility, strengthening collaboration and driving continuous improvement within teams and organizations. His approach combines deep experience with an eye for organizational culture and behavioral change. In doing so, his focus is always on building strong and resilient teams that work from a common purpose.