Wie arbeitet man agil?
Hört man die Formulierung „agile Arbeitsweise“, so verbindet man damit vermutlich eine bestimmte Methode, die streng zu befolgen ist. Fakt ist jedoch: Es gibt eine Vielzahl von agilen Ansätzen, die zu den unterschiedlichen Produkten und Bedürfnissen von Teams passen. Einige von ihnen sind bekannter, da sie besonders oft in agilen Kontexten erwähnt und eingesetzt werden. Doch im Grunde genommen gibt es keine starren Regeln, wenn es um agiles Arbeiten geht.
Ebenfalls denkbar ist es, einzelne Elemente – Tools, Formate oder Strategien – aus verschiedenen Methoden zu wählen und diese mit anderen Elementen zu kombinieren. Für Agilität ist in erster Linie entscheidend, ein Produkt möglichst schnell und bedarfsgerecht zu entwickeln und es dann kontinuierlich zu verbessern – es gibt für ein Team viele Möglichkeiten, dieses Ziel zu erreichen.
Im Folgenden finden Sie eine Auswahl agiler Methoden und Elemente, die ohne Anspruch auf Vollständigkeit näher vorgestellt und erläutert werden sollen. Zu beachten ist: je nach Methode werden bestimmte Begriffe eventuell unterschiedlich verstanden oder definiert. Die Erklärungen hier sind daher bewusst allgemein gefasst. Sollten Sie bei dem einen oder anderen Begriff tiefer eintauchen wollen (wozu wir Sie gerne ermutigen möchten), werden Sie womöglich auch andere Auslegungen oder strengere Definitionen vorfinden.
1. Nutzer:innenbedarfe erfassen und verstehen
User Personas & User Stories
Nutzer:innen und ihre Bedarfe sind zentral für agile Entwicklungsstrategien. Ein Weg, wie agile Teams diese Bedarfe in ihrer Entwicklungsarbeit verankern, ist die Erfassung von Nutzer:innenprofilen (sogenannten „User Personas“). Hierbei handelt es sich um Kurzprofile von potenziellen (aber fiktiven) Produktnutzer:innen, die Details wie Alter, Geschlecht und Beruf umfassen können.
Das Produktteam nutzt diese Profile, um sogenannte „User Stories“ (Nutzer:innengeschichten) zu schreiben. Diese enthalten kurze Beschreibungen (wirklich nur 1-2 Sätze) über die Interessen und Ziele eines/einer Nutzer:in im Bezug auf das zu entwickelnde Produkt.
Als ein/e [User Persona] will ich [irgendein Ziel erreichen] damit ich [irgendeinen Mehrwert aus dem Ziel realisieren kann].
User Personas und User Stories helfen dem Produktteam ihre Arbeit rund um die tatsächlichen Nutzer:innenbedarfe zu fokussieren: so behält das Team im Blick, für wen sie das Produkt letztlich entwickeln und was diese Personen von dem Produkt erwarten.
Wichtig: Personas und Stories sollten nicht auf den eigenen (unterstellten) Annahmen beruhen. Vielmehr sollte das Team noch vor Beginn der Entwicklung Interviews mit potenziellen Nutzer:innen durchführen, um ihre Bedürfnisse besser zu verstehen. Die Ergebnisse sollten im Anschluss dafür genutzt werden, um die Personas und Stories zu verfassen.
“Die Nutzer:innenperspektive” (Service Agent:innen Schulung vom CityLAB Berlin)
“Persona-Profil” aus dem kostenlosen Handbuch Öffentliches Gestalten
Nutzer:innentests
Die agile Entwicklung sieht vor, dass ein Produkt über mehrere Iterationszyklen hinweg prototypisch verbessert wird. Der Schlüssel hin zur kontinuierlichen Verbesserung eines Produkts liegt bei Nutzer:innentests. Regelmäßige Tests mit Nutzer:innen erlauben es nämlich, Feedback zur Funktion und Nutzbarkeit eines Prototypen zu sammeln, das anschließend direkt in die Verbesserung des Produkts fließt.
Wie genau ein User Test durchgeführt wird, ist abhängig vom Produkt. Wie zuvor gilt auch hier wieder, den Fokus auf echte Nutzer:innen (und nicht jemand aus dem Produktteam oder Kolleg:innen aus einer anderen Abteilung) zu richten und zu verstehen, wie sie das Produkt bedienen. In der Regel gibt das Entwicklungsteam den Nutzer:innen eine Aufgabe, die mit dem Produkt erledigt werden soll (z. B. einen Antrag mithilfe des Produkts einzureichen oder ein passendes Angebot durch die Suchfunktion zu identifizieren). Anschließend beobachtet jemand aus dem Team die Nutzer:innen und notiert, wo es Schwierigkeiten bei der Bedienung des Produkts gab oder welche Aspekte des Produkts eventuell nicht wie erwartet funktioniert haben. Dieses Wissen wird schließlich für die nächste Iteration des Produkts benutzt.
2. Aufteilung von Aufgaben und Rollen
Rollen im Team
Die klassische Rollenverteilung in agilen Teams richtet sich in der Regel nach den spezifischen Verantwortlichkeiten und Aufgaben der jeweiligen Personen im Arbeitsalltag. So gibt es neben den Entwicklern (Developer), die das Produkt technisch umsetzen, auch Personen im Team, die weniger bis gar keine technischen Aufgaben übernehmen. Hierzu zählen etwa das Erfassen von Nutzer:innenbedarfe in Form von User Personas und User Stories, das Durchführen von Nutzer:innentests sowie die Organisation von teaminternen Meetings (s. nächster Abschnitt). Hierfür gibt es je nach agiler Methode unterschiedliche Bezeichnungen und Definitionen.
Eine besonders wichtige Rolle in einem agilen Team ist die des Product Owners. Diese Person ist dafür zuständig, dass die Nutzer:innenperspektive nicht nur am Anfang und am Ende, sondern über den gesamten Prozess hinweg einbezogen wird. Product Owner beschreiben funktionale Anforderungen an das Produkt aus Sicht der Nutzenden, evaluieren zusammen mit den Kunden die Zwischenergebnisse und priorisieren die Aufgaben und jeweiligen Zielsetzungen für den nächsten Entwicklungs-Sprint. Nicht zuletzt müssen sie die Befugnis und die Kompetenzen besitzen, Entscheidungen und Priorisierungen im Sinne der Endnutzer:innen zu treffen, weshalb eine klare Definition dieser Rolle unerlässlich ist.
Produkt-Backlog
Als Backlog bezeichnet man eine Liste von einzelnen Aufgaben und Funktionen (geschrieben auf physischen oder digitalen Karten), die für die Erstellung des Endprodukts erforderlich sind. Diese Liste wird abgeleitet aus den bereits erfassten Nutzer:innenbedarfen und User Stories sowie aus den Zielvorgaben, die Teil der Roadmap sind. Die Aufgaben und Funktionen werden vom Team (bzw. vom Product Owner) regelmäßig priorisiert. Anhand dessen wird dann entschieden, welche Funktionen bei der nächsten Iteration angegangen und implementiert werden sollen.
Kanban Board
Ein Kanban Board ist eine Methode zur Visualisierung von bereits erledigten und noch ausstehenden Aufgaben für das Team. Im Kern geht es darum, einzelne Aufgaben (z. B. aus dem Backlog) für die Entwicklung des Produkts aufzuschreiben und diese nach ihrem aktuellen Status in verschiedenen Spalten zu sortieren. Der klassische Ansatz wäre eine Unterteilung in Spalten wie „noch zu bearbeiten“, „in Bearbeitung“, „zu prüfen“ und „erledigt“. Es gibt hier aber keine festen Regeln und das Team selbst kann entscheiden, welche Unterscheidungen am meisten Sinn machen.
Was es allerdings geben sollte ist eine Einigung im Team, wie viele Aufgaben sich maximal in einer Spalte befinden dürfen, um einen Bearbeitungsstau im Team zu vermeiden (wenn etwa zu viele Aufgaben auf eine Überprüfung warten müssen). Ein Kanban Board kann sowohl eine physische Tafel sein (z. B. Wand oder Whiteboard) oder auch digital abgebildet werden (z. B. mit Tools wie Trello oder Jira).
Sprints
Agile Teams arbeiten gewöhnlich in sogenannten Sprints. Ein Sprint bezeichnet eine Zeitperiode von einer vordefinierten Länge (meistens jedoch zwischen einer bis vier Wochen), in der das Team auf ein zuvor festgelegtes Zwischenziel hinarbeitet. Die Länge eines Sprints sollte grundsätzlich eher kurz gehalten werden, damit regelmäßige Fortschritte am Produkt gemacht werden können. Wird der Zeithorizont zu weit gestreckt, ist die Wahrscheinlichkeit höher, dass zu viele Aufgaben auf einmal angenommen werden und mit der steigenden Komplexität auch mehr Probleme auftauchen werden.
Das Team entscheidet zu Beginn eines Sprints, welche Aufgaben aus dem Produkt-Backlog im jeweiligen Sprint bearbeitet werden sollen. Entsprechend sollten nur Aufgaben ausgewählt werden, die auch realistisch innerhalb des Sprint-Zeitraums erledigt werden können, denn: Während eines Sprints kommen keine neuen Anforderungen oder Anpassungen hinzu, um das Team nicht zu stören.
3. Austausch im Team
Daily Standup
Ein agiles Team lebt davon, im ständigen Austausch zueinander zu stehen, um möglichst schnell und effizient arbeiten zu können und potenziellen Problemen frühzeitig zu begegnen. Zu diesem Zweck führen viele agile Teams ein tägliches Check-In durch, das oft auch als „Daily Standup“ genannt wird („Standup“ hier im Sinne vom „Aufstehen“). Hierbei berichten alle Teammitglieder kurz darüber, woran sie gerade arbeiten, vor welchen Herausforderungen sie aktuell stehen und ob sie konkrete Unterstützung von anderen Teammitgliedern brauchen. Daily Standups sollten in der Regel maximal 15 Minuten dauern – also so kurz, dass alle Teammitglieder das ganze Meeting bequem im Stehen durchführen können.
Sprint-Planungstreffen
Agile Teams arbeiten meistens in Sprints (siehe „Aufteilung von Aufgaben und Rollen“ für eine Erklärung von Sprints). Zu Beginn eines Sprints gibt es ein Planungstreffen, in dem das Produktteam festlegt, was die Arbeitsziele und die damit verbundenen Aufgaben für den kommenden Sprint sind und wer an welchen Aufgaben arbeiten wird. Die Arbeitsziele sollten für den Zeitraum des Sprints realistisch geplant sein. Bei dieser Einschätzung spielen z. B. die Komplexität der Aufgaben und die Auslastung im Team eine wichtige Rolle.
Retrospektiven (Retros)
Am Ende eines Sprints kommt das Produktteam nochmal zusammen, um gemeinsam darauf zu schauen, wie der Sprint gelaufen ist: Wurden die definierten Ziele für den Sprint erreicht? Was hat während des Sprints gut funktioniert (z. B. was die Team-Produktivität und Zusammenarbeit angeht) und was hat nicht so gut funktioniert? Diese Treffen sind gleichzeitig eine Chance, andere Teammitglieder für ihre besonders gute Arbeit zu loben sowie Möglichkeiten für Verbesserungen zu identifizieren. Retros sollten idealerweise eine feste Struktur haben und streng getaktet sein, um nicht zu viel Zeit in Anspruch zu nehmen.