Business Analyse im klassischen, hybriden und agilen Projektkontext

by | 20.08.2017 | Requirements Engineering

Was bringt die neue BABOK® Agile Extension v2?

In diesem Beitrag erfahren Sie, dass Business Analyse sich im Kontext von Projekten mit unterschiedlichem Grad von Agilität ändern und an reale Situationen anpassen muss, um möglichst gute Ergebnisse zu erreichen. Die gerade erschienene zweite Version der Agile Extension der IIBA®, die sich am aktuellen BABOK® v3 [1]orientiert, führt neue Strukturen für agile Prinzipien und das Konzept der Planungshorizonte für die sogenannte agile Business Analyse ein. Diese stelle ich kurz vor und bewerte ihre praktische Relevanz.

Wie agil ist das Projekt?

Unter dem Agilitätsgrad von Projekten verstehen wir das Maß an Agilität, das in Projekten vorzufinden ist. Projekte sind heutzutage in den wenigsten Fällen rein „klassisch“ oder rein „agil“. Auch der oft verwendete Begriff „hybrid“ als Mischform spiegelt die Realität nur recht unpräzise wieder. Die Agilität in realen Projekten hat vielmehr den Charakter einer analogen Größe, sie ist stufenlos, von klassisch bis agil und mit unzähligen Ausprägungen dazwischen.

Kann ein Projekt also ein „bisschen“ agil sein und ein anderes Projekt ein wenig mehr? Wir denken die Antwort ist ja, absolut! Die meisten Unternehmen, die Agilität in ihr Projektmanagement erfolgreich eingeführt haben, sind schrittweise vorgegangen. Sie haben mit ausgesuchten, vielleicht kleineren Projekten experimentiert, kontinuierlich aus Erfahrungen gelernt und mit der Zeit immer mehr Agilität erfolgreich eingeführt. Die Organisation von Projekten wird so vom inneren Mindset her immer agiler, der Grad der Agilität, nach und nach auch in größeren Projekten, steigt. Agilität ist ein Wertesystem, das zwangsläufig die Kultur im Unternehmen ändert – und das braucht ein wenig Zeit. Das schnelle, überstürzte Einführen von Agilität in einem großen Schritt ist zum Scheitern verurteilt, besonders in großen Unternehmen mit vielen, unterschiedlich gepolten Stakeholdern und einer komplexen, vielschichtigen Kultur. Durch gescheiterte Versuche Agilität einzuführen ist der Begriff „agil“ in manchen Unternehmen regelrecht verbrannt worden, weitere Versuche gestalten sich dann deutlich schwieriger oder werden mangels interner Unterstützung erst gar nicht unternommen.

Was bedeutet dies nun für die Business Analyse im Projekt? Inwieweit beeinflusst der Grad der Agilität des Projekts die Arbeit des Business Analysten? Die Antwort ist hier: erheblich! Die erfolgreichen Techniken und Vorgehensweisen der Business Analyse sind unmittelbar abhängig von denen im Projektmanagement und müssen sehr sorgfältig, möglichst individuell in jedem Projekt, angepasst und zugeschnitten werden. Und das betrifft insbesondere radikale agile Elemente wie den Verzicht auf detaillierte Feinspezifikationen der Anforderungen. Was in einem Projekt funktioniert hat, kann im nächsten Projekt fehlschlagen. Das ist die ernüchternde Erkenntnis aus jahrelanger Praxis und jedes Mal eine erneute Herausforderung für alle Business Analysten, die in Projekten arbeiten.

Was bringt die agile Extension des BABOK® für den Zuschnitt einer passenden agilen Business Analyse?

Um diese Frage beantworten zu können, stelle ich die zum BABOK® v3 gehörende Agile Extension v2 [2] kurz vor. Die Extension führt sieben Prinzipien für die agile Business Analyse ein, die auf dem agilen Manifesto [3] und dem Business Analysis Core Concept Model des BABOK® v3 basieren. Das 2001 von namhaften Experten in den USA formulierte agile Manifesto für die Softwareentwicklung ist die weltweit anerkannte Basis allen agilen Gedankenguts und stellt die hervorgehobenen Werte auf der linken Seite über die auf der rechten Seite.

Agile Manifesto

Die sieben Prinzipien der Business Analyse greifen diese Werte nun auf drei verschiedenen Kontextebenen auf, den sogenannten Planungshorizonten, die ich nun noch vor den sieben Prinzipien einführen werde. Einfach erklärt bedeutet dies, dass die Business Analyse Prinzipien in den drei üblichen Projektphasen, Initiierung, Planung und Durchführung unterschiedliche Ausprägungen haben. Die erste Phase findet hierbei oft schon vor dem eigentlichen Hauptprojekt statt, als Strategieanalyse, Vorprojekt oder Machbarkeitsstudie und kann ggfs. natürlich auch dazu führen, dass die Investition in ein Projekt nicht getätigt wird. Insofern hinkt der Vergleich der Planungshorizonte mit Projektphasen oder PMBOK®-Prozessgruppen [4], macht aber für einen einfachen Einstieg in die Thematik durchaus Sinn. Die Bezeichnungen der drei Planungshorizonte passen somit auch in unser allgemeines Verständnis:

Concept of Horizons

Das Concept of Horizons

Strategy – oft ausserhalb von Projekten, auf Strategie- oder Portfolioebene
Initiative – meist im frühen Projektkontext, wenn eine Initiative (ein Projekt) konkret geplant wird
Delivery – Lieferungen (Output) am Ende, aber vor allem auch während des Projektes

 

Die sieben Prinzipien lauten nun wie folgt:

Prinzipien der agilen Business Analyse

Prinzipien der agilen Business Analyse

28ee the Whole
Das große Ganze sehen bedeutet, den Bedarf des Unternehmens im vorliegenden Kontext zu verstehen und in diesem Umfeld machbare Lösungen zu bewerten und später zu begleiten, je nach Planungshorizont. Die Zusammenarbeit mit dem Kunden aus dem agilen Manifesto wird hier sprichwörtlich großgeschrieben.

Think as a Customer
Business Analysten arbeiten in agilen Umgebungen oft als Product Owner oder arbeiten mit oder für POs. In diesen Funktionen ist eine Voice-of-the-Customer-Attitüde wichtig um die Interessen des Kunden wirksam zu vertreten und in enger und ständiger Zusammenarbeit Lösungen zu entwickeln, die dem Fachbereichen des Kunden möglichst hohen Nutzen bringen.

Analyze to Determine What is Valuable
Dieses Prinzip zielt sehr stark auf eine nutzenorientierte Priorisierung. Ein Business Analyst wird in agilen Umgebungen meist die Verantwortung für die Priorisierung des Backlogs haben oder die Verantwortlichen zumindest beeinflussen können. Hierbei soll der Schwerpunkt auf den Liefergegenständen liegen, die dem Kunden unmittelbar Nutzen bieten. Die Formulierung „Maximizing the amount of work not done“ klingt paradox aber beschreibt sehr treffend, dass Arbeiten, die dem Kunden keinen Nutzen bringen, minimiert werden sollten.

Get Real Using Examples
„Werde konkret und erläutere deine Vorstellungen anschaulich mit Hilfe von Modellen“ ist eine gut geeignete Übersetzung dieses Prinzips. Stakeholdern komplexe Zusammenhänge zu erläutern ist nicht einfach, die Kommunikation muss sorgfältig vorbereitet und durch Modelle anschaulicher gestaltet werden, ansonsten kommt man nur schwerlich zu einem gemeinsamen Verständnis des Nutzens, den die geplanten Produkte und Lösungen bieten sollen.

Understand What is Doable
Business Analysten müssen ein gutes Verständnis dafür haben, welche Lösungen oder Lösungskomponenten in Rahmen des Projektes realisiert werden können. Einschränkungen finanzieller Art, Kapazitäten oder Zeitvorgaben spielen oft maßgebliche Rollen und bestimmen den Rahmen der Möglichkeiten.

Stimulate Collaboration and Continuous Improvement
Kontinuierliche Verbesserung und ständiges Lernen ist ein Kernelement der agilen Vorgehensweise. Business Analysten sind aufgefordert, die agilen Elemente wie Empirik oder Retrospectives (eine agile Form des aus dem klassischen Projektmanagement bekannten Lessons Learned) zu unterstützen und somit eine ständige Weiterentwicklung der Kunden- und Lieferantenteams zu fördern.

Avoid Waste
Dieses Prinzip geht zurück auf die japanische Philosophie Kaizen und das durch Toyota stark beeinflusste Lean Management. Während es Dinge gibt, die der Kunde nicht als wertvoll wahrnimmt, die aber trotzdem notwendig sind in der Architektur der Lösungen, gibt es auch immer wieder Arbeiten für Dinge, die keinen Nutzen stiften. Diese sollten natürlich unterlassen werden. Aber auch das sogenannte Re-Work, also die Überarbeitung von vermeintlich schon fertigen Komponenten kann minimiert werden. Ein zunächst nicht ganz offensichtlicher Aspekt ist, dass Entscheidungen erst dann getroffen werden sollen, wenn man sie auch treffen muss. Oder dass Dokumentation erst dann geliefert werden muss, wenn sie auch benötigt wird.

Fazit

Die agile Extension in der vorliegenden Version 2 ist eine Bereicherung für jeden Business Analysten, insbesondere wenn in wenig „agil“ entwickelten Umgebungen gearbeitet wird. Viele Unternehmen befinden sich in einer Übergangsphase zwischen klassischen und agilen Vorgehensweisen und werden diese Phase auch in absehbarer Zeit nicht abschließen können, sie vielleicht bis auf Weiteres als Status Quo akzeptieren müssen. Vor diesem Hintergrund ist es wichtig, dass Business Analysten die agilen Prinzipien verstehen und in ihrer Arbeit weiter fördern und entwickeln können. In Ergänzung zum BABOK® 3 ist die agile Extension hier sicherlich hilfreich, reicht aber bei Weitem nicht aus. Das Studium von weiterführender Literatur zum Thema Agilität und der persönliche Austausch mit Experten ist unverzichtbar. Hier sollte man übrigens nicht dem Trugschluss unterliegen, dass die Auseinandersetzung mit der agilen Projektmanagementmethode Scrum ausreicht. Viel wichtiger als den Scrum-Prozess zu verstehen ist eine Verinnerlichung der agilen Werte. Das ist in der „Agile Extension to the BABOK® Guide“ aus meiner Sicht sehr gut umgesetzt, Kompliment an die Autoren!

 

Quellen:
[1] Business Analysis Body of Knowledge BABOK® v3, International Institute of Business Analysis IIBA®, Toronto 2015, http://www.iiba.org/babok-guide.aspx 
[2] Agile Extension to the BABOK® Guide v2, International Institute of Business Analysis IIBA®, 2017, http://www.iiba.org/babok-guide/Agile-Extension-to-the-BABOK-Guide-IIBA.aspx 
[3] Agile Manifesto, 2001, http://agilemanifesto.org/iso/de/manifesto.html 
[4] Mehr zum Project Management Body of Knowledge auf Wikipedia: https://en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge