Abenteuer in SAFe - Sei der Product Manager!
“Herzlichen Glückwunsch! Du bist jetzt Product Manager! Ach ja, wir setzen hier das Scaled Agile Framework (SAFe) ein, Product Manager ist da ein bisschen anders als Du es vielleicht im klassischen Sinn kennst. Macht ja nix, geh mal auf scaledagile.com oder so ähnlich, da stehen ein paar Zeilen zu der Rolle und den Aufgaben, die Dich erwarten. Ach ja, Du kannst auf jedes Element des SAFe Big Picture klicken und kriegst dann entsprechende Hintergrundinfos - viel Spaß!”
Ihr seid also Product Manager in einem Unternehmen geworden, das auf das Scaled Agile Framework setzt. Soweit so gut. Leider gibt es außer der dazu gehörigen Webseite, einem nicht mehr ganz aktuellen Buch und einigen Schulungen, die Lidl und Aldi nicht ins Sortiment aufnehmen würden, nicht allzu viele Informationen zu eben dieser zentralen Position in SAFe.
Auf der Team-Ebene im Framework ist es einfacher, für ScrumMaster und Product Owner gibt es einen unerschöpflichen Fundus an Büchern, Podcasts, Blogs, Schulungen und Veranstaltungen, die helfen können, diese Rollen so gut wie eben möglich auszufüllen. Für den Product Manager in SAFe ist das - diplomatisch ausgedrückt - ein Feld mit Ausbaupotenzial…
Hier komme ich mit diesem Blogpost ins Spiel: Ich darf in einem Unternehmen, welches vor nicht allzu langer Zeit auf SAFe umgestellt hat, als ScrumMaster arbeiten. Auch wir haben Product Manager und daher schon einige Erfahrungen mit dem “Leben” dieser Rolle machen können. Aus meiner rein subjektiven Sicht und mit den Erfahrungen aus genau einem Einsatz von SAFe möchte ich mir trotzdem anmaßen, ein paar Erfahrungen bzw. Hinweise zu teilen und Euch damit hoffentlich den Einstieg in die Rolle ein wenig leichter zu machen!
1. In SAFe ist der Kunde sehr weit weg, Du bist der Proxy-Kunde
Leider haben die Macher von SAFe den Kunden in ihrem Framework erst einmal vollkommen vergessen und in der kommenden Version 4.0 sehr weit weg von den Orten “wo die Action ist” entfernt plaziert. Der Kleber zwischen Kunden, PO und Team bist Du, quasi als Proxy.
Die Anforderungen an das Produkt kommen von Dir, und nur von Dir!
2. Bereite Dich auf das Release Planning vor
Die Anforderungen kommen also von Dir. Das klingt erstmal einfach, ist es aber gar nicht (so sehr). Im Scaled Agile Framework gibt es alle paar Wochen ein großes Spektakel - das Release Planning Event (ab 4.0 ist es das Product Increment Planning Event). Das sind ein, zwei oder vielleicht auch drei Tage, an denen sich alle Beteiligten zusammen setzen und die nächste große Iteration planen: Der Product Manager stellt die gewünschten Features vor und unterstützt den Product Owner und das Team dabei, für dieses Feature User Stories zu definieren und zu schätzen. Danach, wird festgelegt, welche Features in der nächsten Iteration realisiert werden sollen. Damt ist das Event für Dich ein zentraler Steuerungspunkt.
Beim Planning Event bist Du der König! Sei ein weiser und umsichtiger Herrscher!
Definiere Anforderungen
Deine Features sind Anforderungen und sollen keine Lösungsbeschreibungen sein. Versuche, Dich von technischen Details, beteiligten Systemen und Schnittstellen zu lösen - darum kümmern sich die Entwicklungsteams und finden sicher die beste und einfachste Lösung. Beschreibe was Du willst und warum Du es benötigst. Mache es so einfach und klar wie möglich. Wenn in Deinem Featuretext bestimmte Schlüsselworte (z.B. “und”) vorkommen, kann es sein, dass Du vielleicht zwei Features in eines formuliert hast? Solche Fragestellungen und Methodiken unterscheiden sich nicht so extrem von denen, die ein Product Owner zur Erstellung seiner User Stories nutzt. Zum Glück gibt es dazu jede Menge Literatur und Unterstützung!
Sage, wann es für Dich ok ist
Das Team will Deine Anforderung umsetzen, der Product Owner möchte seine Stories so erstellen, dass sie die Anforderungen möglichst effizient darstellen. Was kannst Du tun, um deine Teams zu untestützen? Formuliere Akzeptanzkriterien zu Deiner Anforderung: Was muss erfüllt sein, damit alles so funktionieren kann, wie Du es Dir ausgedacht hast. Diese Kriterien müssen verifizierbar, also testbar sein. Das ist nicht einfach und braucht Übung. Mach Dir keine Sorgen, wenn es am Anfang ein wenig holpert ;-)
Ein weiterer Weg zu sagen, was Du willst, ist das Aufstellen von Szenarien: Bringe ein paar Beispiele von dem, was Du von der Lösung erwartest. Es ist schwierig, ein Szenario nicht zu einer Bedienungsanleitung für eine Software werden zu lassen. Präsentiere die Szenarien jemandem, der die bestehende technische Lösung nicht kennt und der Dir ehrliches Feedback gibt. Auch die ScrumMaster und der Release Train Engineer helfen sicher gerne!
Bestimme, was es Dir bringt
Ein sehr schwieriger aber wichtiger Punkt ist die Bewertung Deiner Anforderungen. Du musst einen Weg finden, Deinen Features einen Wert zuzuweisen. Das kann alles von einem Euro-Wert oder einer virtuellen Projektwährung bis hin zum Klassiker (Gummibärchen) sein. Nicht immer lassen sich Features mit einem Ertrag versehen. Was ist mit Anforderungen, die dem Marketing oder dem internen Reporting dienen? Glücklicherweise bist Du auch hier nicht allein, denn es ist kein SAFe-spezifisches Problem.
Schreib einen Preis dran
Wenn Du es geschafft hast, einen Wert an Deine Anforderung zu schreiben, brauchst Du noch die Information, was es Dich kostet. Vielleicht lohnt sich diese Funktinalität ja gar nicht! Kannst Du den Preis, also den Aufwand zur Realisierung, selber bestimmen? Wahrscheinlich schon, aber gerade am Anfang nicht besonders gut. Zum Glück sind wir ja ein Team: Lass Deine Product Owner und ihre Teams die Features mit Dir zusammen in Relation zueinander schätzen. Beobachte, welche Kriterien sie heranziehen. Werte die Durchlaufzeiten Deiner Features aus. Mach das immer! Bei jedem Feature. In jedem Release. Mit diesen Daten und Erfahrungswerten kannst Du sicher bald auch alleine eine grobe Einschätzung machen, die für die Abwägung von Wert und Kosten als Vorbereitung zum Planning Event ausreichend ist.
Es ist ein Wunschzettel
Deine Liste mit Anforderungen, die Du in der nächsten Iteration umgesetzt haben möchtest, ist wie ein Wunschzettel. Du willst alles davon haben. Du weißt aber leider auch, dass Du vielleicht nicht alles haben kannst (Ich habe auch an zwei aufeinanderfolgenden Weihnachtsfesten NICHT den großen Leiterwagen von Playmobil bekommen!). Das ist doof, aber eben auch die Realität. Die Realität müssen wir leider akzeptieren und mit den Konsequenzen umgehen, wenn wir unseren Job gut machen wollen. Wenn Du also nicht alles haben kannst, musst Du sagen, was Dein größter Wunsch ist. So stellst Du sicher, dass der Leiterwagen definitiv unter dem Baum landet. Das ist nicht neu für Dich und Du weißt, worauf ich hinaus will: Du musst priorisieren.
Du hast natürlich das Recht, Deine Priorisierung zu geeigneten Zeitpunkten zu ändern. Im Planning Event. Zum Sprintwechsel. Wann immer die Product Owner und die ScrumMaster es Dir erlauben! Nutze dieses Instrument, es ist ein mächtiges Steuerrad auf dem Weg zu Deinem Ziel.
Agilität ist etwas seltsames - je mehr man sie skalieren will, desto kleiner scheint sie zu werden.
3. Sei beim Team
Bei der Skalierung von Agilität scheint es irgendwie schwer zu sein, agil zu bleiben. In SAFe kann man leicht auf die Idee kommen, es gäbe Übergabepunkte, an denen die Verantwortlichkeit für ein Feature wechselt. Du als Product Manager willst aber Dein Feature nicht am Planning Event abgeben und Dich fünf Wochen später überraschen lassen, was daraus geworden ist. Damit die Vorteile eines agilen Ansatzes nicht wie ein ein Wasserfall ins Tal stürzen, musst Du Dich bemühen, immer nah an den implementierenden Teams zu sein.
Warum möchtest Du das so sehr?
- Nur, wenn Du in kurzen Zyklen siehst, was das Team macht, kannst Du steuern und effektiv unterstützen
- Bist Du nah beim Team, kannst Du viel über die Arbeitsweise und Probleme dort lernen. Das kann Dir beim Planen und Formulieren der nächsten Anforderungen enorm helfen.
Plane Dir also den Kalender nicht zu voll, damit Du kurzfristig für Deine Teams verfügbar bist. Schau öfter mal spontan vorbei und lass Dir den Stand der Lösung zeigen. Gehe zu den Regelmeetings und gib spätestens dort ein ehrliches Feedback.
Nur so bekommst Du am Ende das beste Produkt, welches unter den Rahmenbedingungen in Deinem Unternehmen möglich ist!
4. Schlussformel
Vielleicht konnten Dir diese Ausführungen ein bisschen helfen oder haben zu ganz neuen Ansätzen und Ideen bei Dir geführt? Das würde mich sehr freuen. In jedem Fall wünsche ich viel Spaß und dass Du am Ende ein großartiges Produkt geliefert bekommst!