Von einer Vision geleitet zieht ein Experten-Team aus, um seine Mission Schritt für Schritt in Teilprodukten eigenständig zu erfüllen. Dabei werden Arbeitsweisen und entwickelte Produkte regelmäßig reflektiert und angepasst. Hierarchien sind dem Projektteam fremd. Doch auch wenn diese agile Methode immer beliebter wird: Erwarte bitte kein Wundermittel. SCRUM ist harte Arbeit!

Diesen Blogbeitrag möchte ich mit einem grundsätzlichen Hinweis zu SCRUM beginnen. Die Anwendung dieser agilen Methoden erscheint simpel: drei SCRUM-Rollen, sechs Meetings, acht Artefakte (s.u. Methoden). Es kommt jedoch auf die Verinnerlichung des zugrundeliegenden Wertesystems und Grundprinzipien an (vgl. www.agilemanifest.org).

Wie oft habe ich jedoch gehört „Wir sind agil – wir realisieren unsere Projekte mit SCRUM!“. Die nötige Unternehmenskultur war dabei nicht gegeben. Agilität lässt sich nicht vom Management anordnen. Dies wird nicht funktionieren. SCRUM kann nur dann seine Wirkung entfalten, wenn der Wille zur Veränderung tatsächlich gegeben und gelebt wird.

SRUM als Methode

SCRUM ist ein agiles Framework, welches vor allen in der Softwareentwicklung zum Einsatz kommt. In erster Linie handelt es sich hierbei um ein Managementframework, welches teamzentriert dazu führt, dass iterativ kundenorientierte Werte geschafft werden (vgl. Stephen Denning, The Leader’s Guide to Radical Management, 2010).

Ergo sind bei einer Einführung vom SCRUM und der Realisation von Projekten offene Konflikten vorprogrammiert.

Ein SCRUM-TAM besteht dabei klassisch aus drei SCRUM-Rollen: dem Entwicklungsteam, dem Scrum Master und dem Product Owner. Diese würde ich, aus der Praxis kommend, um die Rollen des Auftraggebers, des Kunden und des Managements erweitern (siehe den kommenden Blog-Beitrag). Der Produktentwicklungsprozess wird vom Scrum Master initiiert und kontrolliert, wobei er von der Produktentwicklung nicht direkt betroffen ist.

Zu Beginn steht die Produktidee. Diese wird vom Auftraggeber an den Product Owner herangetragen. Alleine oder gemeinsam mit dem Projektteam und optional dem Kunden / den Interessenvertretern erarbeitet der Product Owner hieraus das grundlegende Produktkonzept (Produktvision). Dieses beschreibt grob die Kundenbedürfnisse, Leistungsmerkmale und Zielgrößen wie Alleinstellungsmerkmale, Nutzen oder wichtige Funktionalitäten.

Im Anschluss werden diese im Product Backlog, einer langen Liste, in groben Epics oder User Stories (siehe Artefakte) aufgebrochen und niedergeschrieben. Der Product Owner bringt diese Liste durch Priorisierung in eine Reihenfolge. Hoch priorisierte Epics bricht er, zur Vorbereitung des ersten Sprint Plannings, in Anforderungen (User Stories) herunter. Jede User Story beinhaltet entsprechende Akzeptanzkriterien (Definition of Done). Dabei kann eine User Story durch das Team in kleinere Tasks / Issues unterteilt werden.

Im Rahmen der strategischen Planung wird das Product Backlog initial durch das Team auf seinen Umfang geschätzt. Das Ergebnis wird dem Product Owner mitgeteilt. So gewinnt dieser einen ersten Eindruck, mit welchem Aufwand zu rechnen ist. Gleichzeitig hat das Team eine Vorstellung wie das zukünftige Produkt aussehen soll.

Im Anschluss startet die Umsetzung mit einer taktischen Planung. Diese wird in zwei Meetings unterteilt. Dem Sprint Planning Meeting 1, in welchem der Product Owner, das Team, der Scrum Master und ggf. der Kunde das Ziel des Sprints festlegen. Hier wird definiert welche User Stories oder auch Tasks im kommenden Sprint realisiert werden sollen. Die Summe der Anforderungen wird in SCRUM als Selected Backlog bezeichnet. Ein Sprint umfasst dabei i. d. R. zwei bis vier Wochen.

Im Sprint Planning Meeting 2 definiert das Team gemeinsam mit dem Scrum Master und optional dem Product Owner, wie das Ziel erreicht werden soll. Hier entsteht das sogenannte Sprint Backlog.

Im Daily Scrum bzw. StandUp, trifft sich das Team, der Scrum Master und der Product Owner um ihre Aufgaben eigenständig abzustimmen. Näheres hierzu im Blog-Beitrag zum Thema Meetings in SCRUM.

Gemeinsam mit dem Product Owner bereitet das Team während des laufenden Sprints den nächsten Sprint vor. Dieses beinhaltet die Aktualisierung des bestehende Product Backlogs und der Aufwandsschätzung. Dieses Meeting wird als Estimation Meeting bzw. Backlog Refinement bezeichnet und liefert die Basis für die spätere Releaseplanung.

Im Sprint Review werden die Ergebnisse vom Team dem Product Owner und optional weiteren Stakeholdern präsentiert. Sind genug Funktionalitäten realisiert und freigegeben, wird im Anschluss ein Release (Veröffentlichung) erfolgen.

Im Nachgang erfolgt eine Sprint Retrospektive. In dieser führt das Team mit dem Scrum Master Manöverkritik aus. Bei sehr hoher Vertrauensbasis darf der Product Owner ebenfalls teilnehmen. Ziel ist es die eigenen Arbeitsprozesse zu optimieren.

Als Projektmanagementmethode hilft SCRUM Projektteams dabei, konzentriert und fokussiert, aufgrund von kurzen Sprints, zu arbeiten. Mit einem Scrum Master als „Teamleiter“ und einem Product Owner als „Projektleiter“ übernehmen viele Unternehmen bei der Umstellung vom klassischen auf agiles Projektmanagement die altbekannten Rollen. Herausfordernder ist es eine adäquate Rolle für das bisherige Management zu finden. Eine Möglichkeit, wie dies gelingen kann, beschreibe ich im Blogbeitrag „SCRUM Rollen“.

Schwerer fällt es Unternehmen im Wandel die Artefakte zu übertragen. So stellt das Backlog z. B. keine Projektplanung dar: Die aus dem klassischen Projektmanagement kommende Denkweise, zu Beginn zu definieren, was wann fertig sein wird, widerspricht der rollierenden Planung des agilen Ansatzes. So wird das finale Projektziel in SCRUM erst nach und nach erarbeitet bzw. greifbar.

Impressum | Datenschutz