Ein Beitrag von: Diplom-Kauffrau Marion Charlotte Willems

Marion Willems berät Unternehmen bezüglich Prozessmanagement, agilen Arbeitsweisen sowie digitalen Tools und Methoden der Artificial Intelligence. Nach dem Studium an den Universitäten Bonn (VWL) und Köln (BWL) war sie als Projektmanagerin für KPMG und PwC tätig. Außerdem hat sie ein Zertifikat über Artificial Intelligence von der MIT Sloan School of Management erhalten.

Kontakt
marion.willems@mcw-consulting.de, Tel.: +49 163 232-8414, www.mcw-consulting.de

Das Funktionieren agiler Frameworks setzt voraus,

• dass sich die Mitarbeiter eines Teams selbstverantwortlich auf ein gemeinsames Ergebnis mit Wertschöpfungsbeitrag verpflichten und fokussieren,
• dass in kleinen Zeitabschnitten gearbeitet wird,
• dass Kunden/Stakeholder in den Prozess einbezogen werden,
• dass Teams relativ klein sind, um effizient arbeiten zu können,
• dass es einen transparenten kontinuierlichen Verbesserungsprozess gibt,
• dass Mitarbeiter ein agiles Mindset mitbringen,
• dass man gemeinsame Werte und Prinzipien beachtet.

Die schnelle Produktentwicklung erfordert, dass Unternehmen cross-funktional und interdisziplinär die erforderlichen Kompetenzen zusammenziehen,
damit das auslieferungsfähige Produkt beziehungsweise die Dienstleistung allen Anforderungen der Kunden und Stakeholder gerecht wird. Hierzu ist eine regelmäßige Kommunikation über den Stand der Arbeitsfortschritte und eventuell auftretende Probleme unabdingbar.

Scrum ist „ein Rahmenwerk innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit höchstmöglichem Wert auszuliefern (3).“
Das Scrum-Rahmenwerk hat folgende Bestandteile:

1. Das Scrum Team bestehend aus den beteiligten Personen (Product Owner, Scrum Master und Entwicklungsteam),
2. Ereignisse („Events“):

• Sprint = Zeitrahmen, innerhalb dessen ein auslieferungsfähiges Produkt (Inkrement) erstellt wird
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospektive

3. Sogenannte Artefakte: Product Backlog, Sprint Backlog und Inkrement
4. Regeln, die Wechselwirkungen zwischen 1. bis 3. regeln

Scrum ist eine Prozesskontroll-Methode, die auf Erfahrung beruht. In einem sogenannten Sprint wird innerhalb von einem vordefinierten Zeitraum iterativ an einem nutzbaren und auslieferungsfähigen Inkrement in einer sehr strukturierten Art und Weise gearbeitet.
Der Auftraggeber (Product Owner) erstellt eine Anforderungsliste (Product Backlog (PBL)) mit Einzelaufgaben unter der Angabe von Prioritäten und Aufwandsschätzungen, die für die Erstellung eines Inkrements erforderlich ist. Siehe hierzu den Scrum Kreislauf in Schaubild 1:

In dem folgenden Sprint Planning beschließt das Entwicklungsteam, welche Aufgaben aus dem PBL mit Blick auf das Produkt, die Kapazitäten und bisherige Leistungen in dem Sprint zuverlässig abgearbeitet werden können. Es wird festgelegt, was wie zu erstellen ist. Hierzu werden die Product Backlog Einträge in noch detailliertere Aufgaben heruntergebrochen. Die Kriterien für ein fertiges Produkt oder Produktteile werden festgelegt (Definitions of Done): Output dieses Meetings sind ein Sprint Backlog mit den zu erledigenden Aufgaben sowie ein
Umsetzungsplan.
In einem täglichen Daily Scrum werden der aktuelle Stand der Arbeit und eventuell auftretende Hindernisse mit Blick auf das Produkt im Entwicklungsteam besprochen. Dies trägt zur Transparenz im Team bei. Der Output dieses Meetings ist ein angepasster Sprint Backlog mit „open“, „work in progress“ und „done“- Einträgen.
Im Anschluss an den Daily Scrum oder zwischen zwei Sprints findet zusätzlich noch ein Product Backlog Refinement statt, in dem gemeinsam mit Stakeholdern und dem gesamten Scrum Team die nicht fertigen Produkt Backlogeinträge für den nächsten Sprint ermittelt werden.
In einem Sprint Review wird anschließend das Produkt (Inkrement) inspiziert. Der Product Owner prüft die Ergebnisse und entscheidet, was „done“ ist und was nicht. Hier können auch weitere Stakeholder ihr Feedback geben. Am Ende wird ein angepasster Product Backlog erstellt.
Ziel eines Sprint Retrospective Meetings ist es, die Arbeit des Scrum Teams zu inspizieren und anzupassen. Die Arbeit des letzten Sprints wird bezüglich Tools, Prozessen Personen und Verbesserungsvorschlägen beurteilt.
Sprints wiederholen sich solange, bis am Ende das Produkt mit den gewünschten Eigenschaften in einem auslieferungsfähigen Zustand ist und Kunde und Stakeholder zufrieden sind.
Wichtig bei der Vorgehensweise ist das Zusammenspiel von Product Owner, Scrum Master (SM) und Entwicklungsteam sowie der Informationsaustausch über den Stand der Arbeit und über eventuelle Hindernisse.
Der Product Owner (PO) maximiert den Wert des Outputs für Kunden und Stakeholder, indem er klare Vorstellungen von den Aufgaben im Product Backlog in Abstimmung mit den Stakeholdern formuliert. In vereinzelten Ausnahmefällen kann er einen Sprint abbrechen.
Das Entwicklungsteam soll laut Scrum aus sieben plus minus zwei Teammitgliedern bestehen, weil Erfahrungen gezeigt haben, dass dies die optimale Gruppengröße für eine effektive Zusammenarbeit ist. Das Team stimmt das Ziel eines Sprints mit dem Product Owner ab, arbeitet ansonsten selbstführend und eigenveranwortlich. Es wählt selbst seine Arbeitspakete aus dem Product Backlog aus und teilt diese unter den möglichst interdisziplinären Mitgliedern auf. Jeder macht das, was er am besten kann. Es werden keine Fachkonzepte geschrieben. Das Product Backlog ist die bestimmende Richtschnur für den Output.
Der Scrum Master agiert nicht wie ein Projektmanager, sondern wie ein Coach oder servant leader, er hilft dem Team, das Ziel zu erreichen, Hindernisse aus dem Weg zu räumen und stellt sicher, dass die Sprints und Events in der beschriebenen Art und Weise ablaufen und die Scrum Werte und Prinzipien eingehalten werden. Hierbei achtet er auch auf die in Schaubild 1 dargestellten Zeitvorgaben, die für die jeweiligen Events vorgesehen sind.
Die Scrum-Methodik ermöglicht das fokussierte Arbeiten an einem Zieloutput mit regelmäßigen Feedbackschleifen und Optimierungen. Fehlentwicklungen werden so schneller als bei klassischen Wasserfallprojekten erkannt und behoben.

Mit Large Scale Scrumm (LeSS) gibt es ein Scrum-Rahmenwerk, das eine unternehmensweite Anwendung von Scrum in großen Projekten mit bis zu acht Teams mit je acht Personen ermöglicht. Das LeSS Rahmenwerk funktioniert wie ein Scrum Rahmenwerk, das einfach nur skaliert
wird.
Ein paar Unterschiede im Gegensatz zum single Scrum gibt es jedoch. So gibt es

• nur ein Product Backlog unternehmensweit, denn es geht nur um ein Produkt,
• eine Definition of Done Anforderung für alle Teams,
• ein potentiell auslieferbares Inkrement am Ende jeden Sprints,
• einen Product Owner, aber mehrere Scrum Master für die jeweiligen Scrum Subteams,
• einen Sprint.

Alle Teams legen fest, was zu erstellen ist. Daily Scrum und Product Backlog Refinements (PBR) und Retrospektiven finden jeweils in den einzelnen Teams statt. Zusätzlich gibt es „overall PBR“ und Sprint Reviews, die übergreifend mit allen Teams und dem PO stattfinden. Außerdem findet eine übergreifende Retrospektive mit dem PO, dem Scrum Master und im Wechsel mit ausgesuchten Vertretern der jeweiligen Scrum Subteams statt.
Für noch größere Projekte mit Tausenden von Mitarbeitern eignet sich LeSS Huge oder Scrum@Scale (5).

Kanban visualisiert Arbeitsabläufe bei Projekten, Dienstleistungen oder in der Produktion anhand einer Art Todo-Liste, dem Kanban Board. Auf dem Kanban Board, das im Schaubild 2 dargestellt ist, werden die Aufgaben in drei Gruppen eingeteilt, wobei nach Bedarf weitere Einteilungen
hinzugefügt werden können:

• noch zu erledigen (open),
• in Bearbeitung (work in progress) und
• erledigt (done) und für alle Projektmitarbeiter sichtbar gemacht.

Der Arbeitsfluss, Engpässe und Projektfortschritt werden so für alle transparent. Jeder Mitarbeiter ist für seine Aufgaben selbst verantwortlich und arbeitet an Verbesserungen des Arbeitsablaufs.
Ziel ist es, die „work in progress-Arbeiten“ zu limitieren, die Durchlaufzeiten von Arbeitspaketen zu erhöhen und den ganzen (Wertschöpfungs-) Prozess so zu verbessern, dass der Kunde zufrieden ist.
Der Vorteil von Kanban ist, dass die Methode leicht verständlich und sofort einsetzbar ist, ohne die Organisation oder die Rollen verändern zu müssen.

Die Erfolgsfaktoren von Scrum und Kanban liegen

• in der engen Zusammenarbeit mit den „Projektbeteiligten“,
• dem gemeinsamen „Ziehen an einem Strang“,
• der Transparenz der Prozesse,
• den stetigen Prozessverbesserungen beziehungsweise der Adaption an sich ändernde Anforderungen
• und der kontinuierlichen Analyse der Arbeitsergebnisse.

Die Fokussierung auf ein gemeinsames Ziel gelingt am besten mit gemeinsamen Werten und Prinzipien. Hierfür gibt es bei Kanban vier Prinzipien und sechs Praktiken (6) und bei Scrum das Agile Manifest (7), in denen sich die Mitarbeiter zu einer zielorientierten agilen Arbeitsweise
verpflichten.
Langwierige Entscheidungen über diverse Hierarchiestufen hinweg sind eher hinderlich. Aufgabenbezogene Netzwerke mit flachen Hierarchien hingegen tragen dazu bei, ein wertschöpfendes Produkt in hoher Qualität und kurzer Zeit zu entwickeln.