Iteration & Feedback: Why You Need Skills, Not Frameworks
The label “Agile” is burnt, as I already analyzed in my last article. Does that also mean that “Agile” itself is burnt? No! We just have to look closer: If we throw away all the baggage of role descriptions, certification circuses, Jira workflows, and colorful post-its, what is left?
It is exactly two words: Iteration and Feedback.
That is the entire core. Agile working is not rocket science; it is a mercilessly honest cycle: build something functional in short cycles, get real feedback, and permanently adjust the course. That’s all it is. But that is exactly where the problem lies: most companies haven’t mastered this core – and they hide their inability behind 500-page framework manuals.
The Fairytale of “We can’t release more often”
Whenever I talk about this topic online, I get the following answer over and over again.
Thomas, that sounds nice with the feedback. But we are an enterprise environment. Technically, we can only release every three months. Our architecture doesn’t allow for anything else.
My answer is harsh but honest: That is a lie.
It is not a God-given law that software takes three months to reach the customer. It is a decision not to invest in the necessary craft. Anyone who says “I can’t release more often” actually means: “We are afraid of our own code.” (Yes, there are exceptions, such as legal requirements...)
We must stop discussing agility as a management method. We must start perceiving it as a craft.
The Skill Gap Behind the Process Curtain
Why does it take three months? Because manual testing eats up weeks. Because deployment is a high-wire act without a safety net. Because nobody knows what happens if you pull on Module A while Module B is still hanging by a thread. Because there is no good planning and no story decomposition.
If your environment is complex – and it usually is, otherwise you wouldn’t need agile working – then the only way to minimize risk is to reduce the size of the units.
If your stories, and therefore your iterations, are too large, your risk of developing something the customer doesn’t need at all increases exponentially. If the feedback comes too late, you spend three months building something that misses the market. This becomes very expensive.
To break this vicious cycle, we don’t need new meetings; we need technical excellence. Testing, CI/CD, feature flags, and decoupled architectures are not “nice-to-have” developer gimmicks. They are the basic prerequisite for the word “Agile” to have any meaning at all. And believe me, you’ll be preaching to the choir with the devs. They have probably been demanding this for a long time or discussing it behind closed doors (in the retro).
Those who cannot release quickly cannot learn quickly. Those who do not learn quickly do not work agilely. They are just doing waterfall in expensive sprints.
The Good News: It Can Be Learned
The beauty of this realization is: missing skills are not destiny. You can work on them!
If you notice that your feedback cycle is too slow, then that is your most important backlog item. Forget the next feature. Make sure that the three months become three weeks. Then three days. Does that sound expensive? It is! But developing something that takes three months until it is released, only to find it doesn't fulfill what the users actually wanted, is even more expensive.
These steps require hard work on the system and on your own skills.
You must learn to slice tasks better. If a feature is too large for a quick release, you have sliced it incorrectly. There is always a smaller, value-adding part.
You must learn to automate. Every manual test is a brake on your agility. Decouple the release from the deployment: with feature flags, you can bring code live without immediately activating it for everyone. This takes the pressure off and increases the speed of feedback.
There are many other methods and approaches to keep features small. I mentioned a few of them in the article Backlog Refinement Technique: Slicing Tickets Like a Pro.
Conclusion: Focus on the Core
Regardless of whether your business card says Product Owner, CTO, Tech Lead, Scrum Master, Release Train Engineer, or Agile Coach: your job is not to moderate ceremonies. Your job is to clear the way for iteration and feedback.
If you work in a complex environment, the overhead of agile working (the meetings, the slicing, the coordination) is only justified if you actually get the power onto the road.
Stop hiding behind frameworks like SAFe, Scrum, or Kanban. Look at your feedback cycle. Is it too long? Then work on your skills instead of calling for new methods.
Agile working is a craft. And 2026 is the year we finally start building again.