Kommentierte Links (LXXII)
Auf den ersten Blick eine unverständliche Frage. Product Owner findet man mittlerweile in gefühlt jeder zweiten IT-Abteilung, ihre Existenz dürfte also gesichert sein. Auf den zweiten Blick ist sie aber gar gar nicht so abwegig, denn bei einer radikalen Auslegung des Scrum Guide könnte man tatsächlich Zweifel haben. Besonders der
im Scrum Guide stehende Satz "For Product Owners to succeed, the entire organization must respect their decisions" wird in diesem Zusammenhang immer wieder aufgeführt, häufig verbunden mit der (in den meisten Firmen völlig unrealistischen) Forderung, dass das so weit gehen müsste, dass der Product Owner sich gegebenenfalls ohne Rücksprachen entscheiden könnte das Produkt einzustellen. Willem-Jan Ageling nimmt
eine solche Aussage Anlass um etwas Kontext und Realismus in die Debatte einzubringen. Das vorweggenommene Fazit: Product Owner gibt es, und Maximalforderungen sind nicht hilfreich.
Dass eine immer stärkere
Aufblähung eines Produktes dazu führen kann, dass ein Team alleine nicht mehr die ausreichende Kapazität hat um es weiterzuentwickeln ist ein oft anzutreffendes Phänomen. Die häufigste Reaktion darauf ist das Hinzufügen weiterer Teams, deren gemeinsame Arbeit dann durch ein Skalierungsframework koordiniert wird (mit Bürokratie und Ineffektivität als häufiger Folge). Christiaan Verwijs hat einen anderen Vorschlag: warum nicht stattdessen das zu gross gewordene Produkt in mehrere kleine aufspalten, die dann wieder von jeweils einem Team verantwortet werden können? Passend dazu
ein ähnlicher Vorschlag von Sara Estes: man kann Produkte auch gesundschrumpfen indem man Features wieder entfernt.
Letzten Endes betont Jeff Gothelf hier einmal mehr,
dass organisatorische Silo-Strukturen problematisch sind. Er geht aber auch darüber hinaus und zeigt eine weitreichende Konsequenz auf: wenn man nicht mehr von wenigen zentralen Einheiten abhängig sein will dann führt kein Weg daran vorbei deren Aufgaben zumindest in Teilen selbst zu übernehmen. Sein Beispiel dafür ist HR, es liesse sich aber auch auf viele andere übertragen. Wer wirklich
crossfunktionale Einheiten anstrebt wird an derartigen Überlegungen nicht vorbeikommen.
Selbst wenn es in diesem Artikel in erster Linie um
Holokratie geht - das grundlegende Phänomen das Serafin Eilmes hier beschreibt lässt sich auch in nahezu jeder grösseren Organisation wiederfinden. Sobald der Umfang der Regeln die die Mitarbeiter zu befolgen haben eine bestimmte Schwelle überschreitet ist es für sie nicht mehr möglich den Überblick über alle Vorgaben zu behalten von denen sie betroffen sind. Im schlimmsten Fall ist die Menge der Vorschriften sogar so gross (und ggf. so verstreut gespeichert), dass es nicht mehr mit vertretbarem Aufwand möglich ist sie auf Relevantes zu durchsuchen. Die Folge: obwohl umfangreiche Regelwerke bestehen kommt es immer wieder vor, dass die regulierten Personen sich über deren Inhalt oder sogar Existenz im Unklaren sind. In Folge dessen wird einfach ein irgendwie sinnvoll scheinender Weg gewählt, der aber im Zweifel ein unbewusster Regelverstoss ist.
Bereits letzten Oktober habe ich in einem
Artikel von Cal Newport einen Denkanstoss bekommen. Newport geht davon aus, dass das von Peter Drucker eingeführte Führen mit Zielen (Management by Objectives) oft zu positiv gesehen wird, weil es in der Realität immer wieder dazu führt, dass Angestellte mit Zielen überhäuft aber mit der Umsetzung alleingelassen werden. Nachdem ich zwar die Absicht hatte darüber zu schreiben, es aber monatelang vor mir hergeschoben habe, ist mir Marcus Raitner jetzt zuvorgekommen. Besonders zwei der von ihm erörterten Aspekte finde ich wichtig: zum einen ist das was heute unter dem Namen Management by Objectives stattfindet nicht mehr das was Drucker erreichen wollte, aber zum anderen kann die Nutzung von iterativen Ansätzen wie Scrum dafür sorgen, dass es wieder dazu wird.
