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

#LINKSDERWOCHE | 18/2025: Produktivität, Agile, Management und Leadership

EDITORIAL

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.

PRODUKTIVITÄT

Prokastination | Wenn „Verschieben“ zum Problem wird

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.

https://www.manage-dich-selbst.de/prokrastination-ueberwinden/#Welche_konkreten_Ursachen_fur_Prokrastination_gibt_es

KI und Workflows | Ändert sich wirklich etwas?

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

Schmeichelei | Weshalb wir Schmeichelei bleiben lassen sollten und was wir stattdessen tun sollten

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/

Tooltipp | Datensparsam im Grünen den Weg finden

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/

Kreativität | Kreative Lösungen entstehen im Plural

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/

AGILE

Scrum Master | Wie man es garantiert vergeigt …

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 | Agiles Produktmanagement gehört zum Handwerkszeug

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/

Veränderungen | Überzeugen durch Wirksamkeit

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/

Obeya | Starte mit dem Wozu

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/

MANAGEMENT UND LEADERSHIP

Organisatorische Silos | Wie lokale Optimierung zur Falle für die Organisation wird

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

Freie Wahl | Den „Chefe“ selbst auswählen

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

Kompetenzaufbau | Sinnvoll in die KI-Kompetenz investieren

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/

Sustainable teams over individual heroics

https://doi.org/10.13140/RG.2.2.12459.91681

#Agile #AgileLeadership #AgileProjectManagement #AgileScrumGuide #AgileTeams #Collaboration #ContinuousImprovement #Innovation #Leadership #ProjectManagement #Scrum #SustainableTeams #TeamDynamics #Teamwork #WorkCulture #SustainableTeamsOverIndividualHeroics #HeroesInAgile

@SabineTerwelp
oh, so cool. warm welcome to our beautiful #fediverse

@stereo @acccgn @micheal @agile

#acccgn26 #scrum #agile

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!

#AI #agile #systemlearning

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

#ai #agile #systemlearning

Thank you to Gartner for the shout-out!

EDIT: Originally from 2019, but worth revisiting.

#Agile #Scrum #AgileScrumGuide #AgileProjectManagement #ProjectManagement #ScrumMaster #ProductOwner #Book #Gartner #Tech #Metrics #Quote #MetricsQuote

Hackathons often fail when they're just "real work" in disguise. True innovation needs a safe space for weird, unconstrained ideas. PostHog proves that protecting this time builds multi-million pound products. Stop the roadmap talk and let your team build: https://newsletter.posthog.com/p/great-companies-are-built-in-hackathons #ProductLeadership #Agile

will do a session about #columinity at the @acccgn in some minutes.

#agile #scrum #acccgn26

Alt...

part of the open space schedule showing my session directly after the session of bob galen ☺️

just happened at the @acccgn people attending a screening of elenas movie

cc @_elena
@agile

#scrum #agile #fediverse #acccgn26

Alt...

people sitting in front of a projected movie

Dew Drop Weekly Newsletter 481 - Week Ending May 1, 2026

https://zc.vg/VK9Bt?m=0

#dewdrop #newsletter #aspnetcore #css #azure #javascript #xaml #cpp #windowsdev #dotnet #csharp #mcp #ai #agile #devops #gamedev #appdev #dotnetmaui #podcasts #m365 #data #sqlserver #powershell #devtools

working software over comprehensive documentation;

Good code documents itself.

But there’s a lot of context outside the code that informs it. There’s architecture and design decisions about which language to use, about whether it’s micro services, monoliths, containers, clouds, or mobile apps.

There’s legal frameworks and security certifications.

Code determines how. Tests determine the what. But documentation tells you why and when. Documentation supports future you or the next team member to understand what the reasoning behind that code was. It gives your present self grace for what you know now and don’t know yet.

Document the requirements in just enough detail, but document the decisions in depth. Working software, that’s suitably readable, is the best way to describe what it does. But understanding how that code came to be has a value you only understand after you forget how it came to be.

Document why you built this, but not that. What was the experiment? What was the context? Is it time to experiment again? Is it time to chalk the experiment up to experience and move on?

Be nice to yourself. Comprehensively document decisions.

Alt...

A mug with a handle that's broken into many pieces

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.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

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 #просторетро

»Two Steps Ahead: What I Learned by Leading an AI Adoption Before Anyone Asked Me To« https://agilealliance.org/leading-an-ai-adoption/ #Agilist.in #Agile #Change #Lean #Kanban #Scrum

Working in Jira is like wading through molasses. And they call this agile?

#Jira #agile

the @acccgn is about to start

#scrum #agile #acccgn26

Alt...

people sitting in a large circle

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.

#OpenSystemsTheory #SocioTechnical #OrgDesign #strategy

Anthropic’s shift from monthly to daily shipping is a masterclass in AI product agility. Cat Wu highlights why PMs must build for future models today. See how mission alignment and "just doing things" eliminates friction: https://www.lennysnewsletter.com/p/how-anthropics-product-team-moves #AI #Agile

AI is a dysfunction multiplier if your "demand funnel" is broken. John Cutler explores how demand mix—whether you're a feature factory or truly empowered—dictates success. Adding AI to a messy process won't fix it; it just accelerates the chaos.

Explore the framework: https://cutlefish.substack.com/p/tbm-415-demand-mix-shaping-and-ai

#ProductManagement #Agile

leaving #freiburg in some minutes, heading to the @acccgn

@agile
#scrum #agile

Alt...

sunny freiburg trainstation

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)

I'm currently reading Tom Gilb's paper titled Evolutionary Delivery versus the "Waterfall Model," which was published in 1985!

#agile

Alt...

A black and white flow chart titled "The EVO Cycle 'spread out'" illustrates a hierarchical project management methodology across three levels of scale. The diagram is organized into three descending columns that represent timeframes, moving from left to right: Multi-year Level (Left): Three large, bolded boxes stacked vertically: Analysis (tagged with a "Goals" bullseye icon), Design (tagged with a "Solutions" lightbulb icon), and Planning (tagged with a "Steps" grid icon). Thick arrows point from Analysis to Design, and Design to Planning. Single Year Level (Middle): Smaller versions of the Analysis, Design, and Planning boxes. Horizontal arrows indicate that the Multi-year Analysis feeds into the Single Year Analysis, and so on. A vertical arrow labelled "Feedback and Correction" points from the bottom of this section back up to the Planning box. Step Level (Right): Four columns of very small boxes labelled Ana, Des, Pla, and Dlvr (Delivery).

Agile question for the community:
Who benefits most from how your team runs Agile today - business, engineering, or customers?

Joshua Angolano is speaking at Nebraska.Code() about aligning all three.

👉 https://nebraskacode.amegala.com/

#Agile #SoftwareEngineering

The PM role is shifting. Nikhyl Singhal’s latest take on the "AI-first" rehire and why half of PMs are at risk is a wake-up call for senior leaders. Success now demands reinvention over fancy logos. See how to navigate this chaotic period: https://www.lennysnewsletter.com/p/why-half-of-product-managers-are-in-trouble #ProductLeadership #Agile

»Importance of ENTRY as a…« https://bobgalen.substack.com/p/importance-of-entry-as-a #Agilist.in #Agile #Change #Lean #Kanban #Scrum

Карта выживания новичка: как устроена разработка ПО в российских реалиях

В IT-индустрии сложилась парадоксальная ситуация. Курсы по Python, тестированию и аналитике плодятся как грибы после дождя. Тысячи людей получают «корочки» и выходят на рынок, уверенные, что знают своё дело. Но на практике одного знания языка программирования или инструмента оказывается катастрофически мало. Встречаются сотрудники, которые блестяще разбираются в конкретной технологии, но понятия не имеют, как работает продуктовый цикл, зачем нужна ретроспектива и почему тимлид не утверждает их пулл-реквест. Они путаются в подобных элементарных вещах, что не дает им расти. Чтобы стать настоящим профессионалом, нужно понимать, как работает система под названием «разработка программного обеспечения» в целом. И как же она работает?

https://habr.com/ru/companies/bhv_publishing/articles/1029460/

#разработка #карьера #agile #kanban #онбординг #онбординг_новых_сотрудников #разработка_по

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

Stop calling it assistance. #AI is management.

In #agile, we said teams decide. Now models decide faster, cheaper, and without meetings. You don’t collaborate with #AI — you align to it.

#AgileCheese makes it explicit: the real shift isn’t automation of work, it’s automation of judgment. If your decisions can be predicted, they will be replaced.

So choose: become unpredictable — or become obsolete.
That’s where the #cheese starts. 🧀🔥

tomorrow is the start of the @acccgn

I am very proud of our move to onboard the attendees to use #matrix and join a "space" for that.

no #slack no #discord not ms #teams
instead @element for @matrix

@agile

@micheal
@DerGuteAlteHerrSchwarz @Tapir @rueschen @can_g 🎉

#exciting #scrum #agile #agileparty #acccgn26

This illustration of me as a GTA-style character was created for my speaking engagements at video game development conferences. 🎮

Continue: https://scottgraffius.com/publicspeaker.html

#Gaming #GameDev #VideoGameDevelopment #GTA #PublicSpeaker #Agile #Agility #Teamwork #Innovation

@acccgn_countdown @acccgn

oh, only two times sleeping ;) @agile

just collecting attendees from the @haufegroup to invite them to our digital twin rooms in #matrix

@DerGuteAlteHerrSchwarz @Tapir @rueschen @can_g 🎉

#exciting #scrum #agile #agileparty

In case you missed it. Here is my blog post about the basics you need to know when turning around a failing team.

https://www.edyouragilecoach.com/why-your-agileteam-is-struggling-and-how-to-fix-it/

Listening, written rules of the road, and setting expectations work wonders.

#GhostGang #Agile #business #leadership

@albertocblanco

Ремонт в квартире как IT-проект: Scrum, спринты и ежедневные митапы с бригадой

Как связаны ИТ и строительство? Очень тесно — через методологию управления. Несколько лет назад я впервые столкнулся с методологией Scrum. Тогда она произвела на меня колоссальное впечатление. Позже, конечно, я нашёл и негативные стороны этого подхода, и понял, что в разных проектах лучше использовать разные подходы. Благо, что их придумано множество!

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

#Scrum #Agile #управление_проектами #ремонт_квартиры #daily_standup #проектное_управление #методологии #лидерство #быстрый_ремонт #строительство

In an Agile sense, do you think the time a task spends in "blocked" (eg waiting on a third party) counts as time spent on the task?

#softwareengineering #agile #dev

Fighting #complexity with #AI makes it even worse.

Complexity was never the problem — hesitation was.

#agile tried to manage complexity with frameworks.
#AI tries to remove it with automation.
Both miss the point.

Every layer added to “handle complexity” hides responsibility.
The system gets smarter — accountability disappears.

#AgileCheese does the opposite.
We remove options until decisions hurt again.

If it doesn’t hurt, it’s not real.
Comfort kills. 🧀🔥

Story points — прошлый век?

Мнение. Предложение к обсуждению, а не новая догма. Story points долго были удобным способом оценивать сложность задач в разработке. Но в 2026 году всё больше работы делается не только инженером, но и в связке с LLM: генерация кода, тестов, документации, рефакторинг, разбор ошибок. Возникает вопрос: может ли рядом со story points появиться новая метрика — neuro points, отражающая AI-итеративность решения задачи? В статье предлагаю этот подход как гипотезу для обсуждения и разбираю, зачем он вообще может понадобиться командам, которые уже активно используют нейросети в рабочих процессах. Обсудить подход

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

#story_points #neuro_points #agile #scrum #LLM #AI_coding #оценка_задач #нейросети_в_разработке #developer_productivity #engineering_management

Organisational Dysfunction of the Day

Fear of making decisions

Context: One issue many teams in an agile organisation face is the stalemate that frequently happens when they need to make a decision that will impact other teams or other parts of the organisation. They have been empowered and given autonomy to decide for themselves, but they still want to be good players and are afraid to do something that could negatively impact others. Some may even be worried whether the change is allowed at all, like changing their work process or tools to use for things like ticketing, or changing the technical architecture by using a different data storage platform. Good ideas and suggested improvements are often shelved or even abandoned.

OST explains: This is another predictable side effect of a partial DP2 transition to self-managing teams, where the teams are given autonomy to self-manage, but do not feel able to. Or, maybe now they are not really empowered, as they know all too well, there are DP1 (bureaucratic) structures still in place that can and will stop them. And, even if they were in a pure DP2 setup, they still need tools to coordinate. One that works well is referred to as the "advice process" and was first described by Dennis Bakke, later by Laloux and Harmel-Law. In it, anyone can make any decision provided they follow this simple rule: first seek advice from 1) everyone who will be meaningfully affected, and 2) people with expertise in the matter. So instead of drawing up everything and then getting approval from someone who cannot possibly understand it properly, or going rogue, you formulate the decision as best as you can and then seek advice on it and adjust it to your liking based on that. Not only do you make better decisions, but you also own them. No more blame game, which DP1 creates, and no chaos, which the mixed mode induces. Participative democracy in practice.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Dr. Harold Kerzner's "Innovation Project Management" book features content from my "Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions" book:
https://amzn.to/3LFxFfO

#Agile #Scrum #AgileScrumGuide #ProjectManagement #Innovation #ScrumMaster #ProductOwner #Book