Business Analysten werden agil

Wo und wie kommen Business Analysten in agilen Vorgehensmodellen (z.B. Scrum) zum Einsatz? Welche Aufgaben und Aktivitäten üben sie aus, welche Techniken setzen sie üblicherweise ein, was sind gebräuchliche Begriffe? Diese Fragen beantwortet die vor kurzem veröffentlichte Agile Extension, herausgegeben vom IIBA und Agile Alliance.

Bei agilen Vorgehensmodellen steht die stetige Zusammenarbeit mit den (internen und externen) Kunden im Vordergrund. Business Analysten stellen dabei den Entwicklern die richtigen Anforderungen mit der richtigen Detaillierung zur richtigen Zeit zur Verfügung, damit diese das richtige Produkt entwickeln. Üblicherweise werden in einem iterativen Vorgehen folgende Schritte ausgeführt: Planung, Anforderungen ermitteln, Akzeptanzkriterien definieren, Anforderungen priorisieren, Software entwickeln und die daraus entstandenen Ergebnisse prüfen.
Im Gegensatz zu langen Anforderungsdokumenten bei Wasserfall-Vorgehensmodellen werden eher „schlanke“ Anforderungen z.B. in Form von User Stories geschrieben. Auch stellen Business Analysten die Anforderungen in jeder Iteration zur Verfügung und sammeln nicht zu Beginn des Projekts (möglichst) alle Anforderungen ein. Kommunikation, Verhandlung und Moderation spielen dabei im agilen Umfeld eine große Rolle. Business Analysten sorgen dafür, dass die beteiligten Personen eine Sprache sprechen und möglichst auch mit einer Stimme.

Im Folgenden werden drei agile Ansätze skizziert: Scrum, Extreme Programming (XP) und Kanban.
Anschließend sehen wir uns sieben Prinzipien an, die (nicht nur) „agile“ Business Analysten zum Erfolg führen.

Scrum
Scrum findet eine immer stärkere Verbreitung in der Softwareentwicklung. Die Iterationen werden als Sprints bezeichnet, die zwischen zwei bis vier Wochen dauern. Am Ende eines Sprints steht (mindestens) eine Funktionalität, die Kundenanforderungen umsetzt.
Alle Anforderungen werden im Product Backlog gesammelt, aus dem für jeden Sprint Anforderungen priorisiert und in den Sprint Backlog überführt werden. Während des Sprints diskutiert das Team in einem Daily Scrum Meeting, woran es arbeitet und welche eventuelle Hindernisse zu beseitigen sind.
Am Ende des Sprints wird die erstellte und getestete Software in einem Sprint Review besprochen, möglichst unter Einbeziehung des Kunden. Dabei ergeben sich möglicherweise neue Anforderungen, die ins Product Backlog einfließen.
Aufgaben der Business Analyse sind u.a. das Product Backlog zu pflegen und die Anforderungen darin zu priorisieren (mehr unter Mapping the BABOK to Scrum).

Extreme Programming (XP)
Extreme Programming (XP) nutzt User Stories; Anforderungen, die in kurzen Sätzen beschreiben: „Als Akteur/Rolle/Kunde will ich Beschreibung der Funktionalität/Eigenschaften, um Nutzen/Ziel zu erreichen.“
Im Release Planning werden die Funktionalitäten zusammengestellt, die im Release umgesetzt werden sollen (ähnlich zum Sprint Backlog bei Srum). Beim Iteration Planning werden die User Stories nach der Wichtigkeit für den Kunden sortiert.
Bei einer großen Anzahl von Nutzern oder unerfahrenen Nutzern ist es sinnvoll Business Analysten einzusetzen. Sie stellen ein gemeinsames Verständnis der zu erstellenden Funktionalitäten sicher, verhandeln bei unterschiedlichen Meinungen, moderieren, entwickeln Akzeptanzkriterien für die User Stories und sorgen so dafür, dass die Anforderungen richtig umgesetzt werden.

Kanban
Kanban ist ein Ansatz, um den Arbeitsfluss zu managen. Vier Prinzipien kommen zum Einsatz: Arbeit visualisieren, Arbeit limitieren, auf den Arbeitsfluss fokussieren, ständige Verbesserung. Dabei werden nicht unbedingt feste Iterationen durchlaufen.
Kanban setzt auf Queues (Arbeitsstapel). Ähnlich wie Backlogs bei Scrum wird in der Queue die Arbeit zusammengefasst, die notwendig ist, um ein Produkt bzw. eine Funktionalität zu liefern. Wenn neue Anforderungen eintreffen, werden sie nach Priorität und Dringlichkeit in der Queue einsortiert. Mit Grooming the Queue werden zu große Funktionalitäten für ein Release verkleinert bzw. Anforderungen außerhalb des Lösungsumfangs herausgenommen.
Kanban kennt im Gegensatz zu Scrum und Extreme Programming keine festgelegten Rollen. Business Analyse wird durchgeführt, um erste Anforderungen für die Queue zu dokumentieren. Wenn die Entwickler diese bearbeiten, ermittelt der Business Analyst weitere Anforderungen für die nächste Funktionalität.

7 Prinzipien für erfolgreiche „agile“ Business Analysten
Die sieben Prinzipien sind dem Agilen Manifest und Lean Management entlehnt. Sie führen „agile“ Business Analysten zum Erfolg.

Auch für nicht-agile Vorgehensmodelle oder für das Tagesgeschäft lassen sich diese Prinzipien sinnvoll anwenden. Das habe ich mir selbst vorgenommen 😉