Im Laufe der letzten Monate haben wir festgestellt, dass die Umsetzung unserer Anforderungen oft zu Rückfragen und Richtungsänderungen geführt hat. Während der Arbeit änderten sich fachliche Anforderungen oder es kamen zusätzliche “Features” hinzu, die als “Trittbrettfahrer” mitgenommen wurden. Wir mussten deshalb immer wieder bereits begonnene Arbeit korrigieren.

Unser “agiler” Ansatz hatte dazu beigetragen, dass wir diese Änderungen laufend aufgenommen haben. Flexibel waren wir damit durchaus. Aber die Umsetzung wurde auch immer wieder zum Ort, an dem wir erst klärten, was wir eigentlich bauen wollten.

Das war der Anlass, unsere Anforderungsermittlung und die Zusammenarbeit genauer anzuschauen. Daraus sind strukturiertere Fachkonzepte, die Wiedereinführung geschützter Sprints und wöchentliche Story-Reading-Termine entstanden. Für mich steckt darin vor allem ein Thema, das mich als Führungskraft beschäftigt: Wie unterstütze ich meine Product Owner dabei, sich weiterzuentwickeln und selbst Verantwortung zu übernehmen?

Ich habe das Konzept in Gesprächen mit einem meiner Product Owner vorgestellt und ihm ein Beispiel gegeben. Die Einführung mit dem Kunden und dem Team hat er anschließend selbständig übernommen.

Gerade dieser zweite Teil ist für mich entscheidend. Er hängt mit einer Aufgabe zusammen, die mich schon länger begleitet: selbst aus dem Operativen herauszukommen und meinen Product Ownern den Raum zu geben, ihren Bereich eigenständig weiterzuentwickeln.

Warum ein Fachkonzept?

In einem früheren Beitrag habe ich darüber geschrieben, wie wichtig es ist, hinter einer Anforderung den eigentlichen Mehrwert zu finden. Wenn ein Kunde eine zusätzliche Spalte im Excel haben möchte, ist damit noch lange nicht klar, welches Problem wir lösen sollen.

Auch wenn wir das Problem verstanden haben, geht die Arbeit weiter. Wie soll der fachliche Ablauf aussehen? Welche Regeln gelten? Was ist noch offen? Und verstehen Kunde, Product Owner und Entwickler tatsächlich dasselbe darunter?

Genau dabei soll uns ein strukturierteres Fachkonzept helfen. Es gibt dem Gespräch einen Rahmen und macht das gemeinsame Verständnis nachvollziehbar.

Eine mögliche Struktur lässt sich schon mit wenigen Fragen beschreiben:

  • Problem und Ziel: Was soll sich für den Kunden verbessern?
  • Fachlicher Ablauf: Was passiert in welcher Reihenfolge und wer ist beteiligt?
  • Regeln und Ausnahmen: Was muss gelten und welche Sonderfälle müssen wir berücksichtigen?
  • Abgrenzung: Was gehört zu dieser Anforderung und was bleibt erstmal außen vor?
  • Offene Fragen: Was wissen wir noch nicht und mit wem müssen wir es klären?

Das ist als Beispiel gedacht. Wie viel davon nötig ist, hängt vom jeweiligen Thema ab. Für eine kleine Änderung braucht es sicherlich keinen Roman. Bei einem komplexeren Ablauf reicht dagegen ein Satz im Ticket vermutlich nicht aus.

Aus den Fachkonzepten ergeben sich dann die einzelnen Storys. Damit haben wir einen fachlichen Zusammenhang, auf den wir uns beim Zuschnitt und bei Rückfragen beziehen können. Auch zusätzliche Wünsche lassen sich so besser einordnen: Gehören sie zum vereinbarten Ziel oder erweitern sie den Umfang?

Mein erster Beitrag: den Ansatz greifbar machen

Ich hätte die neue Vorgehensweise selbst im Team vorstellen können. Vorlage zeigen, Erwartungen erklären, Einführung begleiten. Als Verantwortlicher für den Bereich wäre das durchaus möglich gewesen.

In diesem Fall habe ich den Weg über meinen Product Owner gewählt. In unseren Gesprächen habe ich das Konzept vorgestellt und mit einem Beispiel greifbar gemacht.

Ein Beispiel hilft mir dabei oft mehr als eine abstrakte Erklärung. “Wir brauchen bessere Fachkonzepte” lässt ziemlich viel Raum für Interpretation. An einem konkreten Beispiel lässt sich besprechen, welche Informationen hilfreich sind und warum die Struktur einen Nutzen haben könnte.

Diese Form der Unterstützung meine ich hier mit Coaching: Ich bringe meine Erfahrung ein und gebe meinem Gegenüber etwas, mit dem er weiterarbeiten kann. Das Beispiel schafft eine gemeinsame Grundlage für das Gespräch. Entscheidend ist, dass mein Product Owner den Ansatz versteht, sich eine eigene Einschätzung bildet und ihn auf seine Situation übertragen kann.

Geschützte Sprints und Story-Reading

Mein Coaching ging dabei über die Fachkonzepte hinaus. Wir haben auch über die Wiedereinführung geschützter Sprints und wöchentlicher Story-Reading-Termine gesprochen. Die drei Elemente greifen für mich ineinander.

Mit geschützten Sprints wollen wir dem Team einen verlässlicheren Rahmen für die Umsetzung geben. Zusätzliche Features sollen nicht einfach als Trittbrettfahrer in die laufende Arbeit rutschen. Neue Wünsche brauchen eine bewusste Entscheidung über Priorität und Umfang. Sonst wird aus einer zunächst überschaubaren Story während der Umsetzung etwas deutlich Größeres.

Die Story-Reading-Termine setzen früher an. Jede Woche schauen wir gemeinsam auf anstehende Storys und prüfen sie auf Unklarheiten: Ist der Ablauf verständlich? Sind die fachlichen Regeln klar? Fehlen Ausnahmen? Und wissen wir, woran wir erkennen, dass die Anforderung erfüllt ist?

Solche Fragen wollen wir möglichst klären, bevor die Umsetzung beginnt. Auf Grundlage der Fachkonzepte und durch das frühe gemeinsame Lesen sind klarere Storys entstanden. Die Entwickler können ihr Verständnis einbringen und offene Punkte werden sichtbar, solange wir sie noch ohne Korrektur bereits umgesetzter Arbeit klären können.

Natürlich werden wir während der Entwicklung weiterhin etwas lernen und Anforderungen anpassen müssen. Mir geht es darum, bewusster mit diesen Änderungen umzugehen. “Agil” sollte für uns kein Grund sein, vermeidbare Unklarheiten bis in die Umsetzung mitzunehmen oder zusätzliche Wünsche nebenbei unterzubringen.

Der nächste Schritt lag bei ihm

Anschließend hat mein Product Owner das Konzept selbständig mit dem Kunden und dem Team eingeführt.

Damit lag bei ihm mehr als die Weitergabe einer Vorlage. Er musste den Ansatz erklären, mit den Beteiligten besprechen und in die Zusammenarbeit einbringen. Das ist eine andere Aufgabe als ein Dokument auszufüllen.

Für mich ist das der Teil der Delegation, der zur Entwicklung beiträgt: Mein Product Owner übernimmt die Umsetzung und gestaltet sie mit den Menschen, mit denen er täglich arbeitet. Er kennt den Kunden und das Team. Er muss dort auch künftig mit der Vorgehensweise arbeiten können.

Meine Rolle ist dabei, Unterstützung anzubieten und für Rückfragen erreichbar zu bleiben. Die Verantwortung für die Einführung liegt bei ihm. Wenn ich die Gespräche mit Kunde und Team dann doch selbst führe, nehme ich ihm genau die Gelegenheit, die ich ihm eigentlich geben wollte.

Was das mit der Entwicklung meiner Product Owner zu tun hat

In meinem Beitrag über unser Team-Offsite habe ich beschrieben, dass unsere Product Owner auch fachliche Führung übernehmen. Dazu gehört für mich, die Zusammenarbeit weiterzuentwickeln und Veränderungen mit Kunde und Team umzusetzen.

Genau dafür bieten aktuelle Themen eine gute Gelegenheit. Die Entwicklungsaufgabe ergibt sich aus der Arbeit, die ohnehin ansteht. In diesem Fall: verstehen, wie Fachkonzepte, Story-Reading und geschützte Sprints zusammenwirken, ihren Nutzen vermitteln und die Zusammenarbeit mit den Beteiligten weiterentwickeln.

Für die Entwicklung meiner Product Owner muss ich Raum lassen. Dazu gehört, dass sie einen Ansatz anders erklären oder umsetzen, als ich es getan hätte. Sonst delegiere ich zwar eine Aufgabe, behalte aber jede Entscheidung bei mir.

Raus aus dem Operativen

Das fordert auch mich. Wenn ich eine Vorstellung davon habe, wie etwas funktionieren könnte, liegt es nahe, die Umsetzung gleich selbst mitzuübernehmen. Fachlich kann ich etwas beitragen, ein Problem lösen und unmittelbar ein Ergebnis sehen. Das fühlt sich erstmal gut an. Man hat etwas geschafft.

Bei Führungsarbeit ist das oft schwieriger. Nach einem Gespräch über einen neuen Ansatz gibt es vielleicht noch kein fertiges Dokument und keine sichtbare Veränderung im Team. Es braucht weitere Gespräche, eigene Erfahrungen und Zeit, bis jemand sicher genug ist, das Thema selbst voranzubringen.

Wenn ich in dieser Phase wieder selbst übernehme, erledige ich zwar die aktuelle Aufgabe. Gleichzeitig gewöhnen wir uns aber daran, dass ich bei solchen Themen doch wieder derjenige bin, der sie vorantreibt. Und beim nächsten Mal stecke ich erneut mitten im Operativen.

“Raus aus dem Operativen” bedeutet für mich deshalb, meine Zeit bewusst anders einzusetzen: für Gespräche mit meinen Product Ownern, für Orientierung und für die Entwicklung ihrer Fähigkeiten. Dazu gehört auch, auszuhalten, dass eine Umsetzung Zeit braucht und ich ihren Verlauf nicht in jedem Detail bestimme.

In diesem Fall habe ich mein Wissen in die Gespräche und das Beispiel eingebracht. Mein Product Owner hat die Einführung übernommen. So kann ich fachlich unterstützen und ihm gleichzeitig die Verantwortung überlassen, die zu seiner Rolle gehört.

Führungsarbeit braucht Geduld

Schon in einem älteren Beitrag hat mich die Frage beschäftigt, wie sich der Wertbeitrag einer Führungskraft messen lässt. Dieses Beispiel passt für mich gut dazu.

Ein großer Teil dieser Arbeit passiert im Hintergrund. Gespräche, in denen man einen Gedanken gemeinsam sortiert. Ein Beispiel, an dem ein Ansatz verständlich wird. Rückfragen und die Entscheidung, dem anderen die Umsetzung zu überlassen. Das lässt sich am Ende einer Woche schwer neben erledigte Tickets legen.

Die Früchte zeigen sich häufig erst mittel- bis langfristig: wenn ein Product Owner ähnliche Themen eigenständig erkennt, einen passenden Ansatz entwickelt und Veränderungen mit Kunde und Team umsetzt. Bis dahin kann Führungsarbeit langwierig sein. Ein gutes Gespräch allein macht noch keine dauerhafte Veränderung.

Mit den Fachkonzepten und den wöchentlichen Story-Reading-Terminen sind klarere Storys entstanden. Die geschützten Sprints sollen uns helfen, diese Grundlage während der Umsetzung zu bewahren. Wie dauerhaft wir damit Rückfragen, Richtungsänderungen und Korrekturen reduzieren können, muss sich über die nächsten Monate zeigen. Für mich ist dabei auch relevant, dass mein Product Owner den Weg vom besprochenen Ansatz zur Einführung der Fachkonzepte selbständig gegangen ist.

Darauf möchte ich aufbauen. Ich will, dass meine Product Owner mit der Zeit mehr solcher Themen selbst voranbringen können. Dafür muss ich heute Zeit investieren und ihnen Verantwortung überlassen, auch wenn ich den Nutzen dieser Arbeit erst später vollständig sehe.