Agiles Chaos? Vier Vorurteile über Scrum: wahr oder falsch?

Es ist schon ein paar Jahre her, als eine Geburtstagsfeier eines Freundes sich mir ins Gedächtnis einbrannte: Nach ein paar klassischen Kennenlern-Fragen („Was machst du so?“) stellten die Partygäste fest, dass Scrum ein gemeinsames Thema war. Und da fiel der Satz, der mir hängengeblieben ist: „Scrum wurde doch nur erfunden, damit Entwickler es endlich schaffen, miteinander zu reden.“

Diese zugespitzte Meinung wurde natürlich mit einem Augenzwinkern geäußert. Doch abgesehen von den impliziten Vorurteilen gegenüber Software-Entwickler*innen ist mir folgender Punkt aufgefallen: Scrum wird auf eine reine Kommunikationshilfe reduziert. Das entspricht nicht meinen Erfahrungen. Scrum kann viel mehr.

Illustration by Dovile Kietzmann www.dovile.de

Es war nicht das erste und nicht das letzte Mal, dass mir Vorurteile gegenüber Scrum und Agilität begegnen. Mit ein paar davon möchte ich hier aufräumen bzw. mir die ehrliche Frage stellen, welche vielleicht auch einen Funken Wahrheit enthalten könnten.

Kurz die reinen Fakten zu Scrum

Bekannt wurde Scrum Anfang der 2000er als eine agile Methode zur Softwareentwicklung. Der Kreis rund um Jeff Sutherland und Ken Schwaber formulierte im Agilen Manifest einige methodische Grundsätze, die eine schnellere und bessere Produktauslieferung versprechen. Gleichzeitig transportieren sie auch ein eigenes Mindset, das den Menschen in den Fokus rückt und Kollaboration in flachen Hierarchien anstrebt. Inzwischen hat Scrum nicht nur in der Softwareentwicklung Spuren hinterlassen. Und trotz aller Erfolge tauchen immer mal wieder Vorurteilen zu Agilität auf.

Scrum-Vorurteil 1: „Damit Entwickler endlich miteinander reden“

Das eingangs zitierte Vorurteil möchte ich hier als Erstes aufgreifen. Zunächst möchte ich klarstellen, dass Entwickler*innen keine unbeholfenen Nerds ohne Sozialkompetenz sind, die nie miteinander reden. Doch davon abgesehen: Was sagt die Bemerkung über Scrum aus? Ist die agile Methode ein rein soft-skill-orientiertes Kommunikationsmittel?

Zugegeben: Einige Scrum-Artefakte wie etwa die Sprint-Retrospektive dienen neben der fachlichen auch der zwischenmenschlichen Verständigung. Und die Autoren des Agilen Manifests betonen die Wichtigkeit von Face-to-Face-Kommunikation, Individuen und Interaktionen. Also ja: Als menschenzentrierte Methode fördert Scrum die Kommunikation im Team. Wird das Framework dadurch zu einer reinen Wohlfühl-Veranstaltung, bei der der Austausch unter Kollegen dem Selbstzweck dient? Mitnichten. Das Hauptziel besteht darin, Kundenbedürfnisse zu erfüllen und eine schnelle Auslieferung des (Software-)Produkts zu ermöglichen.

Zweifellos kann die verbesserte Kommunikation sich positiv auf das zwischenmenschliche Miteinander auswirken. Und warum sollte das etwas Schlechtes sein? Es gibt keinen Grund, das „miteinander Reden“ gering zu schätzen. Längst weiß man, wie wichtig psychologische Sicherheit bei der Arbeit ist. Scrum fördert sie.

Scrum-Vorurteil 2: „Es läuft gerade chaotisch. Aber wir sind halt agil!“

Diese Aussage ist mir bisher am häufigsten begegnet: Agilität wird mit einer chaotischen Arbeitsweise gleichgesetzt. Meistens kam die Äußerung von Personen, die erst seit Kurzem nach Scrum arbeiteten oder eine abgewandelte Form von Scrum anwendeten („Scrum light“). Dagegen ist nichts einzuwenden. Wichtig ist dennoch, zu verstehen, dass Scrum und andere agile Frameworks einer klaren Struktur folgen. Sie sind nicht chaotisch. Zwar sollen kurze Iterationen dazu dienen, auf geänderte Anforderungen schnell zu reagieren. Jedoch folgen die Aktivitäten einem klaren Release-Plan.

Daher würde ich empfehlen: Wenn euch im Arbeitsumfeld eine ähnliche Aussage zu Ohren kommt, lohnt es sich, genauer hinzuschauen: Sind die Projektziele klar und für alle sichtbar? Fühlen sich die Beteiligten sicher in ihrem Rollenverständnis? Sind Reihenfolge und Priorität der Aufgaben nachvollziehbar? Sobald der Begriff „agil“ herangezogen wird, um chaotisches Arbeiten zu legitimieren, kann es sehr gut daran liegen, dass nicht alle Teammitglieder richtig abgeholt und eingebunden wurden.

Scrum-Vorurteil 3: „Scrum ist ein Zeitfresser.“

Einige Menschen nehmen Scrum als eine sehr zeitintensive Methode wahr. Ja, es stimmt, dass Scrum einige Meetings vorsieht: Daily, Planning, Review, Retro, Estimation oder auch Backlog Refinement. Der Grund für die diversen Routinen ist jedoch keinesfalls Micro-Controlling, sondern Transparenz im Team. Der regelmäßige Austausch macht Hindernisse schneller sichtbar. Sie werden aus dem Weg geräumt, bevor sie Folgen nach sich ziehen, die viel mühsamer zu revidieren sind. Die gesteigerte Produktivität sollte die investierte Zeit mehr wieder wett machen.

Zugegeben: Schwierig wird es, wenn Personen nur einen geringen Teil ihrer Arbeitszeit in einem Scrum-Projekt mitwirken. Dies habe ich in Unternehmen erlebt, in denen einzelne Projekte agil umgesetzt werden. Beispielsweise ist dann die Abteilungsleiterin für Brand Management zu 20 % Mitglied eines Squads zur Website-Entwicklung. Für die individuelle Person lässt sich dieses Problem mit keinem Patentrezept lösen. Hier ist vielmehr die Ebene des Managements und der Organisationsentwicklung gefragt: Sollen die Mitarbeitenden in Parallelwelten arbeiten (Tagesgeschäft vs. agiles Projekt)? Oder sollte das Unternhemen ganzheitliche agile Transformation anstreben?

Scrum-Vorurteil 4: „Es reicht ja auch Scrum light.“

Richtig ist: Ein Tool oder eine Methode sollten immer so eingesetzt werden, dass sie für den konkreten Anwendungsfall den größten Nutzen anbieten. Es bringt nichts, dogmatisch auf bestimmten Prinzipien zu beharren, wenn diese nur dem Selbstzweck dienen. Also ist es vollkommen legitim, das Scrum-Framework abzuwandeln, wenn es für das Projekt und das Team besser passt. Bei angepassten Formen von Scrum – z.B. ohne Scrum Master, mit Weekly statt Daily, etc. – spricht man von „Scrum light“. Wenn die gewählte Scrum Light Form für alle zufriedenstellend ist, dann unbedingt weitermachen!

In der Praxis habe ich aber schon häufig beobachtet, dass Scrum so weit reduziert wird, dass von der Methode nichts bleibt, als dass Aufgaben an einem Board visualisiert werden. Wenn sich dann keine Verbesserung einstellte, fehlt wohl doch etwas. Unterschätzen Sie nicht, dass Agilität mehr als ein Werkzeug bietet, sondern auch ein eigenes Mindset mitbringt. Ihr volles Potenzial entfalten agile Frameworks mit der passenden Mentalität. Wird das Umdenken einfach übersprungen, bleiben die Veränderungen oft hinter den Erwartungen zurück.

Wenn ich diese vier Vorurteile noch einmal revuepassieren lasse, wird deutlich, dass Missverständnisse und Enttäuschungen oft dort entstehen, wo die methodische Neuerung vielleicht zu schnell erfolgt. Im Scrum-Guide weisen die Autoren selbst darauf hin, Scrum sei "simple to understand, but difficult to master."

Nach meiner Erfahrung kann eine agile Transformation dann gelingen, wenn deren Leitung dem Change Prozess genug Raum gibt und immer im Dialog mit den Mitarbeitenden bleibt. Warum ist die Methoden-Änderung wichtig? Was wollen wir gemeinsam erreichen? Was trägt jedes Teammitglied dazu bei? Wenn Sie hier gute Antworten liefern, wird sich jeder und jede mit der eigenen Tätigkeit identifizieren und eine gesteigerte Wertschöpfung erleben.

Und dann lasst uns statt den Scrum-Vorurteilen lieber die Erfolge als Gesprächsstoff auf Partys mitnehmen.