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
Nobody wants to own this
Context: There is a service that seven teams depend on. It was built three years ago by a team that no longer exists. The code lives in a repository that has eleven different people listed as contributors. When it breaks, everyone notices. When it needs updating, everyone waits. Slack messages go out asking who owns it. The answers are variations of "we use it, but we didn't build it" and "I think that was the old platform team." Someone eventually fixes the immediate problem. Nobody fixes the underlying one. The service is not on anyone's roadmap or in anyone's OKRs. It is not neglected because nobody cares. It is neglected because the structure has no place to put it.
OST explains: DP1 organises work by splitting it into owned pieces, services to teams, components to people, functions to departments. The logic works for things that fit neatly into boxes. It breaks down entirely for things that are shared, the platform everyone uses, the legacy system too expensive to replace, the cross-cutting concern that belongs to the whole organisation rather than any part of it. These things fall into the gaps between the boxes and stay there. Nobody is incentivised to invest in something that appears on nobody's performance review. In a DP2 structure, where a team owns its whole task end-to-end, the boundary location principle requires that the team controls everything it depends on to do its work. Shared dependencies are a structural signal that the boundaries are wrong, that the work has been sliced in a way that leaves essential things ownerless. The abandoned service is not a prioritisation failure. It is a design failure. The organisation drew the lines in the wrong places and then wondered why nothing fills the gaps.
#OpenSystemsTheory #SocioTechnical #OrgDesign #agile
***
The series has become a book, available now on Leanpub.
https://www.organisationaldysfunctions.com
Top Links
Aspire 13.5.4 (Aspire Team)
Performance Improvements in .NET 11 (Stephen Toub)
Intelligent Terminal 0.2.2572: Faster, Smoother, and More Reliable (Hamza Usmani)
Share your .NET story with the community (Luis Quintanilla)
Rider and ReSharper 2026.2.2 Are Out! (Alexander …
During British rule of India, a bounty was offered for every cobra killed, to reduce the population. It backfired: people started breeding and killing cobras for income. In 2002, British officials in Afghanistan paid farmers $700 per acre to destroy opium crops. The result: farmers planted opium so they'd have something to burn.
"What is measured is managed" is a famous quote I can't find clear attribution for (often mis-attributed to Peter Drucker). The damage this mindset has done over the past century is amazing.
I've seen salespeople with regional bonuses fight over who gets credit for a large sale, undermining each other instead of building client relationships. In one organization, we had an annual award for whoever was best at solving difficult customer problems. Those same people were so busy solving problems that they were also creating the quality problems that became next year's fires.
The more metrics you have in place, the more likely they are to come into conflict. Quarterly sales bonuses often lead to discounts, because locking in a sale for the bonus is worth a 20% cut, even if it hurts overall profit. They also pressure product teams to push work out the door by quarter-end, and quality always suffers.
Two questions before you add another metric:
- Can we eliminate one first?
- What are the second-order effects? (Systems Thinking)
We'll never predict all the ways a measurement changes the system it measures. Only measure what matters.
I've long said, and research supports it: a fragile organization that goes faster will be knocked over by the slightest wind.
Most of the oxygen in the online conversation right now is being swallowed by AI hype. AI is a valuable tool, but when misapplied it makes organizations more fragile, not more resilient. The current fascination with using AI to produce code faster concerns me when it becomes a general crutch rather than a tool used in specific, select ways.
Attempts to speed up a system without first ensuring quality, alignment on strategy, and focus on the actual bottleneck just pile up more of the wrong thing, probably full of defects.
What makes organizations fragile:
- Focusing on speed over quality
- Adopting new technology without understanding its impact throughout the system
- Heavyweight change management process
- Involving every stakeholder in every decision
- Standardization overkill
- Centralization of decision making
Resilience isn't an afterthought. It isn't a fixed characteristic, it's something we constantly work on.
Not anti-AI. We study the failure modes so we can avoid the traps. Without that, we're flying blind.
Where have you seen things that make your organization more fragile?
RE: https://hachyderm.io/@pmbauer/117260981856027009
Solve the problems of the users!
Do not get in love with the complexity of the solving technique!
This title should be written in bold letters:
AI Can Write Backlog Items. It Can’t Create Shared Understanding
Have you ever heard of the "Fundamentals First Repair System"?
I read the blog post https://www.scrum.org/resources/blog/real-meeting-happens-hallway
and found
https://www.fundamentalsfirst.eu/
#FundamentalsFirstRepairSystem #Agile #Meetings #AgileCoach #ScrumDotOrg
Mastodon
🗂 В RetroPoint появилась группировка карточек ретроспективы по темам.
Похожие наблюдения получают общее название, а карточки сохраняют авторов, комментарии и вложения. Темы можно сворачивать, переносить между колонками и выбирать голосованием.
Ручная группировка доступна на бесплатном тарифе «Ретро». AI может предложить названия и состав групп в пределах вашей квоты, с проверкой перед применением.
Посмотрите пример со скриншотами:
https://retropoint.ru/news/topic-card-groups?utm_source=mastodon&utm_medium=organic_social&utm_campaign=2026_09_topic_card_groups&utm_content=topic_card_groups_post
#RetroPoint #ретроспектива #Retrospective #Agile #TeamLead #TeamLeadTools #retrospective #itmanager
Organisational Dysfunction of the Day
The talent myth
Context: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." This principle from the Agile Manifesto is one of the most quoted and most acted upon in the industry. Hiring processes are designed around finding motivated people. Managers are coached to give them space and trust. Perks, autonomy, and purpose are offered as the environment and support needed. And yet engagement surveys keep returning the same dispiriting numbers. The motivated individuals either leave, quietly stop being motivated, or were never quite as motivated as the interview suggested. The organisation concludes it needs to find better people, or do a better job of retaining the ones it has.
OST explains: The manifesto gets the outcome right but the mechanism backwards. Motivation in OST is an emergent property of the structure people work in, not a precondition you select for in hiring. It emerges when six structural conditions are met: elbow room to make your own decisions, continual learning through room to set your own goals and get accurate, timely feedback, enough variety in the work, mutual support and respect from colleagues, meaningfulness through work that is socially valued and lets you see the whole product or service, and a sense of a desirable future rather than a dead end. These are properties of the work, not personal traits. You cannot find motivated individuals and protect their motivation; you design a structure that produces motivation as a natural output for whoever works within it. OST flips the manifesto's framing. The group is the basic unit, the design principle is the primary determinant, and motivation is what happens when the structure is right. The manifesto points in the right direction but stops one step short of the structural answer.
#OpenSystemsTheory #SocioTechnical #OrgDesign #agile
***
The series has become a book, available now on Leanpub.
http://organisationaldysfunctions.com
PDCA-Kreis.
Work-Feedback-Loop.
Kundenfokus/-feedback.
Wie auch immer man es nennen mag.
Hier eine schöne Agile Success Story von @FelixStein
https://www.lean-agility.de/2026/09/agile-success-stories-scrum-im-kundenservice.html
Holy Moly.... wie die Zeit verrennt.
Vor mehr als 2(!) Jahren war ich Gast bei @nobsagile im Podcast:
https://no-bullshit-agile.de/nba25-im-gespraech-marco-von-scrumschau-ueber-scrum.html
Habr » 🤖 🌐
@habr@zhub.link
Почему продукт и разработка не могут работать отдельно друг от друга
Кажется, что при создании сложных инженерных систем разработка создает технологию, а продукт упаковывает ее для заказчика. У каждой команды своя зона ответственности. На самом деле всё не так просто. Мы в «Фалькон Тех » уже 9 лет разрабатываем цифровые решения для умного города на основе видеоаналитики и машинного зрения. В статье рассказываем, почему продукт и разработка должны работать в связке, а не передавать друг другу задачи по цепочке.
Imagine scaling your output 40x by managing AI agents instead of writing code. Richard Kasperowski’s experiment with a Scrum team of six AI agents is a masterclass in modern orchestration. It’s not just about speed; it’s about rigorous safety gates and quality.
See the results: https://kasperowski.com/i-gave-six-ai-agents-a-scrum-board/
AI doesn't create leadership problems; it exposes them. Kate Leto shares a brilliant take on how AI adoption relies on trust and psychological safety rather than hierarchy. It’s a vital reminder that human dynamics drive tech success. Dive into the five patterns here: https://www.kateleto.com/articles/ai-exposes-leadership-gaps #ProductLeadership #Agile
We ask business people to make big plans, but to succeed, they must break those plans into small bites.
My blog talks about the importance of being small.
https://www.edyouragilecoach.com/s-is-for-small/
🏴☠️ 🐻
Agentic AI can produce code 10x faster, but if your testing or governance can't keep up, you've just automated a bottleneck. Nigel Thurlow brilliantly explains why we must fix our systems before scaling them with AI agents. Don't industrialise dysfunction.
https://nigelthurlow.com/automating-a-broken-system-agentic-ai/
Ich nutze die „chaotische” Ablage teilweise, indem ich Verstichwortung verwende. Unter anderem in meinem E-Mail-Postfach, aber auch in Obsidian. Allerdings nicht nur, denn ich habe auch eine sehr schlanke Ordnerstruktur. Sie ist an meine aktuellen Bedürfnisse angepasst. Diese Erkenntnis teile ich offenbar auch mit Thomas Mathoi, der sich mit Obsidian deutlich besser auskennt und es auch deutlich effektiver zu nutzen scheint als ich. Dass er die Allgemeinheit an seinen Erkenntnissen und Erfahrungen teilhaben lässt, finde ich super. Regelmäßig bekomme ich von ihm Anregungen zur Verbesserung meines eigenen Systems. Sein aktueller Erfahrungsbericht gibt mir erneut einen Impuls, meine Ablage (nicht nur in Obsidian) insgesamt zu überdenken.
https://www.mathoi.at/2026/09/09/ordner-in-obsidian-ganz-ohne-gehts-doch-nicht/
Wir haben nicht zu wenig Zeit, sondern wir nehmen uns keine Zeit für die Dinge, die uns wichtig sind. Ich weiß nicht mehr, wo ich diesen Satz aufgeschnappt habe. Aber er trifft den Nagel auf den Kopf. Es ist eine Frage, was uns wichtig ist. Gut, ich lerne gerade, dass es manchen Menschen tatsächlich schwerfällt, Prioritäten zu setzen, weil der zugehörige Filter irgendwie anders funktioniert (ADHS-Betroffene werden verstehen, was ich meine), aber im Grundsatz ist es so. Was wir vermutlich – zum überwiegenden Teil – oft viel zu wenig tun, ist, uns die Frage zu stellen, was für uns wirklich wichtig ist. Denn Zeit hat man nicht – man nimmt sie sich. Und manchmal brauchen wir eine Erinnerung daran. Eine solche Erinnerung hat mir Anna Koschinski in meinen RSS-Reader gespült. Vielen Dank dafür.
https://anna-livia.de/keine-zeit/
Routinen werden – zumindest aus meiner Sicht – zu wenig wertgeschätzt. Ich bin ein Mensch, den Routinearbeit sehr schnell langweilt und nervt. Und doch habe ich Routinen zu schätzen gelernt. Als Entschleuniger, als Erinnerung, inne zu halten und zu reflektieren, als „Gewohnheit“, die mich dazu bringt, Dinge besser zu machen. Genau da setzt der Blogartikel von Dan Rockwell ein Stück weit an. Er hebt die Bedeutung gesunder Routinen hervor, die wir viel zu sehr unterschätzen. Das deckt sich mit meiner eigenen Erkenntnis. In den letzten Wochen habe ich begonnen, mir ein paar neue Routinen anzugewöhnen, weil sie mir guttun. Man sollte sie nicht unterschätzen.
https://leadershipfreak.blog/2026/09/10/a-routine-that-changes-everything/
Ivan Blatter hat erneut eine für mich sehr spannende Podcastfolge veröffentlicht. Er überträgt das Hebelprinzip ins Selbstmanagement. Eine sehr passende Metapher, die er gekonnt auf den Arbeitsalltag und das Zeitmanagement überträgt. Die zentrale Frage lautet: Was ist der Hebel und wo ist der Ansatzpunkt, der uns am ehesten voranbringt? Die Hebelfrage lautet: Was macht alles andere einfacher oder sogar überflüssig? Im Podcast geht er darauf tiefer ein. Ich bin gespannt, wie gut es mir gelingt, die Idee in meine Arbeitsabläufe zu integrieren. 😉
https://share.transistor.fm/s/6fefc937
Der A3-Report ist ein hervorragendes Werkzeug, um Verbesserungen zu ermitteln. Wie immer kommt es allerdings darauf an, wie man das Werkzeug nutzt. Ich sehe im A3-Report-Format eine Visualisierungshilfe, die das Nachdenken unterstützt, und nutze es entsprechend, wenn es zum Einsatz kommt. Dass dies jedoch nicht unbedingt der Fall ist und vermutlich oft nicht der Fall ist, verdeutlicht mir der Beitrag von Götz Müller. Er zeigt genau auf, was schiefgehen kann, wenn das A3-Format nicht als Werkzeug zum Denken genutzt wird, sondern zu bloßem Formalismus verkümmert.
https://www.geemco.de/artikel/a3-ohne-denken/
Gegenwärtig vertreten immer mehr agile Vordenker die Meinung, dass der Einsatz von KI die bisherigen Rahmenwerke und die damit verbundenen Rollen überflüssig macht. Abgesehen davon, dass ich diese Meinung nicht teile, stimme ich Marc Löffler im Kern zu, dass die agilen Grundlagen bestehen bleiben. Unabhängig vom rasanten technischen Wandel, der sicherlich manches beschleunigt und vereinfacht, aber eben auch an anderer Stelle zu ganz neuen Herausforderungen führt, die exploratives, reflektiertes und vermutlich auch bewusst entschleunigtes Arbeiten notwendig machen werden. Wie Marc sehe ich keine Methodenkrise. Methoden wurden und werden immer noch zu Wunderwaffen verklärt, die sie nie waren und nie sein werden.
https://passionateteams.com/e/back-to-basics-%e2%80%94-was-bleibt-und-was-jetzt-kommt
Wie ich bereits erwähnt habe, bin ich nicht der Auffassung, dass die Rahmenwerke und Methoden wie Scrum oder Kanban obsolet werden. Gerade wenn wir tatsächlich mit KI mehr Arbeit erledigen können, besteht die Gefahr, dass wir mehr nicht wertschöpfende Arbeit produzieren. Wie Maria Iqbal richtig erkennt, können wir zwar manche Dinge schneller erledigen, überlasten aber an anderer Stelle unsere Prozesse, indem wir die Menge der parallelen Arbeit erhöhen. Es ist großartig, wie aktuell die Idee von Kanban immer noch ist. Durch den Einsatz von KI verschiebt sich der Engpass ggf. an eine andere Stelle, sodass wir entsprechend reagieren müssen.
https://www.scrum.org/resources/blog/ai-changed-bottleneck-your-wip-limits-should-change-it
Hm, das von Steven Deneir angesprochene Problem ist mit Sicherheit kein typisch „agiles” Problem. Der Status „melonengrün” (außen grün, innen …) ist ein Indiz für ein strukturelles Problem. „Keine Probleme zu haben, ist das größte Problem von allen”, sagte schon Taiichi Ohno. Er war einer der Väter der Toyota Production Systems. Probleme und Hindernisse müssen beim Namen genannt werden, damit man sie lösen kann. Außerdem enthalten sie immer auch die Lösung des Problems und damit die Möglichkeit zur Verbesserung und Innovation, die ungenutzt bleibt. Ganz zu schweigen von der Unmenge an nicht wertschöpfender Arbeit, die damit verbunden ist.
https://www.scrum.org/resources/blog/reality-doesnt-need-your-permission-escalate
Ich bin auf einen Blogartikel von Ralph Jocham aufmerksam geworden, der mich nachdenklich stimmt. In den agilen Prinzipien heißt es: „Einfachheit ist essenziell und damit die Kunst, die Menge der nicht erledigten Arbeit zu maximieren.” Irgendwie haben wir das Lean-Prinzip im Kontext agiler Ansätze nicht gut genug vermittelt. Zumindest wird mir das beim Lesen seines Blogartikels klar. Da muss ich mich auch an die eigene Nase fassen. Wir investieren extrem viel Zeit in die Priorisierung und das Refinement von PBIs. Aber ganz selten stellt jemand die Frage, ob etwas auch zum Ergebnis beiträgt und, wenn nicht, ob wir es nicht einfach „löschen” sollten. Genau das ist etwas, das ich durch die Beschäftigung mit dem Toyota Production System zu schätzen gelernt habe. Was trägt wirklich zum Ergebnis bei und was nicht? Das Weglassen dessen, was nicht zum Ergebnis beiträgt, und das Beibehalten dessen, von dem wir sagen können, dass es uns weiterbringt. Übertragen wir das Ganze auf unsere Backlogs, spüren wir einen echten Effekt, denn Priorisierung ist am Ende ein Nullsummenspiel, das Entfernen nicht-wertschöpfender Arbeit jedoch nicht. Es bringt uns weiter.
https://www.scrum.org/resources/blog/reordering-your-backlog-zero-sum-deleting-it-not
Ich persönlich messe Rollentiteln nicht allzu viel Bedeutung bei. Wichtiger ist, wie sie mit Inhalt befüllt werden. Das wird in der Tat auch immer wichtiger, weil die Rolle des Product Owners, die lange mit Scrum assoziiert wurde, sich inzwischen so stark verbreitet hat, dass man nicht mehr davon ausgehen kann und muss, dass sich dahinter auch ein PO im Sinne von Scrum verbirgt. Das kann mit Blick auf das Erwartungsmanagement aller Beteiligten schnell zur Herausforderung werden, wie ich immer wieder feststellen muss. Daher finde ich den Podcast der Produktwerker zum Thema „Product Owner ohne Scrum – Widerspruch oder inzwischen oft Alltag?” sehr interessant. Er spricht ein Thema an, das sich in der Praxis deutlich wiederfindet.
https://produktwerker.de/product-owner-ohne-scrum-widerspruch-oder-inzwischen-oft-alltag/
Ich bin zwar ein großer Freund von Konzepten wie der psychologischen Sicherheit. Ich lege sehr viel Wert auf Transparenz und Authenzität. Und doch wird es mir langsam zu viel es Guten. Den wie so oft, macht das richtige Maß den entscheidenden Faktor aus. Daher hat mich der Blogartikel von Ralf Lanwehr und Elena Grobbel direkt angesprochen. Führung soll Richtung gebe, Führung soll Klarheit schaffen und Klarheit soll Sicherheit vermitteln. Gleichzeitig braucht es Transparenz, Authenzität und Verbundenheit. Beides muss im Gleichgewicht sein, damit es Wirkung zeigt. Genau das ist es, was die beiden Autoren mit verdaulicher Transparenz überschrieben haben. Diese Balance. Die Überbewertung eines Aspektes ohne sein Gegengewicht, führt funktioniert nicht. Und genau dies ist, auf was es ankommt.
https://t2informatik.de/blog/verdauliche-transparenz/
Langsamkeit ist etwas positives? Ja, ist es. Und wir bräuchten mehr davon. Klar, ich lese ständig, dass die KI alles noch schneller macht. Noch mehr in weniger Zeit ermöglicht. Ist das aber immer erstrebenswert? Ich finde nicht. Zeit für Reflexion, Zeit um Wachsen, Zeit um etwas zu verstehen, Zeit um etwas zu durchdenken ist unglaublich wichtig. Und das gilt auch für das Thema Führung. Gute Führung befähigt, sie bevormundet nicht. Gute Führung, ist entschleunigt und schafft Raum für Reflexion und Wachstum. Und genau darum geht es auch im folgenden Beitrag von Dan Rockwell:
https://leadershipfreak.blog/2026/09/07/the-go-slow-leader/
Ich mache keinen Hehl daraus, dass ich von der sogenannten „Alternative für Deutschland” nichts halte und sie sogar als autokratischen Sauhaufen ablehne. Es ärgert mich kolossal, dass sich eine Partei, die die Werte des Grundgesetzes derart mit Füßen tritt, ausgerechnet mit den Farben des Grundgesetzes, der Frankfurter Paulskirche und der Verfassung der Weimarer Republik schmückt. Nein, sie haben nicht das Recht, diese Farben zu tragen. Ganz im Gegenteil. Denn sie vertreten Werte, die genau die Werte, für die diese Farben stehen, beleidigen und in Abrede stellen. Schwarz-Rot-Gold gehören nicht einer rechtsextremistischen Gruppierung. Sie sind die Farben der Demokratie. Sie sind die Farben der Demokraten und Republikverteidiger, wie zum Beispiel des Reichsbanners Schwarz-Rot-Gold, das sich seit 1924 für Republik und Demokratie einsetzt. Und so sollte es sein. Bei jeder Demo für Demokratie und Vielfalt, die sich der „Alternative” entgegenstellt, sollten die Farben der Demokratie neben den Farben der Vielfalt und dem europäischen Sternenkranz sichtbar wehen. Die Botschaft sollte lauten: Unsere Demokratie, unsere Farben – wir lassen sie uns von euch nicht wegnehmen!
https://www.demokratie-geschichte.de/15426/wem-gehoert-schwarz-rot-gold/
Lutz Heuken schlägt in eine ähnliche Kerbe und benennt klar: Wer eine rechtsextremistische Partei wählt, tut dies nicht aus Protest. Er oder sie wählt bewusst eine verfassungsfeindliche Partei und die Autokratie. Das dürfen wir nicht länger entschuldigen oder verharmlosen. Wir müssen es klar benennen. Ohne Wenn und Aber. AfD-Wähler sind keine Opfer, sondern Täter! Das müssen wir laut und deutlich aussprechen. Wir müssen das laut und deutlich benennen. Demokraten müssen sichtbarer werden. Auf der Straße, im Alltag, im Privatleben, im Beruf. Es liegt an uns. Wir müssen laut und sichtbar werden, in Gespräche gehen und die Fratze des Autokratie der AfD entlarven.
https://www.blog-der-republik.de/afd-waehler-sind-taeter-keine-opfer/
#Agile #Gesellschaft #Leadership #Lean #Management #Politik #ProduktivitätAnsible for DevOps by Jeff Geerling is on sale on Leanpub! Its suggested price is $9.99; get it for $6.99 with this coupon: https://leanpub.com/ansible-for-devops/c/LeanPublishingDaily20260909 #agile #software #startups #ansible #devops #cloud_computing
Dew Drop Weekly Newsletter 500 - Week Ending September 11, 2026
#dewdrop #newsletter #javascript #azure #aspnetcore #blazor #cpp #windowsdev #xaml #dotnet #csharp #ai #mcp #devops #agile #appdev #podcasts #sqlserver #data #powershell #cli #m365
Stable teams sound like a nice-to-have until you look at the fields where an error kills someone.
Most of the academic work deals with familiarity, not stability. Roughly: "we've worked together enough in the past to understand each other as individuals".
Cardiac surgeons who worked across multiple hospitals but maintained stable teams had a lower rate of mortality, even with more surgeries performed.
Aviation gives the same signal. 73 percent of the accidents for which information was available occurred on the first day the captain and first officer had flown together. A NASA study found that fatigued crews who had a history of working together made about half as many errors as crews of rested pilots who had not flown together before.
Tired and familiar beat rested and unfamiliar.
Back down to earth: at Wipro increased familiarity reduced defects by 19%, and Larry Maccherone showed stable teams had 40% better predictability.
I track the business value I deliver to Fortune 500 companies and other organizations I've served. I previously reported $2.51 billion. It's grown. The updated figure is $3.1 billion.
🔎 Learn more: https://scottgraffius.com/blog/files/scott-m-graffius-generated-over-3-point-1-billion-dollars.html
Organisational Dysfunction of the Day
Endless alignment meetings
Context: The calendar is full of alignment meetings. Syncs between teams, cross-functional check-ins, steering group updates, all-hands, and the occasional offsite to get everyone on the same page. Each one feels necessary in isolation. There really are dependencies to manage and decisions that affect multiple parties. But the total volume is considerable, and after every meeting, more meetings are needed. The organisation is spending a significant portion of its working time just trying to stay coordinated.
OST explains: High coordination cost is a reliable indicator of poorly drawn boundaries: when teams depend on each other to complete their own work, they need constant communication to manage those dependencies. In a DP2 structure, a group owns its whole task, including responsibility for its own coordination and control, which is exactly what removes the need for this kind of external alignment work. Research on the software industry found that lack of coordination makes a more powerful contribution to low motivation than lack of control. Most discussion of engagement assumes autonomy is the primary driver; working together toward shared goals appears to matter more. The meetings are not just a productivity drain: they are what fills the space left by coordination that was never designed into the structure, and that absence is what erodes motivation. The goal is not fewer meetings; it is a structure where coordination is built into the work itself.
#OpenSystemsTheory #SocioTechnical #OrgDesign #agile
***
The series has become a book, available now on Leanpub.
http://organisationaldysfunctions.com
i like to push the keyboard away and to create a workshop design offline...
and must admit, its really helpful to have so many thought out material by @barryovereem and @christiaanverwijs 🙏
you can find it here:
https://github.com/theliberators/facilitation-materials/
and still need to digest it into my own flow.
Things get weird during holiday work weeks. If you missed it, here is my take on why estimation matters.
https://www.edyouragilecoach.com/e-is-for-estimation/
🏴☠️ 🐻
#Business #GhostGang #Agile #Leadership
and
Organisational Dysfunction of the Day
Somebody has to chase it
Context: The reorg genuinely changed things. Stream-aligned teams now own their own backlog and ship independently, without waiting on a steering committee. People notice the difference; work feels less like asking permission. But cross-team dependencies did not disappear when the topology chart was drawn; they just stopped having an owner. A platform change that three stream-aligned teams need gets raised in three different Slack channels and forgotten in two of them. The one that gets built is the one where someone personally followed up, twice, then a third time. That person is not the platform team's manager and has no authority to reprioritise anyone's backlog. They are just the one who keeps asking.
OST explains: Wilfred Bion identified pairing as one of the basic assumption patterns a group falls into when it is not working to task: an unconscious reliance on a few individuals to generate the movement the group is not structured to produce on its own. Merrelyn Emery's organisational instrument measures this directly, as a single item: how many people report that a few must personally push things forward for anything to happen. Team Topologies, done well, can genuinely increase control: teams own more of their own work and answer to fewer layers above them. What it does not automatically produce is coordination, the horizontal negotiation between teams that a topology diagram assumes but does not design. Where that negotiation mechanism is missing, what remains is informal pushing, absorbed by whoever notices the gap and cares enough to close it, without the authority that would make it anyone's actual job.
***
The series has become a book, available now on Leanpub.
https://www.organisationaldysfunctions.com/
Habr » 🤖 🌐
@habr@zhub.link
SDD для AI-агентов: как мы заново изобрели очень быстрый waterfall
Представим обычную продуктовую задачу. Нужно добавить новую фичу. Команда описывает её через Specification-Driven Development и фиксирует сценарии, ограничения, API и критерии приёмки. Агент получает контекст, быстро пишет код, тесты и инфраструктуру. Через день, а то и раньше, почти готов результат. Но где здесь waterfall? Если фича изолирована, команда может безопасно выкатить её под флагом, быстро увидеть пользовательский сигнал и так же быстро откатить изменение. Тогда большой агентный батч становится отличным экспериментом. Привет, Хабр! Меня зовут Марат Киньябулатов, я эксперт по гибким практикам и отвечаю за эффективность инженерных команд в ядре банка. В этой статье я разберу, когда SDD действительно помогает агентам, а когда слишком рано фиксирует решение. Покажу это на нескольких кейсах и разберу, как сохранить короткий цикл обратной связи, когда код появляется быстрее, чем команда успевает проверить результат.
https://habr.com/ru/companies/raiffeisenbank/articles/1078392/
#specdriven_development #sdd #aiагенты #агентная_разработка #waterfall #extreme_programming #agile #code_review #маленькие_батчи #управление_разработкой
@barryovereem thanks for sharing, i find it always very valuable to zoom in and talk about the small details as a facilitator.
The Anatomy Of Domain-Driven Design - Booklet by Scott Millett and Samuel Knight is free with a Leanpub Reader membership! Or you can buy it for $7.99! https://leanpub.com/theanatomyofdomain-drivendesign #agile #computer_programming #software
Agile's success is also its Achilles heel. Everyone wants to do Agile, but not everyone wants to make any changes to be Agile. There is a lot of focus on performing ceremonies, yet organizations often don't take the time to understand the mindset.
It's sometimes hard to talk about Fake Agile in your own organization. Outside stories can help:
- Detecting Agile BS, from the US Defense Innovation Board https://media.defense.gov/2018/Oct/09/2002049591/-1/-1/0/DIB_DETECTING_AGILE_BS_2018.10.05.PDF
- Agile Theatre is Doing More Damage Than Waterfall Ever Did https://hackernoon.com/agile-theatre-is-doing-more-damage-than-waterfall-ever-did-20cb783ccd1b
- How the Efficiency Mindset Leads to Zombie Scrum https://medium.com/the-liberators/how-the-efficiency-mindset-leads-to-zombie-scrum-d817b29fa852
- Imposition and Dark Agile, by Ron Jeffries https://ronjeffries.com/articles/018-01ff/dark-imposition/
- A bleak outlook for public sector tech https://sboots.ca/2021/12/15/a-bleak-outlook-for-public-sector-tech/
More ways to do Fake Agile exist than can be counted.
https://agilepainrelief.com/glossary/fake-agile/?utm_source=mastodon&utm_campaign=archive-reshare
We hebben het perfecte kerstcadeau voor Nederlandstalige (#agile) #testers
https://leanpub.com/agiletestingcondensed-nl/
De Nederlandse vertaling van
janet gregory
&
@lisacrispin boek vertaald door de Nederlands talige community