Scrum ist nicht neu. Die Ursprünge von Scrum reichen weit in die 80er Jahre hinein, als Toyota mit seinem „Toyota Production System“ neue Wege ging und das später so genannte „Lean-Manufacturing“ begründete. Viele agile Strömungen und Methoden sind seit dem entwickelt worden, wobei Scrum, welches eigentlich auch nur eine Zusammenfassung von „Best practices“ darstellt, aktuell die bei weitem am meisten verwendete ist.
Alle agilen Methoden basieren auf denselben Werten und bedeuten im allgemeinen tiefgreifende Änderung der Unternehmenskultur, was bei der Einführung auch eigentlich die Schwierigkeit darstellt.
Der „PDCA-Kreislauf“, worüber wir schon gesprochen haben, basiert letztlich auf einer bereits 1620 von Francis Bacon beschriebenen wissenschaftlichen Methode, die man als „Hypothese, Experiment, Evaluation“ zusammenfassen kann (Francis Bacon: Novum Organum).
Man kann also wirklich nicht behaupten, dass Scrum nur „neumodisches Zeug“ ist…
Nun reden alle über Scrum, aber warum wollen es viele machen (oder meinen es machen zu müssen)? Also starten wir mit einem Vergleich: 5 Gründe, warum Scrum besser als Wasserfall ist:
Grund Nummer 1: Der Realität ins Auge sehen
Projekte starten im Allgemeinen in einem Flow des Optimismus. Wir glauben, dass alles funktionieren wird – wenn wir einmal alle Anforderungen aufgenommen und spezifiziert haben – und das auch im Vertrag geregelt ist, dann wird schon alles funktionieren…
Die Realität sieht leider meistens anders aus. Wenn das Projekt fortschreitet, stellen wir gewöhnlich fest, dass Anforderungen missverstanden werden oder Lösungen komplexer sind, als zunächst angenommen. Das Festpreisangebot für den festgeschriebenen Scope ist daher nicht mehr erreichbar, ohne Kompromisse bei der Qualität zu machen…was natürlich niemand will…
Die Praxis in hunderten von Projekten hat gezeigt und ich kann das bei meine Projekten, die ich als Projektmanager gemacht habe, bestätigen: Es ist naiv zu glauben, dass das, was der Kunde am Anfang an Anforderungen und Vorstellungen in seinem Kopf hat, auch genauso vom Dienstleister oder Entwickler verstanden wird.…daher kommt es bei der Präsentation der Ergebnisse nach einem langen Zeitraum (also klassisch nach der Konzept- und Realisierungsphase) oft zu unangenehmen Überraschungen…Und es kommt noch schlimmer: selbst wenn die Kommunikation im Projekt außergewöhnlich gut läuft und alles genau so realisiert wird, wie der Kunde es verstanden hat, kann man nicht davon ausgehen, dass der Kunde am Anfang des Produkts überhaupt in der Lage war zu beschreiben, was er am Ende des Projekt wirklich braucht. Das liegt nicht an der Dummheit des Kunden, sondern an der Tatsache, dass wir auf dem Weg lernen und Erfahrungen machen, die wir nunmal am Anfang nicht haben. Das hat sich ja auch in einem Sprichwort manifestiert, dass wir alle kennen: “Hinterher ist man immer klüger”…nur warum glauben wir das im Projektmanagement nicht?
Die Tatsache ist, dass Änderungen unvermeidlich sind. Fataler Weise gehen klassische Projektmanagement-Methoden davon aus, dass wir alle Eventualitäten im Voraus festlegen können (wenn wir nur intensiv genug darüber nachdenken) und dass wir Verständnis und Kundenbedürfnisse mit Dokumenten kommunizieren können und dass wir das auch noch mit einem Abnahmeprozess festschreiben und fest kalkulieren können. Da das eigentlich noch nie wirklich funktioniert hat, müssen wir anerkennen, dass wir hier anders vorgehen müssen.
Grund Nummer 2: schneller sein…
Probleme bauen sich typischerweise in einem traditionellen Projekt über die Laufzeit auf und treten dann in der Testphase zu Tage. Die Testphase startet sehr spät, wenn alle Teilentwicklungen integriert sind. Der Nutzen kann also erst am Ende des Projekts generiert werden.
Scrum-Teams sammeln die Anforderungen nur so lange, bis verwertbare Bestandteile entwickelt werden können und setzen sie dann um. Dabei sollen die wichtigsten, fundamentalsten aber auch einfachsten Anforderungen zuerst umgesetzt werden. Ein Nutzen wird dann bereits mit dem ersten Sprint erreicht.
Die „Time to Market“ wird radikal gesenkt und es können sofort erste Kundenfeedbacks eingeholt werden. Die weiteren Entwicklungen können auf das Feedback reagieren, so dass der Kunde genau die Funktionen oder Features bekommt, die er wirklich benötigt.
Grund Nummer 3: Qualität bereits eingebaut:
Das klingt etwas provozierend, doch es ist ja so: Wenn Entwicklungs- und Testphasen zeitlich sehr weit auseinander liegen, dann dauert der Fehlerfindungsprozess auch sehr viel länger. Wenn die Tests in einem 2 Wochensprint integriert sind, bist Du als Entwickler gedanklich ja noch voll im Thema und findest den Fehler auch viel schneller.
Aber Scrum-Teams gehen natürlich noch viel weiter: Automatische Regressionstests stellen sicher, dass die Weiterentwicklung auf Basis des bestehenden Codes funktioniert. Falls Du Product-Owner bist, solltest du aber auch darauf achten, dass genügend Zeit für die Erstellung solcher Testfälle besteht und das auch geplant wird (also auch Userstories dafür geschrieben werden). Schaffe also Dir selbst den Freiraum, die Säge zu schärfen, damit du den Baum schneller fällen kannst…
Scrum-Teams lassen nichts ungetestet. Der Code ist immer zu 100% getestet. Im Zweifel werden eher Funktionen weggelassen als Funktionen ungetestet auszuliefern. Daher gibt es am Ende keine „technologischen Schulden“, da der Fokus auf Qualität liegt.
Grund Nummer 4: Wir können jederzeit aufhören!
Im klassischen Umfeld quasi undenkbar, in Scrum sollte es jedoch Alltag sein: da wir kontinuierlich Nutzen liefern, steht uns jederzeit die Entscheidung offen, das Projekt zu beenden – nämlich dann, wenn der Nutzen für den Kunden erreicht worden ist…Was bedeutet das? Die Anwendung des Pareto-Prinzips: Du kennst das wahrscheinlich aus Deiner eigenen Erfahrung auch: um 80% des Nutzens zu errreichen brauchst Du eigentlich nur 20% des Aufwandes reinzustecken. Der Teufel liegt im Detail, die nächsten 20% bis zur 100% Umsetzung verschlingen dann 80% des Aufwandes. Nun muss man das nicht wörtlich nehmen, doch Du solltest immer bedenken: Brauchen wir das Feature wirklich im neuen Release oder kann das auch noch später kommen – vielleicht stellt sich heraus, dass wir es gar nicht mehr benötigen.
Immerhin – nach einer Studie der Standish Group enthält Software wie Excel zu 64% Funktionen, die von den meisten Menschen selten oder gar nicht benötigt werden. Und etwas zu entwickeln, was hinterher niemand braucht, ist Verschwendung – und die wollen wir vermeiden!
Grund Nummer 5: Bessere Planung
Es gibt eine Menge Fehlinformationen zu agilen Projekten. Wenn man das erste Mal davon hört, könnte man leicht denken, dass agil gleich planlos ist.
Doch genau das Gegenteil ist der Fall:
Die traditionelle Projektplanung an Hand von Gantt-Diagrammen und Statusreports reflektiert nicht den wirklichen Nutzen des Projekts, sondern macht nur den Fortschritt gegenüber dem Plan deutlich. So bleibt es sehr lange völlig intransparent, ob ein geplanter Nutzen auch wirklich erreicht wird. Im schlimmsten Falle wird ein Projekt komplett „grün“– also in Time, in der gewünschten Qualität und im Budget umgesetzt um dann zu merken, dass das, was da umgesetzt worden ist, gar nicht das ist, was wirklich gebraucht wird.
Um es mal zu verdeutlichen: im klassischen Projektmanagement gibt es zu Beginn des Projekts eine Planungsphase und dann wird dazu übergegangen, diesen Plan zu verfolgen. Erst wenn es erkennbare und nicht mehr zu leugnende Abweichungen vom Plan gibt, wird der Plan angepasst. Die Plananpassung gilt hierbei als etwas schlechtes.
Im agilen Projektmanagement gibt es hingegen 5 Planungshorizonte, die eine große Transparenz und Flexibilität erzeugen – diese Horizonte reichen von täglich bis zu mehreren Monaten oder Jahren:
- Daily-Standup
- Sprintplanung
- Product Backlog
- Releaseplan
- Vision
Also hier nochmal die Planungshorizonte…
- täglicher Horizont: Im Daily-Standup oder DailyScrum wird jede einzelne Aktivität täglich vom Team geplant und aktualisiert. So ist im gesamten Team Transparenz über den Stand der Arbeit gewährleistet.
- wöchentlicher Horizont 1 – Sprintplanungsmeeting: In der Sprintplanung planen Product Owner und Dev.-Team die Arbeitspakete für die kommende Iteration. Die Betroffenen planen also selbst, so kann man immer besser lernen und Planabweichungen werden mit der Zeit immer selterner.
- wöchentlicher Horizont 2 – Backlog Refinement: Die weitere Gestaltung des aktuellen Produkts planst Du als Product Owner im Refinement Meeting zusammen mit dem Team, so dass auch später kommende Aufgaben schon mit vorbereitet werden können.
- Horizont über mehrere Monate – Releaseplan: Die weitere Releaseplanung wird vom Product-Owner zusammen mit Stakeholdern, Produktmanagern über die nächsten Monate vorgenommen.
- Horizont über mehrere Monate oder auch Jahre – Vision: In der Vision kannst Du das endgültige Potenzial des Produkts planen. Der zeitliche Horizont kann hier über die nächsten Jahre gehen. Wichtig ist, dass ein gemeinsames Bild entsteht, was man zukünftig erreichen will.
Fazit: Scrum oder nicht Scrum?
Die Frage, ob Du nun Scrum anwenden sollst oder lieber nicht, solltest Du nicht einfach nur aus dem Bauch oder nur entsprechend aktueller „Modeerscheinungen“ beantworten. Bei bestimmten Aufgabenstellungen hat die klassische Projektmethode „Wasserfall“ durchaus ihre Vorteile und Existenzberechtigung. Um eine Einschätzung auf die eigene Situation zu vereinfachen, kannst Du dir einen „Schieberegler“ vorstellen, der dort hingeschoben werden kann, wo er in der aktuellen Situation in deiner Firma oder im Projekt am besten die reale Welt beschreibt. Die beiden Enden des Schiebereglers sind natürlich immer die Maximalwerte – in der Realität wird alles irgendwo dazwischen liegen.
Stell Dir also einen Equalizer vor, der 5 Schieberegler zu folgenden Themen hat:
• Schieberegler Kultur: Ist es zum Beispiel bei Euch üblich in partnerschaftlichem Verhältnis zusammen mit Kunden oder Auftraggebern Anforderungen umzusetzen, regelmäßig Feedback zu geben und sich gegenseitig zu engagieren ODER herrscht ein Arbeitsklima der Abgrenzung, der Skepsis gegenüber der Leistungsfähigkeit des Partners und der Kontrolle bzw. Beschuldigung?
• Schieberegler Time-To-Market: Sind die Aufgabenstellungen durch schnelle technische Weiterentwicklungen im Markt ständigen Schwankungen ausgesetzt ODER haben wir es mit (z.B. gesetzlichen) Anforderungen zu tun, die sich überJahrzehnte nicht grundsätzlich ändern werden?
• Schieberegler Organisation: Wie ist Deine Firma organisiert? Wird in traditionellen Hierarchien gearbeitet, in denen Abteilungsleiter ihre Teams nach fachlichen Funktionen gruppieren und eine Zusammenarbeit zwischen verschiedenen Abteilungen eher selten vorkommt ODER wird bereits eine Form von „Soziokratie“ gelebt, in der kleine übergreifende Teams in selbstorganisierten Inseln ihre Aufgaben bearbeiten?
• Schieberegler Technologie: Haben wir es mit technologischen Rahmenbedingen zu tun, die schnelle Änderungen an den Systemen verhindern – wie z.B.monolithische Systeme, in denen Änderungen über bürokratische ChangeRequest-Verfahren langwierig beantragt werden müssen und vielfältigen Sicherungs- und Kontrollmechanismen unterliegen ODER arbeiten wir mit schnellen, kleinen, komponentenbasierten Systemen, die quasi „am offenenHerzen“ – also im laufenden Betrieb geändert werden können?
• Schieberegler Markt: Wie ist die aktuelle Marktsituation in Deiner Firma? Ist es überlebenswichtig schnell neue Produkte am Markt zu platzieren ODER ist die Produktpalette eher auf „commodities“ ausgerichtet, die sich nicht wirklich ändern (wie z.B. In der Versorgungsindustrie)?
Je nachdem, wo bei Dir der Schieberegler steht, wird die Scrum-Einführung schwerer oder leichter fallen. Die Entscheidung sollte sich aber nicht nur stoisch an der gegebenen Situation ausrichten, sondern in die Zukunft gerichtet sein. Grundsätzlich gilt aus meiner eigenen Erfahrung: je unbekannter das Produkt oder zu erreichende Ergebnis, und je unsicherer die Gesamtsituation und je größer der Druck der Konkurrenz am Markt, desto eher eignet sich Scrum zur Umsetzung von Projekten und dementsprechend zur Lösung der dringendsten Probleme in Deinem Unternehmen.
Soviel zu Scrum oder nicht scrum
Ich hoffe, die Folge hat dir gefallen.
Falls Ja – bitte ich Dich mir eine Rezension bei Itunes zu geben.
Mach’s gut
Dein agilophiler Frank