5.1 Scrum

Scrum ist ein Rahmenwerk für Prozesse, die auf die Herstellung komplexer Produkte abzielen. Erfunden wurde Scrum von Ken Schwaber und Jeff Sutherland, welche an der Verfassung des Agilen Manifests mitgewirkt haben (vgl. Schwaber / Sutherland 2014: S. 137). Im Folgenden wird zunächst der generelle Ablauf von Scrum in seinen Grundzügen erläutert, bevor anschließend untersucht wird, wie sich Scrum auf Six Sigma Projekte übertragen lässt.

 

5.1.1 Vorstellung der Methodik

Der Scrum-Prozess ist in Bild 1.1 dargestellt und beginnt mit der Vision des Product Owners, also der Person, die das fertige Produkt schließlich nutzen möchte (vgl. Hanser 2010: S. 68-69; Schwaber / Sutherland 2014: S. 57). Hierbei schildert er, wie er sich das Produkt konkret vorstellt und welche Eigenschaften es aufweisen sollte. Anschließend wird der Realisierungsaufwand geschätzt sowie eine grobe zeitliche Planung vorgenommen. Ähnlich wie in der Define-Phase von Six Sigma Projekten, steht hierbei die Frage im Vordergrund, welchen Nutzen das Projekt hat und ob sich die Durchführung lohnen würde (vgl. Hanser 2010: S. 68-69).
Sofern Einigkeit über die Sinnhaftigkeit des Projektes herrscht, wird der Scrum- Prozess fortgesetzt, indem der Product Owner das Product Backlog anfertigt. Dabei handelt es sich um ein Dokument, welches eine Priorisierung aller Anforderungen an das Produkt aufweist. Die Erfüllung der aufgelisteten Anforderungen bildet letztendlich die Grundlage für die weitere Projektarbeit (vgl. Hanser 2010: S. 68-69).

Sind die Anforderungen bestimmt und kommuniziert worden, erfolgt die eigentliche Arbeit am Produkt. Da Projekte oft komplex und unübersichtlich sind, wird das Gesamtprojekt in mehrere kleine Arbeitszyklen aufgeteilt. Diese Zyklen werden als „Sprints“ bezeichnet und umfassen einen Zeitraum von maximal einem Monat, wobei jeder Sprint die gleiche Dauer aufweisen sollte. Ziel jedes Sprints ist die Fertigstellung einer nutzbaren Software, die bestimmte Anforderungen aus dem Product Backlog erfüllt. Die Menge der ausgewählten Anforderungen für jeden Sprint wird als Sprint Backlog bezeichnet. Grob ausgedrückt, beantwortet das Sprint Backlog die Frage, über welche Funktionen die Software nach dem bevorstehenden Sprint verfügen sollte. Es stellt außerdem einen Plan dafür dar, welche Aufgaben zur Implementierung dieser Funktionen bewältigt werden müssen. Allerdings handelt es sich hierbei um keinen endgültigen Plan, da das Entwicklungsteam diesen während eines Sprints jederzeit anpasst.Hierdurch kann auf Probleme reagiert werden und neue Lösungsansätze werden nicht ignoriert (vgl. Schwaber / Sutherland 2017: S. 9, 10, 17).
Jeder Sprint beginnt mit dem Sprint Planning, bei dem der Ablauf des bevorstehenden Sprints geplant wird. Dieses Meeting sollte nicht länger als acht Stunden andauern. Hier klärt das Entwicklungsteam gemeinsam mit dem Product Owner die Ziele des Sprints sowie die Inhalte des Sprint Backlogs. Nach Abschluss des Sprint Plannings sollten alle Beteiligten die gleiche Vorstellung davon haben, an welchen Funktionen im Laufe des nächsten Sprints gearbeitet wird. Außerdem sind die hierzu nötigen Aufgaben ebenfalls offen kommuniziert worden. Sofern die Inhalte des bevorstehenden Sprints geklärt worden sind, beginnt das Entwicklerteam mit der Arbeit (vgl. Schwaber / Sutherland 2017: S. 11–12).
Während des Sprints findet täglich eine kurze Teambesprechung statt, genannt „Daily Scrum“. Diese sollte nicht länger als 15 Minuten dauern und stets zur selben Zeit, sowie am selben Ort stattfinden. Ziel des Meetings ist der Austausch aller Teammitglieder untereinander, um den aktuellen Stand des Projekts zu besprechen. Jedes Mitglied kann hierbei Probleme ansprechen, für die das Team Gegenmaßnahmen erarbeitet. Außerdem wird während des Meetings offen kommuniziert, wer im Laufe des Tages an welcher Aufgabe arbeitet, wodurch eine hohe Transparenz untereinander herrscht (vgl. Preußig 2015: S. 149–150).
Das Ende des Sprints bildet die Fertigstellung eines sogenannten „Inkrements“. Hierbei handelt es sich um eine funktionierende und somit nutzbare Software (vgl. Schwaber / Sutherland 2014: S. 20, 21, 86). Anschließend findet die Abnahme des Inkrements durch den Product Owner statt, welche als „Sprint Review“ bezeichnet wird. Des Weiteren reflektiert das Projektteam im Zuge der Sprint-Retrospektive über den Ablauf des vergangenen Sprints und diskutiert über mögliche Verbesserungsmaßnahmen. Anhand der gesammelten Erfahrungen während des vergangenen Sprints kann auf diese Weise die Zusammenarbeit für den nächsten Sprint verbessert werden. Die Retrospektive bildet den Abschluss des vergangenen Sprints, womit der nächste Sprint gestartet werden kann (vgl. Hanser 2010: S. 68-69).

 

5.1.2 Anwendbarkeit bei Six Sigma Projekten

Nachdem erläutert wurde, was gemeinhin unter agilen Methoden zu verstehen ist, stellt sich die Frage, ob diese für eine Anwendung bei Six Sigma Projekten geeignet sind. Der Projektstrukturplan bei Six Sigma Projekten ist gemäß dem DMAIC-Zyklus phasenorientiert. Jede nachfolgende Phase baut auf den Ergebnissen der vorangegangenen Phase auf.
Abhängig vom Umfang und der Komplexität des zu lösenden Problems liegt die Projektlaufzeit von Six Sigma Projekten in der Regel zwischen drei bis sechs Monaten. (vgl. Schmieder 2005: S. 105). Daher dauert es entsprechend lange, bis eine Verbesserung der Ausgangssituation und der vorliegenden Problematik erreicht wird. Das Projekt durchläuft zuvor in den einzelnen Phasen zahlreiche Messverfahren und Analysen, bevor mit der tatsächlichen Optimierung begonnen wird. Für den Kunden äußert sich der Nutzen des Projekts entsprechend erst nach mehreren Monaten. An diesem Problem setzt einer der Vorteile von agilen Methoden an. Hier ist der Ansatzpunkt der agilen Methoden, die sich unter anderem durch ihren inkrementellen Arbeitsablauf in Form von mehreren Zyklen auszeichnen (vgl. Abrahamsson et al. 2002: S. 17). Auf diese Weise erhält der Kunde bereits nach verhältnismäßig kurzer Zeit Zwischenergebnisse, von denen er profitieren kann. Im Folgenden soll daher unter anderem überprüft werden, ob sich derartige Zyklen auf Six Sigma Projekte übertragen lassen. Des Weiteren kann der bekannte DMAIC-Zyklus bei Six Sigma Projekten eventuell um Aspekte aus agilen Methoden erweitert werden. Welche Elemente von agilen Methoden stellen einen Mehrwert für Six Sigma Projekte dar?

 

5.1.2 Anwendung ausgewählter agiler Methoden bei Six Sigma Projekten

Den Hauptbestandteil von Scrum bilden die Sprints, welche regelmäßig für neue Ergebnisse sorgen. Der Kunde muss also nicht erst das Gesamtergebnis abwarten, sondern kann bereits mit den Zwischenergebnissen arbeiten und diese nutzen. Ein solches Sprint-Prinzip lässt sich auch auf Six Sigma Projekte übertragen.
Wie eine solche Adaptierung aussehen könnte, haben Mohamed Amr und Ayman Khalifa in Ihrem Artikel „Agile and Six Sigma, how do they mix together“ beschrieben. Anstelle des üblichen DMAIC-Ablaufs, bei der der gesamte zu verbessernde Prozess jede Phase durchläuft, werden jeweils in mehreren Zyklen einzelne Fragmente des Prozesses bearbeitet. Lediglich die Define- Phase wird einmalig für den Gesamtprozess durchlaufen, um das Problem zu definieren und an alle Teammitglieder zu kommunizieren. Alle weiteren Phasen des DMAIC-Zyklus werden anschließend in mehreren Sprints durchlaufen, wie in Bild 1.2 dargestellt (vgl. Amr / Khalifa o.J.).



Nach Abschluss der Define-Phase folgt zunächst ein Sprint Planning. Hier legt das Team fest, an welchen Aspekten der Problemstellung im kommenden Sprint gearbeitet werden soll. Daraufhin werden die üblichen Phasen eines Six Sigma Projektes in Form eines Sprints durchlaufen (Measure, Analyze, Improve, Control). Diese sollten nach wie vor mit derselben Sorgfalt durchgeführt werden, wie beim klassischen DMAIC-Zyklus, allerdings konzentriert auf die vorher festgelegten Aspekte. Jeder Sprint wird außerdem von täglichen Meetings begleitet, den Daily Scrums. Dies verhindert, dass die Projektbeteiligten aneinander vorbei arbeiten und sorgt für eine konstante Kommunikation innerhalb des Teams. Sofern die Arbeitspakete möglichst klein gehalten wurden, dauert ein solcher Sprint ca. zwei Wochen, bevor das erste sogenannte „Prozess Inkrement“ implementiert werden kann. Hierbei handelt es um eine Prozessverbesserung kleineren Umfangs (vgl. Amr / Khalifa o.J.). Auf diese Weise kann bereits nach relativ kurzer Zeit eine Verbesserung geschaffen werden.
Am Ende des Sprints folgt, wie beim üblichen Scrum-Ablauf, die Sprint- Retrospektive, bei der das Team den zurückliegenden Sprint Revue passieren lässt. Hier werden gesammelte Erkenntnisse ausgetauscht, um zukünftige Sprints effektiver und effizienter zu gestalten. Die abgeschlossene Retrospektive bildet das Ende des Sprints, woraufhin sich der Zyklus wiederholt und mit dem nächsten Sprint Planning begonnen werden kann (vgl. Hanser 2010: S. 69). Durch diesen Ablauf muss nicht das gesamte Projekt durchlaufen werden, bevor spürbare Ergebnisse eintreten. Schritt für Schritt werden Prozessverbesserungen implementiert, von denen der Kunde bereits profitieren kann.

 

5.1.3 Nutzen der Anwendung

Die zusätzlichen Meetings, in Form von Sprint Plannings, Daily Scrums und Retrospektiven, sorgen für eine bessere Kommunikation im Projektteam. Die Teammitglieder befinden sich in einem ständigen Austausch untereinander und können zu jeder Zeit über den weiteren Projektablauf diskutieren. Gleichzeitig wird die fortlaufende Projektplanung verbessert, da das Team lediglich kurze Zeiträume planen muss, bevor es zu einem erneuten Meeting kommt. Folglich gestaltet sich die Projektarbeit effektiver, da regelmäßig kommuniziert wird, wer für die Erledigung welcher Aufgaben verantwortlich ist. Hierdurch werden Unklarheiten beseitigt und alle Beteiligten sind sich ihrer Verantwortlichkeiten bewusst.
Die eingeführten Sprints führen zu regelmäßigem Projektoutput. Im Gegensatz zum üblichen DMAIC-Zyklus, sehen sowohl das Projektteam als auch der Kunde bereits nach kurzer Zeit spürbare Ergebnisse. Die einzelnen Verbesserungen sind zwar eventuell von geringem Ausmaß, doch sie sorgen für spürbare Teilerfolge und somit für Motivation bei allen Beteiligten. Außerdem erfährt der Kunde auf diese Weise bereits relativ frühzeitig einen Nutzen vom Projekt, da er von den bereits implementierten Verbesserungen Gebrauch machen kann.
Des Weiteren können implementierte Verbesserungen besser auf ihre Wirksamkeit hin überprüft werden. Während mehrere Sprints durchlaufen werden, können die aus vorherigen Sprints entstandenen Verbesserungen parallel kontrolliert werden. Falls nötig, können hier bereits Anpassungen vorgenommen werden. Laut Ken Schwaber und Jeff Sutherland liegt in dieser Transparenz der große Vorteil von Scrum. Durch spürbare Ergebnisse nach jedem Sprint wird die geleistete Arbeit für alle Beteiligten ersichtlich und es fällt leichter, über die nächsten Schritte nachzudenken (vgl. Schwaber / Sutherland: 2014 S. 64). Das Projektteam kann so flexibler auf unerwartete Probleme reagieren, als bei einer Implementierung, die erst nach monatelanger Arbeit erfolgt.

 

Navigation

1. - 4. Einleitung

5.1 Scrum

5.2 Design-Thinking

5.3 Kanban




Literaturverzeichnis

  • Amr / Khalifa o.J. Amr, Mohamed / Khalifa, Ayman: Agile and Six Sigma, how do they mix together?, o.J., online unter: https://www.agilealliance.org/resources/experience-reports/agile-six-sigma-mix- together/, [Stand: 28.05.2018].
  • Goll / Hommel 2015 Goll, Joachim / Hommel, Daniel: Mit Scrum zum ge- wünschten System, Wiesbaden: Springer Fachmedien Wiesbaden, 2015, online unter: https://link.springer.com/content/pdf/10.1007%2F978-3-658-10721-5.pdf, [Stand: 28.05.2018].
  • Hanser 2010 Hanser, Eckhart: Agile Prozesse: Von XP über Scrum bis MAP, Berlin: Springer-Verlag Berlin Heidelberg, 2010, online unter: https://link.springer.com/content/pdf/10.1007%2F978-3-642-12313-9.pdf, [Stand: 28.05.2018].
  • Preußig 2015 Preußig, Jörg: Agiles Projektmanagement. Scrum, Use Cases, Task Boards & Co., Freiburg: Haufe-Lexware GmbH & Co. KG, 2015, online unter: https://www.wiso-net.de/document/HAUF,AHAU,VHAU 9783648065198236, [Stand: 28.05.2018].
  • Schwaber / Sutherland 2014 Schwaber, Ken / Sutherland, Jeff: Software in 30 Tagen. Wie Manager mit Scrum Wettbewerbsvorteile für ihr Unternehmen schaffen, Heidelberg: dpunkt.verlag GmbH, 2014.

agile Methoden


Der Begriff „agil“ selbst beschreibt keine Methode, sondern eine bestimmte Denkweise. Dies bedeutet allerdings nicht, dass keine agilen Methoden existieren. Hierbei handelt es sich unter anderem um Methoden wie Scrum, Design-Thinking und Kanban. Diese Methoden werden in dem folgenden Artikel „Anwendung ausgewählter agiler Methoden bei Six Sigma Projekten" beschrieben.

 

Flexibles Projektmanagement ist ein Teil der agilen Methoden. APQC hat zu diesem Bereich eine kurze Umfrage durchgeführt.
 

Six Sigma Deutschland GmbH – Ihr Spezialist für Six Sigma Trainings

DMC Firewall is a Joomla Security extension!
Cookies erleichtern die Bereitstellung unserer Dienste. Mit der Nutzung unserer Dienste erklären Sie sich damit einverstanden, dass wir Cookies verwenden.
Ok