Dieser Artikel beschäftigt sich mit einer Realität, die leider sehr oft nicht fair ist. Es geht um die Frage, wie Organisationen einen Scrum Prozess organisieren können, ohne dabei die meiste Zeit im Dunkeln zu tappen und sich sogenannten oder selbsternannten Scrum Experten, mit ihrem Mantra von „nichts genaues weiß man nicht“ hilflos auszuliefern.
Das Spiel beginnt in der Regel schon vor dem eigentlichen Projekt in einem Scrum Prozess Schritt, nennen wir ihn mal Demand-Management.
Ein Change-Advisory Board sitzt über einer Vielzahl von Projektanträgen, in der Regel nur high-level beschrieben, meist auch priorisiert, aber dann wieder nur sehr selten geschätzt, wie auch?
Und natürlich herrscht Zeitdruck.
Wenn Ihnen das irgendwie bekannt vorkommt, dann lesen Sie weiter. Falls Sie das noch nie erlebt haben, lesen Sie lieber etwas anderes, schönes.
Das Mantra vieler Scrum Master „Wir machen Scrum, wir geben kein Estimate“, bringt Scrum den Vorwurf ein, als Methode dem Kommunismus näher zu stehen als der Realität.
Scrum versteht sich nicht unbedingt als Projektmanagement Methode, eher schon als eine Implementierungsmethode (wie damals Wasserfall auch), dennoch bzw. eingebettet in ein Projekt steht sie doch in einer direkten Beziehung zum Projekt und allen seinen Belangen.
Viele Scrum Experten haben es sich in der Methode gemütlich eingerichtet, ihre Weisheiten gefunden und wichtige Fragen – offenbar aber nicht wichtig genug für viele Scrum Experten – einfach ausgeklammert.
Scrum Experte ist, wer z.B. bei Scrum.org in einer Stunde achtzig Fragen überwiegend richtig beantwortet hat. Dann weiß man, woraus ein Scrum Team besteht, wieviel Minuten ein Daily dauern darf, was eine Timebox ist, dass das Team über allem steht und das Scrum Wert auf Transparenz legt.
Außer natürlich bei der Frage, was das Projekt denn kosten wird und wann es fertig ist.
Hier wird dann gleich darauf verwiesen, dass ein Backlog potentiell ewig lebt und ständig fortgeschrieben wird und am Anfang eine Handvoll Storys genügen, um mit der Entwicklung zu starten, was oft genug auch der Realität entspricht und auch in meinen Augen absolut richtig und sinnvoll ist.
Wozu dann also dieser Artikel?
Weil damit Scrum als Methodik zwar ziemlich vollständig beschrieben ist, aber es dennoch nicht die ganze Wahrheit ist.
Denn die Wahrheit – philosophisch betrachtet – kennt auch noch einen Bezug zur Realität. Und die sieht oft so aus:
Das Scrum Prozess Ping-Pong Spiel
Die Organisation möchte sich nun gerne für Scrum als Methodik entscheiden, in vielen Fällen bleibt ihr auch gar nichts anderes übrig, denn für einen klassischen Wasserfall fehlt aus Zeit- und/oder Komplexitätsgründen die Detailspezifikation.
Sie wird sich jetzt die Frage stellen, wie das Scrum-Projekt budgetiert und kontrolliert werden soll, bevor über den Projektantrag überhaupt entschieden werden kann. Genau an dieser Stelle beginnt oft ein amüsantes oder frustrierendes (je nach Perspektive) Ping-Pong Spiel.
Die IT soll das Projekt schätzen, kann es aber nicht, weil die Requirements nicht gut oder nicht vollständig (meist beides) beschrieben sind. Sie gibt es zurück zum Fachbereich.
Die können es nicht besser beschreiben, weil ihnen dazu IT-know-how fehlt, immerhin soll ja ein Produkt und nicht ein Geschäftsprozess beschrieben werden.
Das Spiel geht eine Weile hin- und her bis die Akteure daran die Lust verlieren. Unentschieden. Was tun?
Natürlich haben beide recht. Die IT hat keine Glaskugel und wird jetzt sogar noch durch den Scrum – Prozess geschützt, bzw. durch die Scrum-Experten und ihrem Mantra.
Der erste Fehler, der hier sehr oft gemacht wird, ist dass die Tatsache, dass zu Beginn nicht präzise geschätzt werden kann, generalisiert wird.
Denn dass ich zu Beginn eines Projektes nicht den Aufwand und die Dauer genau schätzen kann, bedeutet nicht notwendig, dass dies auch lange so bleiben muss.
Der Zweite Fehler liegt in einer Miss-Interpretation bzw. einer Überbetonung von Scrum als Wertschöpfungs-Instrument.
Natürlich ist Scrum eine Methodik, die den Prozess der Wertschöpfung im Blick hat. Manchmal etwas zu wenig, wenn es zu sehr die DevOps Kultur und die Selbstorganisaiton von Teams betont und zu wenig daran denkt, dass das Team kein Selbstzweck ist, sondern ein Produkt erschaffen soll. Und dann auch wieder zu viel, wenn es laut herausschreit „Business-value first“ und einen anderen Aspekt dabei fast unter den Tisch fallen lässt.
Scrum ist zunächst einmal eine Risikomanagement Methode
Oh ja, Sie haben richtig gelesen. Softwareentwicklung ist eine komplexe und komplizierte Angelegenheit. Umso mehr, wenn man versucht, atemberaubende Software höchster Komplexität ohne eine genaue Spezifikation zu entwickeln.
Teams, die das tun leisten unglaubliches. Es gleicht einem Drahtseilakt ohne Netz und doppelten Boden, ein enormes Risiko also. Scrum versucht, dieses Risiko, mit allem was es hat in den Griff zu bekommen. Und dazu – und das wird leider sehr oft übersehen – gehört auch der Entwicklungsrhytmus.
Scrum führt eine vertikale, feature-orientierte Entwicklung ein. Anders als Wasserfall, in dem eher horizontal, layer orientiert entwickelt wird.
Betrachten wir das Verhältnis beider Methoden mal aus einer anderen Perspektive, der Wertschöpfungsperspektive.
Wasserfall, bestehend aus den Phasen Spezifikation, Implementierung, Verifizierung (Test) und Dokumentation, betreibt Wertschöpfung nur in der Phase Implementierung. Natürlich ist die Spezifikaiton eine Voraussetzung für die Wertschöpfung und die Verifizierung und Dokumentation setzen die Nachhaltigkeit der Wertschöpfung, aber die Wertschöpfung selbst findet nur während der Implementierung statt.
In Scrum ist dies ganz anders. Wir versuchen hier den Wertschöpfungszeitraum auf ein Maximum auszudehnen. Extrem früh anfangen (Sprint 1) und – durch den Einsatz von Testautomatisierung, Continuous Integration bis hin zu Release-on-Demand – erst ganz kurz vor dem Release mit der Feature-Entwicklung stoppen. Auch das ist ganz klar Bestandteil einer Risikomanagement Strategie.
Permanente Wertschöpfung betreiben, also ständig zählbares auf die Habenseite schaffen, minimiert das Risiko.
Dennoch, einer der schweren Fehler, die leider gemacht werden, ist der, dass dann oft doch wieder (wasserfallartig) chronologisch entwickelt wird. Also zuerst die Startseite mit Login und dann langsam weiter.
Wie ein Artist, der über das Drahtseil geht und erst nach einem Drittel des Weges realisiert, dass das Seil am anderen Ende gar nicht richtig festgebunden ist, gelangen auf diesem Wege viele Teams viel zu spät an die architektonischen Herausforderungen. Gefahrlose Rückkehr unmöglich.
Was Scrum – verstanden als Risikomanagement Methode – eher entsprechen würde ist nicht der Satz „Business Value first“, sondern „Risk first“.
Scrum Prozess: Risk first
Zuerst versuchen wir in kurzen Sprints mit einigen Proof-of-Concepts, Prototypen oder was auch immer, die Risiken zu identifizieren und auszuräumen. Auch das ist schon Wertschöpfung, folgt aber anderen Prinzipien.
Und diese Erkenntnis lassen wir jetzt auch in das Projektmanagement einfließen, sodass wir mit wenigen Handgriffen ein gutes Projekt-Controlling hinbekommen. Und so geht’s:
Zunächst wird der Projektantrag im Demand-Funnel sehr grob geschätzt
Dabei empfehlen sich zunächst T-Shirt Sizes, die einer bestimmten Range entsprechen (z.B. S <= 50 Tage, M bis 200 Tage, was auch immer). Natürlich können auch Story-Points und Fibonacci dafür verwendet werden, falls das Ihrem CAB etwas sagt. Diese grobe Schätzung dient zunächst nur, um ein initiales Budget zu bestimmen. Die Eintrittswahrscheinlichkeit sollte bei 50% liegen, also alles andere als genau.
Dann definieren wir eine erste Phase bis zum Point-of-no-Return
Das ist der Punkt, bis zu dem Sie noch relativ gefahrlos ein Projekt komplett absagen oder neu aufsetzen können, ohne dass das Kind schon in den Brunnen gefallen ist, also zu viel Geld verbrannt ist.
Meiner Einschätzung nach sollte dieser Punkt nur maximal 10% der initial geplanten Projektlaufzeit ausmachen. In dieser Phase arbeiten Sie nach der „Risk first“ Methode, Sie tun also alles, um Ihre Risiken zu bewerten und auszuräumen. Denn nach dieser Phase sollten Sie über das Projekt ca. 80% Sicherheit erlangen. In dieser Phase geht es nicht darum, irgendwelchen Business Value zu generieren, sondern nur darum Gewissheit über die Machbarkeit des Projektes zu erlangen.
In der nun folgenden dritten Phase erschaffen Sie das sogenannte MVP (minimum viable product)
Also den Kernprozess der Anwendung. Je kleiner Sie diesen definieren können, desto besser. In dieser Phase wird nur Business Value geschaffen. Code-Optimierungen, nachhaltige Qualität, pixelgenaue UI, fancy features – alles Nebensache. Nach dieser Phase sollen Sie einen Markt besetzten, bevor es jemand anderes tut. Ob Sie mit diesem Produkt schon Preise gewinnen ist genauso wenig wahrscheinlich wie erstrebenswert. Sie sind da, das genügt. In dieser Phase sollten Sie möglichst früh die 80% Sicherheit auf 95% erhöhen. Da Ihr Backlog in der Tat nie zu Ende sein wird, werden Sie auch nie dichter an die 100% kommen. Aber mit dieser Unschärfe lässt es sich meist komfortabel leben.
In der vierten Phase, also nach dem MVP lassen Sie dann das Produkt reifen
Sie werden aus dem MVP reichlich Feedback erhalten haben, sodass Sie jetzt auch bei der Reife kein Geld sinnlos verbrennen, sondern genau das optimieren was Ihre Kunden wirklich brauchen.
Dieser Rhythmus gibt Organisationen früh Sicherheit, auch wenn ganz am Anfang natürlich eine ziemlich große Unsicherheit herrscht.
Diese lässt sich nicht vermeiden, aber sie sollte sich rasch auflösen.
Wenn sich Risiken durch diese Methode schnell beherrschen lassen, sind Organisationen auch eher bereit, sie am Anfang einzugehen.
