Produktivität
Persönliche Produktivität | Der verzweifelte Versuch, systemische Fehler der Organisation zu beheben
Ein sehr kritischer Beitrag von Marcus Raitner, der aber auf den Punkt bringt, was in vielen Organisationen gang und gäbe sein dürfte: Persönliche Produktivität als Versuch, die Folgen systematisch schlechter Organisation auf individueller Ebene abzumildern. In diesem Zusammenhang fällt mir Jim Benson mit seinem Buch Why Limit WiP ein. Eine zentrale Forderung des Buches: WiP-Limits für Themen oberhalb der Teamebene mit Leben zu füllen. Eine Organisation, die zu viele Themen gleichzeitig bearbeitet, fördert den organisationalen Burnout. Passt gut zum Beitrag von Marcus. Verzweifelt wird versucht, die systemischen Mängel der Organisation auf individueller und Teamebene zu kompensieren. Kann nicht gelingen.
https://raitner.de/2024/06/der-grausame-optimismus-persoenlicher-produktivitaet/
Zielvereinbarungsgespräche | Weshalb sie oft scheitern
Führen mit Zielen ist immer noch weit verbreitet. Doch die Fehler, die Dan Rockwell hier beschreibt, treffen auch auf die individuelle Zielsetzung zu: Hindernisse ignorieren, Motivation unterschätzen, keine Verantwortlichkeit schaffen, keine Reflexion. Alles dabei.
https://leadershipfreak.blog/2024/06/26/4-reasons-goal-setting-conversations-fail-and-how-fix-them/
MAC | Kurzbefehle fürs Fenstermanagement
Der folgende Tipp richtet sich an MAC-User. Wir Windoofs-User gehen leider leer aus, aber damit kann ich leben. Wer aber einen MAC hat, sollte den Hinweis von Thomas Mathoi hilfreich finden. Aus eigener Erfahrung kann ich das leider nicht bestätigen. Vielleicht findet sich ja jemand, der einen Kommentar hinterlässt.
https://www.mathoi.at/2024/06/28/fenstermanagement-am-mac-mit-kurzbefehlen/
Agile
Stakeholder Management | Wie es gelingt als PO freundlich Nein zu sagen
Zentrale Aufgabe des Product Owners ist das Stakeholder Management. Und bitte beachten: Stakeholder sind NICHT nur die zahlenden Kunden. Gerne werden die „Lieferanten“ vergessen, die nicht weniger zum Erfolg beitragen. Ein gutes Verständnis dafür, wie Stakeholder ticken und was sie brauchen, um eine vertrauensvolle Beziehung aufzubauen, ist essentiell. Gerade dann, wenn nicht alle Wünsche und Vorstellungen erfüllt werden können. Die hohe Kunst des Nein-Sagens gehört daher zu den Kernkompetenzen guter Product Owner. Genau damit beschäftigt sich Simon Flossmann in folgendem Blogbeitrag, der einige sehr gute Punkte enthält, auch wenn ich den Superlativ in der Überschrift (Ultimative Anleitung) für deutlich übertrieben halte. Kleine Randbemerkung, weniger reißerische Überschriften zu wählen und mehr durch gute Zusammenfassungen auf den Inhalt neugierig zu machen, würde uns allen gut tun. Aber das ist ein anderes Thema.
Reflexion | Sind wir in der Community zu „arrogant“ geworden?
Sind wir in unserer agilen Gemeinschaft arrogant und überheblich geworden? Diese Frage hat auch mich schon beschäftigt. Und manchmal möchte ich sie bejahen. Vielleicht mit einem etwas anderen Fokus als Christiaan Verwijs hier. Und doch entdecke ich in seiner Argumentation einige Parallelen zu meinen Gedanken. Auf jeden Fall möchte ich ihm zustimmen, dass wir in der agilen Community (endlich) anfangen müssen, von dem „hohen Ross“ herunterzusteigen, auf das wir uns selbst gesetzt haben. Die „Krise der Agilität“ könnte dazu eine Chance sein.
Agile Coaching | Braucht es das noch oder kann es weg?
Passend zum vorigen Thema der Beitrag von Wilhelm-Jan Ageling über die Zukunft des agilen Coachings. Ein Begriff, der mir immer weniger gefällt. Auch wenn ich ihn für notwendig halte. Der Begriff scheint mir zu oft in die Irre zu führen. Vielleicht finden wir einen passenderen Namen. Wichtig ist auf jeden Fall, dass wir uns wieder mehr darauf besinnen, worum es bei Agilität eigentlich geht. Und hier trifft der Autor den Nagel auf den Kopf: „Creating valuable products“ und agile Teams sind dabei „nur“ das Mittel zum Zweck, nicht der Zweck selbst. Zurück zum Kernthema. Agiles Coaching“ wird es auch in Zukunft geben. Der Bedarf ist da. Keine Frage. Wahrscheinlich unter einem anderen Namen, weil der Begriff irreführend ist. Wer weiß. Bleibt abzuwarten. Und ja, ich glaube, es gibt eine Krise. Aus dieser Krise entsteht hoffentlich die Rückbesinnung auf das Wozu, von dem ich vorhin gesprochen habe.
https://ageling.substack.com/p/the-future-of-agile-coaching
Agile Krise | Ist Agilität tot oder einfach nur „normal“ geworden?
Und noch einmal – ein ähnliches Thema – diesmal von Mike Cohen, einem agilen Urgestein. Auch er beschäftigt sich mit der „agilen Krise“. Im Gegensatz zu vielen anderen Autoren sieht er in der „vermeintlichen“ Krise eher eine Normalisierung. Und da möchte ich ihm fast zustimmen. Ja, es mag eine Krise geben. Die Goldgräberstimmung ist vorbei. Ich kann heute nicht mehr jeden Mist verkaufen, nur indem ich agil davor stehe. Und das ist gut so. Ich hoffe sehr, dass wir ein gesundes Verständnis dafür bekommen, wann der agile Weg der zielführendere ist und dass wir an den Punkt kommen, an dem wir die beidhändige Organisation in den Mittelpunkt stellen, die je nach Situation zwischen stabil und agil wechseln kann. Das hoffe ich zumindest. Denn beides bedingt einander.
https://www.mountaingoatsoftware.com/blog/is-scrum-dead-is-agile-dead
Velocity | Durchsatz ist keine Erfolgsmetrik
Noch einmal für alle zum Mitschreiben: Durchsatz oder Geschwindigkeit sind keine Erfolgsindikatoren. Sie sagen nichts darüber aus, ob wir einen Mehrwert schaffen. Sie sind reine Flussmetriken, mit denen wir sichtbar machen können, ob es irgendwo im Fluss ein Problem gibt. Man sollte meinen, dass sich das herumgesprochen hat. Meine Beobachtung ist, dass es immer noch genug Leute gibt, die sich zu sehr auf Flow Metrics konzentrieren und damit ungesunde Entwicklungen auslösen. Der Blogartikel von Mary Iqbal zeigt noch einmal deutlich, dass Velocity kein gutes Kriterium ist, um ein Scrum Team zu bewerten. Noch einmal für alle: Velocity ist eine Flow-Metrik des Teams für das Team und keine „Performance-Metrik“ für das Management.
https://www.scrum.org/resources/blog/dont-confuse-velocity-success
Agiles Schätzen | Die Herausforderungen rund um Story Points
Das „agile“ Schätzen mit Story Points ist einfach und doch sehr komplex, wie auch Piyush Rahate gut beschreibt. Ich persönlich bin der Meinung, dass Schätzen in erster Linie ein Feedback über die Größe der Product Backlog Items und deren Zuschnitt ist. Ab einer gewissen Größe sind, wenn man die Komplexität als Maßstab nimmt, die möglichen Störgrößen nur noch schwer „beherrschbar“. PBIs sollten daher nicht nur in einer Iteration realisierbar sein, sondern auch eine Größe haben, mit der man mit möglichen Unbekannten gut umgehen kann.
https://www.scrum.org/resources/blog/story-points-estimate-or-not-estimate
Runaway Effect | Weshalb man technische Schulden möglichst schnell auflösen sollte
Was ich aus der Beschäftigung mit Monozukuri und Kaizen gelernt habe, lässt sich wie folgt zusammenfassen: Behebe Fehler so schnell wie möglich. Am besten sofort. Sonst wird der Spaß richtig teuer. Dafür gibt es sogar einen schönen Namen, wie ich von Felix C. Stein gelernt habe. Stein gelernt habe: Runaway Effect. Er bezieht sich auf die Software-Entwicklung. Er beschreibt ziemlich treffend, wie technische Schulden, die nicht so schnell wie möglich aufgelöst werden, zu einem großen Problem werden können.
https://www.lean-agility.de/2024/06/runaway-effect.html
Effectuation | Das Prinzip des leistbaren Verlusts
Effectuation, der Umgang mit echter Unsicherheit, ist ein spannender Ansatz. Gerade das Prinzip des erträglichen Verlusts finde ich für die Praxis spannend. Was kann ich umsetzen, ohne dass mich der mögliche Verlust zu viel „kostet“? Dieser Ansatz hat mir schon oft geholfen, die innere Hürde zu überwinden und mich auf sehr vage Möglichkeiten einzulassen, um zu sehen, ob sich daraus etwas entwickeln kann. Ein spannendes Konzept also, das Michael Schenkel hier vorstellt:
https://t2informatik.de/blog/prinzip-des-leistbaren-verlustes/
Toms Gedankenblog 