Wir alle kennen sie, die Organisationsmythen. „Neue Mitarbeiter sind die einzigen, die einen Kulturwandel herbeiführen können“. Stimmt das, oder ist es viel wahrscheinlicher, dass die derzeitigen Mitarbeiter dazu beitragen? „Manager treffen rationale Entscheidungen“. Manager sind oft für schwierige Entscheidungen verantwortlich, aber geschieht dies aufgrund von Logik oder Gefühl? Bei fast allen meinen Schulungen tauchen solche Scrum-Mythen auf, oder sind sie in Wirklichkeit keine Mythen, sondern Fakten? In diesem Beitrag möchten wir das herausfinden.
#1 Scrum-Mythos: Scrum funktioniert nur bei IT-Projekten gut.
#2 Scrum-Mythos: Scrum funktioniert nur bei großen Projekten mit Vollzeitmitarbeitern.
#3 Scrum Mythos: Scrum kann für alle Projekte verwendet werden.
Ähnlich wie in der Fernsehsendung MythBusters werden wir herausfinden, ob die Scrum-Mythen wahr sind oder ob es sich um urbane Legenden handelt. Werden die Scrum-Mythen bestätigt, entlarvt oder als plausibel definiert? Bevor wir beginnen, möchte ich Sie bitten, zunächst selbst zu überlegen und dabei gleich Ihr Scrum-Wissen zu testen. Schreiben Sie für sich selbst auf, welche Scrum-Mythen Sie als wahr, falsch oder plausibel definieren würden.
1. Scrum funktioniert nur für IT-Projekte
Jeff Sutherland, einer der Begründer von Scrum und dem Scrum Guide, erklärt die Ursprünge von Scrum in seinem Buch The Art of Doing Twice the Work in Half the Time. Sutherland wendete Scrum bei Softwareprojekten an, die länger und teurer waren als zuvor geschätzt. Als er diesen Unternehmen bei der Einführung von Scrum half, sorgte er dafür, dass in wenigen Wochen mehr funktionierende Software zur Verfügung stand, als in den Jahren zuvor an dem Projekt gearbeitet worden war. Scrum verhalf zu schnell testbarer Software anstelle von einem Code, der erst ganz am Ende eines Projekts verknüpft und damit getestet werden konnte.
Nun wird oft die Frage gestellt, ob Scrum nur auf IT-Projekte angewendet werden kann, weil es bei Software relativ einfach ist, in kurzer Zeit etwas Funktionierendes zu produzieren. Schließlich kann man beim Programmieren die Website am Ende des Tages aktualisieren, während bei einem Auto nicht alle 24 Stunden ein brandneues Modell aus der Fabrik rollt. Dafür braucht man eher ein Jahr. Würde sich der Scrum-Mythos, dass „Scrum nur für IT-Projekte funktioniert“, bestätigen?
Glücklicherweise spielt es keine Rolle, dass Sie erst nach einem Jahr über endgültige Ergebnisse verfügen. Das Schöne an Scrum ist nämlich, dass Sie in der Zwischenzeit bereits ein wertvolles Produkt (MVP) liefern, das Sie testen können. Volkswagen muss nicht auf das Ende des Projekts warten, um sein neues Auto zu prüfen. Nein, sie können auch in der Zwischenzeit prüfen, indem sie nach jedem Sprint einen kleinen Teil testen. Ein Beispiel: Volkswagen möchte ein neues Armaturenbrettsystem in einem Auto einführen, das im nächsten Jahr auf den Markt kommen soll. Wie würden sie dann vorgehen? Zum Beispiel könnte man das verbesserte Armaturenbrett in einen aktuellen Volkswagen einbauen (sozusagen mit Klebeband). Sie verwenden dann Prototypen und können auf diese Weise in der Zwischenzeit das Feedback der Stakeholder einholen. Das zeigt, dass Scrum auch für Non-IT Projekte gut funktionieren kann.
Fazit 1. Scrum-Mythos: Scrum funktioniert nur für IT-Projekte: Widerlegt
2. Scrum eignet sich nur für große Projekte mit Vollzeitkräften
Können Sie Scrum anwenden, wenn Sie Lehrer sind, 26 Stunden unterrichten, 10 Stunden Verwaltungsarbeit leisten und 4 Stunden pro Woche übrig haben, um an einem Projekt zu arbeiten? Können Sie Scrum anwenden, wenn es in Ihrem Team 6 Vollzeitkräfte und drei Teilzeitkräfte gibt, die nur einen Tag pro Woche arbeiten?
Wie Sie mit Teilzeitkräften während eines Sprints umgehen wollen, ist in jeder Organisation anders, und es gibt keine Scrum-Handbücher dafür. Überlegen Sie, was in Ihrem Team funktioniert. Testen Sie es. Und evaluieren Sie die Entscheidung und passen Sie die Arbeitsvereinbarungen bei Bedarf an. Natürlich gibt es einige Dinge zu beachten:
- Prüfen Sie in dem Sprint Planning, wie groß die Kapazität des Teams ist. Wie viel Zeit haben wir als Team insgesamt, die wir tatsächlich für das Projekt aufwenden können?
- Wenn Teammitglieder nicht am Daily Scrum teilnehmen können, wie stellen wir dann sicher, dass sie trotzdem informiert werden?
- Sprint Planning, Sprint Review und Retrospektive sollten so geplant werden, dass das gesamte Team anwesend ist.
Gerade weil Scrum eine gute Koordination und Kommunikation innerhalb eines Teams erzwingt, funktioniert es sehr gut, Scrum mit Teilzeitkräften anzuwenden.
Fazit 2. Scrum-Mythos: Scrum funktioniert nur bei großen Projekten mit Vollzeitmitarbeitern: Widerlegt
3. Sie können Scrum für alle Projekte anwenden
Wenn Sie die Zeitung aufschlagen, sehen Sie Beispiele für alle möglichen Projekte: Die Restaurierung des Doms in Köln oder eine elektronische Patientenakte, die Ärzten und Patienten im Gesundheitswesen helfen soll. Vielleicht haben Sie auch zu Hause ein Projekt am Laufen: eine Renovierung, Sommerferien in drei verschiedenen Ländern mit öffentlichen Verkehrsmitteln oder die Organisation eines Kinderfestes für Ihren Sohn oder Ihre Tochter.
Die Frage ist: Kann man Scrum für all diese Projekte verwenden oder sind andere Frameworks dafür besser geeignet? Um diesen Scrum-Mythos zu überprüfen, können wir am besten das Cynefin Framework oder die Stacey Matrix heranziehen. Das Cynefin-Framework besteht beispielsweise aus vier Quadranten: einfach, kompliziert, komplex und chaotisch.
Einfach: Angenommen, Sie stehen auf und wollen mit dem Fahrrad zur Arbeit fahren. Leider stellen Sie fest, dass Ihr Reifen platt ist. Was sollen Sie tun? Reparieren Sie Ihr Fahrrad selbst oder bringen Sie es in einen Fahrradshop. Brauchen Sie dafür mehrere Scrum-Meetings? Nein. Für ein einfaches Projekt erfordert Scrum zu viel Zeit und verursacht zu viel Aufwand.
Kompliziert: Stellen Sie sich ein kompliziertes Projekt als operative Prozesse vor. Denken Sie zum Beispiel an den Kundendienst von amazon.de. Wenn ein verärgerter Kunde anruft, weil der Spiegel, den er gekauft hat, einen Kratzer hat, muss der Kundendienst eine Lösung finden. Dazu gehören mehrere Aktionen wie die Rücksendung des Spiegels und die Zusendung eines neuen Spiegels (einschließlich aller damit verbundenen E-Mails). Dies ist ein Beispiel für ein kompliziertes Problem, bei dem Sie sich fragen sollten, ob Sie Scrum anwenden wollen. Tatsächlich ist Scrum für die operative Arbeit weniger geeignet (u. a. wegen des Aufwands), und dafür ist man mit Kanban besser bedient. Es gibt immer ein Gleichgewicht zwischen dem Grad der Gewissheit, wie etwas aufgebaut werden soll, und dem Grad der Übereinstimmung zwischen den Stakeholdern, was das Ergebnis sein soll. In dem Artikel über die Stacey Matrix sehen wir uns genauer an, wie Scrum für eine komplizierte Situation geeignet sein kann.
Komplex: Denken Sie zum Beispiel an ein Reisebüro, das 14 neue Reisen vermarkten und bewerben möchte. In diesem kreativen Prozess wissen Sie noch nicht genau, wie das Endergebnis aussehen wird und wie Sie es abholen werden. Welche Hotels, Restaurants und Aktivitäten wählen wir aus? Was ist mit den örtlichen Führern, der Kultur und den Gesetzen und Vorschriften? Wie transportieren wir uns von Ort A nach B und wo kann der große Reisebus parken? Hier ist Scrum am leistungsfähigsten. Schließlich berät man sich in einem multidisziplinären Team jeden Tag darüber, wie es uns geht, und die Vermarkter, Geschäftsentwickler und Produktentwickler können sich darüber abstimmen, wie die Touren am besten gestaltet werden können.
Chaotisch: Auf ein Erdbeben, einen Krieg oder eine Pandemie kann man sich nicht ohne weiteres vorbereiten. Vorgefertigte Protokolle sind darauf vorbereitet, aber in dem Moment, in dem es passiert, sind Ursache und Wirkung oft schwer zu bestimmen. Es geht dann darum, zu handeln, zu erkennen und zu reagieren. Hier spielen Frameworks wie Design Thinking eine gute Rolle. Die Beschäftigung mit dem eigentlichen Problem sorgt letztlich für die richtige Lösung.
Fazit 3. Scrum-Mythos: Scrum kann man für alle Projekte anwenden: Widerlegt
Wie bei der wissenschaftlichen Herangehensweise in Mythbusters wollen Sie nicht alles für wahr halten, sondern selbst Fragen stellen, testen und daraus lernen. Schauen Sie sich daher immer genau die spezifische Situation an, in der Sie und Ihr Team sich befinden. Bei Ihrer Arbeit als Scrum Master, Product Owner oder Entwickler wollen Sie Annahmen so früh wie möglich überprüfen, damit Ihre Projekte nicht länger und teurer werden als vorher geschätzt.
