Foto: fizkes - shutterstock.com
Scrum gehört zu den Spitzenreitern unter den agilen Arbeitsmethoden. Mit 84 Prozent ist Scrum die führende Methode in Teams, wie eine internationale Studie zu agilen Ansätzen der Hochschule Koblenz in Zusammenarbeit mit der Deutschen Gesellschaft für Projektmanagement (GPM), dem europäischen Dachverband für Projektmanagement IPMA und der Scrum.org bestätigt. Bei einem Blick hinter die Kulissen mancher Scrum-Teams meint man allerdings, sich in der Tür geirrt zu haben.
Wo Scrum draufsteht, ist nicht immer Scrum drin. Vieles erinnert an Verhaltensweisen aus dem klassischen Projektmanagement. Es gibt Produktverantwortliche (Product Owner), die Aufgaben verteilen wie ein Projektmanager und so manch ein Daily-Stand-up, eine agile Zeremonie zum regelmäßigen Austausch im Team, gleicht eher einem Status-Update. Selbstverständlich ist jedes Team anders und Projekte haben ihre eigenen Anforderungen. Genau hier finden wir oft „Scrumbut“.
Was ist Scrumbut?
Laut dem Gabler Wirtschaftslexikon ist Scrum ein “Vorgehensmodell der agilen Softwareentwicklung, das davon ausgeht, dass Softwareprojekte aufgrund ihrer Komplexität nicht im Voraus detailliert planbar sind. Aus diesem Grund erfolgt die Planung nach dem Prinzip der schrittweisen Verfeinerung, wobei die Entwicklung des Systems durch das Team nahezu gleichberechtigt erfolgt“. Dieses Modell passt zwar für viele Teams, dennoch nicht für alle. Einige gehen dazu über einzelne Bestandteile von Scrum wie Zuständigkeiten, Events oder Artefakte anzupassen, nach dem Motto: “Wir verwenden Scrum, aber…”. Diese Modifikation nennt sich Scrumbut.
Lesetipp: Agile Softwareentwicklung - Scrum entfesselt Kreativität
Eine folgenreiche Entscheidung
Vergleichen wir Scrumbut als Modifikation mit einem Jailbreak beim iPhone. iOS, Apples eigens entwickeltes Betriebssystem, ist ein geschlossenes System, das aus guten Gründen nur bedingt personalisierbar ist und somit nur bestimme Funktionen zulässt. Warum? Für die optimale User Experience soll ein möglichst reibungsloser Betrieb gewährleistet sein. Zu Deutsch ist ein Jailbreak, ein Gefängnisausbruch. Auf die Technologie übertragen, beschreibt der Begriff die Modifikation des Betriebssystems, in diesem Fall iOS.
Wendet man das auf Scrum an, ist die Parallele die Erweiterung einer effizienten Methode, um den eigenen Handlungsspielraum zu erweitern. Das kann zum Problem für die Systemstabilität werden: mehr Abstimmungen werden notwendig, Projektverzögerungen treten ein, Komplexität und operatives Chaos folgen. Also genau genommen das Gegenteil von Agilität und Effizienz. Trotzdem können es viele Teams nicht bei der bereits bewährten Methode belassen. Beispiele für Scrumbut gibt es zahlreiche. Diese drei Modifikationen sind häufig anzutreffen:
"Wir verwenden Scrum, aber ohne ein Daily-Stand-up. Es ist zu zeitaufwändig, daher machen wir es einmal pro Woche.”
“Wir verwenden Scrum, aber der Produktverantwortliche teilt uns die Aufgaben zu.”
“Wir verwenden Scrum, aber wenn es dringende Aufgaben gibt, dann schieben wir unsere Sprintziele nach hinten.”
Die Wurzel(n) des Scrumbut-Problems
Viele Teams wollen Scrum nach dem Lehrbuch anwenden, doch wissen nicht wie. Es scheint für sie nur mit Anpassungen möglich. Tatsächlich machen rechtliche Gründe eine Abweichung vom Standard manchmal unausweichlich. Das ist jedoch eine Seltenheit. Drei der häufigsten Gründe, weshalb Teams zu Scrumbut greifen, sind:
1. Fehlende Voraussetzung
Unternehmen möchten Scrum implementieren, doch es fehlt ihnen häufig am notwendigen Fundament. Nehmen wir beispielsweise ein Team, das die meiste Zeit mit dem Löschen von unkalkulierbaren operativen Bränden im Produktivsystem verbringt. Scrum braucht einen gewissen Grad an Planbarkeit. Möchte man es dennoch implementieren, ist Scrumbut die Rettung: “Wir verwenden Scrum, aber wenn es dringende Aufgaben gibt, dann schieben wir unsere Sprintziele nach hinten." Scrumbut ermöglicht Scrum trotz fehlender Voraussetzungen zu implementieren. Möchten Unternehmen die bestmöglichen Startbedingungen für Scrum und den Transformationserfolg schaffen, sollten sie für stabile, agile Rahmenbedingungen sorgen.
2. Unrealistische Erwartungshaltung
Agile Arbeitsweisen sorgen für mehr Flexibilität und Schnelligkeit, so die Versprechen bei agilen Transformationen. Viele Mitarbeiter erwarten zeitnahe, sichtbare Erfolge. Ist Scrum eingeführt, sieht die Realität oft anders aus. Die Mitarbeiter beklagen beispielsweise, dass sie mehr Zeit in Besprechungen verbringen als mit der Erledigung ihrer Aufgaben und Kunden beschweren sich über Verzögerungen. Enttäuschung sowie Zweifel an der Methode und ihrer Anwendbarkeit machen sich breit. Ist weiterhin keine Besserung in Sicht, beginnen Teams nach Lösungen zu suchen, was bei Scrumbut endet. Eines der häufigsten Opfer der Modifikationen ist das Daily-Stand-up: “Wir verwenden Scrum, aber ohne ein Daily-Stand-up. Es ist zu zeitaufwendig, daher machen wir es einmal pro Woche.” Zeitsparender ist das allerdings nur auf den ersten Blick. Vorausgesetzt, dass das Daily-Stand-up kein verdecktes Status-Update ist, müssen die dort behandelten Informationen, Fragen und Problemstellungen auf andere Weise geklärt werden. Das braucht wiederum mehr Zeit.
Der Grund, dass Scrum die Erwartungen der Mitarbeiter zu Beginn oft enttäuscht, liegt weniger an der Methode als an unrealistischen Erwartungen. Wie im Sporttraining braucht Scrum kontinuierliche Übung, eine korrekte Technik und realistische Ziele. Zu Beginn einer neuen Sportart erwartet kaum jemand, dass nach ein paar Trainingseinheiten das Niveau jahrelanger Sportler erreicht wird - bei Scrum oftmals schon. Unternehmen können positiven Einfluss auf den Transformationserfolg nehmen, indem sie einen realistischen Zeithorizont und Referenzwerte kommunizieren.
3. Mangelhaftes Change Management
Agile Arbeitsweisen muss man mögen. Wer möchte nicht selbstbestimmt entscheiden und handeln? Was für viele agile Enthusiasten nach einer rhetorischen Frage klingt, ist es für andere nicht. So gibt es Mitarbeiter, die agilen Arbeitsweisen aus den unterschiedlichsten Gründen skeptisch gegenüberstehen. Das Problem ist nicht die Skepsis, sondern wie mit den Skeptikern umgegangen wird. Statt auf ihre Bedenken einzugehen, werden sie schnell als veränderungsresistent abgestempelt. Wer agil nicht gut findet, hat agil schließlich nicht verstanden. So geht mehr als nur Kommunikation auf Augenhöhe verloren. Skeptiker werden als Problem definiert und agiler Anpassungsdruck ausgeübt.
Druck erzeugt Gegendruck: "Jetzt erst recht nicht" ist daraufhin eine der häufigsten Trotzreaktionen. Reaktanz nennen Psychologen laut dem Gabler Wirtschaftslexikon das "Phänomen des Widerstands gegen wahrgenommenen Beeinflussungsdruck. Reaktanz tritt auf, wenn ein Individuum sich in seiner Meinungs- und Verhaltensfreiheit bedroht fühlt. Die Reaktanz wird um so intensiver, je größer der wahrgenommene Beeinflussungsdruck ist". So erhöht sich die Wahrscheinlichkeit, dass genau das Gegenteil erreicht wird und Projekte können nachhaltig Schaden nehmen.
Ein Beispiel für Scrumbut aus der Praxis
Bei der Einführung agiler Arbeitsweisen ist es nichts ungewöhnliches, dass die bisherigen Führungskräfte in ihrer neuen agilen Rolle als Product Owner oder Scrum Master ihre Kompetenzen überschreiten, indem sie typisches Managerverhalten an den Tag legen. Sie treffen weiterhin Entscheidungen oder verteilen Aufgaben, obwohl das in der Verantwortung des Teams liegt. Die Ursache des übergriffigen Managerverhaltens scheint schnell gestellt: ein fehlendes agiles Mindset. Doch ist das wirklich das Problem?
Stellen Sie sich vor, ein Meeting beginnt erst dann, wenn Sie den Raum betreten. Die Teammitglieder berichten Ihnen vom aktuellen Status der Aufgaben. Kein Schritt wird gemacht, ohne dass er von Ihnen vorher abgesegnet wurde. So geht es einigen Scrum Mastern oder Product Ownern. Täglich werden sie wie Führungskräfte behandelt, ohne es zu forcieren. Anfangs fällt es noch leichter, den Ball der Verantwortung an das Team zurückzuspielen. Schwieriger wird es, sich der aufgedrängten Führungsrolle über einen längeren Zeitraum zu entziehen. Fast unmöglich wird es, wenn noch eine Prise Stress, Projektverzug oder verärgerte Kunden hinzukommen.
Dieses Szenario kann eintreten, wenn zuvor agiler Anpassungsdruck auf die Mitglieder eines Teams ausgeübt wurde. Tag für Tag gegen den agilen Strom zu schwimmen ist anstrengend, doch nachgeben und etwas tun, wovon die Menschen nicht überzeugt sind, kommt nicht infrage. Es braucht eine energiesparende Lösung, um nicht ständig anzuecken und trotzdem seiner skeptischen Meinung treu bleiben zu können. Das begünstigt Scrumbut. Hinter den Worten “Wir verwenden Scrum, aber der Produktverantwortliche teilt uns die Aufgaben zu”, könnte sich somit tatsächlich ein Product Owner verbergen, der sich mit dem agilen Führungsverständnis schwertut. Oder die Aussage könnte die Überlebensstrategie eines Teams sein, um bewährte Rollen wie eine richtungsweisende Führungskraft mit in die agile Welt zu nehmen.
Lesetipp: Agile Führung - Die 7 Gewohnheiten des agilen Managers
Die zuvor beschriebenen Gründe sind ein Ausschnitt an möglichen Motiven für Scrumbut. Sie zeigen, dass Scrumbut immer eine Lösungsstrategie ist. Die Frage ist: für welches Problem? Ein tiefgehendes Verständnis der Situation ist notwendig, sonst fließt viel Zeit in Maßnahmen, die am Problem vorbeigehen.
Von Scrumbut zu Scrum
Teams verwenden Scrumbut, weil es ihnen nützt. Doch schnell bedingt eine Änderung die nächste und nach einiger Zeit finden sich Teams in einer selbst gestrickten Scrum-Version wieder, die weder agil noch hilfreich ist. Es fehlt an Ideen, um die Situation grundlegend zu verbessern, denn der hektische Alltag lässt kaum Zeit für Experimente und Projekte und Kunden erwarten Ergebnisse.
Diese drei Fragen können Teams helfen, sich aus der Verstrickung zu lösen und wieder mehr Orientierung und Kontrolle zu bekommen:
1. Was nützt uns Scrumbut?
Die meisten Antworten auf diese Frage offenbaren die wahrgenommene Alternativlosigkeit: “Es geht nicht anders”, “Wir haben das schon immer so gemacht” oder “Die Kunden erwarten das von uns”. Handlungsfähig kann ein Team erst dann werden, wenn die Beteiligten erkennen, dass sie sich selbst für Scrumbut entschieden haben und diese Entscheidung tagtäglich aufrechterhalten. Das Team muss aus der Opferrolle herauskommen und seinen Beitrag an der Situation erkennen. Wer eine Situation herbeiführt, hat auch die Macht sie wieder zu ändern.
2. Was kostet uns Scrumbut?
Jedes Element in Scrum hat eine Funktion und sie wegzulassen verursacht Kosten. Diese werden oftmals unterschätzt oder übersehen. Häufige Risiken bei Scrumbut, die Kosten verursachen können, sind Projektverzögerungen, Intransparenz oder die ständige Notwendigkeit weiterer Anpassungen. Ein zusätzlicher Faktor ist der Zeitraub aufgrund vermehrter Abstimmungen in Form von Besprechungen oder steigender Unterbrechungen durch E-Mails oder Chat-Nachrichten. Diese Punkte zu erkennen hilft, die Kosten der Entscheidung für Scrumbut klar zu beziffern, sie gegen den Nutzen abzuwägen und sich gegebenenfalls auf die Suche nach einer profitableren Lösung zu machen.
3. Was ist eine bessere Lösung?
Findet ein Team heraus, dass es zu sehr damit beschäftigt ist, Scumbut am Laufen zu halten, dann ist es an der Zeit, die Reißleine zu ziehen. Jetzt sind neue Ideen gefragt. Kreativitätstechniken helfen, diese zu entwickeln. Möchten Teams auf ihrem Weg zum Ziel systematisch begleitet werden, hat sich die mediative Teamentwicklung bewährt. Sie harmoniert besonders mit agilen Ansätzen, da sie ebenfalls iterativ arbeitet, auf Empowerment setzt und Teams dabei unterstützt, zielführende Lösungen zu entwickeln und diese im dynamischen Tagesgeschäft umzusetzen. So können Teams systematisch den agilen Erfolgskurs einschlagen. (bw)