Komplexe Projekte neigen dazu, am Ende doch irgendwie zum Wasserfall im Kleidchen zu mutieren, weil man bestrebt ist, die vage Vision möglichst schnell in ein umfassendes Konzept umzuwandeln, das in der Folgezeit Schritt für Schritt abgearbeitet wird. Natürlich hat das rein gar nichts mehr mit einem Agilen Vorgehen zu tun. Was ist aber der »richtige« Weg, sich einem größeren Projekt zu nähern?
Natürlich wissen wir, dass jede Planung nur eine Momentaufnahme ist, und dass wir immer bereit sein müssen, im Zweifel alles über den Haufen zu werfen, doch je mehr Zeit und Arbeit man in ein Konzept gesteckt hat, desto mehr wird man dazu neigen, es zu verteidigen. Genau darin liegt das Problem. Grundsätzlich ist nicht viel dagegen einzuwenden, dass man zu Projektbeginn ein umfassendes und detailliertes Konzept erarbeitet, aber wenn man einmal eines hat, dann ist man im allgemeinen auch bestrebt, dies genau so umzusetzen, wie es ist. Das ist eine ganz normale menschliche Eigenschaft, die ich an dieser Stelle auch nicht bewerten will.
Hinzu kommt, dass immer viele Interessen bei der Entwicklung einer Software mitwirken. Wir sind Teil eines Unternehmens, das Gewinn erzielen möchte. Ein Geschäftsführer fragt also (vollkommen nachvollziehbar) nach einem Releasetermin und einem zu erwartendem Leistungsumfang. Wir argumentieren dann mit Scrum und der damit verbundenen Unsicherheit, aber irgendwie ringen wir uns doch ganz gern zu einer Aussage durch, die wir dann auch umsetzen möchten. Das liegt zum Teil daran, dass Agilität nicht immer im ganzen Unternehmen angekommen ist, zum Teil aber auch daran, dass wir immer irgendwie um Sicherheit bemüht sind.
Das sind ganz grundsätzliche Dinge, die wir nur in einem längeren Prozess ändern können. Die Einführung von Scrum über die Grenzen der Entwicklung hinaus geht nicht von heute auf morgen, auch wenn alle Beteiligten guten Willens sind. Die Änderung von über Jahren erlernten Gewohnheiten braucht ebenfalls Zeit. Für uns soll das jetzt aber nicht das Thema sein. Diese Sache sehen wir uns in einem anderen Artikel genauer an. Jetzt möchte ich mich mit Ihnen der Frage widmen, wie ich als Product Owner ein komplexes Projekt an den Start bringe.
Wenn Sie ein Buch zum Thema Scrum aufschlagen, werden Sie dort immer eine Art Anleitung finden, nach der auf die Produktvision ein Grobkonzept folgt, mit dessen Hilfe das Backlog initial befüllt und ein erster Releaseplan erstellt werden kann. Das liest sich recht einfach, ist in der Umsetzung allerdings sehr schwer, weil man sehr schnell zu viel oder zu wenig in die Zukunft blickt.
Beginnen wir also mit unserem Gedankenspiel an dem Punkt, an dem Sie als PO zum ersten Mal mit der Produktidee konfrontiert werden. In diesem Moment gibt es im Prinzip nur eine Frage: sollten wir das überhaupt machen? An dieser Stelle warne ich dringend davor, zu schnell auf den Zug aufzuspringen. Natürlich kenne ich all die wunderbaren Phrasen wie »die Schnellen fressen die Langsamen«, aber viel zu oft entpuppt sich das neue Projekt bei näherer Betrachtung als reines Gift, weil ein überschaubarer Kundennutzen einem gigantischem Entwicklungsaufwand gegenüber steht, oder weil nicht zu erwarten ist, das Kunden für ein Angebot bezahlen werden, das sie an anderer Stelle umsonst bekommen. Die möglichen Gründe sind vielfältig.
Es sind also Marktanalysen, Kundenbefragungen usw. notwendig. Als PO sollten Sie im Idealfall bereits zu diesem Zeitpunkt involviert sein. Auch die Meinung eines erfahrenen Softwareentwicklers oder Architekten sollte schon so früh wie möglich eingeholt werden, um sowohl den möglichen Start des Projekts vorzubereiten (Stichwörter Infrastruktur, Entwicklungsumgebung etc.), als auch um sich schon erste Gedanken um Entwicklungsaufwände machen zu können.
Während dieser frühen Phase neigen Projekte dazu, von Tag zu Tag komplexer zu werden. Am Anfang steht eine erste grobe Idee. Diese wird in einigen Runden (das können Workshops sein, Einzelgespräche oder was auch immer) verfeinert und ausgebaut. Das ist im Moment vollkommen in Ordnung und auch gewollt, achten Sie jedoch darauf, dass Sie den Zeitpunkt nicht verpassen, an dem es mit der Verfeinerung vor Projektbeginn genügt, wir eine Linie ziehen und wieder damit beginnen, das Große Ganze in Teilbereiche zu zerlegen, um unser Backlog initial zu befüllen.
Ich will Ihnen nichts vorlügen: es ist sehr schwer, hier das richtige Maß zu finden. Ich beobachte sehr oft, dass man entweder viel zu spät den Absprung schafft, weil man der Meinung ist, dass man mit so einer wolkigen und wenig konkreten Vorstellung nicht an den Start gehen könne, oder man zu früh in eine Backlogplanung geht, weil man so schrecklich »agil« sei.
Der Punkt ist genau dann erreicht, wenn man ein Minimum Viable Product (MVP) definieren kann. Dafür müssen wir selbstverständlich mit dem Anwender gesprochen haben, um deren Wünsche und Bedürfnisse zu verstehen. Widerstehen Sie der Versuchung, dass Sie diesen Punkt überspringen, weil Sie glauben, die Anforderungen Ihrer Kunden zu kennen. Sie werden sich wundern, was Sie in Gesprächen noch alles lernen können.
In diesen Dialogen werden Sie sehr wahrscheinlich einen ganzen Blumenstrauß an Anforderungen bekommen, was uns direkt zur nächsten Schwierigkeit führt: die wichtigen von den unwichtigen Anforderungen zu trennen. Wir alle wissen, dass oftmals die gehört werden, die am lautesten schreien. Das ist jedoch nicht unbedingt ein Indikator dafür, dass dies auch die wichtigsten Punkte sind. Andere Dinge werden vielleicht immer wieder nur am Rande genannt, aber von so vielen Personen, dass man davon ausgehen kann, dass es sich um einen Schmerzpunkt für viele handelt.
Diese Sache ist Kernaufgabe eines jeden Product Owners. Sie sammeln die Anforderungen bewerten (vielleicht anhand des Kosten-Nutzen-Diagramms) und erstellen so ein Bild vom kleinstmöglichen Produkt, dass für Ihre Kunden einen echten Nutzen erfüllt. Damit befüllen wir das Backlog. Dies kann (und sollte) im Moment noch sehr grob gefasst sein. Keiner der aufgenommen Punkte kann schon einer eigenen Userstory entsprechen. Wir haben die Key Features für unser MVP zusammengetragen und somit eher eine Reihe von Epics definiert.
Allerspätestens jetzt sollte ein Entwickler oder Architekt hinzugezogen werden (am liebsten schon früher). Es kann nur hilfreich sein, wenn bereits vor dem ersten Sprint einige grundlegende Fragen geklärt sind, z.B. der Aufbau der Infrastruktur, das Bereitstellen der Server, Entwicklungsumgebungen und Vieles mehr. Vergessen wir auch nicht, dass wir ggf. noch ein Team zusammenstellen müssen. In Scrum sprechen wir immer vom Dreigestirn Product Owner, Scrum Master und Entwickler, in Wahrheit gehört zum Aufbau eines Projekts jedoch noch mehr. Wie sieht die Schnittstelle zum Marketing aus? Wie wird die Qualitätssicherung realisiert? Gibt es einen Tester innerhalb des Teams oder oder eine Testabteilung, an die Ergebnisse übergeben werden müssen? Gibt es die erforderliche Fachkompetenz innerhalb des Teams, sowohl technisch bei den Entwicklern als auch inhaltlich beim PO, oder muss man Fachleute integrieren? Der Teamaufbau ist hochkomplex und kann sehr viel Zeit in Anspruch nehmen. Nicht selten ist gerade das der Punkt, der den Start eines Projekts über eine sehr lange Zeit verzögert.
Beim Teamaufbau hat es sich bewährt, wenn Scrum Master, Product Owner und Lead Developer bzw. Architekt zuerst ihre Rollen übernehmen und dann gemeinsam den weiteren Ausbau des Teams treiben. Dazu ist selbstverständlich Unterstützung nötig. Gelder müssen ggf. bewilligt und neue Mitarbeiter rekrutiert werden.
Dieser Teamaufbau läuft parallel zur initialen Projektplanung. Als Product Owner priorisieren Sie die Key Features, arbeiten die höchstprioren detailliert aus und erstellen User Stories. Gemeinsam mit dem Architekten können Sie einen ersten (sehr groben) Releaseplan erstellen, der in Zukunft immer wieder überarbeitet werden muss. Ebenfalls gemeinsam mit dem Architekten erstellen Sie eine weitere Gruppe von Anforderungen rein technischer Natur, die Sie ebenfalls ins Backlog übernehmen. Darin finden sich solche Dinge wie Serverkonfigurationen, technologische Evaluierungen usw.. Auch diese Dinge müssen eingeplant und priorisiert werden. Einige müssen erledigt sein, bevor der erste Sprint angegangen wird, andere im ersten Sprint, wieder andere können vielleicht noch ein wenig warten. Diese Priorisierung nehmen Sie also gemeinsam mit Ihrem Entwickler vor.
Nicht zwingend vor dem ersten Sprint, aber in jedem Fall zu Projektbeginn (kann auch im zweiten der dritten Sprint sein – aller Erfahrung nach sind Sie die ersten Wochen mit rein technischen Dingen beschäftigt) sollten wir uns auch um die Definition of Done kümmern. Diese ist eigentlich immer sehr ähnlich: getestet, vom PO abgenommen, gemerged. Hier und da gibt es Erweiterungen, wichtig ist nur, dass alle ein gemeinsames Verständnis entwickeln.
