Every few years, a new framework arrives in the software and organisational world that promises to solve the hardest problems. You know the pattern: the book comes out, the conference talks follow, the consulting practices spin up, and soon enough teams everywhere are adopting the thing wholesale – restructuring, renaming, retooling – in the hope that this time, the framework will be the one that makes it all click.
At Agile Tour Vienna 2025, Florian Raimann and Daniel Sack took the stage with a title borrowed from the statistician George Box – all models are wrong, but some are useful – and spent their session making a carefully argued case against exactly that pattern. Not against any specific framework. Against the mindset that makes organisations reach for frameworks in the first place, as if a model designed elsewhere, for someone else’s context, could arrive pre-fitted to yours.
Florian is a leadership and organisational development specialist with a background in business and neuroscience. Daniel is a software architect with fifteen years of experience who thinks about organisations the way architects think about systems – with attention to structure, coupling, and the hidden assumptions baked into every design choice. Together, they brought a perspective that was part engineering, part psychology, and entirely practical.
Florian and Daniel open with a scene that anyone who has worked in technology transformation will recognise immediately. An organisation is struggling – with processes, with unclear requirements, with the gap between what gets built and what actually gets used. Someone calls in an expert. The expert flies in, surveys the landscape from a comfortable altitude, identifies a framework that matches the rough shape of the problem, and drops it. Kafka. SAFe. Flight Levels. OKRs. Whatever is currently on the conference hype cycle. Then the expert flies off 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, without the accumulated knowledge of why each piece of it exists. The framework might be excellent. The problem is the delivery mechanism. Change that arrives from a helicopter rarely sticks – not because the ideas are wrong, but because the people who have to live with the change didn’t build it with their hands, didn’t struggle through the hard parts, didn’t develop the understanding that comes from walking the path rather than being airlifted to the destination.
The alternative Florian and Daniel propose is not a better helicopter. It’s a different posture entirely: walk the path together. This sounds slower. It often is, at least at first. But the kind of understanding that gets built when teams work through hard problems collectively – the shared language, the ownership of the solution, the ability to explain to a new joiner exactly why things are the way they are – is qualitatively different from anything a dropped framework can produce. And the change lasts, because the people involved understand it well enough to maintain and evolve it.
George Box’s aphorism, borrowed from statistics, provides the intellectual grounding for everything that follows. All models are wrong. That’s not a failure – it’s the nature of models. We live in a world too complex and too fast-moving to capture completely in any abstraction. Models help us simplify complexity to the point where our brains can process it, work with it, make decisions. The simplification is the point. But simplification is also always information loss. Something gets left out. Every framework, every best practice, every set of principles has something it can’t see – and the job of the thoughtful practitioner is to know what that is.
Before going further, Florian and Daniel are careful to define the scope of what they mean by a model, because it’s broader than most people assume. It isn’t just frameworks like Scrum or SAFe. It isn’t just formal methodologies or documented processes.
A model, in the sense they’re using, is any simplified representation of something more complex that is designed to help us think about it. That includes principles, concepts, heuristics, practices, roadmaps, mental models, hypotheses, paradigms, strategies, and simulations. All of these are models. All of them are simplifications. All of them have a context in which they work well and contexts in which they don’t.
The point isn’t that models are bad – it’s that they are always purpose-built. A construction blueprint and an architectural rendering of the same building serve completely different purposes. Neither is wrong. Neither is the full truth. Both are useful – in the right context, for the right question. The error is in treating a model as if it were the territory rather than a map, or in using one type of map to navigate terrain it was never designed for.
This framing has a practical implication: choosing a model should be a deliberate act. Before reaching for a framework, it’s worth asking three questions. What specific problem are we trying to think through? What does this model help us see that we couldn’t see before? And what does it cause us to miss?
One of the more unexpected references in the talk is Bloom’s Taxonomy – a model from educational psychology that describes levels of cognitive engagement. At the base: remembering and understanding. In the middle: applying and analysing. At the top: evaluating and creating.
Florian and Daniel use it to make a point about what organisations need from their people right now, in a moment when AI tools can instantly produce answers to almost any question you can formulate.
If an AI can recall any fact, apply any standard pattern, and synthesise any existing knowledge faster than any human, then the competitive value of doing those things yourself collapses. What remains – and what AI cannot substitute for – is the higher-order thinking at the top of the taxonomy: the capacity to analyse a specific situation in its full complexity, evaluate genuinely different options against each other, and create solutions that are fitted to a particular context in ways that haven’t been templated before.
That’s what autonomous teams need to be able to do. Not just follow the sprint ceremonies, not just remember which column cards go in, but genuinely reason about the problems in front of them, evaluate trade-offs, and propose solutions that make sense given their specific constraints. Bloom’s Taxonomy works as a diagnostic here: if a team is spending most of its time in the lower tiers – executing procedures, following checklists, applying standard patterns – that’s a signal. Not necessarily that they’re doing things wrong, but that there’s headroom to develop, and that the work of an agile coach or organisational designer might most usefully focus there.
Rather than replacing one framework with another, Florian and Daniel structure their approach around three dimensions that every organisation navigating change has to work through: where you’re trying to get to, where you are now, and the path between the two. For each dimension, they share models that have genuinely helped them in practice – presented not as prescriptions but as examples of useful thinking tools.
Defining a target picture
The most important shift in how most organisations think about goals is toward genuine customer focus and personal honesty. Florian and Daniel draw on Amazon’s “working backwards” discipline as an example of the former: before writing a specification, before designing a feature, write the press release. Describe the outcome as if it’s already happened, in language a customer would understand. If you can’t write that press release, you don’t yet understand what you’re trying to build.
Equally important – and far more often skipped – is the personal story behind the goal. Why does this particular person, in this particular role, actually want this outcome? What does success mean to them, beyond the business case? When that question goes unasked, the stated goal is often a proxy for something else: a political need, a status concern, a fear of a different outcome. Making the personal story explicit doesn’t make it go away. It makes it discussable.
Their approach to goal-setting deliberately resists jumping straight to metrics. Instead, they work through a sequence of time-framed questions: what does success look and feel like in one year? In two? What has to be true in three months for us to believe we’re on track? The time horizons are chosen carefully – close enough to be concrete and actionable, far enough to be genuinely ambitious. Metrics come later, once there’s shared understanding of the direction. Trying to define metrics before that shared understanding exists usually produces metrics that measure the wrong things precisely.
Understanding the current state
The single strongest recommendation in this section is also the simplest: stop sending specialists in separately. The pattern of letting business analysts map the process first, then developers assess the technical landscape, then architects review the system design, produces three incompatible pictures of the same reality. The business analyst’s map doesn’t match the developer’s map, which doesn’t match the architect’s map, and nobody is wrong – they’re just describing different projections of a complex system.
The alternative is to bring people from all of those perspectives into the same room and model the current state together. EventStorming is Florian and Daniel’s preferred method for this – a collaborative workshop technique in which participants from across the organisation map out domain events together, on a shared surface, using a shared language, until a picture emerges that everyone can recognise as true.
The results are often surprising in their content and unsurprising in their form. A thirty-person EventStorming session at an educational organisation surfaced almost no new technical insights. What it surfaced was human: the moment when someone from one team discovered that another team had been doing something for years that made their own work significantly harder – and that both teams had simply never been in the same room long enough to notice. “If I’d known you were doing that, I wouldn’t have sent the email.” That sentence justified the entire workshop. The silo problem, seen up close, is usually a visibility problem. Collective modelling makes invisible things visible.
Finding the path between
Two tools get particular attention here. The first is Wardley Mapping, which Daniel illustrates through a case study from their own experience organising ComooCamp, a community conference. In the first year, everything was manual: every ticket registration came in through a web form, was typed up by hand into a Word document, and an invoice was sent manually by email. Four people, 120 participants, in their spare time. The overhead was significant.
After the first year, they used Wardley Mapping to look at their value chain – to understand which activities were genuinely differentiating and which were commodity problems that had already been solved elsewhere. Ticket management fell clearly in the second category. They bought standard software, automated the flow, and reduced their manual workload by 80%. The map also helped them identify where to take genuine creative risk: a new “Day Zero” format – an additional pre-conference day – was trialled on a small, experimental basis. It sold out immediately. The conference was restructured around it. The map didn’t make these decisions. It made them easier to see and easier to discuss, which is what good models do.
The second tool is Architectural Decision Records – or more precisely, the thinking process behind them. The format is simple: document the problem you were trying to solve, the options you considered, the decision you made, and its consequences. Revisit it when someone, three months or three years later, asks why things are the way they are. The value is not the document. The value is the discipline of making decisions explicit, so that they can be revisited as understanding grows and circumstances change. Nobody made a bad architectural decision on purpose. They made the best decision they could with the information they had at the time. Write it down. When you know more, you can make a better decision – and the record tells you what you thought you knew, and what turned out to be different.
A section on software architecture that applies equally well to organisational design. Conway’s Law – the observation that systems tend to reflect the communication structures of the organisations that build them – is often cited in technical discussions. Florian and Daniel apply it more broadly.
If there is a hard organisational boundary between two functions, the software those functions build will have a hard boundary in the same place. You can try to design around it, but the boundary will reassert itself over time, because the communication channels that shape the work haven’t changed. The implication is significant: if you want a different architecture, you may need to change the conversation structure first.
Team Topologies provides useful vocabulary here – stream-aligned teams, enabling teams, platform teams – but the vocabulary only becomes actionable once you’ve done the harder work of defining what a “stream” actually means in your specific organisational context. That’s where Domain-Driven Design earns its keep: not the tactical patterns (value objects, aggregates, repositories), but the strategic tools – bounded contexts, ubiquitous language – that help an organisation understand its own structure clearly enough to make deliberate choices about it.
Cognitive load is the other constraint. The instinct in many organisations is to build feature teams that own everything end to end. In principle this is appealing – full ownership, no hand-offs, maximum autonomy. In practice, the scope of what a team needs to understand to operate that way has grown dramatically. There are now so many layers – cloud infrastructure, security, data, accessibility, performance, integrations – that the cognitive load of owning all of them genuinely exceeds what most teams can carry. The question shifts from “who owns it all?” to “what does this specific team need to focus on, and what should be provided as a service so they don’t have to?”
The talk closes with a reflection on how change actually sticks, and why so much organisational change doesn’t.
Ceremonies – retrospectives, sprint reviews, daily standups – are valuable. But they are means to an end, and in many organisations they have become ends in themselves. The team runs the retrospective. The cards go on the board. The actions are written down and never revisited. The ceremony was completed. The improvement didn’t happen.
Florian and Daniel draw on Atomic Habits to think about this differently. The unit of organisational change isn’t the event. It isn’t the workshop or the training or the transformation programme. It’s the habit – the small, regularly repeated behaviour that gradually reshapes how work gets done. Habits can be examined, adjusted, and replaced in ways that one-off events cannot. And the question worth asking, of any ceremony, is whether it is genuinely connected to a behaviour change that improves outcomes – or whether it has become self-justifying, a ritual that the team performs because that’s what agile teams do.
The same logic applies to metrics. If you’re measuring outputs and calling them outcomes, the ritual of measuring is working against you. The question of whether what you’re tracking is actually connected to the impact you’re trying to create is worth revisiting – not every week, but regularly enough that drift gets caught before it hardens into habit.
Florian closes with the single line he most wants the audience to carry away: don’t adopt models – adapt them.
No framework arrives pre-fitted to your context. Every model was designed somewhere else, for someone else’s problems, in an environment with constraints that differ from yours in ways that are hard to see until the framework breaks. The work – the real work, the slow work, the work that produces change that lasts – is to understand why a model works where it works, to identify the underlying principles that make it effective in that context, and to extract and apply those principles in your own situation with judgment and care.
That is slower than dropping a framework from a helicopter. It is also the only thing that actually works.
