Scrum ist Medium, aber nicht Quelle der Probleme

Ihr kennt das: Mitarbeiter oder Leute in eurem Umfeld beschweren sich, dass Scrum nicht funktioniert, teilen Posts wie diesen (“Stop Doing Scrum! Scrum is Cancer!”) und sind oft sehr ungehalten, weil ihnen Scrum scheinbar den Arbeitsalltag und damit einen substantiell großen Teil ihres Lebens versaut.

Als Scrum Master aus Leidenschaft höre ich diese Hilferufe natürlich mit anderen Ohren. Einerseits verstehe ich die dargestellten Probleme, andererseits blutet mir das Herz, weil diese Probleme meist nichts mit Scrum zu tun haben und das Framework (und damit auch meine Berufsbezeichnung) geflamed werden für folgende Probleme:

1. Scrum baut auf Teams auf, und in Teams müssen gewissen Grundsätze herrschen, wie Vertrauen und Respekt, Mut und Offenheit, Engagement und Verantwortungsübernahme und eine gemeinsame Richtung, ein Arbeits-Fokus. Scrum beschreibt dies in den Scrum-Werten. Werden diese nicht eingefordert, ist es kein Scrum. Störenfriede innerhalb des Teams, die diese Werte verletzen, müssen damit konfrontiert werden. Wenn Kernpunkte des Teamworks wie Vertrauen, Konfliktfähigkeit und Verantwortungsübernahme nicht funktionieren, kann man mit den 5 Dysfunctions of a Team (von Patrick Lencioni) anfangen. Wenn man diese Dysfunktionen größtenteils beseitigt hat, funktioniert Scrum plötzlich wie angepriesen. Außer natürlich, dass es sich auch organisatorisch nicht um ein Team handelt. Ein Scrum-Team besteht aus mindestens drei Entwicklern, einem Product Owner und einem Scrum Master – ohne dass diese ihre Ressourcen teilen müssen.
2. Scrum wird oft ohne ausreichend qualifizierte Agilisten eingesetzt. Die Scrum-Zertifikate sind relativ wertlos, weil sie ausschließlich nachweisen, dass der Zertifizierte sich mit dem Framework auskennt – doch der Scrum Guide passt auf nur knapp 20 DIN-A4-Seiten. Wie wir aus dem Scrum Guide wissen verkörpert der Scrum Master eine echte Führungsrolle, und Führung ist mit Theorie unterfütterte Erfahrungssache. Führungserfahrung lässt sich kaum über einen Multiple-Choice-Test abfragen. Außerdem ist der Scrum Master ein Team Coach, und Coaching ist ein ganz eigenes, ausgesprochen anspruchsvolles Feld. Gibt man noch Empathie, Kreativität, eine fundierte Wissensbasis, Bescheidenheit, Konfliktfähigkeit und eine positive Grundhaltung für einen guten Scrum Master hinzu, sind diese Anforderungen schwer abprüfbar und – leider – selten erfüllt.
3. Scrum wird oft in einem Umfeld eingesetzt, in dem es nicht funktionieren kann. Es ist für Produktentwicklung vorgesehen – ohne Produkt(e) wird’s also schwer. Außerdem: Es kehrt die Top-Down-Command-and-Control-Hierarchie um, damit die Fachkräfte (am unteren Ende der Hierarchie-Kette), die sich mit den Herausforderungen am besten auskennen, die Lösungen und die dafür notwendigen Prozesse entwickeln können. Der “Wasserkopf” ist zwar länger in der Firma angestellt und/oder verdient mehr Geld, ist aber viel weiter vom Kunden und vom Produkt entfernt und kennt sich dementsprechend schlechter mit dem Problemfeld aus. Daher sollte das Management auch dem Scrum Team dienen (das sogenannte Servant Leadership), damit das Team seine Arbeit möglichst effektiv ausführen kann. Diese dienende Führung kann in Form von Staffing, Teamschnitt, Feedback und Organisationsgestaltung passieren. Servant Leadership ist leider auch nur selten gegeben, denn Führungspersonen steht oft ein zu großes Ego bzw. ein Mangel an Bescheidenheit im Weg.
4. Scrum erfordert persönliche Reife. Offenheit, Respekt, Selbstverpflichtung und Konfliktfähigkeit fallen nicht vom Himmel. Scrum verlangt, dass man den anderen wie einen erwachsenen Menschen behandelt, und sich wie ein selbstständiger, erwachsener Mensch benimmt. Wenn das Recruiting einen guten Job gemacht hat, sollte das kein Problem sein – haben wir es aber im Team mit egoistischen, hypersensiblen oder vertrauensgestörten Personen zu tun, die auch bisher in ihren Jobs immer nicht-eigenverantwortlichen Dienst nach Vorschrift abgeleistet haben, dann ist agiles Arbeiten mit Teamwork für diese klar überfordernd.

SCRUM ist Medium aber nicht Quelle der Probleme

Wie gesagt: für diese Probleme trifft Scrum keine Schuld. Zu viele Meetings? Wenn ihr keine Plannings, Reviews & Dailies machen wollt, dann macht ihr halt mehr Meetings mit anderen Namen, wo die Zusammenarbeit aber bestenfalls genauso schlecht klappt, oder ihr macht halt gar keine Meetings. Dann seid ihr komplett weg vom Teamwork, jeder bekommt seine Aufgaben (inklusive sinnloser Anforderungen) vom ahnungslosen Management, Mitdenken und Kreativität ist passé, jeder lebt in seiner eigenen Realität und Konflikte werden bestenfalls über passiv-aggressive E-Mails und Eskalationen nach oben ausgefochten, anstatt dass man in Retros mal ein unangenehmes Gespräch im Safe Space führt, was eine echte Lösung ohne “Geschmäckle” herbeiführen könnte. Wenn ihr neben dem Product Owner Team-externe Quellen habt, z. B. einen Teamleiter, einen Tech Lead, einen Chefarchitekten und einen CEO habt, die alle aktiv in die Arbeit des Teams eingreifen, dann habt ihr einen Wasserkopf und macht kein Scrum. Ein schlechtes Arbeitsklima wird ohne Scrum definitiv nicht besser, weil dieses Klima mit 100%iger Sicherheit nicht Scrum als Quelle, sondern nur als Medium hat. Korrelation statt Kausalität.

Der Scrum Master als Transformationstreiber

Wenn die aufgezählten Probleme gegeben sind, ist es der Auftrag des Scrum Masters, dafür zu sorgen, dass diese “Impediments” behoben werden. Aus meiner Erfahrung kann ich sagen, dass man als Scrum Master meist der Einzige ist, der diese Probleme angeht oder zumindest wahrnimmt, und dass man viel Eigeninitiative und sehr viele unterschiedliche Skills haben muss, um diese Beseitigung auch tatsächlich veranlassen zu können. Meine Vorerfahrung als Teamleitung und als Projektkoordinator haben mich jedenfalls sehr viel besser auf meine Aufgaben als Scrum Master vorbereitet, als der Scrum Guide und die Zertifizierungen das hätten tun können. Scrum Trainer Timon Fiddeke hat da sicher auch ein paar wichtige Impulse und Learnings gesetzt, und selbstverständlich habe ich auch von meinen agilen Kollegen bei Ascora, Thalia und WBS Training viel gelernt. Aber am Ende gibt es keine Ausbildung, die die notwendigen Skills strukturiert vermittelt.

SCRUM unterstützt Problembeseitigung

Wenn die Umstände aber passen, oder man mit ihnen Umgehen kann, dann wird die korrekte Anwendung von Scrum dazu führen, dass das Team lernt, sich selbst zu führen. Es wird mit steigender Effektivität das Produkt kundenzentriert in die richtige Richtung zu entwickeln – bei voller Transparenz. Scrum sorgt dafür, dass die Meetings minimalisiert, der Fokus maximiert und die Zeit des Teams an der echten Arbeit optimiert wird.

Wenn aber die oben genannten Probleme herrschen, wird Scrum über seine Rollen, über die Transparenz der Kommunikation und der Artefakte, seine Werte (Fokus, Respekt, Offenheit, Mut und Commitment) und nicht zuletzt über die Retrospektiven dafür sorgen, dass diese Schwierigkeiten eben nicht mehr unter der Oberfläche und hinter künstlicher Harmonie versteckt bleiben. Stattdessen entsteht Reibung, Impedements werden benannt und können endlich eskaliert werden. Dies bringt sicherlich den Verdacht auf, das SCRUM diese Probleme verursacht hat – es hat sie jedoch nur aufgedeckt.

Fazit

Am Ende ist es immer leicht, das agile Framework zu beschuldigen, wenn der Kollege unangenehm ist oder nicht mitzieht, wenn CEOs und Manager Micromanagement machen oder wenn der Scrum Master Ahnung hat von Programmierung, aber keine Ahnung von Moderation, Facilitation oder Leadership. Aber wie fast jede Platzierung von Schuld zementiert dieser das dysfunktionale System, statt den unangenehmen, menschlichen Konflikt zu suchen, der zur Lösung der wirklichen Probleme notwendig ist.

(Bild-Credit: Foto von JESHOOTS.COM auf Unsplash)