schmonz.com is a Fediverse instance that uses the ActivityPub protocol. In other words, users at this host can communicate with people that use software like Mastodon, Pleroma, Friendica, etc. all around the world.
This server runs the snac software and there is no automatic sign-up process.
Organisational Dysfunction of the Day
Built for yesterday
Context: The strategy keeps changing. The market shifted, then shifted again. A competitor emerged from an unexpected direction. AI is rewriting the economics of the industry faster than anyone predicted. The three-year plan written eighteen months ago is already obsolete. Leadership responds with more planning, tighter governance, and faster decision cycles at the top. The organisation is working harder than ever and adapting less than ever. People at the coalface can see what needs to change, but cannot get decisions made quickly enough. By the time something is approved, the situation has moved on. The organisation is not slow because people are lazy or misaligned. It is slow because it was designed for a world that no longer exists.
OST explains: Emery and Trist identified four types of organisational environment, which they called causal textures. The third, disturbed reactive, is the competitive industrial world that DP1, the bureaucratic structure, was designed for, with large, similar organisations whose moves continually disturb one another. The fourth, turbulent fields, is categorically different: the environment itself is in motion, driven by forces in the field itself, like technological disruption, social change, and ecological pressure. In turbulent fields, the variety generated by the environment exceeds the capacity of any hierarchy to process and respond to it. DP1 is actively maladaptive here, because concentrating perception and decision-making at the top creates exactly the bottleneck that makes the organisation slow when speed matters most. DP2, the self-managing-group structure, distributes that capacity across the whole organisation, with every group actively scanning its environment, adapting, and feeding learning back into the system. We have been in turbulent fields for decades. AI has just turned up the intensity several orders of magnitude. To 11.
Today I spend some time sharing leadership lessons.
https://www.edyouragilecoach.com/success-through-the-power-of-presence/
🏴☠️🐻
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.
Gefühlt wird die Ausbeute an interessanten Links immer geringer. Hängt das vielleicht mit der KI zusammen? Oder sind überoptimierte Algorithmen das Problem? Zumindest bei LinkedIn und anderen Netzwerken habe ich diesen Eindruck. Es gibt schöne Bildchen, viel Selbstbeweihräucherung und wenig Inhalt. Zum Glück setze ich auf RSS-Feeds für den Informationsüberblick und bin damit zumindest teilweise vor Algorithmen sicher, die Bullshit spucken. Leider nicht ganz vor KI-generiertem Bullshit, der deutlich zunimmt. Ich habe nichts gegen KI-Unterstützung, aber bitte nur als „Unterstützung”. Wenn alles nur noch von anderen abgeschrieben wird, ohne eine eigene Denkleistung einzubringen, dann wird es schnell langweilig. Ein kleines Beispiel: Kürzlich hat es sogar eine vermeintliche Band geschafft, mich kurz auszutricksen. Dieses eine Lied war richtig gut. Ich habe mir weitere Titel angehört, die erstaunlich ähnlich aufgebaut waren. Etwas zu glatt. Zu viel des Guten. Eine kurze Google-Suche hat ergeben, dass die Lieder komplett KI-generiert sind. Zu langweilig. Kein Pfiff. Das ist die schöne neue Welt.
Denjenigen, die sich bereits mit Prokastination beschäftigt haben, bringt der Blogartikel von André Bosse vermutlich keine neuen Erkenntnisse. Die Zusammenfassung finde ich dennoch brauchbar. Viele der Punkte findet man übrigens auch im Podcast von Ivan Blatter, der auch immer wieder in den „Links der Woche” erwähnt wird. Abgesehen davon ist das Aufschieben vermutlich normal. Bis zu einem gewissen Grad ist es sicherlich auch hinnehmbar. Ich lasse zum Beispiel gerne auch mal bewusst Aufgaben liegen, um Gedanken reifen zu lassen oder zu überprüfen, ob sie wirklich wichtig sind. Das fällt nicht unter Prokastinieren, weil es eben bewusst geschieht.
Lässt sich jeder Workflow mittels KI optimieren? Diese Frage habe ich diese Woche in die Runde geworfen und dabei angemerkt, dass auch eine KI nur so gut sein kann, wie die Daten, mit denen sie gefüttert wird. Wer also keine gute Struktur hat, kann auch von einer KI keine Wunder erwarten. Abgesehen davon waren und sind hochstandardisierbare Workflows auch ohne KI automatisierbar. Dumm nur, dass vieles gar nicht so hochstandardisierbar ist. Das ist ein Grund, weshalb ich die Erwartungen an KI für überzogen halte, ebenso wie die Erwartungen an Automatisierung generell. Die Maschine wird manches ermöglichen, aber eben keine Wunder wirken, da bin ich sicherlich mit Jan Fisbach einer Meinung.
https://www.teamworkblog.de/2026/04/workflow-und-ki-andert-sich-etwas.html
Beim Stöbern im Leadershipfreak-Blog von Dan Rockwell bin ich wieder einmal über Ideen gestolpert, die mir seltsam bekannt vorkamen. Das dürfte nicht wundern, denn er verweist tatsächlich auf die Stoiker der Antike. Auch nach so langer Zeit sind sie in vielen Dingen noch immer gut für Ratschläge. Das muss man ihnen einfach neidlos zugestehen. Zu den vielen Ratschlägen der Stoa gehört beispielsweise, nicht der „Schmeichelei” zum Opfer zu fallen. Wie immer sehr lesenswert.
https://leadershipfreak.blog/2026/05/01/escape-the-flattery-trap/
Zum Thema Produktivität gehört für mich die Auszeit im Grünen, zum Beispiel Wandern oder Radtouren. Leider kommt das bei mir etwas zu kurz, da es den Kindern oft zu langweilig ist. Da ich gerne meinen Weg finde, beschäftige ich mich natürlich auch mit geeigneten Hilfsmitteln wie Apps. Google Maps ist dafür nicht wirklich ideal. Die bekannten Apps tun sich nicht gerade durch Datenschutz hervor, wie immer wieder durchsickert. Netzpolitik hat einige Alternativen vorgestellt. OrganicMaps habe ich übrigens schon eine Weile ausprobiert und ganz passable Erfahrungen damit gemacht. Auch als Alternative zu Google Maps für die Navigation im Auto ist es gut geeignet.
https://netzpolitik.org/2026/wandern-radfahren-frei-und-dezentral-ins-gruene/
Das Thema von Lars Richter passt tatsächlich als Querschnittsthema in fast alle Bereiche der „Links der Woche”. Ich ordne es daher hier bei Produktivität ein. Denn es geht um Kreativität. Und kreative Prozesse gelingen meiner Beobachtung nach am besten im Austausch mit anderen Mitmenschen. Da kommt auch keine KI wirklich mit. Auch wenn sie als Unterstützungshilfe Impulse liefern kann. Echte Kreativität entsteht dabei jedoch nicht. Sie ist am Ende aber nicht in der Lage, selbstständig zu denken. Übrigens habe ich auch beobachtet, dass man viele Ideen entwickeln und verwerfen muss, ehe aus diesem Prozess die zündende Idee entsteht. Auch das funktioniert wieder nur im Zusammenspiel mit anderen. Ganz im Sinne von Lars Richter: Kreativität gibt es nur im Plural.
https://scamper.blog/kreativitaet-gibts-nur-im-plural/
Der Job eines Scrum Masters ist anspruchsvoll. Sehr sogar. Vorausgesetzt, man versteht, worum es geht. Sicherlich fällt kein Meister vom Himmel. Gute Scrum Master*innen entwickeln sich daher auch beständig weiter. Die weniger guten bleiben in ihrer Entwicklung hängen. Doch wie erkennt man seine Entwicklungsmöglichkeiten? Eine Möglichkeit ist, sich anzuschauen, was man auf keinen Fall tun sollte. Simon Flossmann zeigt hier fünf Wege, wie man es garantiert an die Wand fährt. Es geht um etwas mehr als nur den Scrum-Leitfaden und seine Regeln, sondern auch um ein tiefergehendes Verständnis des Wesens und der Organisation an sich. Nur um einige Punkte zu nennen.
https://www.scrum.org/resources/blog/5-todsichere-wege-als-scrum-master-miserabel-zu-sei
Scrum Master*innen, die ihr Handwerk verstehen, wissen um die Bedeutung der Produktentwicklung für das Gelingen eines Scrum-Teams. Zur Erinnerung: Scrum ist ein Framework für die Produktentwicklung, also das explorative Erkunden. Neben dem Team gehören auch die Product Owner zu den wichtigen Protagonisten. Auch sie benötigen gelegentlich Unterstützung, um den Rahmen abzustecken und dem Team die notwendige Orientierung zu geben. Ein gutes Zusammenspiel zwischen Product Owner und Scrum Master ist daher unerlässlich. Dies wiederum setzt voraus, dass Scrum Master:innen ein gutes Verständnis von Produktentwicklung haben. Genau darum geht es im Podcast der Produktwerker mit Jan Neudecker.
https://produktwerker.de/was-sollten-scrum-master-ueber-agiles-produktmanagement-wissen/
Ich denke, den Fehler, den Marc Löffler in seinem Podcast anspricht, haben wir alle in der Vergangenheit schon mehr oder weniger gemacht und schmerzhaft gelernt. Bei Veränderungen geht es nicht darum, ein Werkzeug zu implementieren, sondern Ergebnisse zu erzielen. Ergebnisse, die für die Beteiligten greifbar und erlebbar sind und einen Nutzen haben. Nach all den Jahren, in denen ich mich mit Agilität beschäftigt habe, kann ich seine Rückschlüsse auf jeden Fall bestätigen. Agilität ist kein Selbstzweck. Sie ist ein Hilfsmittel, mit dem wir etwas erreichen wollen. Zum Besseren. Damit begeistert man seine Mitmenschen. Übrigens habe ich gelernt, Widerstände als wertvolle Impulsgeber und Indikatoren für Verbesserungspotenziale zu schätzen.
https://marcloeffler.eu/2026/04/28/warum-dein-team-jede-veraenderung-mitmacht-wenn-der-preis-stimmt/
Heute möchte ich etwas „Eigenwerbung” für einen Blogartikel machen, den ich für das Forum Agile Verwaltung geschrieben habe. Es geht um Obeya – oder besser: Was es braucht, um Obeya zu starten. Und hier bin ich, wie bei fast allen Dingen, der festen Überzeugung, dass das „Wozu” der zentrale Kompass und die Gelingensvoraussetzung für einen guten Start ist. Wozu wollen wir etwas tun? Falls sich jemand mehr für das visuelle Management mit Obeya interessiert, stehe ich gerne Rede und Antwort. Wissen vermehrt sich, indem man es teilt.
https://agile-verwaltung.org/2026/04/30/mit-obeya-starten-das-weshalb-als-schluesselfrage/
Joost Minnaar von Corporate Rebels bringt es mit der dramatischen Geschichte des Untergangs der Titanic auf den Punkt: Die Katastrophe hätte verhindert werden können, wenn die organisatorischen Silos an Bord des Schiffs nicht verhindert hätten, dass die Warnungen vor Eisbergen die nötige Dringlichkeit erhielten. Nicht, weil inkompetente Mitarbeitende Mist gebaut haben, sondern weil strukturelle Probleme in Form von lokal optimierten organisatorischen Silos ihren Job ziemlich gut gemacht haben. Aber eben nicht aus einer ganzheitlichen Perspektive. Genau dieses Problem nehme ich in vielen Organisationen wahr. Lokal optimierte Silos, die das große Ganze allerdings gefährden. Die Lösung? Autonome Teams in dezentralen Strukturen, die eigenständig – innerhalb einer gemeinsamen Zielrichtung – reagieren können, sowie kurze Rückkoppelungswege.
https://www.corporate-rebels.com/blog/organizational-silos
In diesem Zusammenhang ist auch die Idee der freien „Vorgesetztenwahl” interessant. Sicherlich ist dies nicht in jedem Kontext und uneingeschränkt möglich, aber seien wir mal ganz ehrlich: Wenn das Vertrauensverhältnis zerrüttet ist, sollte ein Wechsel des „Chefs” möglich sein. Denn nicht immer liegt es an den Mitarbeitenden, wenn es nicht funktioniert. Das ist ein Gedanke, dem ich Felix Stein daher beipflichte und den ich spannend finde. Eine Führungskraft, mit der ich vor ein paar Jahren zusammengearbeitet habe, sagte einmal, dass Menschen Menschen folgen. Dabei schwang eine gewisse Bewunderung mit, wie gut es einem bestimmten Teamleiter gelang, Mitarbeiter nicht nur zu gewinnen, sondern auch deutlich länger zu halten, als es anderen Teamleitern gelang. Ich bin mir sicher, dass manche auch gerne zu diesem Teamleiter gewechselt wären, wenn man ihnen die Wahl gelassen hätte. Nicht, weil er besonders großzügig gewesen wäre, sondern weil er durchaus kritische Dinge auf positiv-menschliche Weise vermitteln konnte und es ihm gelang, Menschen auf authentisch-ehrliche Weise anzusprechen. Das war eine große Stärke.
https://www.lean-agility.de/2026/04/freie-vorgesetzten-wahl.html
KI ist derzeit in aller Munde. Ich bin der Überzeugung, dass die Erwartungen an KI viel zu hoch sind. Dennoch ist sie gekommen, um zu bleiben. Das setzt auch den Aufbau von KI-Kompetenz in Organisationen voraus. Ebenso wie jede andere digitale Kompetenz (in diesem Bereich wurde bereits genug geschlampt). Mit Nadine Pedro bin ich einer Meinung: KI-Kompetenz sollte gezielt entwickelt werden. Und nein, das ist nicht allein Sache der Mitarbeitenden, sondern auch des Unternehmens. Wer aus falsch verstandenem Kostendruck seine Mitarbeitenden nicht bei der Kompetenzentwicklung unterstützt, hat nicht verstanden, wer in Organisationen die Wertschöpfung erzeugt, die die Organisation am Leben erhält.
https://t2informatik.de/blog/foerderung-ki-kompetenzen-unternehmen/
#Agile #KI #Kompetenzaufbau #Kreativität #Leadership #Management #Obeya #Produktivität #Prokastination #Radfahren #Schmeichelei #Scrum #ScrumMaster #Silos #Tools #Tooltipp #Veränderungen #Wandern #Workflow@SabineTerwelp
oh, so cool. warm welcome to our beautiful #fediverse
Just because systems get faster does not mean they get more productive.
I blogged about that:
https://no-bullshit-agile.com/just-because-systems-get-faster-doesnt-mean-they-get-more-productive.html
Happy to read your opinion!
Nur weil Systeme schneller werden, werden sie nicht produktiver.
Ich habe ein wenig geblogged und freue mich auf eure Meinung:
https://no-bullshit-agile.de/nur-weil-systeme-schneller-werden-werden-sie-nicht-produktiver.html
Dew Drop Weekly Newsletter 481 - Week Ending May 1, 2026
#dewdrop #newsletter #aspnetcore #css #azure #javascript #xaml #cpp #windowsdev #dotnet #csharp #mcp #ai #agile #devops #gamedev #appdev #dotnetmaui #podcasts #m365 #data #sqlserver #powershell #devtools
Since many of you are enjoying a day off, I’m hitting 'pause' on my Dysfunctions series. Instead, I want to address a common objection to OST: the idea that while these principles work in manufacturing, IT is 'too unique' for them to apply.
Here is my take (and the #OST perspective):
The design principles are about where responsibility for coordination and control sits. They are content-agnostic. They apply equally to stitching shoes, nursing, and writing software, because they describe the structural relationship between people and their work, not the work itself.
Knowledge work actually requires DP2 more than routine work does. The whole argument for self-management is variety: when work demands judgment, context, and adaptation, you cannot pre-specify it from above. DP1 is a worse fit for knowledge work than for assembly lines, not a better one.
Big software companies are full of DP1 patterns dressed in agile clothing: product managers who own the goals, engineering managers who own the headcount, architects who own the tech, PMOs who own the process. The product manager role itself is often a DP1 supervisor function relabeled.
My International Workers' Day speech.
Top Links Windows App SDK 2.0 (2.0.1) Released 🎉 (agniuks) .NET Rocks! Episode 2000! (Carl Franklin & Richard Campbell) VSTest is Removing its Newtonsoft.Json Dependency (McKenna Barlow) What Actually Happens When You Port a WPF App to a Modern .NET UI using Agents (Matt Mattei) Kayla + Maddy LIVE – Plants, Trains, and Aspire (Kayla … Continue reading Dew Drop – April 30, 2026 (#4658)
🖥 Как провести онлайн-ретроспективу и не потерять команду в видеозвонке
Ретро на удалёнке — другая встреча. Мимика в плитке 5×5 см считывается хуже, половина камер выключена, а молчание в экран давит сильнее, чем в переговорке.
Написали пошаговый гайд на 60 минут:
🔧 Как подготовить инфраструктуру — доска, видеосвязь, таймер
✍️ Что делать на каждом этапе — от сбора стикеров до голосования
🎯 Как закрыть встречу действиями, которые команда реально выполнит
⏱ Почему тайм-бокс спасает от «ну, у кого ещё что-нибудь?»
Внутри — конкретные приёмы: почему все пишут одновременно, а не по очереди, зачем звать по имени и как не дать ретро превратиться в монолог фасилитатора.
Подходит scrum-мастерам, тимлидам и всем, кто ведёт ретро на удалёнке 👇
https://retropoint.ru/news/online-retrospective-guide
#retrospective #ретроспектива #agile #scrum #kanban #teamlead #it #itleads #teamleasthings #команда #RetroPoint #retroonline #просторетро
Organisational Dysfunction of the Day
OKRs imposed from above
Context: Many organisations have adopted OKRs, but a common way of doing them is like a cascade: company OKRs are set by leadership, then broken down into department OKRs, then into team OKRs. Everyone has objectives and key results. The teams go through the quarterly ritual of setting them, reviewing them, and scoring themselves at the end. Some teams engage genuinely, while others may treat it as a compliance exercise. A common complaint is that the team-level OKRs are effectively dictated by the level above, with little to no room to define what matters to them. The framework says teams should own their goals, but the structure says otherwise.
OST explains: OKRs are a good idea applied in the wrong structure. In DP2, goal-setting is one of the core functions of the self-managing group; it is not something done to them. When goals are cascaded down from above, even with good intentions, the team is not really setting its own objectives; it is translating management's objectives into local language. That is a DP1 (bureaucratic) function dressed in DP2 clothing. The quarterly scoring ritual then becomes a performance review proxy, which is about the last thing a self-managing team needs. In a genuine DP2 structure, the team's goals emerge from its understanding of its own work, its environment, and the shared organisational purpose it has participated in defining. That is a fundamentally different starting point, and it produces fundamentally different commitment.
Top Links Visual Studio April Update – Cloud Agent Integration (Mark Downie) A2A v1 Is Here: Cross-Platform Agent Communication in Microsoft Agent Framework for .NET (Sergey Menshykh) PowerToys 0.99 is here: new monitor controls, easier window management, and Dock upgrades (Niels Laute) Continuing the story of early DOS development (Stacey Haffner & Scott Hanselman) Uno … Continue reading Dew Drop – April 29, 2026 (#4657)