Scrum ist die ungekrönte Nummer eins auf der Hitliste der agilen Methoden und reißt Scharen von agilen Coaches zu Begeisterungsstürmen hin. Genau das hielt mich bislang immer davon ab, die Methode und ihr Potenzial eingehender zu betrachten. Für meinen Geschmack erzeugte Scrum ein bisschen zu viel Wind in der Welt der Berater, Coaches und Trainer.

Am Ende ist es auch nur eine Methode im Ozean des Strebens nach Agilität und Selbstorganisation.

Oder?

Meine Haltung änderte sich im Rahmen eines Beratungsauftrags für ein mittelständisches Softwareunternehmen in Thüringen, bei dem wir gemeinsam mit dem Kunden entschieden, Scrum gleich im Doppelpack einzusetzen: einmal als Methode für die Produktentwicklung und zum anderen als Modell für einen Transformationsprozess hin zu mehr Agilität im Unternehmen. Das Vorhaben war also durchaus ambitioniert, zumal der Auftrag mitten in den Corona-Lockdown platzte und eine Zusammenarbeit mit dem Kunden zumindest am Anfang nur online möglich war. Trotzdem entwickelte sich sehr schnell eine produktive Dynamik. Ich war erstaunt, wie schnell sich die Mitarbeiter in Sprint Teams organisierten und damit begannen, in agilen Rollen zu arbeiten. Das Vertrauen in selbstorganisierte Arbeitsweisen wuchs von Tag zu Tag, ebenso wuchsen die Frei-Räume für die Entfaltung eigener Kompetenzen und Erfahrungen, die jede/r in das Projekt einbringen konnte.

Mich faszinierten diese spürbar werdenden psychologischen Veränderungsdynamiken. Tatsächlich halte ich Scrum inzwischen für eine Methode, die wie kaum eine andere aus dem Werkzeugkasten des agilen Managements dazu in der Lage ist, Menschen dazu zu befähigen, ihre Fähigkeiten ganzheitlich zu entwickeln und bestmöglich einzusetzen.

Woran liegt das?  

Management bedeutet Planung. Vor allem größere Projektvorhaben beginnen mit umfangreichen Planungssitzungen, die ebenso umfangreiche Powerpoint-Präsentationen oder Excel-Tabellen nach sich ziehen. Mit der eigentlichen Arbeit wird erst begonnen, wenn alle vorhersehbaren Eventualitäten ermittelt, dokumentiert und mit entsprechenden Aufgabenlisten hinterlegt sind. Solche Vorgehensweisen gehen mit der Illusion einher, man könne alles im Vorfeld planen und müsse dann die erstellten Listen nur noch abarbeiten. Unzählige Beispiele von kollabierenden Großprojekten mit explodierenden Kosten und enormen zeitlichen Verzögerungen verdeutlichen jedoch, dass umfangreiche Projektvorhaben nur bedingt planbar sind. Perfektionismus bis ins Detail funktioniert in volatile Umwelten nur kurzfristig; langfristig ist er zum Scheitern verurteilt, weil sich die Umweltbedingungen ändern, Märkte sich wandeln oder einfach der Kunde nach Monaten feststellt, dass er eigentlich doch etwas ganz anderes wollte.

Bei Scrum tritt an die Stelle einer langfristigen Planung eine "Planung auf Sicht. Kurze Produktionszyklen von 1-4 Wochen strukturieren einen iterativen Prozess und ermöglichen, auf notwendige Änderungen sofort zu reagieren und etwaige Fehler im nächsten Sprint zu korrigieren. Ein Scrum-Projekt bewegt sich also spiralförmig seinem erfolgreichen Abschluss entgegen, während das klassische Projektmanagement darauf abzielt, einen einmal aufgestellten Plan Schritt für Schritt und möglichst fehlerfrei abzuarbeiten.

In der Scrum-Community wird gerne erzählt, dass Scrum aus dem Rugby kommt.  Der Vergleich mit dem "Gedränge" (scrum), in dem ein Team als Organismus zusammenspielt, liefert tatsächlich ein passendes Bild für die selbstorganisierte Teamarbeit bei Scrum. Weniger bekannt ist,  dass der Name zum ersten Mal in einem Artikel in der Harvard Business-Review aus dem Jahr 1986 auftaucht. Darin stellen die beiden japanischen Management-Vordenker Takeuchi und Nonaka heraus, dass bei der Entwicklung eines komplexen Produktes die besten Ergebnisse erzielt werden, wenn kleine Teams Ziele gesteckt bekommen, die sie selbstorganisiert erreichen müssen. Diese agile Arbeitsweise verglichen sie mit Rugby.

Jeff Sutherland und Ken Schwager, die beiden Erfinder von Scrum, übernahmen diese Referenz und ergänzten den Beinamen "framework". Im Allgemeinem wird diesem Subtitel wenig Beachtung geschenkt. Zu Unrecht, denn tatsächlich handelt es sich bei Scrum genau um eben das: ein "Rahmenwerk" für einen strukturierten Prozess der Produktentwicklung. Innerhalb dieses Rahmens herrschte größtmögliche Freiheit zur Selbstorganisation der Projektbeteiligten.

Während im Projektmanagement die Organisation und Steuerung von Tätigkeiten und Aufgaben im Zentrum steht, geht es bei Scrum immer um das zu erreichende Ziel – das kann die Entwicklungen einer Software sein, eine Produktlinie für Kosmetik, ein Auto aber auch eine Dienstleistung wie etwa die Planung einer Hochzeit. Wie das Projektziel erreicht wird, liegt beim Team. Die Komponenten von Scrum bilden lediglich Leitplanken auf dem Weg dahin. 

Zumindest funktioniert es wie ein Team-Spiel im Gewand einer Anleitung für die Produktentwicklung.

Alle Elemente von Scrum – Backlog, Sprint Planning, Daily Scrum, Sprint Review und Retrospektive – definieren die Spielregeln und setzen den Rahmen, innerhalb dessen gespielt wird (framework). Die Spieler (Mitglieder des Sprint-Teams)  gestalten diesen Rahmen (Selbstorganisation). Die Aufgabe ist es, möglichst schnell und unter Einsatz der individuellen Stärken der Spieler als Team zum Ziel zu kommen (Sprintplanning + Sprints). Hier sind Initiative, Risiko-Bereitschaft und Macher-Mentalität ´gefragt (test-and-learn, Prototyping, aus Fehlern lernen etc).

Ein Spiel zwingt zu Entscheidungen. Und entscheiden können, ist die Grundlage von Führen.

Was umgekehrt bedeutet, dass jede/r im Spiel lernt, sich selbst und die Fähigkeiten seiner Mitspieler gut einschätzen zu können. Kompetenz und Erfahrung sowie eine gewisse Leichtigkeit im Spiel – Resultat von jedem guten Team-Play – sind Kriterien für den Erfolg.

Selbstorganisation als Motivations-Beschleuniger gehört zu den absoluten Vorzügen von Scrum.

Aber genau hierin liegt auch die Crux, denn die Fähigkeit zur Selbstorganisation setzt ein bestimmtes Mindset voraus.

Für die Spieler unter uns ist es ganz einfach, hier sind die Regeln immer nur Mittel zum Zweck, der darin besteht, möglichst schnell und effektiv zum Ziel zu kommen.

Für die anderen, die Manager unter uns, ist das Erlernen der Spieleanleitung hingegen eine unglaublich komplizierte Angelegenheit: Wie detailliert muss ein Backlog sein? Was genau wird im Sprint Planning festgelegt? Was besagt die "Definition of Done" denn nur ganz präzise? Wann müssen sich Product Owner und Scrum Master abstimmen? Wieviele Sprints darf ein Scrum-Prozess maximal haben?

Jede, die schon einmal mit Scrum gearbeitet hat, weiß, dass sich diese Fragen in der Theorie nur bis zu einem bestimmten Schärfegrad beantworten lassen .Einfach ausprobieren! Experimentieren! Ins Machen kommen! Das hat nicht nur den Vorteil, dass relativ schnell deutlich wird, wo die Spielregeln an die individuellen Anforderungen und Bedarfe der eigenen Organisation angepasst werden müssen, sondern auch, dass die positiven Effekte von Scrum – Prozessoptimierung und Qualitätssteigerung – nicht lange auf sich warten lassen.

Jenseits von ökonomisch meßbaren Erfolgen besteht der wichtigste Effekt von Scrum in der Erfahrung von Selbstwirksamkeit. Die Mitglieder eines Sprint-Teams erleben, dass ihre Handlungen erfolgreich sind.

Vor dieser Erfahrung steht allerdings der Mut, ausgetretene Gleise des so-war-es-schon-immer-und-so-machen-wir-das-weiterhin zu verlassen und den ersten Schritt in die Veränderung zu tun.  Dazu gehört vor allem die Bereitschaft, einfach mit dem anzufangen, was aktuell machbar ist – ohne ausgeklügelten Plan, der vermeintlich glasklar alle Parameter von A bis Z auflistet.

Die Erfahrung zeigt, dass dieses "Auf Sicht fahren" gar nicht so einfach ist. Gerade in der Arbeitswelt sind wir darauf getrimmt, alles im Griff zu haben und Eventualitäten und Unsicherheiten möglichst aus dem Weg zu räumen.

Einfach anzufangen, auch wenn noch nicht alles restlos klar ist, bedeutet, diesem Reflex entgegenzuwirken.

Das erzeugt zunächst Unsicherheit und Abwehr: Könnte mir bitte mal jemand sagen, ob das richtig ist, was wir gerade tun? Was passiert, wenn wir die Deadline nicht halten können? Wer garantiert, dass wir mit dieser Strategie nicht Baden gehen?

Die Antwort lautet: Keiner, oder besser gesagt: alle, die am Entwicklungsprozess beteiligt sind. Und das ist zuallererst die Geschäftsleitung des Unternehmens. Ihr Commitment ebnet den Weg für den Kurswechsel und fördert eine Unternehmenskultur, die Raum und Gestaltungsmöglichkeiten für selbstorganisiertes Arbeiten, kollegiale Führungsstile und Team-Spirit schafft.

Mir ist völlig klar, dass der Vergleich zwischen Scrum und einem Spiel hinkt. Immerhin handelt es sich bei einem Spiel um eine freiwillige Handlung, die ihr Ziel in sich selber hat, während Scrum eine Methode aus der Arbeitswelt ist, deren Erfolg am Ende an knallharten ökonomischen Kennzahlen gemessen wird. Mir geht es also keinesfalls um eine naive neoliberale Verklärung agiler Methoden. Trotzdem bin ich davon überzeugt, dass ein nicht unerheblicher Teil des Erfolgs von Scrum in der Förderung von spielerischen Möglichkeiten seiner Akteure liegt, die ihre Kompetenzen und individuellen Stärken anders als in der herkömmlichen Projektarbeit entfalten können.  Als "framework" schafft Scrum einen Rahmen – aka Spiel-Räume – in denen anders, d.h. selbstorganisierter, freier, interdisziplinärer, eigenverantwortlicher und (hopefully)  produktiver zusammengearbeitet werden kann.

Alle Abbildungen stammen aus der Ausstellung "It Wasn't Us"  von Katharina Grosse im Hamburger Bahnhof, Berlin 2020.

Photos:Anja Osswald