AI might lower the cost of a single feature, but production-quality product remains hard. Teresa Torres and Petra Wille debunk the "free delivery" myth, exposing the risks of feature bloat and technical debt. Discover why the last 30% is where the real work happens: https://www.producttalk.org/delivery-isnt-free-all-things-product-podcast-with-teresa-torres-petra-wille/ #ProductManagement #Agile

Top Links
Introducing XAML.io v0.9: Build .NET Apps From a Prompt, in Your Browser (XAML.io Team)
Single Day Tickets Now Available for TechBash 2026 (TechBash Team)
New in Edge for developers – Create better components and make your site agent-ready (Patrick Brosset)
7 Document A…

Simplicity isn't something you install once and forget. It's both a principle and a value. Whenever you make a change, ask "What is the simplest way this could be done?" That applies at every level, from small coding decisions up to an organization's structure.

Simplicity is hard, because the natural cognitive bias is to add, not take away. Our default approach to improving a product, system, or organization is to add something more. Enhance, boost, augment: these all imply that increasing size also increases strength or value. We rarely notice an opportunity to subtract, and it's rarely what gets rewarded or praised.

Why does this matter? Complex systems are more likely to break. The financial crisis of 2007/8 is a good example: the mortgage system had become so complex that no one understood the whole thing, not even at a high level. Everyone assumed someone else was doing the due diligence.

In software development, we spend more time reading and understanding code than writing it. Rush through development without taking time to simplify, and there's a price: the next person spends far more time understanding code that wasn't written with simplicity in mind, because the author wanted to save 10 minutes. Worse, complexity in code is a key source of bugs.

What's one area in your work where complexity is masking a deeper issue? Then ask, "What if we simplified this?" The answer might surprise you.

#Agile #Leadership

https://agilepainrelief.com/blog/less-is-more-creating-resilient-systems-through-simplicity/?utm_source=mastodon&utm_campaign=archive-reshare

Before 2026, we as humans used to develop "agile".

Working with #AI kind of changes this back to be more like "waterfal"-ish, call it spec driven.

Create a spec with AI first, build mocks, refine the spec, build it, create change proposals and drafts and let it invalidate outdated drafts.

Human can easily reproduce how and why development went into a direction.

#ai #agile

For german speakers: https://www.techflix.ch/videos/ac110006-a0c4-1f17-81a0-c4e9d92d0000

400k LOC, 45 days (in 6 months). 1 experienced software engineer.

The American Management Association features my “Phases of Team Development” IP in its "Leadership Skills and Team Development for Technical Professionals" course

🔗 https://scottgraffius.com/blog/files/ama-23.html

#AmericanManagementAssociation #ProjectManagement #Teamwork #Leadership #Agile #Agility

Communities can be wonderful places for inspiration, experimentation, and learning.

But they also have a pitfall: the bubble.

When everyone around you loves Agile, Scrum, or whatever your community is about, it’s easy to conclude that the problem is always “them”, the people outside the bubble.

My suggestion: keep adding fresh oxygen.

Talk to real users. Invite managers, stakeholders, and team members. Explore their struggles. Test whether your ideas actually help.

#agile

Alt...

Hand-drawn illustration showing people labeled User, Manager, and Team standing outside several large bubbles. Inside the bubbles, Agile coaches do different things: present Scrum, balance competing demands, fall over, and discuss certifications. The image playfully illustrates the risk of Agile and Scrum practitioners becoming disconnected from the people they aim to help.

Businesses, professional associations, government agencies, universities, and publications use my "Phases of Team Development" resource on teamwork tradecraft. I'm pleased to share that Verizon was added to the list!

https://www.scottgraffius.com/blog/files/verizon-features-scott-m-graffius.html

#Tech #Agile #Teamwork #Leadership

If you're a ScrumMaster wondering whether the role survives GenAI, here's a better question: which parts of it actually should?

Logging an impediment is something a tool can do today. Tracing it back to the decision or handoff that keeps producing it? That still takes a person. Updating tickets and chasing status is starting to get absorbed. Coaching your Product Owner through the backlog, or helping the team raise their game on testing and craft, isn't going anywhere.

I built an eight-question quiz on how you actually spent your last couple of Sprints, not how you'd like to remember them. You get back a map: what's slipping to the tools, what's getting more valuable, and one specific change worth making first. No score, no archetype.

GenAI won't replace you. It will keep reshaping which parts of your week are worth defending.

#ScrumMaster #Agile

https://agilepainrelief.com/quiz/scrum-master-ai/?utm_source=mastodon&utm_campaign=archive-reshare

The Anatomy Of Domain-Driven Design - Booklet by Scott Millett and Samuel Knight is free with a Leanpub Reader membership! Or you can buy it for $7.99! https://leanpub.com/theanatomyofdomain-drivendesign #agile #computer_programming #software

Imagine working with an immigration lawyer to prepare an application several hundred pages long, then the decision comes back in under a minute, with the officer looking at several files at once. How would you feel if you were the applicant?

Immigration, Refugees and Citizenship Canada measures how long it takes officers to process visa and immigration applications. Should be a win, right? Not so fast.

The backlog is real. But pretending an officer can review multiple applications simultaneously defies how human brains work. The system shows a point-and-click Approve or Deny screen with 3-4 applications displayed at once. Some run over 200 pages, so applicants are getting denials citing a missing birth certificate that was actually attached, or insufficient funds the application clearly proves they have.

One former immigration officer explains that in recent years, the only thing that matters is getting the file processed and the backlog cleared: a local optimization.

Fairness aside, this approach clogs the system with appeals. Instead of clearing the backlog faster, it creates a new one. The local optimization became a systemic problem.

We've seen this before in call centres, measuring how fast agents handle calls. Give an agent a simple problem, they'll help you quickly. Give them a complex one, and some will find a way to lose the call. The complex customer becomes someone else's problem.

#Leadership #Agile

https://agilepainrelief.com/blog/mismeasurement-mess-ircc-leads-the-way-in-measuring-the-wrong-thing/?utm_source=mastodon&utm_campaign=archive-reshare

»Getting Shit Done« https://bobgalen.substack.com/p/getting-shit-done #Agilist.in #Agile #Change #Lean #Kanban #Scrum

„Wer agil ist, muss nicht planen." Den Satz höre ich seit Jahren, oft von Leuten, die agiles Arbeiten verteidigen wollen.

Der wahre Kern daran: Der Plan ist wertlos. Eisenhower hat angeblich gesagt, Pläne seien wertlos, das Planen sei alles.

In der Praxis wird daraus etwas anderes. Kein Plan, und der Termin steht trotzdem. Dann plant jemand anders für dich. Ohne dich.

https://no-bullshit-agile.de/nba17-wer-agil-ist-muss-nicht-planen.html?mtm_campaign=mastodon

#SoftwareDevelopment #Projektmanagement #Agile

Alt...

Plakat auf hellem Papiergrund, schwarze Versalien: „Kein Plan heißt nicht kein Termin", das Wort „Termin" invertiert. Darunter: „Dann plant jemand anders. Ohne dich."

AI tool gains mean little if your operating model is broken. Silos act as a tax, absorbing speed gains through handoffs and coordination debt. Real ROI requires moving from functional silos to cross-functional team topologies. See why structure trumps tools: https://zenexmachina.com/the-silo-tax-ai-return-organisation/ #ProductManagement #Agile

Продакт + Проджект на 20 человек: как мы разделили руль

Опыт управления командами у меня больше 10 лет. Начинала с нагрузочного тестирования в аутсорсе и там исполняла роль тимлида+проджекта. И в роли продакта я работала как с совсем маленькими, так и с командами по 20 человек. В маленьких командах получается быстро договориться, а вот в командах 15+ операционка может перетаскивать на себя огромный временной ресурс и отжирать то, чем я люблю заниматься. В этой статье расскажу, как я подхожу к управлению большими командами, как мы делили обязанности с проджектом и адаптировали Scrumban под наши потребности. Привет! Меня зовут Маша, я Senior Product Manager и разбираю только те продукты, над которыми сама хотела бы поработать, так как ими пользуюсь, люблю и вижу, где есть потенциал роста. Мне драйвово искать для них решения, которые выводят продукт на новый уровень не только по деньгам, но и по UX и любви пользователей. Мои разборы: «Рейтинг ни на что не влияет»: Почему Яндекс.такси выбирает газлайтинг вместо честного UX и Кэшбек Шрёдингера и молчаливые проценты: Dark Patterns в банкинге . Сегодня я поделюсь как работаю с командой и какие лайфхаки нашла для себя для ускорения Time to Market.

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

#Управление_продуктом #управление_командой #scrumban #agile #управление_проектом

#LINKSDERWOCHE | 37/2026: Produktivität, Lean, Agile, Management und Leadership, Politik und Gesellschaft

PRODUKTIVITÄT

Übersicht | Vorgänge und Projekte auf dem Schirm behalten

Ich glaube, dass viele Menschen – zumindest im beruflichen Kontext – den Fehler machen, zu versuchen, Aufgaben zu verwalten. Aufgaben befinden sich auf der operativen Ebene. Sie befinden sich in einem permanenten Fluss. Da wird es schwer, strategisch zu organisieren. Der Begriff „Projekte”, den David Allen über GTD für die übergeordneten Themen verwendet, ist manchmal missverständlich. Zumindest kommt es mir so vor. Jan Fischbach spricht in diesem Kontext immer gerne von „Vorgängen”. Das ist an sich gar nicht schlecht, allerdings zucken viele innerlich zusammen, weil es sich für sie nach „preußischer Verwaltung” anhört (sie war oder ist übrigens besser als ihr Ruf). Losgelöst vom Begriff ist die Grundidee nach wie vor richtig und funktioniert in vielen Kontexten, in denen ich unterwegs bin, sehr gut. Und zwar vom Informations- bis zum Wissensmanagement. Das Ganze lässt sich übrigens auch sehr gut mit Kanban (und dem eher unbekannten Kamishibai) abbilden. Zusammen mit einem Obeya kann es als Gesamtsystem wunderbar visualisiert werden – im Sinne des von Jan Fischbach thematisierten Leitstands – und so in der „Dokumentenablage“ gespiegelt werden. Wichtig ist, das System möglichst einfach zu halten. Es sollten nur wenige Kategorien und eine einfache, flache Struktur verwendet werden. Sonst wird es wieder unübersichtlich. Dann funktioniert es nicht für uns als Individuum, sondern sehr gut im Team und in einer größeren Organisation.

https://www.teamworkblog.de/2026/09/viele-vorgange-und-projekte-mit-einem.html

Obsidian | Kanban mit Obsidian-Bases

Noch habe ich es selbst noch nicht ausprobieren können, da die anstehende Version 1.14 für Obsidian noch nicht ausgerollt ist. Dennoch, der Artikel von Thomas Mathoi macht mich neugierig. Mein Personal Kanban habe ich zwischenzeitlich in Personal Kanban integriert und mein Personal Obeya soll in Kürze folgen. Geplant ist mit der Version 1.14 Kanbanboards auch ohne Plugins in Obeya zu ermöglichen. Das hat Charme und erleichtert sicherlich den Einstieg für Obsidian-Nutzer in die Visualisierung von Workflows im Sinne eines Kanbanboards. Ich bin gespannt, wie gut es funktioniert, auch wenn meine Erwartungshaltung an die Flexbilität der Visualisierung nicht sonderlich hoch ist. Da kommen aber auch alle üblichen Verdächtigen nicht wirklich an ein haptisches Board an der Wand oder ein digitales Whiteboard heran. Liegt in der Natur der Technik.

https://www.mathoi.at/2026/09/16/kanban-mit-obsidian-bases/

LEAN

Kaizen und disruptive Innovation | Wir brauchen beides, unerschätzen aber Kaizen …

Ich finde den Artikel von Pascal Dennis insofern spannend, als er zeigt, wie sehr wir die Wirkung von Kaizen als kontinuierliches Streben zum Besseren im evolutionären Sinne unterschätzen. Wir feiern die „disruptiven Helden” der Innovation, die (vermeintlich) etwas Neues schaffen, wie Superhelden. Aber was ist mit der evolutionären Verbesserung? Die kleinen Minischritte mit ihren kaum merklichen Veränderungen sind mindestens genauso wichtig wie die vermeintlich supertollen neuen Ideen, die meist gar nicht so neu sind, sondern oft auf bestehenden Ideen basieren. Nur am Rande bemerkt: Diese feiern zufällig erst jetzt ihren öffentlichkeitswirksamen Durchbruch.

https://blog.leansystems.org/2026/09/kaizen-abracadabra-innovation.html

Reifegradmodelle | Wen sie in die Irre führen

Mir ist über die Lean Knowledge Base eine gelungene Erinnerung daran ins Blickfeld gerückt, dass wir Reifegradmodelle nicht zu sehr überbewerten sollten. Das Besondere daran ist, dass das Reifegradmodell nicht grundsätzlich verteufelt wird, sondern unser Umgang mit ihm im Fokus steht. Zur Erinnerung: Es sind Modelle. Sie stellen eine Referenz dar, die uns dabei hilft, etwas einzuordnen und zu erkennen. Sie sind niemals allein aussagefähig. Es braucht auch immer den Kontext. Ein Reifegradmodell hilft, Widersprüche und mögliche Handlungsfelder zu erkennen – nicht, sie zu verursachen. Gute Reifegradmodelle helfen uns, bessere Fragen zu stellen. Sie sind aber nie Selbstzweck. Es geht nicht darum, um jeden Preis den nächsten Reifegrad zu erreichen (selbst wenn er nicht zum Kontext passt), sondern herauszufinden, wo mögliche Potenziale liegen, die gehoben werden könnten.

https://leanbase.de/publishing/post/warum-reifegradmodelle-organisationen-in-die-irre

Kata | Routinen ohne Weshalb sind inhaltsleer

Persönlich habe ich reflektierte Routinen sehr zu schätzen gelernt. Dass ich das Wort „reflektiert” davorsetze, hat einen guten Grund, wie man sich denken kann. Routinen sind reproduzierbare, bewährte Praktiken im Sinne einer Gewohnheit. Im Lean-Kontext spricht man gerne von Kata. Sie haben einen Zweck und Grund. Aber der Zweck und Grund kann sich im Laufe der Zeit verändern, sodass eine perfekt ausgeführte Routine dennoch „Quatsch” sein kann. Es ist ein leeres Ritual ohne Lerneffekt. Da muss ich mich immer wieder daran erinnern, dass eine Routine – wie jeder andere Standard auch – nichts anderes als eine Arbeitshypothese ist, die so lange gilt, bis sie durch eine bessere abgelöst wird. Ganz abgesehen davon soll eine Routine uns beim Lernen unterstützen. Wird sie zum Selbstzweck, dann wird sie zum stumpfen Schwert ohne Mehrwert. Gerade deshalb ist es wichtig, sich immer wieder zu vergegenwärtigen, weshalb es die Routine gibt. Dann macht die Routine im Sinne einer Kata auch Sinn. In diesem Sinne bin ich voll und ganz bei Götz Müller. Eine perfekte Choreografie, die den Zweck jedoch ausklammert, ist keine Kata im Sinne von Lean.

https://www.geemco.de/artikel/wenn-kata-zur-choreografie-wird

AGILE

Moderation | Wie neutral muss ich als Moderator sein?

Michael Schenkel fragt: „Muss Moderation neutral sein?” Ich formuliere die Frage um: Kann sie überhaupt neutral sein? Unter uns gesagt, kann niemand vollkommen neutral sein. Der Unterschied besteht darin, sich dessen bewusst zu sein. Besser ist es, sich zu fragen, welche Aufgaben die eigene Rolle als Facilitator hat, wie man diese Rolle im jeweiligen Kontext am besten ausfüllt und was dies jeweils bedeutet. Denn ich habe immer auch einen Auftrag, der mich zwingt, in dieser Rolle Entscheidungen zu treffen. Damit bin ich wieder beim Artikel von Michael Schenkel, der das sehr gut herausarbeitet. Das Ganze erinnert mich irgendwie an die hohe Kunst der Gastgeberschaft, bei der ich als „Gastgeber” immer wieder verschiedene „Rollen” und „Positionen” einnehme, um den Raum und den Rahmen zu schaffen, der Austausch ermöglicht. Und das ist die eigentliche Kunst. Ein spannendes Thema.

https://t2informatik.de/blog/wie-neutral-muss-moderation-wirklich-sein/

Scrum | Mehr Besprechungen durch Scrum?

Ein Klassiker. Scrum führt zu mehr Besprechungen. Wirklich? Ja, wenn man es zusätzlich zu bestehenden Besprechungsrunden einführt. Drehen wir doch mal den Spieß um! Was wäre, wenn alles, was wir mühsam in vielen anderen Besprechungen erarbeiten, in effektiv geführten Scrum-Meetings stattfinden würde? Viele Besprechungen wären überflüssig. Kein Scherz. Ich habe das so oft erlebt. Und das gilt sogar dann, wenn die Stimmung ursprünglich gegen Scrum war. Das Problem sind nicht die Scrum-Meetings. Es ist vielmehr die Art und Weise, wie Kommunikation und Austausch gelebt werden, die sich immer wieder als Problem herausgestellt hat. Zu viele Besprechungen sind zu wenig ergebnisfokussiert und zu sehr mit „Selbstdarstellung” gefüllt. Wenn wir den Fokus bei Besprechungen auf das Ergebnis und die Zusammenarbeit richten, werden eben diese oft viel gescholtenen endlosen Runden schlagartig zielführender. Das ist eine spannende Erfahrung, die ich immer wieder mache. Ralph Jocham stößt in ein ähnliches Horn.

https://www.scrum.org/resources/blog/scrums-meetings-are-capped-five-hours-week-something-else-filled-your-calendar

Scrum Master | Sich obsolet machen ist nicht das Ziel

Chee-Hong Hsia trifft einen Nerv. Gute Scrum Master (und vergleichbare Facilitator-Rollen) haben zwar den Anspruch, Menschen zu befähigen, ihre Probleme selbst zu lösen – eine Idee, die übrigens aus dem Lean-Kontext stammt –, aber sie machen sich damit nicht obsolet. Sie schaffen den Rahmen und den Raum, sodass sie sich bei vielen Dingen zurücknehmen können und Teams eigenverantwortlich agieren können. Damit werden sie nicht überflüssig, sondern verschieben ihren Fokus. Den „Führung” braucht es immer. Als Impulsgeber, Motivatoren und Unterstützer. So gewinnen sie den Raum, den sie brauchen, um neue Ideen und Fertigkeiten zu entwickeln. Diese tragen wiederum dazu bei, dass Teams die nächste Entwicklungsstufe erreichen können. Organisationen müssen sich beständig weiterentwickeln. Weil sich ihr Umfeld fortentwickelt. Und dafür braucht es immer wieder jemanden, der dabei begleitet, unterstützt und befähigt.

https://www.scrum.org/resources/blog/hi-scrum-masters-if-your-goal-make-yourself-obsolete-then-youre-doing-it-all-wrong

Roadmap | Kollaborativ zur Roadmap

Ich werde nicht müde, immer wieder zu betonen, dass es für Scrum Master, Agile Coaches und vergleichbare Rollen sehr wertvoll sein kann, bei Bürgerbeteiligungen und Partizipationsprozessen zu hospitieren. Denn dort lernt man viele gute Methoden kennen, die bei der Arbeit mit Gruppen im beruflichen Kontext sehr hilfreich sein können. (Kleine Info: Im Kontext des bürgerschaftlichen Engagements begann übrigens vor fast 20 Jahren meine Reise in die Agilität.) Darunter auch die Methode des Gallery Walks, die Maria Iqbal in ihrem Blogartikel beschreibt. Wir erinnern uns: Es geht um gute Zusammenarbeit. Und genau hierfür sind viele Moderationstechniken aus dem Bereich des bürgerschaftlichen Engagements gedacht. Im Blogartikel wird der Gallery Walk genutzt, um eine realistische IT-Roadmap zu entwickeln.

https://www.scrum.org/resources/blog/gallery-walk-it-roadmap

Customer Journey Map | Eine kleine Anleitung

Wie kommt entwickelt man eigentlich eine Customer Journey Map? Diese Frage beantwortet Lars Richter aus Sicht eines Solopreneurs. Übrigens locker übertragbar auch in andere Bereiche. Die einzigen, die eventuell stolpern könnten, sind die Kollegen im Bereich der öffentlichen Hand. Gerade im hoheitlichen Bereich könnte es schwierig werden, den Kunden zu identfizieren, den der ist nun mal die Allgemeinheit. Mit etwas Transferleistung lässst sich das Ganze aber auch hier adaptieren und trägt zu einem besseren Verständnis bei, wie zum Beispiel Prozesse ausgestaltet werden sollten. Daher bin ich ein großer Freund der Customer Journey – auch über die Produktentwicklung hinaus. Der Blick von rechts nach links (also ausgehend von der Frage, was will ich für wen mit welchem Zweck erreichen) hilft tatsächlich so manchen Knoten auch bei prozessualen Fragen zu lösen. Zugegebenermaßen, man macht es viel zu selten.

https://scamper.blog/customer-journey-map/

Erfolgsgeschichten | Wen Scrum funktioniert

In den letzten Tagen ist mir wieder einmal bewusst geworden, dass wir – zumindest in Deutschland – sehr gut darin sind, das Negative zu sehen und das Positive auszublenden. Dabei wissen wir, wie wichtig positive Narrative für uns sind. Als Motivator, Energiespender und Hoffnungsträger. Natürlich müssen wir auch über das Scheitern reden, aber genauso wichtig ist es, über das zu sprechen, was gut funktioniert. Und uns überrascht hat. Ich war zum Beispiel überrascht, dass Scrum im Kundenservice erfolgreich war – ich hätte hier eher eine Domäne von Kanban vermutet. Aber mal ganz ehrlich: Wenn es funktioniert, ist mir das Framework schnuppe. Gerade in der explorativen Phase eines Veränderungsprozesses kann Scrum sehr gut unterstützend wirken. Diese Erfahrung durfte ich auch schon machen. Im Regelbetrieb wurde dann stärker auf Kanban in Verbindung mit der Verbesserungskata gesetzt. Na, fällt was auf? Genau. Eine methodische Zusammenarbeit statt Gegeneinander, je nach Bedarf und Kontext. Aber zurück zur Geschichte von Felix Stein. Es gibt Hoffnung. 😉

https://www.lean-agility.de/2026/09/agile-success-stories-scrum-im-kundenservice.html

Backlog | Wenn die KI die Anforderungen schreibt, aber das Verständnis fehlt

Ich lese oft über KI im Kontext des Backlog-Refinements. Alles gut. Als Hilfe eingesetzt durch aus sinnvoll. Und doch bleibt ein dickes „Aber“ übrig. Um es mit Mike Cohen auszudrücken: „Eine gut geschriebene Geschichte kann immer noch die falsche Geschichte sein.“ Und genau diese Gefahr besteht, wenn wir uns zu sehr auf die „Maschine“ verlassen. Sein Fazit ist für mich treffend: Der Mensch bestimmt, was den Mehrwert ausmacht und die Maschine hilft uns die Informationen zu „strukturieren“. Das Verstehen, was sich dahinter verbirgt, können wiederum nur die Menschen im gemeinsamen Austausch. Nicht die KI. Die Versuchung ist groß, aber Geschwindigkeit und Menge allein, liefern die Qualität und das Verständnis.

https://www.mountaingoatsoftware.com/agile/ai-can-write-backlog-items-it-cant-create-shared-understanding

LEADERSHIP UND MANAGEMENT

Teamreife entwickeln | Ein Team befähigen ist das Ziel

Vermutlich hört man es bei mir immer wieder heraus: Ich schätze eine Führung, die befähigt und Menschen in die Lage versetzt, Probleme und Hindernisse selbst zu lösen. Behandelt erwachsene Menschen wie erwachsene Menschen und habt Vertrauen in ihr Können. Und dann werdet ihr sehen, wie vieles plötzlich funktioniert. Leider beobachte ich oft genug das Gegenteil und bekomme das auch so zurückgespiegelt. Gefühlt sogar deutlich häufiger als früher. Und das gerade jetzt, in Krisenzeiten, in denen wir dieses Potenzial eigentlich bräuchten. Ich würde mir mehr Führung im Sinne von Dan Rockwells Beitrag wünschen, die es den Teammitgliedern ermöglicht, zu wachsen und sich zu entwickeln. Das ist meiner Meinung nach ein echter Booster.

https://leadershipfreak.blog/2026/09/17/how-to-develop-mature-team-members/

Fähigkeiten entwickeln | An konkreten Fertigkeit arbeiten bringt zum Ziel

Ein weiterer Impuls von Dan Rockwell hat mich positiv überrascht. Wir reden ja gerne davon, Führungskompetenz oder „Leadership“ zu entwickeln. Was wäre, wenn wir dabei viel zu groß denken? Wenn es eigentlich darum geht, einzelne Fähigkeiten zu entwickeln? Fähigkeiten, die zwar zur Führungskompetenz beitragen, aber auch für sich allein schon wertvoll sind. Konkrete Fähigkeiten. Das ist richtig, denn damit sehen wir schneller Wirksamkeit und auch schneller konkrete Ergebnisse. Kleinere Ziele, schnellere Ergebnisse, früheres Feedback. Moment, das klingt ja nach … ups … nach Agilität. Pardon, musste sein. Das ist eigentlich ein offenes Geheimnis. Nur übersehen wir es zu oft. Die Verbesserung der Kommunikation ist ein großes Thema und ich bin mir sicher, dass jeder von uns innerhalb dieses Feldes Stärken und Schwächen hat. Und es ist ein großes Feld. Lieber erst mal kleiner anfangen und es richtig umsetzen, dann steigt auch die Erfolgschance.

https://leadershipfreak.blog/2026/09/16/stop-developing-your-leadership/

Reorganisation | Wenn Reorganisation zum Motivator werden kann

Olaf Hinz widmet sich dem Thema Reorganisation. Ein großes Wort dafür, dass sich jede Organisation eigentlich beständig neu erfinden muss, um sich an geänderte Rahmenbedingungen anzupassen. Wo ich ihm voll zustimme, ist, dass eine gelungene Reorganisation ein Motivationstreiber auf allen Ebenen ist. Das durfte ich selbst schon mehrfach erleben. Mein persönlicher Favorit als Meta-Modell ist die Verbesserungskata, da sie dabei hilft, den Prozess mit Rhythmus, Ziel, Zwischenzielen, Feedbackzyklen und klarem Wirkungsfokus klarer zu machen. Das passt auch ganz gut zu seinen fünf Fragen. Aus meiner Beobachtung ist es wichtig, dass die Antworten auf diese fünf Fragen transparent gemacht werden und immer wieder Teil des Prozesses sind.

https://www.hinz-wirkt.de/lotsenblog/artikel/6842-wenn-reorganisation-gelingt-ist-sie-ein-motivator/

Satire | Führungskräftecodes oder Floskelsprech statt Klarheit

Mit Humor lässt sich auch manches Kritische sagen. In der aktuellen Folge des Agentursatire-Blogs von Buddy Müller schwingen mehr als eindeutig kritische Untertöne in Richtung Führung mit. Meister Konfus war bei der Lektüre sehr erfreut. Phrasendrescherei in der Führung statt Klarheit und Transparenz? Ja, was will man mehr? Mit Blick auf Veränderungen und Reorganisationen ist es genau das, was wir brauchen, damit Veränderungen nicht positiv wirken können. Ganz im Sinne von Meister Konfus gilt es, die Mitarbeiter zu verwirren, Klarheit zu vermeiden und am besten keinerlei Richtung aufzuzeigen.

https://agentursatire.blog/2026/09/18/folge53-fkk/

POLITIK UND GESELLSCHAFT

Zur Rubrik | Weshalb ich sie für wichtig halte

Vielleicht ein paar Worte zu dieser Rubrik (Politik und Gesellschaft), weil mir der eine oder andere zurückspiegelt hat, dass die Themen dieser Rubrik nicht wirklich zum Rest der Links der Woche passen. Nun, ich bin da gänzlich anderer Meinung. Politik und Gesellschaft – das ist das Meta-System, in dem wir uns bewegen. Dieses Meta-System geht uns alle an. Es spielt direkt in unseren Alltag hinein, privat und beruflich. Für dieses Meta-System tragen wir alle, jeder einzelne von uns, Verantwortung. Und genau deshalb habe ich diese Rubrik auch in die Links der Woche aufgenommen. Man sehe es mir nach, aber es geht uns alle an, was in unserer Gesellschaft passiert. Wir können nicht neutral sein und bleiben. Man sehe mir daher bitte nach, wenn ich diese Rubrik weiterhin als Teil meiner Links der Woche sehe.

Offene Gesellschaft | Eine offene Gesellschaft braucht offene Denkmäler und diese brauchen uns als Zivilgesellschaft

Für mich ist Erinnerungskultur gelebte Verantwortung im Sinne von „Prophylaxe“. Echte Verantwortung bedeutet, dass man sich auf die Spurensuch begibt. Nicht weil man der Schuldige ist, sondern weil man danach strebt die Dinge besser zu machen und für die Zukunft lernt, um Fehler in Zukunft zu vermeiden. Daher sind mir Gedenkstätten und ihr Arbeit extrem wichtig. Übrigens, es gibt nicht nur Gedenkstätten, die den Opfern von Autokratie und Diktatur gedenken, sondern die auch vergessene Demokratiegeschichte wieder lebendig machen. Ein positive Narrativ erzählen. Diese sind gewissen Kreisen ebenso ein Dorn im Auge, wie die Erinnerungsorte für Opfer von Diktatur und Krieg. Und hier sind wir alle gefragt. Hier. Jetzt. Heute. Und gerade deshalb ist ein Angriff auf unsere Denkmäler und Ort der Erinnerung immer auch ein Angriff auf unsere Gesellschaft. Wir haben es in der Hand.

https://www.demokratiegeschichten.de/offene-denkmaeler-offene-gesellschaft/

AfD-Verbot | Verschwinden dann die Wähler der Nicht-Alternative?

Ich mache keinen Hehl daraus. Eine Partei, die so offen rechtsextremistische Thesen verbreitet wie die „Alternative für Deutschland“, gehört verboten. Eine Demokratie darf keine Toleranz gegenüber Intoleranz zeigen, die darauf abzielt, jegliche Toleranz und Freiheit abzuschaffen. Nun könnte man einwenden, dass ein Verbot nicht dazu führt, dass die Wähler verschwinden. Der Volksverpetzer zeigt meines Erachtens sehr genau auf, dass dieses Argument nicht greift. Die „Nicht-Alternative“ erzeugt ihre „Zielgruppe“ selbst. Sie schafft es geschickt, das Narrativ zu bestimmen, für das es in weiten Teilen nicht einmal empirische Belege gibt. Ganz im Gegenteil. Und genau diesen Prozess gilt es zu unterbrechen. Dann haben wir die Möglichkeit, ein Gegennarrativ zu setzen, denn es gibt durchaus Anknüpfungspunkte.

https://volksverpetzer.de/analyse/afd-verbot-waehler-verschwinden/

🔐 В RetroPoint вход теперь сохраняется между рабочими днями. Закрыли вкладку в пятницу, в понедельник продолжаете без пароля. Войти заново понадобится после 30 дней без захода.

В профиле появился раздел «Аккаунт» с вкладкой «Безопасность». Видно устройства, на которых выполнен вход. Сессию можно завершить отдельно или выйти везде. Смена пароля завершает все сессии.

Подписки на модули и пакеты теперь отключаются самостоятельно и работают до конца оплаченного периода. Пакет «+30 вызовов» AI за 149 ₽ в месяц доступен на любом тарифе, включая бесплатный.

https://retropoint.ru/?utm_source=mastodon&utm_medium=organic_social&utm_campaign=2026_09_account_and_billing&utm_content=account_and_billing_post

#RetroPoint #Agile #TeamManagement #тимлид

Ansible for DevOps by Jeff Geerling is on sale on Leanpub! Its suggested price is $9.99; get it for $6.99 with this coupon: https://leanpub.com/ansible-for-devops/c/LeanPublishingDaily20260917 #agile #software #startups #ansible #devops #cloud_computing

How do you know whether Agile Coaching is actually making a difference?

I believe Agile Coaches and Scrum Masters can add tremendous value. But we can do a much better job of making that value tangible.

Don’t rely only on intuition and gut feeling. Use data, evidence-based feedback, and conversations with teams and stakeholders to understand the impact you’re having.

Make your value visible.

#agile #coaching

Alt...

Illustration of a large balance scale. On the left, a team member, manager, and stakeholder stand beside a bag of money marked with a euro symbol. On the right, three coaches stand beside an upward-pointing arrow labelled “Coaching R.O.I.” The scale balances the financial investment in coaching against its return.

10 Options to start with Scrum.

We created this illustration a few years ago (or even longer), it's still a fun & interesting poster to use for reflection.

How did you get started, and what happened because of that? If you could start all over again, what approach would you prefer this time?

#agile #scrum

Alt...

A poster with 10 options to start with Scrum.

@michael_muench thats really cool, i am in. i guess with a session about some results of using #columinity @index
and looking forward to attend with the @haufegroup crew (again)

cc
@agile @micheal @karen @barryovereem @christiaanverwijs @derchristian
#agile #scrum #lean

In a Wizard of Oz MVP, you present what looks to the end user like a fully functional product. Behind the scenes, it's just people doing the work.

The most famous example is Zappos (originally Shoesite). Like any good Lean startup, they needed to test their riskiest assumption: would anyone buy shoes online? You can't test fit, feel, or quality through a screen. Rather than spend millions building a fulfillment center, founder Tony Hsieh put up a website that sold shoes, then fulfilled orders manually by buying them at local stores.

Airbnb did something similar: the founders visited early hosts' homes, took professional photos, and listed them on the site themselves. When a guest booked, the founders handled the details in the background. Both were testing the same riskiest assumption: is it safe to buy or rent over the internet?

Build a realistic front end, leave out the back end, and iterate quickly as you see how people actually use it. To the end user, it has to look real. Measure whatever you'd normally measure in a live product: does the user buy, rent, or take the key action?

Pros: cheap, cheerful. Cons: consistency is hard to maintain doing repetitive tasks manually, and it doesn't scale. If demand overwhelms you early, you may need to shut the door temporarily and build the real thing. Remember, you built throw-away code. Don't build on top of it.

Wizard of Oz is one of my favourite MVP techniques.

#Agile #ProductOwner

https://agilepainrelief.com/glossary/wizard-of-oz/?utm_source=mastodon&utm_campaign=archive-reshare

Running the Scrum events and keeping everyone coordinated? That's busywork, and it's the first place to lean on a tool or trim back.

Coaching your Product Owner, going after the root cause of a recurring impediment, working through conflict until people are actually aligned? That's the part of the ScrumMaster role no tool is going to do for you.

I built an eight-question quiz that maps where your last couple of Sprints actually went: the work that's slipping to the tools, and the work that's getting more valuable. No score, no archetype, just an honest map and one specific recommendation of where to start.

Works whether you hold the ScrumMaster title, cover it alongside delivery work, or run the process as a Project Manager.

Which parts of your role still need a person? Find out in about three minutes.

#ScrumMaster #Agile

https://agilepainrelief.com/quiz/scrum-master-ai/?utm_source=mastodon&utm_campaign=archive-reshare

@thomasfricke

i like the most, that all those people in the slide are here, except mr waits.

@k9ox @kentbeck @rebeccawb @ericevans

@agile
#agile #scrum #newword

Eine interessante Analyse von Rudi Gysi darüber wo es Probleme bei der Koordination mehrerer Teams geben kann. Egal ob SAFe oder andere agile Agile-Skalierungen.
Mit seiner Erfahrung sieht er die Lücke in dem was Klaus Leopold Flight Levels nennt.
Und ihm fehlen gemessene Daten. Es wird viel Versprochen und gibt Erfahrungsaussage, aber kaum öffentlich verfügbare Daten.
https://agilereflection.org/diesmal-ist-es-nicht-die-lehmschicht/
#agile #scrum #kanban

Ретроспектива за 45 минут: как перестать превращать ретро в час коллективного нытья

Ретро умирают одинаково: жалобная книга вместо разговора, сорок минут на один спор, экшен-айтемы в никуда. Разбираю тайминг на 45 минут, четыре формата (Start Stop Continue, Mad Sad Glad, 4L, Sailboat) — что писать в каждую колонку и когда какой брать, — и правила, которые держат ретро живым. Во второй части — как устроена моя бесплатная доска для ретро: стек, где хостится, шифрование карточек и что происходит с данными.

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

#ретроспектива #ретро #agile #scrum #команда

Organisational Dysfunction of the Day

Nobody wants to own this

Context: There is a service that seven teams depend on. It was built three years ago by a team that no longer exists. The code lives in a repository that has eleven different people listed as contributors. When it breaks, everyone notices. When it needs updating, everyone waits. Slack messages go out asking who owns it. The answers are variations of "we use it, but we didn't build it" and "I think that was the old platform team." Someone eventually fixes the immediate problem. Nobody fixes the underlying one. The service is not on anyone's roadmap or in anyone's OKRs. It is not neglected because nobody cares. It is neglected because the structure has no place to put it.

OST explains: DP1 organises work by splitting it into owned pieces, services to teams, components to people, functions to departments. The logic works for things that fit neatly into boxes. It breaks down entirely for things that are shared, the platform everyone uses, the legacy system too expensive to replace, the cross-cutting concern that belongs to the whole organisation rather than any part of it. These things fall into the gaps between the boxes and stay there. Nobody is incentivised to invest in something that appears on nobody's performance review. In a DP2 structure, where a team owns its whole task end-to-end, the boundary location principle requires that the team controls everything it depends on to do its work. Shared dependencies are a structural signal that the boundaries are wrong, that the work has been sliced in a way that leaves essential things ownerless. The abandoned service is not a prioritisation failure. It is a design failure. The organisation drew the lines in the wrong places and then wondered why nothing fills the gaps.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

***

The series has become a book, available now on Leanpub.
https://www.organisationaldysfunctions.com

Top Links
Aspire 13.5.4 (Aspire Team)
Performance Improvements in .NET 11 (Stephen Toub)
Intelligent Terminal 0.2.2572: Faster, Smoother, and More Reliable (Hamza Usmani)
Share your .NET story with the community (Luis Quintanilla)
Rider and ReSharper 2026.2.2 Are Out! (Alexander …

During British rule of India, a bounty was offered for every cobra killed, to reduce the population. It backfired: people started breeding and killing cobras for income. In 2002, British officials in Afghanistan paid farmers $700 per acre to destroy opium crops. The result: farmers planted opium so they'd have something to burn.

"What is measured is managed" is a famous quote I can't find clear attribution for (often mis-attributed to Peter Drucker). The damage this mindset has done over the past century is amazing.

I've seen salespeople with regional bonuses fight over who gets credit for a large sale, undermining each other instead of building client relationships. In one organization, we had an annual award for whoever was best at solving difficult customer problems. Those same people were so busy solving problems that they were also creating the quality problems that became next year's fires.

The more metrics you have in place, the more likely they are to come into conflict. Quarterly sales bonuses often lead to discounts, because locking in a sale for the bonus is worth a 20% cut, even if it hurts overall profit. They also pressure product teams to push work out the door by quarter-end, and quality always suffers.

Two questions before you add another metric:
- Can we eliminate one first?
- What are the second-order effects? (Systems Thinking)

We'll never predict all the ways a measurement changes the system it measures. Only measure what matters.

#Leadership #Agile

https://agilepainrelief.com/blog/how-hidden-complexity-tax-saps-organization-resilience/?utm_source=mastodon&utm_campaign=archive-reshare

I've long said, and research supports it: a fragile organization that goes faster will be knocked over by the slightest wind.

Most of the oxygen in the online conversation right now is being swallowed by AI hype. AI is a valuable tool, but when misapplied it makes organizations more fragile, not more resilient. The current fascination with using AI to produce code faster concerns me when it becomes a general crutch rather than a tool used in specific, select ways.

Attempts to speed up a system without first ensuring quality, alignment on strategy, and focus on the actual bottleneck just pile up more of the wrong thing, probably full of defects.

What makes organizations fragile:
- Focusing on speed over quality
- Adopting new technology without understanding its impact throughout the system
- Heavyweight change management process
- Involving every stakeholder in every decision
- Standardization overkill
- Centralization of decision making

Resilience isn't an afterthought. It isn't a fixed characteristic, it's something we constantly work on.

Not anti-AI. We study the failure modes so we can avoid the traps. Without that, we're flying blind.

Where have you seen things that make your organization more fragile?

#Agile #Leadership

https://agilepainrelief.com/blog/speed-trap-how-the-obsession-with-speed-is-build-a-fragile-organizations/?utm_source=mastodon&utm_campaign=archive-reshare