Ein Innovation Lab ohne agiles Projektmanagement ist kaum denkbar. Scrum und Kanban helfen uns als Projektmanagementtools agil und schnell Projekte voranzutreiben. Und genau darum geht es bei uns. Was die Vorteile sind und wie wir es leben, das erfahrt ihr in unseren beiden Blogbeiträgen zum agilen Projektmanagement.

Scrum im Alltag des Innovation Labs

Seit ein paar Jahren ist Scrum oder agiles Projektmanagement in aller Munde. Was ursprünglich mal als Methode zur agilen Weiterentwicklung von Software angefangen hat, zieht mittlerweile weite Kreise. Was ist dran an diesem Buzzword und wie kann Scrum auch zur Entwicklung von Ideen in einem Innovation Lab seinen Beitrag leisten? Wir wollen mit diesem Artikel über unsere eigenen Erfahrungen im Innovation Lab berichten.

 

Was bedeutet Scrum überhaupt?

Nach 2 Jahren Innovation Lab verfügen wir mittlerweile über einige Methoden und Tools die wir in unserem Alltag einsetzen. Wir haben einen ziemlich pragmatischen Zugang zu den meisten Themen, egal ob das Design Thinking, Lean Startup oder auch Scrum ist und nutzen genau die Elemente die uns das Leben erleichtern beziehungsweise weiterbringen.

Bevor wir aber zu den praktischen Erfahrungen kommen, schauen wir uns erst noch an, was sich hinter dem Schlagwort Scrum verbirgt. Welche Rollen braucht es im Prozess? Was steckt hinter dem Begriff Sprint?

Starten wir, wie bei vielen Themen, mit einem ersten Abstecher bei Wikipedia:

„Ken Schwaber veröffentlichte auf der OOPSLA 1995 den ersten Konferenzbeitrag über Scrum. Darin schrieb Schwaber: „Scrum akzeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist. Das Produkt ist die bestmögliche Software unter Berücksichtigung der Kosten, der Funktionalität, der Zeit und der Qualität.“ Der Begriff Scrum stammt aber von Ikujirō Nonaka und H. Takeuchi, die damit das Gedränge (englisch scrum) im Rugby als Analogie für außergewöhnlich erfolgreiche Produktentwicklungsteams beschrieben. Diese Teams arbeiten als kleine, selbst-organisierte Einheiten und bekommen von außen nur eine Richtung vorgegeben, bestimmen aber selbst die Taktik, wie sie ihr gemeinsames Ziel erreichen.“ Quelle:  Wikipedia

Im klassischen Projektmanagement verlaufen die meisten Projekte nach einem eher starren Schema. Ziele werden festgelegt (Lasten- und Pflichtenheft), Arbeitspakete erstellt, verteilt und jeder arbeitet dann für sich seine Aufgaben ab. Dem Projektmanager als zentrales Bindeglied obliegt die Kommunikation und Steuerung der einzelnen Projektmitarbeiter. In unserer zunehmend komplexeren und schnelllebigen Welt, funktioniert dieser klassische Ansatz immer weniger, da sich Anforderungen fortlaufend ändern und einer allein kaum mehr Herr über die Lage sein kann.

Vor diesem Hintergrund hat sich das agile Projektmanagement beziehungsweise die Scrum-Methode entwickelt.

 

Wie läuft Scrum ab?

Der Sprint

Ein wichtiger Teil der Planung in Scrum ist der Sprint und seine selbst gewählte Dauer (bei uns ist das ein Monat). Innerhalb des Sprints werden die Arbeitspakete von den Teammitgliedern individuell abgearbeitet, mit dem Ziel der Zusammenführung am Ende des Zyklus, sofern mehrere Personen an ein und demselben Projekt arbeiten. In den täglichen Standup-Meetings (Daily, Dauer max. 15 Minuten) werden untereinander die Pläne, Fortschritte und auch Probleme ausgetauscht, um gegebenenfalls rasch reagieren zu können.

Die Sprintplanung

Bevor ein Sprint startet wird die Sprintplanung durchgeführt. Dafür werden Userstories (Was sind die Anforderungen und Wünsche, die umgesetzt werden sollen?) aus dem Backlog (dem Speicher in dem priorisiert die Ideen und Projekte in Form von Userstories liegen) genommen und in Arbeitspakete aufgeteilt. In der Software- und Produktentwicklung ist das Ziel, dass am Ende des Monats testbare Elemente rauskommen, die nach erfolgreichem Test als abgeschlossen betrachtet werden können. Hierzu arbeiten mitunter mehrere Teammitglieder am selben Element und müssen sich koordinieren. Für den kurzen täglichen Austausch sind die Dailies gedacht, bei größerem Abstimmungsbedarf stimmen sich die Beteiligten direkt untereinander ab. Der Backlog wird permanent (in der Regel auf monatlicher Basis bei uns) neu priorisiert und die wichtigsten Themen können so rasch umgesetzt werden.

Die Nachlese: Sprintreview und Sprintretrospektive

Nach dem Sprint ist vor dem Sprint und im Sinne eines kontinuierlichen Verbesserungsprozess werden gemeinsam die Ergebnisse und Erkenntnisse des Sprints kurz analysiert. Im Review werden die Ergebnisse des Sprints besprochen und gezeigt, wohingegen die Retrospektive sich der Methode und dem Prozess annimmt. Was hat nicht so gut funktioniert und wo gibt es mitunter Verbesserungspotential? Diese Erkenntnisse des Teams können und sollen gleich als Verbesserung in die Planung des nächsten Sprints mit einfließen, auch das ein wichtiger Teil des agilen Projektmanagements.

Das Kanban-Board

Das Kanban-Board ist ein visuelles Hilfsmittel, dass mit einfachen Mitteln einen aktuellen Stand über den Status der Tasks innerhalb des Sprints gibt. Für den Scrum Master ist es zudem ein simples Tool das die Auslastung des Teams und den Fortschritt innerhalb des Sprint zeigt. Im Verlauf der Sprintplanung schätzt das Team gemeinsam, welches Arbeitspensum im Rahmen des Sprints umgesetzt werden kann. Die einfachste Ausprägung des Boards hat drei Spalten (To do, Doing, Done) und eine Zeile für jedes Mitglied. Komplexere Boards beinhalten noch persönliche Backlogs, die Auslastung, Urlaubsplanung bzw. Abwesenheiten,… sprich alles was für den Scrum Master zur Planung notwendig ist. Das Kanban-Board kann digital (z.B. auf Trello) oder analog sein (klassisch mit Post-it’s), beide Varianten haben ihre Vor- und Nachteile.

Der Scrum Master

Eine der wichtigsten Funktionen in Scrum. Er ist für den reibungslosen Ablauf des Scrum-Prozess zuständig, organisiert das Team, ist quasi der Zeremonienmeister und Moderator in Personalunion (im klassischen Projektmanagement wäre dies am ehesten der Projektmanager). Was hat er zu tun? Den Überblick behalten und dafür sorgen, dass am Ende des Sprints alle Aufgaben abgearbeitet wurden. Mögliche Hürden die dabei auftauchen, sollte er aus dem Weg räumen. Er sorgt für den regelmässigen Austausch der Teammitglieder, sorgt dafür das alle benötigten Infos vorhanden sind, beruft die Dailies ein und schaut das diese auch im Rahmen bleiben.

Der Product Owner (bei uns der Project Owner)

Der Product/Project Owner vertritt die Kundensicht im Prozess. Über den Backlog und die Userstory gibt er die Priorität der anstehenden Themen vor. Was möchte der Kunde? In welcher Qualität? Was ist der Nutzen für den Kunden? All diese Fragen sollen kurz und prägnant in einer User Story beantwortet werden, um die Kundenwünsche auch in Produkte oder Funktionen umzuwandeln. Im klassischen Projektmanagement ist diese Rolle am ehesten mit dem Produktmanager vergleichbar. Und das Pendant zur Userstory könnten Lasten- und Pflichtenheft sein, wobei hier der große Unterschied zu tage tritt. Wo ein Pflichtenheft versucht möglichst umfangreich zu sein und Planungssicherheit über den großen Zeitraum einer Produktentwicklung suggeriert, verfolgt die Userstory genau den umgekehrten Ansatz. Das runterbrechen in viele kleine Tasks, die schnell umsetzbar und testbar sind, die aber alle auf ein übergeordnetes Ziel einzahlen. So bleiben in einer zunehmend schnelllebigeren und komplexen Welt, Freiheitsgrade in der Projektplanung offen um den vorhandenen Unsicherheiten auf dem Weg zu begegnen und um seinen Plan (den Backlog und die Userstories) dann gegegebenfalls anzupassen.

 

Der zweite Teil gibt euch noch einen sehr persönlichen Eindruck, wie wir SCRUM und Kanban leben. In 2 Wochen könnt ihr euch auf den zweiten Teil des Blogs “Agiles Projektmanagement im Innovation Lab – die Zweite” freuen. Viel Spaß beim Lesen.

No comments so far.

Schreibe einen Kommentar

Your email address will not be published. Website Field Is Optional

16 − acht =