#SCRUM2go oder wie man seinem Kunden SCRUM im Projektverlauf beibringt

Kapitel 1 – Der klassische Worst-Case

Wie sieht eigentlich ein Worst-Case-Ausgangsszenario für ein SCRUM-Projekt aus? Diese Frage stellt man sich vielleicht erst, wenn es einem selbst widerfährt. Fangen wir mit dem Klassiker an – der Kunde hatte bisher noch nicht nach SCRUM gearbeitet, seine Mitarbeiter noch nicht geschult, wollte aber trotzdem schnellstmöglich anfangen. Auch der zweite Klassiker war dabei: eine detaillierte Anforderungsliste, welche im vereinbarten Scope erfüllt werden sollte. So weit so gut, aber das war es noch nicht, denn die Anforderungen hatte nicht das eigentliche SCRUM-Team aufgenommen – dieses kam erst zu Beginn frisch ins Projekt. Um es abzurunden, stellte uns der Kunde auch einen Projektleiter an die Seite und der Product Owner (PO) auf Kundenseite wurde kurz vor Projektbeginn ausgetauscht. Es warteten also eine Menge Herausforderungen auf unser SCRUM-Team.

Kapitel 2 – Kennenlernen und Abholen

Wo fängt man also an? Wir versuchten es zunächst mit der Struktur und den Rollen. Also Meeting zum Kennenlernen und Erklären angesetzt und im Anschluss das Protokoll mit dem Modell versendet. Unser Ziel dabei war, eine hierarchiefreie Struktur zu zeigen und gleichzeitig das agile Mindset zu verdeutlichen. So sollten Projektleiter bzw. Projektmanager nur als Interessensvertreter und Unterstützer agieren und der Projektmanager seitens der MMS als agiler Coach präsent sein.

Am nächsten Tag hatten wir eine E-Mail mit einem Modell im Postfach, wie es sich der Kunde vorstellt – klassisch mit Projektleiter und einer Hierarchie. Dieses wurde stark von der internen Organisationsstruktur geprägt. Als Folge befindet sich das SCRUM-Team in dem hierarchischen Organigramm ganz unten. Was nun? Wie bekommt man einen “klassischen” Projektleiter in einem SCRUM-Team unter? Ist das überhaupt möglich?

Um den Kunden nicht direkt zu verschrecken, indem wir seine Abbildung für nichtig erklären, nahmen wir diese als Grundlage. Herauskam ein Hybrid aus beiden Welten und ein Bild, mit dem der Kunde, nach einem erklärenden Meeting, etwas anfangen konnte. Mit dieser Abbildung konnten wir sichtbar machen, dass Rollen wie „Director“/”Senior-” und „Projektorganisator“ (um den Begriff Projektleiter/-Manager zu vermeiden) zwar wichtig sind, aber keinen direkten Zugriff auf das „geschützte“ SCRUM-Team haben. Wir versuchten das SCRUM-Team im Zentrum zu platzieren, um den Fokus darauf zu setzen. Das Verbindungsstück von allen Positionen zum Projekt sollte der Product-Owner-Lead (PO-Lead) sein. Diese Rolle entstand, da es auf Kundenseite mehrere Zuständige und damit Product Owner für gewisse Teilbereiche gab. Die verschiedenen Product Owner bildeten zusammen mit dem Product-Owner-Lead das “Product-Owner-Team”, welches durch den PO-Lead im Scrum-Team vertreten wurde.

Kapitel 3 – Eine Grundsatzfrage

Wenn wir schon in den ersten Schritten des agilen Projektes so holprig unterwegs sind und für das vorgegebene Budget auch ein vorgefertigtes „Backlog“ haben, ergibt das agile Vorgehen hier dann überhaupt Sinn? Agilität ist eins dieser Schlagwörter, wie “Cloud” vor 5 Jahren oder “Containerisierung” und “NFT” (Non-Fungible Token) im Moment, welche häufig als Allheilmittel im IT-Umfeld gelten. Das ist es aber aus unserer Sicht nicht und unter diesen Voraussetzungen überlegten wir, das Projekt hybrid oder doch gar klassisch durchzuführen. Einiges sprach gegen ein agiles Projekt, aber vieles dafür, wie der explizite Wunsch des Kunden nach einem agilen Vorgehen. Also machten wir uns Gedanken über das „Wie?“. Schlussendlich entschieden wir uns für einen Drei-Stufen-Plan.  

Shhritt 1 Eine 90-minütige Zusammenfassung für alle Projektbeteiligten des Kunden zum Thema “Agilität” inklusive des Formates “SCRUM in 60 Minuten”. 
Schritt 2 Ein Workshop über zwei Tage mit dem Kernteam, um das agile Vorgehen modellhaft auszuprobieren.  
Schritt 3 Einen Demosprint bzw. Sprint 0 durchführen.

Kapitel 4 – So viele Meetings? 

Wenn man von außen auf ein SCRUM-Team schaut und noch keine Erfahrungen mit dem Framework sammeln konnte, kann man den Eindruck bekommen: „Das sind sehr viele Meetings und sehr viel Overhead!“. So auch unser Kunde zu Beginn. Insbesondere mit den verschiedenen Meetings, welche wir zur genaueren Anforderungsaufnahme benötigten, fühlte sich der Kunde schnell von zu vielen Meetings erschlagen. Mit „SCRUM in 60 Minuten“ konnten wir dem Kunden ein Grundverständnis für agiles Arbeiten vermitteln. „SCRUM in 60 Minuten“ ist ein Format, welches alle wichtigen Grundsätze des SCRUM-Frameworks zusammenfasst und somit ideal für einen ersten Überblick ist. Dies allein war für das Verständnis von SCRUM-Events jedoch nicht ausreichend.
Nach unserem Startschuss mit „SCRUM in 60 Minuten“ brauchte der Kunde also etwas „zum Anfassen“, um sich unter all den SCRUM-Events etwas vorstellen zu können. Hier entschieden wir uns, etwas mehr Zeit zu investieren und einen Workshop mit einem virtuellen Szenario durchzuführen.
Unser Szenario war ein Zoo. Da sich jeder etwas unter einem Zoo vorstellen und auch Erwartungen an einen Zoo definieren kann, ist war es ein gutes Beispiel zum Ausprobieren. In zwei Teams bekam der Kunde jeweils die Rollen, welche er auch später im Projekt einnehmen sollte. Aus heutiger Sicht war dies einer der wichtigsten Schritte.

Kapitel 5 – Der PO im Zoo 

In dem fiktiven Zoo-Bau-Szenario sammelte der Kunde und insbesondere der Product-Owner, wichtige Erfahrungen. Im Nachhinein antwortete er uns auf die Frage, was im Training besonders gewirkt habe und was sich dadurch veränderte: „Es hat Verständnis für die Rollen geschaffen bzw. wie man sich in den Rollen fühlt, was schwer oder leicht ist.“ und auf die Frage welchen Nutzen das fiktive Szenario für ihn hatte: „…praktische Anwendung hilft ungemein, auch wenn sich damals das Bild noch nicht ganz geschlossen hatte. Trotzdem ist die Simulation ein wesentliches Element das agile Projektmanagement zu erleben.“
Unser zeitlicher Invest auf Kosten eines späteren Starts der ersten Sprints hatte sich also gelohnt. Denn nun hatten wir einen PO auf Kundenseite, der bestens vernetzt war, gleichzeitig aber auch schon erste Erfahrungen im SCRUM-Framework sammeln konnte.
Hilfreich war es auch, in dieser Simulation bereits die tatsächlichen Rollen zu verteilen. Somit konnte man in späteren projektbezogenen Situationen auf die Beispiele aus dem Zoo verweisen und wie man dort mit den Themen umgegangen ist.

Kapitel 6 – Rein ins kalte Wasser

Zugegeben, mit den bisher getätigten Vorbereitungen (“SCRUM in 60 Minuten” und dem Workshop) war das Wasser nicht mehr eiskalt, sondern eher lauwarm. Trotzdem war der Start des Sprint 0 holprig. Das Backlog war mäßig gefüllt und viele der dort beschriebenen Themen entsprachen weder einer “Definition of Ready” noch anderen SCRUM-Standards. Mit dem geschaffenen Grundverständnis war es aber gut möglich, auch diese Standards schrittweise einzuführen und zu dokumentieren. Der Sprint 0 war dafür ideal. Die meisten Tickets waren wenig technisch und da wir sie als Team ausformulierten, wuchs beim Product Owner immer mehr das Verständnis, dass jeder Task ein Ticket bedeutet und Tickets, die jetzt geschrieben werden, frühestens in den nächsten Sprint kommen. Zusätzlich erkannte der Kunde den Sinn der verschiedenen SCRUM-Meetings, sodass auch diese effizienter wurden.

Kapitel 7 – Sprint 1, Keyressource -1

Ein agiles Projekt hat den Vorteil, flexibel auf verschiedene Gegebenheiten reagieren zu können. Davon mussten wir leider früher Gebrauch machen als uns lieb war. Nach allen Vorbereitungen brach uns in Sprint 1 eine unserer zwei Key-Ressourcen weg, welche die detaillierten Anforderungen erfasst und dokumentiert hat.
Dabei lernte der Kunde direkt welche Vorteile das agile Vorgehen haben kann. Da wir bereits gut geschriebene Tickets hatten, verlangsamten wir das Sprinttempo temporär und gaben uns so die Möglichkeit, einen neuen Kollegen ins Team zu holen, welcher Anhand der Dokumentation und der Tickets bereits einen Sprint später schon voll einsatzbereit war. Der Ausfall war zwar immer noch spürbar, aber weniger schmerzhaft.

Kapitel 8 – Ende gut, alles gut oder man lernt nie aus

Je mehr Sprints wir durchführten, desto sicherer fühlte sich der Kunde im Framework und während wir anfangs Grundlagen des agilen Vorgehens besprachen, diskutieren wir nun detailliert einzelne Prozessschritte und Tools und versuchen diese für unser Projekt zu optimieren. Der Kunde nutzt inzwischen aus eigener Initiative Jira-Tickets, um interne Klärungen zum Projekt sauber verfolgen zu können. Wenn ihm eine neue Idee kommt, oder er Fehler findet, ist sein erster Weg, ein Ticket zu erstellen. In den Sprintwechseln gibt es neben konstruktivem Feedback auch ein gut gefülltes und qualifiziertes Backlog. Nachdem wir uns mit dem Kunden sicher im SCRUM-Framework bewegten, konnten wir auch die Sprintdauer von zwei auf drei Wochen erhöhen. Das reduzierte den Overhead und brachte mehr Zeit für Entwicklungen. 

Im Vergleich zu anderen agilen Projekten ist dieses SCRUM-Vorgehen sicher noch nicht vollständig ausgereift und es gibt Verbesserungspotential. Im Gegensatz zur Ausgangssituation konnten wir mit unserem Vorgehen aber sowohl beim Kunden als auch im SCRUM-Team eine sehr große Zufriedenheit schaffen, welche uns der Kunde regelmäßig bestätigt.