Teil 1/4: Die Transformation und das Rollenverständnis
Übermäßig aufgeblähtes und letztlich hinderliches Projektmanagement ist zur Tradition geworden. Und eine Tradition ist nur der Gruppenzwang der Vergangenheit. Schluss damit! In unserer Artikelserie zeigen wir Euch, wie die Abräumer von morgen Produkte völlig ohne Projektmanagement entwickeln und dabei Zeit, Geld und Nerven sparen – und worauf ein Product Owner dabei achten muss.
Weiterlesen
Das Thema ist eine Serie bestehend aus 4 Artikeln, die unterschiedliche Aspekte beleuchten. Und am Ende der Artikelserie werdet Ihr wissen, wie Ihr die Transformation vom klassischen Projektmanagement zu modernen erfolgreichen Ansätzen hinbekommt, welche Aufgaben und Zuständigkeiten ein sogenannter „Product Owner“ (im Folgenden mit „PO“ abgekürzt) tatsächlich hat, bzw. woran dieser weiß, ob er/sie erfolgreich ist, bzw. gute Arbeit abliefert. Wir werden uns aber auch ansehen, wie eine gute Wochenroutine aussieht, die Euch bei Eurem Erfolg helfen wird. Und um das Thema vollumfänglich abzurunden, werfen wir ein besonderes Augenmerk auf die Wichtigkeit der Einschätzung des Bearbeitungs- und vor allem auch Abnahmeaufwandes.
Fassen wir kurz nochmal zur Orientierung zusammen, worum es in der Artikelreihe Produktentwicklung ohne Projektmanagement gehen wird:
- Wie Euch die Transformation vom klassischen Projektmanagement zu modernen erfolgreichen Ansätzen gelingt
- Die Zuständigkeiten und Aufgaben der Product Owner-Rolle (PO)
- Woran der PO weiß, ob er/sie erfolgreich ist bzw. gute Arbeit macht
- Wie eine gute weekly Routine aussieht + Erfolgs- Checkliste
- Die Wichtigkeit der Einschätzung des Bearbeitungs- und vor allem auch Abnahmeaufwandes
Im ersten Artikel unseres Vierteilers geht es um die Zuständigkeiten und Aufgaben des Product Owners und wie Euch ein Wechsel aus dem klassischen Projektmanagement gelingt. Wir beschäftigen uns also mit dem modernen Ansatz der Produktentwicklung, wie man vom klassischen Management dahin gelangt und wie der typische Ablauf aussieht. Außerdem machen wir uns klar, was genau die Aufgaben und Zuständigkeiten der Product-Owner-Rolle genau sind.
Bisheriger Flaschenhals für Product Owner
Lassen wir gleich mal die Katze aus dem Sack: Manager sind heute der Flaschenhals bei der Produktentwicklung. Was die meisten Team-Mitglieder wahrscheinlich ohnehin schon immer wussten, ist im Lauf der Zeit immer deutlicher geworden: denn dass sich Anforderungen ändern können und man durch Experimente neue Erkenntnisse gewinnt, ist in der heutigen VUCA-Welt nicht mehr verhinderbar. Aber die bisherige Management-Methoden sind dafür einfach nicht (mehr) geeignet. Die Folge: Jeder Manager und jede Managerin geht im Stress und Koordinationsaufwand unter. Und dann setzt sich die Lawine erst richtig in Gang: Das Team kann nicht mehr ohne Unterbrechungen arbeiten. Alle notwendigen Entscheidungen stauen sich auf höherer Hierarchie-Ebene und gehen dort ebenfalls unter. Die Budgets werden gesprengt und Projekte dauern plötzlich Jahre länger oder scheitern direkt komplett.
Kommt Euch bekannt vor? Eben. Hat jeder und jede schon mal direkt oder indirekt mitbekommen. Willkommen im Club, so läuft das 21. Jahrhundert! Stoßen wir auf zahllose insbesondere deutsche Unternehmen und Vorhaben an, die auf diese Weise gescheitert sind und noch wegen dem Festhalten an alten Strukturen scheitern werden!
Eure Transformation zum Product Owner
Fehler sind nicht dazu gedacht, sie immer wieder zu begehen, selbst wenn das hierzulande schon an Tradition zu grenzen scheint – nein! Wir wollen aus Fehlern lernen und wollen, dass es Euch nicht so ergeht. Stressfrei und in Time- and-Cost eine erfolgreiche Innovation auf den Markt bringen, das ist unsere gemeinsame Mission. Wir helfen euch dabei!
Also legen wir los: Wie muss die Transformation aussehen, damit sie bei Euch klappt?
Stufe 1: Ihr sprengt Eure Vorstellung davon, wie Hierarchien aussehen. Die Pyramide? Weg! Stellt Euch nur mal vor, es gäbe in Eurem Entwicklungsteam keine Abteilungsleiter und Teamleiter mehr. Projektmanager? Wegrationalisiert! Ihr seid jetzt Euer kleines eigenes Mini-Startup. Und Ihr seid frei! Die Unternehmensleitung fungiert von nun an als kompetente Beratung für dieses Mini-Startup, aber nur um Impulse und Erfahrungswissen mit reinzugeben, wenn danach gefragt wird.
Stufe 2: Jemand im Team, der besonders gut mit Kunden (und ggf. anderen Stakeholdern) kann, nimmt die Rolle des Vollzeit Product Owners ein. Dieser PO arbeitet permanent an einer ganz konkreten Produktvision und zaubert den Nutzern immer genau die Features, die im Moment am wertvollsten sind, und versucht die Bedürfnisse aller Stakeholder zu erfüllen. Diese Person steht zwischen Nutzern und dem Entwicklungsteam, ist nun also nicht mehr ganz „im“ Team. Die Zuständigkeit der Product Owner: Sie haben die „Macht“ alles Relevante für das Produkt zu entscheiden (das WAS, aber nicht das WIE).
Stufe 3: Das Unternehmen gibt dem Team den Handlungsspielraum vor, in dem es frei verwalten und entscheiden darf. Dazu zählen das Kennen und Anwenden der Kernwerte des Unternehmens, die Unternehmensmission und natürlich Regelungen, welche Ressource (Geld, Personal, Geräte, Wissen) wie genutzt werden kann/darf. Das Team einigt sich mit der Unternehmensleitung, wer sie wann wie kontrolliert, um sicherzustellen, dass alle auf dem richtigen Pfad sind. Was sind die genauen Konsequenzen bei den verschiedenen Themen, wenn man sich nicht richtig verhält? Ihr seht: Das Team hat die „Macht“, das WIE immer selbst zu entscheiden. Aber es gibt dennoch ganz grobe Grenzen, um strategisch im Sinne des Unternehmens zu handeln und existenzielle Risiken einzudämmen.
Stufe 4: Der PO beginnt mit der Arbeit. Zunächst durchläuft ein Product Owner üblicherweise folgende 5 Schritte, ehe eine Entwicklung starten kann:
- Der PO sammelt regelmäßig, z.B. alle 1 -3 Monate, die aktuellen Wünsche und Bedürfnisse der Kunden (und anderer Stakeholder) ein, die den Kundenalltag JETZT und mit heutigem Kenntnisstand erleichtern oder etwas ermöglichen können, das vorher nicht möglich war.
Wichtig: Diese Bedürfnisse und Wünsche können sich jeden Monat sowohl durch neue Erkenntnisse als auch Änderungen in der Umwelt oder den Arbeitsbedingungen ändern, daher immer neu ausloten!
- Nach der Priorisierung der Wichtigkeit und der Höhe des Mehrwerts (subjektiv, immer aus Kundensicht!) kann der PO dem Team die Themen vorstellen. Das Team versucht alles zu verstehen und gute Fragen zu stellen. So wird das Thema konkreter greifbar und wichtige Elemente werden beleuchtet, die vorher noch im Dunkel lagen.
- Im nächsten Schritt versucht das Team zusammen mit dem PO, das Thema auf mehrere Unterthemen herunterzubrechen, deren Realisierung nicht mehr ganz so komplex ist und dennoch Kunden (jede/r einzelne!) einen Mehrwert bieten. Diese Unterthemen werden dann vom Team geschätzt – und zwar relativ zueinander (Stichwort: „Storypoints“). Als Referenzaufwandsgröße wird der Umfang einer früheren Umsetzung angenommen.
Wenn Ihr damals beispielsweise mal für Kunde X das Feature Y realisiert und dafür grob 2 Tage für diese Art Komplexität benötigt habt, nehmen wir das als Referenzgröße und ordnen diesem Teilprojekt die Storypoint-Größe 8 zu. Jetzt lässt sich ganz einfach abschätzen, ob die neuen Unterthemen im Vergleich zum Referenzprojekt gefühlt viel größer oder kleiner, also aufwändiger, bzw. komplexer sind als die Referenz.
- Wenn die Aufwände der einzelnen Unterthemen gesammelt sind, kann der Product Owner die Themen nach Aufwand-Nutzen-Verhältnis sortieren. Die Themen mit großem Nutzen und kleinem Aufwand sollten zuerst umgesetzt werden. Der PO erarbeitet einen Vorschlag, was das Team als nächstes realisieren (oder auch Vorhandenes anpassen) kann.
- Der Product Owner / die Product Ownerin stellt das Bundle im Team vor und das Team klärt offene Fragen und welche Möglichkeiten (Ressourcen) zur Verfügung stehen. Anschließend selektiert das Team, was es im nächsten Zeitabschnitt wirklich realisieren kann, wenn sie alle Eventualitäten mit berücksichtigt haben, und committet sich dann final dazu: Es verspricht zum Datum X, dass diese Selektion zu 100%, also in jedem erdenklichen Fall, realisiert ist und vom PO erfolgreich abgenommen wurde.
Das gewünschte Feature auf der Reise in die Live-Umgebung
Schritt 1: Das Team organisiert sich
Nachdem das Team sich zum Was und Wann committet hat, setzt es sich zusammen und überlegt intern, wie sie es (möglichst einfach, aber dennoch nachhaltig) realisieren können. Sie erstellen Subtasks und Todos und verteilen die Aufgaben. Wichtige Fragen hierbei: Was kann wie getestet werden? Was muss wo dokumentiert werden? Zudem geht das Team die Definition-of-Done (eine vorab gemeinsam mit dem PO beschlossene Definition, was alles dazugehört, damit eine Story “Erledigt” ist) sowie ggf. weitere definierte Akzeptanzkriterien durch, was alles dazu gehört, damit die ausgewählten “Items” zu 100% abgeschlossen sind.
Schritt 2: Das Team und der für Product Owner nehmen die Entwicklung ab
Wenn das Team einzelne Features und Stories realisiert hat, wird der PO (mit noch genügend Zeit vor der versprochenen Deadline) mit eingebunden und gebeten, es im Gesamtkontext (also auch im Zusammenspiel mit externen Systemen, mit den Testdatenbanken, etc.) zusammen mit dem Team abzunehmen. Dabei werden auch viele End-to-End-Tests durchgeführt, um gleichzeitig sicherzustellen, dass auch bisher Funktionierendes noch richtig funktioniert. Clevere Teams automatisieren die für das Unternehmen kritischsten Szenarien, die zu einem schlechten Ruf führen könnten. Die Teams können wiederholend bei jeglichen Änderungen per Mausklick einen Testreport erstellen lassen. Wer sich dafür interessiert -> hier gibt es dazu noch mehr Infos.
Schritt 3: Das Team stellt (allen Stakeholdern) vor
Regulär gibt es dann zur Deadline eine Präsentation, bei der das Team zusammen mit dem PO die Änderungen allen Stakeholdern vorstellt. Bei vielen Startups, die bspw. eine Webanwendung mit vielen tausend Besuchern betreuen, findet diese Präsentation meist nicht mehr öffentlich statt, sondern nur noch “intern”.
Schritt 4: Die Freigabe und das Rollout
Wenn der Product Owner allen realisierten Items die Freigabe erteilt, kann das neue Release (also die neue Version: das bestehende System mit den neuen Features integriert) ausgerollt werden. Dazu hat dieser in der Regel eigene Spezialisten (meist aus der IT), die ein sauberes Rollout durchführen, die Updates einspielen, Datenbanken-Strukturen und -Daten wie notwendig anpassen und Konfigurationen überprüfen. Wenn der Live-Test soweit auch erfolgreich war, schicken viele Startups einen Newsletter oder Social-Media-Beiträge oder direkte Mailings raus und informieren so ihre Nutzer über die neuesten Updates und Mehrwerte (deren Wünsche ursprgl. ja von den Nutzern kamen, siehe oben den PO-Schritt 1).
Also was sind jetzt die Aufgaben und Zuständigkeiten der Product Owner?
Ein Product Owner trägt die Produktvision. Ein Product Owner steht im engen Kontakt mit der Zielgruppe und kennt zu jeder Zeit ihre aktuellen Bedürfnisse und Wünsche. Er/Sie kann diese nach Mehrwert sortieren und beschreibt dem Team die Wünsche in Form von Userstories. Ein PO legt die Akzeptanzkriterien, bspw. während einer Abnahmephase, fest, und bestimmt so, wann eine Userstory „done“ ist. Er oder sie sorgt dafür, dass alle Fragen des Teams angehört und geklärt werden.
Eine große Herausforderung und Verantwortung im späteren Schritt: Er oder sie sorgt dafür, dass durch die Integration von Änderungen keine für das Unternehmen kritische Risiken, wie etwa Rufschäden, bspw. durch Ausfälle, Fehler und Probleme an anderen Stellen oder Kompatibilitätsprobleme o.Ä. entstehen. Hierfür steht der PO insbesondere in der Verantwortung, Systeme und Prozesse zu seiner eigenen Absicherung zu designen und zu etablieren. Oft verlässt sich dazu ein Product Owner auf die Reports von (seiner oder ihrer Annahme nach relevanten) End-to-End Tests, und steuert die Abnahmen nach eigener Risikoeinschätzung.
Darüberhinaus sorgt ein PO dafür, dass der Zielgruppe immer neue Features vorgestellt und auf Live-Systemen (z.B. durch IT-Leute, DevOps) ausgerollt werden.
Klingt irgendwie ein bisschen nach Management-Verantwortung in Form von richtigem Verständnis von Kunden sowie seiner Delegationsfähigkeit (Verlassen auf Testreports, Rollout-Deployment, …), oder?
Der gewaltige Unterschied ist, dass er/sie weder über die Lösungswege involviert ist, noch die Realisierungsverantwortung trägt, denn dazu hat sich das Entwicklungsteam ja in der jeweiligen Anfangsbesprechung bereits zu 100% verpflichtet.
Fazit
Eine Transformation vom klassischen Management hin zu den modernen Ansätzen ist mit mehreren Stufen verbunden. Dem Entwicklungsteam wird mehr Verantwortung und Freiheit eingeräumt, während gleichzeitig das verwaltende Management wegfällt und die neue Rolle des Product Owners entstanden ist: Dieser trägt die Verantwortung über das „Was“ und sorgt dafür, dass das richtige und wichtigste „Was“ immer schnell beim Kunden landet. Frühere (hierarchische) Vorgesetzte mit ihrer mehrjährigen Expertise werden hierbei zu wichtigen Beratern für die Teams. Diese Neuorganisation ermöglicht es, das Produkt jederzeit schnell, richtig und agil anpassen zu können, sowie typische Flaschenhals-Probleme mit überarbeiteten Managern in hierarchisch strukturierten Unternehmen zu beseitigen.
Heute also ein Muss, wer sich in der schnelllebigen und dynamischen VUCA-Welt auf dem Markt behaupten möchte.
Ausblick
In der nächsten Folge dieser vierteiligen Serie erfahrt Ihr, woran das Unternehmen und der PO weiß, ob er/sie erfolgreich ist bzw. gute Arbeit macht. Ihr dürft gespannt sein! Tipp: Und um nichts zu verpassen, abonniere einfach diesen Kanal rechts in der Seitenleiste.