Scrum ist nicht agil
Zugegeben, der Titel ist ein wenig provokant. Das soll es aber auch, denn ich möchte damit ein Gefühl zum Ausdruck bringen, das mich schon lange beschleicht. Der Ausschlag gebende Anstoß für diesen Artikel kam, als ich mich selbst in folgender Situation befand: Wir waren mitten im Sprint und der Kunde wünschte dringend die Umsetzung einer bestimmten Funktionalität. Meine fast schon automatische Antwort darauf war:
wir sind mitten im Sprint. Während des Sprints ändert sich der Scope nicht. Gerne nehmen wir die Anforderung auf und priorisieren diese im kommenden Sprint entsprechend.
Ich fühlte mich schlecht dabei, wusste aber in diesem Moment nicht genau warum. Erst später kam ich darauf: ich hatte den Prozess höher gewertet als den Kunden und unsere Interaktion. Ich hatte eine wichtige Anforderung künstlich um 2 Wochen verzögert, nur weil der Prozess es so will. Immerhin sind wir in der Lage, Änderungen innerhalb von 10 Minuten auf Produktion zu deployen. Mir wurde schlagartig klar, dass das nur die Spitze des Eisbergs war. Immer mehr Episoden dieser Art aus vergangenen Projekten schossen mir auf einmal durch den Kopf, so dass mir letztendlich klar wurde, Scrum ist nicht agil.
Selbstverständlich kann ich eine solche Aussage nicht lediglich auf der Basis eines Gefühls oder eines einzelnen Beispieles postulieren. Glücklicherweise können wir bei Pulsar Solutions auf eine recht umfangreiche Projekt-Historie zurückgreifen. Hier finden sich hauptsächlich Projekte, die nach Scrum entwickelt worden sind. Mit anderen Worten, die hier vorgestellten Erkenntnissen basieren auf empirische Daten, gesammelt aus den Erfahrungen von ca. 10 Jahren Projektgeschäft.
Bevor ich erkläre, warum Scrum nicht agil ist, sollten wir definieren, was agil ist. Aus unserer Sicht ist ein Team (oder eine Organisation) dann agil, wenn es sich an die Werteverteilung hält, die im Agilen Manifest beschrieben worden ist. Hier die Werte des Agilen Manifests:
Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:
- Individuen und Interaktionen mehr als Prozesse und Werkzeuge
- Funktionierende Software mehr als umfassende Dokumentation
- Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
- Reagieren auf Veränderung mehr als das Befolgen eines Plans Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.
Gehen wir die einzelnen Werte der Reihe nach durch und schauen wir, ob diese in der Praxis so gelebt werden oder nicht:
Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Leider ist unsere Erfahrung, dass in der Praxis das Gegenteil der Fall ist. Insbesondere das Thema Prozesse hat einen extrem hohen Wert gegenüber Individuen und Interaktionen. Ohne Rücksicht auf Verluste muss der Prozess eingehalten werden. Dafür ist der Scrum Master schließlich da, um den Prozess einzuhalten... Aber woher kommt diese Verschiebung der Werte? Aus unserer Erfahrung gibt es dafür zwei Gründe. Zum Einen geht es bei Scrum um viel Geld. Es werden Zertifizierungen verkauft. Es werden zertifizierte Mitarbeiter - entschuldigung: Consultants - verkauft. Es werden Tools, Schulungen, usw. verkauft. Dass diese Zertifizierungen meistens das Papier nicht Wert sind, auf das Sie gedruckt sind, weil sie nach einem 2-Tages-Workshop vergeben werden, interessiert offenbar niemand. Der andere Grund, warum der Prozess meistens so vehement umgesetzt wird, hat mit Conway's Gesetzt zu tun. Dieses besagt:
Organisationen, die Systeme entwerfen, […] sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.
Nun sehen sich solche Unternehmen aber in einem Konflikt, weil es zwei Kräfte gibt, die an diesen Strukturen rütteln. Zum Einen wollen die meisten Mitarbeiter von IT Abteilungen nach modernen Methoden arbeiten. Es gibt also Druck von unten. Zum Anderen wird solchen Unternehmen verkauft, dass man mit agilen Methoden viel Geld sparen kann. Wie können diese Unternehmen also die Vorteile nutzen, ohne das Unternehmen selbst in eine agile Organisationsform umzugestalten? Das würde ja den Verlust von Kontrolle und Hierarchien bedeuten. Zum Glück gibt es Scrum! In der Organisation kann alles beim Alten bleiben, an der Grenze zur "agilen" IT steht ja ein Product Owner der als Schnittstelle zwischen Entwicklung und Stakeholder steht und übersetzen muss. Und zum Glück gibt es ein Backlog mit 500 User Stories, die schon vor Projektbeginn in einer Initialbefüllung für eine Aufwandsabschätzung herangezogen wurden. Man möchte ja wissen was der Spaß kosten wird, agil hin oder her. Ich könnte die ironischen Spitzen immer weiter treiben, aber ich glaube die Idee ist klar geworden. Scrum ist mittlerweile nur noch ein Vehikel, um nicht agilen Unternehmen einen Prozess zu verkaufen, der zwar auch nicht wirklich agil ist, aber so klingt und mit dem man Ausgaben rechtfertigen kann.
Funktionierende Software mehr als umfassende Dokumentation
Ursprünglich bezog sich dieser Satz darauf, dass Entwickler zu viel Zeit mit der Erstellung von Dokumentation verbracht haben, anstatt zu entwickeln. Dieser Umstand hat sich heute etwas verändert, aber auch hier hat Scrum dazu geführt, dass sich die Werteverteilung umgekehrt hat. In Scrum-Projekten ist es mittlerweile Usus, dass die ersten Sprints nichts brauchbares Produzieren und dazu dienen, die "Werte" einzupendeln. Mit Werte sind hier Metriken gemeint, die gerne in KPI Dashboards Management-gerecht auf Knopfdruck generiert werden können. Velocity, Burn Down Chart, Defect Fix Rate und etliche mehr. Weiter wird meistens ein Wiki aufgesetzt, wo sich Definition of Done befinden, Richtlinien für die Nutzung der Sourcecode-Verwaltung, Leitfaden für effektive Stand-up Meetings, Ablaufplan des Sprint Reviews, der Grooming Session, der Retrospektive, des Sprint-Pre-Plannings usw. Weiter werden die Ergebnisse, Protokolle und Notizen dieser Meetings fest gehalten. Das ist alles Dokumentation. Und in all der Zeit, die damit verbracht wird, wird keine einzige Zeile Code geschrieben und an den Kunden ausgeliefert.
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Sprints bzw. die für einen Sprint zugesicherten Story Points, die Velocity, das (hoffentlich) als Business-Value formulierte Sprint-Ziel sowie die Capacity der Teammitglieder während eines Sprints. Das sind alles Verträge. Nicht im klassischem Sinne, aber dennoch Verträge. Je größer die Organisation um so mehr wird auf diese Indikatoren geachtet, mit dem Resultat, dass wir an Agilität verlieren. Die folgende Situation dürfte jedem bekannt vorkommen, der schon mal in einem Scrum Team gearbeitet hat. Mittem im Sprint taucht ein Problem auf, der eigentlich erfordern würde, dass die Arbeit sofort gestoppt wird und erstmal mit dem Kunden Rücksprache gehalten wird. Selbst wenn der Impuls da ist, sitzen einem dann automatisch die Scrum-Teufelchen auf der Schulter, die sagen: "wenn du jetzt nicht weitermachst wird die Velocity sinken" oder "mach einfach weiter, sonst schaffst du nicht die von dir zugesicherten Story Points". Das Problem wird also erstmal ignoriert, kommt aber erfahrungsgemäss trotzdem raus. Dann gibt es Diskussionen mit dem Kunden darüber, ob die Story angenommen werden kann oder nicht, wie viel zusätzlicher Aufwand das beim nächsten Sprint generiert, usw. Also Vertragsverhandlungen anstelle von Zusammenarbeit mit dem Kunden.
Reagieren auf Veränderung mehr als das Befolgen eines Plans
In Scrum muss der Plan befolgt werden. Wenn die Arbeit für die nächsten 2, 3 oder 4 Wochen fest steht, werden Veränderungen entweder ausgeblendet oder auf den nächsten Sprint geschoben. Auch hier gilt, nur die Definition dessen was ein Plan ist, hat sich verändert seitdem das Manifest geschrieben wurde. Die Werte aber sind geblieben. Ein Sprint ist ein Plan. Zwar nicht für 3 Jahre, sondern nur für 3 Wochen, aber trotzdem ein Plan. Stellen wir diesen Plan über die Fähigkeit, auf Änderungen zu reagieren, sind wir nicht agil.
Und was nun?
Die Frage ist an dieser Stelle natürlich mehr als berechtigt. Was sollen wir statt dessen tun? Die Antwort darauf ist ein klares "kommt darauf an". Jede Organisation und jedes Team ist anders. Für manche Organisationen ist Scrum mit all den Problemen, auf die ich hier aufmerksam gemacht habe, trotzdem besser als das was davor praktiziert wurde. Andere wiederum würden extrem davon profitieren, sich von Scrum zu lösen. Auf verschiedene Fälle, die wir beobachtet haben, werden wir in kommenden Artikel detaillierter eingehen. Grundsätzlich ist es aber sicher nicht verkehrt, bei der täglichen Arbeit im Rahmen von Scrum (oder anderen agilen Methoden) sich einfach die Werte des Agilen Manifests bewusst zu sein und ggf. Dinge zu hinterfragen, wenn die Vermutung nahe liegt, dass eine Werteumkehrung statt findet.
