Der Business Analyst – als Scout im agil skalierten Umfeld

„Was wird aus unseren Business Analysten?“ – Diese Frage ist häufig zu hören – vor allem in größeren Organisationen – wenn die agile Transition beginnt.

Auf diese Frage fallen mir vier Antworten ein:

Rolle auflösen
Die Rolle des Business Analysten wird aufgelöst und die Tätigkeiten werden an den Product Owner  übergeben. Benötigt der PO zusätzliche Unterstützung, weil er die Aufgabe alleine nicht bewältigen kann, könnte das Team mitwirken. So können Teammitglieder beispielsweise an User Stories und deren Konkretisierung durch Akzeptanzkriterien arbeiten. Diese Variante kommt dem reinen Scrum-Lehrbuch am nächsten, da alle Fähigkeiten, die für die Umsetzung eines Ziels benötigt werden, im Team vorhanden sein müssen.

Business Analyst übernimmt die Rolle des PO
Für diese Variante ist in vielen Fällen ein  Umdenken bei Business Analysten nötig. Dem klassischen BA fehlt das agile Mindset. So ist beispielsweise zu akzeptieren, dass nicht alles komplett sein muss, bevor man mit der Umsetzung beginnen kann. Aber wir, die wir im agilen Umfeld bereits arbeiten, sind auch nicht mit agilem Mindset geboren worden. Das erste hilfreiche Prinzip kommt aus dem Lean-Ansatz – Verschwendung vermeiden.

Business-Team bilden
Hierbei bildet der Product Owner mit einem oder mehreren Business Analysten ein Business-Team. Trotzdem  muss einer die Entscheidungen treffen und gegenüber der Organisation verantwortlich sein – dies ist weiterhin der PO.  Bei dieser Variante unterstützen ein oder mehrere  Business Analysten den PO bei seinen Aufgaben und beteiligen sich beim „Backlog Grooming“. Ansprechpartner für das Team sollte weiterhin nur der PO sein, damit es nicht zu mehrdeutigen Antworten kommt. Alternativ delegiert der PO bewusst und mit allen Konsequenzen z.B. vollständige Themengebiete an einen BA.

4. Möglichkeit – BA als Scout
Diese Variante kann in Organisationen sinnvoll sein, in denen der Anteil an (Geschäfts-) prozesslastigen Systemen besonders hoch ist und für viele Kunden entwickelt wird – ein sog. agil skaliertes Umfeld.
Sicherlich ist ein Umfeld wünschenswert, in dem für genau einen Kunden ein Produkt entwickelt wird und dazu ein Kundenvertreter (z.B. als PO) beim Entwicklungsteam tätig ist – soweit die Theorie.
In der Praxis haben wir aber in vielen Fällen die Konstellation, dass ein Produkt für viele Kunden für sehr viele Endanwender entwickelt wird  (z.B. 120 Kunden mit 30.000 Endanwendern) und dieses Produkt wird von zahlreichen Entwicklungsteams (z.B. 16 agilen Teams) umgesetzt. Dieses agil skalierte Umfeld hat zur Folge, dass weder nur ein Kundenvertreter allein zum Review eingeladen werden kann, um sein Feedback einzuholen, noch dass dieses Review-Event als Erhebungsworkshop mit nur einem Kundenvertreter für neue User Stories genutzt werden kann.
In dieser Konstellation müssen neue Ideen eingebracht werden.
Als Ergänzung zum Review können an dieser Stelle Business Analysten unterstützen und den umgekehrten Weg einschlagen –  sie sind in der Rolle als Scouts vor Ort bei den Endanwendern und nicht die Endanwender sind bei den Entwicklern. Business Analysten können die unterschiedlichen User bei ihren täglichen Aufgaben beobachten und mit ihnen gemeinsam die alltäglichen Hürden und Problemstellungen analysieren. In Workshops vor Ort können die Bedürfnisse und Wünsche erhoben werden und dadurch kann eine erhebliche Menge an möglichen User Stories entstehen. Zudem könnten die BAs temporär selbst in die Rolle eines Endanwenders schlüpfen und Aufgaben übernehmen, um direkt die Problemstellungen in Erfahrung zu bringen. Darüber hinaus können sie Abläufe beim Kunden vor Ort analysieren und Anforderungen identifizieren, die die Ablaufaktivitäten noch besser unterstützen.
Laut Definition sind Scouts Späher oder Wegbereiter aus dem Umfeld des Sports, des Militärs oder der Pfadfinder, die nach getaner Arbeit wieder zurückkehren.
Also kehren auch unsere Scouts zurück zum Entwicklungsstandort, um gemeinsam mit dem Product Owner die gewonnenen Erkenntnisse in Form von User Stories zu konkretisieren,  zu priorisieren und dem Team vorzustellen.  Wichtig bei dieser Varianten ist es, die direkte Kommunikation zwischen PO und BA nicht zu vernachlässigen. Die Business Analysten dürfen keine Spezifikationen erstellen, die sie dem PO „über den Zaun werfen“. Dies würde nicht den Prinzipien des agilen Manifests entsprechen und wäre nach dem Lean-Ansatz eine der sieben Verschwendungen.

Pragmatisch statt dogmatisch
In einigen Organisationen ist eine großer Unsicherheit zu spüren, wenn es um Rollen geht, die im Scrum-Guide nicht vorgesehen sind. Sätze wie „wir sind nicht mehr agil, wenn wir kein reines Scrum machen“ sind zu hören.  An dieser Stelle möchte ich gerne das Agile Manifest ins Spiel bringen.
In den Werten und Prinzipien des agilen Manifests sind keine speziellen Rollen vorgesehen, so dass eine Organisation, die die Rolle BA weiter verwendet, trotzdem agil sein kann, wenn sie die Werte und Prinzipien des Manifests verinnerlicht und diese lebt. Scrum ist nur eine mögliche Umsetzung des Manifests – es gibt noch Alternativen oder gar die Möglichkeit, einen eigenen agilen Prozess zu implementieren. Zudem ist Scrum keine vollständige Methode, sondern ein Framework, das angereichert werden muss, damit es gelebt werden kann. So ist die User Story beispielsweise auch nicht verpflichtend und könnte durch ein anders „Backlog-Item“ ersetzt werden.

Fazit
Der Business Analyst kann eine Schlüsselrolle für ein agiles Team übernehmen, erfolgreich sein und akzeptiert werden.  Dazu ist es allerdings erforderlich, dass der BA zunächst die traditionelle Arbeitsweise im Umgang mit Anforderungen ablegt und bereit ist, sich neue Fähigkeiten und Techniken zu erarbeiten, die einem agilen Umfeld entsprechen, und er muss sich ein agiles Mindset aneignen. Die Arbeit vor Ort beim Endkunden kann in agil skalierten Umfeldern eine sinnvolle Ergänzung sein, um die Bedürfnisse und Anforderungen der Kunden noch besser zu erheben.

Andreas Becker

Kontaktieren Sie Andreas Becker

Andreas Becker ist Agile Transition Coach, Senior Consultant und Trainer bei HOOD GmbH / Agile-by-HOOD. Er begleitet Unternehmen bei der Transition zu agilen Organisationen und unterstützt bei der Implementierung von „Lean Thinking“. Im Fokus seiner Arbeit stehen agile Teams und Business Analysten in agil skalierten Umfeldern. Er ist in der Lean, Agile und Scrum Community aktiv und veröffentlicht Artikel, hält Vorträge und führt Workshops auf internationalen Konferenzen durch und ist zudem Lehrbeauftragter an der Hochschule Rosenheim für "Agile Produktentwicklung". Herr Becker ist zertifizierter Scaled Agile Framework - Program Consultant (SAFe), ScrumMaster und Product Owner. Neben seiner langjährigen Erfahrung im agilen Umfeld hat er in den Bereichen Requirements Engineering, Softwaretest- und Qualitätsmanagement in unterschiedlichen Branchen gearbeitet.