#LINKSDERWOCHE | 19/2025: Produktivität, Agile, Management und LeadershipLINKSDERWOCHE |

PRODUKTIVITÄT

Schlechte Gewohnheiten | So wird es einfach sie wieder los zu werden

Schlechte Gewohnheiten erwirbt man oft unbewusst. Sie schleichen sich ein. Allmählich und hinterhältig. Wie wird man sie wieder los? Wenn man Dan Rockwells Ideen hierzu folgt, wird es etwas einfacher, aber es ist dennoch schwer genug. Ein Grund, das Handtuch zu werfen? Niemals.

https://leadershipfreak.blog/2026/05/08/break-the-habit-of-bad-habits/

PROJEKTMANAGEMENT

Dos und Don’ts | Damit das Projekt gelingt …

Wer es kurz und knackig mag: Ich bin normalerweise kein Freund von KI-Zusammenfassungen, mache hier aber eine Ausnahme, weil sie wirklich gut ist. Hier sind die Dos und Don’ts im Projektmanagement von Bernhard Schloss als grafische Zusammenfassung. Man sollte sie sich ausdrucken und in jeden Projektraum hängen 😉

https://www.bernhardschloss.de/blog/dos-und-donts-im-projektmanagement/

Projektstatusbericht | Wie man ihn besser macht

Ich persönlich würde, wann immer es möglich ist, direkt auf Obeya umsteigen. In einem gut gestalteten Obeya-Raum habe ich alle Schlüsselinformationen auf einen Blick und die Notwendigkeit eines Statusberichts, wie er im Projektmanagement üblich ist, entfällt. Nur leider liegt das nicht immer in meiner Hand und es wird wohl auch weiterhin Projekte geben, in denen jemand einen Statusbericht verlangt. Wenn er gut ist und Nutzen stiftet, ist das durchaus legitim. Leider ist das so eine Sache mit der Qualität. Aus verschiedenen, durchaus nachvollziehbaren Gründen, die auch im Artikel von Andrea Windolph ihren Niederschlag gefunden haben. Spannender sind allerdings die Hinweise, wie man es besser macht. Das lässt sich übrigens auch auf andere Kontexte gut übertragen. Und ja, Kommunikation ist nicht einfach.

https://projekte-leicht-gemacht.de/blog/projektmanagement/klassisch/projektsteuerung/projektstatus-fehler/

LEAN

Versteckte Kosten | Wenn man das System igorniert …

Mark Graban trifft damit einen Nerv. Viele begehen einen zentralen Fehler, wenn sie versuchen, Kosten zu optimieren. Sie betrachten nicht das Gesamtsystem, sondern nur Teilbereiche. Die Personalkosten stehen oft in der Kritik, weil sie als zu hoch angesehen werden. Was ich an Toyota Production System (TPS) schätze, ist, dass dort eben der ganzheitliche Blick vorherrscht. Dies haben viele bei ihrer Lean-Adaption leider übersehen. Das ist ein Grund, weshalb ich lange mit „Lean” gehadert habe (ich kannte zu dem Zeitpunkt nur die angelsächsische Lean-Variante und noch nicht Monozukuri). „Lokale Optimierung” verschiebt die Folgekosten lediglich und oft genug steigen die „Gesamtkosten” (besonders, wenn man Kunden, Lieferanten usw. mit einbezieht) dadurch deutlich. Als Kunde großer Telekommunikations-, Versicherungs- und Energiekonzerne kann ich darüber mittlerweile mehr als nur ein Lied singen. Daher freut es mich, dass Mark Graban das Thema aufgreift und verdeutlicht, dass man etwas mehr Hirnschmalz investieren muss, wenn man sinnvoll an das Thema „Kosten sparen” herangehen will. Auskömmlichkeit zu verbessern ist halt etwas anderes …

https://www.leanblog.org/2026/05/working-charge-nurse-hidden-cost/

Das System wirkt | Niemand kann einfach aus dem System ausbrechen

Wie oft musste ich schon hören, dass die Menschen schlicht und ergreifend nicht das richtige „Mindset“ haben und es deshalb nicht klappt! Bei näherer Betrachtung lag es jedoch nicht unbedingt an den Menschen und ihrer Haltung, sondern in weiten Teilen am System selbst und seiner Mechanik. Diese lässt sich nicht einfach dadurch ändern, dass man jetzt regelmäßige Retrospektiven durchführt. Götz Müller greift dieses Thema im Zusammenhang mit Lean und Verbesserung auf und verdeutlicht: Oft liegt es nicht an den Menschen, sondern am System.

https://www.geemco.de/artikel/warum-menschen-auf-systeme-reagieren-und-nicht-auf-leitbilder/

Pimär Metrik | Wie Metriken helfen Wirksamkeit von Verbesserungen zu prüfen

In John Knotts Blogartikel geht es um Verbesserung und Metriken. Interessanterweise beobachten wir häufig, was nicht gut läuft. Darauf basieren Annahmen und Hypothesen über die Ursachen und die mögliche Wirkung. Allerdings machen sich nur wenige Gedanken darüber, wie sie diese Vermutungen faktenbasiert, also empirisch, belegen können. Dabei geht es nicht darum, Zahlen zu erzeugen, sondern in erster Linie darum, transparent zu machen: Sind unsere Annahmen korrekt und zeigen unsere Maßnahmen daher Wirkung?

https://blog.gembaacademy.com/2026/05/08/start-every-process-improvement-effort-with-the-primary-metric/

AGILE

Zu viel Planung, zu wenig Fortschritt | Wenn es an der Basis klemmt

Obwohl viele von Agilität reden, kommt mir das, was Merlin Mechler unter dem Stichwort „zu viel Planung, zu wenig Fortschritt” zusammenfasst, doch sehr bekannt vor. Besonders gerne – sorry, ich kann es mir nicht verkneifen – fallen mir dazu Umfelder ein, in denen man sich skalierte Rahmenwerke auf die Fahne schreibt. Die Grundlagenarbeit passt noch nicht. Es fehlt der Fokus auf Wirksamkeit und kurze, echte Feedbackschleifen, die aufzeigen, wo die Probleme liegen. Wenn man das Ganze mit passenden Metriken ergänzt, die auch tatsächlich sinnvolle Veränderungen sichtbar machen und das „Lernen” als Organisation unterstützen, wird es definitiv besser. Aber Achtung: Auch mit Kennzahlen kann man viel Schindluder treiben, und „Controlling” ist kein Selbstzweck. Die Metriken dienen dazu, das Lernen als Organisation zu stärken. Sie sollten daher auch regelmäßig auf den Prüfstand gestellt werden.

https://t2informatik.de/blog/zu-viel-planung-zu-wenig-fortschritt/

Stakeholdermap | Immer noch ein Top-Werkzeug fürs Stakeholdermanagement

Die gute alte Stakeholder-Map ist nach wie vor ein hervorragendes Werkzeug, um den Überblick über die verschiedenen Anspruchsgruppen und ihre Bedürfnisse zu behalten. Leider erlebe ich in der Praxis sehr häufig, dass sie zwar begonnen, aber selten dauerhaft gepflegt wird. Das liegt vermutlich daran, dass sie nicht Teil der „alltäglichen” Arbeit ist und dann gerne mal vergessen wird. Abhilfe schafft hier ein guter Obeya-Raum, in den sie integriert ist, weil sie dann präsent bleibt und bei Bedarf schnell fortgeschrieben werden kann, wenn neue Erkenntnisse hinzukommen. Nur mal so am Rande. Wer jetzt nicht weiß, was ich meine, für den bietet der kleine, aber feine Artikel von Fadi Stephan eine schnelle Zusammenfassung des Werkzeugs Stakeholder-Map.

https://www.kaizenko.com/how-to-manage-stakeholders-using-the-power-interest-matrix/

Planung ist ein „gemeinsames Problem“ | Auch in der Planung gilt: echte Zusammenarbeit ist Trumpf

Ein Klassiker, den ich auch immer wieder erleben durfte: Product Owner:innen und Teams werden bei der Planung gar nicht groß gefragt. Das Management entscheidet irgendwo, wann was fertig zu sein hat, und dann gibt es ein böses Erwachen. Und das, obwohl es mehrfach Hinweise aus dem Team und vom Product Owner gab. Ein solches Projekt durfte ich vor geraumer Zeit als Scrum Master begleiten. Erst als es richtig geknarzt hat und wir kräftig investiert haben, lief es ähnlich wie von Mike Cohn als idealer Zustand beschrieben. Überraschung: Die Planung war nicht nur realistisch, sondern die dabei entstandene Transparenz im Dialog hat auch beim Management zu einem besseren Verständnis der Herausforderungen geführt, die es zu lösen galt. Leider endete kurz darauf meine Zeit in diesem Projekt – wie das bei Externen nun mal so ist. Soweit ich jedoch gehört habe, läuft es jetzt deutlich besser und reibungsfreier. Es lohnt sich wirklich, zusammenzuarbeiten, auch über „Hierarchieebenen” hinweg. Die Fachleute auf der operativen Ebene können dem Management nämlich realistischer zurückspiegeln, was machbar ist und was nicht. Ab und an den Ort des Geschehens zu besuchen, ist durchaus etwas, das man tun sollte. 😉

https://www.mountaingoatsoftware.com/blog/when-planning-should-become-a-shared-problem

MANAGEMENT UND LEADERSHIP

Komplexität | Die 4 Hebel für den Umgang mit Komplexität

In den letzten „Links der Woche” hatte ich bereits auf Daniel Dubbel verwiesen, der zu Recht erklärt hat, dass Komplexität kein neues Phänomen ist. Unabhängig vom Rahmenwerk gibt es einige Dinge, die dabei helfen, die Zusammenarbeit in komplexen Situationen sinnvoll zu gestalten: Vernetzungsgrad gestalten, Abhängigkeiten klären, Transparenz herstellen, Geschwindigkeit takten, Informationsdichte filtern. Dabei ist Visualisierung, wie sich der geneigte Leser sicherlich denken kann, extrem hilfreich. Daniel Dubbel führt das Ganze noch ausführlicher aus, sodass man einen guten Rahmen erhält. Das Ganze gilt es dann auszugestalten. Zu einem Zusammenarbeitssystem, bei dem ein geeignetes Rahmenwerk Hilfe bieten kann – aber nicht muss.

https://www.inspectandadapt.de/komplexer-mythos-hier-sind-4-hebel/

„Scrum is a team collaboration framework. Kanban is a method to manage work."
Schon die Wikipedia-Definitionen zeigen den fundamentalen Unterschied. Scrum optimiert auf Menschen. Kanban optimiert auf Arbeit.
In Unternehmenssystemen, in denen Arbeit heterogen ist – Support neben Projekten, Kleinstaufgaben neben Epics – bricht das Rückgrat von Scrum (der stabile Sprint) regelmäßig. Flow-Management ist dort die ehrlichere Wahl.
Wir managen die Arbeit, nicht die Menschen.
#agile #scrum #kanban

I didn‘t Write the Work-Feedback Loop with #AI in mind but to explain the fundamentals of #agile Systems. But time and again I see that it can explain why AI often fails: The Loop is not closed, Systems miss the Feedback Part… https://no-bullshit-agile.com/wfl/

Do you agree with me when I say that agile work is primarily about being a learning organization? What do I mean by that? Organizations are forced to learn effectively and reliably when they operate in a complex environment. This learning can only take place if real-world feedback has a direct and immediate impact on the next step in development. That’s what I call learning. BTW: that’s why the use of AI often isn’t successful. People forget that feedback must have an impact.

#agile

🎉 В RetroPoint появился модуль 1‑2‑1

От ретро — к управлению командой.

У тимлида в профиле теперь есть личная комната с каждым участником: общая повестка с авторством пунктов, действия с дедлайнами и привязкой к Key Results, лента обратной связи и приватные заметки только для руководителя. Всё в одном продукте — не нужно собирать связку из 5 разных сервисов.

Что внутри:
📅 Встречи с .ics-приглашением в календарь
📝 WYSIWYG-заметки и повестка от обоих участников
✅ Action items на уровне комнаты с фильтрами
💬 Обратная связь по типу praise / development / observation
🔒 Приватные заметки тимлида (видны только вам)
🎖️ Каталог из 30 бейджей признания — от «Шерлока Холмса» до «Древня»
📤 Экспорт всей истории в Markdown и PDF

Подключается пакетом «1‑2‑1 для команды» — 199 ₽/мес или 1 990 ₽/год — на тарифах «Команда», «Направление» и «Бизнес».

Как начать: профиль → команды → вкладка «1‑2‑1».

Подробности — в анонсе на https://retropoint.ru/news/one-on-one-launch 👉

@rf @Russia@3zi.ru @russia@lemmy.ml @russian_mastodon

#RetroPoint #тимлид #1to1 #управлениекомандой #retrospective #ретроспектива #agile #scrum #kanban #teamlead #it #itleads #teamleadthings #команда #retroonline #просторетро #oneonone #one2one

Is your team working at maximum speed but struggling to deliver? Join us at @SoCraTes_UK Training Day (June 18th near London) to meet @tottinge for his session on Value Stream Mapping. 📊

Learn to identify hidden waste and "10x" your delivery WITHOUT working harder, by adopting lean practices for agile development. 🚀

🎟️ Info: https://socratesuk.org/training_day.html

(1/3) 🧵 #Lean #Agile

Alt...

Headshot of Tim

What's the biggest topic in your #agile #team right now? For us it's achieving a smoother #flow. That means smaller #stories, which requires more modular #development, which requires better #tests. Everything's connected, but I'm convinced it pays off. It's a journey :)

With #AI, the number of possible could-dos has exploded. The bottleneck is no longer ideas — it’s execution.

#AgileCheese has a radical answer: implement all of them.

Impossible? Not with #PersonalityVirtualization. Why limit yourself to one productive self when your brain can host an entire parallelized #agile organization?

One personality strategizes, one codes, one tests, one ships.
Infinite throughput powered by #cheese. 🧀🚀

@stereo @haufegroup @acccgn @micheal

it was a beautiful experience to learn from others and share from myself.

@luilegeant
@PaddyCorry @pedromosilva @SabineTerwelp @Tapir @DerGuteAlteHerrSchwarz @rueschen @gerhard

@agile

#agile #scrum #kanban

Alt...

my very friendly and happy looking agile / scrum / okr colleagues at the agile coach camp cologne

Die KI-Ausgabenfalle: Warum Adoption schneller gelingt als belastbare Ergebnisse (von Stefan Wolpers)

Was der Agile-Hype und KI-Hype gemeinsam haben.

https://www.scrum.org/resources/blog/die-ki-ausgabenfalle-warum-adoption-schneller-gelingt-als-belastbare-ergebnisse

#scrumDotOrg #Scrum #StefanWolpers #ScrumMaster #Agile #Agilität

Dew Drop Weekly Newsletter 482 - Week Ending May 8, 2026

https://zc.vg/2D38e?m=0

#dewdrop #newsletter #javascript #css #azure #blazor #cpp #xaml #windev #csharp #dotnet #ai #mcp #agile #devops #dotnetmaui #appdev #podcasts #m365 #data #sqlserver #powershell #cli

Organisational Dysfunction of the Day

The error factory

Context: Something goes wrong. A post-mortem is held, a root cause is identified, and a fix is put in place. A few months later, the same thing goes wrong again, in a slightly different form. The organisation responds with more process, more checklists, more training. The error rate stays stubbornly high. Leadership concludes that people are not following the processes correctly, so more oversight is added. The errors continue. Nobody questions whether the structure itself might be amplifying the mistakes rather than catching them.

OST explains: The research is mathematically precise on this. In a DP1 (bureaucratic) structure, if five people each make sound judgements eight times out of ten, the probability they give you correct unanimous advice is only one in three. The more you control through hierarchy, the deeper you move into error. In a DP2 structure with the same five people and the same fallibility, wrong unanimous advice occurs only three times in ten thousand. In DP1, errors get amplified because asymmetry and competition mean people filter information to serve their own position rather than the truth. In DP2, the same errors become learning opportunities because everyone has shared responsibility, and it is in nobody's interest to hide a mistake. The diagnosis of inadequate training and the prescription of more training will not reliably reduce error rates; that requires attention to the underlying structural cause.

#OpenSystemsTheory #SocioTechnical #OrgDesign #management

“Wir freuen uns dir mitzuteilen, dass wir deine Einreichung “User-Centric Product Management in Open Source” für die 24. Gulaschprogrammiernacht akzeptiert haben.”

🥳

Bis bald bei der #gpn24!

#productmanagement #agile

Product Feedback looses value over time. The value decays. What is your Feedback Response Time?

#agile #Product #Feedback #Response

Alt...

we wn -— . | ‘action Love. had en i, CC SCN EE Cre Se EE Err S——— EE Cr Se IF (2.1rt > t_threshold) { LOOP EFFECTIVENESS="DEGRADED"; }

Is your strategy connected to production?

#agile #strategy #production

Alt...

we wr i. vr SE om — [ome Tom [mmm [em] EE rrr Re fe IF (strat > t_coord) { STRATEGIC RESPONSE="LAGGING'; } pms iEm—— ERS

In tech, we know how to scale systems. But scaling humans? Well … that’s another story.

Even with the right tools and processes, technical teams often struggle to scale behaviorally & culturally.

In this #InfoQ video, Charlotte de Jong Schouwenburg explores why behavioral and cultural scaling is harder than technical scaling - and what leaders and teams can do about it.

🎬 Watch now: https://bit.ly/4uw8ctk

📄 #transcript included

#Teamwork #Performance #Scalability #Agile

How fast can you reallocate budget based on signals you get from the real world?

#agile #budget #decision #signal

Alt...

we wen -— wr [om Jom [mmm [mn] EER CTT Re EN rrr —— om IF (t_cap >> t_prod) { COUPLING="RIGID"; ADAPTIVE RANGE="RESTRICTED"; } i SAE,

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

What's your latency?

#agile #loop #protocol

Alt...

Work-Feedback Loop Protocol

»From Requirements to Results: A Product‑First Model for Business Analysis« https://agilealliance.org/from-requirements-to-results-a-product-first-model-for-business-analysis/ #Agilist.in #Agile #Change #Lean #Kanban #Scrum

How to See Your Leading, Lagging, and Reliable Estimation Metrics
https://www.jrothman.com/mpd/2026/05/how-to-see-your-leading-lagging-and-reliable-estimation-metrics/
#Progress #Agile

In a PI planning meeting working on story dependencies and I just want to shout into the void

🏴‍☠️🐻

#Agile #leadership #wednesday

»A Bit Too Far…« https://bobgalen.substack.com/p/a-bit-too-far #Agilist.in #Agile #Change #Lean #Kanban #Scrum

It’s always interesting to talk with others about what you can measure in agile teams and what actually makes sense! For example, I’m a fan of cycle time and opposed to velocity (especially when it’s used across team boundaries).

Cycle time is a nice, simple empirical metric. Velocity is based on gut feeling.

#agile #cycletime #velocity

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