Die SwissQ liebt und lebt Agilität. Wir helfen unseren Kunden, agile Prinzipien umzusetzen. Ich bin derzeit als agiler BA in einem agilen Grossprojekt tätig. In diesem Blog-Beitrag rapportiere ich, was ich eigentlich so tue und will damit aufzeigen, dass ein agiles Business Analyst auch in Zeiten von Mastern und Ownern weiterhin essentiell für den Projekterfolg ist.
Projektkontext - worum geht's eigentlich?
Mein aktueller Kunde beschäftigt knapp tausend Mitarbeitende (interne wie externe) in dessen Corporate IT. Die Anwendungslandschaft besteht aus einer unbekannten Grösse von diversen selbstentwickelten Host- oder JAVA- sowie ordnungsgemäss beschafften Standard-Anwendungen.
Das aktuelle Projekt ist bestrebt, ausgewählte Anwendungen zu sanieren oder mit Neuentwicklungen abzulösen. Knapp 90% aller zu sanierenden oder zu entwickelnden Anwendungen in unserem Projektumfang sind Individuallösungen. Das eigentliche Projektteam umfasst knapp vierzig Personen. Das Projekt dauert mehrere Jahre und ist in einem intensiven Projektprogramm untergeordnet.
Das Projekt ist in sechs Teams gekapselt, die gewisse Anwendungen verantworten. Mein Team schafft zentrale Webservices, welche die eigentlichen Backend-Systeme fürs Frontend anbinden. Dort bin ich also als agiler BA wirkend.
Also, los geht's!
07:08: Hilfe! Modell kompiliert nicht
Gestern abends musste ich auf den Zug rennen, um meinen Anschluss nicht zu gefährden. Ich hatte am ausführbaren Modell für die automatische Codegenerierung noch etwas geändert. Wirklich ein ganz kleine Änderung, denn wir hatten kurz vor Feierabend noch etwas diskutiert. Heute morgen wollte ich meine Änderung im Modell testen, indem ich Code generiere. Leider zickte der Codegenerator. Ich habe eine Assoziation ohne Rolle eingefügt. Anfängerfehler! Immerhin ist niemand blockiert, weil ich der erste im Büro bin.
08:45: Sequenzdiagramme für eine Abstimmung mit Frontend und Backend Architekten vorbereiten
Als agiler BA bin ich auch Übersetzer und Vermittler. Ich verknüpfe Frontend mit Backend, ich verbinde Business mit IT. Die Diskussionen lenke ich mit simplen Sequenzdiagrammen. Darin sind die einzelnen Aufrufe transparent. Die Zielgruppe sind die IT-Architekten der Frontend- und Backend-Anwendungen. Meine Sequenzdiagramme sollen inspirieren und Abhängigkeiten aufzeigen.
10:15: User Storys zusammen mit dem PO verfeinern
Vor dem Sprint ist nach dem Sprint oder umgekehrt? Zusammen mit dem PO versuche ich, die vorgeschlagenen User Storys des nächsten Sprints für unser Team zu verfeinern. Wir schneiden unsere User Storys mit folgendem Muster:
- Arbeitsschritte aufteilen
- Operationen bilden
- Geschäftsregeln variieren
- Datenoptionen einschränken
- Schnittstellen abgrenzen
Das Muster lehnt sich an der Empfehlung von agile for all, im Original nachlesbar auf der Seite https://www.humanizingwork.com/the-humanizing-work-guide-to-splitting-user-stories/
11:15: Standup!
Alle agilen Teams haben um dieselbe Zeit ihr Standup. Um 11:15 Uhr treffen sich alle Teams vor ihren Boards. Jeder berichtet, was er tat und was er noch tun wird und was ihn behindert. Manchmal ist's sehr technisch. Dort, wo ich nichts verstehe, frage ich nach dem offiziellen Standup rasch bilateral nach. Mir ist es wichtig, dass ich weiss, was mein Team tut - und natürlich umgekehrt.
Was ich bis jetzt tat:
- Anforderungen der Webservice-Konsumenten in Diskussion geschärft und direkt ins Modell eingearbeitet
- Nächste Iteration der Abstimmung mit Webservice-Konsumenten geplant und vorbereitet
- User Storys für den nächsten Sprint verfeinert
Was ich noch nun tun werde:
- Allfällige Änderungen durch Webservice-Konsumenten ins Modell einarbeiten
- SQL-Skripts für Datenbank-Änderungen vorbereiten
- Entwickler unterstützen bei der Implementierung, gewisse Details müssen just in time noch verfeinert, sprich ausspezifiziert werden
Was mich behindert:
- Derzeit nichts 🙂
11:23: SQL-Statements vorbereiten
Unser Team betreut auch zwei-drei Backend-Anwendungen. Wir machen also nicht nur Schnittstellen! Da die Entwickler gerade mit einer technischen Migration beschäftigt sind (Sprint-Ziel!), helfe ich rasch aus - so gut ich natürlich kann. Ich bereite einige SQL-Scripts vor. Damit entlaste ich den Entwickler. Denn wir sind ein Team und haben unsere Team-Ziele, an denen wir gemessen werden. Ich als agiler BA bin also nicht irgendwie privilegiert, sondern darf auch mitunter operativ werken.
13:51: Rückfragen vom Entwickler beantworten
Meine Entwicklungsfähigkeiten sind bekanntlich beschränkt. Aber mit dem Modellierungswerkzeug generiere ich für unsere Entwickler ziemlich rasch und problemlos einen Code-Rumpf. Der generierte Code ist jedoch nicht immer makellos. Der Entwickler will es genauer wissen. Ich als BA bin mir gewohnt, eine gewisse Unschärfe zuzulassen, um die Lösung nicht einzuschränken. Bei der ausführbaren Modellierung tolerieren Entwickler (wie auch der Codegenerator!) jedoch keine Unschärfe. Seine (berechtigten!) Rückfragen beantworte ich. Fehler meinerseits korrigiere ich sogleich.
14:34: SoapUI Tests durchführen
Sobald unsere Entwickler eine Version bereitgestellt haben, prüfe ich als erster das Ergebnis, um mir einen Eindruck zu verschaffen. Da wir hauptsächlich Schnittstellen produzieren, ist ein Servicetest-Tool zu empfehlen. Mein Kunde nutzt SoapUI. Ich verwende also SoapUI, um simple Abfragen durchführen zu können. Meine Tests sind oberflächlich, allerhöchstens Smoke-Tests (https://de.wikipedia.org/wiki/Smoke_testing). Wir beschäftigen in unserem Team auch einen eingebetteten Tester, der dann das Ergebnis "richtig" testet.
15:11: Schon wieder eine Modelländerung
Ich spezifiziere die Schnittstellen im Modell. Mein Modell erzeugt Code. Meine Modell-Kommentare dokumentieren den Code. Der Entwickler kann sich auf die Geschäftslogik fokussieren - das Definieren und Deklarieren schultere ich. Ich spezifiziere nur, was auch im Sprint umgesetzt wird. Langfristige Zielbilder skizziere ich bloss. Auf Vorrat spezifiziere ich grundsätzlich nicht. Anforderungen im klassischen Sinne beschreibe ich nicht - ich spezifiziere on demand. Damit spare ich mir den "Umweg" via Anforderungen.
Was ich im letzten Sprint spezifizierte, musste ich aufgrund einer neuen Erkenntnis im aktuellen Sprint komplett umbauen. Im Modell mit wiederverwendbaren Modellelementen konnte ich das rasch beheben. In agilen Projekten bin ich mir gewöhnt, das Produkt stets den aktuellsten Informationen gemäss zu formen. Ich orakle nicht, was 2016 mal sein könnte, sondern beschäftige mich, was in diesem Sprint zu liefern ist.
16:10: Traceability zum Business sicherstellen
Als agiler BA sichere ich die Kompatibilität zur Facharchitektur, also zu dem fachlichen Kontext und dessen Anforderungen. Ich prüfe, ob das, was wir bauen, das ist, was wir brauchen und wollen. Ich orientiere mich daher an unserem Fachmodell, das ich kontinuierlich weiterentwickle. Für Rückfragen und Vertiefungen habe ich einen Business-Zirkel installiert, wo ich meine Stakeholder regelmässig treffe und Entscheidungen abnehme. Ich wirke also zugleich als "eingebetteter Businessvertreter" im Team.
Was macht nun also ein agiler BA?
Anforderungen sind auch in agilen Projekten wichtig, allerdings ist der Zeitpunkt, wann Anforderungen erhoben und wie detailliert spezifiziert werden, viel wichtiger. Ein totales Abspezifizieren des gesamten Projektumfangs per Stichtag ist in agilen Teams weniger gefragt als in klassischen Wasserfall-Projekten. Stattdessen spezifiziert der agile BA das, was unmittelbar im Sprint implementiert wird. Die Form der Spezifikation ist dabei irrelevant, lauffähiger Code heiligt jedes Mittel. In diesem Beispiel werden Sequenzskizzen, Kontextdiagramme, Zustandsautomaten, Klassenmodelle modelliert, welche die Entwicklung beschleunigen und somit eine wesentlich höhere Lösungsdichte respektive -nähe haben als klassische, lösungsneutrale Anforderungssätze im Sinne, dass das System fähig sein muss, Zahlungen durchführen zu können.
Der agile BA kann auch als defacto on site customer Rückfragen des Teams rasch und unmittelbar klären. Hier übernimmt der agile BA operative PO-Aufgaben, denn in skalierten agilen Projekten sind die PO auf anderen Ebenen unterwegs, sprich amten zusätzliche Aufgaben und weniger klassisches PO-ing - und vernachlässigen mitunter die Team-Ebene. Er liefert auch immer als erster Feedback über die produzierten Ergebnisse und kann somit bereits vor dem eigentlichen Testen und vor der Abnahme gewisse Fehler entdecken.
Der agile BA ist also die Informations- und Kommunikationsschaltstelle, der als interner Dienstleister für das Team auftritt.
Die Ausprägungen eines agilen BA unterscheiden sich jedoch je nach individuellen Fähigkeiten und je nach Team respektive Projekt. Dieses Beispiel hier ist nicht repräsentativ, sondern eine Möglichkeit, wie ein agiler BA im Projektgeschäft ausgeprägt werden kann. Die agilen Business Analysten der SwissQ beweisen in verschiedenen agilen Projekten, dass es die richtige Mischung aus Erfahrung, Können und unterschiedliche Ausprägungen ihrer Einsatzprofile ist, die zum Erfolg führt.
SwissQ unterstützt sie in der Ausbildung ihrer agilen Business Analysten. Der Certified Agile Business Analysis Kurs, den mein Kollege Stephan hier bereits besprach, kann auf unserer Webseite gebucht werden.
Und nochmals alles 🙂
- Es gibt nicht den agilen BA, sondern einen je nach Fähigkeit, Erfahrung und Team
- Spezifikation bleibt wichtig, wichtiger ist der Zeitpunkt der Detaillierung
- Spezifikationen haben eine höhere Lösungsdichte und -nähe
- Der agile BA schultert operative PO-Aufgaben
- Der agile BA gehört zum (Entwicklungs-)Team und orientiert sich an deren Bedürfnissen
- SwissQ empfiehlt den Certified Agile Business Analysis Kurs 🙂