„Business Analyse und Agilität – das passt nicht gut zusammen!“ Diese These ist weit verbreitet. Zu unterschiedlich die Herangehensweisen, unvereinbar die Vorgehensweisen und außerdem – im Scrum Guide steht nichts von der Rolle des Business Analysten. Wir prüfen die These auf ihren Wahrheitsgehalt und zeigen auf, wie das Zusammenspiel im Arbeitsalltag klappen kann.
Business Analysten: Schnittstelle zwischen fachlichen Anforderungen und technischer Umsetzbarkeit
Business Analyse ist aus vielen IT-Projekten nicht mehr wegzudenken. Business Analysten kümmern sich etwa um die Exploration von Projekten, die Analyse und Modellierung von Geschäftsprozessen, die Identifikation von funktionalen und nichtfunktionalen Anforderungen, sowie die fachliche und technische Konzeption.
Business Analysten sind die Schnittstelle zwischen fachlichen Anforderungen und technischer Umsetzbarkeit. Sie beraten nicht zuletzt bei der Erarbeitung einer Produktvision. Auch in zahlreichen agilen Projekten, welche häufig nach Scrum organisiert sind, wird auf ihre Unterstützung zurückgegriffen.
Allerdings fällt eines schnell auf: Die Rolle des Business Analysten kommt im Scrum Guide nicht vor. Auch andere agile Frameworks weisen die Rolle nicht explizit aus. Statt eines linearen Projektablaufs von Phase zu Phase sieht agiles Projektmanagement außerdem einen iterativen Prozess vor.
Eine dedizierte Explorationsphase, in der ein Fachkonzept ausgearbeitet wird, ist somit auch nicht mehr vorgesehen. Die Anforderungen werden kontinuierlich erfasst. Im Projektalltag erleben wir zudem häufig, dass die Tätigkeitsfelder und Beauftragungsmodelle für Business Analysten sehr stark variieren, da das Framework keine übergreifende Rollen- und Aufgabenbeschreibung für sie bereithält.
Passen Business Analyse und Agilität überhaupt zusammen? Und wenn ja – wie funktioniert es am besten?
Eine eindeutige Antwort gibt es hier nicht. Auch unsere Empfehlungen, weichen teilweise stark voneinander ab. Wir zeigen auf, welche verschiedenen Ansätze es für die Zusammenarbeit gibt und welche Vorgehensweisen wir als besonders geeignet betrachten.
Unsere Erkenntnisse – auf einen Blick
Detailbetrachtung
Product Owner stehen oft vor der Herausforderung, sowohl Themen wie Geschäftsstrategie, Marktanalyse und Finanzierung als auch das Anforderungsmanagement, die Erstellung und Refinement von User Storys sowie die Zusammenarbeit mit dem Entwicklungsteam und Stakeholdern zu managen.
Dabei fehlt ihnen aufgrund der kurzen Entwicklungszyklen oftmals die Zeit, sich intensiv mit den fachlichen Themen auseinanderzusetzen. Eine Entlastung durch Business Analysten, als eine von vielen ihrer Aufgaben, ist hier oftmals sinnvoll und notwendig.
Darüber hinaus kann ihre Unterstützung bei der Exploration, Erstellung von Machbarkeitsanalysen, dem Design von Mockups und der Durchführung von (Design-)Workshops maßgeblich zum Erfolg eines Projektes beitragen.
Doch wie passen diese Tätigkeiten in ein Zusammenarbeits-Modell nach Scrum?
Wir haben im Wesentlichen zwei konträre Sichtweisen identifiziert:
Der integrative Ansatz sieht vor, dass Fähigkeiten eines Business Analysten in einem multidisziplinären Team vorhanden sind, auch wenn es dafür keine separate Rolle eines Business Analysten benötigt. Die Aufgaben der Business Analysten werden demnach durch das DEV-Team abgedeckt und somit im Rahmen der ein- bis vierwöchigen Sprints mit erledigt.
Nähere Informationen hierzu finden sich im Scrum Guide
Der explizite Ansatz weist die Rolle der Business Analysten dagegen gesondert als Unterstützung des Product Owners bei der Anforderungserstellung und Bereitstellung detaillierter Artefakte aus. Der Business Analyst läuft also außerhalb des Sprint Zyklus und fungiert als Bindeglied zwischen Kunde/Geschäftsanforderung und dem Produktentwicklungsteam.
Aus dem Vergleich der beiden Ansätze in unserem Umfeld und der Analyse der Spannungsfelder und Potentiale in der Zusammenarbeit lassen sich folgende Erkenntnisse zusammenfassen:
Rolle des BA im Projekt klären
Ob integrativer oder expliziter Ansatz, ein wesentlicher Faktor, damit Agilität und Business Analyse reibungslos und effizient miteinander funktionieren, ist eine klare Definition der Rollen und Aufgaben. Auch eine eindeutige Abgrenzung der Tätigkeiten ist essenziell. Diese sollten zu Beginn des Projektes mit allen am Prozess beteiligten Parteien, mindestens also dem Product Owner, seinem Fachbereich und gegebenenfalls Stakeholdern sowie dem Entwicklungsteam, geklärt werden. Insbesondere, da die Tätigkeiten im Framework nicht ausgewiesen sind und die Vorstellungen und Erwartungshaltungen hier oft unterschiedlich sind, empfiehlt sich zu Projektstart eine kurze Vorstellung der Kompetenzen und des generierten Mehrwertes, sowie eine klare Beschreibung des Aufgabenspektrums der Business Analysten.
Dazu haben wir ein Rollenbild erarbeitet, welches mögliche Aufgaben der Business Analyse im agilen (Scrum) Vorgehensmodell vorschlägt:
- Unterstützung bei Problemidentifikation
- Anforderungsaufnahme und Lösungsgenerierung
- Beratung bei der Priorisierung des Backlogs
- Schreiben und Übergabe von User Storys an DEV-Team
- Leistung von fachlicher Unterstützung während des Entwicklungsprozesses
- Fachliche Unterstützung bei Scrum Meetings nur bei Bedarf (i.d.R. nicht bei Dailys)
Trennung von Business Analyse und Sprint
Es gibt bereits Projekte, in denen das Produktentwicklungsteam sowohl aus Softwareentwicklern als auch Business Analysten besteht. In diesem Fall empfiehlt sich besonders, die User Stories möglichst klein zu schneiden, damit die Analyse in einem Sprint erfolgen kann. Es ist zielführender das Anforderungsmanagement unabhängig von Sprints bzw. über mehrere Sprints hinweg zu organisieren.
Da viele Tätigkeiten der Business Analysten meist näher an denen der Product Owner liegen und darüber hinaus nicht analog der User Stories schätz- und planbar sind, bietet es sich an, sich zwar an den Refinements und Estimations zu orientieren, die Tätigkeiten jedoch nicht in die Sprint-Fenster zu integrieren.
Das heißt: Business Analysten erstellen Arbeitsergebnisse (sprintunabhängig) als Input für Folgeprozesse (sprintabhängig).
Separate Business Analyse Beauftragung
Nicht zu unterschätzen sind außerdem die Details der Beauftragung. Oftmals liegt die Problematik der Zusammenarbeit nicht bei der Verbindung von Business Analyse und Agilität sondern im Abrechnungsmodell. Wir empfehlen die BA Leistungen direkt in der Vertragsphase zu berücksichtigen, auszuweisen und ein entsprechendes Modell zu definieren.
Eine mögliche Methode, die für alle Beteiligten zufriedenstellend sein kann, ist Business Analyse Aufwände mittels Kontingentmodell oder mittels extra Business Analyse Tickets zu beauftragen. Die Leistungsbestandteile bleiben so transparent und sind einfach abzurechnen.
Wie ein Kontingentmodell beispielhaft aussehen kann:
- Es wird ein konkreter Anteil an BA-Tätigkeit festgelegt.
- Dieser konkrete Anteil wird nach und nach aufgebraucht.
- Nachdem das BA-Kontingent aufgebraucht ist, kann der Kunde entscheiden, ob weitere Stunden beauftragt werden sollen, oder von der Entwicklungsleistung umgewidmet werden können.
- Entwicklungsleistung in Stunden wird festgesetzt – ca. 30 % dieser Stunden wird dem Kunden für BA Tätigkeit verkauft
Vorteile:
- Schätzung der explorativen Anteile entfällt
- Vereinfachte Abrechnung der Beratungs- und Unterstützungsleistungen
- Geringerer Verwaltungsaufwand für zusätzliche BA-Storys
Unser Fazit
Agilität und Business Analyse – das geht zusammen und ist aufgrund der komplexen, oft kurzfristigen und vielschichten Anforderungen an den Product Owner als Unterstützung nicht selten unentbehrlich. Damit die beiden Disziplinen voneinander profitieren können, sollten die Tätigkeiten und Erwartungshaltungen sowie die Beauftragung vorab gemeinsam definiert werden.
Erfahren Sie mehr über das Zusammenspiel von Agile und Business Analysis.
Wir informieren Sie gerne.
