Post #3528682

2026-06-17 06:14 UTC

Organisational Dysfunction of the Day The agile scaling trap Context: The teams are working well, or well enough. Sprints are running, retrospectives are happening, and there is some genuine ownership of the work. Then the question arrives from above: how do we scale this? The organisation has hundreds of developers across dozens of teams, and it needs them to be coordinated, aligned, and pulling in the same direction. A scaling framework is adopted; SAFe is the most common, but there are others. Release Trains are introduced. Programme Increment planning fills two days every quarter. A new layer of roles appears: Release Train Engineers, Solution Architects, Portfolio Managers. The teams are still doing agile. The organisation around them now looks remarkably like the bureaucracy agile was supposed to replace. OST explains: Scaling frameworks like SAFe are not an extension of agile; they are a reassertion of DP1 over the partial DP2 that agile attempts. The coordination problem agile never solved at the team level becomes acute at scale, and in the absence of a structural answer, the bureaucracy provides one: add a layer above. The Release Train is a project in disguise, the PI planning session is a quarterly waterfall, and the portfolio layer is the PMO with new vocabulary. OST predicted this: when you introduce DP2 practices into a DP1 organisation without changing the underlying design principle, DP1 will fight back, and it usually wins, because it controls the resources, the budget, and the careers. SAFe is not a solution to the scaling problem; it is proof that the scaling problem was always an organisational design problem agile never had an answer to. The answer is not a bigger framework but a hierarchy of functions. Self-managing groups at every level, each owning its whole task and coordinating as peers. Agile needed fixing. Instead, it got scaled. #OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Replies (1)

@trondhjort@hachyderm.io 2026-06-18 06:01

Organisational Dysfunction of the Day Budgets are bureaucracy Context: The organisation has restructured into product teams. They have autonomy over their work, their roadmap, and how they collaborate. Then comes budget season. Each team is asked to forecast its needs twelve to eighteen months ahead, justify them against business cases, and compete with other teams for a finite pool of money. The forecasts get approved or revised by people who are not part of the teams. Mid-year, priorities shift. Some budgets get cut. Others get reallocated through a process that the teams do not control. The autonomy on paper meets the finance department in practice. Everyone knows which one wins. The team owns the product, but not the resources that decide what the product can actually become. OST explains: Whoever controls the allocation of money controls the structure, regardless of what the org chart says. A DP2 design with DP1 budgeting is not a DP2 organisation. It is a DP1 organisation with self-managing teams operating in the spaces that money has decided in advance. DP2 requires that groups control the resources for their own work. That is what it means to own the whole task. What OST does not do is prescribe how this should look in a given organisation, because OST is a conceptual framework, not a recipe. A preset model handed down would itself be a DP1 move — exactly the kind of imposed design the theory argues against. The methods OST provides, Search Conference and Participative Design Workshop, exist to help an organisation work out its own answer, not to deliver one. Beyond Budgeting, developed in part by Norwegian practitioner Bjarte Bogsnes, is one practical attempt to separate the decisions about goals, resources, and evaluation that the annual budget collapses into one. It moves in the right direction. But the answer to how money should flow in a self-managing organisation is one that each organisation must design for itself, using its own people. The structure of money is the structure of the organisation. Both have to be designed together, by the people who will live with the result. #OpenSystemsTheory #SocioTechnical #OrgDesign #leadership

Open ##3528681