Every organisation has a graveyard of frameworks that didn’t work. SAFe rollouts that created more coordination overhead than they removed. Kanban boards that became wallpaper. OKR cycles that nobody trusted.
The instinct, when a framework fails, is to find a better one.
Florian Raimann and Daniel Sack think that instinct is the problem.
At Agile Tour Vienna 2025, the two practitioners made the case that frameworks don’t fail teams – teams fail frameworks, by adopting them without understanding what they’re actually for. This article explores that argument, looks at what it means in practice for everything from process design to AI tooling, and asks the question that every team reaching for a new methodology should answer first:
What problem are you actually trying to solve?
Florian and Daniel open with an image that lands immediately: the helicopter consultant. Someone flies in, surveys the landscape from altitude, drops a framework – SAFe, Flight Levels, Wardley Maps, take your pick – and flies out to the next engagement. The organisation is left holding a methodology it doesn’t fully understand, applied to a context it was never designed for.
The alternative they propose isn’t another framework. It’s a different posture: walk the path together. There’s something that happens when a team works through hard problems collectively – the shared understanding, the ownership, the ability to explain why things are the way they are – that no drop-in solution can replicate. Change that arrives by helicopter rarely sticks.
Florian and Daniel are deliberate about scope here. A model isn’t just a formal scaling framework or a management methodology. It includes:
Mental models (how we think a system works), process models (how work should flow), architectural models (how systems should be structured), AI models (how a trained system predicts outputs), and the informal models embedded in team culture and individual habits.
All of them are simplifications. All simplifications involve information loss. The question is never „is this model correct?“ – it isn’t, by definition. The question is „what does this model help me see, and what does it cause me to miss?“
The Cynefin framework is useful here: different problem types require fundamentally different approaches. A model that works brilliantly in a complicated domain – where cause and effect are knowable – will produce actively harmful results in a complex domain, where they aren’t. Knowing which domain you’re in before reaching for a model is most of the work.
Three patterns come up again and again, across different frameworks and different organizations.
The model gets adopted, not adapted. It arrives as a complete system – roles, ceremonies, artefacts – and gets implemented as specified. The team is now doing the framework rather than solving their problem. When results don’t materialize, the conclusion is that the framework wasn’t followed correctly, rather than that the framework was the wrong fit.
The context gets ignored. Every model was designed for a specific kind of problem in a specific kind of environment. SAFe was designed for large enterprises coordinating multiple teams. Kanban was designed for visualizing and managing flow. Scrum was designed for small, cross-functional teams building complex products. These are different answers to different questions. Using the wrong answer is expensive.
The information that’s missing never gets named. This is the most insidious failure. Teams adopt a model, learn its vocabulary, measure the things it tells them to measure – and never ask what the model can’t see. Every framework has a blind spot. If you don’t name it explicitly, it runs unchecked.
Before reaching for a model, name the problem you’re actually trying to solve. Not the symptom („our sprints keep overrunning“) – the underlying dynamic („we have no shared understanding of what done means across teams“).
Once the problem is named precisely, the model choice becomes clearer. And often enough, the right tool is simpler than the one you were reaching for.
This is harder than it sounds in organizations under delivery pressure. The reflex is to reach for the most credible-looking framework available, apply it, and see what happens. The discipline Florian and Daniel are describing is the opposite: slow down long enough to understand the problem first, then choose the tool that fits it.
AI models are a particularly striking example of the talk’s central thesis. They are impressive. They are also wrong in ways that are hard to predict, inconsistent across inputs, and confident regardless of accuracy.
The teams getting real value from AI code generation are the ones treating it the way Florian and Daniel describe treating any model: as a tool with specific strengths, specific failure modes, and a context in which it works best. They’ve named what the model can’t do – reason about novel architectures, maintain consistency across large codebases, catch its own logical errors – and built workflows that compensate for those gaps. TechTalk’s Agentic Engineering Intro and Hands-On AI Agent Engineering programs are built around exactly this kind of honest prior assessment – understanding what agents can and can’t do before designing systems around them.
The teams struggling are the ones who adopted the model as a complete solution. The puzzlement when the output needs constant correction is the cost of skipping the problem-naming step.
Florian and Daniel’s closing argument is the most transferable thing in the talk: don’t adopt models, adapt them.
Take what’s useful for your specific context. Leave what isn’t. Make explicit what the model can’t see. And walk the path with your team, rather than landing frameworks on them from altitude.
This is harder than framework adoption. It requires judgment, which is harder to teach than the process. It requires honesty about what’s working, which is uncomfortable to sustain. And it requires the patience to let understanding develop incrementally, rather than announcing a transformation and hoping the culture follows.
The models aren’t the problem. The problem is the gap between what a model promises and what your specific situation actually needs – and the failure to look honestly at that gap. All models are wrong. The useful ones are the ones you understand well enough to know exactly how they’re wrong.
Florian Raimann and Daniel Sack spoke at Agile Tour Vienna 2025. The 2026 edition is live – the full program is available now.
Build your solid foundation through our training and continue developing your leadership and coaching journey.