Die Business Analyse gehört NICHT in den Sprint

Person arbeitet mit Analyse Dokumenten und Tablet auf Tisch
Lesedauer 7 Minuten

Du arbeitest mit Scrum und hast die Rolle Business Analyst:in, Requirements Engineer oder Consultant im Team? Vielleicht bist Du auch schon auf Herausforderungen bei der Organisation Eurer Sprints gestoßen. Denn Scrum sieht diese Rolle nicht vor und auch nicht deren Einbindung. Unsere Pionierin Jenni erklärt Dir, wofür diese Rollen nötigt zu sein scheinen und wie man sie sinnvoll einsetzen kann. (Bildquelle: Firmbee.com/unsplash.com)

1. Expert:innen werden in Domänenteams zusammengezogen

Wenn ich neu zu Kund:innen komme, hat manchmal vorab schon die „agile“ Umstrukturierung eines Bereichs stattgefunden. Die Idee war in der Regel, den agilen Prinzipien „Kund:innenzentrierung“, „Teamwork“ und „Crossfunktionalität“ gerecht zu werden. Liegt der Fokus bei der Umstrukturierung nur auf einem einzelnen internen Unternehmensbereich, sind mit Kund:innenzentrierung die internen Kund:innen dieses Bereichs gemeint. Stell Dir eine IT-Abteilung vor: Die meisten unterscheiden einerseits nach Entwicklung und Betrieb und dann noch mal nach Technologien oder Programmiersprachen. Nun wollen sie sich in Richtung ihrer internen Kund:innen, sprich der Fachbereiche, aufstellen. Die Folge: Die IT-Expertinnen aus den bisherigen Teams, die für ein und denselben Fachbereich Leistungen erbringen, werden jeweils zu einem crossfunktionalen Team neu zusammengeführt. Man nennt dies auch häufig Domänenschnitt.

2. Domänenteams haben Vorteile, sind aber nicht pauschal anwendbar

Auf diese Weise brauchen die Fachbereiche nur noch mit einem klar benannten Team zu interagieren. Das Durchfragen bis zur:m richtigen Expert:in hat ein Ende. Und auf der anderen Seite sind in den Teams endlich alle zusammen, die für ein selbstorganisiertes Ende-zu-Ende-Arbeiten nötig sind.

In vielen Fällen funktioniert das angewandte Prinzip aber nicht, z. B.:

  • wenn die Expert:innen für einen Fachbereich mit sehr großer fachlicher Breite und gegebenenfalls technologischer Vielfalt zusammengezogen werden.
  • wenn die IT hauptsächlich mit externen Anbietern arbeitet und nur zwischen den Anforderungen des Fachbereichs und dem Anbieter vermittelt.
  • wenn die Leistungen für einen Fachbereich zu gering sind, um ein ganzes Team zu beschäftigen. Hier betreut ein Team manchmal mehrere „kleine“ Fachbereiche zusammen. Gerne kombiniert: die HR-, die Finance- und die Real Estate-Systeme.

Das Ergebnis: Wir erhalten eine große technologische und/oder fachliche Vielfalt in einem Team. Und gegebenenfalls umfasst das Team auch weit mehr als die gerade eben noch handhabbaren neun Mitglieder. Die kognitive Last und die Anzahl der Kommunikationskanäle werden für alle zu groß. Dass das Team unter solchen Bedingungen in seine Bestandteile zerfällt, habe ich Dir in einem weiteren Blogartikel erklärt.

Domänenteams haben Vorteile, hier dargestellt durch Team, dass gemeinsam mit Laptops an einem Tisch arbeitet

Domänenteams haben Vorteile, sind aber nicht pauschal anwendbar (Bildquelle: marvin-meyer/unsplash.com)

3. Product Owner:innen werden eingesetzt, aber…

Die genannten Beispiele haben auch Auswirkungen auf die Idee, den Teams im Sinne des Scrum-Konzepts eine:n Product Owner:in „vor die Nase“ zu setzen.

  • Menschen, die vorher die Anforderungen mit dem Fachbereich direkt selbst geklärt und umgesetzt haben, wird der vordere Teil ihrer Arbeit weggeschnitten. Zukünftig übernimmt der:die Product Owner:in die Aufgabe der Klärung mit dem Fachbereich sowie die Priorisierung. Damit verlängert sich die Kommunikationskette. Die Effekte des Stille-Post-Prinzips nehmen zu. Ganz zu schweigen von dem Motivationsverlust, wenn Teammitgliedern sinnvolle Aufgaben und Autonomie weggenommen werden.
  • Der:die Product Owner:in alleine kann nicht alles fachlich lernen und mengenmäßig schaffen, was vorher auf die Expert:innen verteilt war.

Daher führen viele Unternehmen eine weitere Rolle ein, die es normalerweise bei Scrum nicht gibt. Man kennt sie aber von früher aus dem Projektmanagement und „exportiert“ sie in das neue Zusammenarbeitsmodell: Die Rolle des:der Business Analyst:in oder des Requirements Engineers. In manchen Unternehmen heißt diese Rolle auch Consultant.

4. Business Analyst:innen sollen als Teil des Teams unterstützen

Sie:er soll die konkrete fachliche Klärung der Anforderungen für die:den Product Owner:in übernehmen. Und bestimmt gibt es auch andere Kontexte als die oben genannten, in die diese Rolle gut hineinpasst. Nun beobachte ich in der Folge, dass die Business Analyst:innen als Teil des Umsetzungsteams gesehen werden. Ihre Arbeit ist dementsprechend in den Sprint eingeplant. Das ist jedoch recht unpraktikabel, denn: Mach Dir noch mal bewusst, was ein Sprint, Sprint Ziel und ein Sprint Forecast (ehemals Sprint Commitment) ist:

  • Product Owner:in und Umsetzungsteam besprechen im Planning I das kommende Sprint Ziel.
  • Das Team zieht sich aus dem Product Backlog nach Priorität die User Stories, die es glaubt, im kommenden Sprint zu dem vereinbarten Sprint Ziel umsetzen zu können und gibt damit seinen Sprint Forecast ab.
  • Dafür hat entweder im Planning I oder in einem vorgelagerten Refinement eine Klärung der User Stories stattgefunden. Dabei werden die User Stories so lange diskutiert, bis das Umsetzungsteam ein gemeinschaftliches Verständnis entwickelt und die anstehenden User Stories geschätzt hat.

Voraussetzungen dafür, dass dieses Vorgehen funktioniert:

  • Nur wenn klar ist, was zu tun ist, kann das Team schätzen.
  • Und erst, wenn die User Stories geschätzt sind, kann das Team auch einen Forecast abgeben.
  • Und nur, wenn das „Was“ klar ist, kann das Team im Planning II die einzelnen für die Umsetzung notwendigen Aufgaben besprechen.
  • Und das wiederum ist die Voraussetzung dafür, dass die Aufgaben gemeinsam verantwortet und im Sprint abgearbeitet werden können.

5. Business Analyse passt nicht in die Idee von „Sprint“

Wird die Business Analyse im Sprint eingeplant, planen wir damit Aufgaben ein, deren Ziel noch gar nicht klar ist. Ein Team soll also User Stories forecasten und die Umsetzungsschritte planen, ohne zu wissen, worum es genau geht oder wie groß die Anforderung ist. Das wird es nicht können. Die Aufgabe wird also blind in den Sprint aufgenommen, in der Hoffnung, dass sich das dann im Laufe des Sprints klärt und dass die Aufgabe von der Größe her in den Sprint passt. Damit wird das Arbeiten in Sprints ad absurdum geführt.

Selbst wenn nur die Erwartung besteht, dass die Business Analyse, also die Klärung des „Was“, bis zum Ende des Sprints fertig werden soll, schaffen wir uns ein Problem: Im Zweifel dauert es eineinhalb Sprints von der Kenntnisnahme einer Aufgabe, bis sie zur Umsetzung eingeplant werden kann. Etwas, was sonst vielleicht nur einen halben Sprint benötigt hätte. Denn der Sprint ist ja geschlossen. Alles, was an Aufgaben hereinkommt, muss bis zum nächsten Sprint warten. Konsequenterweise bei dieser Herangehensweise auch die Klärung von Aufgaben. Weil dies nicht zielführend ist, nehmen Business Analyst:innen in der Praxis häufig nachträglich noch dringende Klärungen in den Sprint auf. Hier stellt sich aber die Frage, welchen Sinn der Sprint dann noch hat.

6. Die Business Analyse ist eine Dienstleistung für das Team

Und zuletzt ist die Idee bei Scrum, dass das Team gemeinschaftlich an der Umsetzung der User Stories arbeitet. Die Business Analyse ist aber eine Dienstleistung für das Team, um überhaupt zu umsetzbaren User Stories zu gelangen. Wenn das Team schließlich doch wieder seine User Stories selbst klärt, dann sind wir eigentlich wieder in dem Status von vor der Umstrukturierung – was ja nicht schlecht gewesen sein muss. Oder wir sondern die Business Analyst:innen als Unterteam ab. Aber was ist dann mit der Idee von gemeinsamer Verantwortung und Teamwork?

7. Business Analyse ist strukturgleich mit den Aufgaben einer:s Product Owner:in

Wenn wir uns die Business Analyse genauer anschauen, stellen wir fest, dass diese strukturgleich mit der Arbeit eines:einer Product Owner:in ist. Ein:e Business Analyst:in ist also NICHT Teil des Umsetzungsteams – wie häufig angenommen, sondern Partner:in des:der Product Onwer:in. Dazu kommt, dass die Arbeit von Product Owner:in und Business Analyst:in anderen Gesetzmäßigkeiten folgt als die Umsetzung. Sie ist gekennzeichnet von Abhängigkeiten und Wartezeiten. Daher ist diese Art der Arbeit auch nur schwerlich sinnvoll in Sprints zu organisieren.

Business Analyse ist strukturgleich mit den Aufgaben einer:s Product Owner:in, hier dargestellt durch zwei Personen, die gemeinsam an einem Tisch arbeiten.

Die Business Analyse ist strukturgleich mit den Aufgaben einer:s Product Owner:in (Bildquelle: scott-graham/unsplash.com)

8. Die Product Owner:innen-Rolle scheint den größten Status zu haben

Die automatische Einstufung von Business Analyst:innen als Teil des Teams und damit als Teil der Sprint-Aufgabe könnte vor allem mit einer falschen Vorstellung vom Wert der einzelnen Rollen zu tun haben. So beobachte ich häufig, dass viele vor allem die Product Owner:innen-Rolle als eine herausgehobene Führungsrolle wahrnehmen. Die „niederen Ränge“ werden zum gefühlten „Resterampe-Team“ zusammengefasst. Auf wenig Verständnis trifft zu Beginn häufig auch die Scrum Master:innen-Rolle. Sie „läuft so mit“, wenn sie überhaupt besetzt wird. Verschärft wird diese Haltung dadurch, dass häufig ehemalige Führungskräfte in die Product Owner:innen-Rolle wechseln. Diese hadern vielleicht mit ihrem gefühlten Wert in der Organisation. Somit möchten sie sich nicht mit einem:r Business Analyst:in gemein machen. Vielleicht kommen sie aber auch einfach aus der gelernten Haltung „es kann nur eine:n geben“. Folglich sehen sie ein:e Business Analyst:in nur IM Team.

9. Im Scrum Team gibt es keine Hierarchien

Hier liegen neben den oben genannten Missverständnissen also noch weitere vor, denn:

  1. Jede:r hat in einem Scrum-Team eine Führungsrolle. Und alle sind auf Augenhöhe miteinander. Keine:r hat Macht gegenüber einer:m anderen. Alle haben den gleichen hohen Wert.
  2. Die Rolle „Team“ ist genauer gesagt die Rolle „Umsetzungsteam“. Damit wird vielleicht noch klarer, dass die Business Analyse nicht ins Team gehört.
  3. Wenn Du Scrum zweckentfremdest, musst Du das Konzept gegebenenfalls auch abwandeln, damit es weiterhin funktioniert – so auch das einfache Rollenmodell Product Owner:in, Umsetzungsteam, Scrum Master:in.

10. Mach Business Analyst:innen zu Partner:innen der Product Owner:innen

Wenn Du also mit Business Analyst:innen arbeitest, benötigst Du vielleicht ein ganz anderes Vorgehensmodell als Scrum oder eine andere Teamstruktur. Die Rolle kann aber auch Sinn machen, etwa in einem sehr stark regulierten Markt. Dieser führt häufig dazu, dass der:die Product Owner:in der ganzen Test- und Dokumentationspflichten nicht alleine Herr oder Frau wird. In so einem Fall betrachte die Rolle als außerhalb des Umsetzungsteams stehend. Tipp: Bilde mit Product Owner:in und Business Analyst:innen eine Art Unterteam. Setze zum Beispiel ein Kanban-Board mit ihnen auf, mit dessen Hilfe sie sich selbstorganisieren können. Erst wenn die User Storys fertig sind, verschiebt Ihr sie in das Backlog des Umsetzungsteams. So kannst Du auch mit Business Analyst:innen sinnvoll in einem Scrum-Prozess arbeiten.

Du möchtest mehr über Teamstrukturen und passende Führungs- und Vorgehensmodelle wissen?

Du brauchst einen strukturellen Schnitt, eine neue prozessuale Lösung oder eine neue Führungsorganisation? Wir führen gerne einen Pioneers Organisational Design Sprint mit Dir durch.

Informiere Dich jetzt über unseren Organisational Design Sprint
AutorInnen dieses Beitrags

Jennifer Rolle
Management Consultant

Nach ihrem erfolgreich abgeschlossenen Psychologiestudium mit Schwerpunkt Arbeit- und Organisationspsychologie war eine ihrer wichtigsten Stationen die Arbeit in der Personalentwicklung…


Schreibe einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit * markiert.

Formular zurücksetzenBeitragskommentare