Product Owner: Motor oder Sollbruchstelle agiler SW-Projekte? (Teil 2)
Dieser Beitrag ist der zweite Teil unserer Serie „Product Owner: Motor oder Sollbruchstelle agiler SW-Projekte?“ In Teil 1 habe ich beschrieben, warum Softwareprojekte oft (ca. 70%!) scheitern: Als häufige Ursache ist dabei schon immer die Qualität von Anforderungen identifiziert worden. Der Versuch, das Problem durch immer detailliertere Spezifikationen zu lösen, machte Projekte zunehmend langwieriger und starrer, aber nicht merklich erfolgreicher. Als Abhilfe und Gegenbewegung dafür wurde um die Jahrtausendwende die agile Softwareentwicklung eingeführt. Unter bestimmten Bedingungen kann diese Methodik wahre Wunder bewirken; sie hat den rasanten Aufstieg und die geschäftliche Agilität vieler Internet-Player ermöglicht. Doch sie ist kein Allheilmittel und erfordert bestimmte Voraussetzungen: Besonders in der „old economy“ sind viele Unternehmen von agilen Projekten ernüchtert und fragen sich, was sie falsch machen.
In diesem Teil beschäftige ich mich mit der Frage, warum die immanenten Probleme komplexer Softwareprojekte nicht automatisch verschwinden, wenn man z. B. auf Scrum setzt.
Scrum hat gar nichts mit Softwareentwicklung zu tun!
Scrum ist verführerisch einfach (siehe Grafik). In wenigen Minuten hat man Funktionsweise und Vorteile dieses Prozesses verstanden. Dieses schnelle Heilsversprechen ist sicher auch ein Grund für die weite Verbreitung. Aber: Die Einführung von Scrum führt nicht automatisch zu erfolgreichen Software-Projekten und schon gar nicht zu brillanter Software, wie Anwender sie im Netz und auf ihren Mobilgeräten heute erwarten (und zwar ganz selbstverständlich, dem Kano-Modell sei Dank). Wer aber diese Erwartungshaltung enttäuscht, kann auch als etabliertes Unternehmen der „old economy“ sehr schnell am Markt scheitern, denn ohne (gute) Digitalisierung funktioniert zukünftig kaum noch ein Geschäftszweig – zumindest bei den „digital natives“, die als Konsumentengruppe zunehmende Bedeutung haben.
Das Geniale, aber auch Gefährliche an Scrum ist, dass es gar kein Softwareentwicklungs-Prozess ist, sondern lediglich ein Framework, das die agile Herangehensweise an die Entwicklung eines nicht näher beschriebenen Produkts beschreibt. Deswegen ist auch die Nomenklatur so einfach wie vielseitig: Nirgendwo ist von Software die Rede; und schon gar nicht von Architekturen, CI-Servern und ähnlichem „Technikzeug“, was Manager ohnehin nur unnötig verschrecken würde.
Trotzdem setzen viele Menschen Scrum mit Softwareentwicklung gleich; ganz einfach, weil es das gängigste Einsatzgebiet ist. Wenn man von einem Scrum-Team redet, dann denkt man i.d.R. an eine Gruppe von meist 6–8 SW-Entwicklern und ggf. Testern, die ganz selbstverständlich den Scrum-Prozess mit Leben füllen, indem sie Methodiken und Tools verwenden, die Umsetzung agiler Prinzipien sind (TDD, CI, Pair Programming u.ä.).
Software-Profis auf der Höhe der Zeit lieben aus gutem Grunde agile Entwicklung und haben jede Menge dieses Know-Hows in ihrem Portfolio – inklusive agilen Werten wie common code ownership; die Zeiten, da jeder an „seinem“ Code geschraubt hat, sind zum Glück längst vorbei. Deswegen ist es – von der Verfügbarkeit abgesehen – heute in der Regel kein Problem, ein professionelles agiles Software-Team zusammenzustellen.
Auch die Rolle des Scrum Master ist gut verstanden und etabliert. Da er als eine Art Moderator dem Team „nur“ hilft, den Prozess einzuhalten und beständig zu optimieren, ist es für seine Skills fast unerheblich, ob es sich beim Produkt um Software oder etwas völlig anderes handelt, auch wenn gute Scrum Master natürlich wissen, welche Untiefen in Software-Projekten lauern.
Enter the stage: Product Owner
Aber was genau macht die dritte Rolle in Scrum, die noch nicht mal in der offiziellen Prozessgrafik dediziert auftaucht (s.o.)? Hier haben sich die Scrum-Erfinder Schwaber und Sutherland elegant aus der Affäre gezogen. Da der Scrum-Prozess die iterative Erstellung eines Produkts in sogenannten Inkrementen vorsieht, wurde sinnvollerweise eine Rolle Product Owner (PO) eingeführt. In der Theorie klingt das einfach: Als PO schreibe ich meine Anforderungen in ein Backlog und das Team arbeitet das so lange ab, bis ich mein fertiges Produkt in Händen halten. Natürlich will mein Team immer mal mit mir reden (jemand hat mal gesagt, eine User Story sei vor allem eine Verabredung zum Gespräch), aber dafür muss ich mir ja auch weniger Mühe mit den Anforderungen machen, oder?
In der Praxis von Softwareprojekten ist das aber ungleich schwerer. Hier trennt sich die Spreu vom Weizen. Nur Projekte mit guten POs haben eine Chance auf langfristigen Erfolg. Denn der Product Owner muss zumindest grob die konzeptionelle Komplexität eines Softwaresystems beherrschen und die wesentlichen Technologien ausreichend gut kennen, um die richtigen Entscheidungen zu treffen. Da das Team sich nur von Sprint zu Sprint hangelt und die Stakeholder in aller Regel zu wenig Verständnis und Interesse für die konkrete Softwaretechnologie mitbringen, ist er eine Art Architekt des Systems, zumindest fachlich.
Denn auch wenn es die Rolle SW-Architekt offiziell in Scrum nicht gibt: Die Vorstellung, dass sich eine sinnvolle Architektur „emergent“ ergibt, wenn nicht jemand am Anfang zumindest eine relativ klare Vision des Endzustandes und entsprechende Richtungsentscheidungen formuliert, scheint bei komplexen Systemen mit einem langen Lebenszyklus naiv. Gleichzeitig muss der PO aber das beherrschen, was Requirements Engineering genannt wurde, als man feststellte, dass das Formulieren guter Anforderungen/Spezifikation eigentlich eine Ingenieurstätigkeit ist. Und er ist eine Art Projektleiter, da letztendlich er die relevanten Entscheidungen treffen muss.
Schon eine grobe Beschreibung seiner Aufgaben gibt einen Eindruck, wie anspruchsvoll die Rolle des Product Owner ist:
- Eine Vision des fertigen Produkts entwerfen (inklusive zu verwendender Technologien)
- Die Anforderungen an das Produkt von den Stakeholdern ermitteln und in ausreichend kleine Häppchen zerlegen, die sog. Backlog Items (typischerweise in Form von User Stories)
- Im Product backlog die Items so priorisieren, dass eine sinnvolle Reihenfolge entsteht, in der das Produkt inkrementell entstehen kann, denn Scrum ist bekanntlich ein iterativ-inkrementeller Prozess; dabei muss der PO in der Lage sein, zu erwartende Abhängigkeiten im Softwaredesign zu berücksichtigen
- Die Items so beschreiben, dass sie einerseits dem Team klarmachen, was verbindlich erwartet wird (Abnahmekriterien), andererseits genug Freiheit für die konkrete Umsetzung lassen (der PO soll kein SW-Design machen, nur gute Rahmenbedingungen dafür schaffen)
- Im Sprint Planning die jeweils nächsten Items an das Team kommunizieren und dafür werben, dass daraus ein möglichst sinnvolles Produktinkrement im nächsten Sprint wird; dabei muss er technische Argumente des Teams zumindest grob verstehen und in Entscheidungen berücksichtigen können
- Während des Sprints dem Team für Detailklärungen zu den Items zur Verfügung stehen, gleichzeitig den Kontakt zu den Stakeholdern pflegen und das Backlog weiter verfeinern
- Änderungen des Sprintumfangs nachverhandeln, wenn das Team das wünscht, weil es sich z.B. verschätzt hat oder sich Machbarkeitsprobleme abzeichnen
- Spätestens im Sprint Review das Inkrement anhand der Items und ihrer Abnahmekriterien abnehmen (das ist nicht notwendigerweise der User Acceptance Test, aber der Schritt, mit dem der PO dem Team bestätigt, dass sie ihn zufrieden gestellt haben)
- eine agile Releaseplanung machen, um den Sprintprozess mit übergreifenden, oftmals nicht agilen Prozessen auszurichten, insbesondere in Hinblick auf marktrelevante Meilensteine; hier ist oft noch eine detaillierte Beurteilung externer Abhängigkeiten technischer oder organisatorischer Natur nötig
Die Aufgabe des Teams ist es „lediglich“, den Inhalt des jeweiligen Sprint-Backlogs so zu einem Produktinkrement zu machen, dass die Abnahmekriterien erfüllt sind und der bisherige Systemumfang keine Regression erleidet (Testautomatisierung ist eine absolute Grundbedingung agiler Projekte).
Die Aufgabe des Product Owner ist es aber, den Überblick über den gesamten Weg zu haben und das Team in Richtung eines möglichst nützlichen Software-Produkts zu führen, das die Ziele seiner Stakeholder erreicht – auch wenn diese „moving targets“ sind, was ja ein Grund agiler Arbeitsweise ist.
Mit der Kompetenz des Product Owner steht und fällt also der Erfolg eines Scrum-Projekts. Diese Rolle kann Motor oder – häufiger? – Sollbruchstelle sein.