Kommentierte Links (LXXV)
Das Thema Business Value, bzw. dessen Bestimmung und Messung ist einer der grossen Klassiker für agile (und nicht-agile) Teams, Produktmanager und Unternehmen. Was Kai Pukall hier zurecht anmerkt ist, dass es sich dabei grösstenteils um Business-Theater handelt. Die Zukunft vorauszusagen (und mit ihr die Gewinne oder Einsparungen die sich mit einem Produkt oder Feature erzielen lassen) ist nicht möglich, aber ganz umsonst ist die Beschäftigung mit dem Thema nicht - es lassen sich so Indikatoren, Wahrscheinlichkeiten und Risiken identifizieren. Aus meiner persönlichen Erfahrung würde ich noch einen weiteren oft unterschätzten Mehrwert von Business Value-Diskussionen einwerfen: sie helfen dabei Anforderungen aus den Backlogs und Roadmaps herauszunehmen die fast keinen Wert haben, aber trotzdem irgendwann eingeplant wurden. Das ist oft schmerzhaft, bringt aber sehr viel.
Apropos herausnehmen. Was hier ein "Autorenkollektiv" aus den Firmen Reforge und Mixpanel zusammengetragen hat ist die umfangreichste Auseinandersetzung mit dem Thema des Ausbauens von Produkt-Features die ich bisher gelesen habe. Angefangen bei den Gründen dafür (Spoiler: es gibt auch gute Gründe für das Entfernen von Features deren Einführung Sinn gemacht hat), über die technischen, menschlichen und wirtschaftlichen Probleme die dabei auftreten können bis hin zu den Erfolgsfaktoren und notwendigen oder hilfreichen organisatorischen Rahmenbedingungen. Ein Text der jedem Product Owner und Produktmanager wärmstens zu empfehlen ist.
Vor allem in grossen Organisationen ist eines der grössten Hindernisse für positive Veränderungen die weit verbreitete Meinung, selbst nicht der Lage zu sein dazu beitragen zu können (→
Untertanenkultur). Dass das nicht so ist wird zwar von Change Managern und Agile Coaches immer wieder betont, wie es vor sich gehen kann wird aber häufig nicht gesagt. Steve Denning stösst in diese Lücke und gibt eine gute Anleitung zum Verändern einer Organisation "von unten". Wie immer muss zwar auch hier klar sein, dass es sich um eine Inspiration handelt und nicht um eine Blaupause, es ist aber auf jeden Fall vieles dabei was sich in fast jedem Kontext anwenden lässt.
Das Explizit machen von Regeln ist einer der grossen Klassiker im Rahmen agiler Transitionen und führt immer wieder
zu wertvollen Erkenntnissen. Das gilt bereits dann wenn Teams in Co-Location zusammensitzen, es gilt aber nochmal verstärkt im Fall von Remote-Arbeit. Was Jason Yip völlig zu Recht anmerkt ist, dass in diesem Fall die implizite Kommunikation wegfällt, sowohl in Bezug auf das weniger sichtbar werdende Verhalten der anderen Teammitglieder als auch in Bezug auf die abnehmbare Sichtbarkeit der Aktionen von Experten und erfahrenen Kollegen, an denen andere (bewusst oder unbewusst) ihre Handlungen ausgerichtet haben. Yip geht soweit, dass er nicht nur das Explizit Machen von Arbeits- und Entscheidungsprozessen sondern auch von Informationsströmen empfiehlt, um so in Summe alles abzubilden was für die Produktentwicklung relevant ist.
Ich gebe zu, auch ich neige vermutlich manchmal dazu, im Kanban-Umfeld (zu) viele japanische Lehnwörter zu benutzen. Aus diesem Grund fühlte ich mich leicht ertappt als Gojko Adzic mit seinem japanisch klingenden (?) Begriff "Nijute" ein bisschen die Agile-Community trollte, bei dem es sich in Wirklichkeit um die Abkürzung für "Not Impossible, Just Too Expensive" handelt. Unanhängig von diesem Hintergrund kann man ihm nur zustimmen, dass "möglich, aber zu teuer" bei Machbarkeitsdiskussionen ein besseres Argument ist als das häufig benutzte "das geht nicht". Weshalb das so ist und warum hinter dieser Aussage mehr steckt als im ersten Moment zu vermuten kann man schön herausgearbeitet bei ihm nachlesen.
