Search results for tag #Scrum
![[?]](https://files.mastodon.social/accounts/avatars/112/342/617/510/979/081/original/8bb6c11cb1111c15.png)
Ein PDF verlinkt man nicht. Man schickt es rum, und drei Wochen später hat jeder eine andere Version.
Deshalb steht mein Buch jetzt komplett als Seiten im Netz. 34 Kapitel, jedes mit eigener URL, durchsuchbar, kostenlos, kein Formular, keine Mail-Adresse.
Wenn im nächsten Refinement wieder die Frage kommt, wer eigentlich entscheidet: Kapitel 11 verlinken statt eine Datei anzuhängen.
PDF und EPUB gibt es weiter.
![[?]](https://files.mastodon.social/accounts/avatars/116/172/258/484/767/755/original/762c6736dd89edfc.png)
Scrum nació mirando equipos flexibles. Terminó rodeado de ceremonias, tickets y adultos usando puntos de historia como si fueran física nuclear.
Contenido audiovisual generado íntegramente con IA.
![[?]](https://media.hachyderm.io/accounts/avatars/116/580/040/333/101/968/original/460dbb1a82fed4cd.jpg)
🎯 Setting your Sprint Goal as "finish all seven stories" misses the point.
A Sprint Goal is a single shared objective describing the purpose of the Sprint. "Finish the stories" says nothing about why the work matters. And it isn't imposed by the PO: the PO explains the business objective, the team negotiates what's feasible, and because everyone sets it, everyone owns it.
Struggling to set one is often a sign the business strategy underneath is unclear. Worth chasing, not skipping.
https://agilepainrelief.com/glossary/sprint-goal/?utm_source=mastodon&utm_campaign=archive-reshare
🎭 Too many Sprint Reviews are a Show and Tell: someone demos every corner of a feature while the room says "good job" and nothing substantive. The point is to increase engagement with stakeholders and users, and talking at people does the opposite.
Two fixes. Get key stakeholders (Marketing, Support) into Product Backlog Refinement so concerns surface early, not as an ambush in the Review. And replace Show and Tell with Show and Play: pair each developer with a user and let them actually use the product.
Nothing beats watching someone else use your app to see where they get confused.
⏱️ Shortly after ChatGPT 4o, people talked about doing Backlog Refinement in minutes with GenAI. Most have realized that's a bad idea.
Sprint Planning isn't about a tidy Sprint Backlog. It's the team building a shared understanding of the Sprint Goal, capacity, and how they'll get there. A faster event doesn't build that understanding, it skips it.
So don't ask how GenAI makes the event quicker. Ask how it helps the team spot what gets missed and go deeper. Stress-test the plan: yes. Write your Sprint Goal for you: no.
GenAI amplifies what you're already doing, good and bad.
@midzer schrieb, Scrum sei ein brutaler Scam, erfunden von Krawatten.
Ich halte den Satz für falsch. Die Wut dahinter für berechtigt.
Die meisten Devs, die agiles Arbeiten hassen, haben es nie erlebt. Sie kennen das Daily als Statusreport für den Chef und die Schätzung, aus der eine Deadline wird.
Ich hab fünf Jahre Scrum nach Lehrbuch gemacht und es sein lassen. Warum es trotzdem nicht an dir liegt:
https://no-bullshit-agile.de/es-liegt-nicht-an-dir-agiles-arbeiten-devs.html?mtm_campaign=mastodon
![[?]](https://mastodon.moscow/system/accounts/avatars/116/397/673/048/057/419/original/9d603921e10edc15.png)
Ретроспектива закончилась хорошим разговором, а договорённости снова потерялись? Попробуйте WRAP 🔄
Четыре зоны Worked, Room to improve, Actions и Plans помогают отделить наблюдения от решений, выбрать конкретные действия и встроить их в следующий рабочий цикл.
В статье разобрали, как провести WRAP за 55 минут, назначить владельцев и выбрать один-два эксперимента, к результатам которых команда вернётся на следующей встрече 🎯
Читайте и пробуйте на своей ретроспективе:
https://retropoint.ru/news/wrap-retrospective
#WRAP #Ретроспектива #Agile #Scrum #TeamLead #RetroPoint
🧱 I met a team where the client was the Product Owner. The backlog didn't make sense to them, they'd never seen a vision or strategy, and yet they wanted more features, faster, now.
The product looked like a Jenga tower about to topple.
Being a Product Owner is a craft: own the vision and strategy, order the backlog, understand users, security and usability, build a rhythm with the team. Clients usually just want to know it works.
So make your client a stakeholder, not the PO. A good PO solves the client's problem while holding the big picture, not just the next feature.
🛡️ Psychological safety is almost always misunderstood as something it isn't.
It isn't trust. We can trust each other and still not be safe. Edmondson's definition: "the belief that one will not be punished or humiliated for speaking up." Safety is knowing a mistake won't be held against you.
It isn't the absence of conflict either. Higher safety usually means more open disagreement, not less.
And it isn't a licence to point out everyone else's mistakes. It's about owning your own, and what you learned, without repercussions.
Get those three straight and a lot of "we tried it and it didn't work" makes sense.
![[?]](https://files.mastodon.social/accounts/avatars/109/248/158/793/719/138/original/8e2492a53f609e58.jpg)
Ein sehr sehr guter Text über "Code Review", der in Scrum Teams oft eine eigene Spalte auf dem Scrum Board darstellt.
Oft ein Diskussionsthema in Retrospektiven. Oft fühlt es sich nervig an. Jetzt kommt AI ins Team. Wie kann es helfen? Und warum machen wir das eigentlich alles nochmal?
https://newsletter.getdx.com/p/what-are-code-reviews-even-for
#AgileAI #Scrum #Agile #ScrumMaster #AgileCoach #Retrospektive #CodeReview
![[?]](https://files.mastodon.online/accounts/avatars/110/662/852/345/682/042/original/142c7afdf9675462.png)
🤖 Tools keep promising to automate the parts of Scrum that are entirely about human connection. It's worth naming why they miss.
One vendor replaces the Daily Scrum with scheduled text and video reports for admins. But the Daily Scrum exists to inspect progress toward the Sprint Goal, surface impediments, and plan the day together. An automated tool serves none of that. It has nothing to do with Scrum, except that it stole the language.
Same story for Retrospectives on autopilot from survey submissions. Grouping exercises exist to start a conversation about how problems connect; hand that to AI and you've replaced the human insight that was the whole point.
Data collection and note-taking can help. Replacing the conversation doesn't.
![[?]](https://files.mastodon.social/accounts/avatars/116/681/513/686/348/267/original/97b0f4952cc8e138.png)
Why Sprint Reviews Fail — and How to Fix Them
Three anti-patterns: Demo Rehearsal, Passive Audience, Backlog Black Hole. The sprint review is the highest-leverage activity in Scrum.
#Scrum #Agile #SprintReview #SoftwareEngineering
![[?]](https://media.beige.party/accounts/avatars/113/034/207/135/364/238/original/40e16639091d4a5e.jpeg)
Just a feeling, but I think there might be a slight disconnect between the sales team and our delivery teams. Managing expectations is a vital skill
I'm always on Team Yellow! 👨💻
#EnterpriseIT #Outsourcing #Agile #Scrum #ScrumTeam #dev #developer #coding #IT
Alt...
Two-pane photo. On top, a generic stock photo of a smiling, energetic, young and sharply dressed business team in a white void.
Text: "Our highly skilled and motivated team, as communicated by Sales."
Below, in a similar void, a collection of minions looking proper confused. Two are seemingly discussing what to do about a light bulb hanging from the ceiling.
Text: "Our actual delivery team, rolling in on Day 1 of the multi-year contract."
🧭 Drowning in an oversized Product Backlog? A Story Map is a good life raft. When a backlog is hundreds of items in a flat list, nobody can see the product, only the pile.
Lay it out as a journey instead: major steps across the top, the stories that belong under each. Duplicates line up, whole regions turn out to be features nobody will build, and the gaps become obvious.
Jeff Patton built this because flat backlogs lose the Product Vision.
https://agilepainrelief.com/glossary/story-mapping/?utm_source=mastodon&utm_campaign=archive-reshare
Kein Board hat eine Spalte "warten auf Entscheidung" obwohl das der längste Wartezustand im System ist.
Wir messen Cycle Time und Lead Time. Die Wochen zwischen "Signal gesehen" und "verbindlich entschieden" messen wir nie.
Ein Team, das alle 2 Wochen liefert, aber im Quartalsgremium auf Priorisierung wartet, ist nicht agil. Nur schnell im falschen Takt.
https://no-bullshit-agile.de/nbak12-decision-latency-unsichtbarer-engpass.html?mtm_campaign=mastodon
#Agile #Scrum #Kanban #SoftwareDevelopment
Alt...
NBAK12: Decision Latency. Der unsichtbare Engpass
🚧 Cross-functional teams are not departments. A department is organized by role: the dev group here, QA down the hall. A cross-functional team is organized around the work, from the moment a feature is considered until it's delivering value.
The difference shows up as waiting. Depend on an outside group and you wait for your work to reach the top of their list. Inside a cross-functional team, far less work has to happen elsewhere.
🧩 Going from 2 people to 4 doesn't double what a team gets done, and Amdahl's Law explains why: some work happens in parallel, but the serial part sets a ceiling no headcount can lift.
Speed doesn't come from throwing more people at the job. With teams of 9 or larger, I split into two: separate teams of 4 and 5 reliably get more done than the original.
Is your team sized for looking busy, or for reaching Done every Sprint?
https://agilepainrelief.com/blog/scrum-team-size/?utm_source=mastodon&utm_campaign=archive-reshare
🗂️ Product Backlog Refinement has a quiet failure mode: everyone nods that they understand the item, yet each person holds a different picture. It looks like agreement, but the gap surfaces mid-Sprint.
When you're stuck on a feature, write an example: a pencil sketch of the interface, or a quick happy path. Just enough detail to get everyone on the same page.
The goal isn't a tidy backlog. It's a team holding the same picture.
Ich schreibe hier über agiles Arbeiten. Über manches kann ich nicht schreiben, weil ich es nicht erlebt habe.
SAFe von innen. Der Alltag als Scrum Master. Agiles Arbeiten als Tester. Agil außerhalb der Softwareentwicklung.
Schreib einen Gastbeitrag bei mir.
Kein Wortlimit, kein Konzept, kein SEO. Eine Erfahrung in eine Mail getippt reicht. Struktur und Formatierung mache ich. Autorenbox mit deinen Links gibt's dazu.
Boost, please!
https://no-bullshit-agile.de/ich-habe-luecken-du-hast-erfahrung.html
Alt...
Ich schreibe hier über agiles Arbeiten. Über manches kann ich nicht schreiben, weil ich es nicht erlebt habe.
SAFe von innen. Der Alltag als Scrum Master. Agiles Arbeiten als Tester. Agil außerhalb der Softwareentwicklung.
Schreib einen Gastbeitrag bei mir.
![[?]](https://media.mas.to/accounts/avatars/109/296/442/707/229/247/original/7b1ee8b9aec68d1e.png)
Scrum Isn’t for Stormtroopers, by (not on Mastodon or Bluesky):
https://www.scrum.org/resources/blog/scrum-isnt-stormtroopers?ref=frontenddogma.com
#scrum #agile #engineeringmanagement #productmanagement #concepts
![[?]](https://friends.librescrum.org/system/accounts/avatars/108/476/351/362/026/785/original/2dc25be415e8a90d.png)
what a nice start today to appear on the same page with @JuttaEckstein and
@karen
i assume we were always on the same page. and now visible to anyone 🥰
i am in for healthy ai usage: planet, humans and software.
its new to me to go into "action research" within @haufegroup . will keep you posted.
Alt...
chris and barry with a crowd in a liberating structure setting
photo by lisanne lentink
Neulich im Daily: Es geht reiherum, jeder spricht 90 Sekunden ins Leere,
keiner hört zu. Am Ende weiß genau einer mehr als vorher: der Chef.
Ein Daily ist kein Status-Report. Sobald es einer wird, optimiert jeder
seine eigene Zeile statt den Fluss der Arbeit. Zu Recht hasst ihr das Ding.
Es gibt eine Variante, in der die 15 Minuten wirklich was bewegen. Die
redet nicht über Menschen, sondern über Tickets.
https://no-bullshit-agile.de/warum-daily-standups-oft-scheitern-und-wie-man-sie-wiederbelebt.html
Хотите посмотреть RetroPoint в работе до регистрации? Теперь это можно сделать за один клик 🚀
Мы запустили заполненный демо-режим. Внутри уже есть ретро-доски с карточками и Action Items, OKR и SWOT, встречи 1‑2‑1, Performance Review, Planning Poker, команды, отпуска и дни рождения.
Можно открыть доски, изучить реальные сценарии работы команды, посмотреть графики прогресса и попробовать интерфейс голосования 🃏
Демо доступно без регистрации и оплаты. Данные защищены от изменений, поэтому можно смело исследовать продукт. А когда захотите попробовать самостоятельно, создайте обычный аккаунт прямо из демо ✨
#RetroPoint #Ретроспектива #УправлениеКомандой #Agile #Scrum #OKR #PlanningPoker #Тимлид #УдаленнаяКоманда
RE: https://mastodon.social/@Berufebilder/116990885908664913
Ein Artikel über agile Kommunikation, bei dem das Scrum-Board-Beispiel im falschen Kapitel steht.
Kernthese: bessere Kommunikation = mehr Innovation. Kein Wort davon, dass schlechte Kommunikation meist Symptom ist für kaputte Feedback-Schleifen und unklare Verantwortung.
Stattdessen: Trainings gegen Hierarchiedenken. Ein Miro-Link gegen Missverständnisse.
Genau das Muster. An der Oberfläche schrauben.
Wie jeden Montag: Eine sehr gute "Presseschau".
#Scrum #Agile #AgileCoach #ScrumMaster
#LINKSDERWOCHE | 30/2026: Produktivität, Lean, Agile, Mangement und Leadership
Photo by Pixabay on Pexels.com
PRODUKVITIÄT
Obsidian | Callouts farblich gestalten
Eine Funktion, die ich in Obsidian bisher noch nicht genutzt habe, ist durch einen Blogartikel von Thomas Mathoi wieder in meinen Fokus gerückt: Callouts. Offenbar gibt es so etwas wie einen „Callout-Manager”, mit dem sich die Callouts farblich variieren lassen. Das ist sicherlich für den einen oder anderen interessant. Ich selbst weiß noch nicht, ob und wie ich diese Möglichkeit künftig nutzen werde.
https://www.mathoi.at/2026/07/22/obsidian-kaizen-der-callout-manager/
Statt Bequemlichkeit | Tue, was den Unterschied macht
Dan Rockwell wirft einen interessanten Ansatz in den Raum. Nicht das, was uns glücklich macht, sollte in den Fokus gestellt werden, sondern das, was uns voranbringt. Das klingt naheliegend. Eigentlich. Aber seien wir ehrlich: Wir suchen doch immer zuerst nach dem „Glück” und dem, was uns „Spaß” macht. Zumindest legen das viele Ratschläge immer wieder nahe. Rockwell sagt jedoch, dass das, was den Unterschied macht, viel relevanter ist. Ich würde ergänzen, dass dort der Schlüssel zur langfristigen, gesunden Zufriedenheit liegt. Glück ist flüchtig. Zufriedenheit macht träge. Etwas zu finden, das den Unterschied macht und von dem man überzeugt ist, dass es einen voranbringt, ist nicht immer bequem, hält uns aber in Bewegung.
https://leadershipfreak.blog/2026/07/24/do-what-makes-you-unhappy/
Gefühl der Einsamkeit | Ein nachdenklicher Impuls
Der Blogartikel von Uwe Hauck lässt mich nachdenklich zurück. Ein bisschen erkenne ich mich selbst darin wieder. Spezialthemen, die nur wenige interessieren – das kommt mir bekannt vor. Wenn auch die thematische Schnittmenge eine etwas andere ist. Auch ich habe gemerkt, wie wichtig soziale Kontakte sind, und nehme daher regelmäßig an Veranstaltungen wie dem Europa-Stammtisch, Meet and Talk von Wir in Weinsberg und ähnlichen Events teil. Viele Freunde und Bekannte, die meine Interessen teilen, leben übrigens oft 100 km weit weg von meinem Wohnort. Mit nur wenigen Menschen im Umkreis von 50 km habe ich einen sehr intensiven Kontakt, der unter die Rubrik „echte Freundschaft” fällt. Glücklicherweise kämpfe ich nicht gegen eine Angststörung. Das macht es etwas einfacher. Aber auch bei mir kommt gelegentlich das Gefühl der Einsamkeit hoch, wenn Gespräche mit Tiefgang fehlen und der Austausch im Alltag nur an der Oberfläche kratzt.
https://www.livingthefuture.de/2026/07/19/alleine-ist-ein-zustand-einsam-ein-gefuehl/
LEAN
Standardisierung und Kaizen | Gute Standards sind lebendig
In seinem Blogartikel beschreibt Mark Graban ein Thema, das ich in ähnlicher Form auch immer wieder aufgreife: Standards. Ich verstehe Standards als „fluid” und adaptiv. Es sind gut bestätigte Arbeitshypothesen, die so lange gültig sind, bis wir eine bessere finden. Ganz simpel und einfach. Sie entwickeln sich beständig weiter. Ganz im Sinne von Kaizen. Allerdings erlebe ich immer wieder, dass Standards nicht reflektiert oder hinterfragt werden – geschweige denn angepasst. Einmal definiert, gelten sie, bis das Römische Reich untergeht. Das ist in meinen Augen unsinnig. In eine ähnliche Kerbe schlägt auch der Beitrag.
https://www.leanblog.org/2026/07/standardized-work-and-kaizen-toyota
AGILE
Prototypentest | Feedback Capture Grids nutzen
Im Scamper-Blog von Lars Richter bin ich auf einen Ansatz gestoßen, der mich stark an ein Format erinnert, das wir gerne in Team-Retros verwenden. Der Unterschied ist, dass er es im Kontext von Prototypentesting nutzt. Eigentlich naheliegend. Das Feedback Capture Grid ist ein einfaches Raster, das sich leicht abbilden lässt und fast selbsterklärend ist. Es liegt also nahe, es auch tatsächlich als Feedback-Werkzeug für das Prototypentesten zu nutzen.
https://scamper.blog/feedback-capture-grid
Impediments | Einordnung der Impediments auf einer Wirkungspyramide
Als ich den Blogartikel von Dominik Maximini gesehen habe, bin ich im ersten Moment innerlich etwas zusammengezuckt. Eine Pyramide der Impediements? Glücklicherweise hat er direkt klargestellt, dass es nicht darum geht, dass Teams eine Stufe nach der anderen durchlaufen – in dem Fall hätte ich den Beitrag nicht einmal erwähnt – sondern dass es sich um eine Einordnungshilfe handelt, die dabei helfen soll, Hindernisse zu kategorisieren. Das macht die Sache für mich interessanter. Die Hauptunterscheidung liegt in den Einflussebenen „Team” oder „Organisation”, also wo kann ich den Hebel ansetzen, um Wirkung zu erzielen? Diese beiden Hauptebenen differenziert er in Unterkategorien, die in einer „Wirksamkeitspyramide” münden. Die Darstellung finde ich persönlich zwar nicht optimal, dennoch kann ich inhaltlich gut folgen. Denn tatsächlich sind viele Impediments struktureller Art und es hilft herzlich wenig, an einem Team „herumzudoktern”. Solche Fälle durfte ich im Leben auch schon oft genug erleben. Das Team war top, konnte aber wegen struktureller Probleme an den Schnittstellen innerhalb der Organisation – beispielsweise entlang der Wertstromkette, in die es eingebunden war – sein Potenzial nicht nutzen.
https://www.scrum.org/resources/blog/pyramid-impediments
Agile Rolle | Gute Arbeit, die unsichtbar bleibt
In den letzten Monaten hatte ich den Eindruck, dass massenweise Agile Coaches, Scrum Master:innen, Kanban Coaches und Ähnliches nach neuen Jobs Ausschau gehalten haben, weil ihre Stellen in Unternehmen wegrationalisiert worden sind. Das Problem bei diesen Rollen ist, dass die Leistung der Inhaber:innen nicht direkt bezifferbar ist und somit oft unklar ist, welchen Mehrwert die Rolle hat. Marc Löffler greift genau dieses Thema unter dem Titel „Gute Arbeit, die keiner sieht, sieht aus wie gar keine Arbeit” auf. Ich würde behaupten, dass dies für jede Form echter und guter Führungsarbeit gilt. Selbst wenn man seinem Vorschlag folgt, braucht es immer noch eine Referenz, um die Sichtbarkeit durch einen Vergleich herzustellen, was in der Praxis weiterhin schwierig bleiben dürfte.
https://passionateteams.com/e/gute-arbeit-die-keiner-sieht-sieht-aus-wie-gar-keine-arbeit
Velocity | Die kognitiven Fallen der Velocity
Die gute alte Velocity ist nach wie vor ein Dauerbrenner, wie es scheint. Noch einmal: Sie misst den Durchsatz und ist somit eine Kennzahl für das Team, mit der sich dessen spezifische Geschwindigkeit ermitteln lässt. Ein Vergleich mit anderen Teams ist jedoch nicht möglich, da er auf relationellen Schätzungen basiert. Sie ist aber sicherlich nicht die einzige Kennzahl, mit der man arbeiten und auf die man sich verlassen sollte. Chuck Suscheck verdeutlicht gut, weshalb dem so ist, denn hier lauern auch einige kognitive Fallen, die zu Fehlschlüssen verleiten könnten.
https://www.scrum.org/resources/blog/cognitive-trap-velocity-misinterpretation
Scheitern | Weshalb „kontrolliertes“ Scheitern für das Lernen von Bedeutung ist
Auf den ersten Blick mag der Titel „Wann Scrum Master Teams bewusst scheitern lassen sollten” von Niklas Magerl etwas seltsam klingen. Zusammengefasst geht es jedoch nicht um das Scheitern an sich, sondern um „Risikomanagement” im Hinblick auf Experimente, die die Lernerfahrung des Teams stärken sollen. Es geht also um ein kontrolliertes „Scheitern“ mit dem Ziel, die Lernerfahrung zu intensivieren. Das ist naheliegend, denn Scheitern gehört zum Geschäft, wenn wir explorativ unterwegs sind und Lösungen erkunden. Wir müssen ja erst herausfinden, was der richtige Weg ist. Versuch und Irrtum gehören dazu. Das Ganze jedoch auf Risikomanagement zu reduzieren, würde zu kurz greifen. Ein durchaus lesenswerter Ansatz.
https://t2informatik.de/blog/scrum-master-teams-scheitern-lassen-sollten/
Scrum ohne Manager? | Auch selbstorganisierte Teams brauchen Führung
Ein hartnäckiger Mythos ist, dass selbstorganisierte Teams ohne Führung auskommen und man daher keine Führungskräfte mehr braucht. Das artet gerne auch mal so aus, dass behauptet wird, das Team sei selbstorganisiert und solle deshalb alles selbst entscheiden, wobei das Team dann im Stich gelassen wird. Nein, die Führung und das Management haben auch bei selbstorganisierten Teams nicht ausgedient. Die meisten Teams sind operative Teams. Sie sind auf operativer Flughöhe unterwegs. Für den ganzen taktischen, strategischen „Kram” haben sie nur bedingt Kapazitäten – und hier kommt unter anderem die Führung ins Spiel. Nur um ein Beispiel zu geben. Es ist auch ein weitverbreitetes Missverständnis, dass Scrum Master (und oft auch Product Owner) keine Führungskräfte sind. Sie sind genau das. Dazu passt, dass Mary Iqbal der Frage nachgeht, ob es in Scrum keine „Manager” gibt.
https://www.scrum.org/resources/blog/no-manager-scrum
LEADERSHIP UND MANAGEMENT
Führung braucht Ausbildung | Führungskräfte oft nicht auf Führungsaufgabe vorbereitet
Bei vielen Führungskräften lässt sich feststellen, dass sie nicht darauf vorbereitet wurden, Führungskraft zu werden. Mit etwas Glück bringen sie Vorerfahrung mit, sind hochgradig selbstreflektiert und bereiten sich daher selbst auf ihre Aufgabe vor. Dennoch ist meine Beobachtung nach wie vor, dass man sie viel zu oft im Stich lässt und sie nicht auf ihre Aufgabe vorbereitet. Eine Beobachtung, die Jan Fischbach zu teilen scheint. Er plädiert dafür, dass Führungskräfte eine „Ausbildung” benötigen. Führen will gelernt sein. Und da stimme ich ihm zu. Da ist nach wie vor viel Luft nach oben.
https://www.teamworkblog.de/2026/07/fuhrungskrafte-brauchen-eine-ausbildung.html
#Agile #Führung #Impediments #Kaizen #Leadership #Lean #Mangement #Obsidian #Produktivität #Prototypentest #Scheitern #Scrum #Standardisierung
![[?]](https://tomsgedankenblog.social/wp-content/uploads/2022/10/cropped-wp-1666202986272-4.jpg)
#LINKSDERWOCHE | 30/2026: Produktivität, Lean, Agile, Mangement und Leadership
Photo by Pixabay on Pexels.com
PRODUKVITIÄT
Obsidian | Callouts farblich gestalten
Eine Funktion, die ich in Obsidian bisher noch nicht genutzt habe, ist durch einen Blogartikel von Thomas Mathoi wieder in meinen Fokus gerückt: Callouts. Offenbar gibt es so etwas wie einen „Callout-Manager”, mit dem sich die Callouts farblich variieren lassen. Das ist sicherlich für den einen oder anderen interessant. Ich selbst weiß noch nicht, ob und wie ich diese Möglichkeit künftig nutzen werde.
https://www.mathoi.at/2026/07/22/obsidian-kaizen-der-callout-manager/
Statt Bequemlichkeit | Tue, was den Unterschied macht
Dan Rockwell wirft einen interessanten Ansatz in den Raum. Nicht das, was uns glücklich macht, sollte in den Fokus gestellt werden, sondern das, was uns voranbringt. Das klingt naheliegend. Eigentlich. Aber seien wir ehrlich: Wir suchen doch immer zuerst nach dem „Glück” und dem, was uns „Spaß” macht. Zumindest legen das viele Ratschläge immer wieder nahe. Rockwell sagt jedoch, dass das, was den Unterschied macht, viel relevanter ist. Ich würde ergänzen, dass dort der Schlüssel zur langfristigen, gesunden Zufriedenheit liegt. Glück ist flüchtig. Zufriedenheit macht träge. Etwas zu finden, das den Unterschied macht und von dem man überzeugt ist, dass es einen voranbringt, ist nicht immer bequem, hält uns aber in Bewegung.
https://leadershipfreak.blog/2026/07/24/do-what-makes-you-unhappy/
Gefühl der Einsamkeit | Ein nachdenklicher Impuls
Der Blogartikel von Uwe Hauck lässt mich nachdenklich zurück. Ein bisschen erkenne ich mich selbst darin wieder. Spezialthemen, die nur wenige interessieren – das kommt mir bekannt vor. Wenn auch die thematische Schnittmenge eine etwas andere ist. Auch ich habe gemerkt, wie wichtig soziale Kontakte sind, und nehme daher regelmäßig an Veranstaltungen wie dem Europa-Stammtisch, Meet and Talk von Wir in Weinsberg und ähnlichen Events teil. Viele Freunde und Bekannte, die meine Interessen teilen, leben übrigens oft 100 km weit weg von meinem Wohnort. Mit nur wenigen Menschen im Umkreis von 50 km habe ich einen sehr intensiven Kontakt, der unter die Rubrik „echte Freundschaft” fällt. Glücklicherweise kämpfe ich nicht gegen eine Angststörung. Das macht es etwas einfacher. Aber auch bei mir kommt gelegentlich das Gefühl der Einsamkeit hoch, wenn Gespräche mit Tiefgang fehlen und der Austausch im Alltag nur an der Oberfläche kratzt.
https://www.livingthefuture.de/2026/07/19/alleine-ist-ein-zustand-einsam-ein-gefuehl/
LEAN
Standardisierung und Kaizen | Gute Standards sind lebendig
In seinem Blogartikel beschreibt Mark Graban ein Thema, das ich in ähnlicher Form auch immer wieder aufgreife: Standards. Ich verstehe Standards als „fluid” und adaptiv. Es sind gut bestätigte Arbeitshypothesen, die so lange gültig sind, bis wir eine bessere finden. Ganz simpel und einfach. Sie entwickeln sich beständig weiter. Ganz im Sinne von Kaizen. Allerdings erlebe ich immer wieder, dass Standards nicht reflektiert oder hinterfragt werden – geschweige denn angepasst. Einmal definiert, gelten sie, bis das Römische Reich untergeht. Das ist in meinen Augen unsinnig. In eine ähnliche Kerbe schlägt auch der Beitrag.
https://www.leanblog.org/2026/07/standardized-work-and-kaizen-toyota
AGILE
Prototypentest | Feedback Capture Grids nutzen
Im Scamper-Blog von Lars Richter bin ich auf einen Ansatz gestoßen, der mich stark an ein Format erinnert, das wir gerne in Team-Retros verwenden. Der Unterschied ist, dass er es im Kontext von Prototypentesting nutzt. Eigentlich naheliegend. Das Feedback Capture Grid ist ein einfaches Raster, das sich leicht abbilden lässt und fast selbsterklärend ist. Es liegt also nahe, es auch tatsächlich als Feedback-Werkzeug für das Prototypentesten zu nutzen.
https://scamper.blog/feedback-capture-grid
Impediments | Einordnung der Impediments auf einer Wirkungspyramide
Als ich den Blogartikel von Dominik Maximini gesehen habe, bin ich im ersten Moment innerlich etwas zusammengezuckt. Eine Pyramide der Impediements? Glücklicherweise hat er direkt klargestellt, dass es nicht darum geht, dass Teams eine Stufe nach der anderen durchlaufen – in dem Fall hätte ich den Beitrag nicht einmal erwähnt – sondern dass es sich um eine Einordnungshilfe handelt, die dabei helfen soll, Hindernisse zu kategorisieren. Das macht die Sache für mich interessanter. Die Hauptunterscheidung liegt in den Einflussebenen „Team” oder „Organisation”, also wo kann ich den Hebel ansetzen, um Wirkung zu erzielen? Diese beiden Hauptebenen differenziert er in Unterkategorien, die in einer „Wirksamkeitspyramide” münden. Die Darstellung finde ich persönlich zwar nicht optimal, dennoch kann ich inhaltlich gut folgen. Denn tatsächlich sind viele Impediments struktureller Art und es hilft herzlich wenig, an einem Team „herumzudoktern”. Solche Fälle durfte ich im Leben auch schon oft genug erleben. Das Team war top, konnte aber wegen struktureller Probleme an den Schnittstellen innerhalb der Organisation – beispielsweise entlang der Wertstromkette, in die es eingebunden war – sein Potenzial nicht nutzen.
https://www.scrum.org/resources/blog/pyramid-impediments
Agile Rolle | Gute Arbeit, die unsichtbar bleibt
In den letzten Monaten hatte ich den Eindruck, dass massenweise Agile Coaches, Scrum Master:innen, Kanban Coaches und Ähnliches nach neuen Jobs Ausschau gehalten haben, weil ihre Stellen in Unternehmen wegrationalisiert worden sind. Das Problem bei diesen Rollen ist, dass die Leistung der Inhaber:innen nicht direkt bezifferbar ist und somit oft unklar ist, welchen Mehrwert die Rolle hat. Marc Löffler greift genau dieses Thema unter dem Titel „Gute Arbeit, die keiner sieht, sieht aus wie gar keine Arbeit” auf. Ich würde behaupten, dass dies für jede Form echter und guter Führungsarbeit gilt. Selbst wenn man seinem Vorschlag folgt, braucht es immer noch eine Referenz, um die Sichtbarkeit durch einen Vergleich herzustellen, was in der Praxis weiterhin schwierig bleiben dürfte.
https://passionateteams.com/e/gute-arbeit-die-keiner-sieht-sieht-aus-wie-gar-keine-arbeit
Velocity | Die kognitiven Fallen der Velocity
Die gute alte Velocity ist nach wie vor ein Dauerbrenner, wie es scheint. Noch einmal: Sie misst den Durchsatz und ist somit eine Kennzahl für das Team, mit der sich dessen spezifische Geschwindigkeit ermitteln lässt. Ein Vergleich mit anderen Teams ist jedoch nicht möglich, da er auf relationellen Schätzungen basiert. Sie ist aber sicherlich nicht die einzige Kennzahl, mit der man arbeiten und auf die man sich verlassen sollte. Chuck Suscheck verdeutlicht gut, weshalb dem so ist, denn hier lauern auch einige kognitive Fallen, die zu Fehlschlüssen verleiten könnten.
https://www.scrum.org/resources/blog/cognitive-trap-velocity-misinterpretation
Scheitern | Weshalb „kontrolliertes“ Scheitern für das Lernen von Bedeutung ist
Auf den ersten Blick mag der Titel „Wann Scrum Master Teams bewusst scheitern lassen sollten” von Niklas Magerl etwas seltsam klingen. Zusammengefasst geht es jedoch nicht um das Scheitern an sich, sondern um „Risikomanagement” im Hinblick auf Experimente, die die Lernerfahrung des Teams stärken sollen. Es geht also um ein kontrolliertes „Scheitern“ mit dem Ziel, die Lernerfahrung zu intensivieren. Das ist naheliegend, denn Scheitern gehört zum Geschäft, wenn wir explorativ unterwegs sind und Lösungen erkunden. Wir müssen ja erst herausfinden, was der richtige Weg ist. Versuch und Irrtum gehören dazu. Das Ganze jedoch auf Risikomanagement zu reduzieren, würde zu kurz greifen. Ein durchaus lesenswerter Ansatz.
https://t2informatik.de/blog/scrum-master-teams-scheitern-lassen-sollten/
Scrum ohne Manager? | Auch selbstorganisierte Teams brauchen Führung
Ein hartnäckiger Mythos ist, dass selbstorganisierte Teams ohne Führung auskommen und man daher keine Führungskräfte mehr braucht. Das artet gerne auch mal so aus, dass behauptet wird, das Team sei selbstorganisiert und solle deshalb alles selbst entscheiden, wobei das Team dann im Stich gelassen wird. Nein, die Führung und das Management haben auch bei selbstorganisierten Teams nicht ausgedient. Die meisten Teams sind operative Teams. Sie sind auf operativer Flughöhe unterwegs. Für den ganzen taktischen, strategischen „Kram” haben sie nur bedingt Kapazitäten – und hier kommt unter anderem die Führung ins Spiel. Nur um ein Beispiel zu geben. Es ist auch ein weitverbreitetes Missverständnis, dass Scrum Master (und oft auch Product Owner) keine Führungskräfte sind. Sie sind genau das. Dazu passt, dass Mary Iqbal der Frage nachgeht, ob es in Scrum keine „Manager” gibt.
https://www.scrum.org/resources/blog/no-manager-scrum
LEADERSHIP UND MANAGEMENT
Führung braucht Ausbildung | Führungskräfte oft nicht auf Führungsaufgabe vorbereitet
Bei vielen Führungskräften lässt sich feststellen, dass sie nicht darauf vorbereitet wurden, Führungskraft zu werden. Mit etwas Glück bringen sie Vorerfahrung mit, sind hochgradig selbstreflektiert und bereiten sich daher selbst auf ihre Aufgabe vor. Dennoch ist meine Beobachtung nach wie vor, dass man sie viel zu oft im Stich lässt und sie nicht auf ihre Aufgabe vorbereitet. Eine Beobachtung, die Jan Fischbach zu teilen scheint. Er plädiert dafür, dass Führungskräfte eine „Ausbildung” benötigen. Führen will gelernt sein. Und da stimme ich ihm zu. Da ist nach wie vor viel Luft nach oben.
https://www.teamworkblog.de/2026/07/fuhrungskrafte-brauchen-eine-ausbildung.html
#Agile #Führung #Impediments #Kaizen #Leadership #Lean #Mangement #Obsidian #Produktivität #Prototypentest #Scheitern #Scrum #Standardisierung
4 days in, #AgileConfessions has some gems:
"I misused the daily as a status report."
"I thought agile meant finishing tickets fast so I could change the plan anytime."
"Endless upfront plans, until I learned to run experiments."
Your turn: the most anti-agile thing you've done, and what it taught you. Any language, just tag #AgileConfessions.
#softwaredevelopment #agile #scrum #kanban
Alt...
Agile Confession
![[?]](https://cdn.masto.host/mastodonie/accounts/avatars/109/287/644/790/067/714/original/5e277c239abea519.jpg)
![[?]](https://media.hachyderm.io/accounts/avatars/109/376/561/571/647/114/original/e013b8d04db5434e.jpeg)
JiraMetrics v3.0 is out.
It's a free, open-source command-line tool that turns your Jira history into agile metrics charts (cycle time, aging WIP, throughput, and more) in one self-contained HTML report. Useful for any team that wants to understand and improve its delivery flow.
A major release because it now requires Ruby 3.4 (or JRuby 10) and removes long-deprecated features.
Full change log at https://jirametrics.org/changes/
#agile #jira #flowmetrics #kanban #scrum
Alt...
The label JiraMetrics in the centre, on top of four quadrants, each with its own graph. Top left shows estimates against actual time elapsed, top right is a cycle time scatterplot, bottom right is work in progress by day, bottom left, is a throughput chart.
🗂️ Product Backlog Refinement is where the whole Scrum Team prepares the backlog for the next few Sprints: adding items, breaking down big ones, sharing prioritization reasoning, deleting what no longer matters.
Most of that is conversation, not paperwork. The value is the shared understanding. That's why GenAI won't speed it up, and shouldn't.
What does your team treat as paperwork here?
🤝 Building a Working Agreement? The ScrumMaster coaches, not leads. Canvass the team first on what matters: Daily Scrum time, respect, phones, equal voice.
Start with a check-in, then use a format where every voice is heard (I like 1-2-4 with the Decider Protocol). When someone says no, they suggest something better.
Every few Sprints, ask: is this still our Working Agreement?
🚦 Most teams treat Definition of Ready as a checklist to enforce. Hold it lightly instead.
If items get stuck mid-Sprint, a Definition of Ready can help, but only cover the details actually causing problems now. As the team matures, make it thinner. The failure mode: it becomes a dumping ground for every little problem the team ever had.
Does your "Ready" gate reduce delay, or just hide it earlier?
📋 The Product Backlog is an ordered list of the work the Product Owner wants the team to tackle next. The trouble starts when it stops being ordered and turns into a dumping ground.
When everything is "high priority", nothing is, and the list becomes a graveyard of ideas nobody will build. A deep backlog is well understood near the top and deliberately vague further down.
When did you last delete a backlog item?
#LINKSDERWOCHE | 29/2026: Produktivität, Lean, Agile, Politik und Gesellschaft, Satire
PRODUKTIVITÄT
KI im Alltag | Nur weil es technisch möglich ist, ist es noch lange nicht gut
Nicht alles, was technisch möglich ist, ist auch sinnvoll oder wünschenswert. Das scheinen viele KI-Enthusiasten gerne zu vergessen. Daher spricht mir Michael Schenkel in seinem Blogartikel regelrecht aus dem Herzen. Es ist übrigens kein neues Muster, das wir hier erleben. Ich habe in den Tiefen meines Gedächtnisses nach Beispielen gesucht, bei denen übertriebene Technikgläubigkeit zu Desastern geführt hat. Mir sind auf Anhieb neben der Titanic und zwei gescheiterten Polarexpeditionen noch viele weitere Beispiele bewusst geworden. Und dabei habe ich noch nicht einmal tief gewühlt. Das Ganze führt mir vor Augen, dass bei aller Begeisterung für neue Ideen der bewusste, kritisch reflektierte Umgang extrem wichtig ist. Offensichtlich ist der Mensch nicht in der Lage, aus der Geschichte zu lernen (was man übrigens auch im Umgang mit der Nicht-Alternative in einem anderen Kontext erleben und lernen darf). Falls sich jetzt jemand fragt, weshalb ich das Thema unter Produktivität verlinke: Ich sehe die Fähigkeit zur Selbstreflexion und den kritischen Umgang mit KI in erster Linie bei uns als Individuen. Wir entscheiden, ob wir unsere und die Zeit unserer Mitmenschen mit sinnlosen Aktionen „verschwenden”.
https://t2informatik.de/blog/technisch-moeglich-inhaltlich-zweifelhaft/
Erfolg und Demut | Sich trotz Erfolg in Demut zu üben erdet
In seinem Blogbeitrag erinnert Dan Rockwell daran, dass Erfolg sehr flüchtig sein kann und wir uns daher – bei allem Erfolg – in Demut üben sollten. Damit trifft er bei mir einen Nerv (was die Leser meiner „Gedankenblitze” vermutlich schon wissen). Ich halte es für sehr essentiell, sich immer wieder bewusst zu machen, dass Erfolg auch etwas mit „Zufall”, der Mitwirkung anderer Menschen sowie beständiger Reflexion und Lernen zu tun hat. Erfolg ist flüchtig und kann schnell kippen. Besonders, wenn wir uns in unserem Erfolg baden und in Arroganz abdriftet.
https://leadershipfreak.blog/2026/07/16/the-unexpected-blunder/
Schreiben | Schreiben hilft beim Denken, Strukturieren und schafft Verbindungen.
Ich habe es endlich geschafft, eine Folge von Anna Koschinskis Podcast „Verbindungen schaffen” anzuhören. Im Fokus steht das Schreiben von Texten. Ich weiß, wie schwer es ist und wie viel Überwindung es kostet. Mein schriftstellerisches Talent würde ich nicht gerade als herausragend bezeichnen, und dann muss man auch noch ein Thema finden. Nach langer Übung bin ich da etwas entspannter geworden. Mir hilft das Aufschreiben beim Reflektieren. Ich notiere meine Gedanken sehr häufig, meist in Obsidian. Dadurch erhalte ich mehr Klarheit. Wenn dann mal etwas herauskommt, von dem ich denke, dass es eine sinnvolle Reife erreicht hat, entsteht daraus öfter mal ein Gedankenblitz oder noch besser ein Beitrag für den Blog des Forums Agile Verwaltung. Gut, ich schreibe nicht mit einer „professionellen” Zielsetzung. Toms Gedankenblog dient in erster Linie der eigenen Reflexion und der „verrückten” Idee, mit Gleichgesinnten in Austausch zu treten. Das ist etwas anderes. Hört einfach mal rein. Es ist auf jeden Fall hilfreich, auch wenn man selbst nicht regelmäßig Texte produzieren muss. Schreiben ist Denken und Strukturieren. Das hilft in vielen anderen Kontexten ebenso.
https://verbindung-schaffen.podigee.io/74-verbindung-schreiben
Vom Wissen zur Umsetzung | Wie wir es schaffen, Erkenntnisse in die Umsetzung zu bringen
Ivan Blatter schafft es immer wieder, dass ich mich beim Hören seines Podcasts ertappt fühle. 😉 So auch bei der aktuellen Folge, in der es darum geht, wie wir unser neu erworbenes Wissen umsetzen. Die Erkenntnis zu haben, ist zwar der erste Schritt. Von der Erkenntnis in die Umsetzung zu kommen, ist allerdings oft viel herausfordernder, denn jede Erkenntnis bedeutet auch, an unseren Gewohnheiten zu arbeiten. Neue Erkenntnisse und neues Wissen in die Praxis umzusetzen, ist eben nicht ganz so einfach.
https://share.transistor.fm/s/c986b589
LEAN
Umgang mit Fehlern | Echte Verantwortungsübenahme ist der Schlüssel
Mark Graban bringt es auf den Punkt. Gute Führung sucht nicht nach Schuldigen, sondern übernimmt Verantwortung. Sie erkundet, wo im System Ursachen für Fehler und Probleme schlummern, und versucht, diese zu beheben. In meiner beruflichen Vergangenheit habe ich immer wieder die Erfahrung gemacht, dass nach einem Fehler ein Schuldiger gesucht und verantwortlich gemacht wurde. Damit war die Sache dann erledigt. Und was für eine Überraschung – der Fehler trat wieder auf. Denn die Ursache wurde nicht behoben. Genau das schätze ich sehr am Toyota Production System. Man sucht nicht nach Schuldigen, sondern nach Ursachen und versucht, diese zu beseitigen. Leider reicht es nicht aus, eine positive Fehlerkultur zu entwickeln, wenn die dazugehörige Lern- und Verantwortungskultur nicht vorhanden ist und die tieferliegenden Ursachen nicht beseitigt werden.
https://www.leanblog.org/2026/07/how-to-react-to-a-mistake/
AGILE
Workshops | 3 Formate für einen guten Abschluss
Ich bin immer wieder dankbar für Ideen und Ansätze, mit denen sich Workshops, Besprechungen und Austauschrunden sinnvoll gestalten lassen. Es geht darum, Formate so zu gestalten, dass sie einen erkennbaren Mehrwert schaffen. Der Blogartikel von Simon Flossmann enthält drei interessante Formate für die Abschlussrunde von Workshops, von denen ich eines tatsächlich noch nicht kannte. Sehr interessant.
Scrum-Kumbaya | Zu viel des Guten oder Scrum Master über das Ziel hinausschießen
Ich bin begeisterter Lean- und Agile-Enthusiast. Mit selbstorganisierten Teams zu arbeiten, ist das Größte für mich. Das macht mir mehr Freude als alles andere. Ich gehe davon aus, dass ich es mit mündigen Erwachsenen zu tun habe. Erwachsene und mündige Menschen in einem Team. Die „gescheiterten Sozialarbeiter-Scrum-Master” sind mir daher schon öfter unangenehm aufgefallen. Scrum ist kein Selbstzweck. Und es braucht auch kein „Scrum Kumbaya”, wie Mary Iqubal es treffend überschrieben hat (den Begriff muss ich mir merken). Noch einmal: Wir haben es mit erwachsenen, mündigen Fachleuten zu tun, die lösungsfokussiert zusammenarbeiten und hochwertige Ergebnisse erzielen wollen und sollen. Meine Aufgabe als Scrum Master ist es, den Rahmen dafür zu schaffen, dass ein Team produktiv zusammenarbeiten kann. Mein Job ist es nicht, ein Team zu „betüdeln”. Ganz im Gegenteil. Ich muss einen Rahmen schaffen, damit das Team produktiv arbeiten kann, und es auch herausfordern, wenn die Ergebnisse nicht stimmen. Eine positive Arbeitsatmosphäre kann dabei helfen, aber man kann auch deutlich über das Ziel hinausschießen. „Scrum Kumbaya” ist ein Beispiel dafür.
https://www.scrum.org/resources/blog/scrum-kumbaya
Explore vs Exploit | Eine Simulation für das Lernen als Team
Thomas Schissler stellt in seinem Beitrag eine sehr praxisnahe Simulation mit Verbindungen zur Praxis in vielen Teams vor. Im Fokus stehen die Arbeitsmodi „Explore” und „Exploit”. Das Interessante an seinem Beitrag ist, dass er nicht nur das spielerische Format ins Spiel bringt, sondern auch gleich die Brücke zur gelebten Teampraxis schlägt und somit aufzeigt, wie diese Simulation Teams dabei helfen kann, das richtige Maß zwischen „Explore” und „Exploit” zu finden. Das ist mit Sicherheit etwas, das sich für den einen oder anderen Workshop nutzen lässt. Mal sehen, ob ich Gelegenheit bekomme, es selbst auszuprobieren.
Schätzung | Schätzungen sind Wetten mit hoher Unsicherheit
Ich persönlich halte vom Schätzen der „Liefergeschwindigkeit” in komplexen Kontexten wenig. Schätzen ist hingegen sehr gut geeignet, um die Größe von Produktinkrementen einzuordnen. Für die Prognose eines Liefertermins taugt es hingegen wenig, da wir hier von einer Wette ausgehen, die auf vielen Unbekannten basiert. Liegt die Schätzung daneben, kommt es meist zu der von Dave West beschriebenen Reaktion. Verlässliche Prognosen erhalte ich in der Regel erst durch aussagekräftige historische Daten, die bei Entwicklungsprojekten – je nach Art der zu erledigenden Arbeit – oft nicht vorliegen. Während ich repetitive Aufgaben, für die ich vergleichbare Daten habe, sehr gut prognostizieren kann, ist es bei explorativen Tätigkeiten gerade wegen der fehlenden Qualität der Daten ein sehr unsicheres Spiel. Sehr erfahrene Teams haben zwar mit der Zeit aufgrund von historischen Daten und Erfahrungen ein gutes „Gefühl” dafür entwickelt, wie verlässlich sie liefern können, aber auch hier steckt sehr viel Erkenntnis aus der Vergangenheit drin. Und diese ist bei einem hochkomplexen Projekt nicht vorhanden. Prognosen sollten daher als „Wetten” mit hoher Unsicherheit verstanden werden, die im Laufe der Zeit aber immer genauer und präziser werden können. Nicht als exakter Plan. Regelmäßige Kommunikation über neue Erkenntnisse und deren Auswirkungen auf die Prognose ist daher extrem wichtig.
https://www.scrum.org/resources/blog/your-team-isnt-bad-estimating-planning-just-harder-we-admit
Umgang mit Fehlern | Wenn niemand die Wahrheit sagt, weil das System bestraft
Steve Denir beschreibt ein Problem, das Kurt Tucholsky einst in einem anderen Kontext sehr treffend umschrieben hat: „Im Übrigen gilt hier ja derjenige, der auf den Schmutz hinweist, als viel gefährlicher als derjenige, der den Schmutz macht.“ Die Wirkung sollte jedem klar sein. Wer auf einen Fehler hinweist und dafür an den Pranger gestellt wird, wird es nie wieder tun. Und alle, die so etwas auch nur im Geringsten mitbekommen haben, werden es dieser Person gleichtun. Lernen für die Zukunft? Keine Chance. Ich kann mich gut an die Idee eines Lean-Enthusiasten erinnern, jeden entdeckten Fehler zu feiern. Anstatt einen Schuldigen zu suchen, sollte man sich auf die strukturellen Ursachen konzentrieren und eben diese beseitigen. Das ist übrigens etwas, das ich an „echten” Lean-Adaptionen sehr schätze, bei denen ich den Eindruck habe, dass Kaizen gelebte Realität ist. Nur mal so nebenbei.
https://www.scrum.org/resources/blog/your-people-stopped-telling-you-truth-you-trained-them
POLITIK UND GESELLSCHAFT
Doppelmoral | Wenn Politik im Elfenbeinturm den Kompass verliert
Zu den Blogs, die ich fast täglich lese, gehört der von Heinrich Kümmerle. Er sagt, was er denkt. Und das gefällt mir. Wir kennen uns auch persönlich. Nicht immer bin ich seiner Meinung, aber das weiß er auch. Er gehört zu den wenigen Menschen, bei denen ich weiß, dass ein Meinungsaustausch nicht dazu führt, dass man hinterher – auch bei einem Dissens – kein Bier miteinander trinken gehen kann. Was uns beide eint, ist, dass wir überzeugte Demokraten und europäische Föderalisten sind. Mit dem verlinkten Blogartikel trifft er aktuell einen Nerv: die Doppelmoral mancher Politiker, die offenbar seit vielen Jahren nicht mehr aus ihrem Elfenbeinturm herausgekommen sind. An dieser Stelle ein kurzer Einschub: Bei aller berechtigter Kritik gibt es keinen Grund, einer Partei die Stimme zu geben, die auf die Abschaffung der freiheitlich-demokratischen Grundordnung abzielt. Noch dazu übertrifft sie in puncto krimineller Energie selbst die genannten Vertreter der Doppelmoral.
https://kuemmerle.name/doppelmoral/
Visionen | Uns fehlt es an handlungsleitenden Zukunftsbildern
Roland Dürre bringt es auf den Punkt: „Wir leben in einer Welt, die arm an Visionen geworden ist.“ Und das ist ein Problem. Wir brauchen klare Leitbilder. Positiv formulierte Leitbilder für die Zukunft, die es schaffen, die „Spaltung“ zu überwinden und Hoffnung zu stiften. Das ist ein schöner Denkanstoß, der mich diese Woche auch schon zu einem Gedankenblitz verleitet hat und den ich an dieser Stelle gerne weitergeben möchte.
https://www.if-blog.de/rd/visionen/
SATIRE
AInüchterung | Über die „Überhöhung“ der KI
Ich gebe zu, die Flut an Blogartikeln, die um jeden Preis etwas mit KI einbauen müssen, geht mir gewaltig auf den Nerv. Die „KI-Euphorie” scheint bei einigen schon fast neurotische Züge anzunehmen. Wenn ich mir so manchen von der KI glattgebügelten Artikel durchlese, vergeht mir auch langsam die Lust, so manchen Blog zu lesen. Es ist schön, wenn jemand das Ganze mal humoristisch auf die Hörner nimmt, wie „Buddy Müller” in seiner Agentursatire. So wie „Buddy Müller” in seiner Agentursatire. Ich habe herzhaft gelacht, auch wenn mir angesichts der Tatsache, was manche Manager meinen, durch KI günstiger machen zu können, eigentlich das Lachen vergehen müsste. Nur weil etwas technisch möglich ist, muss es nicht gut sein – damit schließt sich der Kreis zu den heutigen Links der Woche. 😉
https://agentursatire.blog/2026/07/18/folge52-diegroseairnuchterung/
#Agile #Demut #Doppelmoral #Erfolg #Fehlerkultur #Gesellschaft #KI #Lean #Lernen #Politik #Satire #Schätzung #Scrum #VisionMan verlangt vom Team Eigenverantwortung und lässt jede echte Entscheidung vom Management absegnen. Das ist keine Autonomie. Das ist Schuld-Delegation.
Ein Team ohne Entscheidungsbefugnis trägt nur die Verantwortung fürs Scheitern, nicht die Macht, es zu verhindern.
#management #agile #scrum #kanban
Alt...
VERANTWORTUNG
ohne Befungnis
Estimates aren't promises
An estimate is our best understanding of the effort involved based on what we know today.
It isn't a contract.
It isn't a deadline.
It isn't a guarantee.
As we learn more, the estimate may change. That's good engineering, not poor planning.