Agilität ist mehr als Scrum

Neben dem Missverständnis, agil und flexibel sei das gleiche, gibt es mit der Gleichsetzung von Scrum und Agilität einen weiteren häufigen Grund, warum „Agilität“ scheitert. Nicht nur, dass sich vortrefflich Scrum komplett an agilen Werte und Prinzipien vorbei praktizieren lässt, auch das durch die Gleichsetzung deutlich werdende Unverständnis von Agilität wird hier deutlich.

Agiles Manifest Sketchnote

Agiles Manifest Sketchnote

Viele setzen agil mit Scrum gleich, vielleicht weil sie von Scrum gehört haben, das agile Manifest aber nicht kennen. Wie oft höre ich von Kritikern, dass „agil“ nicht gehe, weil Scrum sich nicht eigne – basierend auf mehr oder weniger ausgeprägtem Halbwissen und ohne jemals etwas mit Unterstützung ausprobiert zu haben. Etwas erfahrenere Kritiker gehen einen Schritt weiter und ergänzen, dass auch Kanban nicht gehe, aus diesen oder jenen Gründen.

Auch wenn ich glaube, dass Scrum oder Kanban in Gänze oder in Teilen viel häufiger hilfreich sind, als es Kritiker wahr haben wollen, bin ich ebenso überzeugt, dass es sich nicht immer eignet. Das bedeutet nicht, dass eine agile Haltung und agiles Arbeiten nicht möglich sind. Ja, Scrum und Kanban sind in Kreativ- und Wissensberufen – vor allem in der Software Entwicklung – die verbreitetsten Prozessmodelle, die dabei helfen können, auf Basis agiler Werte und Prinzipien zu arbeiten. Trotzdem ist Agilität nicht nur Scrum und Kanban oder Scrumban. Agil ist eine Sammlung von Werten und Prinzipien, eine Haltung.

 

Häufig wird die Einführung von Agilität gleichgesetzt mit der Einführung von Scrum. Natürlich kann die Einführung von Scrum dabei helfen, agile Werte und Prinzipien innerhalb einer Organisation zu etablieren. Oft gilt aber Agilität als abgeschlossen eingeführt, nachdem Scrum versucht wurde auszurollen oder die Einführung schlicht als abgeschlossen definiert wird. Dabei ist gar nicht sicher gestellt, dass Scrum erfolgreich praktiziert wird. Und selbst wenn die Regeln von Scrum eingehalten werden, wäre das kein Beweis oder Garantie für Agilität. Das gleiche gilt auch umgekehrt: Auch wenn Scrum nicht funktioniert heißt das nicht, dass Agilität nicht möglich wäre oder nicht sogar schon gelebt wird.

Ein paar Beispiele, die ich häufig erlebt habe: Scrum Teams, die vortrefflich Scrum gemacht haben, aber kein Verständnis für die Werte und Prinzipien des agilen Manifests hatten.

  • Das Daily ist die tägliche Abstimmungsrunde, eine Mini-Iteration in der sich das Team über den aktuellen Fortschritt der Aufgaben eines Sprints austauschen und den Tag gemeinsam planen. Statt das gemeinsame Vorgehen zu planen, wir dem Scrum Master, dem Product Owner oder dem luftleeren Raum ein Statusreport darüber abgeliefert, was gestern gemacht wurde und warum Dinge nicht fertig wurden. (Das Daily wird aber regelkonform eingehalten.) Es findet keine Interaktion statt, der Prozess wird eingehalten. Im agilem Manifest heißt es aber „Individuen und Interaktionen mehr als Prozesse und Werkzeuge“.
  • Regelmäßig trifft sich das Team zu einem Review-Meeting und die Abnehmer der Arbeitsergebnisse sind vor Ort, um sich das Ergebnis anzusehen. Gezeigt wird, was entwickelt wurde, nicht was fertig ist und funktioniert – am Besten in einer Präsentation um sicher zu sein, dass keine Peinlichkeit durch ein nicht verfügbares System während der Präsentation entsteht. Das Team dokumentiert damit seinen vermeintlichen Fortschritt. Im agilen Manifest heißt es aber „Funktionierende Software mehr als umfassende Dokumentation“. Und in den Prinzipien wird ergänzt: „Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.“
  • Scrum Teams ist natürlich klar, dass eine kontinuierliche Verbesserung wichtig für den Erfolg ist. Also trifft sich das Team zu Retrospektiven und diskutiert über die vergangenen Tage. Es gibt mal hitzigere und mal oberflächlichere Diskussionen und am Ende sind sich alle einig, dass jemand mal etwas machen müsste. In den Prinzipien des agilen Manifests ist auch die Rede von diesen Reflektionsrunden, aber damit ist es nicht getan. Genau genommen ist die Rede von einer Anpassung des Verhaltens. Maßnahmen werden in Retrospektiven aber häufig nicht beschlossen und nachgehalten.: „In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.“

Agiles Arbeiten braucht keine Frameworks. Agiles Arbeiten braucht Menschen, die agil sind, die also auf Basis agiler Werte und Prinzipien (zusammen) arbeiten. Frameworks können dabei helfen, müssen aber nicht.

 

(Das verwendete Bild ist von Broo_am (Andy B) – Vielen Dank!)

One Comment

Leave a Comment

Schreibe deinen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Achtung: Ich erkläre mich damit einverstanden, dass alle eingegebenen Daten und meine IP-Adresse nur zum Zweck der Spamvermeidung durch das Programm Akismet in den USA überprüft und gespeichert werden.
Weitere Informationen zu Akismet und Widerrufsmöglichkeiten.