Agile Moderation

Ob und wie sich die Ideen der agilen Produktentwicklung auf die Moderation von Gruppen und Teams übertragen lassen

Thomas Tiller

• Verlag: Books on Demand
• Jahr: 2018
• eBook-ISBN: 9783748166283
• Auflage: 1
• Thema: Business
• Thema: Business General

Agile Produktentwicklung, agiles Projektmanagement, agile Führung, agile Unternehmen und jetzt auch noch agile Moderation? Agilität und agiles Vorgehen stehen im Augenblick hoch im Kurs. Und natürlich ist es eine Frage der Zeit gewesen, bis Kundinnen und Kunden nach agiler Moderation oder Supervision von Teams oder Gruppen fragten. Aber was ist agile Moderation? Genau dieser Frage stellt sich der vorliegende Reader. Grundlage dafür ist die agile Software- und Produktentwicklung. Daher ist der erste Teil des Buchs eine sehr knappe Einführung in die agile Produktentwicklung. Nachdem Unterschiede zwischen agilem Vorgehen und klassischer Moderation, und deren Gemeinsamkeiten, beleuchtet werden, zeigt das Buch verschiedene Wege auf, sich dem Begriff der agilen Moderation anzunähern. Der Autor stellt beispielhaft eine agile Moderationsmethode mit den entsprechenden Techniken vor, die sich in der Praxis bewährt hat. Thomas Tiller hat ein Studium der Informatik absolviert, lange in der Software-Entwicklung gearbeitet und moderiert seit über 15 Jahren Gruppen unter anderem in komplexen und schwierigen Situationen. Aus diesem Erfahrungshintergrund nähert er sich in diesem Reader für Moderatorinnen und Moderatoren der Frage nach agiler Moderation an. Der Reader richtet sich an alle, die professionell mit Gruppen arbeiten, und sich ein Bild davon machen möchten, was der Begriff "agile Moderation" bedeuten und wie agile Moderation aussehen könnte.

Teil 1: Eine sehr kurze Einführung in agile Produktentwicklung

Ziel dieser kurzen Einführung ist es, dass Sie als Moderatorin oder Moderator eine Vorstellung davon bekommen, wie die Idee des agilen Vorgehens entstanden ist. Dazu stelle ich agile Software- bzw. Produktentwicklung in ihren einzelnen Komponenten vor.[1] Um später in diesem Reader agile Moderation betrachten zu können, ist es vor allem wichtig, die Grundprinzipien des agilen Vorgehens verstanden zu haben und den Prozess mit seinen einzelnen Schritten zu kennen. Ich gehe davon aus, dass Sie als Leserin oder Leser genügend Prozess- und Methodenkompetenz im Umgang mit Gruppen und Teams mitbringen, dass ich bei den einzelnen Methodenschritten und Techniken nicht zu sehr ins Detail gehen muss. Nachdem Sie diesen Abschnitt gelesen haben, sind Sie vielleicht (noch) nicht in der Lage, in einem agilen Projekt zu arbeiten. Aber Sie haben auf jeden Fall verstanden, wie agile Produktentwicklung entstanden ist, wie sie in groben Zügen funktioniert und was ihre Vorteile und ihre Fallen sind.

Ganz grob sind bei den meisten agilen Vorgehensweisen vier Ebenen von Bedeutung:

Ebene	Beschreibung
Agile Methode	Gesamtstruktur und -prozess für agile Projekte
Agile Techniken	Einzelne Techniken, die in der Methode Anwendung finden
Agile Prinzipien	Handlungsleitende Prinzipien
Agile Werte	Fundament des agilen Ansatzes

Was ist agile Software-Entwicklung und wie ist sie entstanden?

In den 90er Jahren des letzten Jahrhunderts gab es in der noch sehr jungen Disziplin der Software-Entwicklung ein paar klassische Vorgehensweisen, so genannte Software-Entwicklungsmodelle. Das klassische Wasserfallmodell und das V-Modell sind nur zwei davon. Diese Modelle geben ein streng lineares Vorgehen vor und teilen die Entwicklung in vier oder mehr Phasen ein, die nacheinander durchlaufen werden. Kent Beck und viele andere Pioniere dieser Zeit haben mit den klassischen Modellen gearbeitet und immer wieder mit ähnlichen Schwierigkeiten zu kämpfen gehabt, unter anderem mit:

• großen Verzögerungen,
• hohem, erst während der Projektlaufzeit anfallendem Mehraufwand,
• vielen (Zwischen-)Ergebnissen und Leistungen, die im Endprodukt überhaupt keine Rolle mehr spielten,
• dem individuellen Programmierstil der einzelnen Entwickler, wodurch diese oft – trotz entsprechender Software-Engineering-Ansätze und umfassender Code-Dokumentation – nicht ersetzbar waren,
• die Einteilung in Fachteams für die unterschiedlichen Module und die unterschiedlichen Phasen der Software-Entwicklung nach Kompetenz und Funktion, was eine ständige Kommunikation zwischen den Fachteams nötig machte, die aufwendig und fehleranfällig war,
• der zentralen Vergabe der jeweiligen Teilaufgaben durch einen Projektmanager, wodurch die Gefahr bestand, dass Entwickler keine besonders hohe Eigenmotivation und auch keine Gesamtverantwortung für das Endergebnis entwickelten,
• Integration und Test der einzelnen Module einer Software, die erst sehr spät im Projektverlauf stattfanden, und so grundlegende und strukturelle Fehler zu spät erkannt werden konnten,
• Unehrlichkeit den Kunden gegenüber bei Verzögerungen oder ungeplantem Mehraufwand, entweder aus Angst, die Kunden zu verlieren, oder im Glauben, die Verzögerungen noch ‚reinholen‘ zu können,
• Überforderung auf Kundenseite, wenn diese zu Beginn eines Projektes die gesamte Funktionalität eines Produktes in der Theorie spezifizieren sollten, ohne irgendeine praktische Erfahrung zu haben und
• der Tatsache, dass sich bei länger laufenden Projekten die Kundenanforderungen zwar nach der Spezifikation, jedoch vor Projektende änderten, diese Änderungen aber nicht mehr einbezogen werden konnten, weil sich alles auf die ursprünglichen Anforderungen stützte und eine Änderung nicht vorgesehen war.

Konfrontiert mit diesen und anderen Schwierigkeiten in der so genannten „klassischen“ Software-Entwicklung[2] machten sich verschiedene Software-Entwickler und Software-Projektmanager auf den Weg, neue Vorgehensweisen zu entwickeln. Dabei entstanden parallel unterschiedliche Prozesse (zum Beispiel „Extreme Programming“ oder „Scrum“), die alle ein paar Aspekte gemeinsam hatten.

2001 trafen sich dann einige dieser Software-Entwickler und Projektmanager und erarbeiteten aus den bisher gewonnenen Erfahrungen mit diesen neuen Vorgehensweisen (die damals noch als „light-weight“ bezeichnet wurden) das Agile Manifest[3]. In diesem Manifest schrieben sie vier Werte-Paare und 12 Prinzipien fest, die alle diese light-weight-Methoden gemeinsam hatten.

Die grundlegende Idee dieser so genannten agilen Methoden ist es, den Entwicklern maximale Selbstorganisation bei maximaler Transparenz den Kunden gegenüber zu geben. Außerdem, den Kunden damit einen Teil ihrer Verantwortung ‚zurückzugeben‘ und alle Stakeholder und Kunden regelmäßig in den Prozess mit einzubeziehen. Dies geschieht unter anderem durch kurze, sich wiederholende Zyklen, in denen immer nur ein funktionsfähiger Teil des Endproduktes entwickelt wird. Nach jedem dieser Zyklen (auch Iterationen genannt) kann der Kunde das bis dahin entwickelte Produkt ausprobieren und entsprechendes Feedback geben. Dieses Feedback kann dann in die weitere Entwicklung des Produktes einfließen. So können zum Beispiel auch neue Anforderungen immer wieder in die Entwicklung einfließen.

Agile Werte

Im oben genannten Agilen Manifest sind folgende agile Werte festgehalten, die als Grundlage für alle agilen Projekten gelten:

• Individuen und Interaktionen vor Prozessen und Werkzeugen
• Funktionierende Software vor umfassender Dokumentation
• Zusammenarbeit mit dem Kunden vor Vertragsverhandlung
• Reagieren auf Veränderung vor dem Befolgen eines Plans

Wobei die Verfasser des Agilen Manifests deutlich darauf hinweisen, dass jeweils beide Seiten der genannten Wertepaare wichtig sind, allerdings der Fokus stark auf den jeweils erstgenannten Werten liegt.

Agile Prinzipien

Aus den vier Werten und der schon gesammelten Erfahrung mit agiler Software-Entwicklung hat die Gruppe die folgenden 12 handlungsleitenden Prinzipien abgeleitet:

1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller (im Sinne von Mehrwert für den Kunden – meine Anmerkung) Software zufriedenzustellen.
2. Heiße Anforderungsänderungen, selbst spät in der Entwicklung, willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen.
6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
7. Funktionierende Software ist das wichtigste Fortschrittsmaß.
8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
10. Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.
11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.

Damit haben die Verfasser des Agilen Manifests ein paar, damals in der Software-Entwicklung revolutionäre Dinge festgeschrieben (und in ihren eigenen Projekten gelebt):

• Selbstorganisation des Teams (statt hierarchischer Arbeitsverteilung und Organisation).
• Wandel ist integraler Teil des Projektes (nicht Hindernis).
• Direkte Kommunikation aller Beteiligten auf Augenhöhe (aber in klar verteilten Rollen).
• Funktionierende, einsatzfähige Zwischenergebnisse sind erstrebenswerter (und bringen einen schnelleren Return-on-Investment, ROI) als ein finales Endergebnis.
• Agile Teams erarbeiten nicht nur inhaltliche Ergebnisse, sondern bauen im Laufe ihrer Zusammenarbeit gemeinsam sowohl Prozess- als auch soziale Kompetenzen auf. Ein agiles Team ist ein Team, das permanent auf verschiedenen Ebenen lernt (inhaltlich, Prozess, Umgang miteinander und Kommunikation).
• Nicht die Sicherheit des Managements, sondern Einfachheit und die Bedürfnisse des Kunden sind handlungsleitend.
• Agile Projekte laufen iterativ ab, also in immer wiederkehrenden Zyklen, wobei nach jedem Zyklus ein funktionsfähiges und in jeder Iteration wachsendes Teilergebnis (Inkrement) vorhanden ist.

Agile Techniken

Auf Basis der Werte und Prinzipien und durch deren Umsetzung in entsprechenden Projekten sind über die Jahre Techniken entstanden, die sich über die unterschiedlichen agilen Methoden hinweg ähneln oder gar auf die gleiche Weise eingesetzt werden. Im Folgenden werden die Techniken kurz erklärt, die entweder essenziell für agile Software-Entwicklung sind oder eben in der Moderation ihre Anwendung finden könnten.[4] Die Rollen in der agilen Software- und Produktentwicklung werden weiter unten noch genauer besprochen. Für ein Verständnis der Techniken seien hier nur zwei der Rollen erwähnt: der Product Owner und der Prozess-Master. Der Product Owner ist, grob gesagt, das Bindeglied zum Kunden und kennt das Produkt. Der Prozess-Master unterstützt das Team so gut er kann, den agilen Prozess und die agilen Techniken einzuhalten und anzuwenden und als Team zu wachsen. Die Techniken im Einzelnen:

Product-Backlog

Zu Beginn eines Projektes erarbeiten der so genannte Product Owner und der Kunde gemeinsam die Anforderungen an das zu entwickelnde Produkt. Dies geschieht in Form so genannter Epics, Personas und Use Cases (s. u.). Dann bringen Product Owner und Kunde diese Anforderungen in eine Reihenfolge (Gewichtung). In dieser Reihenfolge werden die Anforderungen vom Team bearbeitet werden. Bei der Gewichtung der Anforderungen können unterschiedliche Kriterien eine Rolle spielen, wie etwa:

• Wertigkeit für den Endkunden,
• Wert für den Kunden,
• Abhängigkeiten der einzelnen Anforderungen,
• Risiko bei der Umsetzung,
• oder andere Kriterien, die für den Kunden oder eine reibungsfreie Entwicklung relevant sind.

In einem nächsten Schritt schätzt das Team den Aufwand der einzelnen Anforderungen in einem so genannten Planning-Poker (s. u.) ab, sodass der Gesamtaufwand für die Entwicklung des Produktes so gut wie möglich feststeht. Die gewichtete Sammlung der Anforderungen an das Produkt mit Aufwandsschätzung nennt man Product-Backlog.

Das Product-Backlog stellt kein fixes oder unveränderbares Dokument dar. Ganz im Gegenteil. Im Laufe des Projekts werden Schritt für Schritt die einzelnen Anforderungen aus dem Product-Backlog genommen und umgesetzt. Außerdem können sich die Kundenanforderungen oder -prioritäten ändern oder Aufwandsschätzungen müssen angepasst werden. In jedem dieser Fälle wird das Produkt-Backlog entsprechend aktualisiert. Hilfreich für die Selbstorganisation des Teams ist es, wenn das Product-Backlog für alle gut sichtbar an einem zentralen Ort aushängt.

Task-Board

Agile Projekte finden in Zyklen – so genannten Iterationen – statt. In jeder Iteration wird ein Teil der Anforderungen aus dem Product-Backlog vom Team umgesetzt. Dabei entscheidet das Team anhand des Product-Backlogs, welche und wie viele Anforderungen es in einer Iteration umsetzen kann. Das Team hält sich bei dieser Entscheidung im Idealfall an die Reihenfolge, die im Product-Backlog festgelegt wurde. Die ausgewählten Anforderungen werden zu Beginn der jeweiligen Iteration aus dem Product-Backlog genommen und in das so genannte Task-Board übertragen. Im Task-Board stehen somit alle Anforderungen, die in der aktuellen Iteration umgesetzt werden sollen. In der Regel ist ein Task-Board in mindestens drei Spalten unterteilt: „zu bearbeiten“, „in Bearbeitung“, „erledigt“. Das Team hält das Task-Board immer auf dem aktuellen Stand. So haben das Team, der Product Owner und der Prozess-Master immer einen Überblick, inwieweit die Aufgaben für eine Iteration schon erledigt sind. Dabei ist besonders darauf zu achten, dass sich ein Task nur dann in der Spalte „erledigt“ befindet, wenn er die so genannten „Definitions of Done“ (s. u.) erfüllt. Im optimalen Fall stehen am Ende einer Iteration alle Anforderungen auf dem Task-Board in der Spalte „erledigt“.

WIP-Limits

Im Zusammenhang mit dem Task-Board gibt es eine Technik mit dem Namen WIP-Limit. Diese Technik soll das Team unterstützen, die Entwicklungsarbeit so effizient wie möglich zu erledigen. WIP steht für „Work In Progress“. Ein WIP-Limit legt fest, wie viele Anforderungen im Task-Board maximal zur selben Zeit in der Spalte „in Bearbeitung“ stehen dürfen. Der Hintergrund dafür ist die Erkenntnis, dass ein Team ab einer bestimmten Zahl von parallel zu erledigenden Aufgaben ineffizient wird. Wie hoch dieses WIP-Limit ist, hängt von Projekt und Team ab. Das WIP-Limit wird zu Beginn eines Projektes vom Team festgelegt. Die Einhaltung wird in der Regel vom Prozess-Master überwacht.

Daily Standups

Im Idealfall sitzen alle Teammitglieder (auch der Product Owner und der Prozess-Master) am gleichen Ort. Um sicherzustellen, dass alle Teammitglieder bezüglich des Entwicklungsfortschrittes immer auf dem aktuellen und gleichen Stand sind, gibt es einmal täglich ein kurzes Meeting (ca. 15 min.). Dieses Meeting hat eine sehr klare Struktur. Es ist praktisch eine Blitzlichtrunde mit zwei oder drei Fragen: Was habe ich seit dem letzten Daily Standup umgesetzt? Auf welche Hindernisse bin ich gestoßen? An was arbeite ich jetzt weiter? Sollten Hindernisse auftreten, ist es in der Regel Aufgabe des Prozess-Masters, diese im Anschluss an das Meeting auszuräumen oder die entsprechende Unterstützung anzubieten. Die Treffen finden – so die Idee – im Stehen statt. Dadurch haben alle ein Interesse daran, dass das Meeting nicht zu lange dauert. Im Daily Standup ist in der Regel auch Zeit, kurz über Änderung von Kundenwünschen zu reden, die nach den strengen Regeln des agilen Projektmanagements aber erst in der nächsten Iteration einfließen dürfen.

Außerdem können an diesen Meetings neben dem Team, dem Prozess-Master und dem Product Owner auch andere Beteiligte teilnehmen, wie zum Beispiel Kunden, Management oder andere Stakeholder. Allerdings ist vorher zu klären, dass diese nur in einer zuhörenden und beobachtenden Rolle dabei sind und entsprechende Änderungswünsche im Anschluss über den Product Owner eingebracht werden müssen. Es ist Aufgabe des Prozess-Masters, dafür zu sorgen, dass alle außer dem Team und dem Product Owner sich aus dem Daily Standup inhaltlich raushalten.

Time-Boxing

Time-Boxing ist eine der wichtigsten Techniken bzw. Prinzipien in praktisch allen agilen Methoden. Time-Bo...

Inhaltsverzeichnis

• Cover
• Inhalt
• Einleitung
• Teil 1: Eine sehr kurze Einführung in agile Produktentwicklung
• Teil 2: Moderation – der Versuch einer Eingrenzung
• Teil 3: Moderation und agiles Vorgehen – Gemeinsamkeiten und Unterschiede
• Teil 4: Wege zur agilen Moderation – drei Beispiele
• Teil 5: Eine agile Moderationsmethode
• Teil 6: Weitere Möglichkeiten, agiles Vorgehen auf Moderation zu übertragen
• Fazit
• Literatur und Quellen
• Danksagung
• Über den Autor
• Impressum