Scrum: Ein Reality Check

Es lässt sich mittlerweile statistisch gut belegen, dass Projekte die agile Methoden einsetzen signifikant erfolgreicher sind als Projekte, die ein klassisches Projektmanagement nutzen ^[1]. Daher verwenden auch wir in vielen Kundenprojekten agile Vorgehensweisen, von denen Scrum eine der populärsten und am weitesten verbreiteten Methoden ist.
Die Realität zeigt jedoch, dass die überwiegende Mehrheit der Projekte von einem durchgängig agilen Vorgehen abweichen.

Grund genug für uns, die Lehrbuchdefinition von Scrum mal genauer unter die Lupe zu nehmen und gegen unsere Projekterfahrung abzugleichen.

Scrum beschreibt die Möglichkeit, niedriger priorisierte Einträge im Product-Backlog auch in einem niedrigeren Detailgrad zu beschreiben. Dadurch muss nicht schon zu Beginn des Projekts eine vollständige Spezifikation des späteren Endprodukts existieren. Die Detailierung erfolgt also erst dann, wenn die Umsetzung näher rückt.
In der Praxis besteht dadurch die Gefahr, dass bestimmte Ansätze und Ideen unter Umständen nicht vollständig zu Ende gedacht werden. In der Folge können sich die Gesamtkosten im weiteren Projektverlauf massiv erhöhen. Zum einen weil sich der Scope, also der Aufwand zur Umsetzung der Anforderungen, erhöht und die ursprüngliche Schätzung zum Gesamtaufwand auf einer anderen Annahme getroffen wurde. Zum anderen, weil bereits implementierte Funktionalitäten wieder umgebaut werden müssen. Anstatt geradeaus auf dem kürzesten Weg zum Ziel zu kommen, dreht man also zahlreiche Extrarunden. Das kann zu weiteren, ungeplanten Mehraufwänden führen.

Laut Scrum ist exakt eine Person für die klare Spezifikation und Priorisierung der Backlog-Einträge zuständig. Dadurch soll verhindert werden, dass nicht ein ganzes Komitee am Backlog arbeitet und ggf. gegensätzliche Anforderungen eingesteuert werden.
Jedoch unterschätzen Kunden häufig den Aufwand, den eine Product Owner Rolle mit sich bringt. Im Ergebnis hat man dann unter Umständen Anforderungen, die von den Entwicklern kaum oder falsch verstanden werden. Oder sie haben eine so geringe Qualität, dass sie durch das Entwicklungsteam zurückgewiesen werden müssen. Gerade letzteres birgt ein gewisses Konfliktpotential, da der Product Owner in der Regel auch gleichzeitig unser Kunde ist.

Wenn man Scrum hört, denkt man automatisch an User Storys und Story Points. In der Praxis haben sich diese beiden Techniken als ein De-Facto-Standard im Scrum Umfeld etabliert. Allerdings schreibt Scrum gar nicht vor, welche Art der Spezifikation oder welches Schätzverfahren man nutzen sollte.
User Storys und die damit verbundenen Akzeptanzkriterien sind eine hervorragende Art der Spezifikation, wenn man ein gut greifbares Softwareprodukt (z.B. mit einer Nutzeroberfläche) hat. Allerdings gibt es auch Projekte, in denen man überwiegend Algorithmen implementieren muss. Hier ist man unter Umständen auf umfangreiche Dokumente angewiesen, die exakt beschreiben, was wie implementiert werden muss. In diesem Umfeld kommen User Storys als einzige Spezifikationsform an ihre Grenzen.

Auch tun sich manche Entwickler – gerade bei neuartigen Entwicklungsprojekten und zu Beginn der Entwicklung –  schwer die Komplexität^[2] von Anforderungen zu schätzen, da schlichtweg eine geeignete Referenz fehlt. Darüber hinaus landet man in vielen Projekten am Ende des Tages sowieso wieder bei einer Umrechnung in Personentage, da entweder ein Forecast oder eine Abrechnung auf Basis der geschätzten Story Points erstellt werden muss.

Der original Scrum Guide^[3] definiert, dass während des Sprints

• keine Änderungen vorgenommen werden dürfen, die das Sprint‐Ziel gefährden,
• der Qualitätsanspruch nicht geschmälert werden darf, und
• der Anforderungsumfang  zwischen Product Owner und Entwicklungsteam geklärt und
  neu ausgehandelt werden kann, wenn sich neue Erkenntnisse ergeben haben.

Auch in unseren Kundenprojekten sind je nach Kunde und Projektphase mal mehr, mal weniger Anpassungen am Sprintumfang notwendig. Die größte Herausforderung für uns ist, Anforderungen die vom Kunden kommen auch wirklich einmal konsequent abzublocken. Häufig steht der nächste Go-Live auf dem Plan oder das Management hat eine gewisse Erwartungshaltung an das Sprintergebnis. Dort einen gesunden Kompromiss zwischen dem eigenen Qualitätsanspruch und den Erfordernissen beim Kunden zu finden, kann durchaus eine Herausforderung darstellen.

Die Scrum Bibel empfiehlt eine Sprintlänge von höchsten 4 Wochen und sieht für diesen Zeitraum folgende Termine vor^[4] :

• 15 Minuten Daily
• 8 Stunden Sprint Planning
• 4 Stunden Sprint Review
• 3 Stunden Retro
• 10 Prozent der Entwicklerkapazität für Backlog Refinement

Mit einer einfachen Milchmädchen Rechnung (0,25h x 20 Arbeitstage + 8h + 4h + 3h + 20 Arbeitstage*8*10%) kommt man auf bis zu 36 Stunden die ein Entwickler im Monat mit den diversen Scrum-Meetings zubringen kann. Das entspricht bei 20 Arbeitstagen 23 Prozent seiner verfügbaren Arbeitszeit.

Je komplexer das Projektumfeld und je größer das Entwicklungsteam ist, desto weiter nähert man sich erfahrungsgemäß den o.g. Zeiten an, d.h. die Meetings ziehen sich in die Länge.

Fazit unseres Scrum Reality Checks

Die Lehrbuchdefinition von Scrum beschreibt einen Idealzustand. In der Realität ist es jedoch oftmals schwierig, dieses Zielbild im jeweiligen Kundenprojekt 1:1 abzubilden^[5]. Unsere Erfahrung ist, dass es oftmals notwendig ist, sich dann an die Gegebenheiten im Projekt bzw. beim Kunden anzupassen.
Die agile Welt bringt viele Vorteile mit sich und ist für den Projekterfolg oftmals die deutlich bessere Wahl. Dennoch erschlägt ein Wechsel z.B. von einem klassischen Projektmanagement zu einem agilen Vorgehen nicht alle Probleme die auf dem Weg von einer Idee zum Produkt auftreten können. Denn auch dann gilt nach wie vor: „It’s a people‘s business“.

Glossar:
[2] Mit Story Points wird in der Regel die Komplexität einer Anforderung bewertet
[4] Die Zeiten geben jeweils eine Höchstgrenze an
[5] Interessant wäre an der Stelle eine Studie, die untersucht wie viele Projekte Scrum nach Lehrbuch wirklich zu 100% umsetzen (können). Leider habe ich im Rahmen dieses Blogbeitrags keine geeignete Referenz gefunden

Quellen:
[1] Studie zu Verbreitung und Nutzen agiler Methoden
[3] http://www.scrumguides.org/index.html