Scrum ist nicht zielführend

Das Scrum-Problem verbildlicht.
Robyn Mackenzie | shutterstock.com



Eine Führungskraft im Software-Business zu finden, die keinen gesteigerten Wert darauf legt, „agil“ zu sein, dürfte schwierig werden. Dabei wage ich zu behaupten, dass nur ein verschwindend geringer Prozentsatz dieser Manager das Agile Manifesto überhaupt einmal zu Gesicht bekommen hat. Geschweige denn darüber nachgedacht hat, was Agile wirklich bedeutet und wie es in der Praxis angewendet werden kann.



Nicht wenige Unternehmen, die irgendwann feststellen, dass sie agil arbeiten wollen, gehen davon aus, dass das mit einem Berater und der anschließenden Scrum-Implementierung getan ist. Auf der Gewinnerseite stehen dabei regelmäßig eher die Consultants, die hier ein gutes Geschäft wittern.



Warum sich das alles so verhält, ist mir ehrlich gesagt ein Rätsel. Ich kann absolut nicht nachvollziehen, inwiefern sich in Scrum die agilen Prinzipien manifestieren. Aus meiner Sicht steht Scrum vielmehr in direktem Widerspruch zu diesen und erfüllt nicht annähernd den angestrebten Zweck.



Der Sprint, der niemals endet



Die Problemstellung bei Scrum: Ein riesiger, rechteckiger Block (an Aufwand) soll in eine fest definierte Aussparung gepresst werden, die nicht verändert werden darf. Deswegen wird der Block in viele kleine Blöcke aufgeteilt, die so zurechtgeschnitzt werden müssen, dass sie passen. Auch wenn das Ergebnis am Ende nicht wirklich das ist, was man will oder braucht. Wie durch dieses Konzept „Individuen und Interaktionen Vorrang vor Prozessen und Tools“ erhalten sollen, erschließt sich mir nicht.



Davon abgesehen, passen die kleinen Blöcke trotzdem nur selten richtig in die Aussparung: Wenn der Sprint sich seinem Ende nähert,




ist die Arbeit entweder schon erledigt, oder



wird auf keinen Fall mehr rechtzeitig fertig.




Und ganz ehrlich: Bitte melden Sie sich bei mir, wenn Sie Lust darauf haben, kontinuierlich Deadlines im Nacken zu haben. Ständiger Druck, etwas „fertigstellen“ zu müssen, führt im Regelfall lediglich zu oberflächlichen, überstürzten Lösungen. Unter anderem.



Sowohl Anforderungen als auch Einschränkungen verändern sich wegen „unknown Unknowns“ im Bereich der Softwareentwicklung ständig. Entsprechend braucht es oft Zeit, die Dinge richtig und sorgfältig zu erledigen. Der Scrum-Prozess sieht Kursänderungen allerdings erst nach Ende des Sprints vor. Wie passt das zu „auf den Change reagieren, statt einem Plan zu folgen“?



Der Sprint an sich ist ein eng fokussierter Prozess, der dazu führen kann, dass der Blick aufs große Ganze verloren geht. Und Scrum artet nur allzu oft Zeremonien-artig aus. Aber wer hat denn nicht Bock auf das tägliche Stand-Up-Meeting, bei dem jeder erzählt, was er oder sie getan hat und tun wird? Auch Retrospektiven werden regelmäßig erzwungen, selbst wenn kein Feedback vorhanden ist. Unter dem Strich wird vieles bei Scrum einfach nur „pro forma“ gemacht – das exakte Gegenteil von Agilität und Anpassungsfähigkeit. Und dabei haben wir noch gar nicht über endlose Sprint-Planungs- und Backlog-Grooming-Meetings gesprochen.



Letztendlich verkommt Scrum so zu einer Endlosserie kurzer Softwareprojekte, die wie die meisten anderen Projekte dieser Art enden:




Sie dauern länger als erwartet,



erreichen ihre Ziele nicht und



beinhalten viele Meeting-Stunden, die sich die meisten Beteiligten lieber sparen würden.




Der bessere Scrum-Prozess



Hier ein Gegenvorschlag in acht Schritten:




Teilen Sie die Arbeit in „natürliche“ Chunks variabler Größe auf, die zu den Projektanforderungen passen.



Arbeiten Sie diese Chunks in einer sinnvollen Reihenfolge ab und setzen Sie die jeweils benötigte Anzahl von Entwicklern darauf an.  



Seien Sie sich bewusst, dass die Zeit für die jeweiligen Abschnitte von der zu Beginn eingeplanten Dauer abweichen wird. Tracken Sie dabei jeden Abschnitt separat und erzwingen Sie nicht, diese zu festen, unflexiblen Zeitpunkten abschließen zu müssen.



Wenn Sie merken, dass bestimmte Tasks aufgrund veränderter Umstände keinen Sinn mehr ergeben, leiten Sie sofort eine Kursänderung ein.



Das Review erfolgt, wenn die Zeit dafür reif ist – nicht, wenn der Kalender es vorschreibt.



Wenn Chunks wegfallen, hinzukommen oder sich verändern müssen, ist das zu akzeptieren.



Wiederholen Sie das, bis alle benötigten Chunks fertig sind, dann liefern Sie die Software aus.



Eventuell macht es auch Sinn, jeden Chunk direkt nach Fertigstellung auszuliefern.




(fm)



Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!