Agile Praktiken im Überblick

Der Dedicated Customer (in Scrum Product Owner genannt) ist eine Funktion bzw. eine Rolle. Er ist verantwortlich für die Umsetzung der Kundenanforderungen. Somit ist er vergleichbar mit dem klassischen Projektmanager, daher der Product Owner ebenfalls die Verantwortung des Projekts trägt. Er integriert sich in den Prozess als Schnittstelle zwischen Team und Kunde (vgl. Pichler, R. 2008: S. 10-12).
Zu den Aufgaben des Product Owner zählen: Anforderungen und Kundenbedürfnisse verstehen Kundenbedürfnisse priorisieren Erfüllung der Kundenbedürfnisse überprüfen. Damit setzt der Product Owner vor allem den dritten Wert (Zusammenarbeit mit dem Kunden) des agilen Manifests um. Durch den starken Kundenfokus, sowie durch das flexible Priorisieren der Kundenbedürnisse, vor jeder Iteration, schafft der Product Owner einen Mehrwert im agilen Arbeiten.
Bekannt ist die Rolle des Product Owners aus Scrum. Dort gehört der Product Owner zu den drei essenziellen Rollen der Scrum-Methode. Allerdings wird die Rolle auch unabhängig von Scrum eingesetzt.

Das Product Backlog besteht aus mehreren Elementen, die jeweils eine Funktionalität bzw. eine Produktanforderung wiederspiegeln. Somit ist das Product Backlog das wichtigste Werkzeug des Product Owners. Dessen Aufgabe ist es, das Product Backlog – gemäß der Kundenanforderungen – zu pflegen und die Aufgaben vor jedem Sprint zu aktualisieren. Um ein Product Backlog zu erstellen, braucht es zunächst ein genaues Verständnis der Kunden-/Produktanforderung und eine klare Produktvision. Das Product Backlog kann als Software geführt werden. Um die Transparenz und den Informationsfluss zu steigern, empfiehlt sich allerdings ein physisches Product Backlog zu führen, das für alle einsehbar ist. Das wird meist getan, indem das Product Backlog auf dem Scrum Board visualisiert wird. Dazu werden die einzelnen Elemente des Product Backlogs, in der Spalte Product Backlog, priorisiert aufgelistet. Das Team entscheidet dann welchen Umfang an Elementen es für den nächsten Sprint vorsieht. Die ausgewählten Elemente – mit Rücksicht auf die Priorisierung – wandern in die nächste Spalte. Diese Elemente werden somit im aktuellen Sprint vom Team umgesetzt. Durch diese individuelle Anpassung vor jedem Sprint gewinnt das Vorgehen an Agilität und es wird sichergestellt, dass die priorisierten Kundenanforderungen nicht vernachlässigt werden können. Das Product Backlog ist ebenfalls ein wesentlicher Bestandteil der Scrum-Methode. Wie jede andere agile Praktik, kann auch das Product Backlog unabhängig einer agilen Methode eingesetzt werden.

Bei der Praktik Weekly Cycle wird die länge einer Iteration bzw. eines Sprints auf eine Woche festgesetzt. In der Iteration sind die Phasen Plan, Do und Check enthalten. Durch die klare Regelung der Iterationsdauer kann ein effektiver Regelprozess entstehen. Das klingt zunächst kaum nach Agilität und kann eher als Nebenerscheinung angesehen werden. Der Grund für Weekly Cycles ist eher das konsequente kurz Halten von Iterationen. Dadurch bleibt das Vorgehen flexibel für Veränderungen und die Kommunikation wird gestärkt.

Kanban enstand im weltbekannten Toyota-Produktionssystem und bedeutet übersetzte Signalkarte. Das Ziel von Kanban ist es, die Anzahl der parallel durchgeführten Aufgaben zu minimieren. Dazu wird der Prozess auf einer Karte bzw. einem Kanban-Board visualisiert. In Folge dessen wird das Vorgehen genaustens beobachtet und es werden Verbesserungspotenziale ausgeschöpft. Darüberhinaus werden in Kanban ebenfalls die Aufgaben flexibel priorisiert. Kanban kann sowohl als agile Praktik, als auch als agile Methode angesehen werden. Auf dieser Website wird Kanban ausführlich beschrieben und ist über diesen zu erreichen.

Ein Informationsreicher Arbeitsplatz visualisiert, im agilen Arbeiten typischerweise, das aktuelle Projekt sowie den Fortschritt des Projekts. Außerdem werden meist weitere relevante Informationen dargestellt. Dazu zählen zum Beispiel: Kundenanforderungen, Design des Produkts/der Software. Anleitungen, um einen informationsreichen Arbeitsplatz zu gestalten, liefern Scrum und Kanban. Bei diesen Methoden werden Boards eingesetzt, die das Projekt und die Kundenanforderungen visualiseren. Das verbessert nicht nur den Informationszugang, sondern stärkt außerdem die Kommunikation. Der Informationszugang soll vor allem Missverständnisse vermeiden und sicherstellen, dass alle den gleichen Informationsstand haben und niemand in eine falsche Richtung arbeitet. Durch die erhöhte Kommunikation ist es möglich Einwände, Ideen, Erfahrungen und Verbesserungsvorschläge auszutauschen.

Das Einbinden von echten Kunden (bzw. echten Anwendern falls es sich um ein B2B Produkt o.Ä. handelt) setzt erneut den dritten Wert des agilen Manifests um. Dieser Wert manifestiert die Zusammenarbeit mit dem Kunden. Durch das Einbinden wird anhand von Realitätschecks sichergestellt, dass die Kundenanforderungen verstanden wurden und korrekt umgesetzt werden. Diese Praktik findet meist in der Check-Phase statt. Bei Scrum zählt es beispielsweise zum Standardvorgehen, dem Kunden nach jedem Sprint ein funktionsfähiges Teil eines Produkts auszuliefern und Feedback zu erhalten. Einbinden von Kunden wird außerdem in der Planungsphase agewendet. Da ist es wichtig die Kundenanforderungen zunächst zu verstehen und zu prioirisieren.

Definition of Done beschreibt deutlich, wann eine Aufgabe bzw. eine Teilfunktion eines Produkts erfüllt wurde. Durch diese Definition wird sichergestellt, dass ein einheitlicher Qualitätsstandard erreicht wird.

Die am zweitmeisten verbreitete Praktik ist das Iteration Planning (vgl. o.V. 2018a: S. 9). In Scrum wird das Iteration Planning meist Sprint Planning genannt. Diese Praktik hat die Funktion die nächste Iteration zu planen (vgl. Scheller, T. 2017: S. 499). Daher folgt das Iteration Planning meist auf den Daily Scrum (vgl. Scheller, T. 2017: S. 489-490). Für das Iteration Planning werden Produktanforderungen aus einem priorisierten Anforderungskatalog (auch Product Backlog genannt) abgeleitet um in der nächsten Iterationsphase umzusetzen (vgl. Scheller, T. 2017: S. 499).

Das Release Planning hat Ähnlichkeiten mit einem Projektplan. Es erfüllt den Zweck Funktionalität mit Kosten und Zeit in Einklang zu bringen. Der Unterschied zum klassischen Projektplan ist, dass im Releaseplan keine detaillierte Vorgehensweise zu finden ist. So werden beispielsweise die Anzahl der Iterationen abgeschätzt, jedoch nicht was in diesen Iterationen stattfindet (vgl. Pichler, R. 2008: S. 49-52).

Das Planungspoker ist eine interaktive Schätzmethode bei der die Teammitglieder in einem Schätzspiel miteinander interagieren, um so den Aufwand einer Produktanforderung abschätzen zu können (vgl. Pichler, R. 2008: S. 60). 

Das Release Burndown ist eine visuelle Darstellung des aktuellen Fortschritts im Hinblick auf den nächsten Release.

User Stories sind Beschreibungen eines Features aus Kundensicht. Bei Jobs-to-be-done beschreibt der Kunde, was er/sie mit dem Feature erreichen möchte. Das hilft den Entwicklern, die Lösung genau auf das Kundenproblem auszulegen, ohne sich von unwichtigen Dingen ablenken zu lassen. Bei ebay könnte das zum Beispiel so aussehen:

• Job-to-be-done: Ich möchte ein gebrauchtes Fahrrad kaufen – schnell und unkompliziert.
• User Story: „fahrrad“ suchen > Wichtigste Filter für das Fahrrad setzen > Postleitzahl und Radius eingeben > Angebote mit Bildern ansehen > Anbiete anschreiben oder anrufen

Das Daily Standup (in Scrum auch Daily Scrum genannt) verkörpert die agilen Werte wie kaum eine andere Praktik. Es wird von vielen Experten als das A und O der agilen Kommunikation bezeichnet (vgl. Nowotny, V. 2016: S. 80-81). Der Daily Standup ist eine auf 15 Minuten angesetzte Besprechung, die an jedem Tag am selben Ort zur selben Zeit stattfindet (vgl. Pichler, R. 2008: S. 104). Daran nehmen alle Teammitglieder sowie der Product Owner teil (vgl. Pichler, R. 2008: S. 104). Es findet im Stehen statt und wird vor dem Board ausgeführt (vgl. Pichler, R. 2008: S. 104). Der Ablauf des Daily Standup ist eindeutig strukturiert. Jedes Teammitglied beantwortet folgende drei Fragen (vgl. Pichler, R. 2008: S. 105; vgl. Pröpper, N. 2012: S. 93; vgl. Scheller, T. 2017: S. 489).

• Welche Aktivitäten habe ich gestern ausgeführt?
• Was beabsichtige ich heute zu tun?
• Werde ich in irgendeiner Form an der Ausführung behindert?

Das Daily Standup dient allerdings nicht zum Lösen der Probleme. Sondern lediglich zum Aufzeigen dieser Probleme. Dadurch wird Transparenz und Verständnis für die aktuelle Situation geschaffen (vgl. Pichler, R. 2008: S. 105). Dieser tägliche Austausch ermöglicht eine reibungslosere Projektdurchführung (vgl. Scheller, T. 2017: S. 489-490).

Die meistgenutzte Praktik der Durchführungsphase sind kurze Iterationen\u003cstrong\u003e. \u003c/strong\u003eIterationen werden in der Agilität bevorzugt kurz gehalten daher dadurch der Prozess leichter steuerbar ist und bei unvorhergesehenen Ereignissen schneller reagiert werden kann als bei längerfristig geplanten Phasen (vgl. \u003cem\u003eScheller, T.\u003c/em\u003e 2017: S. 252).

Eine weitere Umsetzungsform der Durchführung der Agilität sind Common Work Areas. Das sind Räumlichkeiten in denen Teams die Möglichkeit haben sich schnell untereinander räumlich zusammenzufinden. Dadurch wird ein hohes Maß an Kommunikation und Selbstorganisation gefördert (vgl. \u003cem\u003eScheller, T.\u003c/em\u003e 2017: S. 488).

Die Wichtigkeit der Retrospektive wird von Gloger unterstrichen. In seinem Buch Scrum bezeichnet er die Retrospektive als »das Herzstück des Scrum-Prozesses« (Gloger, B. 2008: S. 212), da diese den Deming-Cycle schließen. Die Retrospektive ist dafür vorgesehen, den Arbeitsablauf zu verbessern. In der Retrospektive diskutieren Team, Scrum Master und Product Owner über den Ablauf und die Methodik der vorangegangenen Iteration. Das Ziel der Retrospektive ist es, den Arbeitsablauf und die Methodik vor Störfaktoren zu schützen. Durch die Praktik der Retrospektive werden die agilen Methoden sowie anderen Prozesse einem kontinuierlichen Verbesserungsprozess ausgesetzt (vgl. Gloger, B. 2008: S. 212-217).

Neben den Retrospektiven sind die Iteration Reviews (in Scrum Sprint Reviews genannt) ein elementarer Teil der Überprüfungsphase. In diesen Reviews werden die Ziele der vorangegangenen Iteration überprüft. Daran nehmen sowohl die Teammitglieder als auch weitere relevante Stakeholder teil (vgl. Pichler, R. 2008: S. 107-109; vgl. Röpstorff, S./ Wiechmann, R. 2012: S. 237-239).

Die Ursachenanalyse setzt es sich zum Ziel keine Symptome, sondern Ursachen von Problemen an der Wurzel zu identifizieren. Dazu gibt es verschiedene Methoden, wie beispielsweise die Methode der 5 Whys. Bei dieser Methode wird das Problem fünf mal mit einem Warum hinterfragt. Somit wird das Problem auf einer tieferwerdenden Flugebene begutachtet.

Freuquent Releases bedeutet häufige Veröffentlichungen und ist eine wichtige Praktik im Lernprozess. Diese Praktik basiert auf dem dritten agilen Prinzip »Liefere funktionsfähige Leistung regelmäßig…« und steht für die häufige Auslieferung an den Kunden sowie die damit einhergehende Absprache mit dem Kunden. Dabei gilt die Faustregel: Eher wenige vollständige Produktanforderungen zu liefern, statt mehrere unfertige Produktanforderungen. Dadurch kann der Kunde gewisse Produktfunktionen möglichst realitätsnah testen. Durch die Frequent Releases soll sichergestellt werden, dass die Erwartungen des Kunden verstanden und erfüllt werden. Außerdem kann Verschwendung, in Form von Übererfüllung oder vom Kunden nicht benötigte Features, eliminiert werden.