Chancen und Risiken von Scrum erkennen

Im Folgenden sollen die Chancen und Risiken von Scrum genauer angeschaut werden. Der Scrum-Prozess bietet ohne Zweifel gerade bei Vorhaben mit großer Unsicherheit und Komplexität zahlreiche Chancen. Die Prinzipien von Scrum können zu einer stärkeren Kundenorientierung, effektiveren Zielerreichung, geringeren Kosten sowie zu einer höheren Produktivität mit einem schnelleren Durchlaufen des Projektes führen. Zudem werden Änderungen und Kundenwünsche frühzeitig erkannt sowie vorab unbekannte Risiken im Projektablauf schnell identifiziert. Zugleich wird die Kommunikation im Projektteam gestärkt, die Motivation und Verantwortung einzelner Teammitglieder gesteigert sowie der Planungs-und Dokumentationsaufwand gemindert.

Um diese Chancen zu nutzen, bedarf es der konsequenten Umsetzung der Prinzipien und Vorgehensweise von Scrum. Eine Kombination aus Scrum-Elementen mit dem traditionellen Projektmanagement ist zwar theoretisch im Einzelfall möglich, kann aber auch zu Verwirrungen und Konflikten führen bzw. die Potenziale von Scrum werden nicht ausgenutzt.

Grundsätzlich ist der Scrum-Prozess nicht auf Unterbrechungen ausgelegt. Das ungestörte und zeitlich klar fixierte Durchführen der Sprints ist ein wesentliches Element für den Erfolg. In der Praxis können aber allein durch das längere Warten auf Feedback von Kunden/Sponsoren bzw. Entscheidungsträgern im Unternehmen oder auch durch das Warten auf eine externe Leistung Unterbrechungen auftreten, die den Scrum-Prozess erheblich stören. Da Scrum dieses Feedback in kurzen Abständen erfordert, kann es wiederum gerade dadurch viele ungewollte Unterbrechungen geben.

Unterbrechungen des Arbeitsablaufs kommen weiterhin bei räumlich verteilten (internationalen) Teams häufig vor. Scrum lebt von einem unterbrechungsfreien Ablauf und einem face-to-face-Kontakt der Teammitglieder einschließlich Scrum-Master und Product-Owner. Trotz der zahlreichen Möglichkeiten der modernen Informations- und Kommunikationstechnologien (Video-Chats, Collaborative Software etc.) ist eine räumlich enge und intensive Zusammenarbeit zwingend erforderlich, um das Prinzip Kommunikation vor Dokumentation im Projekt tatsächlich auch zu leben. Dies ist in der Praxis nicht immer der Fall.

Eine weitere latente Gefahr bei Scrum ist die fehlende Verknüpfung mit der strategischen Ebene. Zwar ist – wie oben skizziert – eine permanente Iteration mit dem Portfolio-Backlog und einer ggf. Neuanpassung der Product-Vision explizit vorgesehen, im Tagesgeschäft kann aber durch die inkrementelle Vorgehensweise und die Just-in-time-Planung der Blick auf das „Big Picture“ schnell verloren gehen. Eine Methode, die das verhindern kann, ist das oben vorgestellte Story-Mapping.

Die inkrementelle Vorgehensweise hat auch den weiteren Nachteil, dass bestimmte Abhängigkeiten zwischen einzelnen User-Storys oder Aufgaben nicht oder nur unzureichend berücksichtigt werden (können). Bei der Sprint-Planung können z. B. durch die Things-That-Matters-Matrix und durch das Story-Mapping solche Abhängigkeiten erkannt werden, gerade wenn – wie bei Scrum – die Aufgabenplanung auch die Fachexperten durchführen. Allerdings können gerade diese hoch-spezialisierten Fachexperten disziplinübergreifende Abhängigkeiten (unbewusst oder sogar bewusst) ignorieren und Querschnittsaufgaben vernachlässigen. Zudem zeigen sich Abhängigkeiten nicht nur auf technischer Ebene bei der Betrachtung von wenigen hoch-priorisierten User-Storys, sondern kundenrelevante Abhängigkeiten sind erst mit dem Blick auf das „Big Picture“ erkennbar, das – wie schon erläutert – ggf. bei Scrum etwas aus dem Blick gerät. Hier sei allerdings nochmals auf das Story-Mapping hingewiesen.

Nicht immer lassen sich des Weiteren User-Storys bilden, die ein Testen (mit dem Kunden) ermöglichen bzw. die zu einem auslieferungsfähigen Produktinkrement führen. Bei Produkten, die modular in einzelne funktionsfähige Elemente aufgebaut werden können, wie z. B. bei Software, ist Scrum sehr gut anwendbar. Bei Produkten mit einer integralen Produktarchitektur, wie z. B. in der Prozessindustrie (Lebensmittel, Chemie-, Pharmaindustrie), ist die Zerlegung des Produktes in einzelne funktionsfähige Inkremente nur bedingt sinnvoll bzw. möglich. Scrum wäre hier weniger für Produkt- als vielmehr für Prozesse geeignet, die wiederum in einzelne Prozessschritte – sinnvoll im Sinne von Scrum – zerlegbar sind.

Die vielen Stakeholder von Projekten erfordern häufig zu einem sehr frühen Zeitpunkt klare Aussagen zu den Planungsparametern (Qualität, Zeit, Kosten), um beim Portfoliomanagement Projekte miteinander vergleichen zu können. Außerdem fordern die Entscheidungsträger umfangreiche Dokumentationspflichten und ein permanentes Projektcontrolling am besten entlang von Kennzahlen ein. Dies kann und will Scrum nicht liefern. Scrum geht davon aus, dass man aufgrund der hohen Unsicherheit belastbare Informationen zu den Planungsparametern erst im Laufe des Projektes bekommt. Dokumentation soll schlank und weniger der Rechenschaft als vielmehr der Kommunikation dienen. Wenn aber keine klaren Aussagen über die Planungsparameter vorab möglich sind und Controlling „anders“ verstanden wird, kann die Akzeptanz bei wichtigen Entscheidungsträgern für das Projekt fehlen bzw. zu Irritationen führen.

Die just-in-time Planung kann auch dazu führen, dass Entscheidungen immer weiter aufgeschoben werden mit dem Hinweis, dass ja noch Ergebnisse aus einem Sprint fehlen. Diese „Aufschieberitis“ kann dann mehr Schaden anrichten, als dass sie durch eine bessere Planung einen Nutzen verschafft.

Scrum ist explizit darauf ausgelegt, dass es Änderungen geben wird. Die Art der Vorgehensweise macht quasi die Berücksichtigung von Änderungen notwendig bzw. Änderungen sind sogar erwünscht. Dies ist für viele Entscheidungsträger im Unternehmen schwer zu akzeptieren. Sind diese Änderungen zudem extrem teuer und aufwendig, sollte vorab im Sinne des traditionellen Projektmanagements ein Projekt gründlich durchgeplant werden. Hier kann Scrum mit seiner just-in-time Planung sogar erhöhte Risiken verursachen.

Mit Scrum sind auch personelle Risiken verbunden. Bei der Zuweisung der Rollen in Scrum kann es zu Konflikten kommen. Die Rollen von Scrum sind zwar klar definiert und umfangreich. In der Praxis kann es allerdings zu einer Kombination von Rollen in einer Person kommen, sodass z. B. Product-Owner und Scrum-Master von einer Person übernommen werden. Der Grund kann z. B. in Kapazitätsengpässen (insbesondere bei kleinen Unternehmen) liegen oder man will eine Person aufgrund ihrer Kompetenz und ihres Status mit mehr Macht im Scrum-Prozess ausstatten. Mit den Aufgaben der einzelnen Rollen sind aber schon je eine Person komplett ausgefüllt. Eine Zuordnung von Vollzeitstellen für diese Rollen ist in Unternehmen schwierig. Zudem können aufgrund der Aufgaben Interessenskonflikte entstehen, wenn der Product-Owner die Interessen der Kunden/Stakeholder und der Scrum-Master die Interessen des Teams in einer Person glaubwürdig vertreten müsste. Des Weiteren können die Rollen in Scrum als (auf den ersten Blick) nicht karrierefördernd angesehen werden, da sie (noch nicht) anerkannt sind. Mit der Position des Projektleiters mit Weisungskompetenzen gegenüber Mitarbeitern wird mehr Tradition und Prestige gerade in größeren Unternehmen verbunden. Die Scrum-Rollen können hier als karrierehemmend und rückstufend (aus Unwissenheit und fehlender Bekanntheit) empfunden werden, zumal es in Scrum keine Job-Titel sondern nur Rollen gibt.

Bei einem eingespielten, harmonischen Team kann Scrum hohe Effizienzvorteile bieten. Wie bei jedem Projektmanagement-Ansatz können aber persönliche Konflikte im Team ein Scrum-Vorhaben zum Scheitern bringen. Dabei kann das Potenzial für Konflikte durch die Prinzipien und Regeln von Scrum durchaus deutlich höher sein. Das Prinzip der Selbstorganisation des Teams erfordert Personen, die mit dieser Freiheit und Verantwortung umgehen können. Gerade Personen aus einem traditionellen Projektmanagement-Umfeld akzeptieren zwar die Arbeitsverteilung durch einen (ranghöheren) Projektleiter, sind aber mit einer (konsensbasierten) Selbstorganisation überfordert. Zudem können dominante Teammitglieder dieses Prinzip für ihre eigenen Zwecke ausnutzen. Die wenigen Regeln von Scrum sind grundsätzlich immer eine Gefahr, dass dies von einigen Teammitgliedern ausgenutzt wird. Die vielfältigen Feedback-Schleifen, die es bei Scrum in kurzen Abständen gibt, sind auch nicht bei jedem Teammitglied beliebt. Hier besteht die Gefahr, dass sich einzelne Teammitglieder auf Kosten anderer profilieren wollen. Letztlich können auch die (wenigen) strikten Regeln wie z. B das Timeboxing von Einzelnen als zu starr, als ein unnötiges Korsett oder sogar als Entmündigung empfunden und damit nicht akzeptiert werden. Offene und verdeckte Konflikte im Team können hier die Folge sein.

Ein Erfolgsfaktor bei Scrum ist die transparente Kommunikation zwischen den Teammitgliedern und vor allem zu den Kunden bzw. Nutzern der Projektergebnisse. Der Kunde/Nutzer wird sehr detailliert im Projektverlauf eingebunden, damit dieser Änderungswünsche schnell formulieren kann. Gerade bei Projekten mit einer hohen Unsicherheit ist dieses Vorgehen zwar grundsätzlich vorteilhaft, aber es besteht bei dieser hohen Transparenz gegenüber (externen) Kunden/Nutzer immer die Gefahr des Know-how-Abflusses. Letztlich kann diese Gefahr über vertragliche Reglungen nur bedingt reduziert werden, sondern erfordert ein hohes Maß an Vertrauen zwischen Unternehmen und den eingebunden (externen) Kunden/Nutzern. Die Gefahr ist allerdings weniger relevant, wenn der Kunde über kein spezifisches Know-how verfügt (dies liegt insbesondere bei Endkunden häufig nicht vor) und/oder der Kunde kein (geschäfts-)Interesse hat, in irgendeiner Weise in Konkurrenz mit dem Unternehmen zu treten.

Scrum fordert die Selbstorganisation der Projektbeteiligten. Dies ist bereits – wie erwähnt – auf Einzelprojekt-Ebene mit einem überschaubaren Projektumfang durchaus herausfordernd. Je umfangreicher ein Projekt wird, umso mehr kann dieses Prinzip an seine Grenzen stoßen. Ferner kann es bei der Koordination von mehreren Scrum-Projekte im Rahmen dieser Selbstorganisation zu vielfältigen Problemen und Konflikten kommen. Aus diesen Gründen kann somit die Skalierbarkeit von Scrum(-Projekten) begrenzt sein. Da Scrum außerdem durch seine flexible Vorgehensweise eine Standardisierung der Planung und Durchführung nicht vorsieht, können somit mögliche Skaleneffekte bei der Planung und Durchführung von mehreren Projekten nicht realisiert werden. Dies schränkt die Skalierbarkeit zusätzlich ein.

Letztlich können die verfolgten Prinzipien und Regelungen bei Scrum nicht zur (erfolgreich etablierten) Unternehmenskultur passen. Gleichwohl könnte allein schon die kritische Auseinandersetzung mit der eigenen Unternehmenskultur – anlässlich einer möglichen Implementierung von Scrum – wertvolle Anregungen liefern.

Einige der mit Scrum (vermeintlich) verbundenen Risiken sind durch eine Einführung im Sinne eines Change-Prozesses und durch die konsequente Beachtung der Prinzipien von Scrum behebbar. Letztlich bedarf es einer Abwägung – ggf. in Form eines Pilotprojektes – ob Scrum in der eigenen Organisation sinnvoll und Erfolg versprechend ist.

Mehr über Scrum erfahren Sie im Management-Handbuch Innovation von Müller-Roterberg.