Agile Business Analyse für wirklichen Echtzeitnutzen

Grundsätzlich meine ich, dass sich die agile Business Analyse (aBA) wesentlich durch veränderte Inputparameter, wie z. B. Value Driven Approach, Input-Zeitpunkte, iterativem Denken, Lightweight Documentation oder die Art und Weise des Prototyping von der herkömmlichen BA unterscheidet. Die Herangehensweise zur Analyse, den User Story Schätzungen und deren Prirosierung sind für mich die entscheidensten Punkte einer agilen Business Analyse. Wann hört man schon von Design Comics, User Story Mapping oder Collaborative Games in der herkömmlichen BA-Praxis? Auch bin ich tief davon überzeugt, dass agile BA nur dann funktioniert, wenn man  zumindest ein paar agile Approaches „intus“ hat. Nur wenn man zumindest den Scrum,- XP, Kanban,- und Behavior Driven Development Prozess von A – Z verstanden hat, kann man auch tatsächlich für die Product Owner, für die Developer, für die Tester und last but not least für die End User Echtzeitnutzen stiften.

Was heißt Agilität für die Business Analyse?

Ich gestatte mir das inhaltlich sehr aussagekräftige „Manifesto for Agile Software Developement“ 1:1 zu zitieren, denn die englische Formulierung ist an Eloquenz nicht zu übertreffen.

We are uncovering better ways of developning software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over coprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

user-story-flow
Worst Case Szenario eines User Story Flow, Kobald Agile Expert & IT Projects, 2017

Oft ist es so, dass den Stakeholdern, Usern und manch einem BA nicht ganz klar ist, dass wir zwischen Problemen, Anforderungen, Business Regeln, Statements und Symptomen unterscheiden müssen. Ein Symptom wäre etwa ein gefühltes Problem, dass sich mit Zahlen nicht verifizieren lässt. Eine Anforderung kann m. M. nach erst dann entstehen, wenn ein spezifisches Problem erkannt, verstanden und analysiert ist. Zu dieser Analyse gehört unbedingt das Story Mapping sowie die User Story Estimations. Diese und ähnliche Missverständnisse können zum BA-Flow führen, wie in der Abbildung weiter oben von mir scherzhaft dargestellt.

Geschäftsnutzen ohne Shelfware 

value-driven-approach
Value Driven Approach, Kobald Agile Expert & IT Projects, 2017

In einer globalen US-Studie in den 1990er Jahren kam ans Tageslicht, dass 40% bestellter Features in der Softwareentwicklung vom Enduser zwar bestellt, aber nie genutzt wurden. Eine Studie in den USA und in UK aus dem Jahr 2011 hat sich auf die Frage nach dem verschwendeten Geld von gelieferten, aber nicht genutzten Funktionalitäten von Softwareprodukten konzentriert. Der Anteil an der so genannten Shelfware betrug gesamt 50 Mrd. US-Dollar. Eine weitere internationale Studie unter IT-Entscheidern in Großunternehmen in DACH, UK und Nordamerika aus dem Jahr 2013 ergab, dass von 100% gescheiterten Projekten 70% aufgrund „unterschiedlicher Planungssichten“ scheiterten. Eine weitere Studie zeigt, dass bei Individual-Softwareprojekten ca. 65% der schwerwiegenden Fehler der Programme auf Fehler bei der Analyse zurückzuführen sind. Eine weitere Studie aus dem Jahr 2015 schlägt in die selbe Kerbe, denn laut dieser sind bei 40 – 50 % späterer Software Bugs die unzureichenden Requirements daran schuld. Wie kommt es dazu? Nach vielen Jahren lehrreicher, spannender, aber mitunter auch schmerzhafter Erfahrungen in der Individual Software Entwicklung habe ich für mich eine Antwort gefunden, die mich gleichzeitig mehr und mehr zur Agilität antreibt. Häufig wird ein Pflichtenheft und ein Lastenheft verfasst, dass zuerst mal in der Schublade landet. Sie werden erst wieder aus der Schublade geholt, wenn die Budgetierung fix ist. Dann aber muss alles sehr schnell gehen und es wird vom Ist-Stand dieser Dokumente mit Volldampf gestartet. Schätzungen die vielleicht drei Monate alt sind, werden als gültige Schätzungen übernommen und nicht adaptiert. Oder wenn adaptiert, dann mit einer Wahrscheinlichkeits-PERT. So wird eine scheinbare Planungssicherheit basierend auf scheinbarer Exaktheit produziert. Den Rest kennt wohl jeder in dieser Branche – die Fehlerkosten, Timlines explodieren und die Qualität kann spürbar abnehmen.

konus-der-ungewissheit
Konus der Ungewissheit, Schweiger, 2017

Der Konus der Ungewissheit sagt aus, dass wir in den ersten 30% eines SDLC zwar sehr wenig Infos haben, die Informationszunahme jedoch expotentiell ansteigt. Danach ist die Informationszunahme zwar weiterhin gegeben, jedoch nicht mehr derart markant und mündet leider häufig in den Scope Creep. So weit ich sehe, ist es trotz dieser Herausforderung in den ersten 30% des SDLC eine der wichtigsten Aufgaben des aBA, bestmögliche User Stories und Estimations zu liefern – allein um den Product Backlog für den Product Owner zu gewährleisten. Im weiteren SDLC ist es eine der wichtigsten Verantwortungen des aBA, die User Stories erst zum letztmöglichen Zeitpunkt genau für das Sprintplanning exakt und detailiert zu definieren. Meiner Erfahrung nach funktioniert das am besten ca. 2 Wochen vor jedem Sprintende. Die Logik dazu ist recht einfach: Es kann davon ausgegangen werden, dass nicht zu viele und vielleicht unnötige SRS (Software Requirements Specification) verfasst werden, weil Sie vielleicht sowieso erst zu einem späteren Zeitpunkt benötigt werden. Wird zum letztmöglichen Zeitpunkt detailliert spezifiziert, ist die Wahrscheinlichkeit, dass alle nötige Information vorhanden ist, am höchsten. Weiter bedeutet diese Art des Requirement Engineering, dass man die SRS in Echtzeit dann fertig stellt, wann sie tatsächlich benötigt werden. Hier wiederum ist die Wahrscheinlichkeit am höchsten, dass die End User alle Informationen abgegeben haben und sich die SRS nicht mehr grundlegend verändern. Weiter ist auch die Wahrscheinlichkeit, dass die User Storys unabhängig sind am höchsten.

 User Story Mapping

customer-journey
Customer Journey, Kobald Agile Expert & IT Projects, 2017
user-story-mapping
User Story Mapping Workshop, 2017
ba-prozess
Analyse Modell, Kobald Agile Expert & IT Projects, 2017

Natürlich ist die Aneinanderreihung der Studien-Ergebnisse nur heuristisch zu interpretieren. Jedenfalls zeigen die Studien im Zeitverlauf für mich, dass IT-Projekte an zwei wesentlichen Faktoren kränkeln. Erstens an ungenauen Anforderungen und zweitens an schlechten Schätzungen.  Für mich ist es im Laufe der Berufsjahre immer wichtiger geworden bestmögliche Schätzungen auf Basis von „klaren“ Anforderungen treffen zu können. Nur so kann tatsächlich Shelfware vermieden werden. Lange bevor die Agilität im deutschsprachigen Raum ein wichtiges Thema geworden ist, wurde beispielsweise in der A1 Telekom Austria, für die ich 7,5 Jahre in Fixanstellung arbeitete, der Business-Driven-Approach in aller Konsequenz verfolgt. Egal ob ich als IT-Projektleiter oder Business Analyst oder in Kombination von beidem in Softwareentwicklungs-Projekten arbeitete, es mussten immer gemeinsam mit den Business Domains die User-Journeys erarbeitet werden, um das Einsparungspotential in der nachfolgenden GAP-Analyse herauszuarbeiten, um darauf basierend die Requirements zu verfassen. Natürlich war das eine Heidenarbeit und ist es heute ja auch noch. Jene Features mit der entweder strategisch höchsten Priorität, oder dem höchsten Einsparungspotential wurden immer zuerst entwickelt. Der Unterschied zu heute ist, dass die agile Perspektive den Standpunkt der Minimum Viable Product Entwicklung vertritt. Der Business Value – und dafür ist der Business Analyst m. M. nach prioritär zuständig – definiert sich für mich aber nach wie vor entlang der Endanwender-Perspektive. Daher priorisiere ich gemeinsam mit dem Projektleiter und den Stakeholdern zuerst immer spezifische Business Rollen, Enduser und die strategischen Business Ziele für die Softwareentwicklung. Denn jede Software soll ein spezifisches Problem in einer oder mehrer Business Domain lösen. Der Outcome deckt  immer spezielle Features, Komponenten und Funktionalitäten für die Enduser ab. Ich bin ein Verfechter der Customer Journey und des User Story Mapping. Die Costumer Journey zeigt mir den E2E Prozess im Jetzt. In der kollaborativen Erarbeitung werden jene Delta User Storys erarbeitet, die dem Enduser in der E2E Betrachtung (See the whole picture!) den meisten Nutzen (realtime business value) bringen. Natürlich muss jedes Feature mit Zahlen belegt werden. Was verändert sich? Können durch die Änderung mehr Geschäftsfälle abgearbeitet werden? Werden manuelle Arbeitsschritte reduziert? Was unterscheidet unser Produkt vom Rest der Welt? Solche und ähnliche Fragen bringen zu Tage, ob eine Änderung tatsächlich Geschäftsnutzen bringt, oder ob es sich bei der Anforderung mehr um ein „gefühltes“ Problem handelt, dass mit Zahlen hinterlegt kaum etwas an Optimierung hergibt. Jeff Patton vertritt die Meinung, dass wir in der Softwareentwicklung immer dazu antreten die Welt zu verändern und dieser Anspruch allein zählt.

value-driven-approach
Value Driven Approach, Kobald Agile Expert & IT Projects, 2017

Da es wichtig ist, dass ich als Ihr agiler Business Analyst die Iterationen des Entwicklungsteams sowie den Product Backlog und Sprint Backlog mit Echtzeitanforderungen beliefere, können die Schätzungen nicht immer eine vollständige Informationsreife haben. Aber was heißt schon allumfassende INformationsreife. Das ist für mich recht eigentlich eine Illusion. Daher zählt das Prinzip der relativen Schätzungen. Hintergrund dazu ist, dass in der agilen Methode die User Stories, oder Szenarios, je nach dem mit welcher Methode entwickelt wird, zum letztmöglichen Zeitpunkt genau definiert und eingelastet werden. So steigt die Wahrscheinlichkeit der bestmöglichen Informationsreife. Gleichzeitig werden durch dieses Prinzip Leerläufe vermieden. Es wird davon ausgegangen, dass es wenig Sinn macht eine User Story nach der anderen fertigzustellen, da sich einerseits immer etwas ändert (kann). Andererseits die User Stories dadurch stärker am Enduser orientiert sind. In der Fachsprache spricht man hier von „Feature Injection“. Zugegebenermaßen ist das ein Punkt der mir mitunter viel Überzeugungsarbeit abverlangt. Besonders, wenn der agile Ansatz noch relativ neu im Denken der Stakeholder und Enduser ist.

Schätzung des Umfangs  

kano-analyse
Kano Analyse Modell, Kobald Agile Expert & IT Projects, 2017

Die Analyse der Ist-Situation immer der erste Schritt. Persönlich arbeite ich sehr gerne mit JAD Sessions und dem DAGσPERT Delphi-Schätzverfahren. Für die tiefgehende Einführung in die DAGσPERT Slim Methode bedanke ich mich an dieser Stelle bei Sven Schweiger von CSS. Erst dadurch ergibt sich die Möglichkeit den Geschäftsnutzen durch eine Softwareentwicklung herauszurechnen. Die für mich wichtigsten Methoden zur Schätzung in diesem Stadium eines Softwareprojekts sind die Delphi-Schätzung, die Kano-Analyse kombiniert mit MoSCoW-Erstpriorisierung und das T-Shirt Sizing (Ein Elefant ist größer als eine Maus.). Sehr spannend finde ich auch das Speedboat Gaming.  Es geht ja darum, eine erste Einschätzung darüber zu treffen wie groß eine User Story in etwa ist und weiter wie wichtig diese für uns ist. Das Function-Point-Measurement hat für mich aufgrund des User Centered Design ebenfalls starke Aussagekraft. Konzeptionell kann diese perfekt mit UML-Diagrammen (vgl. User vs. Actor verbunden werden. Allerdings ist für mich die Kano-Anayse kollaborativer und kann ohne viel Aufwand laufend verändert werden. Aber weder halte ich etwas von „Erfahrungsschätzungen“, Einzelschätzungen oder der Drei-Punkt-Schätzung (Three-Point-Estimation) mit Wahrscheinlichkeiten (PERT). Warum? Die PERT Schätzung ist ein prognostisches Verfahren, welches über Wahrscheinlichkeiten ein bestimmtes Maß an Sicherheit (risk reduction) zu berechnen versucht. Sie verleitet dazu, dass man Zahlen als Fixgröße kommuniziert. Aber in der agilen Umgebung werden keine scheinbar exakten Prognosedaten verlangt, sondern vielmehr empirische Daten aus den Sprints. Die PERT verleitet dazu, dass man eine einmal vorgenommene Schätzung als gegeben hinnimmt. Das ist ein No Way für die agile Entwicklung. Meiner Erfahrung nach sollten beim Schätzen auch gleich die Acceptance Criterias festgelegt werden. Bei Scrum etwa heißt die „Definition of Done“ fertig ist fertig! Es zählen nur 100% Fertigstellung. Diese Definitin heißt natürlich nur, dass das fertigestellte Softwarestück einsatzfähig ist. Erst die mit der Business Domaine festgelegten Akzeptanzkriterien erlauben das Deployment.

Der Business Analyst ist ein Amigo des Product Owner

purpose-alignment-modell
Purpose Alignment Model, Kobald Agile Expert & IT Projects, 2017

Eine der wichtigsten Aufgaben des Business Analysten ist es den Product Owner, Business Represantive oder den Projektleiter bei der Ordnung und Priorisierung des Product Backlog zu unterstützen. Die Beste Unterstützung im Vorfeld für den PO ist so simpel wie schwierig, nämlich so eindeutig und gut geschätzte User Stories zu liefern, wie zu dem Zeitpunkt möglich. Jeff Patton der Chef Requirements Engineer des Online Auftritts zur Obama Wahl war, spricht von den drei Amigos des Product Owner. Diese Sichtweise habe ich mir angeeignet. Um tatsächlich den Backlog priorisieren und mit diesem Vorschlag zum Customer gehen zu können, benötigt er Unterstützung eines Testers, eines Entwicklers und des Business Analysten. Die irgendwo mit Sticky Notes bestückte und aufgepinnte Kano Analyse kann der gemeinsame Bezugspunkt sein. Hilfreich ist auch das so genannte Purpose Alignment Modell. Dieses spannt sich über die Achsen „Erfolgskritisch“ und „Marktdifferenzierung“ auf. Je nach Softwareentwicklung können die Achsen angepasst werden.

 

IREB CPRE (Certified Professional for Requirements Engineering, Lizenz 1369)

ITIL v.3 (Lizenz 5558492.20481540)