The gap does not stay empty. Where coordination has not been designed into the structure, someone still supplies it informally: chasing a decision that should have happened on its own, following up because nobody owns the interface between two teams. Wilfred Bion named this pattern pairing, one of several defensive dynamics a group falls into when the structure is not doing the coordinating work for it. It looks, from the outside, like commitment. It is, for the person doing it, an unpaid job nobody assigned them.

Agile did not fix this. It created a version of it. The scaling frameworks that followed, SAFe, LeSS, and the rest, formalise the pairing that was already happening: they give the missing coordination a role and a ritual instead of a design. They are DP1 reasserting itself at the level above, filling the coordination vacuum with a bureaucracy that now has a PI planning ceremony instead of a waterfall project.

The industry is recoverable. Not by doing more Agile, and not by scaling it. By understanding what it missed.

***

This argument is explored further in my book, Organisational Dysfunctions: Open Systems Theory Explains, out now.
http://organisationaldysfunctions.com

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

(2/2)

Organisational Dysfunction of the Day

The agile terrarium

Context: Agile transformed how software is built. Iterative delivery, short feedback loops, cross-functional teams, and continuous improvement. These were genuine advances over the heavyweight waterfall projects they replaced. The lean movement provided much of the intellectual scaffolding: eliminate waste, optimise flow, respect the people doing the work. And yet, decades on, the research is clear that agile has not delivered the engaged, self-managing, high-performing teams it probably hoped. The process works reasonably well. The organisation around it largely does not. @einarwh described agile teams as terrariums: self-contained ecosystems that look alive and healthy from the inside but are sealed off from the real environment around them. Most people working in agile organisations will recognise that image immediately.

OST explains: The terrarium image is more precise than it might seem. A terrarium is a closed system; it regulates its own internal conditions but does not transact with its environment. That is exactly what agile teams are often designed to be: protected from the turbulence outside, given a stable backlog and told to focus. An open system survives by engaging with its environment, learning from it, and actively adapting to it. Sealing it off does not make the turbulence disappear; it just accumulates outside the glass until something breaks. The agile founders identified "structure" as the problem and removed supervision, but left coordination undefined and control in the hands of individuals. The result was not a move to self-managing groups, what we call DP2, but laissez-faire: an industry lost in the wilderness between DP1, the bureaucratic structure most people work inside, and the self-managing alternative. Research surveying the software industry found 55.7% of respondents were predominantly high laissez-faire, more than either DP1 or DP2. Agile is not failing because the process is wrong. It is failing because a closed system cannot adapt, and the industry has been trying to solve an open systems problem with a delivery methodology.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Deploying AI into a broken system

Context: The organisation is deploying AI: copilots, automated pipelines, intelligent triage, and decision support. The pilots look promising; the broader rollout is patchy, with some people embracing the tools and others routing around them. A few raise concerns about deskilling, about oversight, about what happens when the AI gets it wrong. Leadership frames this as change resistance. The change management programme is expanded. Meanwhile, the tools are also being used to monitor output, flag underperformance, and justify headcount decisions. The people who were concerned start to understand why they were concerned.

OST explains: This pattern is not new. Sociotechnical systems research emerged in the 1950s precisely because organisations kept introducing new technology with enormous focus on technical capability and almost no attention to the social system. The result was that technology failed to deliver its potential, workers became alienated, and productivity gains were short-lived. The core insight applies directly to AI: you will not get the benefit by optimising the technical system alone. In DP1, the manager-led structure, people are defined by the task they perform. One person, one job, one replaceable part, so when the task can be automated, the person becomes redundant by the organisation's own logic. In DP2, the group owns the whole task, and each person brings judgment, context, and adaptability that no tool replicates; AI becomes an extension of the group's capability rather than a replacement of it. In a DP1 structure, AI is almost inevitably used as a tool of control, monitoring output, flagging underperformance, and surveilling the parts. We are in the middle of the fourth industrial revolution and making exactly the same mistake as the third.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Fixing people

Context: "No matter how it looks at first, it's always a people problem." Gerald Weinberg's Second Law of Consulting is good advice. It is a reminder that the human dimension is always present, that purely technical diagnoses miss something essential, and that the people involved always matter. Most managers and HR professionals would recognise themselves in it. Someone on the team is struggling. Maybe they are disengaged, not delivering, clashing with colleagues, or just not showing up in the way they used to. The organisation's response is to fix the person: a performance improvement plan, a coaching programme, a personality assessment, or a quiet word from HR. Sometimes it works for a while. But the same problems keep reappearing, often with different people in the same role. The carousel of interventions never quite stops.

OST explains: Weinberg is right that it is always a people problem; people's experience, motivation, and well-being are always at stake. OST does not disagree; it adds the next step. When the same dysfunction shows up repeatedly across different people in the same role, the problem is not those individuals; it is what the system does to whoever occupies that position. DP1 structures (manager-led), with their competition for recognition and dependency on management for decisions, produce exactly the disengagement and avoidance that organisations then try to coach out of people. Fixing the individual while leaving the structure intact contains a deep paradox: elevating the individual as the problem, isolated from the structure shaping their behaviour, goes beyond blaming the victim; it creates them. So yes, it is always a people problem. The question OST asks is: what is the structure doing to the people?

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Writing Use Cases for AI: How to write use cases for stakeholders, engineers, and AI agents by Simon Martinelli is the featured book 📖 on Leanpub!

Your use cases have a new reader: an AI agent that turns them directly into code and tests. Implementation is now cheap but expressing intent precisely is the bottleneck.

Link: https://leanpub.com/writing-use-cases-for-ai

#Software_engineering #Ai #Computer_programming #Agile

Next-Gen Architecture Playbook: Insights and Patterns for the AI Era

Software architecture faces a pivotal moment: rapid iteration, cloud-native adoption, and ubiquitous AI are reshaping system design. However,…
#NewsBeep #News #Artsanddesign #Agile #AI #AIArchitecture #Architecture #Architecture&Design #Arts #ArtsAndDesign #Design #DevOps #Entertainment #ML&DataEngineering #nextgenarchitectureaiera #PlatformEngineering #UK #UnitedKingdom
https://www.newsbeep.com/uk/759766/

Next-Gen Architecture Playbook: Insights and Patterns for the AI Era

Software architecture faces a pivotal moment: rapid iteration, cloud-native adoption, and ubiquitous AI are reshaping system design. However,…
#NewsBeep #News #Artsanddesign #Agile #AI #AIArchitecture #Architecture #Architecture&Design #Arts #ArtsAndDesign #AU #Australia #Design #DevOps #Entertainment #ML&DataEngineering #nextgenarchitectureaiera #PlatformEngineering
https://www.newsbeep.com/au/879668/

One of the most expensive phrases in software development:

“Don't touch that. Only Brian understands it.”

That's not expertise.

Expertise is valuable.

Dependency is the problem.

Clear, coherent, well-tested code helps knowledge travel across the team.

The goal isn't making everyone interchangeable.

It's making sure the software doesn't depend on one person's memory to survive.

#Agile #Teamwork #SoftwareDevelopment #BusFactor

Lean Agile Predictability Bundle by Daniel S. Vacanti is the featured bundle of ebooks 📚 on Leanpub!

Link: https://leanpub.com/b/leanagilepredictabilitybundle

#Business_and_management #Agile #Leadership_agile #Agile_business_leadership #Lean

The best refactoring doesn't necessarily produce the cleverest code.

It produces better code.

Those aren't always the same thing.

A new abstraction might reduce duplication while making the system harder to understand.

A design pattern might look elegant while adding machinery nobody needs.

A shorter solution might become cryptic.

Technical excellence requires judgement.

Not commandments.

#Agile #Refactoring #SoftwareDesign

please join and help fixing the hype ;)

@christiaanverwijs

@agile
#agile #scrum #liberatingstructures

Top Links
OpenClaw 2.0, Accidentally (Hannes Rudolph)
Adding Full-Text Search to Blazor WebAssembly with Pagefind (David Pine)
Merge Conflict Episode #530 - WinUI Goes Open Source & Mac Mini/Studio Upgrades! (James Montemagno & Frank Kreuger)
From Leaderboards to Model Profiles: …

A team can have:

2-week sprints.
Daily stand-ups.
Retrospectives.
A Scrum board.

…and still take six weeks to make a small change.

That's because process agility and technical agility aren't the same thing.

If the code fights every change, the organization eventually moves at the speed of the codebase.

#Agile #Scrum #SoftwareDevelopment #TechnicalDebt

Депеши, карточки и паранойя: мой опыт скрещивания Waterfall и Agile в проекте для РЖД. Часть вторая

Добро пожаловать обратно, друзья. Если вы читали первую часть , то знаете, как мы выстраивали периметр, прикрывали тылы и готовились к штурму. Теперь переходим к самому интересному – к продукту. К тому самому «цифровому космолету» , который должен был перевернуть рынок пассажирских перевозок. Но как это часто бывает в больших проектах, эпичный концепт столкнулся с не менее эпичной реальностью. Легаси-инфраструктура с которой мы столкнулись и на которой нам предстояло строить этот самый «космолет», в реале оказалась сложнее и неповоротливей, чем мы могли себе представить. Распределённая архитектура, множество стыковочных узлов, кривые сторонние сервисы, языковые и культурные барьеры внутри команд, а главное – жёсткие рамки Waterfall . Всё это требовало не просто инженерной смекалки, а умения балансировать между интересами разных игроков, не теряя фокуса на конечном пользователе. В этой части я проведу вас через наш интеграционный лабиринт. Расскажу, как мы собирали команду, выстраивали процессы, договаривались со стороной интегратора и проектировали идеальное API. Какой путь мы успели пробежать за 8 месяцев хардкора. И как я впервые столкнулся с «обстоятельствами непреодолимой силы». В финале я дам вам 10 правил работы с госами , которые мы вынесли из этого опыта и могут оказаться полезными, если вы окажетесь в подобной ситуации. Если вы не читали первую часть – рекомендую вернуться. Там о том, как мы выстраивали юридическую защиту и внедряли практически полноценный Agile под маской Waterfall . Это не просто «история», это набор инструментов, который помогал нам не сойти с ума. Но если вам ближе продуктовое мясо и детали реализации - добро пожаловать прямо сюда. Читать мою историю можно в любом порядке. Приготовьтесь, отправляемся. Следующая станция – «прод».

https://habr.com/ru/articles/1076876/

#системная_архитектура #управление_проектами_и_командой #agile #waterfall #ржд #легаси #интеграция #проектирование_систем #enterprise #архитектура

Top Links
WinUI OSS Update: Phased Rollout Toward Open Collaboration (Beth Pan) - Rollout complete
TechBash 2026 - Communication Workshop Spotlight (plus don't miss out on Labor Day registration savings) (TechBash Team)
What were the biggest technical shifts in Visual Studio and …

Today, I continue my series on the INVEST model.

https://www.edyouragilecoach.com/v-is-for-valuable/

🏴‍☠️ 🐻

#Business #ghostGang #agile #leadership

@agilealliance

Ansible for DevOps: Server and configuration management for humans by Jeff Geerling 📖 on Leanpub!

Ansible is a simple, but powerful, server and configuration management tool. Learn to use Ansible effectively, whether you manage one server—or thousands.

Link: https://leanpub.com/ansible-for-devops

#Books #eBooks #LeanPublishing #SelfPublishing #Agile

#LINKSDERWOCHE | 34/2026: Produktivität, Lean, Agile, Management und Leadership

PRODUKTIVITÄT

Show your Work | Selbstmarketing anders denken

Hui, da hat mich Lars Richter mit seinem Blogpost angefixt, meine Liste der noch zu lesenden Bücher doch wieder zu öffnen, obwohl ich sie (vorläufig) geschlossen hatte, da sie ohnehin schon sehr lang war. Und das mit einem Blogpost, in dem er vier Erkenntnisse teilt, die er daraus gewonnen hat. Das ist sehr interessant, weil vieles davon im Gegensatz zu dem steht, was ich jeden Tag auf LinkedIn wahrnehme. Dort nehme ich immer mehr „optimierte Selbstdarstellung“ wahr, die den vier Learnings deutlich widerspricht. Es wäre schön, wenn sich manche dies zum Vorbild nehmen würden.

https://scamper.blog/show-your-work/

Digital und in Papier | Weshalb digital allein nicht immer der richtige Weg sein muss

Ich arbeite viel digital, aber auch weiterhin viel analog. Darin sehe ich keinen Widerspruch. Meine Arbeitsweise ist sicherlich nicht ganz mit der von Daniel Schimpke vergleichbar. Bulletjournaling habe ich selbst auch schon probiert, aber es hat sich bei mir nicht durchgesetzt. Jeder hat so seine individuellen Vorlieben. Bei mir ist es beispielsweise so, dass ich Gesprächsnotizen und Ähnliches im Laufe des Tages meist erst auf Papier notiere. Ich arbeite auch gerne nach der Ivy-Lee-Methode. Papier ist dafür schneller, ich kann „kreativ kritzeln” und die Tastaturgeräusche fallen weg. Am Ende des Tages fasse ich meine Notizen dann digital in Obsidian zusammen und ergänze alle weiteren Informationen, die ggf. später gebraucht werden. Alles, was nicht mehr relevant ist, wird nicht übertragen. Ähnlich wie bei Daniel Schimpke ist Obsidian daher der langfristige Speicher, das analoge Medium ist der kurzfristige Speicher. Es ist also kein Widerspruch. Ganz im Gegenteil. Es ergänzt sich gut. Wie so oft muss das System allerdings passen. Und das ist eben das für mich passende System.

https://www.kadaschi.de/obsidian-reicht-nicht-warum-ich-trotzdem-ein-bullet-journal-fuehre/

Aufgaben streichen | Altlasten in der ToDo-Liste streichen

Ivan Blatter hat wieder einmal eine tolle Podcast-Folge produziert. Das Thema erinnert mich ein bisschen an das Backlog mancher agiler Teams, das regelrecht überläuft, weil uralte Einträge immer noch darin liegen. Ähnlich ist es bei den ganzen Aufgabenlisten, die man so führt. Da sammelt sich viel Altlasten an, die Aufmerksamkeit binden. Ich habe mir deshalb angewöhnt, meine Themenlisten wöchentlich und meine Aufgabenlisten täglich aufzuräumen. Ich streiche gnadenlos alles, was ich – je nach Flughöhe – schon länger nicht mehr angefasst habe. Frei nach dem Motto: Wenn es wichtig war, kommt das Thema schon wieder hoch. Also weg damit. Hört am besten selbst rein. Auch wenn ich manches schon ähnlich handhabe, habe ich noch ein paar neue Ideen mitgenommen. Man lernt ja bekanntlich nie aus.

https://share.transistor.fm/s/9e9a2bc1

Verantwortlichkeit | Verantwortlichkeit bedeutet Konsquenzen umsetzen

Dan Rockwell trifft öfter mal einen Nerv bei mir. Das muss der Grund sein, weshalb ich seinen Blog regelmäßig lese. Mit dem verlinkten Beitrag auch wieder. Aufmerksame Leser meines Blogs wissen, dass Verantwortungsübernahme ein Thema ist, das mir sehr wichtig ist (und bei dem ich mich selbst regelmäßig an die eigene Nase fasse). Verantwortung zu übernehmen bedeutet für mich nicht, die Schuldfrage zu klären, sondern Konsequenzen abzuleiten. Wenn ich einen Fehler gemacht habe – und das kommt häufiger vor – dann gehe ich den Ursachen auf den Grund und leite Konsequenzen ab. Das klappt zwar nicht immer perfekt, aber auch daran arbeite ich immer wieder. Da muss ich in der Tat noch besser werden. Aber wie sagte meine Frau neulich: Einsicht ist der erste Schritt zur Besserung 😉

https://leadershipfreak.blog/2026/08/24/accountability-needs-consequences/

LEAN

Auslöser und Reaktion | Weshalb wir nicht sofort reagieren sollten

Der Beitrag von Ron Pereira könnte auch unter dem Thema Produktivität eingeordnet werden, da er im Prinzip beschreibt, wie wir besser auf einen Auslöser reagieren, um nicht vorschnell, sondern reflektiert zu handeln. Das passiert mir, wie vermutlich vielen anderen Menschen auch, öfter, als uns lieb ist. Es geht um Selbstregulation im Sinne von Multiple Perspective Advantage (MPA). Die Idee lässt sich wie folgt zusammenfassen: Anstatt sofort emotional auf einen Reiz zu reagieren, tritt man mental zurück und beobachtet sich aus einer anderen Perspektive. Klingt einfach. Leider ist es das nicht immer. Man muss es trainieren. Und selbst dann klappt es in einer stressigen Situation nicht immer, wie wir alle wissen. Aber man wird besser. Pereira überträgt das Ganze auf den Lean-Kontext. Interessanterweise passt das sogar sehr gut zu meiner Selbstbeobachtung der letzten Wochen. Es ist gerade eines der Themen, bei denen ich deutlich besser werden möchte. Zufall? Selektive Wahrnehmung? Auf jeden Fall ein passender Impuls für mich – und hoffentlich auch für einige andere.

https://blog.gembaacademy.com/2026/08/26/the-space-between-trigger-and-response/

Lean Digitalisierung | Erst Prozess verbessern, dann digitialisieren

Es wird bekanntermaßen fröhlich digitalisiert. So richtig, was das Zeug hält. Doof nur, dass in vielen Fällen zwei Dinge zusammenkommen: Erstens werden analoge Prozesse 1:1 digitalisiert und zweitens spielt es oft keine Rolle, was das für die Beteiligten bedeutet. Solche Beispiele hatte ich in letzter Zeit als Betroffener mehrfach. Und ganz ehrlich, am liebsten hätte ich den Verantwortlichen meine Meinung gegeigt. Statt einfacher wurde es komplizierter. Das kann es nicht sein. Wenn man digitalisiert, sollte man die Prozesse aus der Perspektive der betroffenen Menschen betrachten. Man sollte den Prozess von rechts nach links betrachten und sich tatsächlich die Frage stellen, ob dadurch für die Beteiligten irgendetwas einfacher wird. Genau das stellt Alen Ganic dar. So würde ich es mir wünschen. Und so sollte es meines Erachtens sein. Digitalisierung um der Digitalisierung willen ist nicht das Ziel.

https://blog.gembaacademy.com/2026/08/24/lean-digitalization-improve-the-process-before-you-digitize-it/

Obeya | Kein Selbstzweck, sondern Unterstützung beim Veränderungsprozess

Ich bin bekennender Obeya-Fan und habe früher sogar die Qualifikation als Obeya-Coach erworben, da ich von Obeya sehr überzeugt bin. Leider durfte ich mein Wissen bisher noch nicht im vollen Umfang einsetzen. Schade eigentlich. Das wird hoffentlich noch kommen. Einer der Punkte, die ich in meiner Ausbildung gelernt habe und die auch im Beitrag von Götz Müller zu Obeya von zentraler Bedeutung sind, ist: Ein Obeya ist dazu da, Menschen dabei zu helfen, gute Entscheidungen zu treffen. Darauf kommt es ganz besonders an. Er verändert die Art der Zusammenarbeit. Wenn das nicht der Fall ist, dann stimmt etwas nicht. Visualisierung ist kein Selbstzweck, sondern soll dabei helfen, Kaizen mit Leben zu füllen.

https://www.geemco.de/artikel/wenn-obeya-zum-besprechungsraum-wird/

Menschliche Fehler | Tiefer Bohren statt Schudlige suchen

In seinem Blogartikel zeigt Mark Graban sehr schön, worum es bei den fünf Weshalb eigentlich geht – und das, ohne sie zu erwähnen. Als Aufhänger dient ihm die Aussage, dass ein Fehler auf menschliches Versagen zurückzuführen sei und die Frage, wie es überhaupt zu diesem menschlichen Versagen gekommen sei, nicht weiter hinterfragt werde. Mit anderen Worten: Man hat seinen Sündenbock gefunden und geht der eigentlichen Ursache nicht weiter nach. Genau das machen echte Lean-Enthusiasten und Kaizen-Fans aber nicht. Sie bohren tiefer. Sie wollen verstehen, was dazu beigetragen hat und wie man es künftig verhindern kann. Denn das, was oft als menschliches Versagen abgetan wird, kann künftig vermieden werden, wenn man tiefer gräbt. Es ist anstrengend. Aber es lohnt sich.

https://www.leanblog.org/2026/08/human-error-root-cause/

AGILE

Neurodiversität und Führung | Weshalb wir uns nicht zu voreiligen Einschätzungen hinreißen lassen sollten

Tja, das Thema Neurodiversität beschäftigt auch mich derzeit sehr. Ausgelöst wurde es durch eines meiner Kinder, das – so gehen wir derzeit davon aus – in das Spektrum gehört. Die Beschäftigung damit löst auch bei mir einiges aus. Zum einen, weil ich gelernt habe, dass deutlich mehr Menschen in das Spektrum fallen, als uns oft bewusst ist. Sicherlich wissen auch viele gar nicht, dass sie dazugehören. Auch das ist eine Erkenntnis der letzten Wochen: Über mein Kind lerne ich gerade, dass sogar ich selbst betroffen sein könnte. Leider spricht kaum jemand darüber. Das kann zum Problem werden, weil wir Menschen dann falsch einschätzen. Auch in einem Team. Es ist schön, dass das Thema langsam in die Breite getragen wird und die Sensibilität zunimmt. Danke, Doris Weißgerber. Ein schöner Impuls. Mich hat es auf jeden Fall bestärkt, diesem Thema deutlich mehr Beachtung zu schenken. Auch im beruflichen Kontext.

https://www.teamworkblog.de/2026/08/die-sache-mit-den-faulen.html

Backlogpriorisierung | Wenn Priorisierung nach Aufwand nicht mehr greift …

Ich lese immer öfter, dass KI den Aufwand in vielen Arbeitsbereichen deutlich reduzieren kann. Das hat natürlich zur Folge, dass viele Priorisierungstechniken für das Backlog, die auf Aufwand und Nutzen basieren, nicht wirklich greifen. Wir brauchen also neue Impulse. Die Produktwerker nehmen das Thema in ihrem Podcast auf und bringen unter anderem die Aspekte Lernwert und Umkehrbarkeit ins Spiel. Der Podcast ist auf jeden Fall hörenswert. Gerade die Kombination aus Lernwert und Umkehrbarkeit klingt für mich sehr gut. Ich will nicht zu sehr vorgreifen.

https://produktwerker.de/product-backlog-priorisierung-wenn-aufwand-nicht-mehr-die-bremse-ist/

MANAGEMENT UND LEADERSHIP

Idenitity Leadership | Ein schneller Überblick

Durch den Blog von Daniel Dubbel bin ich auf das Thema „Identity Leadership” aufmerksam geworden. Das Themenfeld war mir – muss ich ehrlich sagen – bisher noch gar nicht bekannt. Der Blogartikel war etwas anspruchsvoller zu lesen, dafür aber sehr aufschlussreich. Das klingt nach einem spannenden Thema. Zumindest für mich. Ich bin ohnehin der Auffassung, dass Führung wesentlich komplexer ist und aus dem Zusammenspiel von Führenden, Geführten und Situation entsteht. Es ist also keineswegs allein die Führungspersönlichkeit, die ausschlaggebend ist. Von daher passt das Modell möglicherweise ganz gut zu meiner These.

https://www.inspectandadapt.de/identity-leadership-ein-starkes-modell-das-an-der-eigenen-logik-haengen-bleibt/

Organisational Dysfunction of the Day

Team leads

Context: Most teams in modern agile organisations may not formally have a manager in the same sense as before. Many still have someone they report to as an employee, dealing with yearly reviews, career development, and any job issues, but they are not formally involved in the daily work. It should therefore be possible to have leaderless teams, where all members are peers and have the same say in everything. No ranking. Still, many teams end up being appointed a team lead, often because the organisation wants one contact point and one person in charge of the work done. Many in this position try to deal with this dissonance by taking on a coaching type role, seeing themselves as a "servant leader," giving space to the team and protecting them from the outside. Some even try to switch, being directive sometimes, supportive at other times (aka situational leadership). Not only is this a tricky job to have, but it also creates so much confusion in the team about who really decides and is in charge.

OST explains: DP1-type organisations require personal leadership positions, as that is how control, coordination and alignment are managed. Agile tries to counter that for efficiency, having teams take more control of the work, in an attempt to shorten the feedback loop and the learning. This is similar to DP2, with self-organising teams, while adding team leaders is not and is an attempt to adapt them to the existing bureaucratic DP1 model. The problem with this is that DP1 and DP2 fit together like oil and water; they are fundamentally so different that no matter how good the adapters are, they will lead to confusion and operational problems. You can remove the need for this adapter by ditching DP1, having teams everywhere and letting them take responsibility for their own goals and the integration needed to work with other teams. Teams may decide to appoint a leader, though, for their own needs, either permanently or when needed, but it is not a formal position of power. It is a participative democracy through and through.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

The company's strategy is unclear

Context: "What we've got here is failure to communicate." A common quote used to describe a lack of understanding of and commitment to the company's strategy. Top management is frustrated by the lack of alignment, projects and departments not seeing the bigger picture clearly drawn up in the strategy document. At the same time, the people at the coalface constantly report back that they miss a clear and concise direction to follow when making decisions. All attempts to hold town hall meetings, clearly visible pages on their intranet, middle management sharing it frequently in their weekly status meetings, and even motivational phrases posted on the office walls seem to help.

OST explains: There are many explanations for this dynamic, like a strategy not really being a strategy but rather a lofty goal that provides no clear guidance, or poor communication lines between the top and the bottom. Let's focus on something often missed instead. A strategy must make operational sense to people; it should give them a clear, relevant purpose for their work, feel relevant and relatable in a way that inspires and motivates. Cool and fancy wording is not the point, not even how and how often it is communicated, but how engaging it is. The best way is for people to take part in its creation, but that is not feasible in large organisations, so at least it must have agents in all parts of the organisation who do, someone the people trust and can relate to. This is what middle management ought to be doing: making the company strategy relevant and actionable for people.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Workshops not working

Context: You have probably seen and even experienced being invited to workshops that you may or may not have that much interest in, but still obligated to join, and although it was carefully planned and executed by the facilitator, it still felt forced, unengaging and maybe even like a waste of time. This is an unfortunate situation as workshops are really the place where important and constructive work ought to happen, where people really feel energised and collaborate at the top of their game. Is it the participants that's the issue, or could it be something else?

OST explains: It is rarely the participants who cause this issue, even when workforce engagement has reached rock bottom. Systemic problems like this have different causes, ranging from the larger structural issues of autocratic hierarchies that inhibit collaboration and put people up against each other to simply bad facilitation. Let's focus on the latter now, as that is an easier adjustment to make. Make sure the facilitators are only in charge of managing the process; they should not own the decision to run the workshop, the technique or process to use, or be involved in the content. The reason for this is that the point of a workshop is for people to own the content and the output, and any attempt to lead will result in Bion's basic assumptions: dependency on the facilitator, just doing what they're told; fight/flight, opposing the whole thing or just not participating; or creating factions that do their own thing instead. Suspect many have experienced these, and they can only be avoided by removing the leader and letting the facilitator serve the group, not the other way around. DP2 instead of DP1.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Communication problems

Context: A common trope in larger organisations is that the root cause of so many problems and dysfunctions is bad communication. That people are not talking to each other and conveying information properly and promptly. Things are taking too long because of all the people that have to be involved and such. People are therefore often seen as the cause of this problem, and a common way of attempting to deal with these problems involves giving people additional communication skills. Something that fuels a huge training industry. Another is to simply limit the communication needed, for example, by setting a cap on team size (often citing Metcalfe's law) or by putting up human adapters/bottlenecks as the team leads mentioned in another post.

OST explains: OST states that these types of communication problems are endemic in DP1 structures and that it has nothing to do with people's ability to communicate. It is not even the primary human property, so why try to fix that first? Many situations can be observed where communication channels exist but are not used at all. What is a determining factor is the organisational structure, having one that is motivated to use the skills and where the number of channels is as few as possible. In DP1, each person is connected with the policy makers through intermediaries, in a non-reciprocal manner, while in DP2, this is reduced to real reciprocal connections between teams that do productive work. Not only is the number of connections fewer, but so is the quality of communication, as all relations are negotiations between peers, far from the asymmetrical relations between the superior and subordinate found in DP1. Think async vs. sync communication; the former is chatty, the latter is not. Also, Metcalfe's does not fit, as people communicate well and efficiently with peers who share the same goals and purpose as themselves.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

HiPPOs and dungeon masters

Context: In bureaucratic organisations, the formal ranking of people is usually well known and clear, where people higher up in the hierarchy have certain mandates over people they manage and/or that reports to them. Anything else would be chaos in that world. Still, there is also a lot of informal power, ranging from age difference and gender to more subtle things like years of experience and size of salary, regardless of formal power. This is problematic when decisions are to be made, as these informal power structures end up trumping data and expertise.

OST Explains: Facilitators especially try to counter these tendencies in workshops, for example, by using different types of techniques. A common one is sometimes called Silent Writing, where people are asked to work on the problem alone first, at the start of the workshop, so that all voices are heard. Sometimes this is taken a step further, as in 11-2-4-all, where the next step is joining a colleague to draw up a joint design, before joining up with another pair to create one they all agree on, and so on, before all get together and decide. This works well to get input from everyone, but does not silence the one with rank, as they will dominate regardless. And potentially lead to failure. In the techniques developed in OST, the focus is instead to create a community from the start of the session, instead of fortifying the differences, as these techniques do focus on the individuals. The Search Conference does this by focusing first on the shared goals and wishes for the future, showing that they all agree on more than they disagree on. And, if they do agree on something, put that to the side immediately and focus on what joins them instead of what separates them. The assumption is that we share the we all share the values that lead to the desirable future.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Local optimisations

Context: Any work group of people want to improve their way of working if they could, removing unnecessary work, resources or waste, as Lean calls it. Agile gave the teams that ability, at least to a large extent. Some may only be able to adjust technical issues, while others may even be empowered to decide how they want to do work. For example, one team decides they want to move to an event-driven architecture, while another wants to replace Scrum with Kanban. All great local optimisations that they should be able to do, but often are prevented from doing so, as they need to interact with other teams and are not able to get them to adjust. Or management may not let them because of the impact it has. Again, teams are stuck.

OST explains: This issue is not directly related to OST necessarily, but more to the parts-to-whole relation that comes out of systems thinking, which OST clearly is. Local optimisations in a part are perfect if it does not affect anyone else, which is rarely the case as parts are interconnected with other parts, often even through the shared relation they have to the whole. In a purposeful social system, even more so, as not only must the changes physically fit, but they must also align with the shared purpose of the system as a whole. Most organisations deal with this paradox, the interest of the parts vs. the whole, by designing top down, creating guardrails for the parts to operate within, giving them limited freedom. OST, on the other hand, replaces this centralisation of command and control by distributing it to the parts, where they can design their own work as long as they make sure it aligns with the goals of the system as a whole, like business goals and strategic plans, and, just as importantly, coordinate with all the affected parties. This enables local optimisations for the benefit of the whole.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

The frozen middle

Context: Assuming you are a team member in an organisation that has gone through an agile transformation. Your team have been given more autonomy and is expected to self-organise, make decisions, and deliver value faster. Yet somehow, almost everything still takes forever. Decisions get stuck, information does not flow, and initiatives die quietly without explanation. The teams are doing their part, but something above them seems to absorb all energy and momentum like a sponge. Middle managers are busy, always in meetings, always promising to follow up. But nothing moves. A frequent excuse is Things Take Time.

OST explains: This is one of the most predictable side effects of a partial DP2 transition to self-managing teams. When teams are given more autonomy while the surrounding DP1 structure remains intact, middle management gets caught in the middle. They lose their traditional role of passing work down and status reports up, but gain no new meaningful function. The result is a layer of people who are neither coordinating in the old DP1 way nor participating as peers in a DP2 fashion. They become a dampening layer, unconsciously protecting the existing power structure while appearing to support the change. This is not a people problem; it is a structural one. In a full DP2 organisation, the coordination is managed by the self-managing teams themselves, coordination work between peers, and not through proxies. The frozen middle is not resistant to change; it is simply a DP1 organ that has lost its purpose but not yet been replaced by anything coherent. Until the whole system transitions, it will continue to insulate the top from the bottom and slow everything down. The bottleneck has shifted.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

The decision that went nowhere

Context: The team has authority to make decisions about their own work. Everyone says so. But a question comes up: whether to move to a different data storage platform, adopt a new ticketing tool, or change how a shared service is handled across three teams. Someone suggests checking with the other teams first. Someone wonders if there is an architectural standard that covers this. A Slack message goes out. Two weeks pass. The thread goes quiet. The improvement is shelved. The team continues with the arrangement everyone agreed was suboptimal. Nobody decided not to change it. Nobody decided to change it either.

OST explains: Laissez-faire produces this pattern reliably. The teams have been told they are empowered, but the structural conditions that would allow them to act on that empowerment are absent or unclear. In a genuine DP2 setup, coordination between teams happens through direct peer relationships, each group owning its whole task and negotiating at the boundary with explicit scope. In laissez-faire, autonomy is asserted at the team level but the boundaries are fuzzy: nobody is certain where their authority ends and someone else's begins, and the organisation has no mechanism for resolving this short of escalating upward. The team defaults to inaction, not from lack of initiative but from a rational reading of their situation. Acting might be wrong. Doing nothing is safe. The cost of acting is immediate and personal. The cost of the delay is diffuse and belongs to nobody. In DP1, at least the approval chain is legible: you know who to ask. In laissez-faire, there is no legible chain, which means the decision cannot travel anywhere. It just stops. In DP2, it would not need to. The group owns its whole task including its boundaries, and cross-team decisions are negotiated laterally between groups that each have genuine accountability for their own domain. The mechanism is not hierarchy. It is peer negotiation between groups that know where they stand. The problem here is not that the team lacks initiative. It is that nobody built the structure that would let initiative go anywhere.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Psychological safety as a patch

Context: Your organisation may have realised that psychological safety is of the essence for good collaboration. Maybe it came out of a retrospective, maybe someone read the Google re:Work study and Amy Edmondson contributions, or maybe it was a leadership initiative after too many people stopped speaking up in meetings. Either way, there are now workshops on it, a section in the onboarding, maybe even a survey to measure it. Leaders are coached to create it. Teams are encouraged to demand it. And yet, somehow, people are still not speaking up, still not taking risks, still not challenging the decisions made above them. The patch does not seem to be holding.

OST explains: Psychological safety is real, and it matters a lot, but what is often missed is that it is an emergent property of the structure people work in, not something you can install. In a DP1 organisation, people are inherently in a dependent, subordinate position, and the rational response to that is to be careful about what you say and to whom. That is not a personal failing; it is Bion's basic assumptions playing out exactly as expected: dependency, fight/flight, and factionalism are the natural human response to autocratic hierarchies. You cannot train people out of that while the structure that causes it remains intact. In a DP2 structure, on the other hand, psychological safety is not a programme or a value on the wall; it is simply what happens when people are peers designing and owning their own work. They speak up because it is their job to, and because there is no hierarchy of dominance to be careful around. Demanding psychological safety in a DP1 organisation is a bit like applying a patch to a system with a structural bug. It might cover the symptom for a while, but the underlying code has not changed.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Forming–storming–norming–performing

Context: When putting together a new team or making big changes to an existing one, many recommend using Tuckman's "forming–storming–norming–performing" model to turn the team into a coherent and well-oiled unit. It begins with Forming (orientation), moves to Storming (conflict), progresses to Norming (cohesion), and ends with Performing (high productivity). Leaders are advised to manage this process closely as progress is not linear; teams may slip back to previous stages if new members join or goals shift. And conflict is regarded as necessary, as the "Storming" phase is essential to growth.

OST explains: Tuckman's model only makes sense in an autocratic bureaucracy, especially those of the Theory X type, and aligns with Taylor's view that people must be managed to perform properly. This is classic DP1 thinking, whereas in the DP2 style, McGregor's Theory Y is the model, which assumes employees are self-motivated, enjoy work, and thrive under trust, empowerment, and autonomy. Grouped into self-managing groups that have designed themselves using Participative Design. No need for either storming or norming; the teams jump right to performing after forming.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Analysis paralysis

Context: An agile team is working on a rewrite of an existing legacy solution and feels that its success depends on the function parity it must have with the old one. They therefore end up doing a detailed and extensive analysis to account for as much as possible, even tracking down former developers to get details on some of the more obscure parts. And, even more problematic, they have to figure out which business people own which parts and who all their users are. This drags out in time, and although they have started the work, the extensible analysis prevents them from releasing anything. They are stuck.

OST explains: Agile as a concept is pretty much designed to handle these kinds of situations; at least that is what many may think. It focuses on small increments and puts things in front of the users as soon as possible to tighten the feedback loop, so it makes sense. The thing, though, is that this is not product discovery, as it is an existing product with external product owners and users, both internal and external, and the team has no real product ownership of the app apart from the technical bits. They are not a self-managing product team as a DP2 style should be. Only when they have end-to-end ownership of the whole product, not just a part, can they take full responsibility and accountability so that they can manage it as they please.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Individualism

Context: Often, there is a large disproportion in how much people are celebrated for their achievements and when blame is placed for accountability when something goes wrong. This feels natural in most parts of the world, as we want to take care of the people and make them feel as good as possible so that they'll feel well and stick around. Being human, as we say. Even toward the people who clearly take on the accountability, and are even paid good money to do so, often leading to few or no consequences. We value the individual when celebrations are due, when heroes are praised, but hide them when there is not. Typically, hero cultures are also a power play, as the ones praised become stretch goals for the rest, showing what lengths they have to go to feel respected and truly valued.

OST explains: This focus on the individual is almost anathema in OST, not because the individual is not valued, but it realises that the group is the basic unit of life, be it your family, your friends or your colleagues. It's founded on the belief that people have both the need for autonomy and homonomy; be able to self-govern and fit in with the group. Actually, valuing individuality as an acontextual thing hides a vital paradox, as it inevitably isolates people as the problem because there is nothing else to blame. It even goes beyond blaming the victim; it creates them. By instead focusing on the group, and having it take responsibility and accountability, it can take both the praise AND the blame. The individual is protected in the group, and it can jointly grow and learn from successes and failures. As it takes them to their shared goals.

 #OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Quiet quitting

Context: Your colleague is still showing up. Still completing tasks, attending meetings, and delivering what is asked. But something has changed. The initiative is gone. The extra effort, the ideas in retrospectives, the willingness to stay late when something mattered. All quietly withdrawn. They are not disruptive. They are not absent. They are just no longer there in the way they used to be. You have seen it in others. You have felt it yourself on certain Monday mornings. The organisation calls it a motivation problem. The Gallup numbers confirm it is everywhere: only around 20% of employees are engaged at work globally.

OST explains: Quiet quitting is neither a generational attitude nor a post-pandemic trend; it is what happens when the six psychological requirements for productive work are chronically unmet. When people have no real control over their work, no meaningful feedback, no variety, no genuine connection to purpose, and no path forward that feels worth taking, withdrawal is the rational response. It is not laziness. It is self-protection. That withdrawal is recognisable as the flight side of Bion's fight/flight assumption: when people conclude they cannot change the situation, they step back, often without rancour. DP1 structures produce these conditions by design: goals come from above, tasks are fragmented, accountability is individual, and the system rewards compliance over contribution. The engagement industry responds with surveys, recognition programmes, and purpose workshops, treating the symptom while the structure remains intact. In DP2, engagement is not something you measure and manage; it emerges from people owning their own work. The quiet quitting is not the problem. It is the answer to the problem.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Роль Agile Coach мертва… да здравствует агент изменений

Здесь и далее: скрам-мастер и аджайл коуч тождественны. TL;DR Роль Agile Coach должна умереть, чтобы переродиться в роль Change Agent (или Organizational Architect). И работать такие спецы должны не "вечно", а проектно - как спецназ внедрения изменений. Самое главное - у роли должна наконец-то появляться ответственность. В посте разберем 4 утверждения: какой должна быть система работы, какие вопросы задать чтобы понять что импакт от коуча есть, почему важно делать нужные бизнесу изменения и то, что софт скилы - это новые харды. Разобраться, почему стоит писать некролог

https://habr.com/ru/articles/1075680/

#agile #scrum #kanban #разработка #ai #изменения #управление_изменениями #эффективность #производительность

Top Links
Repeating the Same AI Prompts? The Agent Skills Handbook Helps You Build Reusable Skills (Suchitha Ramesh)
Copilot Code Reviews for Azure Repos (public preview) (Dan Hellem)
Visual Studio Code 1.136 (Insiders) (Visual Studio Code Team)
.NET Rocks! - Arguing about AI wit…

Две двери, один выбор и несколько подсказок 👀

Мы готовим кое-что, чтобы путь в RetroPoint стал проще и удобнее. Ответ пока не раскрываем.

Какая у вас версия?

https://retropoint.ru

#RetroPoint #UX #ProductDesign #SaaS #TeamLead #TeamLeadTools #scrum #agile #kanban #ретроспектива #ретро

Top Links
Explore new features available in C# 15 preview (Bill Wagner)
.NET Conf 2026 (Jon Galloway)
Unlocking the Power of AI for Every Developer in Visual Studio with Bring your Own Model (Tanmayee Kamath)
From dotnet run to Foundry Hosted Agent in 3 lines of C# (Bruno Capuano…

Стену в ВК мы, конечно, вернуть не можем, но теперь вы можете повторить ее на ваших ретро! 🎨

Выберите цвет и толщину линии, сделайте набросок и сохраните его рядом с текстом. Перемещение и объединение карточек теперь настраиваются независимо.

AI ищет похожие текстовые идеи в выбранной колонке или по всей доске. Ведущий проверяет группы, исключает лишнее и только после этого подтверждает объединение. Самостоятельно AI доску не меняет.

https://retropoint.ru/news/card-drawing-and-ai-grouping

#RetroPoint #Agile #ретроспектива #TeamFacilitation

Organisational Dysfunction of the Day

When the glue leaves

Context: Every team has one. The person who remembers why the architecture is the way it is, who onboards new people without being asked, who spots the misunderstanding between two colleagues before it becomes a conflict, who writes the documentation nobody else gets around to. They are rarely the loudest voice in the room. Their work is invisible precisely because it works. Then they leave, or they are cut in a restructuring because their output is hard to measure. The team notices immediately. Things that used to happen automatically now fall through the gaps. A few months later, a manager is hired to fill the coordination hole. They come from outside, know how to run a team, but not the domain, not the technology, not the relationships. The team now has overhead where it used to have glue.

OST explains: Parkinson observed that in a bureaucratic structure, administrators multiply subordinates rather than rivals, not out of malice, but because DP1 has only one answer to a coordination problem: add a layer above it. When the informal coordinator disappears, the organisation's structural immune response is to hire a professional manager. It is the only move available. The result is a double loss. The team loses the person who held things together from within, and gains someone whose coordination mechanism is hierarchy rather than craft knowledge and trust. In a DP2 structure, those coordination functions belong to the group as a whole; they are distributed across the team by design, so no single person carries them alone and no single departure collapses them. In DP1, that distribution never happened. The coordination lived in one person because the structure had no other place for it. The replacement manager is DP1's only available response to a gap that DP1 itself created, not a solution to it. The organisation did not solve the coordination problem. It institutionalised it.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

***

The series has become a book, available now on Leanpub. Link in the comments.
http://www.organisationaldysfunctions.com

Tim Retout: TF RAID

My hobby: following GOV.UK to look for interesting announcements. Today was an update on the MOD’s Rapid AI Delivery Taskforce which was previously announced in June during London Tech Week.#defence #ai #agile
TF RAID