Agile Business Analyse: Vermeide Verschwendung

In mehreren Blog-Artikeln betrachten wir, wo und wie Business Analysten in agilen Vorgehensmodellen (z.B. Scrum) zum Einsatz kommen, welche Aufgaben und Aktivitäten sie dabei ausüben. Den Auftakt machte eine Übersicht zum Thema. Nach und nach erläutern wir die 7 Prinzipien für erfolgreiche „agile“ Business Analyse:

Drei Prinzipien beschreiben das Was? und Warum?

1. Sieh auf das Ganze (auf Personen, Prozessen und Technologie); mit den Techniken Personas und Value Stream Mapping (Wertstromanalyse).
2. Denke wie ein Kunde (und höre auf die Stimme des Kunden mit seinen Werten und Erwartungen); mit den Techniken User Story, Story Decomposition, Story Elaboration, Story Mapping.
3. Bestimme das Wertvolle (entwickle dadurch eine Lösung, die wertvoll und positiv bewertet ist); mit den Techniken Management des Backlogs, Kano-Analyse, Priorisierung mit MoSCoW.

Vier Prinzipien für das Wie? und Wann?

4. Nutze reale Beispiele (um echte Kundenbedürfnisse zu ermitteln und zu validieren); mit der Technik Behaviour Driven Development.
5. Verstehe, was machbar ist (und unterstütze dadurch die Entwickler in ihrer Umsetzung der Anforderungen); mit den Techniken Schätzung und Planungsworkshop.
6. Fördere Zusammenarbeit und kontinuierliche Verbesserung; mit den Techniken Collaborative Games und Retrospektive.
7. In diesem Blog-Artikel: Vermeide Verschwendung (und erkenne diese rechtzeitig).

Letztes der sieben Prinzipien: Vermeide Verschwendung (und erkenne diese rechtzeitig)

Agile Vorgehen betonen, wie wichtig es ist, dem Kunden eine funktionierende Lösung zu liefern. Business Analysten unterstützen dabei, indem sie die Bedürfnisse der Kunden verstehen. Dadurch kann das Team das liefern, was der Kunde wirklich braucht. Jede Aktivität, die dieses Ziel nicht verfolgt, oder für die der Kunde nicht bereit ist zu zahlen, ist Verschwendung.
Vermeidung von Verschwendung stammt ursprünglich aus dem Lean Management. Lean Management unterscheidet zwischen

• solche Aktivitäten, die Wert schaffen,
• und Muda (das japanische Wort für Verschwendung).

Verschwendung wiederum wird in zwei Bestandteile aufgeteilt:

• solche Aktivitäten, die zwar wertvoll sind, aber nicht direkt in das Endprodukt einfließen; dieses Muda soll so gering wie möglich gehalten werden (z.B. der Plan eines Architekten beim Bau eines Hauses),
• und die Aktivitäten, die gar keinen Wert erbringen; dieses Muda soll natürlich ganz vermieden werden.

Folgende Tipps helfen Verschwendung in der agilen Business Analyse (und nicht nur dort) zu erkennen:

1. Vermeide das Erstellen von Dokumentationen, bevor diese überhaupt irgendjemand benötigt.
2. Vermeide die Verschwendungsart Warten. Lass andere nicht auf Dich und Deine Ergebnisse warten, an denen Du noch nicht oder immer noch arbeitest.
3. Informationen in ein anderes (Datei-) Format oder andere Medientypen zu übertragen, erzeugt keinen Wert für das Endprodukt. Erhebe, analysiere, spezifiziere und validiere Anforderungen daher möglichst im selben Modell bzw. Format.
4. Gestalte Modelle so einfach wie möglich. Füge nicht Informationen hinzu, die für die Stakeholder unnütz sind.
5. Work-in-progress (WIP, also unvollendete Aktivitäten) bzw. Bestände entstehen aus Überproduktion und Wartezeiten. Sie könnten Probleme im Arbeitsprozess verbergen. Wenn Du WIP oder Bestände entdeckst, bearbeite sie weiter oder entferne sie.
6. Arbeite räumlich nah am Kunden und am Entwicklungsteam, denn unnötige Bewegungen sind Verschwendung; genauso wie unpersönliche Kommunikation Verschwendung sein kann.
7. Achte kontinuierlich auf exzellente Arbeit. Mangelnde Qualität (z.B. unklare Anforderungen) erfordern Nacharbeit und Doppelarbeiten, und damit die schlimmste Art von Verschwendung.

Als eine Technik, um Verschwendung zu vermeiden, bietet sich Lightweight Documentation an (leichtgewichtige Dokumentation).

Leichtgewichtige Dokumentation

• hat einen klaren Wert für die Stakeholder,
• wird erstellt, um ein aktuelles Bedürfnis zu erfüllen,
• und verursacht keinen unnötigen Aufwand.

In traditionellen Vorgehensmodellen nutzen die Entwickler die Dokumentation erst deutlich nach ihrer Erstellung. In agilen Vorgehen wird die Lösung innerhalb weniger Tage erstellt, nachdem die Umsetzung bestimmter Anforderungen beschlossen wurde. Daher sollte die Dokumentation keine Informationen enthalten, die das Team erst in späteren Iterationen beschließt.

Traditionell enthält die Dokumentation alle Informationen, die der Business Analyst über das behandelte Problem weiß. Die Spezifikation kann umfangreich den Kontext des Projektes beschreiben.
In agilen Projekten werden diese Informationen nicht schriftlich, sondern möglichst in der persönlichen Kommunikation weitergeben. (Als Beispiel für „schlanke“ Dokumentation sei hier die User Story genannt).

Möglicherweise schreiben externe Faktoren (zum Beispiel gesetzliche Bestimmungen) den Umfang und die Art der Dokumentation vor. Oder es ist sinnvoll Anforderungen, Entscheidungen und Funktionen der Lösungen langfristig zu speichern. Dies sollte allerdings erst nach der Entwicklung geschehen, um sicherzustellen dass die Dokumentation nur das beschreibt, was auch entwickelt wurde.

Leichtgewichtige Dokumentation ist ein Ansatz, der nicht nur für die Spezifizierung von Anforderungen in agilen Projekten gilt. Der Business Analyst sollte so wenig Dokumentation wie nötig erzeugen, und nur solche, die einen Mehrwert bietet.

Vorteile

• Reduzierter zeitlicher Aufwand für das Erstellen der Dokumentation.
• Weniger (Entwurfs-) Versionen der Dokumente.
• Reduzierter Aufwand für das Lesen und Überprüfen der Dokumentation.
• Alle Prüfer können sich auf die Kernpunkte konzentrieren und nicht auf belanglose Details.
• Persönliche Kommunikation berücksichtigt die unterschiedlichen Bedürfnisse der Empfänger; dies gilt für schriftliche Dokumentationen häufig nicht.

Nachteile

• Leichtgewichtige Dokumentation kann zu Konflikten mit Personen führen, die auf Einhaltung formaler Regeln achten.
• Möglicherweise deuten einige Personen „Leichtgewichtige Dokumentation“ zu „Keine Dokumentation“ um.
• Die Dokumentation erfüllt möglicherweise nicht gesetzliche Bestimmungen oder andere externe Anforderungen.

Damit enden (vorerst) die Blogartikel zur agilen Business Analyse. Ein Übersichtsartikel und je einer zu den sieben Prinzipien für agile Business Analysten finden ihren Abschluss.
Das Thema werde ich (spätestens) wieder aufgreifen, wenn IIBA eine aktualisierte Version der Agile Extension veröffentlicht. Ob dies schon bis zum nächsten ibo Trendforum der Fall ist? Wir werden sehen 😉

Weitere Informationen zum Thema Business-Analyse haben wir auf unserer Homepage für Sie zusammengefasst.