Was ist Scrum? Eine kurze Definition

Beginnen wir damit, dass wir es „Scrum“ schreiben, nicht, wie oft zu sehen, „SCRUM“. Es ist kein Akronym, und wir wissen nicht genau, wieso Ken Schwaber und seine Mitstreiter den Begriff großgeschrieben haben. Vielleicht, weil im Zeitalter der Schreibmaschinen Fettgedrucktes als Mittel zur Betonung noch nicht so gut funktionierte wie Kapitalschrift. Vielleicht fand er es einfach cooler – wir wissen es nicht. Ab 2002 spätestens, mit Erscheinen von Schwabers „Agile Software Development with Scrum“, wird es „Scrum“ geschrieben, und so halten auch wir es in diesem Artikel – einverstanden? Das Buch sollte übrigens Pflichtlektüre für jeden angehenden Scrum Master sein, ebenso wie für nach Scrum arbeitende Teams. 

Scrum ist auch kein Software- oder Projekt-exklusiver Begriff: Er stammt aus dem Rugby, übersetzt sich wörtlich mit „Gedränge“ und, so sagt es auch Wikipedia, bezeichnet eine Spielphase, in der alle 32 Spieler um den Ball rangeln, nachdem es einen Regelverstoß gab. Das mündet in verschiedene Versionen eines „Gedränges“, in dem viel passiert, in viele kleine Schritte aufgeteilt; alle wissen, was zu tun ist, was den Ball in gemeinschaftlichen Spielzügen Stück für Stück nach vorne bringt: Ordnung im Chaos. Ach herrje, da haben wir ja glatt die Quint Essenz von Scrum beinahe beiläufig auf den Punkt gebracht. Inkrementelles Arbeiten, wunderbar. Ebenso beiläufig erwähnt seien noch Hirotaka Takeuchi und Ikujiro Nonaka. In ihrem Artikel „The New New Product Development Game“ sprechen die Japaner schon 1986 von Scrum und erwähnen wiederum, dass es bereits zahlreiche Firmen in Japan und den USA gibt, die nach dieser (damals) neuen „Methode“ arbeiten. Also gar nichts so arg Neues im Westen. Und Osten.

(Beinahe) last, but (for sure) not least: Scrum ist ein Framework, keine Methodik. Darüber wird hier und da debattiert. Bei einer „Methode“ ist indes nicht nur der Rahmen klar, sondern auch dessen Umsetzung. Scrum als Framework gibt zwar grundlegende Regeln und Strukturen vor, schreibt darüber hinaus aber nicht vor, wie es umgesetzt werden soll.

Apropos: Müssen wir Scrum an sich an dieser Stelle erneut erklären? Ich denke, wir machen es uns hier lieber einfach, denn die meisten Leserinnen und Leser dürften Bescheid wissen. Zur Sicherheit, falls jemand über die Schulter sieht:

Scrum im Quick Dive

Scrum ist ein Framework für die Projektentwicklung, vornehmlich – aber nicht exklusiv – der Softwareentwicklung. Typische Charaktereigenschaft ist, einstmals große und langwierige Ziele in kleine Schritte zu unterteilen, sogenannte Inkremente, mit fest bestimmten Zeiten und Rollen. Ziel ist, dem Stakeholder immer wieder funktionierende Teilschritte präsentieren zu können, flexibel auf Anforderungen und Änderungen eingehen zu können und sich Schritt für Schritt zu einem finalen Ziel zu bewegen. Scrum. Gedränge, aber mit Ordnung. Macht Sinn. Die Rollen sind klar verteilt:

• Kern ist immer ein (Software-)Entwicklungsteam, das von einem
• Scrum Master unterstützt wird, und mit dem
• Product Owner arbeitet, der die Produktvision mit dem Team teilt und

kooperativ auf das finale Produkt hinarbeitet. Kern dieses Vorgehens ist der „Sprint“, eine definierte Zeit (meist zwischen 1 und 4 Wochen, zwei Wochen sind am häufigsten anzutreffender Standard) in der die eigentliche Entwicklungsarbeit stattfindet.

Um diese Arbeit optimal zu unterstützen, gibt es sogenannte „Scrum Events“:

• Das Sprint Planning zu Beginn des Sprints, in dem das gesamte Team den Umfang der Arbeit für den Sprint basierend auf den Prioritäten des Product Owners und der verfügbaren Ressourcen festlegt.
• Im Daily Scrum (auch „Daily Stand-Up“) trifft sich das Team und bespricht kurz, was am Vortag erledigt wurde und was am heutigen Tage stattfinden soll (macht also früh am Tag Sinn).
• In der Sprint Review stellt das Team die (idealerweise) funktionalen Produktinkremente gegenüber den Stakeholdern, oft dem Product Owner, vor. Im Beispiel einer Smartphone-App könnte das zum Beispiel eine neue Funktion sein, eine Oberfläche, funktionierende Buttons und Ähnliches. Eben nicht die gesamte App, sondern Teilschritte, „Inkremente“ genannt. Dabei spielt auch der Product Owner eine wichtige Rolle und gibt sein Feedback zu den Fortschritten ab. Kernfrage dieses Meetings ist: „Are we on track?“
• Oft stiefmütterlich behandelt und als lästig angesehen, aber mit das wichtigste Event ist die „Sprint Retrospektive“ (häufig mit „Retro“ abgekürzt), in der sich das Team (meist ohne Product Owner) trifft und den vergangenen Sprint reflektiert: Was lief gut, was war nicht ideal, was muss verbessert werden? Wie genau können wir uns verbessern, wo bestehen überhaupt etwaige Lücken? Hieraus sollten sich stets konkrete Ergebnisse ableiten lassen, um den nächsten Sprint zu optimieren.

Wenn man nun noch von den „Artefakten“ gehört hat, also dem

• Product Backlog (also die Liste aller gewünschten Arbeiten am Produkt),
• dem Sprint Backlog (die Liste mit Aufgaben, die das Team im aktuellen Sprint erledigen möchte) und dem
• Increment (Summe aller Product-Backlog-Items, die während dieses und ggf. des vorherigen Sprints abgeschlossen wurden),

ist man schon gut dabei. Mehr muss nur wissen, wer konkret damit arbeitet. Um den Absatz abzuschließen, noch die drei Säulen von Scrum, die unserem Framework Halt geben: Transparenz, Überprüfung, Anpassung. Bei so vielen Inkrementen braucht es Überblick, Teilschritte müssen geprüft werden (Qualitätssicherung), Adaption muss stets gegeben sein. Schließlich stützt sich Scrum als vor allem agiles Framework (welches es bisweilen sein darf – wir kommen noch dazu) auf agile Prinzipien, allen voran das „Agile Manifest“. Das verlinke ich euch aber jetzt zum selbst Nachlesen – geht in einem separaten Tab auf, und wenn du fertiggelesen hast (oder gar nicht erst liest), machen wir hier direkt weiter mit:

Was Scrum nicht ist – Die Grenzen des Frameworks

Wir wissen nun also ganz gut, was Scrum ist, und haben vielleicht auch eine Vorstellung davon, wie wir dieses Framework in unserer Organisation einsetzen möchten. Ist ja keine Raketenwissenschaft. Hat vielleicht auch ein „Agile Master“ vorgeschlagen, die sich – wieso auch immer – leidlich gerne vom Team entkoppeln und hohen Wert darauf legen, dass sie nicht „nur“ Scrum Master sind. Dabei ist die Rolle eines Agile Master oder Agile Coach innerhalb eines Softwareentwicklungs-Teams überaus eindeutig: Es ist die des Scrum Master. Als Teil des Teams. Kein Anführer, bestenfalls Berater. Auch kein Diener – bestenfalls Ansprechpartner für alle Belange, weil Vertrauen besteht.

Das klingt doch alles wunderbar und nicht besonders kompliziert, richtig?

Wieso also müssen wir uns jetzt mit der Prämisse herumärgern, dass Scrum, so der Clickbait-Titel dieses Artikels, gar nicht funktioniert? Ist das denn wirklich so fatalistisch? Nehmen wir einige Beispiele aus realen Projekten, die mir untergekommen sind. Ich nenne sie nicht konkret, aber wir alle, die uns mit diesem Artikel befassen, kennen solche oder ähnliche Geschichten:

• Die Planung jedes einzelnen Schrittes im Team dauert wahnsinnig lange. Ganze Tage werden genutzt, um alles bis ins Detail zu planen. Jira wird installiert, eine Milliarde Stories werden geschrieben und danach sitzen alle im Kreis und fragen sich täglich die gleichen drei Fragen, bis irgendjemand tot umfällt. Am Ende gibt es super viele Story Points, deren tatsächliche Umrechnung in Stunden oder Projekttage dolle geheim ist. Dienen sollten diese dazu, eine Idee von der Komplexität einer Aufgabe zu bekommen, und eine Einschätzung des Teams zu erhalten, wie lange deren Umsetzung benötigen könnte. Stattdessen werden – viel zu oft – Storypoints und Kanban Boards genutzt, um eine rigide Zeit- und Leistungsmessung der Teammitglieder vorzunehmen. Auch außerhalb der Projektlandschaft werden Kanban-Boards enorm gerne so verwendet – oder, das Kind beim Namen genannt: missbraucht.
• Klar – wir haben T-Shirt-Größen, eine großartige Idee: So und so viele Storypoints sind eine M-Aufgabe, ein paar mehr eine XL-Aufgabe, und eine kleine S-Story kriegen wir noch mit rein. Aber ist das Updaten von Kibana jetzt eine L oder XL-Aufgabe, oder splitten wir die Story in lauter kleine S-Stories? Und was, wenn der Testserver ausfällt? Das resultiert darin, dass das Team seinen Terminplan füllt, stets darauf bedacht, die Leistung zu erbringen, statt sich auf das Programmieren (testen, implementieren etc.) zu fokussieren.
• Und was erst, wenn Scrum Master UND Product Owner im Urlaub sind? Gibt es dann dennoch ein Daily, oder gar ein Sprint Planning? Was, wenn Storypoint-Vorgaben immer gleich sind und fast nicht eingeholt werden? Ist ein Spillover eingeplant, oder heißt es einfach: Ziel nicht erreicht, Auftrag weg?
• Na, dann schreiben wir vielleicht doch lieber ein Ticket (aber nur die einfachen – wer will sich schon freiwillig das enorm komplexe Problemticket schnappen, damit später jeder im Kanban-Board sieht, dass er die Aufgabe, möglicherweise unverschuldet, nicht komplett lösen konnte?) Oder wäre das Problem in 5 Minuten gelöst gewesen, während das Verfassen, Weiterleiten und Schließen des Tickets eine halbe Stunde in Anspruch genommen hat? Wie viele sinnlose Storypoints verlieren wir hier? Können wir das dem Kunden trotzdem berechnen?

Ach, wisst ihr was? Bei uns funktioniert Scrum einfach nicht, und der ganze agile Kram bringt doch eh nichts, außer die Dinge kompliziert zu machen.

Aber, Spoiler: Es ist gerade der agile Gedanke, der hier fehlt. Scrum ist NICHT gleich Agile Development. Es ist ein Baustein, und ein Baustein allein macht nun mal kein Haus. Oder Lego-Schloss. Uhm, oder Flussufer-Puzzle, dass nicht nur deswegen seit Monaten auf dem Schrank liegt und verstaubt, weil alle Teile mit Gras drauf verflixt nochmal gleich aussehen. Scrum ist ein Werkzeug, das korrekt eingesetzt werden will, und in all den obigen Beispielen war dies schlicht nicht der Fall.

Scrum bedeutet mitnichten, man müsse nicht oder dokumentieren, weil das Agile Manifest das sage. Tut es nicht. Es sagt: „Wir stellen funktionierende Software über ausführliche Dokumentation.“ Das heißt also, wir schätzen Dokumentation und nutzen sie. Wir wollen sie nur nicht unnötig ausufernd, und funktionale Software-Inkremente, die wir dem Kunden in der – aufgepasst? – Sprint Review vorstellen können, ziehen wir vor. Denn auch das sagt das agile Manifest, wenngleich es oft überlesen wird: Wir ziehen die neuen Erkenntnisse vor, aber wir schätzen auch die Basis, auf der sie aufbauen.

Scrum funktioniert also nicht immer und nicht in jedem Projekt. Es ist letztlich „nur“ ein Werkzeug für das Prozessmanagement, für optimierte und anpassungsfähige Prozesse und Arbeitsschritte. Es ist aber kein Allheilmittel, um jedwedes Softwareentwicklungs-Team leistungsfähiger zu gestalten. Eine nette Grafik hierzu ist die sogenannte „Stacey Matrix“ aus dem offiziellen PMI Agile Practice Guide (zum besseren Verständnis: Scrum als agiles Framework fällt unter „Adaptive Approach“).

Allerdings, und dies sagt Ralph Douglas Stacey selbst: Die Matrix hat keine echte Aussagekraft. Sie soll eine Hilfestellung sein, ein erster Überblick. Oft wird sie aber werbend für agile Methoden oder eben spezifisch Scrum eingesetzt. Das ist nicht der Grundgedank der Matrix. So ist zum Beispiel „Komplexität“ keine passende Metrik, anhand derer man die Projektmethode wählen kann, und auch das spezifische Projektumfeld kann die Matrix natürlich nicht berücksichtigen. Indes, eine Hilfestellung, um sich eine ungefähre Vorstellung davon zu machen, ob Scrum hier passen könnte oder nicht, ist die Matrix sicherlich, und gesehen haben sollte man sie so oder so mindestens einmal. Hiermit erledigt.

Wir lernen also: Es gibt sehr wohl Bereiche, in denen die klassische Wasserfall-Methode in der Entwicklung nach wie vor adäquat ist, oder das V-Modell (hierzu auch empfehlenswert ist die Kenntnis des PDCA-Cycle als erster Check). Scrum ist keine Lösung, die für sich steht und ungeachtet der Umstände auf absolut jeden Deckel passt. Das gilt auch, wenn der Topf ansonsten passen würde: Ein Team ist vielleicht breit aufgestellt, das Projekt benötigt einen adaptiven und flexiblen Ansatz in der Entwicklung, das Unternehmen unterstützt, der Scrum Master kommt nicht aus dem Entwicklungsteam (ein häufig begangener Fehler): Und trotzdem klappt es nicht. Nicht jedes Teammitglied möchte eigenständig und zugleich kooperativ arbeiten. Nicht jeder möchte öffentlich von seiner Arbeit reden, nicht jede Entwicklerin oder jeder Entwickler fühlt sich wohl mit klar definierten Rollen, sondern wechselt lieber oft die Projekte. Ohne Team kein Scrum, das ist eine ungeschriebene, aber absolut essenzielle Wahrheit. Scrum selbst ist aber kein Mittel, um Teams zu bilden. Bisweilen kann ein guter Scrum Master ein Team inspirieren und auch zusammenführen, aber er kann es nicht alleine erschaffen.

Wir haben also nun etabliert, was Scrum alles nicht ist, welche Erwartungen es nicht erfüllen kann und welche Fehler in falscher Anwendung des Frameworks geschehen können. Zeit für uns, uns Scrum nicht länger als eine Lösung anzusehen, sondern als einen Baustein auf dem Weg zum Ziel.

Scrum als Baustein funktionierender agiler Softwareentwicklung

Ein immer wiederkehrender gedanklicher Fehler, der in der täglichen Arbeit mit Scrum und vor allem den Entscheidern, die über dessen Einsatz nachdenken, auftaucht, ist dieser Satz: Scrum ist ein fixes Framework, für das man alle Regeln befolgen muss, damit es funktioniert.

Dabei ist Scrum in seiner absoluten Grundnatur adaptiv. Anpassung ist einer der essenziellen Vorteile des Frameworks. Sicher, Scrum Events wegzulassen ist keine besonders gute Idee. Niemand sagt aber, dass es kein Scrum mehr ist, weil das Product Increment Planning auch mit im wiederkehrenden Meetingzyklus ist. Niemand sagt, dass sich Teammitglieder nicht außerhalb der Retro äußern dürfen oder Inkremente nur in der Review vorstellen sollen. Flexibilität ist eines der Wahrzeichen vor allem der agilen Methodik, und von eben dieser ist Scrum einfach nur ein Werkzeug. Es gibt andere Werkzeuge: Lean Management/Development, Kanban (allerdings fast immer Teil von Scrum), Extreme Programming (XP)(auch hier kann z.B. der Part des „Pair Programming“ Einzug in Scrum-Projekte halten) oder auch Crystal, eine extrem auf die Individuen des Teams fokussierte Methode (bzw. Framework).

Scrum ist also nicht nur ein Projektmanagement-Werkzeug – es ist ein Baustein, eine kritische Komponente einer insgesamten, überhängenden agilen Philosophie, die für Anpassungsfähigkeit steht, für Teamzusammenhalt und Kundenausrichtung. Durch den steten Austausch sind Kunden auch bei komplexen und zeitlich lange laufenden Projekten stets im Bild über den Status Quo, über die Fortschritte, die Ziele und natürlich auch die Kosten. Unternehmen, die Scrum einsetzen, können ebenfalls sehr genau nachverfolgen, welche Kosten an welcher Stelle entstehen, und Unmengen von Erkenntnissen aus bewältigten Sprints ziehen. Vom einfachen Flussdiagramm, das uns eine gute Vorstellung der Team Velocity gibt, bis zu komplexen Dashboards, die Informationen dazu liefern, welche Aufgaben wiederholt anfallen, wie diese bewältigt wurden, mit wie viel Personen, in welcher Zeit? Klare Hausnummern, geliefert von einem adaptiven und flexiblen Werkzeug. Volle Kostenkontrolle und Einsicht über Leistung, ohne diese passiv-aggressiv monitoren zu müssen. Wunderbar.

Insbesondere auf Team-Ebene lässt Scrum die Muskeln spielen: Durch die Säulen von Scrum (ihr erinnert euch, ganz ohne wieder nach oben zu scrollen, richtig?) ist mehr als durch die Events und Grundregeln sichergestellt, dass alle Aufgaben und Abläufe transparent sind, geprüft und jederzeit anpassungsfähig. Die offene Kommunikation, das regelmäßige Zusammenfinden und Interagieren als echtes Team, in dem jedes Mitglied von gleicher Wichtigkeit ist („The Circle Way – With a Leader in Every Chair“), bildet Vertrauen und Verlässlichkeit, in Andere und in die eigenen Fähigkeiten. Eine auf diesen Werten gebildete, offene Kultur lässt Feedback zu, aber auch Fehler: Diese werden untersucht und für die Zukunft vermieden. Und wenn sie doch wieder auftauchen (schließlich darf laut rigider Anwendung jeder Fehler passieren, aber nur einmal…)? Dann untersucht das Team – gemeinsam – wie es dazu kommen kann. Stetes Gehörtwerden, in sicherer Umgebung, ohne Furcht vor disziplinarischen Repressalien: In einer Sprint Retrospektive möglich wie in kaum einem anderen Rahmen. Einfach mal Kritik abgeben, die kein bisschen konstruktiv ist, sondern einfach nur Dampf ablässt, in einer Runde, die dich versteht und schätzt: Unendlich wertvoll. Psychologische Sicherheit ist nicht nur ein Buzzword. Sie befähigt Teams und Individuen zu enormen Leistungen, vor allem aber zu Wohlbefinden, zu Stabilität und Wertschätzung für sich und andere.

Schon klingt Scrum gar nicht mehr so methodisch und starr, richtig?

Korrekt als Baustein einer agilen Transformation eingesetzt, ist Scrum – im richtigen Szenario – eine Option, die funktionieren kann, wenn auf die Variablen geachtet wird. Arbeiten Angestellte nicht gerne eigenständig, sondern brauchen jede Aufgabe explizit genannt und eingefordert? Das gibt es, nicht alle sind für die Freiheit geschaffen. Ist dann vermutlich keine gute Besetzung für ein Scrum Team. Kritikfähigkeit, Weiterentwicklung auf fachlicher wie persönlicher Ebene, Teamgeist und auch eine gewisse Selbstlosigkeit gehören dazu. Scrum ist ein Framework für Teams. Hast du kein Team, brauchst du kein Scrum, so einfach ist das. Ein guter Scrum Master ist hier übrigens von großem Vorteil: Wir sprechen gleich nochmal darüber.

Apropos Teams: Führt man Scrum mit DevOps-Praktiken zusammen, können enorm starke Entwicklungsteams entstehen, mit wenigen Abhängigkeiten nach außen und großer Beweglichkeit, die das Abliefern von High Quality Software (oder anderen Produkten) schneller und verlässlicher ermöglicht als in klassischen Team-Aufteilungen. Das Verringern von Abhängigkeiten („Impediments“) ist erklärte Aufgabe des Scrum Frameworks (und in der Folge des Scrum Masters). Erst in DevOps-Teams lässt sich Scrum wirklich so einsetzen, wie es das agile Manifest einmal vorgesehen hat, nämlich, so sagt es der Scrum Guide: „The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of „Done“ product at the end of each Sprint.”

Echtes Abliefern, von der Entwicklung bis zum Release, also „End-to-End“, ist in reinen Entwicklungsteams so nicht umsetzbar. Oft gibt es reine Entwicklerteams und reine Operations-Teams, und schon erfährt Scrum ersten Gegenwind. Sicher – nicht jede Organisation hat die Wahl. Aber das Gerücht, dass Scrum nicht mit DevOps-Units funktioniert? Nur eine urbane Legende. Eine unsinnige noch dazu.

Es würde sich sogar noch mehr über Scrum als Baustein sagen lassen: Wie es wunderbar skalierbar ist, zum Beispiel in SAFe-Projekten, wie die wiederkehrende Natur von Scrum alle Stakeholder immer wieder auf ein gemeinsames Boot bringt (allegorisch gesprochen. Obwohl ich nicht sehe, wieso eine Retro nicht auch auf einem Boot stattfinden könnte).

Der größte Vorteil von Scrum als Baustein ist aber sicher mit dem vereinbar, was der Mitgründer des agilen Manifests, Ken Schwaber, darüber sagte, wir haben es erst vor zwei Abschnitten auf Englisch zitiert, aber es ist so wichtig, daher noch einmal: Das wichtigste Element von Scrum ist die Erschaffung eines fertigen und grundsätzlich release-fähigen Produktinkrements.

Der Vorteil liegt klar auf der Hand. Am Ende jedes Sprints können Teams, Unternehmer, Stakeholder zusammenkommen und sich echte Fortschritte ansehen. Nicht nach 2 Jahren Entwicklungszeit und intensivem Testing, bei dem uralte Bugs in endlosen Dokus nachgesehen werden müssen (so sie denn überhaupt sinnvoll gestaltet und kommentiert sind. Jeder kennt Legacy-Dokus von Entwicklern, denen es am Ende einfach egal war…), und bei dem es nach der Präsentation siebzehn Schritte zurück in der Entwicklung geht, weil in den letzten 2 Jahren gefühlt eine Million neue Versionen, Updates und Plattformen entstanden sind. Stattdessen schreitet Scrum iterativ voran, ist immer am Puls der Zeit, präsentiert Ergebnisse, passt sich an Gegebenheiten an und gibt überdies die Möglichkeit, auf aktuelle und ggf. auch veränderte Prioritäten der Stakeholder einzugehen: Durch die erneute Priorisierung in jedem Sprint setzt man nur die Ziele um, die wirklich gewünscht sind, statt Arbeit mit unnötigen Tasks zu vergeuden – flexibler geht es kaum.

Für mich ist allerdings etwas anderes noch wichtiger. „Take it with a grain of salt” – meine agile Reise hat erst begonnen. Es mag daher mehr persönliche Note als Fakt sein, indes: Die Bildung eines Teams ist die essenzielle Leistung von Scrum als Framework. Ich kenne kein anderes Werkzeug, das in solchem Maße vertrauen schafft, für Teams, für Kunden, für Unternehmen. In Teams sitzen echte Menschen, mit Stärken, mit Schwächen, die wir – in beiden Fällen – nutzen können, um uns persönlich zu entwickeln. Der stetige, anhaltende Austausch auf Augenhöhe, die Sichtbarkeit aller, Menschen wie Prozesse, die Ermutigung dazu, Verantwortung und Ownership für Entwicklungsschritte und eigene Leistung zu übernehmen: Sie schaffen Zusammenhalt. Regelmäßige, inkrementelle Erfolge schütten Dopamin aus, Belohnung, für geleistete Arbeit. Jeder absolvierte Sprint ist nicht nur ein einfaches Zieleerreichen. Es ist ein Schritt zu einem höheren Standard echter Exzellenz und erweitert die Fähigkeiten des Teams, nicht nur Deadlines zu schaffen, sondern herausragende kollaborative Resultate zu schaffen. Außerdem: Echtes Feedback bringt uns fachlich wie menschlich voran, und davon bietet Scrum mit all seinen Events endlose Möglichkeiten. Gepaart mit einem Scrum Master, der sich nicht nur als Moderator versteht, sondern als in der Rolle wirkender Facilitator, als Enabler, entstehen in Scrum Teams Bindungen, die echte psychologische Sicherheit schaffen und Menschen zu Großem befähigen können. Oder auch zu Kleinem, dafür ist Scrum ja da.

Ach, das wäre doch fast schon ein gutes Schlusswort, der Artikel ist ja nicht gerade kurz. Wir sprechen aber noch kurz darüber, was sich in Scrum geändert hat – das machen wir daran fest, was offiziell im Scrum Guide festgehalten wurde. Ist interessant, bietet Gelegenheit für eine kleine Liste (Google lieeeeebt Listen), und wir haben einen runden Artikel. Denn was Scrum ist, was es nicht ist, was es leisten kann, setzt man es korrekt als Baustein statt als Lösung ein: Haben wir alles geklärt. Also auf auf, Zeit ist rar, schnell die Änderungen und dann zum Fazit, okay?

Was Scrum inzwischen ist – Die Änderungen seit 2020 (offizieller Scrum Guide)

Jaja, die Zeiten ändern sich, und die Zeiten ändern dich. Und sie ändern Scrum. Reden wir zum Beispiel über den Scrum Master: Der hat nach bisheriger Definition bestenfalls keine Autorität im Team, weder disziplinarisch noch fachlich, und sollte aus der Software-Entwicklung stammen (zumindest im Software Development Bereich). Stattdessen werden heute auch Projektleiter gerne als Scrum Master gesehen (vom „Servant Leader“ zum „True Leader“), ebenso wie „nicht-Techies“, die aufgrund ihrer Distanz zur fachlichen Ebene neue und andere Perspektiven einbringen können, und, sofern wir von selbstbewussten Facilitators sprechen, einen höheren Fokus auf das Schaffen psychologischer Sicherheit legen können (empfehlenswert hierzu die Denkschule von Sharon Bowman -> „Training from the back of the room“). Und schon verschwimmen Agile Coach und Scrum Master erneut. By the way: Die Rollen sind keine Titel. Ein Scrum Master kann ein großartiger Scrum Master sein, ohne sich so zu nennen oder jemals eine Scrum-Master-Zertifizierung absolviert zu haben.

In den Sprint Plannings herrschte bislang die These der zwei Fragen: „Was mache ich“ und „wie erreiche ich das“. Inzwischen ist eine dritte Frage gern gesehen: „Wieso wollen wir das?“. Ist eine irgendwie komplexe Frage, die nicht in jeden Kontext passt. Aber (nochmal ein Anglizismus, die mag ich halt:) Here we go again – Scrum ist adaptiv. Dein Scrum Master darf gerne mit oder ohne Autorität daherkommen, solange er KEIN Entwickler aus dem Team ist (die haben Wichtigeres zu tun, zum Beispiel, äh, das Geld für dein Unternehmen zu verdienen!), und du kannst auch nur eine Frage stellen. Aber du hast es jetzt schon mal gehört.

Auch neu sind die „Commitments“ – zu den Artefakten (weißt du noch alle drei?) kommt nun ein Commitment. Das Sprint Backlog bekommt nun das „Commitment“, also die „Widmung“, die „Hingabe“ des „Sprint Goals“, also des „Sprint Ziels“, und das Inkrement erhält die „Definition of Done“. Das erhöht die Transparenz für alle Beteiligten und hilft, die Scrum-Werte weiter zu vertiefen. Ganz ehrlich, für jemanden, der bei fast jeder Aufgabe im Leben wissen will, wieso man sie machen soll und damit zahllose Arbeitgeber in den Semi-Wahnsinn getrieben hat, ist das aus meiner Sicht ein Fanal für kooperatives und wertschätzendes Miteinander im Rahmen eines Frameworks. Wer sagte doch gleich, dass Scrum nicht funktioniert? Oh, ich. Aber wir sind uns ja nun einig, dass das eher ein Köder war. Und wenn du bis hierher gelesen hast: Respekt, das Thema scheint dich zu interessieren!

Einige weitere Aspekte sind ebenfalls neu hinzugekommen: Das Konzept von „einem Team“ (im Gegensatz zur alten Aufteilung in Development Team, Scrum Master und Product Owner). Scrum Master wachen über die Einführung und Einhaltung der Scrum Regeln, aber nicht für das Unternehmen oder den Scrum Guide, sondern für das Team, und Product Owner pflegen das Product Backlog effizient und eigenverantwortlich (Letzteres hat sich allerdings bislang wenig durchgesetzt, allzu oft ist die Pflege des Backlogs Teil von Refinement Meetings mit dem Scrum Team, ebenso wie das Increment Planning, eine Art übergeordneter Visionsabgleich). Product Owner müssen nach aktualisiertem Scrum Guide dafür nicht mehr die Sprint Review moderieren, das macht nun der Scrum Master, und vor allem wurde die Vision des „Product Goal“ wieder deutlicher betont: Wir arbeiten auf ein finales, fertiges Produkt hin. Das geht vor allem in langjährigen und sehr komplexen Projekten mitunter ein wenig verloren. Guter Hinweis, danke Internet und Scrum Guide.

Wir dürfen übrigens jetzt auch mal was weglassen. Wo das Sprint Planning eine extra Frage bekommen hat, darf das Daily komplett darauf verzichten. „Was habe ich gestern gemacht, was mache ich heute, was könnte mich an meiner Arbeit hindern?“ Entwicklungsarbeit, Denkarbeit – das lässt sich selten in Regeln packen, und dank Scrum muss das auch nicht sein: Einfach offen darüber sprechen, woran man arbeitet, wobei man Hilfe brauchen könnte, wo ein Impediment im Weg ist – das ist gesünder und zeitgemäßer.

Ebenfalls weggefallen ist der Begriff der „Estimation“, also der Schätzung, womit natürlich die Storypoints für spezifische Aufgaben gemeint sind. Das bedeutet allerdings nicht, dass Fibonacci-Folge, Planning Poker oder Dot Voting für immer begraben wurden: Sie wurden noch nie spezifisch im Scrum Guide erwähnt. Scrum soll aber weg von Zahlen, von groben Schätzungen, von Einteilung der Leistung in feste Zeitabschnitte. Stattdessen bewegen sich Scrum Teams dahin, den Fokus auf das Erreichen ihrer Ziele zu setzen. Das bleibt freilich etwas nebulös interpretierbar, denn schon betriebswirtschaftlich und zur sinnvollen Aufteilung von Aufgaben im Team werden Storypoints und T-Shirt-Größen bleiben. Es lässt sich aber nicht wegdiskutieren, dass solche Zeiteinteilungen immer auch eine gewisse Leistungsbeurteilung mit sich bringen, die in Scrum Teams eigentlich unerwünscht ist.

Le Grande Finale: Wieso Scrum oft nicht funktioniert, richtig eingesetzt aber mächtig ist

Scrum ist keine Lösung. Kein Allheilmittel. Keine Gelddruckmaschine. Keine Methodik. Nicht für jeden geeignet. Nicht für jedes Projekt geeignet. Nicht für alle Menschen gemacht. Scrum ist nicht geschaffen, um Leistung zu messen, um Stakeholder ruhigzustellen oder Geld zu sparen (wobei das ein angenehmer Nebeneffekt sein KANN). Scrum ist nicht unveränderlich, es ist nicht VUCA, es ist nicht kontrollierend. Scrum ist nicht für Projekte geschaffen.

Wer nur einen einzigen der obigen Punkte anders sieht, ist für Scrum vermutlich nicht geeignet, ohne seine Denkmuster infragezustellen (ja, so rum funktioniert das auch. Scrum kann für dich geeignet sein, du aber nicht für Scrum. Agile Methoden können für dein Projekt nicht passen, aber für dich wunderbar sein).

Scrum ist ein Baustein. Ein Werkzeug aus dem agilen Baukasten. Scrum ist für Menschen geschaffen. Scrum ist eine Leiter, eine Stufe, um Teams zu befähigen, in iterativen Prozessen Großes zu leisten. Scrum ist agil, aber kein Synonym für Agilität. Scrum wird oft falsch eingesetzt. Scrum wird ob seiner Einfachheit oft dahingehend unterschätzt, wie komplex es sein kann (wer sich mal durch das Jira eines Legacy-Projekts arbeitet, weiß wovon ich spreche).

Unternehmen, die Scrum indes gut einsetzen, sammeln Erfahrung, vertrauen auf ihre Mitarbeiterinnen und Mitarbeiter, sehen den Mehrwert von Teams, die sich wohlfühlen und sich wertschätzen. Ich empfehle den Film „Musterbrecher“ (kostenfrei auf YouTube zu sehen, wohin dieser Link führt) uneingeschränkt: Angestellte, die in psychologisch sicheren Umgebungen arbeiten, tauschen diese selbst für deutlich höhere Gehälter und viele andere Benefits nicht ein und bleiben jahrelang, oft ihre gesamte Karriere, bei einem Arbeitgeber, der so ein selbstbestimmtes, kooperatives und wertschätzendes Arbeiten ermöglicht.

Ein klein bisschen Eigenwerbung erlaubst du uns nach so einem langen Artikel doch bestimmt, ja? Cognizant Mobility arbeitet seit Jahrzehnten mit OEMs und hochrangigen Kunden, weil es auf genau diese Werte setzt. Transparenz, Überprüfbarkeit, Anpassung. Nicht nur dank Scrum – es gibt Teams mit und ohne Scrum-Framework (wobei die Mehrzahl nach Scrum arbeitet). Die agilen Werte indes begleiten das Unternehmen im Grunde immer, CEO Jörg Ohlsen arbeitet seit jeher nach der Devise, Mitarbeiterinnen und Mitarbeiter selbstorganisiert, eigenverantwortlich und unter Einhaltung komplett offener Kommunikation walten zu lassen.

Der Erfolg spricht für das Unternehmen, so wie Scrum für die Teams steht, die diesen Erfolg ermöglichen.

Na, also doch eine Erfolgsgeschichte, wer hätte es gedacht. Am Ende funktioniert Scrum ja doch.