Produktivität
Kommunikation | Wie wir weniger langweilig wirken können
Etwas, wo ich mich an die eigene Nase fassen kann: Für andere weniger langweilig sein. Es klingt so banal und doch nachdenklich: Wie oft sind wir von etwas überzeugt und halten unserem Gegenüber Monologe darüber, ohne zu merken, dass es für andere eben nicht so spannend rüberkommt? Dagegen können wir etwas tun. Mischen wir unsere Kommunikation ein wenig auf, ganz im Sinne von Dan Rockwell. Das geht sogar ganz einfach: um Rat fragen, vereinfachen, Meinungen einholen und so weiter. Und schon wird es weniger langweilig.
https://leadershipfreak.blog/2025/01/30/5-guaranteed-ways-to-be-less-dull/
Glück | Das Glück liegt vor unseren Füssen, wir müssen es nur aufheben
Wir suchen das Glück in der Ferne. Dabei liegt es vor unseren Füßen. Wir müssen es nur „aufheben“. Das Problem ist, da bin ich keine Ausnahme, wir sehen es einfach zu wenig. Auch hier bringt es Dan Rockwell sehr schön auf den Punkt. Mit ein paar Kleinigkeiten können wir den Fokus auf das Glück im Alltag lenken, das wir zum Greifen nah vor unseren Füßen haben, anstatt uns im Wettbewerb des Höher, Schöner, Besser zu verschleißen.
https://leadershipfreak.blog/2025/01/29/how-to-face-the-problem-of-happiness/
Agile
Geschwindigkeit | Weshalb wir schnell gute Ergebnisse liefern wollen …
Warum wollen wir so schnell wie möglich gute Ergebnisse liefern? Ganz einfach: Damit wir schneller lernen, was wir besser machen können. Wenn wir etwas Neues entwickeln, sind wir relativ unsicher, was wir wirklich brauchen. Wir tasten uns Stück für Stück heran. Deshalb brauchen wir schnelle und kurze Feedback-Zyklen, um herauszufinden, ob wir tatsächlich das Richtige bauen. Etwas ausführlicher ist die Darstellung im Podcast im No Agile Bullshit Podcast.
https://no-bullshit-agile.de/nba51-gute-software-schnell-liefen.html
Agiles Hamsterrad | Wie wir im agilen Hamsterrad landen und wir entgegenwirken können
Ich habe ein Déjà-vu-Erlebnis. Und was für eins. Könnte es sein, dass Simon Flossmann im gleichen Umfeld unterwegs war wie ich? Möglich. Genauso gut könnte es aber auch sein, dass das, was er hier anschaulich beschreibt, ein Symptom für tiefer liegende Probleme ist, die wir aufgrund der Ähnlichkeit moderner Organisationen sehr oft und sehr häufig beobachten können. Why Limit WiP von Jim Benson ist ein Buch, das ich immer wieder empfehle. In den meisten Organisationen gibt es zu viel parallele Arbeit im „Organisationssystem“. Zu viele parallele Projekte, zu viele Themen parallel, zu viele Aufgaben gleichzeitig. Übrigens auf allen Ebenen der Organisation. Abhängigkeiten sind ohnehin ein Dauerbrenner, der auch viel zu oft zu wenig Beachtung findet. Natürlich lassen sie sich nie ganz auflösen – aber wir können sie deutlich reduzieren. Engpässe sind auch ein Thema, das selten wirklich gelöst wird. Auch weil die ganze Mannschaft im Hamsterrad dreht und die strategische Arbeit zwangsläufig vernachlässigt. Von den immer größer werdenden technischen und organisatorischen Schuldenbergen will ich gar nicht erst anfangen. Und dann der Klassiker: unklare Ziele. Im schlimmsten Fall sind die verschiedenen Ebenen nicht einmal miteinander verbunden (einer der Gründe, warum ich mich intensiv mit Obeya beschäftige). Probleme, die nicht nur Scrum Teams, sondern viele Organisationen in unterschiedlichster Form plagen und viel „nicht-wertschöpfende“ Arbeit verursachen.
Werthaltige Lieferung | Wir mit besserer Abstimmung zwischen Teams und Anspruchsgruppen weniger Verschwendung, mehr werthaltige Lieferung erzeugen können
In eine ähnliche Richtung wie Simon Flossmann geht der Blogbeitrag von Stephan Wolpers. Auch bei ihm spielt die nicht wertschöpfende Arbeit (er spricht von Verschwendung) eine Rolle. Sein Fokus liegt mehr auf dem Produktmanagement. Hier insbesondere auf das fehlende Alignment (einer der fünf Punkte von Simon Flossmann) und die „zugemüllten“ Backlogs, die es unmöglich machen, noch fokussiert zu erkennen, was wirklich wertschöpfend ist. Auch ein Dauerbrenner. Mein Tipp: Regelmäßig „5S im Kopf“ machen und dies auch auf das Backlog-Management übertragen. Regelmäßiges Aufräumen und Überprüfen schafft Klarheit und Übersicht. Leider auch etwas, was zu kurz kommt, wenn sich das Team und die Organisation im Hamsterrad dreht und eben nicht im Vorfeld beginnt. Übrigens gibt es den Artikel in zwei Versionen, wobei interessanterweise die englische Version einen anderen Titel trägt als die deutsche.
Englische Fassung: https://www.scrum.org/resources/blog/stop-shipping-waste
Deutsche Fassung: https://www.scrum.org/resources/blog/abstimmung-zwischen-teams-und-stakeholdern
Kanben und OKR | Wie Kanban dabei helfen kann, besser mit OKRs zu arbeiten
Ich mache keinen Hehl daraus, dass ich der Meinung bin, dass Kanban sehr gut zu vielen anderen agilen Ansätzen passt und ihnen helfen kann, besser zu werden. Wichtig ist, dass Kanban viel mehr ist als die Visualisierung, die immer wieder damit in Verbindung gebracht wird. Die Prinzipien und Kernpraktiken, die auf die kontinuierliche Weiterentwicklung der Organisation ausgerichtet sind, können wahre Wunder bewirken. Das gilt in Verbindung mit Scrum und – wie im Beispiel von Yuval Yeret – mit OKR. Und wenn man das Ganze dann noch in ein Obeya integriert … 😉
https://www.scrum.org/resources/blog/improving-strategic-traction-through-okr-kanban-system
Scrum und Meetings | Zu viel des Guten?
Ich bin ein großer Freund von C.N. Parkinson, auch wenn seine Ideen schon über 60 Jahre alt sind. Er gehört zu den Klassikern. Zum Thema Sitzungen gibt es ein schönes Zitat, das ich in letzter Zeit immer wieder in den Raum werfe: „Zu viele Besprechungen sind ein deutliches Zeichen für schlechte Organisation“. Gelegentlich bekomme ich dann zu hören, dass wir doch auf Retrospektiven, Reviews und Co. verzichten könnten. Aber halt, nicht Scrum oder Kanban oder was auch immer sind das Problem. Es sind die zusätzlichen Termine, die dazukommen. Genauso abstrus übrigens, wenn man OKR-Meetings obendrauf packt, wenn der Personenkreis identisch ist, anstatt sie in bestehende Austauschrunden zu integrieren. Auch so ein Thema. Wie Mike Cohen zeigt, sind die „Scrum Events“ durchdacht, auch mit dem Ziel, die Zahl der Meetings zu reduzieren und die bestehenden nicht unnötig aufzublähen. Vorausgesetzt, man denkt an den ebenfalls heute verlinkten Beitrag von Simon Flossmann, hat man Klarheit, Struktur, Fokus und Richtung sowie eine klare Minimierung von Abhängigkeiten (die besonders große Treiber von Abstimmungsrunden sein können).
https://www.mountaingoatsoftware.com/blog/do-scrum-teams-meet-too-much
Retrospektiven | Mögliche Dysfunktionen und wie wir ihnen entgegenwirken können
Gute Retrospektiven liefern klare und zielgerichtete Verbesserungen für das Team. Auch hier gilt: Weniger ist mehr. Und nein, eine Retrospektive ist keine verlorene Zeit, wenn sie gut ist und zu Ergebnissen führt, die umsetzbar sind und weiterbringen. Die Vorbereitung und Durchführung einer Retro ist also nicht so trivial, wie manche meinen. Praxistipp von mir übrigens: Zwischen den Retros kleine „Reflexionseinheiten“ einbauen. Mal hier zwei Minuten im Daily, mal dort zwei Minuten im Refinement abzweigen und sammeln, wo der Schuh immer wieder drückt. Das Ganze sichtbar festhalten, damit es alle im Team mitbekommen und et voilà – als Scrum Master:in hat man eine Richtung und kann zielgerichtet in die Vorbereitung gehen. Damit haben wir sogar schon zumindest zwei der von Piyush Rahate beschriebenen Dysfunktionalitäten der Retrospektive etwas entgegengesetzt.
https://www.scrum.org/resources/blog/sprint-retrospective-dysfunctions-and-how-overcome-them
Produktentwicklung | Neues erschaffen bedeutet Arbeiten unter Unsicherheit
In diesen Tagen war ich wieder einmal überrascht, wie schwer es einigen meiner Kollegen fällt, zu akzeptieren, dass Produktentwicklung in erster Linie explorativ und damit mit großen Unsicherheiten behaftet ist. Und das, obwohl sie im Produktmanagement arbeiten. Genau diese Zielgruppe spricht Jan-Wilhelm Ageling mit seinem Beitrag an. Oder besser gesagt, für diese Zielgruppe wäre der Beitrag hervorragend geeignet. Er hat ihn treffend mit „8 Product Management Hacks“ überschrieben und das Ganze auch so präsentiert. Für echte Agilisten dürften das keine überraschenden Tipps sein. Nur leider sind echte Agilisten – trotz des vermeintlichen Erfolgs der Agilität – eine seltene Spezies. Meist trifft man eher auf Agilelogen, Methodenfetischisten und Beratungsesoteriker. Entschuldigung, wenn ich jetzt jemandem auf den Schlips getreten bin. Es musste einfach mal raus.
https://ageling.substack.com/p/8-product-management-hacks-6f4
Messbarkeit von Erfolgen | Nicht zu eng denken, sondern Raum lassen
Etwas ähnlich, aber nicht ganz die Zielgruppe, ist das Thema von Stephanie Ockerman. Sie zielt hier eher auf das Management als solches, das ja gerne alles zahlenaffin messen möchte. Durchaus legitim. Nur haben wir hier die besondere Herausforderung, dass, wenn wir uns im Kontext der explorativen Neuentwicklung bewegen, wir uns eben nicht darauf festnageln lassen können, Erfolge kleinteilig messen zu können, sondern wir müssen zumindest kurzfristig Rückschläge akzeptieren. Das liegt in der Natur der Komplexität, deretwegen wir eben explorativ unterwegs sind. Hier die Balance zu halten zwischen Fortschrittsmessung und Raum für Experimente zu lassen, ist eine wesentliche Kompetenz, die Führung entwickeln muss. Sonst funktioniert Agilität leider nicht.
Testing | Braucht es eine eigene Test-Spalte auf dem Scrumboard?
Interessant finde ich den Beitrag von Sebastian Stautz. Zum einen teile ich die Meinung, dass im agilen Kontext die Vorstellung eines sequentiellen Prozesses von Entwicklung und Test nicht gerade das erstrebenswerteste Ziel ist und durchaus problematisch werden kann. Im Idealfall ist das Testen von der Anforderung bis zur Auslieferung im Boot. Braucht es eine „Test-Spalte“ auf einem Scrum-Board? Folgt man seiner Argumentation, sollte sich diese Frage in den meisten Fällen erledigt haben. Gründe, die ich auch teile. Übrigens habe ich diese Diskussion vor einigen Monaten selbst in einem Team geführt, das sich explizit eine Test-Spalte gewünscht hat. Ich habe den Bedarf nicht gesehen. Da es nicht unsere dringendste Herausforderung war, habe ich das Thema hinten angestellt und bin dem Wunsch des Teams gefolgt. Zumal die Zusammenarbeit zwischen Entwicklern und Testern sehr gut funktioniert und harmonisch ist, die Testexperten schon bei den Anforderungen mit am Tisch sitzen und mitreden und wir – aus regulatorischen Gründen – bestimmte Anforderungen vor der Auslieferung explizit testen müssen. Es gibt also durchaus gute Gründe für gelegentliche Ausnahmen. Übrigens ein schönes Beispiel dafür, wie unterschiedliche Arten von Arbeit über das Board wandern, denn nicht alles landet „In Test“ 😉
https://agilereflection.org/warum-eine-test-spalte-auf-boards-ein-problem-darstellt/
Agile Coaching | Wirkmächtige Fragen
Zum Schluss habe ich noch eine Liste mit kraftvollen agilen Coaching-Fragen von Bob Galen. Wir alle wissen, wer fragt, führt und gute Fragen lösen so manchen gordischen Knoten. Am Ende des Tages ist es das Ziel eines jeden Servant Leaders, die Selbsthilfefähigkeit aller Beteiligten zu verbessern. Deshalb gehören Coaching-Fragen in den Werkzeugkasten 😉
https://bobgalen.substack.com/p/agile-mooses-list-of-powerful-agile
Management und Leadership
Selbstmanagement, Macht und Selbstausbeutung | Wo Licht ist, da ist auch Schatten
Stephanie Borgert war schon lange nicht mehr in den Links der Woche. Das ist mir beim Schreiben aufgefallen. Perfekt, dass sie heute wieder dabei ist. Mit einem durch und durch spannenden Thema: Selbstmanagement und Selbstausbeutung. Durchaus ein Spannungsfeld, das regelmäßig reflektiert werden will. Wir bewegen uns in einem Spannungsfeld, in dem gut gemeintes, selbstbestimmtes Arbeiten im Team durch Gruppendynamik in Selbstausbeutung münden kann. Noch einmal das Thema der Reflexion über die Legitimität von Macht und Machtausübung, das immer wieder auftaucht. Auch wenn es manche nicht gerne hören.
Toms Gedankenblog 