10 Scrum-Irrglauben, denen Sie keinen Glauben schenken sollten
In einem Umfeld, in dem Scrum wenig oder gar nicht bekannt ist, werden wir oftmals mit fest zementierten Überzeugungen und Aussagen konfrontiert, die uns aufhorchen lassen. "Bei uns funktioniert Scrum nicht!", "Mit unseren Kunden ist es nicht möglich, Scrum durchzuführen!" oder "Scrum ist für Großprojekte nicht geeignet!", um nur einige mögliche Beispiele dieser Dogmen zu nennen.
Es gibt viele Missverständnisse und Annahmen, die sich auf die Verwendung von Scrum beziehen. Kommt dies etwa dadurch, dass das gesamte Rahmenwerk mit einer Beschreibung der Regeln, Werte, Rollen, Events und Artefakte mit nur 13 Seiten auskommt [1]? Vielleicht. Nicht umsonst schreiben Ken Schwaber und Jeff Sutherland in ihrer Definition von Scrum, dass es leichtgewichtig, einfach zu verstehen und schwierig zu meistern ist.
Der Spielraum an Ausgestaltung bewegt sich eben um diese wenigen festgeschriebenen Regeln. Da tut es doch auch nicht weh, sich etwas vom "Glauben" zu lösen und eigene Glaubenssätze ins Leben zu rufen. Scrum in seiner Reinform durchzuführen ist sehr schwer und nicht weit verbreitet. Schon beim Lesen des Scrum-Guides wird deutlich, was wir meinen:
- Ein cross-funktionales Team von 5-9 Personen, das alle Fähigkeiten besitzt, um das Produkt ohne Abhängigkeiten zu Dritten zu liefern.
- Der Scrum Master agiert als Servant Leader und kümmert sich um die Verbreitung und Kenntnis von Scrum in der gesamten Organisation.
- Der Product Owner trifft eigenständig die Business-Entscheidungen und ist Vollzeit für das Team ohne weitere Abhängigkeiten verfügbar.
- Am Ende eines Sprints werden "Potentially Shippable"-Lösungen ausgeliefert oder der Sprint war nicht erfolgreich.
Dies sind nur einige Beispiele, um zu verdeutlichen, was wir meinen, wenn wir von einer reinen Scrum-Implementierung sprechen.
Einige dieser Glaubenssätze, die wir in unserer Arbeit in Kundenprojekten oder Scrum-Einführungen immer wieder antreffen, haben wir im nachfolgenden Artikel aufgeführt. Diese später wieder loszuwerden, ist oftmals nur mit viel Mühe und Schmerzen verbunden.
1. Irrglaube: Lasst uns Scrum nutzen und alles wird besser
"Unser Wasserfall-Ansatz hat ausgedient. Wenn wir Scrum nutzen, dann lösen wir unsere vorherigen Probleme im Handumdrehen."
Eines der größten Probleme, die Scrum unserer Meinung nach anhaften, ist, dass es nicht als Rahmenwerk verstanden wird, sondern als Ersatz für bereits im Einsatz befindliche Projektmanagement-Methoden und etablierte Prozesse.
Scrum beseitigt keine Probleme, sondern macht sie sichtbar.
Die Versprechen, die bei der Einführung von Scrum gemacht werden, sind mannigfaltig und lauten werbekräftig "schneller", "pünktlich", "einfach" oder "Problemlöser". Dadurch entsteht bei vielen Managern oder Führungskräften oftmals die Annahme, dass mit Scrum gegenüber den plangetriebenen Methoden in kürzerer Zeit mehr erreicht werden kann. Die Wünsche, die von Unternehmen geäußert werden, lauten nicht "Wie können wir bessere Lösungen gemeinsam mit unseren Kunden entwickeln und diese größtmöglich zufriedenstellen?" oder "Was müssen wir tun, damit unsere Mitarbeiter selbständig und motiviert gesteckte Ziele erreichen?". Es werden eher Fragen gestellt wie "Wie können wir effektiver werden?" oder "Wie können wir Liefertermine einhalten?". Diese Fragen setzen leider die falsche Grundlage für den Einsatz von Scrum.
"Scrum: Ein Rahmenwerk, innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit höchstmöglichem Wert auszuliefern." [1]
Laut Definition von Scrum liegt der reale Wert nicht im "höher", "schneller" oder "besser als Wasserfall" sondern in der Auslieferung von Lösungen, die den Kunden zufriedenstellen. In Kombination mit den zugrundeliegenden Scrum-Werten (Selbstverpflichtung, Mut, Fokus, Offenheit und Respekt), die für jedes Scrum-Team essentieller Bestandteil der Team-Genetik werden müssen, ergibt sich ein Kraftpaket, mit dem Teams in der Lage sind, sich auftretenden Problemen zu stellen und gemeinsam mit dem Kunden zu erarbeiten, was dieser als essentiell empfindet.
Dabei ist wichtig, zu verstehen, dass Scrum keine Probleme beseitigt, sondern diese sichtbar macht. Scrum ist wie ein Pümpel, der einer Organisation übergestülpt wird und der zu Tage fördert, was ansonsten niemand sehen möchte.
2. Irrglaube: Mit Scrum haben wir viel mehr Probleme
"Scrum funktioniert bei uns nicht."
Manchmal werden wir zu geplanten Projekten gefragt, wie man diese sinnvoll angehen könnte und oft ist unsere Antwort: "Habt ihr schon mal über Scrum nachgedacht?". Plötzlich blicken wir in versteinerte Gesichter und fragen uns, ob wir etwas Falsches gesagt haben. Auf Nachfrage hören wir dann "Scrum funktioniert bei uns nicht, damit haben wir viel mehr Probleme als vorher!".
Hier ist also vorsichtiges Herantasten gefragt: "Erzählt mal, was habt ihr ausprobiert? Welche Probleme sind aufgetreten?". Die Antworten lassen sich in der Regel in zwei Kategorien einteilen:
- Kategorie 1: Scrum wurde halbherzig eingeführt (wenn überhaupt)
Das Scrum-Framework ist darauf ausgelegt, dass man es als Ganzes einsetzt, weil die einzelnen Teile ineinandergreifen und sich gegenseitig ergänzen. Wenn nur einzelne Teile genutzt werden (z. B. nur Standups, aber keine Plannings und keine Retrospektiven), fehlen letztendlich wesentliche Bestandteile. Dann ist es kein Wunder, wenn der Eindruck entsteht, dass Scrum nicht funktioniert. - Kategorie 2: Scrum wurde richtig eingeführt, aber plötzlich tauchen viele Probleme auf, die vorher nicht da waren.
Hand auf’s Herz: Waren die Probleme vorher wirklich nicht da? Oder wurden sie nur irgendwie umschifft oder ignoriert und durch die plötzliche Transparenz an die Oberfläche gespült?
Der Scrum-Guide sagt dazu Folgendes: "Scrum macht die relative Wirksamkeit Ihres Produktmanagements und Entwicklungsvorgehens sichtbar, so dass Sie sich verbessern können."[1]
Und dass Probleme jetzt plötzlich sichtbar werden und man mehr oder weniger gezwungen wird, sich damit auseinanderzusetzen, sehen wir eher als einen großen Vorteil an, denn jetzt kann man etwas dagegen tun und versuchen, sie dauerhaft zu lösen. Denn wenn wir jetzt diese Probleme angehen, kann Scrum zu einem Geschwindigkeitsschub führen, da wir flexibler auf Unwägbarkeiten, neue Erkenntnisse oder Wünsche reagieren können.
3. Irrglaube: Mit Scrum sind wir schneller
"Mit Scrum erreichen wir unsere Ziele in kürzerer Zeit."
Scrum als Rahmenwerk gibt uns die Kraft, einen agilen Entwicklungsprozess auf die Beine zu stellen. Durch das stetige Feedback als Antwort auf das Voranschreiten innerhalb der kurzen Scrum-Zyklen bewirkt Scrum den Nebeneffekt des "Schneller werdens". Der essentielle Teil, um diesen Effekt nutzen können, liegt im stetigen Inspizieren und Adaptieren, also in der Auseinandersetzung mit den Herausforderungen und Störungen, die es zu beseitigen gilt. Scrum bringt nach kurzem Einsatz schnell diese Hürden zum Vorschein und macht diese transparent.
- Strukturelle Herausforderungen: Sind anfänglich die Automatisierung von Tests, eine gemeinsame Code-Ownership des Teams, die Zusammenstellung des Teams oder das Herstellen eines reibungslosen Release-Prozesses.
- Personelle Herausforderungen: Wie das Zusammenfinden als Team, dem Verständnis von Scrum-Rollen und Selbstorganisation innerhalb des Teams, das Herstellen und Verfolgen von Team-Definitionen oder ein gemeinsames Leben der Scrum Werte.
- Organisatorischen Herausforderungen: Häufig wird das "Einigeln" von Scrum-Teams als Ausgrenzung von Dritten wahrgenommen. Dies führt gerade am Anfang zu Unverständnis. In vielen Fällen sind Scrum-Teams auch über- oder unterbesetzt, da entweder die notwendigen Rollen noch fehlen oder ganze Abteilungen in ein Scrum-Team umgewandelt werden.
Diese wenigen Beispiele zeigen auf, dass in vielen Fällen ein langer und nicht immer einfacher Weg auf Teams und Organisationen wartet, der allen viel abverlangt um Geschwindigkeit bzw. Agilität zu erreichen. Wenn ein Unternehmen glaubt, dass es so weitermachen kann wie bisher, wird Scrum hier enttäuschen.
4. Irrglaube: Scrum passt zu jedem Projekt
"Scrum ist für jedes Vorhaben sinnvoll einsetzbar."
Genauso stark wie der Irrglaube, dass Scrum zu jedem Projekt passt, hält sich auch der Irrglaube, dass Scrum nicht für Großprojekte geeignet ist oder dass in Scrum nicht dokumentiert wird. Der Scrum-Guide propagiert diesen Glauben nicht!
Scrum ist für Projekte geeignet, in denen viel Unklarheit herrscht. Häufig sind dies Vorhaben, die nach neuen Lösungen suchen und deren Kombination aus unvorhersehbaren Risiken der Implementierung und noch unklaren Anforderungen bestehen. Die Unvorhersagbarkeit eines Ergebnisses ist ein klarer Pluspunkt für den Einsatz von Scrum. Scrum ist demnach nicht immer sinnvoll, wenn es um vorhersagbare Lösungen geht, also Lösungen, die standardisiert sind und bei denen das Ergebnis schon exakt feststeht.
In vielen unserer Trainings kommt irgendwann die Frage, wann sich der Einsatz von Scrum lohnt. Als Beispiel wird von den Teilnehmern oft der Bau eines Eigenheims bemüht. Wir halten dieses Beispiel für heikel, da theoretisch ein Einsatz denkbar wäre. In der Praxis würde dies jedoch niemand in Betracht ziehen, da laufende Anpassungen mit zu vielen Zusatzkosten entstehen würden. Theoretisch könnte erst einmal der Keller gebaut werden, um schnellstmöglich einziehen zu können. Die Implikationen die dadurch entstehen, wären in der Praxis jedoch nicht tragbar. Aktuell klammern wir in diesem Beispiel auch einen langwierigen Abstimmungsprozess mit Architekten und Bauherren sowie bestehenden gesetzlichen Restriktionen aus, die oftmals vorgelagert stattfinden bzw. bekannt sind.
Wir möchten hier noch einmal darauf hinweisen, dass die Frage zum sinnvollen Einsatz von Scrum oftmals auch mit dem Abgrenzen von Methoden einhergeht. Der Sinn und Unsinn, "Wasserfall" und Scrum gegenüberzustellen, wird in diesem Beispiel deutlich. Eine Abgrenzung wird oftmals gesucht und damit in vielen Fällen eine integrierte Sicht ausgeblendet.
5. Irrglaube: Wir sind schon agil und machen Scrum
"Wir machen doch schon Scrum!"
Wenn wir diese Aussage hören, werden wir hellhörig. Wir finden regelmäßig Teams vor, die einige wenige Elemente von Scrum adaptiert haben, ansonsten aber weiterarbeiten wie bisher. Oft hat der Teamleiter zusätzlich die Rolle des Product Owners und des Scrum Masters übernommen. "Das sind ja Dinge, die man als Teamleiter sowieso macht". Ein digitales Board gibt es selbstverständlich auch. Sprints dauern "so zwei bis drei Wochen, je nachdem, wie gut wir vorankommen". Die letzte Retro? Das muss vor ein paar Monaten gewesen sein. Maßnahmen daraus gab es auch, aber was daraus geworden ist, weiß niemand.
Agilität und Scrum im Besonderen ist nichts, was man "macht".
Manchmal hat eine Führungskraft etwas über Scrum gehört, war vielleicht auch einmal auf einer Konferenz und hat das eine oder andere Vorgehen herausgepickt und zur Anwendung gebracht. Das Ganze wurde mit dem Buzzword "Scrum" garniert und schon glaubten alle Beteiligten, dass man jetzt Scrum "mache". Mal ganz abgesehen davon, dass Agilität im Allgemeinen und Scrum im Besonderen nichts ist, was man "macht". Gemäß dem Grundsatz "Don’t do agile, be agile" ist Agilität eher eine Einstellungssache, die aber hier leider völlig verlorengeht.
Ken Schwaber hat für solche Szenarien bereits vor vielen Jahren den Begriff "Scrum-But" geprägt. "We’re doing Scrum, but we don’t...". Er sagt auch, dass es Situationen geben mag, in denen man nicht alle Elemente vom Scrum-Guide einsetzt, aber dann möge man es eben nicht Scrum nennen, denn dann sei es etwas anderes. Auf der sicheren Seite ist man, wenn man den Scrum-Guide zu Rate zieht und alle dort angesprochenen Punkte bejahen kann.
6. Irrglaube: Wir können Scrum ohne Werte und Prinzipien verwenden
"Scrum passt perfekt zu unseren Unternehmenswerten und unserer Kultur."
Nahe am 1. Irrglauben besteht auch hartnäckig der Irrglaube, dass bestehende Unternehmenskulturen bereit für die Verwendung des Rahmenwerks sind. Aus unserer Erfahrung ist dies eines der relevantesten Aspekte für das Scheitern von Scrum. Scrum einzuführen bedeutet, im Kleinen zu starten. Schnell zu Misserfolgen zu gelangen und sich mit diesen Erfahrungen weiterzuentwickeln. Dies fühlt sich oftmals nicht gut an und schmerzt viele Manager sehr, da es vorher irgendwie bequemer war, als wir wussten, dass etwas nicht stimmt, aber keiner mehr darüber gesprochen hat.
Wenn wir zurückblicken auf die Unternehmen die wir begleitet haben oder in denen wir selbst als Projektmanager und Führungskraft tätig waren, dann war das klassische Projektvorgehen eines der vorherrschenden Modelle für die Abwicklung von Projekten. Die Organisationsstrukturen und die Unternehmenskulturen die über Jahrzehnte gewachsen sind, bilden die DNA vieler Unternehmen.
"Agil" kommt jedoch mit eigenen Werten und Prinzipien, die als DNA den "Lean"-Gedanken in sich tragen. Organisationen stehen also nicht nur vor der Herausforderung, Scrum richtig anzuwenden, sondern zudem vor dem Anpassen der Unternehmens-DNA. Ein sehr langwieriger Weg, auf dem viele Scrum-Teams scheitern und ein "Wir arbeiten jetzt agil" zu einem "Agilität funktioniert bei uns nicht" wird.
Das Management ist häufig entkoppelt von dem, was in den Scrum-Teams passiert. Wenn bspw. auf Teamebene die Scrum-Werte und agilen Prinzipien gelebt werden, bestehen auf Managementebene viele dunkle Flecken. Wichtig wäre es jetzt, auf Managementebene diese dunklen Flecken zu beseitigen und in die eigenen Erfahrungen zu investieren, um den persönlichen Wandel voranzutreiben. In vielen Fällen erfolgt aber der Rückfall ins Altbekannte, so dass man sich wieder wohl im eigenen Körper fühlt.
7. Irrglaube: Scrum-Teams planen nicht
"In Scrum werden Sprints gemacht. Zeit für langfristige Planung bleibt da nicht."
Es ist nicht lange her, dass wir diesen Satz wieder zu hören bekamen: "Wir planen agil von Sprint zu Sprint – Langfristig können wir noch nicht sagen, was getan werden muss." Dieses Verständnis von "agil" oder der Planung mit Scrum lässt sich oftmals auf mangelndes Wissen der Beteiligten zurückführen. Wenn man einen Vergleich zur klassischen Projektplanung bemühen möchte, dann verzichtet man auf das "Vorab-Planen" zu Beginn und plant stetig im überschaubaren Maße. Kurzfristig klar, mittel- und langfristig unklarer werdend, jedoch mit einem Fokus.
Funktionierende Scrum-Teams sind in der Regel sehr gut vorbereitet und haben im Blick, auf welches Ziel ihre Arbeit einzahlt. Wesentlich ist der Zeitfaktor und der Zeitpunkt der Auseinandersetzung mit dem, was umgesetzt werden soll. Das evolutionäre Vorgehen und die Einteilung in kurze Zeiteinheiten scheint viele zu der obigen Aussage zu bewegen. Letztendlich fängt jedoch jedes Scrum-Team mit einer Vision und einem klaren Zielpunkt an. Klar in dem Sinne, dass ein sinnvolles, erreichbares und geteiltes Ziel im Mittelpunkt der Bemühungen steht. Etwas, auf das ein Scrum-Team fokussiert zusteuern kann; mit der Möglichkeit die Route stetig anzupassen. Um dieses Verständnis herzustellen, hat sich bewährt, eine Story-Map, basierend auf der Vision, zu erstellen [2]. Dieser erste Wurf einer Lösung hilft einem Team, sowohl den Umfang als auch das Ziel fokussiert anzugehen.
Der kleinste gemeinsame Planungs-Nenner ist das tägliche Synchronisieren des Teams während des Daily Stand-Ups. Im Mittelpunkt für das Team steht die Klärung der Frage "Sind wir dabei, das Sprintziel zu erreichen?" Und damit sind wir bei der mittelfristigen Planung der Sprints, die heruntergebrochen auf die Vision oder Teilziele des Projekts einzahlen. Die Anforderungen werden zwischen Team und Product Owner mit Hinblick auf ein gemeinsames Verständnis und Umsetzbarkeit besprochen. Diese Kommunikation und Auseinandersetzung während eines laufenden Sprints führt unweigerlich im Team dazu, eine mittelfristige Planung von mindestens 2 Sprints im voraus vor Augen zu haben. Product Owner planen unserer Erfahrung nach jedoch viel weiter als das und haben bis zu 5 Sprints im Blick. Diese Notwendigkeit der langfristigen Planung wird von vielen Unternehmen oder Führungsetagen weiterhin verlangt. Scrum-Teams setzen also viel daran, der Ungewissheit mit Kommunikation entgegenzuwirken und ein möglichst klares Bild in Zusammenarbeit mit dem Auftraggeber zu erzielen.
8. Irrglaube: Scrum braucht keine Manager
"Scrum-Teams brauchen keine Führung, sie sind doch selbstorganisiert."
In den Anfangstagen von Scrum lag der Fokus stark auf den selbstorganisierten Teams. Alle Verantwortung wurde in die Teams gegeben, der Manager (Team Lead, Abteilungsleiter, …) wurde als machtlose Marionette angesehen, die man nicht mehr braucht. Das ist mitnichten das, was Scrum fordert, aber so wurde es seinerzeit interpretiert und von den Führungskräften empfunden. Angst vor Machtverlust und vor dem Verlust des Arbeitsplatzes hat dazu geführt, dass sich auf der mittleren Managementebene ein starker Widerstand gegen Scrum gebildet hat. Erst mehrere Jahre später wurde erkannt, dass man diese Führungsebene mehr oder weniger sich selbst überlassen hat, anstatt sie in die neue Arbeitswelt einzubeziehen.
Fakt ist: Eine Organisation braucht weiterhin Manager. Es ist nur so, dass sich die Rolle des Managers verändert. Sie entwickelt sich weg von einem Entscheider, Arbeitszuweiser und Kontrolleur hin zu einem Unterstützer, Mentor und Coach. Man stelle sich einen fiktiven Mitarbeiter vor, der genau das tut, was der Chef angeordnet hat. Per Definition hat er einen guten Job gemacht, wenn alles erledigt ist. Und wenn etwas davon falsch war, hatte es ja der Chef entschieden. Verantwortung gleich Null. Alle Last liegt auf dem Schultern des Managers.
Heute sorgt ein Manager z. B. dafür, dass das Arbeitsumfeld stimmt. Er kümmert sich darum, dass seine Mitarbeiter gut ausgebildet sind und sich ständig weiterentwickeln. Er ermuntert sie, Verantwortung für ihren Arbeitsbereich zu übernehmen und schafft eine fehlertolerante Kultur des Vertrauens. Je nach Entwicklungsstand des Teams oder des einzelnen Mitarbeiters benutzt er die volle Bandbreite der Delegationsmöglichkeiten (bspw. vgl. Delegation Poker). Sein Ziel ist es letztendlich, seine Teams vollumfänglich arbeits- und entscheidungsfähig zu machen. Hinsichtlich des oben erwähnten fiktiven Mitarbeiters ist es nun die Aufgabe des Managers, diesen Mitarbeiter dahin zu entwickeln, dass er aktiv mitdenkt, selbst Vorschläge macht und auch mal Dinge ausprobiert. Kurz: Verantwortung übernimmt. Und das ist nichts, was man per Dekret anordnen kann, stattdessen muss der Manager aktiv vorangehen und das Umfeld schaffen.
9. Irrglaube: Eine Scrum-Einführung kann als Projekt durchgeführt werden
"Eine Scrum-Einführung ist irgendwann zu Ende."
Immer wieder bekommen wir Projektanfragen, um eine Scrum-Einführung zu begleiten. Wenn man sich diese "Projekte" mal genauer ansieht, findet man meist das gleiche Muster: Eine Scrum-Einführung ist ein Projekt mit einem Start- und einem Endedatum, das sich auch genau wie ein Projekt planen lässt. Je nach Größe der Organisation und der Anzahl der Teams wird die Einführung x Monate dauern, danach sind alle Teams agil. Autsch!
Allein schon das Festlegen eines Endedatums verursacht uns Bauchschmerzen. Es wird meist dadurch berechnet, dass man einzelnen Teams 1-3 Monate Zeit gibt, um "auf Scrum umzustellen". Dabei werden verschiedene Aspekte völlig außen vor gelassen.
Fangen wir mal auf der Teamebene an:
- Jedes Team ist individuell. Es gibt Teams, die regelrecht dafür brennen, etwas zu verändern. Andere sind extrem skeptisch und benötigen eine lange Anlaufphase.
- Meist ist es so, dass die bestehenden Teamstrukturen historisch gewachsen sind und es Sinn macht, sie vor dem Hintergrund eines schlanken Produktentwicklungsprozesses neu aufzustellen. Dieser Prozess benötigt Zeit und die neuen Teams müssen sich erst aufeinander einschwingen.
- Was ist mit den innerhalb eines Teams vorhandenen Strukturen? Gibt es einen Teamlead? Einen Architekten? Was soll aus diesen Rollen werden?
Selbst wenn wir davon ausgehen, dass auf Teamebene alle Parameter auf Erfolg stehen, bedeutet "auf Scrum umstellen" im Kontext eines Teams nur die Bildung eines lokalen Optimums. Es gibt zwar nicht die Definition von Agilität, aber die meisten Definitionsversuche fangen ungefähr folgendermaßen an:
"Agilität ist die Fähigkeit einer Organisation, sich auf Veränderungen einzustellen und flexibel zu reagieren."
Die Schaffung lokaler Optima in den Teams durch Scrum ist sicher ein Schritt in die richtige Richtung, jedoch gilt es nun, auch den Überbau – die Organisation – entsprechend auszurichten. Es sind Möglichkeiten zu schaffen, dass die Teams direkt und ohne Hierarchien untereinander kommunizieren. Außerdem sollte es teamübergreifende Retrospektiven geben und allen muss klar sein, dass auch die aktuelle Teamstruktur nicht in Stein gemeißelt ist, sondern im Sinne einer stetigen Verbesserung verändert werden kann. Unter diesen Voraussetzungen wird schnell klar, dass man eine Scrum-Einführung nicht als Projekt betrachten kann. Es kann bestenfalls ein Anschub für ein Umdenken und ein permanentes Streben nach Verbesserung sein. Eine Scrum-Einführung ist ein andauernder Prozess, kein Projekt.
10. Irrglaube: Ein Scrum-Zertifikat genügt
"Sogar der Scrum-Guide sagt, dass Scrum einfach ist, da werden wir das ja wohl umsetzen können."
"Zertifizierter Scrum Master" hört sich zugegebenermaßen gewaltig an. Ein Master und dann auch noch zertifiziert. Eine Scrum-Zertifizierung ist sicher eine gute Basis für einen angehenden Scrum Master. Andererseits muss man sich aber auch bewusst machen, dass die unterschiedlichen Scrum-Zertifizierungen bestenfalls dazu dienen, das Scrum-Basiswissen wie es im Scrum Guide steht, zu vermitteln. Dies ist aber nur ein Anfang, es gibt eine große Anzahl Tools und Methoden, um dieses Basiswissen zu ergänzen und zu erweitern.
Wenn Sie einen frischgebackenen Scrum Master in Ihrer Organisation haben, wird nicht alles von Anfang an glatt laufen. Ein guter Scrum Master entwickelt sich erst über die Zeit. Er wendet sein Wissen an, variiert es, probiert neue Dinge aus und bildet sich konsequent weiter, z. B. durch Teilnahme an Konferenzen und aktives Einbringen in die Scrum-Community. Geben Sie ihm Zeit zum Reifen, lassen Sie ihn Fehler machen, geben Sie ihm Freiräume.
Wenn Sie Ihren Scrum Master in seinem Lernprozess unterstützen möchten, empfehlen wir die anfängliche Begleitung durch einen professionellen Scrum Coach, der dabei hilft, gleich in die richtige Richtung zu gehen und klassische Anfangshürden zu umschiffen. Achten Sie dabei darauf, dass der Coach mehrjährige Erfahrung mitbringt und nicht nur den Titel trägt.
Fazit
Die einzige Quelle, die Scrum beschreibt, ist der Scrum-Guide. Wenn etwas nicht im Scrum-Guide beschrieben ist, ist es auch kein Teil von Scrum.
Eigentlich ist dies ganz einfach. Schwer ist es, Scrum in bestehende Organisationsstrukturen und -kulturen einzubinden. Es gilt eben nicht, Scrum anzupassen, sondern diese Strukturen, um den Nutzen von Scrum zu erhalten. Ein wesentlicher Faktor für den erfolgreichen Scrum-Einsatz ist das Leben und die Anwendung der agilen Prinzipien sowie der Scrum-Werte, die kombiniert mit der Bereitschaft sich ständig zu verändern und zu lernen ein starkes Fundament liefern.
- Scrum-Guide
- J. Patton: User Story Mapping: Discover the Whole Story, Build the Right Product. O’Reilly Media, 2014
