Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Books on Demand
- Kategorie: Fachliteratur
- Sprache: Deutsch
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.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 223
Veröffentlichungsjahr: 2018
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Einleitung
Warum dieser Reader?
Seit geraumer Zeit bekomme ich als Gruppen-, Konflikt- und Wirtschaftsmoderator immer wieder Anfragen wie „Können Sie auch agil moderieren?“ oder „Bieten Sie auch agile Moderation an?“. Diese Anfragen haben mich über die Zeit hellhörig werden lassen und meine Neugierde geweckt. Unter anderem, weil ich in den 90er Jahren des letzten Jahrhunderts ein Informatikstudium absolviert habe und dann eine Weile in der Software-Entwicklung gearbeitet habe. Genau in der Zeit also, in der agile Methoden entstanden sind und Beck et. al. das Agile Manifest[1] veröffentlicht haben. Und natürlich haben wir in verschiedenen Projekten entweder agile Techniken eingesetzt oder sogar ganze Projekte agil durchgeführt.
Agiles Projektmanagement und agile Produktentwicklung[2] haben seit damals einen unglaublichen Siegeszug angetreten, und das nicht nur im Bereich der Software-Entwicklung, sondern in fast allen Bereichen, in denen Projekte gemanagt werden müssen. Dabei steckt bei der Wahl, agil vorzugehen, nur allzu oft die Hoffnung dahinter, mit weniger Ressourcen mehr erreichen zu können. Das ist nicht falsch, denn mit diesem Anspruch sind die Entwickler des agilen Vorgehens in der Software-Entwicklung ursprünglich an den Start gegangen. Allerdings übersehen die Verantwortlichen heute dabei sehr häufig, dass nicht jedes Projekt, nicht jedes Team, nicht jedes Management, nicht jede Organisation und nicht jeder Kunde ‚geeignet‘ sind für ein agiles Vorgehen.
Dieser Reader erklärt agile Produktentwicklung in ihren Grundzügen, nähert sich dem Begriff der „agilen Moderation“ an, wirft die Frage nach der Sinnhaftigkeit dieses (Mode-)Begriffs auf und beleuchtet, wie eine Moderationsmethode bzw. Moderationstechniken aussehen könnte(n), die den Namen „Agil“ verdient/verdienen.
Auch wenn ich etwas vorwegnehme, das ich in den folgenden Abschnitten noch genauer beschreiben und erklären werde, sei an dieser Stelle schon einmal eine grundlegende Sache erwähnt, die in den meisten agilen Vorgehensweisen gilt. Obwohl viele Führungskräfte und Teams agiles Vorgehen mit dieser Hoffnung fordern und einführen: Agiles Vorgehen, egal, ob in der Produktentwicklung, im Projektmanagement, in der Führung oder auf Organisationsebene, bedeutet eben nicht die absolute und uneingeschränkte Freiheit.[3] Ganz im Gegenteil: Den meisten agilen Vorgehensweisen liegen sehr klar definierte und stringente Prozesse zugrunde. Und nur durch deren strikte Einhaltung und den disziplinierten Einsatz der entsprechenden agilen Techniken ist ein Höchstmaß an Selbstorganisation und Selbststeuerung auf der inhaltlichen Ebene möglich, ohne das Chaos oder Willkür eine Chance haben.
An wen richtet sich dieser Reader?
In erster Linie an interessierte Moderatorinnen und Moderatoren.[4] Und zwar an die, die verstehen wollen, woher der Begriff kommt, was er in diesem Kontext ursprünglich bedeutet hat und wie er auf Moderation und die entsprechenden Methoden und Techniken angewendet werden könnte.
Dabei habe ich als Autor keinen Anspruch auf Vollständigkeit oder gar Korrektheit. Alles, was ich mit diesem Reader erreichen will, ist, dass Sie als Leser oder Leserin in der Lage sind, zu entscheiden, wie Sie damit umgehen, wenn die Forderung nach agiler Moderation aufkommt. Daher setze ich auch Moderationserfahrung voraus und ein gewisses Grundverständnis für klassisches Projektmanagement. Nur so ist es mir möglich, das Thema in einem relativ kurzen Reader zu behandeln und kein Grundlagenbuch daraus zu machen. Und ich gehe davon aus, dass Sie sich nicht mit schnellen Erklärungen oder Ergebnissen zufriedengeben, sondern den Dingen zumindest ein wenig auf den Grund gehen wollen, um sich ein Bild zu machen.
Außerdem gehe ich davon aus, dass Sie als Moderatorin oder Moderator in der Lage sind, drei Ebenen zu unterscheiden: Inhalt, Arbeitsweise und Prozess. Also stark vereinfacht: was tun wir, wie tun wir es und welchen zugrundeliegenden Weg mit welchen Phasen beschreiten wir dabei.
Wie ist der Reader aufgebaut?
In Teil 1 gebe ich eine sehr kurze Einführung in die Idee der agilen Produktentwicklung bzw. des agilen Projektmanagements, in erster Linie bezogen auf Software-Entwicklung, aber nicht ausschließlich darauf.
Im zweiten Teil versuche ich, Moderation annähernd einzugrenzen. Nur um sicherzustellen, dass wir über das Gleiche sprechen, wenn wir „Moderation“ sagen. Allerdings verlasse ich mich dabei sehr stark auf Ihre Erfahrung als Moderatorin oder Moderator.
Teil 3 widmet sich den Gemeinsamkeiten und Unterschieden von agilen Vorgehensweisen und von Moderation. In erster Linie, um ein besseres Verständnis dafür zu bekommen, was diese beiden Felder eigentlich sind, die da im Ausdruck „agile Moderation“ aufeinandertreffen.
In Teil 4 werfe ich die Frage auf, wie man in der Moderation von Gruppen zu etwas kommen kann, das den Namen „agile Moderation“ verdient. Dabei werde ich mich unter anderem auf einen Kongress zum Thema „agile Moderation“ beziehen, den die Deutsche Gesellschaft für Moderation e.V. im Juli 2018 durchgeführt hat.
Im fünften Teil sind Moderationstechniken und eine Moderationsmethode skizziert, so, wie sie bei einer direkten Übertragung der Techniken und Methoden aus dem agilen Projektmanagement aussehen könnten.
Außerdem gehe ich in Teil 6 kurz auf weitere Möglichkeiten ein, wie agile Moderation auch noch aussehen könnte.
Sollten Ihnen einige der Ausführungen, vor allem zur agilen Produktentwicklung, zu knapp sein, greifen Sie bitte auf eines der im Literaturverzeichnis genannten Bücher zum Thema agiles Projektmanagement, agile Führung oder agile Organisationen zurück. Das sind Einführungen, mit denen Sie sich der agilen Software-Entwicklung, Produktentwicklung, dem agilen Projektmanagement, der agilen Führung und agilen Organisationen auch als ‚Laie‘ gut annähern können. Sollte Ihnen der erste Teil dieses Readers zum Thema agile Produktentwicklung zu ausführlich sein, empfehle ich, direkt bei Teil 2 einzusteigen und nur bei Bedarf die entsprechenden Abschnitte aus Teil 1 zu lesen.
Was ist dieser Reader nicht?
Dieser Reader ist keine Sammlung agiler Moderationsmethoden oder -techniken. Sollten Sie eine solche Sammlung suchen: Patrick Koglin zum Beispiel hat ein sehr hilfreiches Buch mit agilen Moderationstechniken und agilen Moderationsmethoden herausgebracht.[5] Ich werde später in diesem Reader noch einmal kurz darauf zurückkommen.
Dieser Reader ist keine allumfassende Definition von agiler Moderation. Ganz im Gegenteil. Sie werden beim Lesen feststellen, dass es kaum möglich ist, genau zu sagen, was der Begriff „agile Moderation“ eigentlich bedeutet. Und es ist praktisch unmöglich, ihn eindeutig zu definieren. Dieser Reader ist eher als Einladung gedacht, sich mit dem Begriff der agilen Moderation auseinanderzusetzen.
Dieser Reader ist keine umfassende Einführung in agile Vorgehensweisen. Was ich mit der Beschreibung agiler Methoden im ersten Teil allerdings schon erreichen möchte, ist es, Ihnen eine Idee davon zu vermitteln, wer den Begriff unter anderem geprägt hat. Und natürlich, was Agilität in diesem ursprünglichen Kontext tatsächlich bedeutet.
Dieser Reader ist keine weitere Einführung in die Moderation von Teams und Gruppen. Ich gehe davon aus, dass Sie als Leserin oder Leser Erfahrung im Moderieren, Coachen oder Supervidieren von Gruppen haben und nicht auf der Suche sind nach grundlegenden Erklärungen, was Moderation ist, wie Ihre Rolle aussieht oder welche Techniken und Methoden Sie anwenden können.
Dieser Reader ist kein Buch, das Ihnen altbekanntes unter neuem Namen verkauft. Im vorletzten Teil des Buchs skizziere ich zwar eine Methode und nutze mehrere Techniken, die Ihnen aus Ihrer Praxis bekannt vorkommen könnten. Was ich jedoch mache, ist, diese Methoden und Techniken aus einer anderen, nämlich aus der agilen Perspektive zu beleuchten und zu beschreiben. Und auch das wieder nur, um Sie vielleicht zu inspirieren, sich mit dem Modebegriff „Agilität“ im Rahmen von Moderation auseinanderzusetzen. Nicht mehr und nicht weniger.
[1] Kent Beck et. al: Agiles Manifest, 2001, abgerufen am 07.03.2018 unter: http://agilemanifesto.org
[2] Ich werde den Ausdruck „agile Software-Entwicklung“ verwenden, wenn es wirklich nur um spezielle Aspekte der Software-Entwicklung geht, und den Ausdruck „agile Produktentwicklung“, wenn es generell um agiles Vorgehen in der Software- oder Produktentwicklung geht. Den Ausdruck „agiles Projektmanagement“ verwende ich synonym zu „agile Produktentwicklung“ und „agiles Vorgehen“. Genau genommen, wäre eine Unterscheidung zwischen Projekten, in denen Produkte entwickelt werden, und Projekten mit anderem Ergebnis notwendig. Für das Verständnis der agilen Ideen – und nur darum geht es in diesem Abschnitt – tut diese Unterscheidung allerdings nichts zur Sache.
[3] Und es bedeutet auch nicht, dass Chaos oder Willkür regieren. Leider wird der Ausdruck „agil“ inzwischen nicht nur sehr inflationär verwendet, sondern dient oft als Entschuldigung oder als Deckmantel für Chaos und Führungslosigkeit. Das ist aber eben nicht Agilität, sondern nur genau das: Chaos und Führungslosigkeit. Egal, wie es bezeichnet wird.
[4] Ich verzichte ab hier aus Gründen der Lesbarkeit auf die Nennung beider Geschlechter, außer ich spreche Sie als Leserin oder Leser direkt an. Gemeint sind so oder so immer alle Personen des genannten Personenkreises, unabhängig von ihrem biologischen oder sozialen Geschlecht.
[5] Patrick Koglin: „Agil moderieren. Erfolgreiche Veranstaltungen gestalten. Dynamisch, simpel und strukturiert.“, Leanpub, 2015
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:
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.
Heiße Anforderungsänderungen, selbst spät in der Entwicklung, willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
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.
Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
Funktionierende Software ist das wichtigste Fortschrittsmaß.
Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.
Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
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-Boxing steht für das Prinzip, dass Dinge in einer vorgegebenen Zeit erledigt werden. Wenn das nicht der Fall ist, wird nicht die Zeit verlängert, sondern der Anspruch an die Qualität angepasst. Im Dreieck Zeit-Qualität-Kosten wird in klassischen Projekten in der Regel darauf geachtet, dass die geforderte Qualität des zu liefernden Ergebnisses eingehalten wird. Unter anderem, weil der Kunde nicht in den Entwicklungsprozess eingebunden ist und für sein Geld die ursprünglich geforderte Qualität haben will. Sehr oft sind dann Verzögerungen und hohe Kosten die Folgen, von denen in der Regel die beauftragte Firma einen großen Teil selbst tragen muss. Mit dem strikten Einhalten des Time-Boxing-Prinzips verlagert sich dieser Schwerpunkt. Vereinfacht gesagt, heißt Time-Boxing: Die gesetzten Zeiten werden strikt eingehalten. Sollte sich abzeichnen, dass in dieser Zeit ein Produkt nicht – wie geplant – fertig wird, muss darüber verhandelt werden, was tatsächlich umgesetzt wird und was nicht. Das heißt natürlich auch, dass Kunden (und alle anderen Stakeholder, wie etwa das Management!) zum einen das Prinzip Time-Boxing und dessen Konsequenzen verstanden haben müssen und zum anderen permanent im Entwicklungsprozess eingebunden sein müssen. Nur so können Kunden und Stakeholder entscheiden, welche Anforderungen im Falle eines ungeplanten oder unplanbaren Hindernisses nicht oder nicht zu hundert Prozent umgesetzt werden.
Time-Boxing gilt für die Dauer des gesamten Projekts genauso, wie für die einzelnen Iterationen, die in einem Projekt (bis auf wenige, festgelegte Ausnahmen) immer gleich lang sind. Time-Boxing gilt aber auch für alle im Prozess verankerten Meetings, wie Daily Standups, Planning-Meeting, Review und Retrospektive.
Für das Einhalten des jeweils vereinbarten Zeitrahmens tragen zwar in der Regel alle Beteiligten die Verantwortung, jedoch fallen dem Prozess-Master dabei zwei besondere Aufgaben zu: Zum einen muss er Time-Boxing konsequent einfordern und zum anderen ist es sein Job, das Team und alle Beteiligten auf der Prozessebene bei der Einhaltung des jeweiligen Zeitrahmens zu unterstützen.
Definition of Done (Kriterien für „fertig und verwendbar“)
Ein Punkt, weswegen in der klassischen Software-Entwicklung immer wieder Irritationen sowohl in Entwickler-Teams als auch auf Kundenseite auftreten, ist die Tatsache, dass verschiedene Menschen unterschiedliche Vorstellungen davon haben, wann eine Aufgabe tatsächlich erledigt ist. Das klingt im ersten Moment absurd. Wenn Sie sich jedoch vorstellen, dass in einem Team hochspezialisierte Menschen mit sehr unterschiedlichen Aufgaben an einem Produkt arbeiten, dann kann es passieren, dass der eine aus seiner Sicht mit einem Ergebnis vollkommen zufrieden ist, der andere aus seiner Sicht jedoch der Meinung ist, dass noch Arbeit nötig ist. Und der Kunde bzw. das Management wird/werden wieder andere Kriterien haben.
Nun sind in einem agilen Projekt idealerweise alle für alle Ergebnisse verantwortlich. Um zu vermeiden, dass während eines Projekts Unklarheit darüber aufkommt, ob ein Ergebnis tatsächlich fertig und verwendbar ist, werden in agilen Projekten zu Beginn von allen Beteiligten die „Definitions of Done“ gemeinsam festgelegt. Dies sind die Kriterien, die ein Ergebnis oder ein Zwischenergebnis erfüllen muss, um als fertig und verwendbar angesehen zu werden. Spätestens im ersten Review-Meeting, wenn also das Team dem Product Owner und wahrscheinlich auch den Kunden die ersten Zwischenergebnisse vorstellt, sind gemeinsam vereinbarte Kriterien extrem hilfreich. Unter anderem vermeiden diese immer wiederkehrende Diskussionen, ob ein Ergebnis nun abgenommen werden kann oder nicht. Die Kriterien für „fertig und verwendbar“ werden zwar vom Entwickler-Team bestimmt, jedoch mit dem Product Owner und, je nach Produkt, auch mit den Kunden und den anderen Stakeholdern direkt abgestimmt. Denn speziell Kunden und Product Owner sind es, die am Ende jeder Iteration das entsprechende Zwischenergebnis (Inkrement) abnehmen.
Use Cases, Epics und Personas
Während in klassischen Software-Projekten die Anforderungen funktional und technisch spezifiziert werden, liegen einem agilen Projekt Anforderungen in Form von Beschreibungen der Verwendung des Produkts aus Sicht des Kunden und/oder des Endkunden zugrunde.[5] Das bedeutet, dass in der Anforderungsspezifikation nicht steht, was ein Produkt danach können muss, sondern, was ein Kunde oder Nutzer damit tun möchte. Was im ersten Moment sehr ähnlich klingt, macht auf den zweiten Blick einen bedeutenden Unterschied für die Entwicklung aus. Funktionale Spezifikationen sind aus der ‚Sicht‘ des Produktes beschrieben (Wenn das Produkt reden könnte, würde es sagen: „Das und das kann ich, wenn ich fertig bin.“). Anwendungsanforderungen vom Kunden (so genannte „Use Cases“) besagen, was der Kunde mit dem fertigen Produkt machen will. Welche Funktionen das Produkt in welcher Form dazu zur Verfügung stellen muss, ist eine nachrangige Frage, vor allem für den Kunden. Und der soll am Ende ja zufrieden sein mit dem Ergebnis.
Außerdem kann ein Kunde sich viel leichter vorstellen, in welchen Fällen und wozu er ein Produkt braucht, als zu sagen, was es funktional können muss. Durch die Beschreibung der Anforderungen anhand von Use Cases haben also die Kunden den Vorteil, leichter artikulieren zu können, was sie genau wollen. Und das Entwicklerteam ist damit gezwungen, immer wieder in die Perspektive des Kunden zu gehen und so ein Produkt zu entwickeln, mit dem der Kunde etwas anfangen kann.
Epics (Erzählungen) sind – sehr kurz formuliert – mehrere, zusammengehörige Use Cases, die eine ‚Geschichte‘ erzählen, wie der Kunde das Produkt einsetzen wird. In einer E-Mail-Software zum Beispiel könnte ein Epic „Auf E-Mail antworten“ lauten und aus den Use Cases „Antwort-E-Mail öffnen“, „Text verfassen“ und „E-Mail abschicken“ bestehen.
Personas – auch sehr kurz erklärt – sind stereotype Kunden und Anwender. Jeder solche stereotype Kunde bekommt einen Namen (zum Beispiel „Herr Effizient“) und einen Charakter zugeschrieben. Damit können die Entwickler diese Namen verwenden, wenn sie über die unterschiedlichen Arten der Verwendung des entstehenden Produktes reden. Wenn zum Beispiel die Frage aufkommt „Braucht eine Software Tastaturkombinationen, durch die bestimmte Aktionen schneller ausgeführt werden können, als jedes Mal im Menü zu suchen?“ müssen die Entwickler nicht immer wieder neu umschreiben, wer diese Tastaturbelegungen verwenden würde. Stattdessen reicht die verkürzte Formulierung: „Herr Effizient wird die Tastaturkombinationen in diesen oder jenen Fällen (Use Cases) verwenden und hat diesen oder jenen Nutzen davon.“
Planning-Poker
Zu Beginn eines agilen Projekts wird das so genannte Product-Backlog (s. o.) erstellt, dass die Anforderungen an das zu entwickelnde Produkt aus Sicht des Kunden bzw. des Endkunden beschreibt. Teil dieses Prozesses ist es, den Gesamtaufwand des Projekts abzuschätzen. In konventionellen Projekten ist das in der Regel die Aufgabe des Projektmanagers. Den gibt es aber in agilen Projekten in dieser Form nicht. Hier ist das Entwickler-Team für die Abschätzung verantwortlich. Und weil zwei der Forderungen des agilen Vorgehens sind, dass das Team selbstorgansiert arbeitet und dass jeder die volle Verantwortung trägt, ist für die Abschätzung des Aufwands eine eigene Technik entstanden. Diese Technik bezieht alle Entwickler in die Aufwandschätzung mit ein und hat einen Konsens des Teams zum Ziel. Die Technik nennt sich Planning-Poker.
