Blog

Scrum, der richtige Ausgangspunkt für eine agile Transformation?

24 May, 2023
Xebia Background Header Wave

Oft wird in einem Atemzug erwähnt, dass eine Organisation eine agile Transformation durchläuft und dass die Teams Scrum benutzen. Manchmal entsteht das Gefühl, dass Agile und Scrum Synonyme sind oder Scrum der agile Standard und somit der Startpunkt einer agilen Reise sein muss. Ist Scrum aber tatsächlich der richtige Ausgangspunkt für Organisationen, die erst in den Kinderschuhen der agilen Denkweise stehen?

Um diese Frage zu beantworten, ist es wichtig zuerst den Unterschied zwischen klassischem Projekt Management und Agiler Produktentwicklung unter die Lupe zu nehmen. Jeder, der sich mit den Unterschieden zwischen Wasserfall und Agilität auseinandergesetzt hat, hat bestimmt schon einmal untenstehendes «iron triangles» Bild gesehen.

Unterschied zwischen fixen und variablen Aspekten von Wasserfall und agiler Methodik (Quelle: SwissQ)

Auf den ersten Blick wird klar: Bei agilem Arbeiten ist der Wert, der umgesetzt wird, variabel. Was muss sich ändern, damit die ganze Wertschöpfungskette ein variables oder sich änderndes Design umsetzen kann? Was braucht es, damit die Organisation umstellen kann von fixem Scope auf variablen Scope, also von Wasserfall auf agil? Hier fängt die Herausforderung an.

Agilität ist entstanden aus Unzufriedenheit mit den damals üblichen Projektmethoden, unter anderem Wasserfall. Sie waren zu langsam in der Entwicklung und es war aufwendig auf Änderungen zu reagieren. Die Projektmethoden legten viel Fokus auf Details, die sich nicht selten im Nachhinein als unnötig herausstellten. Ebenso stand der Kunde und somit das Produkt nicht ausreichend im Zentrum. Agilität basiert auf iterative und inkrementelle Entwicklung, damit schnell auf Änderungen reagiert werden kann. Dadurch, dass das Wichtigste zuerst umgesetzt und geprüft wird, liegt der Fokus jederzeit auf den Bedürfnissen des Kunden, unnötige Funktionalitäten werden dadurch vermieden.

Agilität ist also keine Methodik, die den Prozess Schritt für Schritt vorgibt. Agiles Arbeiten wird durch Prinzipien definiert, die die erforderlichen Änderung der Denkweise und Kultur fördern, um kundenzentrierte Produktentwicklung zu ermöglichen. Scrum ist ein Framework, durch das Agilität erreicht werden kann. Aber auch wenn Scrum auf den agilen Prinzipien basiert, kann ich in der Praxis oft untenstehende Szenarien beobachten:

Aus Scrum wird Mini-Wasserfall (Quelle: SwissQ)

Das Risiko besteht, dass die Wasserfall-Methode über das Scrum Framework gelegt wird, damit gefühlte Sicherheit in der Planung und Entwicklung entsteht. Die Events und Artefakte sind die von Scrum, aber die Inhalte haben sich nicht verändert. Das Management fühlt sich dadurch sicherer, weil ganz genau bis ins Detail festgelegt werden kann, was wann umgesetzt wird. Die Denkweise ändert sich jedoch nicht in Richtung Agilität und die Arbeitsweise schon gar nicht. Mini-Wasserfall ist entstanden.

Auch wenn das Management dem Team Freiraum gibt mit Scrum anzufangen, ohne die Beruhigungspille Mini-Wasserfall zu verschreiben, besteht das Risiko, dass "einfach eine Methode" eingeführt wird. Alle Events werden zwar durchgeführt, aber oft mit folgendem Ergebnis:

  • die Storys sind schon bis ins Detail spezifiziert und das Entwickler Team setzt einfach um
  • Storys sind schon Monate im Voraus eingeplant und werden ohne die Entwickler (technisch) ausgearbeitet
  • wenn Storys innerhalb des Sprints nicht fertig werden, müssen Überstunden geleistet werden und die Entwickler, die noch offene Storys haben, müssen sich rechtfertigen
  • im Review kommt kein Feedback, wenn überhaupt Stakeholder dabei sind
  • aus der Retrospektive entstehen kaum Verbesserungen, da das Team sowieso nichts ändern kann

Das ist «mechanisches Scrum», ohne echte Anwendung der Werte und Prinzipien, und somit ohne echte Wirkung. Wie bereits erwähnt, ist der Grundgedanke von Agilität eine kundenzentrierte Produktentwicklung mit dem Menschen im Fokus. Ein Prinzip aus dem agilen Manifest behauptet, dass die besten Architekturen, Anforderungen und Designs von selbst-organisierenden Teams kommen. Mechanisches Scrum setzt diesen Grundgedanken nicht um. Die Events werden durchgeführt «weil sich das in Scrum so gehört», das für Agilität klopfende Herz fehlt. 

Die Erfahrungen mit mechanischem Scrum werden vielleicht nicht direkt negativ bei den Mitarbeitern im Scrum Team verinnerlicht, als positiv wird es aber bestimmt auch nicht wahrgenommen. Dadurch werden keine Fans geschaffen, die innerhalb der Firma die positive Botschaft austragen, dass Agilität Mehrwert schafft für den Kunden, die Firma und die Mitarbeiter. 

Sowohl im Mini-Wasserfall als auch im mechanischen Scrum werden Scrum Artefakte und Scrum Events eingeführt. Wieso klappt es dann doch nicht, als Team oder Organisation agiler zu werden? Die Antwort gibt Scrum selbst.

Scrum basiert auf empirischer Arbeitsweise und Vertrauen.
Scrum basiert auf empirischer Arbeitsweise und Vertrauen (Quelle: SwissQ)

Scrum ist aufgebaut auf einem empirischen Vorgehen mit Vertrauen als Fundament, beides sind grundlegende Werte von Agilität. Vertrauen kann entstehen, wenn Scrum Werte gelebt werden. Diese Art von Arbeiten bedingt meistens einen nicht zu vernachlässigenden Wandel in Kultur und Mindset innerhalb eines Team oder einer Organisation. Bei der Einführung von Scrum wird dieses Fundament und Vorgehen oft gar nicht berücksichtigt. Um Scrum wirkungsvoll einzusetzen und damit Agilität zu erzielen, muss das Mindset und die Kultur aktiv gelebt werden. Sonst ist Scrum nur eine statische Methode ohne Agilität, nicht ein agiles Framework

Ist Scrum also der richtige Startpunkt um Agilität einzuführen? Meine Antwort ist "Nein".

Bevor Scrum eingeführt wird und von klassischen Projektmethoden auf agile Arbeitsweise oder Frameworks umgestellt wird, muss die Veränderung der Denkweise und der Kultur angegangen werden, die die Einführung von agilen Methoden oder Frameworks unterstützt.
Wie kann dieses Umdenken gestartet werden? Agil!

Der Grundgedanke von Agilität ist klein anfangen, ausprobieren, verbessern und dann, wenn nötig, skalieren. Dieser Grundgedanke kann auch der Leitfaden sein, um die benötigte Änderung voranzutreiben. Dies kann auch ohne definiertes Framework oder Methode, aber vielleicht mit Aspekten davon geschehen.

Man denke dabei zum Beispiel an Retrospektiven: alle 2 Wochen kann ein Team besprechen, was gut gelaufen ist und was verbessert werden kann. Das Team lernt dabei zu reflektieren und mitzudenken, wie die Arbeitsweise gestaltet werden kann.

Oder durch organisierte Wissensaustausche, teamintern oder teamübergreifend: die Tapferen unter uns können hier nicht nur Erfolge zeigen, sondern auch, was schiefgelaufen ist, was daraus gelernt wurde und wie die Fehler in die Zukunft vermieden werden können: Transparency, Inspect, Adapt.

Mit kleinen Schritten und iterativ werden die Mitarbeiter so vorbereitet auf die Einführung einer neuen Methode oder eines Frameworks. So kommt man dem Erfolg der Einführung einen Schritt näher.

Die Transformation von der klassischen zur agilen Arbeitsweise ist eine gemeinsame Reise, welche nicht nur das Team betrifft, sondern das Team und dessen Umfeld, wobei die Führungskräfte eine Schlüsselrolle haben. Wenn das Umfeld keinen Raum gibt für Änderungen, wenn Agilität nicht vorgelebt wird, ist die Reise zum Scheitern verurteilt.

Die Reise, bevor eine Methodik oder ein Framework eingesetzt werden kann, beginnt mit einer gemeinsamen, iterative Änderung der mentalen Einstellung.
Die Reise, bevor eine Methodik oder ein Framework eingesetzt werden kann, beginnt mit einer gemeinsamen, iterative Änderung der mentalen Einstellung. (Quelle: SwissQ)

Zusätzlich wird es durch wachsendes Verständnis agiler Prinzipien und Werte auch einfacher zu entscheiden, welche Methode oder Framework zur Organisation passt. Genau wie bei der Produktentwicklung: Woher wissen wir, wie wir unsere agile Arbeitsweise gestalten sollen oder welches Framework dabei hilfreich ist, ohne es ausprobiert zu haben?

Fazit

Mein Fazit ist also: Nein, Scrum ist nicht der richtige Startpunkt für eine Agile Transformation. Ich empfehle zuerst die Grundgedanken der Agilität zu verinnerlichen, die Veränderung der Denkweise und Kultur anzustossen und erst dann Scrum einführen.
Aber bei 100 Experten gibt es 101 Meinungen, wie siehst du das? Kann die Einführung von Scrum erfolgreich sein, ohne vorgängig die Veränderung der Denkweise und Kultur anzugehen? Ich freue mich auf deine Meinung in den Kommentaren.

Questions?

Get in touch with us to learn more about the subject and related solutions