Was, wenn „Scrum“ bereits verbrannte Erde ist?
Kommt dir diese Situation bekannt vor? Du bist neu im Projekt und deine Aufgabe ist es, Scrum einzuführen. Vielleicht wurdest du auch gerufen, damit das Team endlich die Scrum Regeln befolgt. Oder du musst dafür sorgen, dass das Scrum Team endlich richtig funktioniert. Kurz gesagt:
Du bist der neue Scrum Master im Projekt.
Allerdings macht das Team bei deinem Erscheinen keine Freudensprünge. Ganz im Gegenteil, das Erste, was du zu hören bekommst:
„Wir haben Scrum schon probiert, funktioniert hier nicht. Wir machen jetzt Kanban.“
Diesen Satz habe ich wortwörtlich so vor einigen Jahren zu hören bekommen. Kurz davor hatte mich mein damaliger Teamleiter „gebeten“, Scrum auch im Vertriebs- und Projektteam einzuführen, da es in unserem Entwicklungsteam doch bereits so gut funktionierte. Aus leidvoller Erfahrung wusste ich schon, dass ich das Vertriebsteam nicht mit Aussagen wie: „Der Chef hat gesagt, ihr müsst Scrum machen“, auf meine Seite bringen würde und für Scrum (wieder) begeistern konnte.
Es musste ein anderer Ansatz her.
Aber Achtung:
Hüte dich vor diesem Fehler
Der Fehler, den unerfahrene Scrum Master in dieser Situation machen – und ich zählte mich für eine lange Zeit auch dazu –, ist es, sich auf die Befolgung der Scrum Regeln zu versteifen. Und dabei ist ihnen (und mir) erstmal kein Vorwurf zu machen.
Im Scrum Guide steht doch:
„Das Scrum Rahmenwerk, wie es hier beschrieben wird, ist unveränderlich. Es ist zwar möglich, nur Teile von Scrum zu implementieren, aber das Ergebnis ist nicht Scrum.“
Falsch verstanden lässt einen dieser Satz zusammenzucken.
Und das ist auch richtig. Was immer dein Team macht, du darfst erst davon sprechen, dass es ein Scrum Team ist, wenn es die Scrum Spielregeln befolgt. Jeff und Ken wollen sich damit absichern. Denn leider gibt es viele Teams, die sich gerade Mal jeden dritten Tag zum Daily Stand-up treffen, gleichzeitig nicht wirklich erfolgreich sind und dann Scrum für ihren Misserfolg die Schuld geben.
Gleichzeitig bedeutet es aber nicht, dass Elemente aus Scrum nicht schrittweise genutzt werden können, um das Team erfolgreicher zu machen. Du darfst es halt einfach noch nicht Scrum nennen. Aber das ist noch nicht der „Hack“, den ich dir in der Überschrift versprochen habe.
Sondern leider ein weiterer Fehler.
Die Elemente von Scrum schrittweise einführen
Wahrscheinlich bist du jetzt etwas verwirrt.
Habe ich dir nicht gerade gesagt, in einer solchen Situation sei es ratsam, Scrum schrittweise einzuführen? Also ein Element von Scrum nach dem anderen hinzuzufügen?
Ja, habe ich.
Aber der Teufel liegt im Detail. Was passiert, wenn du damit anfängst, einen Termin für die Planung des Sprints einzustellen? Was passiert, wenn du dann in der nächsten Woche Termine für tägliche Daily Stand-ups einstellst? Und was wird passieren, wenn du anfängst herumzufragen, wer nicht alles Zeit hat, um am Donnerstagnachmittag die Arbeit des Teams in einem Sprint-Review zu begutachten?
Darf ich ehrlich mit dir sein? Aus meiner Erfahrung nicht das, was du dir erhoffst, sondern du wirst zu hören bekommen: „Scrum besteht nur aus Meetings. Die Scrum Meetings halten mich von der Entwicklung ab. Arbeitet das Team eigentlich auch mal, oder sitzen die Mitglieder den ganzen Tag nur in Meetings?“
Warum ist das so? Durch diese Art der Einführung von Scrum wurden nur Meetings zu eh schon überfüllten Kalendern hinzugefügt. Das Hinzufügen neuer „Regeln“ erleichtert die Arbeit der bereits überbeschäftigten Mitarbeiter nicht unbedingt.
Deshalb verrate ich dir jetzt meinen Ansatz:
Der geheime Hack: Elemente von Scrum hijacken
Anstatt weiter die Kalender der Kollegen mit neuen Meetings zu füllen, anstatt weiter Arbeitsvereinbarungen zu treffen, an die sich jeder zusätzlich im Team halten muss, solltest du die bereits existierenden Meetings und Arbeitsvereinbarungen einfach hijacken.
Natürlich hat die Übernahme ihren Preis.
Du kannst die Meetings erstmal nicht so nennen, wie es im Scrum Guide vorgesehen ist. Das nagt immer etwas an meiner Ehre als Scrum Master. Ich bin Scrum Master, aber mein Team macht kein Sprint-Planning, sondern ein montägliches Surfix? Klingt nicht danach, als wäre es sonderlich erfolgreich. Wenn du deine Scrum-Master-Ehre aber außen vor lassen kannst, dann habe ich hier einige Beispiele, wie ich dabei in der Vergangenheit vorgegangen bin.
Beginnen wir mit dem Wichtigsten:
Scrum Element #1: Produktziel
Warum ist ein Ziel so wichtig?
Vereinfacht gesagt: Ohne Ziel ist ein Team kein Team, sondern eine Gruppe. Anstatt jetzt den Fehler zu machen und das „Team“ zu einem Workshop einzuladen, in dem es sich ein Ziel, eine Vision oder Mission ausdenkt, beginne doch lieber damit, bereits existierende Ziele zu hijacken.
Wie kannst du dabei vorgehen?
Ich starte bei einem Entwickler und seiner Arbeit und frage ihn:
„Warum machst du, was du machst?“
Wenn dann die Antwort kommt: „Ich programmiere die Anforderung, um die mich der Kollege aus dem Vertrieb letzte Woche gebeten hat“, dann könntest du eine weitere Person gefunden haben, der du die gleiche Frage stellen kannst. Meine Erfahrung ist: Je mehr Personen du diese Frage stellst, desto mehr zeigt sich, worauf wir gerade hinarbeiten oder wozu wir die Arbeit machen.
Es zeigt sich also, was das Ziel des Produkts gerade ist.
Scrum Element #2: Definition of Done
Das Ziel gibt eine Richtung für das Scrum Team vor.
Damit Scrum Teams erfolgreich sind, muss die Qualität des Produkts den Erwartungen der Kunden entsprechen. In Scrum nennen wir diese Erwartungshaltung die Definition of Done. Was kannst du dafür hijacken?
Die Frage ist also: Wo werden im Moment die Anforderungen an die Qualität festgehalten?
Mein erster Anlaufpunkt wäre hier der Vertrieb. Sprich mit den Personen, die das Produkt vertreiben. Und dann arbeite dich zur Arbeit des Teams zurück. Dein Ziel sollte es sein, alle Arbeitsschritte zu kennen, die unternommen werden müssen, damit die Qualitätsanforderungen in jeder Lieferung des Produkts erfüllt werden.
Diesen Ansatz kannst du sehr systematisch verfolgen. Er hat sich über die Jahre so bewährt, dass ich ihn auch in meinem „Professional Scrum Master – Advanced“-Training jedem Scrum Master an die Hand gebe.
Als Nächstes widmen wir uns dem Arbeitsvorrat für das Team.
Scrum Element #3: Product-Backlog
Das Product-Backlog beschreibt, welche Änderungen am Produkt vorgesehen sind.
Wie finden wir eine Liste dieser Änderungen? Wie bei den letzten beiden Elementen auch. Sprich mit den Menschen in deinem Umfeld. Stelle dir die Frage: Woher kommt die Arbeit?
Hier einige Personen, die das „Product-Backlog“ vielleicht kennen: Projektleitung, Produktmanagement, technischer Leiter oder der Requirements-Engineer im Team. Wahrscheinlich hat dieses Backlog nicht die gewohnte Form. Vielleicht ist es eine Excel-Tabelle oder ein in Doors abgelegtes Dokument. Das ist nicht schlimm. Wichtig: Mache nicht den Fehler, erstmal Jira bei der IT zu beantragen, einen Jira-Workflow zu definieren und das Team zu zwingen, aus allen Features der Excel-Tabelle jetzt krampfhaft User-Stories zu formulieren.
Vergiss nicht:
Wir wollen keine neuen Elemente einführen, wir wollen Bestehendes hijacken!
Und wenn wir schon nach den Quellen der Arbeit für unser Team suchen, dann finden wir vielleicht auch den Verantwortlichen ...
Scrum Element #4: Product-Owner
Vielleicht hast du ihn bereits im letzten Schritt kennengelernt.
Es könnte ein Projektleiter oder Teamleiter sein. Die Frage, die dich zum Product-Owner führt, lautet:
„Wer kann entscheiden, dass wir die Entwicklung nicht mehr weiterführen?“
Diese Person ist zweifelsohne der Product-Owner.
Es gilt das Gleiche wie im letzten Schritt: Verfalle nicht der Versuchung, die Verantwortung des Product-Owners einfach hinzuzufügen, indem irgendjemand im Team diesen Titel verliehen bekommt.
Jetzt kennst du einige Beispiele, wie du vorgehen kannst, wenn du die Elemente von Scrum im Unternehmen hijacken willst.
Das ist der erste Schritt von dem, was ich als „Undercover-Scrum-Einführung“ bezeichne.
Wie geht es dann weiter?
Im nächsten Schritt geht es darum, diese Elemente transparent zu machen und dem Team regelmäßige Überprüfungen und Anpassungen zu ermöglichen.
In Scrum-Guide-Sprache: empirisches Arbeiten ermöglichen.
Betrachten wir nochmal den Product-Owner.
Ich bin mir zu 100 % sicher, dass der Product-Owner bereits existiert. Vielleicht kennt die Person ihren Einfluss für die Entwicklung von Produkten aber (noch) nicht.
Jetzt hast du als Scrum Master ein Hindernis identifiziert, das du beseitigen solltest, wenn du Scrum weiter einführen willst ...
- Wie kannst du der Person helfen, ihre Verantwortung und Wirkung auf die Entwicklung besser zu verstehen?
- Wie kannst du die Entwickler und den Product-Owner zu intensiverer Zusammenarbeit bewegen?
- Welche Aufgaben können die Entwickler im Team dem Product-Owner abnehmen?
Suchst du für die Beantwortung dieser Fragen nach Unterstützung?
Dann besuche das nächste „Professional Scrum Master – Advanced“-Training. Dort zeigen Marc Kaufmann und ich dir ein systematisches Vorgehen, wie du dein Team und den Product-Owner unterstützen kannst.
Über 271 Scrum Master sind unserer Empfehlung bereits gefolgt und haben sich das Professional-Scrum-Master-II-Zertifikat gesichert – und sind damit den nächsten Schritt in ihrer Karriere gegangen.
Noch unsicher, ob das Training zu dir passt?
Dann wirf einen Blick auf dieses Video, es gibt dir einen guten Einblick, was dich erwartet.