Inhalt

Cover

Anzeige

Impressum

Vorwort

Der Autor

Schätzen – eine Hassliebe

1 Ein Weg für Realisten

2 Was ist agil?

2.1  Den Kunden begeistern – Emotionen

2.2  Was macht agile Produktentwicklung aus?

2.3  Das Problem der klassischen Projektorganisation

2.4  Scrum in aller Kürze

2.4.1  Ein Paradigmenwechsel

2.4.2  Der Scrum Flow

2.4.3  Design Thinking in aller Kürze

3 Der Product Owner in seiner Rolle

3.1  Der Product Owner – eine Wesensbeschreibung

3.1.1  Perfektionismus – zwischen gut und böse

3.1.2  Produktmanager oder Product Owner – eine Typologie

3.2  Mit Scrum zur Produktqualität

4 Das Budget bestimmen: Schneller und besser ist billiger?

4.1  Wie hilft der Business Value dabei, Geld zu verdienen?

4.2  Preisbestimmung

4.3  Weniger ist mehr: das Minimum Viable Product

4.4  Der positive Projektabbruch

4.4.1  Change for free

4.4.2  Scope-Erweiterung

4.4.3  Scope-Verkleinerung

5 Das Produkt – die ersten Ideen

5.1  Projektphasen in der agilen Produktentwicklung

5.2  Exploration

5.2.1  Discovery-Phase

5.2.2  Interpretation-Phase

5.2.3  Ideation-Phase

5.2.4  Experimentation-Phase

5.2.5  Evolution-Phase

5.3  Implementierung – Scrum als Prozessmodell

6 Tools und Techniken während der Implementierung

6.1  Impact-Mapping

6.2  Prototypen

6.3  Das Wie und das Was – User Storys

6.4  Das Product Backlog

6.4.1  Eisberg – die Backlog-Struktur

6.4.2  Story-Mapping

6.4.3  Impact-Mapping vs. Story-Mapping

7 Entscheidungsgrundlagen schaffen – schätzen

7.1  Schätzmethoden

7.1.1  Magic Estimation

7.1.2  Das Estimation Meeting

7.1.3  Planning Poker

7.1.4  Team Estimation Game

7.1.5  Mini-Schätzspiele

7.2  Aufwand, Komplexität oder Funktionalität?

7.2.1  Warum schätzen wir in Funktionalität?

7.2.2  Die Velocity ermitteln – das Schätzen überflüssig machen

8 Planung und Durchführung größerer Projekte

8.1  Scrum-Teams sind klein

8.2  Große Teams in der Produktentwicklung

8.2.1  Planung im skalierten Umfeld – die Product Roadmap

8.2.2  Vom Product Owner zum Product-Owner-Team: Synchronisation während des Sprints

8.2.3  Die Prognose ersetzt den Plan

8.2.4  Monitoring – Darstellung des Fortschritts

8.2.5  Abhängigkeiten – das Umfeld

8.2.6  Cost of Delay

9 Das Ende der Taskschätzung

Ergänzende Literatur und andere Quellen

Endnoten

Vorwort

Mehr als 15 Jahre eigene Projektpraxis, zehn Jahre Scrum, die Erfahrungen als Gründer eines Unternehmens, als Beobachter und Begleiter der komplexen Projekte meiner Kunden, haben mich eines gelehrt: Aufwandschätzungen, Zeitschätzungen und viele andere Planungsaktivitäten, auf die viele Manager, Scrum-Teams und Projektmanager Wert legen, sind die Zeit nicht wert, die sie kosten. Mir ist aber bewusst, dass es vielen schwer fällt, vom Schätzen in seiner traditionellen Form loszulassen und einen neuen Ansatz zu wagen. Doch mit diesem Buch will ich diesen Ansatz vorstellen. Ich will zeigen, wie man über ein neues Verständnis des Schätzens zu einer besseren Planung kommt. Dabei erkläre ich nicht nur die derzeit gängigen Schätzverfahren, sondern gehe auf Ansätze wie das Design Thinking und das Skalieren der Product-Owner-Rolle ein. Es war mir wichtig, nicht nur diesen einen, in Wahrheit sehr kleinen Ausschnitt des eigentlichen Schätzens zu zeigen. Der wesentliche Punkt in der agilen Produktentwicklung ist, von Anfang an mit einer gänzlich anderen Haltung an ein Projekt heranzugehen. Daran kranken nämlich meiner Meinung nach viele Unternehmen und deren Projekte: An der eigenen Einstellung zum Kunden, zum User und zur eigenen Kreativität.

Mein besonderer Dank geht dieses Mal an Dolores Omann. Dieses Buch war ihre Idee, sie hat mich davon überzeugt, dass es gebraucht wird. Sie hatte den Teilnehmern bei einem Scrum-Training zugehört und ihre Not erkannt: Das Schätzen war das Thema, bei dem sich die meisten im Kreis drehten und es im Geiste nicht so richtig in ihren beruflichen Kontext integrieren konnten. Dolores textet und schreibt seit vier Jahren für mich. Dieses Mal ist es zu einem Großteil auch ihr Buch, denn sie hat mich besonders unterstützt und immer wieder motiviert, es fertigzustellen. Zwischen zwei anderen Buchprojekten schrieb ich mir das Schätzen innerhalb kürzester Zeit „von der Seele“ und habe ihr die Rohfassung in die Hand gedrückt. Ohne sie wäre dieses Buch unlesbar.

Ich möchte Ihnen mit diesem Buch ein Handwerkszeug mitgeben, mit dem Sie Ihren agilen Projektalltag meistern können. Die Techniken und Ideen sind keine theoretischen Entwürfe: Sie sind in der Praxis entstanden und sie entwickeln sich in der und durch die Praxis ständig weiter. Probieren Sie die Instrumente in Ihrem Umfeld aus. Ich verspreche Ihnen, Sie werden ein anderes Verständnis von sinnvollen Schätzungen bekommen und sichtbare Erfolge verzeichnen. Ob Sie nun als ScrumMaster, Product Owner, „klassischer“ Projektmanager oder Mitglied eines Scrum-Teams arbeiten: Vielleicht müssen auch Sie sich – wie die Teilnehmer in meinen Trainings – zunächst von bisherigen Denkmustern und Annahmen verabschieden. In diesem Buch werden Sie daher nicht nur lernen, welche agilen Schätzverfahren es gibt und wie sie funktionieren. Es geht darüber hinaus um ein neues Selbstverständnis der Menschen, die für den Erfolg eines Produkts verantwortlich sind. Es geht um neue Herangehensweisen an die Produktentwicklung. Und es geht schließlich um die Erkenntnis, dass Produkte die wichtigste Verbindung zwischen einem Unternehmen und seinen Kunden sind – diese Verbindung braucht einen neuen Stellenwert.

Dieses Buch, dieses „Produkt“, ist auch Ausdruck meiner langjährigen Verbindung zum Hanser Verlag, vor allem zum Team rund um Brigitte Bauer-Schiewek. Sie hat mich dazu ermuntert, aus diesem Thema tatsächlich ein Buch und nicht nur ein Heft zu machen, wie ich es ursprünglich geplant hatte.

Und schließlich danke ich meiner Frau Kathrin für ihre Geduld mit mir. Sie meistert viele Aspekte unseres gemeinsamen Alltags für mich mit, damit ich die Zeit habe, meine Gedanken zu Papier zu bringen.

Laxenburg, im Februar 2014

Boris Gloger

■ Der Autor

2002 führte Boris Gloger sein erstes Scrum-Team beim österreichischen Mobilfunker ONE zum Erfolg. Als weltweit erster, von Ken Schwaber ausgebildeter Certified Scrum Trainer hat er wesentlich dazu beigetragen, dass sich Scrum in Europa, Südafrika und Brasilien als Standard der agilen Softwareentwicklung durchgesetzt hat. Die Erfahrungen aus der Praxis lässt er als Verbesserungen einfließen: So führte er die Rollen Kunde, Manager und Anwender ein und hob damit die Verbindung zwischen Produktentwicklung, Organisation und Markt hervor. Mit „Magic Estimation“ hat er das Schätzen in Scrum vereinfacht.

Bevor er 2008 die Boris Gloger Consulting GmbH gründete, war der Unternehmer als Business Analyst, Team-Leader, Projektmanager und Scrum Consultant für globale Unternehmen (z. B. EDS, Nokia, BenQ) tätig. Die Managementberatung Boris Gloger Consulting GmbH hat ihren Sitz in Baden-Baden und ist auf Training und Consulting für die agile Produkt- und Organisationsentwicklung mit Scrum spezialisiert.

Folgende Bücher von Boris Gloger sind im Hanser Verlag erschienen:

■ Scrum. Produkte zuverlässig und schnell entwickeln. 4., überarbeitete Auflage, 2013.

■ Der agile Festpreis. Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge. 2012.

■ Erfolgreich mit Scrum: Einflussfaktor Personalmanagement. Finden und Binden von Mitarbeitern in agilen Unternehmen. 2011.

Kontakt: boris.gloger@borisgloger.com, www.borisgloger.com

Schätzen – eine Hassliebe

Das Thema Schätzen begleitet mich seit meinem ersten Job bei Electronic Data Systems (EDS) in Rüsselsheim. Mit einem der Projekte wollten wir unter anderem zeigen, dass wir die Standards des Capability Maturity Models Level 2 erfüllen konnten – und ich wollte dafür den Projektplan erstellen. Wie man es eben so tut, hatten wir fein säuberlich alle Zahlen zusammengetragen und mein Projektplan war einfach toll. Als unser Entwicklungsteam die Designphase beendet hatte und das Projekt in die Implementierungsphase ging, war ich vor dem Status-Meeting mit meinen Entwicklern total nervös. War das Design wirklich fertig? Die zwei Entwickler, die sich bis jetzt um das Designdokument – damals hieß das „Technical Design“ – gekümmert hatten, sagten: „Boris, wir sind fertig, aber bitte sag es noch niemandem. Wir müssen noch einen Test durchführen. Bis übermorgen ist das aber erledigt.“ Zuerst verstand ich das nicht, ich war einfach nur total happy, weil mein Projekt auf Schiene war. Dann sagte Peter, der damalige Senior System Engineer: „Boris, du hast nicht verstanden: Wir sind fertig!“ Ich muss wohl ziemlich verdutzt aus der Wäsche geschaut haben. Peter sagte mir doch tatsächlich, das Projekt sei fertig implementiert und fertig getestet – und das drei Monate früher als es mein schicker Projektplan vorgesehen hatte. Ich war völlig perplex: Die geplanten 800 Entwicklungsstunden wurden nicht gebraucht. Die beiden Senior-Entwickler, die eigentlich „nur“ das Design schreiben sollten, hatten beides gemacht – designt und fertig entwickelt. Sie hatten sich also eigentlich nicht an den Prozess gehalten. Ich fragte sie, wie so etwas möglich sei. Die Antwort der beiden war vollkommen logisch: Eigentlich hätten sie das Design so aufbereiten müssen, dass das Offshore-Team genau verstanden hätte, was zu entwickeln war. In derselben Zeit konnten sie statt Pseudocode genauso gut den Code selbst schreiben.

Ein anderes Mal fragte ich Peter, wie viel Aufwand es wäre, eine Hostmaske zu entwickeln. Sie war nicht sonderlich kompliziert. Peter antwortete wie aus der Pistole geschossen: „40 Stunden!“ Als ich ihn fragte, wie er das denn wissen könne, meinte er, dass er eine solche Maske ja nicht zum ersten Mal entwickeln würde. Er kannte sein System, er hatte es selbst entworfen. Wenn Peter und sein Team eine Schätzung abgaben, konnte ich immer sicher sein, dass ihre Angaben auch korrekt waren. Sie hielten ihre Schätzung wirklich immer ein.

Vom Blindflug zum Sichtflug

Erst Jahre später habe ich begriffen, dass das in der Softwareentwicklung nicht „normal“ war. In Projekten mit anderen Teams und anderen Auftraggebern war auch die Realität eine vollkommen andere. Bei meinem ersten großen Projekt in einem Telekommunikationsunternehmen wurde ich mit einem fertig geschätzten Projektbudget losgeschickt. Später stellte sich heraus, dass es vollkommen falsch war. Meine Vorgänger hatten die Schätzungen aus der Luft gegriffen und sie hatten sie unter der Annahme erstellt, dass die Entwicklung Ahnung von diesem zu implementierenden Internetportal haben würde. Als junger Projektmanager, der Erfolg haben musste, kam ich gar nicht auf die Idee, dass meine Entwickler nicht so professionell und erfahren sein könnten wie Peter und seine Kollegen von EDS. Es war zum Verzweifeln: Die Entwicklungsmannschaft wusste nicht, was sie tat. Woran ich das erkannte? Weil mein Entwicklungsteam von den im Design beschriebenen 149 Web-Templates nur ein einziges fertig geliefert hatte. In diesem vierköpfigen Team saßen lauter neue Mitarbeiter, die so etwas noch nie gemacht hatten. Also ging ich zu meinem Chef und warf die rote Flagge! Ich konnte ihn davon überzeugen, einen Teil des Projektprofits aufzugeben und um dieses Geld einen Entwickler zu „kaufen“, der sich auskannte. Ich hatte Glück: Zwei Wochen später war der Entwickler im Projektteam. Er schrieb 109 Templates selbst. Die übrigen 40 wurden von den restlichen Teammitgliedern erledigt – nachdem sie verstanden hatten, wie man diese Art von Templates entwickelt.

Damals berechnete ich den Projektfortschritt nicht nach den geleisteten Stunden, sondern anhand der Anzahl der gelieferten Produktteile (eben diesen Web-Templates). Auf diese Weise konnte ich herausfinden, wie weit wir im Projekt wirklich vorangeschritten waren. Alle anderen, eher traditionellen Ansätze des Projektmonitorings hätten mich komplett im Blindflug gelassen. So aber konnten wir reagieren. Wir konnten genau sagen, wie weit wir tatsächlich waren und der Fachabteilung ständig etwas Fertiges zeigen. Wie endete dieses Projekt? Wir lieferten beinahe zum ursprünglich geplanten Termin. Aus heutiger Sicht hätte dieses Projekt viel erfolgreicher sein können – hätte es nicht gleich am Anfang die auf falschen Aufwänden basierende Schätzung gegeben. Das Traurige daran: Genau so sieht die Projektrealität in vielen Unternehmen heute aus.

Diese beiden Erfahrungen weckten in mir ein tiefes Misstrauen gegen jede Form von Aufwandschätzung und hinterließen in mir das Bewusstsein, dass der Fortschritt eines Projekts auf keinen Fall in Aufwänden gedacht oder beurteilt werden kann. Kurz vor meiner Zertifizierung zum Project Manager Professional (PMP) des Project Management Institutes kam ich zur bitteren Erkenntnis, dass die gängigen Projektmanagementmethoden für das Thema Planung nicht ausreichten.

Alles besser mit Scrum?

Das Thema Schätzen ließ mein Entwicklungsteam auch nicht los, als wir Projekte immer öfter mit der neuen Wunderwaffe Scrum durchführten. Obwohl wir die Software schneller und mit höherer Qualität lieferten, wollten die Fachabteilungen immer zunächst wissen, was es kosten würde und wann es fertig sein würde. Schon gar nicht konnte ich diesen Fragen später als Scrum-Trainer entkommen. Heute genauso wie vor zehn Jahren haben die meisten Teilnehmer in den Trainings genau diese zwei Fragen im Kopf: „Wann ist es fertig und was wird es kosten?“ Dieser zwingende Wunsch nach absoluter Vorhersagbarkeit dominiert ganze Trainingsnachmittage.

Die ersten Ideen, die Ken Schwaber und Jeff Sutherland dazu in ihren Büchern aufbrachten, waren wenig hilfreich. Auch für sie war es damals immer noch logisch, in Tagen und Stunden zu schätzen. Im Laufe der Zeit wurde aber zusehends deutlicher, dass das Schätzen in Aufwänden ständig in eine Sackgasse führt. Allmählich wurde klar: Wenn es bei Frameworks und Vorgehensweisen wie Scrum immer um die Lieferung von Produktteilen geht, ist ein anderer Zugang zum Schätzen und Planen nötig.

Auf der Suche nach neuen Verfahren kam in der XP Community 2004 die Idee der Storypoints auf – eine Revolution! Zwar wurden Storypoints zunächst auch noch als „Aufwände“ verstanden, aber sie machten den Weg frei, über so etwas wie Komplexität bei Aufwänden zu sprechen. Mit den Büchern von Mike Cohn wurde das Schätzen mit Planning Poker populär. Die Fibonacci-Skala konnte implizit ausdrücken, dass es sich beim Schätzen nicht um einen exakten Wert handelt. Die Ungenauigkeit nimmt bei großen Werten zu.

Unzähligen Scrum-Teams hat dieser neue Zugang zum Schätzen sehr geholfen und neue Möglichkeiten eröffnet. Aber das Thema war noch nicht fertig gedacht. Die Schätzungen mit Planning Poker wurden immer zeitintensiver und es gab keine wirklich guten Argumente dafür, was denn der Tester in einem Team schätzen sollte. Der Begriff der Komplexität hatte das Denken in Aufwänden nur kaschiert – verschwunden war es noch nicht. In Trainings und Projekten suchten wir umständlich nach Argumenten, weshalb zum Beispiel eine Story mit dem Wert 13 das eine Mal lange dauerte und das andere Mal einfach nur schwer (kompliziert, da komplex) war.

Ich machte mich auf die Suche nach einer Methode, mit der ich diese Unklarheit lösen konnte. Bei wissenschaftlichen Erklärungen gilt das Prinzip der Einfachheit: Wenn eine Vorgehensweise zu komplex und undurchsichtig wird – und das war für mich die Idee, Aufwände durch Komplexität zu ersetzen –, dann ist sie falsch.

It's the increment, stupid!

Irgendwann, als ich gerade wieder das Schätzen in Storypoints erklären wollte, machte es „klick!“. Damals, im beinahe katastrophalen Webprojekt, hatte ich doch den Projektfortschritt nicht in Stunden, sondern in gelieferten Web-Templates gemessen. Ich hatte einfach nur die Lieferungen gezählt. Da war er, der Erkenntnissprung! Wenn wir nicht mehr in Aufwänden denken, sondern in Lieferungen, dann – ja dann brauchen wir doch nur die gelieferten Funktionen (Storypoints, Websites etc.) zu zählen. Damit haben wir ein Maß für das gelieferte Produkt und können das wiederum in einen Trend umwandeln.

Es war trotzdem noch ein langer Weg von dieser Erkenntnis zur heutigen Variante, in Projekten vollkommen auf das Schätzen von Aufwänden zu verzichten. Der Theoretiker in mir musste erst vom Experimentator in mir bestätigt werden. Und das gelang auch: Als meine Mitarbeiter und ich in einem wirklich großen Projekt mit mehr als 180 Entwicklern, 18 ScrumMastern und 18 Product Ownern dabei helfen konnten, mit Magic Estimation und Epic-Schätzungen das tatsächliche Lieferdatum mit einer Abweichung von nur zwei Wochen zu schätzen, war ich endlich von meiner eigenen Methode überzeugt.

Heute nutzen wir diese Methode ständig. Zwar gibt es immer wieder Widerstand, aber wenn das Konzept nach einigen Estimation Meetings verstanden ist, sind auch unsere Kunden von den Vorteilen überzeugt. Der Verzicht auf Aufwandschätzungen beschränkt sich aber faszinierenderweise nicht auf die User Storys. In den Anfängen meiner Scrum-Karriere war ich von der Idee überzeugt, dass die Entwicklungsmannschaften ihre „Remaining Hours“ pro Sprint in einem Sprint-Burndown aufzeichnen sollten. In den ersten Scrum-Jahren führte das zu interessanten Dynamiken: Aus eigentlich gut gemeinten Sprint Plannings 2 wurden teilweise quälend langweilige und frustrierende Sitzungen, in denen die Entwickler versuchten, sich abzusichern. Die Idee, die Tasks zu schätzen, sollte eigentlich dabei helfen, sich zu „committen“. Tatsächlich wurde es aber noch schwerer, ein Commitment zu bekommen. Tobias Mayer hatte 2006 die Idee, dass die Aufgaben maximal einen Tag dauern sollten. Ein guter Ansatz, aber nun begannen die Entwickler wieder darüber nachzudenken, ob eine Aufgabe acht oder zehn Stunden dauern würde. Das war verschwendete Zeit. In den folgenden Jahren kam ich zu dem Schluss, dass wir völlig auf das Schätzen von einzelnen Aufgaben verzichten müssen. Heute schätzen wir nicht mehr, wie lange Aufgaben dauern und das hat einiges dazu beigetragen, dass Scrum und Kanban von Teams erfolgreich adaptiert werden konnten.

Ohne den Product Owner ist alles nichts

Schätzen ist in Scrum-Projekten also zusehends unwichtiger geworden. Ja, natürlich werde ich Ihnen zeigen, wie man ohne Aufwandschätzung schätzt. Allerdings gestehe ich, dass der Titel dieses Buchs etwas zu einseitig auf diesen Aspekt gerichtet ist. Den Titel habe ich gewählt, weil ich weiß, dass das Schätzen eines der größten Probleme in agilen Projekten ist. Es ist aber nur ein ganz kleiner Aspekt und nur eine der unzähligen Herausforderungen, die ein Product Owner zu meistern hat.

Daher werden Sie in diesem Buch noch vieles mehr finden, das meiner Meinung für den Erfolg eines Scrum-, Kanban- oder anderen agilen Projekts notwendig ist:

■ Design Thinking

■ Ein tieferes Verständnis für die Aufgaben des Product Owners

■ Skalieren von Scrum in größeren Projekten

All das sorgt dafür, das Sie etwas schätzen können, das Sie kennen. Sie erfahren, wie Sie zu User Storys kommen. Sie erfahren, wie man die User Storys anordnet, um einen Releaseplan oder besser gesagt eine „Customer Journey“ zu erstellen. Mit einer neuen großartigen Idee, dem Impact-Mapping, werden Sie in der Lage sein zu entscheiden, welche Storys Sie liefern lassen wollen.

All das setzt aber einen Entscheider im Projekt voraus: den Product Owner. Dieses Buch soll daher auch zeigen, welche Qualitäten ein Product Owner haben muss. Wie er sich gegenüber der Organisation aufstellen sollte und welches Selbstverständnis er braucht.

1 Ein Weg für Realisten

Drei Teams stehen in einer Werkshalle. Hier haben sie viel Platz für die integrierte Entwicklung eines neuen Produkts, hier können sie miteinander arbeiten, diskutieren und lachen. Karl, Consultant in meinem Unternehmen, erklärt gerade, wie Magic Estimation funktioniert. Ich selbst stehe mit dem Product Owner der Teams etwas abseits und beobachte mit ihm, was gerade passiert. Uns fällt auf, dass die Teammitglieder sehr unsicher sind – sie fragen Karl ein Loch nach dem anderen in den Bauch. Nach fünf Minuten hat er sie aber davon überzeugt, Magic Estimation eine Chance zu geben und das Spiel einfach einmal auszuprobieren. Es ist wie im Bilderbuch: In einem großen Gewusel beginnen die Teammitglieder damit, die User Storys zu verteilen. Nach kurzer Zeit legt sich aber die Hektik, es wird ruhiger und nur mehr vereinzelt werden User Storys umsortiert. „Und was kann ich jetzt damit anfangen?“, fragt mich der Product Owner. „Ich will doch sowieso alle Storys, die gerade geschätzt wurden, im nächsten Sprint umgesetzt sehen.“ Ich erkläre ihm den eigentlichen Sinn von Magic Estimation: Es hilft zu erkennen, welche User Storys das Entwicklungsteam verstanden hat und bei welchen es noch unsicher ist. Das Gesicht des Product Owners spricht Bände, er begreift nicht sofort, was ich meine. In Karls Debriefing nach dem Spiel wird es dann allen Beteiligten klar: Es geht nicht so sehr um das Schätzen von Funktionalitäten, sondern um die Frage, ob wirklich alle verstanden haben, was gewünscht wird.

Natürlich gab es auch in diesem Projekt eine Deadline. Den einen Termin, der unbedingt gehalten werden musste. Nach einigen Gesprächen wurde aber klar, dass es wie so oft gar nicht darum ging, alle Features zu liefern: Eigentlich wollte der Product Owner bei der geplanten Präsentation ein Produkt zeigen, das begeistern sollte. Welche Funktionalitäten zu diesem Termin vorhanden sein würden, war in Wahrheit nebensächlich. Eine Forderung nach Vollständigkeit gab es nicht.

Bei solchen Erlebnissen drängt sich mir die Frage auf: „Geht es in Projekten wirklich ums Schätzen und um die Antwort auf die Frage, wann etwas vollständig fertig wird?“ Auf den ersten Blick sicher, schließlich wird die Frage nach der Fertigstellung ständig gestellt. Und dann lese ich, dass sich die Arbeiten am Berliner Flughafen einmal mehr verzögern und es in den Sternen steht, wann er nun wirklich eröffnet werden kann. Die Projektrealität ist also doch eine ganz andere. Projekte und Produkte werden fertig, wenn es soweit ist.1 Ich erlebe Unternehmen, die neun Monate alleine auf die Neuplanung eines Projekts verwenden. Neun Monate für die Planung! In diesem Zeitraum könnte man mit konstruktivem, iterativem, inkrementellem und gemeinsamem Arbeiten bereits die ersten Ergebnisse liefern. Man wüsste, ob man auf dem richtigen Weg ist. Wahrscheinlich hätte man schon nach drei Monaten konkrete Zahlen. Dazu braucht es aber Menschen, die tatsächlich fokussiert an diesem Produkt arbeiten – gemeinsam in einem Raum und mit einer Führungskraft, die dem Team beim Überwinden der eigenen blinden Flecken hilft. Diese Führungskraft würde den Austausch im Team fördern und so dazu beitragen, dass jeden Tag ein neues Teil des Produkts entstünde. Rhythmisch getaktet würde dieses Team bis zur Deadline das Produkt stückweise liefern.

Der Product Owner muss als Erster zu dieser Erkenntnis kommen. Erst wenn er versteht, dass man ein Produkt nicht durch das Abarbeiten einer Liste gewinnt, sondern dass man es durch das ständige Reagieren auf die Veränderungen im Rahmen seiner Möglichkeiten gestaltet, erst dann kann er mit den Kunden, mit dem Management und mit dem Entwicklungsteam gute Erfolge erzielen. Diese Erkenntnis fordert vom Product Owner aber auch eine besondere Haltung: „Ich, der Product Owner, bin für den Erfolg wesentlich.“ Das heißt für ihn, nahe an „seinem“ Produkt zu sein. Er muss auf jedes Detail achten, ja er muss sich regelrecht in sein Produkt verlieben. Er ist inhaltlich für sein Produkt verantwortlich.

In der Praxis treffe ich leider immer noch viel zu oft das völlige Gegenteil an: Product Owner, die Produkte im Überflug kreieren wollen. Sie glauben, man könne gute Produkte bauen, ohne sich wirklich mit ihnen zu beschäftigen. Meistens bleiben sie in ihrer traditionellen Projektmanagement-Haltung stecken: „Ich muss das Projekt doch nur steuern, aber nicht inhaltlich arbeiten!“ Dazu sage ich nur: Das ist falsch! Im Laufe dieses Buches werden wir auch sehen, dass der Product Owner ein Produktspezialist ist.

Ein echter Product Owner, ein guter Product Owner, erträumt sich das Produkt. Diesen Traum setzt er gemeinsam mit seinem Entwicklungsteam in die Realität um und richtet sich dabei an der Realität aus. Ständig überlegt er, was er mit den zur Verfügung stehenden Mitteln erreichen kann – und versucht das Bestmögliche zu erreichen. Die Realität zu akzeptieren und mit ihr zu arbeiten, die Möglichkeiten zu nutzen, die sich bieten: Das ist die große Kunst begnadeter Product Owner.

	Ich möchte aber gleich an dieser Stelle eine Warnung aussprechen: Mit Methoden wie Magic Estimation lassen sich die User Storys auch großer Projekte rasch und vor allem sehr genau schätzen. Sie werden beim Lesen dieses Buches sehen: Die Tools und Techniken können Sie dabei unterstützen, Projekte besser durchzuführen. Was diese Tools und Techniken aber nicht können: Die Realität verändern.
	Den Schätzungen in Scrum wird immer wieder die Bürde auferlegt, sie müssten „richtiger“ sein als traditionelle Schätzungen. Tatsächlich steckt dahinter der Wunsch, dass ein Projekt mit agiler Schätzung plötzlich schneller werden müsste. Wie soll das gehen? Sie werden auch mit agilen Methoden nur dann Erfolg haben, wenn Sie sich eines klar machen: Agile Methoden können das Wunschdenken nicht besser oder erfolgreicher bedienen. Agile Planungsmethoden zeigen vielmehr schonungslos die offensichtlichen Tatsachen. Sie werden erfolgreich sein, wenn Sie folgende zwei Punkte akzeptieren: 1. Die Anforderungen an ein Projekt werden auch bei einem agilen Projekt oft erst während der Laufzeit bekannt. Genau darin liegt die Stärke der agilen Methode: damit umgehen zu können. 2. Im Laufe des Projekts wird sich auch das Umfeld verändern – das können wir am Anfang nicht vorhersehen.