The Agile Extension to the BABOK-Guide

Das ist die Zusammenfassung eines Webinars, das am 17.10.2014 im Rahmen des Austria Chapters des International Institute of  Business Analysis gehalten wurde. Eine Aufzeichnung dieses Webinars finden Sie auf YouTube.

Business Analyse und agile Software-Entwicklung

Gerade als Business Analyst ist man besonders von sich ändernden Anforderungen betroffen. Nur allzu oft tauchen im Laufe des Analyse-Prozesses neue Fakten auf, die ganze Konzepte auf den Kopf stellen und viele  bereits erstellte Dokumente wertlos machen.

Genau hier setzen die agilen Methoden an, die von Haus aus mit sich ändernden Anforderungen rechnen und die Prozesse darauf einstellen.

Diese agilen Methoden haben natürlich auch Auswirkungen auf die Tätigkeit der Business Analysten. Das geht soweit, dass sogar die Tätigkeit der Business Analyse an und für sich in Frage gestellt wird. Hier hat das International Institute of Business Analysis (IIBA) sehr bald reagiert und mit der "Agile Extension to the Business Analysis Body of Knowledge" die Rolle des Business Analysten im agilen Umfeld definiert.

Die "Agile Extension to the BABOK® Guide"

Die "Agile Extension" ist ein Dokument, das man von der Web-Site des IIBA herunterladen kann. Für Mitglieder des IIBA ist das kostenlos, für Nicht-Mitglieder kostet sie knapp 15 Dollar.

Agile Methoden werden ja schon in der aktuellen  Version 2 des "Business Analysis Body of Knowledge" (BABOK-Guide) angesprochen. Es wird dort durchgehend die Unterscheidung zwischen "plan-driven" und "change-driven" getroffen, wobei "plan-driven" traditionelle Vorgangsweisen bezeichnen und mit "change-driven" agile Methoden gemeint sind.

Eine der Neuerungen der kommenden Version 3 des BABOK-Guide sind die so genannten "Perspektiven". Der BABOK-Guide beschreibt die Business Analyse sehr allgemein. Die "Perspektiven" stellen nun Spezialisierungen für bestimmte Anwendungsfälle dar. Im BABOK 3 werden voraussichtlich folgende Perspektiven vorgestellt:

• Information Technology
• Business Intelligence
• Business Process Analysis
• Enterprise Architecture
• Agile

Ziel des IIBA ist es, dass es für jede dieser "Perspektiven" eine eigene "Extension" geben soll. Die "Agile Extension" ist also ein Vorreiter in dieser Beziehung.

Die "Agile Extension" selbst setzt sich folgende Ziele:

• Einführung in agile Methoden für Business Analysten
• Überblick über  Business Analyse-Techniken für Kenner von agilen Methoden
• Aufzeigen von typischen Arbeitsweisen, die von Business Analysten in agilen Projekten angewendet werden
• Überblick über neue und geänderte Rollen, Fähigkeiten und Kompetenzen von Business Analysten in agilen Projekten.

Der Inhalt wird in folgende vier Kapitel gegliedert:

1. Einführung in die "Agile Extension"
2. Business Analyse in agilen Ansätzen: es wird allgemein beschrieben, wie in agilen Ansätzen Business Analyse betrieben wird
3. Agiles Vorgehen in den Knowledge Areas des BABOK-Guides: es werden jeweils die Besonderheiten der jeweiligen Tasks in agilen Projekten beschrieben
4. Agile Techniken: Die Agile Extension führt insgesamt 20 Techniken an, die im vierten Abschnitt beschrieben werden.

Bevor sich die Agile Extension der Frage zuwendet, wie Business Analyse in agilen Projekten betrieben wird, wird auf die Frage eingegangen, was "agil" denn nun eigentlich bedeutet. Neben dem allseits bekannten Scrum gibt es eine Reihe weiterer Methoden, die als "agil" bezeichnet werden. Sie haben alle ihre Besonderheiten und haben doch einen gemeinsamen Kern, auf den sie sich berufen: das so genannte "Agile Manifest", das im Jahr 2001 formuliert wurde. In diesem Manifest werden Prinzipien auf dem Gebiet der Software-Entwicklung in vier Prinzipien zusammengefasst. Diese lauten:

1. Individuen und Interaktionen vor Prozessen und Werkzeugen
2. Funktionierende Software vor umfassender Dokumentation
3. Zusammenarbeit mit dem Kunden vor Vertragsverhandlungen
4. Reagieren auf Veränderungen vor Befolgen eines Plans.

Wichtig ist, dass jeder dieser vier Punkte kein "Entweder - Oder" darstellt, sondern dass jeweils auch die rechte Seite jedes Satzes wichtig ist - nur die Punkte auf der linken Seite werden mehr geschätzt und als wichtiger erachtet.

Gemeinsam sind den einzelnen Methoden auch kurze Iterationszyklen und eine Vereinfachung des Software-Entwicklungs-Prozesses. Diese Vereinfachung geht - wie schon erwähnt - zum Teil so weit, dass auch die Existenz des Business Analysten in Frage gestellt wird.

In den ersten Jahren der Entwicklung der agilen Methoden konnte häufig tatsächlich eine einzelne Person alle Entscheidungen in einem Software-Entwicklungsprojekt treffen - wie es eben für den Product Owner in Scrum vorgesehen ist. So schien es tatsächlich plausibel, dass man Business Analyse in agilen Projekten überhaupt nicht mehr braucht.

Mit der Zeit wurden allerdings die Projekte größer und agile Methoden wurden in größeren und unterschiedlicheren Organisationen eingesetzt. Damit wuchs auch die Bedeutung von Business Analyse-Fähigkeiten in den Projekten wieder.

Wie aber kann die Tätigkeit eines Business Analysten in einem agilen Projekt aussehen? Die Agile Extension nennt dabei folgende Möglichkeiten:

1. Der Business Analyst als Kommunikator, der die unterschiedlichen Stakeholder zusammen bringt
2. Der Business Analyst als Product Owner, der vom Fachbereich ermächtigt ist, Entscheidungen zu treffen
3. Der Business Analyst als Vertreter des Product Owner, der ihn bei Bedarf vertritt
4. Der Business Analyst als Coach des Product Owners, wenn dieser zwar hohe Fachkenntnis aber limitiertes Umsetzungs-Know-How hat
5. Der Business Analyst als Autor und Kommunikator der Akzeptanz-Kriterien
6. Der Business Analyst als Autor der Akzeptanz-Tests
7. Der Business Analyst als "Hüter" des Business Value des Projekts
8. Der Business Analyst als Autor von wichtigen Anforderungen, die von den übrigen Stakeholdern nicht ausreichend repräsentiert sind.

Aus der Vielzahl der agilen Methoden greift die Agile Extension folgende drei heraus und erläutert sie näher:

1.  Scrum: ist die bekannteste und verbreitetste der agilen Methoden. Scrum ist gekennzeichnet durch festgelegte Iterationszyklen (Sprints),definierte Rollen (Product Owner, Scrum Master und das Entwicklungs-Team) sowie durch eine Reihe von formalen Meetings (Sprint Planning, Sprint Review, Daily Standups, Retrospektiven).
2. Extreme Programming: hat zwar als Methode nicht die Bekanntheit erlangt wie etwa Scrum und Kanban; einzelne Elemente, wie User Stories oder Test-Driven-Development haben Eingang in die anderen Methoden gefunden bzw. auch als eigenständige Techniken Bedeutung erlangt.
3. Kanban: ist eine Methode, die keine Änderungen an der bestehenden Organisation verlangt. Besonderer Wert wird auf einen störungsfreien Arbeitsfluss und eine kontinuierliche Verbesserung desselben gelegt.

Agiles Vorgehen in den Knowledge Areas des BABOK 2.0

Im dritten Abschnitt stellt die Agile Extension eine Beziehung her zwischen den Knowledge Areas des BABOK und den agilen Vorgangsweisen. Der BABOK fasst ja die Tätigkeiten, also die Tasks, eines Business Analysten zu so genannten Knowledge Areas (Wissensgebieten) zusammen.

Business Analysis Planning and Monitoring

Die Knowledge Area "Business Analysis Planning and Monitoring" befasst sich mit der Planung des Business Analyse-Prozesses. Es wird der so genannte Business Analysis-Approach festgelegt - also die Entscheidung, ob traditionell oder agil vorgegangen wird. Es werden die Stakeholder ermittelt, es werden die Aktivitäten und die Kommunikation geplant.

Im agilen Vorgehen wird auf mehreren Ebenen geplant: Zunächst erfolgt eines so genannte Strategy Planning, wo die Vision des Produktes entwickelt wird, das anschließend in mehreren Iterationen realisiert wird. In der Release Planning wird bestimmt, welche Funktionalität in die nächste auszuliefernde Version des Produktes kommen soll. Eine Release zieht sich über mehrere Iterationen (also etwa Sprints in Scrum). In der Iteration Planning wird festgelegt, welche Funktionalität in einer Iteration entwickelt wird - das Team kommittiert sich zu diesem Plan. Innerhalb einer Iteration erfolgt eine tägliche - kurze - Planung der Tätigkeiten, die an diesem Tag zu erfüllen sind  (Daily Work Planning). Und schließlich spricht man noch von einer fortlaufenden Aktivitätsplanung (Continuous Activity Planning).

Elicitation

Die Elicitation - also die Erhebung der Anforderungen - ist in agilen Ansätzen ein fortdauernder Prozess, der in jeder Iteration von neuem durchgeführt werden muss. Die Anforderungen für jede Iteration werden kurz vor oder in der Iteration - just in time - erhoben. Allerdings ist eine initiale Erhebung der Anforderungen vor den Iterationen erforderlich, damit überhaupt einmal die Vision des Projekts entwickelt werden kann.

Requirements Management and Communication

Der erste Task der Knowledge Area "Requirements Management and Communication" nennt sich "Manage Solution Scope and Requirements". Es geht dabei darum, sicherzustellen, dass es nicht zu einer schleichenden Ausweitung des Scopes kommt - also zum so genannten "Scope Creep". Hier stellt sich die Situation in einer agilen Vorgehensweise grundlegend anders dar: Es wird der Scope von vorneherein nicht endgültig festgelegt - Änderungen im Scope sind systemimmanent. Vor jeder Iteration wird über das Backlog festgelegt, welche Anforderungen in der Iteration realisiert werden.

Auch der Task "Prepare for Reuse" stellt sich im agilen Ansatz etwas anders dar: Voraussetzung dafür, dass Anforderungen wiederverwendet werden können, ist es, dass sie gut dokumentiert sind. Im agilen Ansatz ist jedoch, wie wir schon gesehen haben, Dokumentation kein besonders hohes Gut. Wenn man daher Wiederverwendung anstrebt, muss man doch - zum Teil gegen die agilen Werte - der Dokumentation eine höhere Bedeutung zumessen.

Die Kommunikation steht im Zentrum der agilen Methoden und wird durch die "ceremonies" abgedeckt: Daily Standups, Retrospektiven und dergleichen.

Enterprise Analysis

Die Enterprise Analysis, also die Unternehmensanalyse, wird tendenziell im Vorfeld - vor den Iterationen - durchgeführt. Auswirkungen gibt es insbesondere auf folgende Tasks:

Einerseits ist da der Task "Determine Solution Approach": Agil ist ja selbst ein "Solution Approach" - hier würde also die Entscheidung fallen, dass überhaupt agil vorgegangen werden soll.

Ein weiterer Task, auf den das agile Vorgehen eine Auswirkung hat, ist "Define Solution Scope". Im agilen Vorgehen ist der Scope nicht etwas, das am Beginn unveränderlich festgelegt wird, sondern das im Prinzip in jeder Iteration neu definiert wird.

Requirements Analysis

In der Knowledge Area "Requirements Analysis" geht es um die Analyse der erhobenen Anforderungen - um deren Priorisierung, deren Organisation - und schließlich auch um deren Qualitätssicherung.

Die Priorisierung wird im agilen Vorgehen durch das Backlogmanagement übernommen. Was im Backlog oben steht, wird in der nächsten Iteration durchgeführt und das Backlog wird vor jeder Iteration neu konzipiert.

Typischerweise werden in agilen Methoden die Anforderungen in der Form von User Stories organisiert.

Wie so vieles ist auch die Spezifikation und Modellierung der Anforderungen kein einmaliger Vorgang, der am Beginn durchgeführt wird - sondern ein fortlaufender Prozess der - just in time - vor der Umsetzung durchgeführt wird.

Auch die Qualitätssicherung der Anforderungen (das "Verify" and "Validate") ist ein Task, der jeweils am Ende jeder Iteration gemacht wird.

Solution Assessment and Validation

Das Ziel jeder Iteration ist es, lauffähige Software zu liefern. Und die Tasks der Knowledge Area "Solution Assessment and Validation" können nach jeder Iteration angewandt werden.

Die Techniken in agilen Methoden

Im vierten Abschnitt behandelt die Agile Extension eine Reihe von agilen Techniken. Es handelt sich dabei um Techniken, die nicht auf agile Vorgehensweisen beschränkt sind. Viele der genannten Techniken sind unabhängig davon entstanden. Sie unterstützen aber das "agile Mindset" - wenn man von so etwas sprechen kann - besonders. Die Agile Extension beschränkt sich nicht auf eine reine Aufzählung dieser Techniken - sondern sie bringt sie in einen Kontext mit diesem "agilen Mindset" und formuliert zu diesem Zweck sieben Grundsätze der agilen Vorgehensweisen.

See the Whole

Der erste Grundsatz "See the Whole" meint, dass in agilen Vorgehen das "Big Picture" besonders beachtet wird - dass der jeweilige Geschäftskontext besondere Beachtung findet - ein Grundsatz, den die agilen Methoden mit der Business Analyse gemeinsam haben.

Gerade in agilen Vorgehensweisen besteht die Gefahr, in den Details der Iterationen das große Ganze aus den Augen zu verlieren. Folgende Techniken sollen diesen Grundsatz unterstützen:

• Business Capability Analysis: Soll helfen, über die Iterationen hinweg einen konstanten Blick auf die Fähigkeiten (capabilities) der Organisation zu behalten - um den Business Value nicht aus den Augen zu verlieren. Die Capabilities beschreiben dabei die Möglichkeiten einer Organisation, bestimmte Tätigkeiten oder Transformationen auszuführen. Wichtiges Instrument dafür sind so genannte Capability Maps, die analysierte Fähigkeiten graphisch darstellen.
• Personas: Es werden fiktionale Charaktere verwendet, um darzustellen, wie typische Benutzer ein Produkt verwenden. Diese Personas werden beschrieben, als wären sie eine reale Person - mit Namen, Persönlichkeiten, Familie, beruflichem Hintergrund. Ziel ist es dabei ein tieferes Verständnis für die Bedürfnisse der jeweiligen Stakeholder zu erzielen.
• Value Stream Mapping: Dabei wird der Material- und Informationsfluss dargestellt, der erforderlich ist, um ein Produkt oder eine Dienstleistung auf den Markt zu bringen. Auf diese Weise sollen potenzielle Verbesserungen in diesem Prozess identifiziert werden.

Think as a Customer

"Think as a Customer" bedeutet, dass das zu lösende Problem hauptsächlich aus der Sicht des "Kunden" wahrgenommen wird - also desjenigen, für den der Business Value geliefert wird. Letztlich bedeutet das nichts anderes als die Konzentration auf den "Business Value", der auch im Zentrum der Business Analyse steht. Es gibt hier also ein große Übereinstimmung mit den agilen Methoden.

Die Antwort der agilen Methoden auf diese Herausforderung lautet "User Story": die Anforderung wird aus der Sicht des jeweiligen Stakeholders formuliert - und enthält auch den jeweiligen Nutzen für ihn. Rund um diese User Story führt die Agile Extension einige Techniken an, die das Herunterbrechen aus dem Gesamtziel, die Ausarbeitung und die gesamthafte Darstellung betreffen. Insgesamt werden folgende Techniken genannt:

• Story Decomposition
• Story Elaboration
• Story Mapping
• User Story
• Storyboarding.

Analyze to Determine What is Valuable

Die kontinuierliche Frage nach dem Business Value verbindet die Business Analyse mit den agilen Methoden. Das wird lt. Agile Extension durch folgende Techniken unterstützt:

• Backlog Management: ist keine Technik im eigentlichen Sinn. Aber das Backlog spielt in jeder der agilen Methoden eine bedeutende Rolle. Über das Backlog wird sowohl der Scope als auch die Priorisierung der Anforderungen gesteuert.
• Business Value Definition:
• Kano Analyse: die Kano Analyse gliedert die Anforderungen in:
• Basisfaktoren: Anforderungen, die vom Stakeholder als selbstverständlich genommen werden und deshalb gar nicht erwähnt werden. Sie führen zwar zu Unzufriedenheit, wenn sie nicht vorhanden sind, führen aber auch bei Vorhandensein nicht zu Zufriedenheit.
• Begeisterungsfaktoren: diese werden vom Stakeholder nicht erwartet, führen aber zu hoher Zufriedenheit, wenn sie doch realisiert werden.
• Leistungsfaktoren: das sind die klassischen Anforderungen, die von den Stakeholdern explizit ausgesprochen werden und die zu Unzufriedenheit führen, wenn sie nicht vorhanden sind und zu Zufriedenheit, wenn sie implementiert werden.
• Moscow Prioritization: diese wird auch schon im BABOK-Guide angeführt. Es werden die Anforderungen in Must-, Should und Could-Anforderungen gegliedert.
• Purpose Alignment Model:

Get Real Using Examples

Ein weiterer Grundsatz der agilen Vorgehensweise ist es, dass vorwiegend mit realen Beispielen gearbeitet wird. In der Realität ist es dann häufig so, dass teamintern mit Modellen - also z. B. mit UML-Klassenmodellen und dergleichen - und im Verhältnis zu den Stakeholdern mit Beispielen gearbeitet wird.

Für diesen Grundsatz nennt die Agile Extension nur eine Technik:

• Behavior Driven Development: formuliert die Beispiele nach einer bestimmten Syntax:
• GIVEN: es wird ein bestimmter Kontext beschrieben
• WHEN: beschreibt einen Trigger bzw. eine Bedingung, die erfüllt ist
• THEN: stellt die Reaktion des Systems auf den Auslöser dar.

Understand What is Doable

Das Verständnis für die Machbarkeit wird dadurch zum Ausdruck gebracht, dass sich das Team vor jeder Iteration zu dem zu lösenden Umfang kommittiert. Um das zu können, kommen geeignete Schätzmethoden zum Einsatz.

• Relative Estimation: Die Idee dahinter ist, dem jeweils zu leistenden Arbeitspensum - also etwa z. B. in Scrum einer User Story - einen relativen Zahlenwert zuzuweisen. Relativ ist dieser Wert im Hinblick auf andere Arbeitspakete - andere User Stories. Man spricht von "Story Points". Aus der Anzahl an Story Points, die ein Team in der Lage ist, umzusetzen, ergibt sich die Velocity. Die Anzahl der Story Points ergibt sich aus dem Umfang des Problems, der Schwierigkeit, dem Neuigkeitsgrad für das Team. Für die Ermittlung der Story Points gibt es wiederum verschiedene Möglichkeiten, wie z. B. Planungspoker - eine Art Abstimmung unter den Teammitgliedern.
• Planning Workshop: die Schätzwerte werden in einem Meeting zwischen den Beteiligten ermittelt.
• Real Options: dabei handelt es sich um eine Methode aus der Finanzwirtschaft. Sie geht davon aus, dass Optionen - also Wahlmöglichkeiten - wertvoll sind und dass diese Optionen ein Ablaufdatum haben. Die Empfehlung ist, sich nicht vorschnell auf eine Option festzulegen, aber auch den richtigen Zeitpunkt für eine Entscheidung zu erwischen, bevor eine Option ausläuft.

Stimulate Collaboration and Continuous Improvement

Zusammenarbeit - Collaboration - ist ebenso ein Schlüsselwert in den agilen Methoden. Das führt unter anderem auch dazu, dass - etwa in Scrum - die klassischen Rollenbilder weitgehend aufgelöst werden. Es gibt zwar im Team Spezialisierungen, aber prinzipiell ist es so, dass jeder alles machen können sollte.

Die "ständige Verbesserung" ist insbesondere ein Merkmal von "Kanban".

Die agile Extension führt folgende Techniken für diesen Wert an:

• Collaborative Games: In spielerischer Form sollen neue Ideen gefunden bzw. Probleme gelöst werden. Als Beispiel wird unter anderem das Spiel "Product Box" angeführt. Dabei geht es darum, gemeinsam die - fiktive - Verpackung für ein zu entwickelndes Produkt zu gestalten. Hintergrund ist, dass auf der Verpackung die wesentlichen Features und der zu erzielende Nutzen besonders herausgestrichen wird. Auf diese Weise sollen die Features und der Nutzen gemeinsam herausgearbeitet werden.
• Retrospektiven: das Team betrachtet kritisch seine eigene Vorgangsweise im Hinblick darauf, was gut war und wo es Verbesserungsbedarf gibt. Aus dieser Erkenntnis sollen Lehren für die zukünftige Vorgangsweise gezogen werden. Diese Technik ist vergleichbar damit, was im BABOK schon als Lessons-Learned-Session bekannt ist.

Avoid Waste

Nur das produzieren, was nötig ist und so zu einer Verschlankung der Prozesse zu kommen, ist ein weiteres entscheidendes Charakteristikum der agilen Methoden.

• Lightweight Documentation: Im Zentrum steht das Liefern von funktionsfähiger Software. Alle Aktivitäten, die nicht diesem Ziel dienen, werden als untergeordnet betrachtet. Das gilt auch für die Dokumentation. Das heißt nicht, dass Dokumentation als völlig überflüssig betrachtet wird. Aber es soll nur jene Dokumentation produziert werden, die einen dezidierten Zweck erfüllt - eine Produktion "für den Aktenschrank" soll vermieden werden.
  Was jeweils als notwendig betrachtet wird, ist auch abhängig vom Projekt - in einer streng reglementierten Umgebung, die umfangreiche Dokumentation verlangt, hat diese auch einen Wert und ist kein "Waste".