Real life tips: Do's and Don'ts for Scrum implementations – the Product Owner

Do

Make the Product Owner a part of your Scrum Team. Why? Because it’s supposed to be one delivery unit. Not two, with one side delivering ideas, and the other side delivering the product and then both sides arguing about what was really required. I’ve seen a good share of political fights for power over people being carried out on the back of the employees: The PO wasn’t allowed to sit next to the Dev Teams because the PO’s manager was afraid of limited influence. Of course his behavior consequently influenced nothing but lead time and the quality of features.
The Product Owner, just like the ScrumMaster, also assumes a leadership role. Therefore, empower your Product Owners to make (risky) decisions on their own. Why? Because eventually it enables everyone to learn from mistakes: A Product Owner once hesitated to switch on a feature that went live four weeks ahead of schedule, because her superior was on vacation and she was afraid that something might go broke. So instead, all the additional buffer that could have been used to fix potential bugs before the promised date, was consumed and the feature was switched on the exact date when it was supposed to – and, of course, it turned out to be buggy and left behind dissatisfied customers.
If your Product Owners work in a different location than your development teams, make them visit each other on a regular basis. Having Skype calls and telcos is better than writing emails and tickets, yet, looking each other in the eye when trying to fix a serious issue or discussing priorities is a whole new ball game! Especially regarding different cultural backgrounds and mother tongue, personal meetings and workshops help to identify barriers quicker and to get the involved parties on the same page. If you encounter political differences between parties, set up a meeting on neutral ground so no one feels like they’re having a disadvantage.

Agiles Anforderungsmanagement mit dem Poke-Prinzip

Marco Ley, Leiter eEntwicklung bei CosmosDirekt, sprach auf den Softwareforen Leipzig letzte Woche über “Agiles Anforderungsmanagement: Das Poke-Prinzip – von harten Anforderungen zu kleinen Experimenten.“ Ich muss von diesem Vortrag erzählen, weil ich so stolz auf dieses CosmosDirekt Team bin. Ich habe nichts dafür getan, dort kennt man mich nicht, und ich will gar keine Lorbeeren einheimsen, die Marco Ley gehören, aber ich bin einfach vollkommen fasziniert.
Kennt ihr das, wenn ihr hart für etwas arbeitet und dann feststellt, dass all das, worüber ihr nachgedacht und ständig gesprochen habt, plötzlich Realität wird? Nun ja – so fühlte ich mich an diesem Morgen beim Vortrag von Marco Ley. Er sprach davon, dass seine Entwicklungsteams vollständig crossfunktional aufgestellt sind – UX, RE, Tester, Developer. Diese Teams arbeiten nicht etwa Anforderungen ab, sondern erarbeiten die User Storys selbstständig, basierend auf groben Vorgaben. Und es sind nicht etwa klassische User Storys, sondern Hypothesen, die in mehr oder weniger aufwendigen A/B Tests auf der Produktivumgebung geprüft werden, so dass die Funktionalitäten für das gesamte CosmosDirekt-Portal live gestellt werden. Die durch die Implementierung gewonnenen Daten beweisen, ob sie wirklich einen Return On Investment bringen.
Damit zeigt uns Herr Ley, dass es ihm gelungen ist, die Rolle des Product Owners so zu leben, wie es meiner bescheidenen Meinung nach sein sollte. Er kümmert sich darum, Ideen zu finden, diese daraufhin zu bewerten, ob man damit Geld verdienen kann und macht dann diese Ideen zu Hypothesen, die er von seinen Kollegen durch Implementierung überprüfen lässt. Was funktioniert, wird behalten, der Rest wieder entsorgt. Einfach toll!
Wir haben ihn natürlich gefragt, wie er erkennt, ob er Erfolg mit der Funktionalität hatte, und er sagte: „Weil wir eine Datenbasis haben.” Er trifft Entscheidungen auf Basis von Daten, die er durch Ausprobieren gewinnt und nicht durch politische Überlegungen. Chapeau!Wenn man ihm so zuhört, tut mir die übrige Online Direktversicherungsbranche leid. Sie kann sich warm anziehen, sollte sich sein Vorgehen bei ComosDirekt weiter durchsetzen. Sein Team wird allen anderen einfach davonlaufen.
Vielen Dank für diesen tollen Vortrag!
An dieser Stelle noch etwas Werbung: Die Softwareforen in Leipzig haben mit der Agilen User Group, die sich dort zwei Mal im Jahr trifft, eine wirklich tolle Veranstaltung ins Leben gerufen. Ich bin sehr dankbar, dass ich dabei sein darf. Mehr Infos hier

Entscheidungsgremien: Erfolgsfaktor in agilen Projekten?

In einem unserer Projekte ging es darum, einen Systemverbund zu stabilisieren, der bisher durch eine fehlerverursachende Schnittstelle nur eingeschränkt genutzt werden konnte. Im Vorgängerprojekt sollten die beiden Systeme zusammengeschalten werden – es wurde klassisch abgewickelt und musste schließlich wegen Erfolglosigkeit gestoppt werden. Wegen der guten Erfahrungen mit Scrum in anderen Projekten lag es nahe, im zweiten Anlauf den agilen Ansatz zu wählen – hier kam ich ins Spiel. Und bevor ich weitererzähle, hier mein Appell gleich zu Beginn: Seid bereit, das Management aktiv an die Hand zu nehmen. Sie werden es euch danken!

Klassische Wünsche im agilen Rahmen

Schon in der Setup-Phase wurde klar, dass im vorherrschenden Umfeld ein tatsächlich agiles Projektvorgehen eine wahre Herausforderung werden wird. Erstens lastete hoher Druck auf dem Projekt, die Systeme endlich stabil zu bekommen und jede Form von Mehrkosten zu vermeiden. Zweitens wurde das Projekt noch mit einem zusätzlichen Gesamtprojektleiter, der übergeordnet die Verantwortung für das Projekt trug, besetzt. Und drittens hatten die entscheidenden Personen, allen voran das Top Management in Form eines Lenkungskreises, alles andere als agile Ansätze im Sinn. Beginnend mit der Forderung nach einem Reporting mit dem Fokus auf Budget und Zahlen kam auch schnell die Frage nach dem „großen“ Projektplan über die angesetzten 6 Monate auf. Was wird bis Datum XY geliefert und viel wichtiger: Was kostet dieses Unterfangen?

Ein Schritt zurück, um vorwärts zu kommen

Um dem Management einen groben Projektplan zu bieten, erarbeiteten die Product Owner mit Unterstützung der ScrumMaster einen physischen Releaseplan mit Post-Its. Dabei planten sie nach dem Eisberg-Prinzip: die kommenden Sprints detailliert und die zukünftigen Sprints auf höherer Ebene. Mit diesem Instrument konnten sie nun auch auf Gesamtprojektsicht einen Plan vorweisen. Anfangs wurde das noch skeptisch beäugt und als schwammig kritisiert. Das größte Hindernis war dabei wohl, dieses Nichtvorhersagen-Können zu akzeptieren. In traditionellen Projekten gibt man sich von Anfang an der Illusion hin, alles bis zum letzten Tag hin genauestens geplant und damit im Griff zu haben. Den Schritt zurück zu machen und zu akzeptieren, dass der Plan sehr wahrscheinlich so nicht eintreten wird, ist schwierig, aber notwendig. Es gelang in diesem Projekt und im Laufe der Zeit entwickelte sich der Releaseplan zu einem zentralen Planungsinstrument.
IMG_0464 Kopie 3

Sehen, worüber wir reden

Trotz des Releaseplans traf das Management in seinem Lenkungskreis (in dem nur der Gesamtprojektleiter, aber kein Product Owner oder ScrumMaster vertreten war) Entscheidungen, die mehr oder weniger große Auswirkungen auf unser Projekt und unseren Releaseplan hatten. Jedes Mal passten die Product Owner resigniert den kompletten Releaseplan an die neuen Entscheidungen an. Bei der x-ten Diskussion über Inhalt und Budget nahmen wir ScrumMaster schließlich das Zepter in die Hand. Wir forderten das Management auf, seine Diskussionen zu neuen Entscheidungen direkt mit uns – den ScrumMastern und Product Ownern – vor unseren Artefakten zu führen und Befürchtungen mit uns zu besprechen. Um es kurz zu machen: Das war die beste Entscheidung, die wir je treffen konnten. Noch nie zuvor hatte es zwischen dem Management (dem Lenkungskreis) und den Projektverantwortlichen einen so regen Austausch über den Scope und das Budget des Projekts gegeben. Alle Unklarheiten wurden geklärt und wir erzielten ein gemeinsames Commitment. Die Teams hielten dieses Commitment auch ein und lieferten.
Im Nachhinein hat es über den Erfolg des Projekts entschieden, dass das Top Management eingebunden wurde und sich mit den Verantwortlichen direkt und regelmäßig ausgetauscht hat. Wie oft hatten wir in der Vergangenheit das Gefühl gehabt, dass reines „Management by Desk“ praktiziert wurde, ohne zu wissen, wie es um das Projekt wirklich bestellt war. Wie oft hatte das Projektteam Angst vor folgenschweren Entscheidungen im Lenkungskreis. Angst davor, dass das Projekt gestoppt werden könnte, trotz erster nachweisbarer Erfolge. Angst vor Budgetkürzungen, die uns den notwendigen innovativen Freiraum nehmen könnten.
Daher nochmals mein dringender Appell: Nehmt euer Management an die Hand! Führt es zu den Artefakten und trefft dort mit den richtigen Personen die richtigen Entscheidungen — gerade und vor allem in traditionell geprägten Unternehmen.

Skalierung aus der falschen Richtung

Wer darüber nachdenkt, wie man Scrum in großen Projekten macht, fängt meistens mit dem klassischen Bild an: Der Product Owner erstellt das Backlog und dann wird es priorisiert … bla, bla, bla – das ist euch allen mittlerweile klar. Wenn ich aber darüber nachdenke, wo die meisten Features herkommen, wer die Fehler findet, wer sich im Review mit dem Kunden auseinandersetzt, dann wird schnell klar, dass die meisten Backlog Items von den Entwicklungsteams geschrieben werden. Sie müssen sowieso von ihnen entwickelt werden. Schaut man in den Design Thinking Prozess von IDEO, dann wird auch dort sehr deutlich, dass das Entwicklungsteam sich selbst überlegt, was der Kunde am Ende benötigt.

Die Entwicklungsteams selbst erstellen die Backlog-Einträge und priorisieren sie auch selbst. Obwohl ich mir das Video über IDEOs Shopping Cart bestimmt 100 Mal angeschaut habe, hat es nicht wirklich Click gemacht. Mir fällt sogar auf, dass ich in jedem Training immer wieder sage, dass das Team die eigentlichen Backlog Items schreibt, aber – wie gesagt – das Klick, das Heureka, fehlte. Dabei lag es schon seit Jahren auf der Hand. Der Product Owner war in den meisten Projekten damit überfordert, wissen zu müssen, was das richtige Feature ist. Er weigerte sich auch oft, das Backlog zu priorisieren und wusste häufig nicht, ob die Kunden das Feature wirklich wollen. Er brauchte immer das Entwicklungsteam, damit er die richtigen Entscheidungen treffen konnte. So weit so schön, wir haben dann immer tolle Erklärungen gefunden, warum der Product Owner, obwohl er keine Ahnung von der Materie hat, dem Entwicklungsteam sagen müsste, was es zu entwickeln hätte.

Dieses Bild hat ausgedient – Skalierung funktioniert so nicht!

Das geht nur so lange gut, wie man nicht skalieren muss. Dann fällt das ganze Kartenhaus zusammen – in einem solchen Fall mit Product Ownern zu arbeiten, die sich inhaltlich nicht auskennen und daher keine Entscheidungen treffen können, führt zu den gleichen Effekten wie im klassischen Projektmanagement: niemand will Entscheidungen treffen. Der Klick kam bei mir, als mich ein Kunde etwas fragte. Dafür bin ich ihm wirklich dankbar.
In diesem Projekt hatten wir es mit 150 Beteiligten – Wissenschaftlern, Entwicklern, Programmierern, Managern – zu tun. Wir rangen mit tausenden kleinerer und größerer Probleme, und wir machten das durch das Aufstellen von Backlogs transparent. Weil das Management die Sicht auf das Ganze haben wollte (was verständlich und nachvollziehbar ist), tauchte die Frage auf, ob man denn so etwas wie ein Master Backlog habe und ob nicht mit entsprechenden Filter-Funktionen in JIRA sichergestellt werden könne, dass alles wirklich abgearbeitet wird? Die gängige Erklärung ist: Sicher, das geht! Das findet sich auch in allen vorhandenen Bildern zur Skalierung von Scrum. „Aber wieso eigentlich?“, fragte ich meinen Kunden. Das Master Backlog sei doch keine Input Queue, sondern bilde nur die Realität ab. Wir müssten unbedingt vermeiden, dass der Product Owner des Master Backlogs dieses priorisiert. Die Verwunderung war groß, denn jedes Bild in Scrum suggeriert, dass die Macht beim Product Owner liegt. Er füllt den Sprint. Der Product Owner kann dieses Backlog aber gar nicht in eine korrekte Reihenfolge bringen. Es sind zu viele Einträge. Der Product Owner müsste bei einem großen Projekt gottgleich alles beantworten können. Solche Typen gibt es, sie sind aber sehr selten und ihr Gewicht wird in Gold aufgewogen.
Gleichzeitig gibt es dennoch – ob der Product Owner es kann oder nicht – zwei Fragen zu lösen:

In großen Projekten ist darüber hinaus drittens auch noch die Frage entscheidend, ob man überhaupt alle Abhängigkeiten zwischen den Teams berücksichtigt hat.
Können die Product Owner diese Fragen nicht selbst lösen, dann müssen sie wohl oder übel die Teams selbst fragen. Doch was, wenn die Product Owner es ihren Teams nicht zutrauen, diese Fragen zu beantworten? Sehr oft haben die Product Owner damit auch recht. Häufig gibt es externe Kollegen in den Teams und die wissen gar nicht all das, was die Product Owner wissen. Sie können es noch gar nicht wissen. Dann bleibt nur, die wenigen Experten in den Teams zu fragen, und schon hat man einen Infinite Loop geschaffen.

Mit Selbstorganisation hat das gar nichts zu tun – nur mit noch mehr Kontrolle

Der Wahn, alles müsste transparent und rückverfolgbar sein, auch nach Monaten oder Jahren müsste noch klar sein, welche Zeile Code von welchem Entwickler geschrieben wurde – dieser Wahn ist heute von vielen Entwicklern umgesetzt worden. Dank JIRA, Bamboo, Team Foundation Server und anderen Tools lässt sich ja alles rückverfolgen. All das hat zu noch mehr Kontrolle und noch weniger Selbstverantwortung der Kollegen geführt. Das Schreiben eines JIRA-Tickets ist einfach – da kann ich als Teammitglied schnell das Denken abschalten, denn es wird ja von einem anderen entschieden, ob ich dann daran arbeiten soll. Wieder wird die Verantwortung nach oben delegiert. Die Entscheidung liegt erneut beim Product Owner, der aber nicht für jede Kleinigkeit geradestehen kann. Wo kommt dieser Anspruch eigentlich her? Denn das sollte er in Scrum gar nie können. Nonaka und Takeuchi hätten nicht beschrieben, wie man einen interdisziplinären, cross-funktionalen Management-Prozess entwickeln kann (den Jeff Sutherland zu Scrum ausgebaut hat), wenn sie dabei gleichzeitig an volle Kontrolle gedacht hätten.
In vielen Scrum-Skalierungsansätzen wird aber genau das Gegenteil propagiert. Was mich dabei erstaunt: In Deutschland sind die Modelle, die das Top-Down-Prinzip in der Skalierung von Scrum erklären (SAF) beliebter als in den USA. Hier werden mehr Bücher dazu gekauft, als in den USA (sagt mein Verlag). Da ist was faul. Übrigens funktioniert es auch nicht. Was gut funktioniert: Skaliert wird durch Abgeben der Verantwortung bei gleichzeitiger Standardisierung, und die Berater verdienen damit viel Geld.
Wenn die Backlogs nicht vom Product Owner und seinen Product-Owner-Kollegen aufgestellt und in die „richtige“ Reihenfolge gebracht werden, wer macht es dann? Genau, die Entwicklungsteams! Skalierung ist dann ganz einfach, denn diese Kollegen wissen sehr gut, was als Nächstes getan werden muss. Sie wissen, ob es heute sinnvoller ist, den Defect zu fixen, oder das nächste Feature anzufangen. Sie haben den Kontakt zu den Usern und können viel besser verstehen, was dort gebraucht wird. Können wir aber den Teams trauen? Wie verhindern wird dann Wildwuchs? Wie verhindern wir, dass Dinge gemacht werden, die niemand braucht? Wie verhindern wir, dass die Entwickler nicht businessgetrieben arbeiten, sich in Lösungen verfangen, einer interessanten Idee nach der anderen nachgehen?
Meine provokante These: Lassen wir doch einfach zu, dass es Schwund und Fehlentwicklungen gibt. Es ist viel billiger, als alles überwachen zu wollen. Die teuren Management-Runden, in denen sich Product Owner erklären lassen, was das Richtige ist, ergeben wenig Sinn. Scrum selbst ist das Korrektiv. Wenn eine Entwicklungsmannschaft nicht liefert, keine Lösungen, keine Ergebnisse, keine neuen Erkenntnisse, wenn sich die Entwicklungsteams ums sich selbst drehen, dann wird das doch im Review sichtbar. Dann kann das Management doch eingreifen. Aber es in die Teams hinein zu kontrollieren, das funktioniert nur bedingt. Dabei wäre das sogar möglich: Wer Qualitätsmanagement als Lernprozess versteht und gefundene Fehler nicht als Versagen von Menschen, sondern als gegebene Realität sieht, wer vergossene Milch als Verlust abschreibt und nach vorne schaut, der kommt auch damit klar, dass Nicht-Liefern eine Information ist. Eine Information ans Management, dass gehandelt werden muss.
Aber das erklärt noch nicht, wie Firmen nun selbstorganisiert skalieren können, oder doch? Ich denke schon! Der Trick besteht darin, sich selbst steuernde, cross-funktionale Teams zu etablieren, die innerhalb eines Kontexts nur auf eine einziges Ziel hinarbeiten können. Dieses Ziel wird durch die Vision geschaffen, doch der Weg dahin bleibt den Teams überlassen. Die Teams müssen sich standardisierte Schnittstellen überlegen. So wie das in der Bauindustrie und in der Elektroindustrie doch auch funktioniert. Diese Übergaben werden trainiert, geschult und zertifiziert. Diese Standards zu verändern ist mühsam, aber so können funktionierende, vielleicht nicht immer perfekte Lösungen gefunden werden. Die Rahmenbedingungen werden von der Organisation gesteckt und die Teams so lange darauf geschult, bis sie die Rahmenbedingungen verstanden haben. Teams, die liefern, werden belohnt und die anderen werden lernen, was erfolgreich ist und werden es kopieren. Gleichzeitig überlässt man mehr und mehr Verantwortung den kleineren Funktionseinheiten, den Teams. Ist das perfekt? Ich weiß es nicht, aber Amazon und Google, Facebook und 3M fahren mit diesem Ansatz ziemlich gut.

Design Thinking für Product Owner – Teil 1: Was ist eigentlich Design Thinking?

Mit der Reihe “Design Thinking für Product Owner” wollen wir Product Owner Anhaltspunkte dafür geben, wie sie ihr Produkt gestalten können und wie sie die Items für das Product Backlog generieren können.

Warum ist Design Thinking für Product Owner wichtig?

Der Product Owner ist für den Return on Investment verantwortlich, er bestimmt die Eigenschaften des Produkts, priorisiert nach Business-Value und kommuniziert eine klare Produktvision. Aber was der Nutzer wirklich braucht und wie aus vagen Produktideen eine klare Produktvision wird, beantwortet Scrum nicht!
Genau hier kann Design Thinking den Product Owner unterstützen. 
In Iterationen nähert man sich der bestmöglichen Lösung für den Nutzer, generiert Wissen für sich und andere und kann schlussendlich dem Kunden und dem eigenen Scrum-Team eine getestete und erfolgversprechende Produktvision im Spannungsfeld aus Wünschbarkeit, Machbarkeit und Wirtschaftlichkeit präsentieren.
DT01_1
Design Thinking behält dabei stets die Menschen, die das Produkt benutzen sollen, im Fokus und strebt danach, die Erfahrung des Nutzers mit der kreierten Lösung zu verbessern.

Was ist eigentlich Design Thinking?

Viele Menschen sehen auf den ersten Blick nur den Design-Thinking-Prozess, im Grunde ist Design Thinking aber eine agile Grundhaltung und eine Sammlung verschiedener Techniken aus unterschiedlichen Disziplinen. In der Kombination soll dies die Erfolgswahrscheinlichkeit bei der Entwicklung von Lösungen in komplexen Umfeldern erhöhen. Die Entwicklung von Ideen im moderierten Design-Thinking-Prozess ist dabei absolut nutzerfokussiert, ergebnisoffen und doch ergebnisorientiert. Das interdisziplinäre Team sucht nach aktuell unbefriedigten menschlichen Bedürfnissen, die dann im Mittelpunkt der Lösungsfindung stehen.
Mitte der 1990er-Jahre wurde an der Fakultät für Ingenieurwesen der Universität Stanford der Name “Design Thinking” für dieses methodische Gerüst der Innovationsarbeit geprägt und in der 1991 gegründeten Innovations-Agentur IDEO bereits angewendet.
In Europa wird diese Methode heute an der School of Design Thinking des Hasso-Plattner-Instituts in Potsdam … nun, nicht gerade gelehrt … eher erfahrbar gemacht.

Was heißt “agiles Mindset”?

Die wichtigsten Komponenten sind das Team, der Raum und der Prozess, aber ohne die passende persönliche Einstellung funktioniert Design Thinking nicht. Design Thinking braucht “T-shaped People”! Eine Bezeichnung für Menschen, die eine Tiefe/Spezialisierung in ihren Skills (vertikaler Balken) aufweisen, aber dennoch in der Lage sind, über Ihre Disziplin hinaus (horizontaler Balken) mit anderen Experten und Perspektiven zusammen zu arbeiten, zu teilen und zu wachsen.
 Der Design-Thinker sollte mit Unvorhersehbarkeit und Unsicherheit umgehen können. Positiv formuliert: Es bedarf einer mutigen, neugierigen und ergebnisoffenen Grundhaltung, denn der Design-Thinker kennt zu Beginn die Lösung nicht und wird erst im Laufe des Prozesses zum Experten. Er provoziert das Scheitern und setzt sich dem gnadenlosen Feedback der Nutzer aus … und das tut weh! 
Aber es ist auch der Auftakt zu neuen Erkenntnissen und – da man stets im Team arbeitet – zum gemeinsamen Lernen.
All dies sollte der Design-Thinker wirklich wollen, verordnen kann man es nicht.
Design Thinking & Change Management Flipcharts
In den folgenden Beiträgen zu “Design Thinking für Product Owner” werde ich Design Thinking näher erklären und aufzeigen, wie es mit Scrum kombinierbar ist.
 Ich freue mich über Fragen, Anregungen und Diskussionen!

Der ScrumMaster – zwischen Stühlen und Fronten

Ort: Meetingraum
Zeit: 08:47
Zweck des Meetings: Sprint Planning 1
Die Beteiligten meiden Augenkontakt. Hochrote Köpfe, betretene Stille. Es geht nicht mehr weiter. Soeben haben sich zwei erfahrene Entwickler des Teams mit dem Product Owner angelegt.
Streiten. Der Product Owner fordert eine sehr große Story für den zu planenden Sprint, weigert sich jedoch, sie zu splitten. Sie in zwei zu teilen. Die Gründe dafür verstehen die Entwickler nicht. Sie verweigern das Commitment. Als ScrumMaster kann ich der Diskussion aus fachlicher Sicht schon lange nicht mehr folgen. Ich fühle mich gelähmt, frustriert, fast unfähig, zum Ziel des Meetings, dem Commitment zu führen. Klar ist mir nur eines: Die Gründe für diese Bewegungslosigkeit liegen im Verborgenen. Weit unter der Oberfläche, denn die Entwickler überzeugen sachlich und argumentatorisch auf ganzer Linie.
Als klar wird, dass es nicht mehr weitergeht, wird das Commitment um einen verträglichen Zeitraum verschoben, um eine Klärung herbeizuführen und die Gemüter zu beruhigen.
Nach ca. einer Stunde kommt der Product Owner zum Team, lenkt ein und stimmt sichtlich erbost zu, die Story doch noch anzupassen. Die Situation scheint gelöst.
Weit gefehlt.
Nach ein bis zwei Stunden taucht die Story im Computersystem wieder auf und … ist unformuliert, aber nicht gesplittet. Die Verärgerung ist den Entwicklern am ganzen Körper und vor allem an ihrer Gesichtsfarbe anzusehen. Die Entwickler bitten mich mit meinen „politischen Fähigkeiten“ – so die Entwickler – um Hilfe und darum, zum Product Owner zu gehen und letztlich zu erbitten, was er doch zugesagt hatte: Die Story in zwei kleinere zu splitten. Ich stimme zu und mache mich sofort auf den Weg.
Ich, als Fachfremder, sehe meine Chance, mir weiteres Standing beim Team zu verdienen. Nun bin ich gefordert und kann meine Fähigkeiten unter Beweis stellen. “Hoffentlich”, denke ich. Es fühlt sich wie ein bewegender Schlüsselmoment für mich und die weitere Zusammenarbeit mit meinem Team an. Ist doch sonst so schwer spürbar, was man an einem langen Tag geleistet hat.
Reden. Ich betrete das Büro des Product Owners. Leider sitzt er noch nicht beim Team. Änderung ist jedoch in Sicht. Ich begebe mich freundlich zum Product Owner und frage ihn mit einem einladenden Lächeln, ob er mir drei Minuten seiner Zeit schenken kann. Ich setze mich zu ihm und danke für die Bereitschaft, über die Story zu sprechen. Ich nehme eine ähnliche Körperhaltung ein wie er, um eine positive Stimmung zu erzeugen und bitte ihn erneut, die Story zu teilen. Es braucht drei Minuten freundliche Worte und ein wenig Small Talk. Der Product Owner stimmt zu, die Story gemeinsam mit mir so umzuformulieren, dass das Entwicklerteam umgehend bereit ist, sein Commitment abzugeben.
„Wie leicht war das denn?“, frage ich mich, kehre voller Stolz zum Team zurück und verbreite die gute Nachricht. Das Team kann nun die neu entstandene und kleinere Story committen.
Verbinden. Ich spüre Freude, Stolz und Erfolg auf ganzer Linie. Mir wird bewusst, was es heißt, ScrumMaster zu sein. Wir ScrumMaster sind das Sprachrohr zwischen den Gemütern, die Mittler zwischen den Parteien, die Mediatoren und Psychologen. Die mit den geheimnisvollen Soft Skills, die Impediments jedweder Art aus dem Weg räumen. Es wird klar, wozu es uns ScrumMaster braucht. In vielen Fällen blockieren die Dinge aufgrund von Befindlichkeiten, Ängsten, Politik oder zwischenmenschlichen Themen.
In meinem Fallbeispiel wird sehr deutlich, dass es oft nur der richtigen Ansprache oder dem Schaffen einer positiven Stimmung braucht, um ein gemeinsames Ziel zu erreichen.
Erschöpft und zufrieden zugleich sinke ich in meinen Bürostuhl und kann kurz darauf das Sprint Planning 1 mit einem einstimmigen Commitment des Teams beenden.
Was habe ich aus meinem Erlebnis mitgenommen? Zum einen wird mir klar, wie wichtig regelmäßige und qualitativ wertige Estimation-Meetings sind, an denen immer alle Teammitglieder teilnehmen. Zum anderen sehe ich die Vorteile, als externer ScrumMaster tätig sein zu können. Frei von Ängsten oder gar Abhängigkeiten kann ich mit verschiedensten Vertretern eines Unternehmens kommunizieren.

You can't be everything to everybody – 4 Strategien für ein Minimum Viable Product

In einem meiner letzten Beiträge habe ich bereits über die Bedeutung des Minimum Viable Products geschrieben. Dieses Mal stelle ich nun vier mögliche Strategien vor, Kunden aber auch potentielle Investoren bereits vor dem eigentlichen Launch für ein Produkt zu begeistern und wertvolles Feedback einzuholen.
Das Erklär-Video
Das Erklär-Video ist kein Produkt im engeren Sinne, sondern beschreibt dem potentiellen Nutzer die Funktionen, die er in Kürze von dem Produkt erwarten kann. Dieses Video ist entweder ein kurzer Animationsfilm, oder vielleicht ein Video eines bereits funktionierenden Prototypen. Ein gutes Beispiel für ein Video als MVP lieferte Dropbox: Bereits vor Fertigstellung der ersten Release sprang die Zahl der Newsletter-Abonnenten innerhalb eines Tages von 5.000 auf 75.000. Defintiv genug, um ein Gefühl dafür zu bekommen, ob es sich lohnt, weiterzumachen. Es versteht sich von selbst, dass ein solches Video entsprechend beworben werden muss.
Die Landing Page
Auf einer Landing Page landen Kunden in der Regel dann, wenn sie im Vorfeld auf eine Online-Anzeige geklickt haben. Sie ist also eine Art Barometer für den Erfolg der Online-Marketing Aktivitäten. Trotzdem soll sie den Besucher im nächsten Schritt dazu anregen, sich für einen Newsletter zu registrieren. Die größte Herausforderung besteht darin, die Value-Proposition so simpel und eindrucksvoll wie möglich zu transportieren – beispielsweise indem man sie mit dem Erklär-Video kombiniert. Achtung: Eine Landing Page ist nur dann wertvoll, wenn man entsprechende Analyse-Tools, wie beispielsweise Google Analytics, einbindet, um den Erfolg oder Misserfolg auch messbar zu machen.
Das Wizard of Oz MVP
Ein Wizard of Oz Minimum Viable Product gibt an der Oberfläche vor, ein Produkt oder ein Service zu sein, das in Wahrheit so noch nicht existiert. Das US-Vorbild des Onlineversandhandels Zalando, zappos.com, hatte beispielsweise damit angefangen, Schuhe in lokalen Schuhläden zu fotografieren und anschließend online zu stellen. In dem Moment, in dem Kunden diese dann online auswählten, gingen die Gründer von Zappos zurück in den Laden, kauften das ausgewählte Modell und kümmerten sich um den Versand. Wichtig: Hier geht es noch nicht darum zu überprüfen, ob ein Produkt oder Geschäftsmodell skalierbar ist, sondern lediglich darum, eine Hypothese zu testen.
Das Concierge MVP
Das Concierge MVP eignet sich besonders dann, wenn das zukünftige Produkt automatisierte Prozesse beinhalten soll, die so noch nicht abbildbar sind. Ich selbst habe sehr gute Erfahrungen mit dieser Art von MVP gemacht: Für eine Smartphone App wollten wir Veranstaltungsdaten über ein Content Management System auch in der App verfügbar machen. Da die erforderliche Schnittstelle für Datenimport und -umformatierung noch nicht fertig war, wir aber unbedingt den Kunden von unserem Produkt überzeugen wollten, haben wir die Daten eben selbst und von Hand eingetragen – mehrere Tage hintereinander, gerne bis tief in die Nacht. Das war zwar mitunter nicht die spannendste aller Tätigkeiten, aber auf diese Weise konnten wir zeigen, wie sich unser Produkt auf Nutzerseite am Ende anfühlt, ohne dass wir bereits den kompletten Funktionsumfang anbieten mussten.
Der Grad der Anwendbarkeit des MVP-Ansatzes und der hier aufgeführten Strategien variieren sicherlich stark, je nachdem, um welches Produkt es sich letztlich handelt.
Die Grundidee des Minimum Viable Products – sich bei der Produktentwicklung auf einige wenige Kernfunktionen des späteren Produkts zu fokussieren – ist jedoch branchenübergreifend gültig und sollte jedem Product Owner präsent sein.

Halbgare Visionen

Welche Führung braucht es, um Produkte zu entwickeln? Zu den Aufgaben von Führungskräften gehört sicher die Entwicklung der Mitarbeiter und das Durchsetzen eines groben Zielbildes. Und doch sind diese Aspekte zu wenig, wenn es um Produktentwicklung geht. Viel zu wenig. David Auerbach hat im Slate Magazine die Lanze für den agilen Produktmanager gebrochen. Sein Credo: Es reicht nicht, das beste Team auf Erden zu haben, wenn keiner da ist, der die Entwicklung so genau kennt, dass er jederzeit entscheiden kann, was tatsächlich gebaut werden soll.
In der traditionellen Vorstellung von Führung kommt der CEO mit einer Vision und lässt diese durch die Unternehmensinstanzen (in hierarchischer Reihenfolge) ausbuchstabieren, planen und umsetzen. Die Interaktion zwischen den hierarchischen Ebenen beruht auf Delegation und regelmäßiger Überprüfung der festgesetzten Erwartungen auf Erfüllung. Die Führungskraft ist dann erfolgreich, wenn Mitarbeiter die gesteckten Ziele erreicht haben.
Was kommt bei einem solchen Ansatz raus? Nichts Gutes. Auerbach spricht von “half-baked visions” – halbgaren Visionen. Als Beispiele nennt er Microsoft, Google und Facebook. Alle drei Unternehmen seien technisch auf hervorragendem Niveau, doch fehle, anders als bei Apple, die Entwicklung eines stimmigen Produktdesigns: “Pretty much every new Microsoft product of the last 10 years fell prey to lousy execution of a half-baked vision, from the Kin to the Surface to Windows 8. But you can see difficulties of product management affecting other companies as well. Facebook’s user experience is simply a mess, still not offering any significant search capabilities (…). Google’s user experience seems to be splitting in two, with its traditionally austere search properties bearing little resemblance to the more gaudy presentation of Google Plus, with Gmail and YouTube seemingly caught in the middle.”
Diese konkreten Einschätzungen kann man teilen oder nicht. Was bleibt, ist das Bild, das Auerbach vom agilen Produktmanager zeichnet. Er ist nicht mehr derjenige, der sich auf die grobe Vision beschränkt. Seine Vision sind die vielen Details, die in der Produktentwicklung stecken. Der agile Produktmanager kennt sein Produkt “end to end”, so dass er in jeder Diskussion mitreden und entscheiden kann. Sein Arbeitsplatz ist nicht das Vorstandsbüro, sondern die Werkbank – eben überall dort, wo Entwicklung stattfindet. Als positives Beispiel nennt er Marissa Mayer von Yahoo. Ihre Detailversessenheit wird ihr häufig negativ ausgelegt, doch Auerbach sieht gerade darin ihre Stärke. Denn erst mit ihrem Wissen sei sie in der Lage, die Lieferungen der einzelnen Teams zu einem kohärenten Ganzen zusammen zu fügen:
“The product manager ideally does not take credit for the deep skills of the people with whom she works. Instead, she works as a peer to draw the necessary connections between them and keep them in sync. She pays attention to the existing self-organization of small groups of smart people and sympathetically exerts soft power to try to leverage their skills on a larger scale, without wrecking what they already do well. She does not build from the ground up, but helps fit pieces together—horizontally.”
Dieses Rollenbild – es ist extrem anspruchsvoll. Es verlangt erstens vom Produktmanager, sich in Tiefen vorzuwagen, die traditionell nur Entwicklern vorbehalten sind. Zweitens verlangt es vom Produktmanager, sein Tiefenwissen eben nicht dafür einzusetzen, bei jeder Diskussion mitzureden und mitzuentscheiden. Das bedeutet, dass die Interventionen des Produktmanagers anders motiviert sein müssen: Nicht das tölpelhafte Mitmischen auf gleicher Augenhöhe, sondern das Zusammenführen und Erheben der besten Ansätze muss im Mittelpunkt seiner Arbeit stehen. Diese integrative Leistung kann nur jemand erbringen, der genügend Abstraktionsfähigkeit und Standhaftigkeit besitzt, um die Attraktivität lokaler Ziele nicht mit der Attraktivität des Gesamtproduktes zu verwechseln.
Wenn das aber gelingt, dann ensteht etwas, wie wir es fast nur noch von handwerklichen Gewerben wie Schuh-, Uhrenmachern oder Juwelieren kennen: Produkte, die wie aus einer Hand gegossen sind, weil sie die Signatur ihres Urhebers tragen. Und deshalb auch einzigartig sind.

Führung ja, nein, jein?

Das Thema Führung hat in Unternehmen und Organisationen in den letzten Jahren eine erstaunliche und erfreuliche (scheinbare?) Renaissance erfahren. Man scheint auf breiter Basis erkannt zu haben, dass Führung – und ebenso Hierarchien – zentrale Elemente sozialer Systeme sind. Viele Dynamiken der vergangenen Jahrzehnte, wie Globalisierung, neue Technologien und vor allem die Herausforderungen permanenter und schneller Change-Prozesse, verlangen nach Orientierung, Sicherheit und Entscheidungen – also Führung. Was allerdings häufig noch fehlt: diese Erkenntnis auch stringent in die Unternehmenspraxis umzusetzen. Denn das heißt schlicht: Aufwand, Zeit und Kosten.
Reinhard K. Sprenger ist überzeugt, „dass die Aufgaben von Führung Universalien sind…“ („Radikal führen“ Campus Verlag 2013). Damit ist gemeint, dass Führung ein gegebenes, natürliches und unverzichtbares Element für Unternehmen ist. Dem ist uneingeschränkt zuzustimmen. Es kann also in diesem Sinne nicht mehr darum gehen, das Führen als Funktion und Rolle in Frage zu stellen, sondern darum, wie Führung ihre Aufgaben wirkungsvoll und effektiv erbringen kann. Zweifellos kostet schwache oder dysfunktionale Führung viele Unternehmen jährlich eine Milliardensumme. Ablesbar ist das u.a. an mangelnder Leistung, zahlreichen Krankenständen, Konflikten und hoher Fluktuation.
Führung ist zum einen das gezielte Gestalten von Interaktionen zwischen Führenden und Geführten (Mitarbeiterführung) und zum anderen das Steuern und Managen der Organisation (Unternehmensführung), beides meist in einer Rolle. Es braucht auf der einen Seite Führungspersönlichkeiten mit Ausstrahlung, sozialen Kompetenzen und Freude an der Führungsrolle. Auf der anderen Seite professionelle Werkzeuge und Instrumente zur Umsetzung in die Führungspraxis. Sache ist also, dass jedes Unternehmen höchsten Wert auf die Auswahl, Ausbildung und Pflege ihrer Führungsmannschaft legen muss. Und zwar nicht als Alibifunktion, um etwas getan zu haben, sondern als hoch priorisiertes, strukturiertes und nachhaltig umgesetztes strategisches Kernanliegen.
Dies gilt genauso, oder gerade, für laterale Führungsrollen, also Führung ohne disziplinarisches Mandat. ScrumMaster, Product Owner, Projektleiter, Teamkoordinator, Supervisor, Arbeitsplatzsteurer, oder wie immer sie auch fantasievoll tituliert werden, findet man immer häufiger in lateraler Führungsverantwortung. Gerade diese, oft neu definierten Rollen, haben meist eine ungünstige Ausgangssituation. Zum einen wird ihnen jede Menge Verantwortung übertragen und zugeschoben, zum anderen fehlt ihnen aber die echte Legitimation, gezielte Ausbildung und Weiterentwicklung und vor allem Unterstützung von oben. Ist die disziplinarische Führung schwach, zu wenig präsent, sich ihrer Unterstützungsfunktion nicht ausreichend bewusst, geraten die lateralen Funktionen in eine schwer lösbare Sandwichsituation. Im Scrum-Kontext wird das dann auch noch mit dem „Prinzip der Selbstorganisation“ verbrämt. So kann man die wertvollsten Mitarbeiter mittelfristig frustrieren oder gar ausbrennen.
Konsequenz für das Unternehmen – siehe oben: Führung als strategisches Kernanliegen betrachten, HR-Abteilungen stark machen und entsprechend investieren.
Konsequenz für betroffene Führungskräfte, insbesondere in lateraler Position: offensiv Legitimation von oben fordern und transparent machen, entsprechende Weiterbildungsmöglichkeiten nutzen und vor allem dazu stehen, dass ihre Führungsfunktion für Teams und Unternehmen elementar ist und ein genuiner Teil von Selbstorganisation.
Tipp: Die eigene Führungskraft stärken – mit dem Wissen aus den Scrum Supplements

Die Kraft der Unzufriedenheit

Auf dem Weg zur Agilität haben wir glücklicherweise immer wieder mit den Widrigkeiten eingekrusteter Strukturen, langen, scope-fixen Releases, dem magischen Dreieck etc. zu tun. Releaseplanungen und Backlog Groomings unter diesen Bedingungen durchzuführen, macht besonders viel Spaß. Man muss nämlich das Beste draus machen und gleichzeitig versuchen, den nächsten Schritt Richtung Produktorientierung zu gehen.
Was es für einen Sinn macht, Backlog Groomings, Releaseplanungs-Meetings zu veranstalten und ein gemeinsames Releaseboard zu pflegen?
Im besten Fall halten die Teilnehmer der Meetings diese irgendwann für so sinnlos und nervig, dass sie selbst anfangen, sich Gedanken darüber zu machen, wie man die Zeit sinnvoller gestalten kann. Wichtig dabei ist aber, dass man sie nicht aus der Pflicht entlässt, dass sie die Zeit gemeinsam gestalten müssen.
Bei einem unserer Kunden haben wir damit angefangen, dass alle Teams im skalierten Umfeld ihre Backlogs teamweise für die nächsten drei Sprints auf Story-Ebene auf einem riesigen Board plakatierten. Alle zwei Wochen veranstalteten wir Meetings, in denen die jeweiligen POs die Stories vorstellten, an denen ihr Team in den nächsten drei Sprints arbeiten würde. So weit im Voraus sollte das Backlog ja einen recht stabilen Stand haben. Um diese Planung machen zu können, hatten die POs aber im Vorfeld die Aufträge schon in mehr oder weniger technische Arbeitspakete geschnitten und auf die Teams/Komponenten aufgeteilt. Im Meeting selbst wurden also keine Abhängigkeiten mehr entdeckt und bei der Vorstellung der User Stories für die nächsten drei Sprints schliefen die POs entweder aus Höflichkeit oder weil wir vor dem Board standen nicht ein.
Zuerst wurde viel über das Meeting gemeckert. Es würde nichts bringen, man würde ja eh auf die anderen POs zugehen, wenn man etwas von ihnen bräuchte. Außerdem sei es zu aufwendig, die Stories auszudrucken und aufzuhängen… Als klar wurde, dass wir das Meeting trotzdem beibehalten würden, wählten sie eine andere Strategie. Statt meckern: besser machen.
Anstatt schon vorab alles zu klären und auf die Teams zuzuordnen, will man nun versuchen, die unterschiedlichen Themen mit initialen User Stories in der Priorität des Company Backlogs abzubilden. Das Meeting kann dann dazu dienen sich bewusst zu machen, welche Aktivitäten nötig sind, um das Thema abzuschließen. Außerdem kann sofort gesehen werden, ob an den richtigen Prozessen gearbeitet wird bzw. ob sich ausreichend Teams aus den oberen Themen Stories ziehen. Die Endlichkeit der Wand führt außerdem automatisch zu einer Fokussierung. Es finden vielleicht gar nicht alle Themen Platz. Die wichtigsten können aber aufgehängt werden. Merkt man, dass die kleinen Stories für die Top-Themen ausgehen, kann man in kleineren Gruppen die Detaillierung durchführen. Burndown-Charts auf Themen-Ebene werden möglich. Die nächste Stufe könnte sein, nicht mehr Themen abzubilden, sondern vielleicht die Kernprozesse im Backlog zu haben, an denen Änderungen gemacht werden. Die Priorität richtet sich dann evtl. danach, welcher Prozess am wichtigsten für das Business ist, oder wo die größten Einsparungen realisiert werden können.
Sind das Meetings und Artefakte wie sie im Buche stehen? Sicher nicht, aber es sind Mittel, die dem PO-Team helfen, den Überblick zu behalten und anderen zu geben.
Welche Möglichkeiten habt ihr durch Unzufriedenheit mit dem Status quo gefunden?