Backlog für alle: Wo bleibt das Commitment vom Fachbereich?

Als Product Owner braucht mich keiner von den Vorteilen interdisziplinärer Teams zu überzeugen. Leider finde ich diese Rahmenbedingung nur selten vor. Ganz nüchtern betrachtet spiegeln die Unternehmen nach Einführung von Scrum oder Kanban immer noch die alteingesessenen Abteilungsstrukturen wider. Eine Abteilung, die IT, arbeitet jetzt halt „agil“.
Die Priorisierung des Backlogs artet in dieser Konstellation für den PO zum Kampf mit der Hydra aus. Möchte ich als PO z.B. noch schnell eine Story zur neuen Zahlungsart „Sofortüberweisung“ entwickeln lassen, muss ich mich nun mit mindestens zwei weiteren Köpfen herumschlagen. Auf der einen Seite klopfe ich leise bei der Leitung der Konzeptionsabteilung an und frage nach, ob eine Ressource für die fachliche Definition der Schnittstelle zur Verfügung steht. Auf der anderen Seite feilsche ich mit der Leitung der Testabteilung um Tester. Es stellt sich heraus, dass ein Mitarbeiter im Urlaub ist und die Tests zu den Zahlungsarten sehr aufwändig sind. Die Tests werden nur dann rechtzeitig vor Weihnachten fertig, wenn ich auf die Inbetriebnahme der neuen Abonnementmodelle verzichte. Ich gehe in mich und entscheide mich um, da die Abonnementmodelle mehr Umsatz bringen. Mit der nächsten umpriorisierten Story geht das Spiel von vorne los.
Das Management lernt in der Regel die hohe Transparenz von agilen Methoden sehr rasch zu schätzen. Plötzlich sieht und versteht man mithilfe von Backlog und User Storys was „diese Entwickler“ da eigentlich machen. Transparenz macht natürlich auch angreifbar. Als PO ist es nichts Außergewöhnliches nach einem abgeschlossenen Sprint vor die Geschäftsführung geladen zu werden. Fragen zur sinkenden Velocity, Prio-1-Blockern oder Releaseverzögerungen können aber souverän beantwortet werden, wenn man während des Sprints sein Team aktiv begleitet hat.
Je selbstorganisierter ein Team arbeitet, desto mehr Freiraum sollte der PO auch haben, um diese wichtigen Gespräche mit dem Management zu führen. Schließlich können hier die kontinuierlichen Prozessverbesserungen am effektivsten platziert werden. Eine Antwort auf die sinkende Velocity könnte beispielsweise lauten, dass die Entwickler statt zu entwickeln viel Zeit mit Rückfragen an den Fachbereich verschwendet haben. Statt noch mehr Entwickler einzustellen, um die Velocity zu erhöhen, sollte lieber ein zusätzlicher Konzeptioner eingestellt oder die Qualität der Storys verbessert werden.
Als PO sind Sie somit gezwungen, stets über den Tellerrand ihrer IT-Scrum-Abteilung zu schauen, damit das Gesamtsystem funktioniert. Den Verzug im Fachbereich oder in der Testabteilung sieht am Schluss niemand, wenn ein Feature nicht wie vom PO versprochen live genommen wird.
Bei einem Sprint Planning sprach mich ein Entwickler einmal direkt auf dieses Ungleichgewicht an: „Warum muss der Fachbereich eigentlich nicht auch committen?“
Warum war ich, die selbst unter der Hydra litt, nicht früher darauf gekommen? Wir führten umgehend ein Backlog für Fachbereich und Tester ein, das ebenfalls nach einem „fachlichen Sprint-Planning“ committed wurde. Diese Prozessoptimierung half besonders mir als PO, die User Storys besser und schneller zu priorisieren. Wir konnten alle trotz getrennter Abteilungen eine interdisziplinäre Transparenz und gegenseitiges Verständnis aufbauten.
Damit keine Abteilung leer zu laufen drohte, fingen wir zudem immer stärker an, den Scrum-Arbeitsfluss auf aggregierter Sprintziel-Ebene wie ein Kanban-System zu steuern. In der folgenden vereinfachten Abbildung ist der Work in Progress = „ein Sprintziel“. PO und Abteilungsleiter saßen dann zusammen und diskutierten wie die Ziele mit der aktuellen Ressourcenlage erreicht werden könnten. Als PO stellte ich beispielsweise einen Sprint lang der Konzeptionsabteilung einen Entwickler zur Mitarbeit an einer Analyse zur Verfügung, damit die User Storys rechtzeitig zum nächsten Sprint Planning fertig wurden.

Es fühlte sich am Schluss an als würde man tatsächlich mit einem einzigen – wenn auch sehr großen – interdisziplinären Team zusammenarbeiten. Manche organisatorischen Veränderungen brauchen ihre Zeit. Ich kann jedem PO daher anraten, stets den Mut für ein paar kleine Schritte aufzubringen. Wenn es besser läuft, laufen automatisch alle anderen auch mit.