Agile Praktiken sind konkrete Umsetzungen der agilen Werte und Prinzipien. Durch die Kombination mehrer agiler Praktiken ergeben sich agile Methoden, wie beispielsweise Scrum. Einige, der in diesem Artikel beschriebenen Prakiken sind von agilen Methoden abgeleitet worden. Allerdings gilt für alle agile Praktiken, dass sie auch unabhängig von der gesamten Methode eingesetzt werden kann. Es empfiehlt sich sogar oft, die Agilität langsam in die Organisation einzuführen. Daher bieten diese Praktiken einzelne Startpunkte, um mit dem agilen Arbeiten zu beginnen.
Dieser Artikel gliedert die agilen Praktiken anhand des Plan-Do-Check-Zykluses. Das agile Arbeiten durchläuft einen Zyklus (ähnlich wieder PDCA- oder auch Deming-Cycle). Allerdings findet die letzte Phase (Act) meist in der nächsten Iteration statt. Somit geht es, nach der Check-Phase, weiter mit einer neuen Iteration. Viele Praktiken kann man einzelnen Phasen in diesem Zyklus zuordnen. Manche erstrecken sich allerdings über mehrere Phasen. Diese Praktiken werden in diesem Artikel als Querschnittsfunktionen bezeichnet und als erstes beschrieben.
Querschnittspraktiken
Bevor die Praktiken der einzelnen Phasen beschrieben werden, werden Querschnittsfunktionen näher erläutert. Zu den Querschnittsfunktionen zählen agile Praktiken, die mehr als eine Phase betreffen.Manche Funktionen und Praktiken begleiten die agile Vorgehensweise über mehrere Phasen hinweg. Somit ergeben sich Querschnittsfunktionen, die sich keiner Phase eindeutig zuordnen lassen können.
Praktiken
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.
Plan
Im Gegensatz zur weitläufigen Meinung, gibt es im Agilen viele planerischen Elemente. Diese haben eine sehr Bedeutung. Der Unterschied zum klassischen Projektmanagement ist allerdings der Planungshorizont. In der Agilität wird sehr wenig langfristig, aber sehr viel kurzfristig geplant. Dadurch bleibt ein Projekt/eine Organisation flexibel für Änderungen oder Probleme. Im agilen Arbeiten wiederholt sich also der der Planungsprozess regelmäßig. Dafür wurden verschiedene Praktiken entwickelt, die für die Agilität essenziell sind.
Plan-Praktiken
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
Do
Nach der Planung werden die Aufgaben – meist priorisiert – umgesetzt. Diese Phase setzt vor allem an den Werten der Zusammenarbeit an. Vor allem die agilen Praktiken Daily Standup und interdisziplinäre Teams verdeutlichen den Stellenwert von Interaktionen im agilen arbeiten.
Do-Praktiken
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).
Check
In jeder Iteration folgt nach der Durchführung, die Kontrollphase. Im agilen Manifest gehen mehrere Werte und Prinzipien auf den hohen Qualitätsanspruch ein. Die Qualität wird in der Check-Phase evaluiert. Allerdings beziehen sich nicht alle agile Praktiken dieser Phase auf die Produktqualität. Die Retrospektive beispielsweise bezieht sich auf Methodik und Verbesserungsprozess. So wird neben dem Output auch noch das Zusammenarbeiten und der Prozess der letzten Iteration bewertet.
Check-Praktiken
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.
Zusammenfassung
Agile Praktiken sind konkrete Handlungsempfehlungen, die die agilen Werte und Prinzipien umsetzen. Im Agilen Arbeiten wird ein ständiger Zyklus durchlaufen. Dieser Zyklus besteht aus drei grundlegende Phasen – Plan, Do, Check. Viele Praktiken gehören einer dieser Phasen an. Andere Praktiken erstrecken sich über mehrere Phasen und sind somit Querschnittsfunktionen. Agile Methoden und Frameworks bestehen aus verschiedenen agilen Praktiken. Agile Praktiken können allerdings auch unabhängig von Methoden und Frameworks eingesetzt werden. Beim Einführen von agilem Arbeiten empfiehlt es sich einzelne Praktiken zunächst unabhängig von Methoden zu anzuwenden. Diese herantastende Vorgehensweise ist vor allem zu empfehlen, wenn das Einführen von Agilität als große Herausforderung gesehen wird oder wenn mit großem Widerstand gerechnet wird.
Quellen/Literaturverzeichnis
Gloger, B. 2008: Scrum, Hanser München, Wien 2008.
Amazon Link
https://explore.versionone.com/state-of-agile/versionone-12th-annual-state-of-agile-report o.V. 2018a: Annual State of Agile Report, unter: https://explore.versionone.com/state-of-agile/versionone-12th-annual-state-of-agile-report, Stand: 09.04.2018, Abrufdatum: 21.06.06.2018.
Pichler, R. 2008: Scrum – agiles Projektmanagement erfolgreich einsetzen, 1. Aufl., dpunkt-Verl. Heidelberg 2008.
Amazon Link
Pröpper, N. 2012: Agile Techniken für klassisches Projektmanagement, 1. Aufl., mitp Heidelberg, München, Landsberg, Frechen, Hamburg 2012.
Amazon Link
Röpstorff, S./ Wiechmann, R. 2012: Scrum in der Praxis, 1. Aufl., dpunkt.verlag Heidelberg 2012.
Amazon Link
Scheller, T. 2017: Auf dem Weg zur agilen Organisation, 1. Auflage, Vahlen München 2017.
Amazon Link
Tools & Resources
Neben Blogartikeln finden Sie auf dieser Website Tools und Ressourcen. Diese können Ihnen bei der Anwendung helfen und sind größtenteils kostenlos. Beispiele:
- Plakate
- Templates
- Bücher
- …