Scrum einführen – Wie Du deine ersten Projekte mit Scrum umsetzt

1. Wählt 1-3 Projekte, die noch frisch sind oder noch nicht begonnen haben. Die Projekte brauchen volle Rückendeckung durch das Top-Management.

2. Benennt Product bzw. Project Owner, die den Mut zur Lücke haben, nicht immer den doppelten Boden suchen, gewillt sind Entscheidungen zu treffen und gut vernetzt sind.

3. Formuliert zu jedem Vorhaben ein Projektziel, in dem unternehmerische Ziele, der Wert für den Kunden / Anwender und Messgrößen für den Erfolg definiert sind.

4. Benennt wichtige Stakeholder, aber entbindet das Team von allen anderen Verpflichtungen, die eure Projektorganisation mit sich bringt (Lenkungsausschüsse, granulare Business Cases vor Projektstart, Reporting- und Dokumentationspflichten etc.).

5. Stellt Projektteams zusammen, die “klein aber fein” sind. Die Mitarbeiter müssen vor allem Zeit mitbringen (mindestens 1 Tag / Woche, 3 bis max 5 Mitarbeiter pro Team).

6. Stellt den Teams einen Projektcoach zur Seite, der das Team in agiler aber vor allem kundenzentrierter Methodik begleitet. Neben Scrum sollte der Coach Erfahrung in Design Thinking und der Anwendung kundenzentrierter Methoden haben.

7. Definiert einen Sprint-Rhythmus. Die Dauer der Sprints ist von dem Projekt aber auch der agilen Erfahrung der Teilnehmer abhängig. Als Daumenregel empfehle ich  zum Start einen Sprint-Rhythmus von einer Woche zu definieren, um Methodik und das Vorgehen zu üben. Je reifer das Team ist, desto weiter könnt ihr den Rhythmus dann ausweiten.

8. Terminiert das Sprint Planning, Reviews und Retrospektiven für die kommenden 3-12 Monate für jedes Projektteam. Ladet auch Stakeholder zu den Reviews ein.

9. Richtet ein Backlog und Kanban Board ein, das allen frei zugänglich ist und den aktuellen Bearbeitungsstand zeigt.

10. Fangt an. Führt projektübergreifend regelmäßige Reviews und Retrospektiven durch und arbeitet heraus, welche Herausforderungen eure Organisation bei der Einführung von Scrum zu bewältigen hat.

Die ausgewählten Scrum Projekte dürfen keine getarnten Arbeitsaufträge sein. Bei einem Arbeitsauftrag sind das WAS und das WIE von vornherein klar und möglicherweise auch vorgegeben. Scrum als Methode bringt euch in Projekten einen Vorteil, in dem es viele Unbekannte gibt.

Zum Start müssen der PO und der Sponsor des Projektes vor allem über das WARUM, das Projektziel, erwartete Outcomes und Messgrößen zur Erfolgsbewertung sprechen. Dieses Framing des Projektes ist die Saat auf dem ein Scrum Projekt gedeihen. Gleichzeitig dient die Vision dem Projektteam, um sein Handeln auszurichten. Dabei ist es wichtig das Besprochene auch möglichst konkret zu verschriftlichen. Diese Formulierung dürft ihr dann lieber einmal mehr als weniger kneten, um wirklich sämtliche Unklarheiten zu beseitigen.

Wenn ihr Scrum einführt, dann orientiert euch an den definierten Scrum Meetings und  Kommunikationsregeln statt zu versuchen diese mit den lieb gewonnen Routinen zu verheiraten. Entsprechend gibt es eine Review statt Lenkungsausschüsse oder Jour-Fixes, das Team arbeitet selbstorganisiert an der Umsetzung und es braucht keinen Projektmanager der Arbeitspakete koordiniert. In Scrum erfolgt die Koordination durch die Priorisierung, die der PO auf Basis des erwarteten Nutzens für Kunden und Unternehmen sowie des erwarteten Aufwands vornimmt. Das Backlog ist für jeden einsehbar und in der Review steht es jedem frei, Fragen zu stellen oder Feedback zu geben.

Scrum basiert als agiles Werkzeug auf einer hohen Kundenzentrierung. In vielen mir bekannten Projektsituationen ist der Anwender / Kunde jedoch eher “Begleiterscheinung” statt Zentrum des Handelns. Die folgenden Fragen helfen Dir den Kunden in den Mittelpunkt zu rücken:

• Wer ist der Kunde / Anwender?
• Welches Problem lösen wir für den Kunden?
• Auf Basis welcher Messgrößen wollen wir den Kundenerfolg bewerten?

Dabei führt kein Weg an der direkten Auseinandersetzung mit dem Kunden vorbei, auch wenn dein Vertrieb meint, er hätte ein Monopol auf ein Gespräch mit dem Kunden. Das Projektteam und vor allem der PO gehen in die direkte Auseinandersetzung mit dem Kunden und beziehen sie eng in die Entwicklung des Vorhabens mit ein. Die Sensibilisierung für die Bedürfnisse des Kunden und Methodik Kundenbedürfnisse zu erfassen, sind eine wichtige Aufgabe eines agilen Coaches, der die Teams auf ihrem Weg begleitet.

Große Organisationen tendieren zu vielen Abstimmungen, das Leben in der Matrix wird zum Bremsklotz. Wenn Du Projekte mit Scrum umsetzt, dann liegen sämtliche Koordinations- und Abstimmungs-Aufgaben in der Kompetenz des PO. Dabei orientiert sich der PO am definierten Projektziel. Der PO entscheidet also, welche Stakeholder er mit einbezieht, welches Feedback er berücksichtigt. Seine Aufgabe ist es, den maximalen Wert für Kunden und das Unternehmen zu realisieren, nicht einzelne Stakeholder glücklich zu machen.  

Eine weitere Tendenz von Unternehmen, die in der Matrix agieren, ist es Projektteams künstlich aufzublähen. Noch mehr Mitarbeiter, die alle eigentlich keine Zeit haben. Wenn du Projekte mit Scrum umsetzt, dann stellt kleine aber schlagkräftige Teams zusammen, die alle notwendigen Kompetenzen haben, um das Projektziel zu erreichen. Es gibt also keine Projektmitglieder, die nur im Team sind, um Abteilung im Loop zu halten. Dafür hat Scrum das Format der Reviews vorgesehen, solche wichtigen Stakeholder sind herzlich eingeladen. Zudem obliegt es der Rolle des PO das Feedback dieser Stakeholder auch im Backlog zu berücksichtigen.

Das Scrum-Framework basiert auf einer hohen Rollenklarheit der Teilnehmer. Nicht immer lässt sich diese strenge Aufteilung bei der Einführung von Scrum aufrecht erhalten:

• Bei internen Projekten verschwimmen die Grenzen zwischen Kunde / Anwender und Mitglied im Projekt- bzw. Scrum Team. Achtet hier auf eine hohe sprachliche Sensibilität, wer gerade welchen Hut aufhat, wenn er etwas einbringt.
• Der Projekt-Owner (PO) ist fast immer auch Teil des umsetzenden Projektteams und übernimmt auch Aufgaben, die für das Erreichn des Sprint Ziels erforderlich sind. Z.B. kann es für die Transparenz im Team wichtig sein, Budgetfragen zu klären. Die Klärung liegt im Verantwortungsbereich des Projekt-Owner (PO), der Transparenz halber würde ich diese Aufgabe auch zum Teil des Sprints machen.
• Bei Projekten in sehr frühen Phasen haben die Evaluierung der Kundenbedürfnisse oberste Priorität, hier sind der PO und das Projektteam gemeinsam gefordert.

Auch wenn der PO in Extremsituationen selbst Anwender, PO und gleichzeitig noch Mitglied des Projektteams ist, muss die Rolle des PO stark besetzt sein und der PO braucht eine hohe Verfügbarkeit und Präsenz.

Der Scrum Master hat die Aufgabe den PO und das Team in der agilen Umsetzung des Projektes  zu befähigen aber vor allem das Projektteam vor ungewollten Einflüssen zu schützen. Z.B. weil dann doch einem direkten Vorgesetzten einfällt, dass sein Mitarbeiter die nächsten 3 Monate nun doch nicht zur Verfügung steht und damit indirekt die Arbeit des Projektteams blockiert.

Gerade unerfahrene Teams in traditionellen Organisationen können ohne einen Projektcoach nicht wirkungsvoll arbeiten. Dazu zwei Überlegungen, die euch helfen sollen die Rolle des Coach zu besetzen:

• Der Coach braucht Expertise im kundenzentrierten und agilen Arbeiten (Scrum, Design Thinking, kundenzentrierte Werkzeuge)
• Je nachdem welche Einflussnahme von Stakeholdern Du “fürchtest” muss der Coach gut in der Organisation vernetzt sein.

Wenn ihr einen internen Kollegen habt, der agil erfahren und gut vernetzt ist, dann ernennt ihn zum Projektcoach des Teams. Wenn ihr diese Kompetenz durch einen externen Coach einbringt, der in eurer Organisation keine Legitimation und vor allem kein Netzwerk hat, dann müssen der PO und der Coach das Team gemeinsam vor ungewollten Einflüssen beschützen. Der Scrum Master hilft die schädlichen Einflüsse zu identifizieren und coacht den PO wie er mit der Situation und dem Stakeholder umgehen muss.

Schließlich basiert der letzte große Fehler auf dem Irrglauben, dass mit der Schulung eigener Mitarbeiter alle Kompetenzen für die Einführung von Scrum besetzt sind. Das Scrum Framework ist sehr zugänglich und leicht verständlich, kollidiert in seiner “idealen Lehre” allerdings ganz sicher mit den realen Projekt- und Organisationsstrukturen. Deshalb ist es wichtig die wesentlichen Prinzipien hinter Scrum zu verstehen, um Entscheidungen treffen zu können, wie die Einführung von Scrum in deinem Unternehmen gestaltet werden kann.  

Die Einführung von Scrum braucht Zeit. Probiert es aus, beobachtet an welchen Stellen Scrum mit eurer Kultur und Organisation kollidiert, zieht entsprechende Schlüsse und passt euer Vorgehen an. Damit ihr die richtigen Schlüsse zieht und Scrum nicht zu sehr dehnt, ist es wichtig euch durch erfahrene Coaches und Scrum Master begleiten zu lassen. Nämlich genau an diesen Bruchstellen, an denen agile Werte mit eurer heutigen Arbeitskultur kollidieren, liegt der Schlüssel zur erfolgreichen agilen Transformation deines Unternehmens. Und deshalb ist die Einführung von Scrum für Unternehmen mit gewachsenen Organisations- und Projektstrukturen ein erster wichtiger Schritt auf dem Weg zum agilen Unternehmen.

Viel Erfolg dabei.