Sind Sie ein Business Analyst in einem agilen Projekt oder ein agiler Business Analyst?

In einer agilen Umgebung, insbesondere im Fall von großangelegten weltweit verteilten Teams, muss ein Business Analyst (BA) nicht nur ein „universeller Kommunikator“ in Bezug auf die Anforderungen sein, sondern muss auch als Product Owner agieren. Es gibt eine Denkrichtung, welche diese Entwicklung ablehnt. Die Kernaussage der genannten Denkrichtung besagt, dass ein BA, der in der Rolle des Product Owner agiert, seine zentralen Pflichten als Analytiker vernachlässigt.

Aufgrund unsere jahrelange Erfahrung mit komplexen globalen Projekten sind wir jedoch zu der Überzeugung gelangt, dass ein WA der als Product Owner agiert einem agilen Projekt einen enormen Mehrwert verleihen kann. Diese Entwicklung ist besonders für Firmen wichtig, die eine Tendenz zur agilen Projekten haben, sich jedoch ganz auf Agile Projekte konzentrieren wollen.

Ein agiles Rollenspiel

Die Anwesenheit eines BAs in einem Projekt implementiert in keiner Weise, dass wir den eigentlichen Product Owner abschaffen wollen. Es bedeutet nur, dass wir die Verantwortlichkeiten zwischen dem Owner und dem BA aufteilen. Wir sind davon überzeugt, dass ein BA in einem agilen Modell, darauf abzielen sollte, über die Aspekte des Erfassens der funktionalen Anforderungen hinaus, Kompetenzen in Produktstrategie, Technologie-Stacks und dem Aufbau von Beziehungen zu entwickeln.

 

Im weitesten Sinne sollte ein agiler BA:

Teil der Strategie sein
Normalerweise würde ein BA die Anforderungen der Stakeholder erfassen, diese dokumentieren, analysieren und kommunizieren. Dies würde sein Blickfeld auf die vorhandenen Anforderungen beschränken. Als Teil der Strategie schaut der BA über diese Anforderungen hinaus und analysiert das Geschäft, die Konkurrenzsituation und – besonders wichtig – die Produkt Strategie. Dies hilft dem Product Owner bei der Priorisierung von User-Stories, damit marktreife Produkte in kürzerer Zeit auf den Markt gebracht werden können.

Wir haben in vielen Projekten herausgefunden, dass die beteiligten Stakeholder (Verkauf, Marketing, Business Groups und Betrieb) „wussten“, was sie wollten, aber über keine gemeinsame Richtung verfügten. Die Formulierung einer strategischen Ausrichtung und die Konsensbildung erfordern ein Zusammenspiel aller dieser Parteien. Ein agiler BA kann hier die Kommunikation wesentlich unterstützen.

Ein [tiefgreifendes] Technologieverständnis haben
In einem traditionellen Geschäftsmodell befasst sich der BA nicht mit der im Projekt eingesetzt Technologie sondern konzentriert sich allein auf funktionale Anforderungen. So wie ein Produktbesitzer, sollte ein agiler BA seinen Beitrag zu der Technologiediskussionen leisten oder zumindest mit dabei sein. Dies stellt sicher, dass ein agiler BA während der Analyse der User-Stories dazu in der Lage wäre, Risiken, die sich aus technischen Herausforderungen ergeben, zu berücksichtigen.

Mit der Allgegenwärtigkeit von modernen Technologien, wie Cloud, Analytics und Internet der Dinge (IOT), hat unserer Erfahrung gezeigt, dass ein grundlegendes Wissen über die wichtigsten Plattformen und der darin enthaltenen Kompromisse dem WA dabei helfen, bei der Product-Roadmap und den nicht funktionalen Anforderungen einen Beitrag zu leisten.

Schnell Entscheidungen treffen können
Aufgrund seiner ausgeprägten Technologiekenntnisse und seines Wissens über Geschäftsstrategien wäre der BA dazu in der Lage, Entscheidungen in Echtzeit zu treffen. Der Großteil der Abklärungen im Hinblick auf Anforderungen könnte dann auf der Implementierungsebene getroffen werden und somit würden den Product Owner lediglich gefilterte Anfragen erreichen. Dies würde eine große Zeitersparnis durch kürzere Bearbeitungszeiten ergeben, was ein Hauptfaktor agiler Projekte ist.

Wir sind davon überzeugt, dass neben der Pflege von Rückständen, ein agiler WA in der Lage sein sollte, den Umfang zu verwalten, Versionen zu planen und UX Entscheidungen, wie z.B. bei Multi-Screen Support zu treffen.

Ein vertrauenswürdigen Partner werden
Wenn ein BA, in die Rolle eines Produktbesitzers schlüpft und die damit verbundenen Aufgaben abwickelt, werden ihn der tatsächliche Product Owner und die Stakeholder aus dem Geschäftsbereich als vertrauenswürdigen Partner wahrnehmen.

Wir haben es erlebt, dass der tatsächliche Product Owner – nachdem er sich mit der Rolle des agilen BA angefreundet hat – einige seiner Verantwortlichkeiten abgibt und somit mehr Zeit auf die Analyse des Geschäftswachstums verwenden kann, was letztendlich dem Gesamtgeschäft dienlich ist.

Die folgende Tabelle stellt einen Schnappschuss der verschiedenen Fokusbereiche dar und vergleicht die Rollen von traditionellen und agilen Business Analysts.

Auch das International Institute of Business Analysis (IIBA) hebt in seiner aktuellsten Version von BABoK™ (Business Analysis Body of Knowledge) die Notwendigkeit für eine Veränderung in der Rolle des BA hervor.

In zahlreichen Projekten haben wir die Beziehung zu unseren Kundenbeziehung auf ein Niveau gehoben, auf dem der Product Owner lediglich eine High Level-Kurzvariante der Anforderungen bereitstellt und unsere agilen BA von da an übernehmen. Diese entwickeln aus dieser Kurzvariante die genaueren Anforderungen, erstellen und pflegen den Product Backlog, planen Releases und führen selbst das User Acceptance Testing durch.

Dies ist es, was es uns erlaubt die Rolle eines wahren Partners für unsere Kunden erfüllen und deren und unseren Erfolg gemeinsam anzutreiben.