Scrum oder murcS? Warum agile Projekte scheitern und wie man das verhindern kann

Scrum Projekte liefern meist „sensationelle Ergebnisse“, so das Zitat eines unserer Kunden bei einem Workshop vergangene Woche. Trotzdem werden sie nicht immer als Erfolg gewertet. Viele Projekte fühlen sich anstrengend an. Der Fachbereich muss sich über den gesamten Projektzeitraum viel intensiver mit der entstehenden Software auseinandersetzen, als gewohnt. Die Entwickler fühlen sich von Sprint zu Sprint gehetzt. Die Scrum Master haben das Gefühl, gegen Windmühlen zu kämpfen, wenn sie für das Team Hindernisse aus dem Weg räumen wollen. In unserem „Center of Competence für Projektmanagement“ haben wir daher einen „wilden Erfahrungsaustausch“ von Entwicklern, Scrum Mastern, Product Ownern und agilen Coaches gestartet und sind auf fünf bekannte, praktisch aber oft vernachlässigte Rahmenbedingungen für erfolgreiche agile Projekte gestoßen.

Es hat sich in vielen agilen Projekten nach unserer Erfahrung schon herumgesprochen, dass eine Definition-of-ready als Eintrittsgateway (1) für eine User Story in den Sprint hilfreich ist. Akzeptanzkriterien und Constraints werden in ihrer Qualität definiert. Mit etwas Glück ist auch die Schätzung durch die Entwickler in der Definition-of-ready zwingend vorgegeben. Der Business Value dagegen wird meistens nicht mehr bewertet. Es fällt dem Fachbereich oft sehr schwer, User Stories gegeneinander zu priorisieren. Warum ist der Business Value so wichtig? Das agile Vorgehen soll sicherstellen, dass die wertvollsten Funktionen zuerst gemacht werden. Die oft als „Goldkante“ bezeichneten Ausgestaltungen einzelner Funktionalitäten können dann im Productbacklog einfach gegen die anderen noch übrigen User Stories priorisiert werden.
Hält man sich am Anfang zu lange mit der „Goldkante“ auf, fehlt nachher die Zeit für die wichtigsten Features und es kommt unnötiger Druck in das Projekt.

Das agile Vorgehen ermöglicht es dem Fachbereich, mit jedem neuen Sprint Anpassungen in das Scrum-Team einzusteuern. Während des Sprints ist das Team vor Änderungen zu schützen. Nach unserer Erfahrung nutzen viele Product Owner allerdings die Abstimmungen mit dem Team während des Sprints, um Spezifikationslücken in ihren User Stories zu schließen. Das wird dann zum Problem, wenn das Schließen der Lücke die Größenordnung einer User Story sprengt. Auch hier wird die Bedeutung einer Definition-of-ready deutlich.
Es liegt in der Verantwortung des Scrum Masters, das Team vor dem Einsteuern neuer Anforderungen während des Sprints zu schützen. Und es liegt in der Verantwortung des Teams, Spezifikationslücken im Sinne der vereinbarten Definition-of-Ready in der Sprintplanung beim Product Owner zu adressieren und die User Story abzulehnen.

3.    Der Scrum Master sorgt auch nach Außen für die Prozesseinhaltung

Der Scrum Master hat die Aufgabe, für die Prozesseinhaltung und permanente Verbesserung der Prozessqualität im Team zu sorgen und Hindernisse für das Team aus dem Weg zu räumen. Das ist auch eine nach Außen gerichtete Aufgabe und schließt die Prozesse des Product Owners mit ein. So muss er dafür sorgen, dass sich der Product Owner auf das konzentriert, was das Team entwickeln soll. Wie das Team die Software entwickelt, liegt nicht in seiner Verantwortung. Der Scrum Master muss dafür sorgen, dass der Product Owner seine Kompetenzen nicht überschreitet. Das kann insbesondere dann zu Konflikten führen, wenn der Product Owner im klassischen Projektmanagement sehr erfahren ist und die agile Rolle neu ausführt. Konflikte sind früh zu adressieren und zu lösen. Andernfalls verlängert sich unnötigerweise die „Einschwingzeit“ für das Team, d.h. die Zeit bis zur optimalen Performance.

Der Product Owner braucht ausreichend Zeit für das Projekt und das Team. Er hat eine wesentliche Aufgabe bei der Beschreibung und Priorisierung des Software-Produktes. Und diese Aufgabe ist nicht nach einer festgelegten Konzeptphase beendet, sondern begleitet das ganze Projekt. Stellt der anfordernde Fachbereich den Product Owner, wird ihm neben seiner Tagesarbeit vielfach nicht genug Zeit gegeben, sich mit dem Backlog auseinander zu setzen. Die permanente Anforderung an ihn als Inputgeber wird als anstrengend und Stress empfunden. Ein „Proxy-PO“ aus der IT bzw. vom IT-Dienstleister kann den Product Owner massiv entlasten. Das entlässt ihn aber nicht aus seiner Verantwortung für das Produkt. Es bleibt essentiell, dass der Product Owner auch für den Proxy-PO in ausreichendem Maß zur Verfügung steht.

Aus den Feedbacks zum agilen Vorgehen wird oft die hohe Anzahl der Meetings kritisiert. Daily Standup, Sprintplanung, Retrospektive, Review, Estimation-Meeting. Wo bleibt da die Zeit für die eigentliche Entwicklung? Wenn man die Zeit für Konzeption, Entwicklung und Test aus dem Wasserfall-Modell zusammenmischt und gleichmäßig über den Sprint verteilt, kommt nach unserer Erfahrung etwa der gleiche Aufwand heraus. Einige Dokumente kann man sich im agilen Vorgehen sparen, die Abstimmung von Produkt- und Entwicklungsdetails dagegen nicht. Dazu muss man sich in Meetings austauschen. Oft fehlt im Management das Vertrauen in die Selbstorganisation des Teams. Teambildungsmaßnahmen wie Scrum Cooking sind gerade bei länger laufenden Projekten eine gute Investition und besonders wirksam, wenn das Management mit eingebunden wird.

Wir haben fünf Rahmenbedingungen für ein erfolgreiches agiles Vorgehens identifiziert, die leider zu oft vernachlässigt werden. In unserem „wilden Erfahrungsaustausch“ stellte sich daher die Frage: Wenn Scrum so viele Voraussetzungen benötigt, die in den Unternehmensorganisationen oft noch gar nicht geschaffen sind, warum machen wir das überhaupt?
Gerade wenn die Anforderungen schon genau bekannt und gut dokumentiert sind, wenn die Entwicklungszeit überschaubar ist und das Projektumfeld bekannt, dann bietet sich auch ein klassisches Vorgehen nach Wasserfall-Modell an. Die meisten Softwareprojekte erfüllen diese Voraussetzungen aber nicht. Für komplexe Anforderungen in einem neuen und unbekannten Umfeld mit langer Laufzeit dagegen, ist ein agiles Vorgehen die beste Wahl. Durch die hohe Transparenz und frühzeitige Einbindung der Anwender können einfach „sensationelle Ergebnisse“ erreicht werden.

(1) Schon gewusst? – „Definition of Ready“ und „Definition of Done“ sind Qualitygateways für Sprints
Die „Definition of Ready (DoR)“ ist eine Liste von Kriterien die an User Stories gestellt werden. Es geht dabei um Qualität und Vollständigkeit von User Stories. Die DoR ist die Anforderung des Scrum-Teams an die Qualität und Informationen einer User Story. Der Product Owner sorgt dafür, dass diese Qualität im Product Backlog gewahrt wird. Die Idee ist, dass nur vage beschriebene User Stories nicht in einen Sprint gelangen können sondern nur solche die der DoR entsprechen.
Dagegen beschreibt die „Definition of Done (DoD)“ die Vorgaben des Product Owners an das Produkt. Das Scrum-Team ist für die Einhaltung der DoD bei der Umsetzung jeder User Story verantwortlich.
Im Sinne des Qualitätsmanagements dient die DoR zum Qualitätscheck beim Eingang in einen Sprint. Die DoD dient dem Qualitätscheck am Ausgang des Sprints.