Am Anfang jeder erfolgreichen Initiative – ganz unabhängig von Thema und Umfang – steht eine Bestandsaufnahme bezüglich Ist und Soll. Im Zusammenhang mit Prozessen wie agiler BI ist das üblicherweise eine Feststellung des Reifegrades, um einerseits realistische Aussagen über die Zielsetzungen und den damit verbunden Aufwand sowie Zeitrahmen machen zu können, andererseits aber auch, um eine gewisse Betriebsblindheit durch einen fundierten Blick von außen zu ersetzen. Geprüfte Modelle und externe Unterstützung sind ausreichend vorhanden, innerhalb eines Quartals lässt sich durch dieses Assessment sehr gut feststellen, welchen Reifegrad die eigene Organisation im Hinblick auf agile BI aufweist. Dabei ist es naturgemäß vorteilhaft, wenn diese Organisation bereits in anderen Bereichen agile Methoden einsetzt, aber das ist heutzutage zumindest im Bereich der Softwareentwicklung ohnehin meistens der Fall.

Ein Vorteil der externen Unterstützung für diesen Schritt ist die Tatsache, dass der wahre Reifegrad einer Organisation meist niedriger ist als es die internen Stakeholder subjektiv einschätzen oder vielleicht auch gerne herbeiwünschen würden. Sofern diese Bewertung ausnahmslos intern durchgeführt wird, besteht durchaus die Gefahr, die Situation durch eine rosarote Brille zu betrachten.

Entweder im Rahmen des Assessments oder unmittelbar darauf sollte für die gesamte Organisation oder den Teilbereich, der für die BI-Initiative definiert wurde, eine Ermittlung aller Themenblöcke – sog. Scope Items - folgen, die Anforderungen an BI, Data Warehousing oder Analytics haben. Diese Anforderungen werden dann nach Beitrag zum Unternehmenserfolg (diese Bewertung muss zwingend mit dem Senior Management der Organisation ermittelt werden), Aufwand und Machbarkeit bewertet sowie deren logische und technische Abhängigkeiten ermittelt.

Puristen könnten hier den Einspruch erheben, dass diese Aufwandsschätzung bei agilem Vorgehen an dieser Stelle nicht machbar ist, aber von erfahrenen Programm-Managern im Bereich BI kann durchaus erwartet werden, dass eine Einordnung in Größenordnungen auch mit minimaler Information erfolgen kann. Eine beliebte Methode an dieser Stelle ist das sogenannte T-Shirt-Sizing, bei dem Scope Items – entweder ausnahmslos basierend auf Erfahrungswerten oder anhand einiger Schlüsselparameter wie Anzahl der Quellsysteme, Wissen über deren Technologie usw. – in eine Skala von XS bis XL eingeordnet werden.

Das Endergebnis dieser Analyse ist eine sogenannte Performance Priority Plot Map. Nun kann die eigentliche Entwicklungsarbeit auf Basis von agilen Vorgehensmodellen wie SCRUM beginnen – nun ja, fast.

Beginnen wir nun, uns die Gemeinsamkeiten und die Unterschiede zwischen dem aus der Softwareentwicklung bekannten SCRUM und der Anwendung im Bereich Business Intelligence in Bezug auf die Rollen etwas näher anzusehen. Eine ganz zentrale Rolle hat bei SCRUM immer der Product Owner, dies gilt auch bei Agiler BI ohne jede Einschränkung. Dementsprechend muss diese Rolle von Anfang an, idealerweise bereits bei der Erstellung der zuvor beschriebenen Performance Priority Plot Matrix, passend besetzt sein – was für diese Rolle bedeutet, dass die folgenden Voraussetzungen erfüllt sein sollten: Domain Knowledge, ausreichende Verfügbarkeit (um auftretende Fragen zumindest am gleichen Tag beantworten zu können), Entscheidungsbefugnis und – man darf sich ja zuweilen auch etwas wünschen – Kenntnisse über DWH und BI.

Um sicherzustellen, dass ein DWH mittel- und langfristig erfolgreich implementiert und gewartet werden kann, ist fundiertes Wissen über die entsprechende Architektur notwendig. Dies beinhaltet die Modellierung von logischen und physischen Schemas (beispielweise Star Schema nach Kimball), Verständnis für komplexe Umgebungen, die in mehreren Layern aufgebaut werden, korrekte Historisierung und vieles mehr. Die Rolle des sogenannten Data Architects kann hinsichtlich der dafür notwendigen Zeit durchaus auf mehr als ein Team aufgeteilt werden, da MitarbeiterInnen mit diesen Erfahrungen üblicherweise nicht scharenweise in den Unternehmen herumlaufen. Manchmal findet man die geeignete Besetzung intern auch gar nicht, daher wird diese Rolle überdurchschnittlich oft extern besetzt.

Eine Ebene tiefer in der Analyse spielt die Rolle des sogenannten Functional Analyst. Hier geht es um das detaillierte Verständnis eines End-to-End-Datenflusses von der oder den Quellen bis zum Ziel. Für diese Rolle braucht es eine gesunde Mischung zwischen Big Picture und Details auf Attribut- oder Metrik-ebene, weiters Domain Knowledge und zumindest ein gewisses Grundverständnis über das Datenmodell und die Inhalte der Quellen.

Gegenparts für diese Rolle, die üblicherweise nicht als ständiger Teil des SCRUM Teams mitarbeiten, aber dennoch enorm wichtig sind für das Funktionieren von Agiler BI, sind Experten hinsichtlich der Quellsysteme, sogenannte Source System Specialists, sowie Experten für die Besonderheiten der Geschäftsbereiche und Prozesse aus der nicht-technischen Sicht, sogenannte Subject Matter Experts.

Last, but not least – Entwickler und Tester sollten im Team auch nicht fehlen, damit die ganze Arbeit der oben genannten Rollen auch während der Iterationen in entsprechende Umsetzung mündet. Beide Rollen sind bewusst in einem Atemzug genannt, da es nur ganz selten eine ausgesprochene Rolle zur Qualitätssicherung gibt, sondern häufig Testtätigkeiten von der Erstellung der Testfälle bis zur Durchführung der Tests von Teammitgliedern durchgeführt werden, die ursprünglich nur als Entwickler vorgesehen waren.

Die Auflistung dieser vielen, bezüglich Aufgabengebiet, Persönlichkeit und Erfahrung ungemein unterschiedlichen Rollen innerhalb eines SCRUM Teams zeigt schon, dass es bei Agiler BI viel mehr als bei klassischer Softwareentwicklung notwendig ist, auf diese Unterschiede im Team Rücksicht zu nehmen, da man einfach nicht davon ausgehen darf, dass jedes Teammitglied bei freier Kapazität jede Story und jeden Task umsetzen kann.

Diese Herausforderung obliegt auch bei Agiler BI der Rolle des SCRUM Masters, der dafür zu sorgen hat, dass der gesamte Prozess so effizient wie möglich abläuft und bei erkannten Schwachstellen im Prozess oder bei den verfügbaren Ressourcen gemeinsam mit dem Programm-Management nach Lösungen suchen muss.

Gerade in den ersten Monaten nach der Einführung von Agiler BI in einer Organisation werden laufend Situationen auftauchen, mit denen die Teammitglieder und auch das Programm-Management zum ersten Mal konfrontiert werden. Auch wenn man es geschafft haben sollte, die Initiative auch ohne externe Ressourcen im Tagesgeschäft mit ausreichenden Kapazitäten auszustatten, ist es in diesen Momenten unheimlich hilfreich, wenn man erfahrene Experten konsultieren kann, die auf viele dieser Fragen aufgrund der Erfahrungswerte schon eine Antwort parat haben. Um so besser, wenn diese Experten das Unternehmen schon kennen, zum Beispiel, da sie das Assessments bezüglich des Reifegrads durchgeführt haben. Dieses Unterstützung kann anlassbezogen, aber auch planmäßig in Form von Reviews, beispielsweise jeweils nach einer definierten Anzahl von Sprints, durchgeführt werden.

Wie lange soll eine Iteration sein?

Eine sehr konkrete, persönliche Erfahrung im Bezug auf die Effizienz von Agiler BI ist die Länge des Sprints. Klassische Softwareentwicklung arbeitet meist auf Basis von Iterationen, die 2 Wochen dauern. Dies hat sich aus 2 Gründen als zu kurz herausgestellt: bei effektiv 8 Entwicklungstagen ist es nur selten möglich, eine komplexe Datenintegration soweit fertigzustellen, dass man dem Product Owner eine sinnvolle Möglichkeit für einen User Acceptance Test bieten kann – schon gar nicht inklusive Reporting Layer. Weiters ist der für Grooming und Planning notwendige Overhead aufgrund der zuvor beschriebenen Komplexität mit verschiedensten Rollen, nahezu ständig auftretenden Architektur- und Modellierungsfragen usw. im Verhältnis zum Output zu hoch, da nach eigener Erfahrung ein gewisser Mindestaufwand für diese Themen ziemlich konstant ist, unabhängig von der Länge des Sprints und der demzufolge diskutieren Stories.

Konsequenz aus dieser Erfahrung über mehrere Monate war die Änderung der Sprint-Dauer auf 3 Wochen mit dem gleichzeitigen Anspruch, spätestens nach 3 Sprints, also etwa 2 Monaten, ein Release in Produktion verfügbar zu machen. Dies wiederum erzeugt eine Releasegröße, die technisch und bezüglich der Abhängigkeiten noch beherrschbar ist, und minimiert gleichzeitig wiederum den Overhead, der in jedem Fall pro Release auftritt – auch bei weitaus häufigerer Durchführung von Integrationstests.

Am Anfang der Entwicklung gibt es noch eine besondere Situation, die eine noch einmal verlängerte Iteration erfordert. Grundprinzipien hinsichtlich Architektur, Verständnis für die inhaltliche Bedeutung der verschiedenen Epics, Fragen bezüglich Infrastruktur usw. benötigen besondere Aufmerksamkeit und sind so wichtig, dass man sie in einer speziellen Iteration – auch gerne Sprint 0 genannt – zusammenfassen sollte. Diese Iteration kann ohne Weiteres 4 – 6 Wochen dauern, die Länge hängt von der Gesamtkomplexität des BI-Programms ab. 

Lieber Product Owner - Testen Sie selbst!

Apropos Testen – für agile Entwicklung gibt es mehrere Komponenten, die dem ganzen Vorhaben einen enormen Schub verleihen können. Zuallererst muss dem Product Owner eine Umgebung zur Verfügung gestellt werden, die einen vernünftigen Abnahmetest, sogenannte User Acceptance Tests, ermöglicht. Das gilt ganz genauso für Agile BI – dementsprechend ist es keine gute Idee, hier zu sparen. Bezüglich Inhalte, Aktualität und Performance sollte sich diese Umgebung möglichst wenig, idealerweise gar nicht, von der Produktion unterscheiden – dadurch verringert sich die Anzahl der Fehler oder Probleme, die man erst in Produktion findet, ganz massiv. Weiters fällt es dadurch garantiert leichter, einen hochqualifizierten Product Owner für das Vorhaben zu gewinnen, wenn sich dieser nicht mit einer Auswahl von 10.000 aus 50 Mio. Datensätzen zufrieden geben muss oder die Abfrage auf Basis von 50 Mio Datensätzen mehrere Stunden dauert.

Der vorher bereits angesprochene Integrationstest, bei dem mehrere Komponenten dahingehend überprüft werden, ob sie auch miteinander und nicht nur nebeneinander funktionieren, wird umso wichtiger, je größer das Team ist oder je mehr Teams an überlappenden Funktionalitäten, beispielsweise dem gleichen Data Mart, arbeiten. In fortgeschrittenen Umgebungen wird dieser Vorgang teilweise oder vollständig automatisiert (Continous Integration) und mit zyklischen, geskripteten Testfällen zusätzlich verifiziert (Regressionstest). In der klassischen Softwareentwicklung trifft man diesen Automatisierungsgrad immer häufiger an, für Agile BI ist das aufgrund der noch einmal höheren Komplexität tatsächlich ein sehr schwer erreichbarer Zustand.

Die Welt ist nicht genug – Agile BI mit verteilten Teams

Eines vorweg – die effizienteste Organisation für Agile BI bedeutet, alle Personen, die eine oder mehrere der genannten Rollen wahrnehmen, in einen Raum zu setzen. Dieses offensichtliche Idealbild ist leider in internationalen Unternehmen, die vielleicht auch noch Outsourcing-Partner in anderen Ländern oder auf anderen Kontinenten haben, nicht umsetzbar. In diesem Fall muss man sich bewusst sein, dass man bei verteilten Teams mit einer um 25 Prozent geringeren Effizienz rechnen muss [1]. Dennoch gibt es einige konkrete Maßnahmen, die diese Teams bei ihrer Arbeit unterstützen können. Zuallererst ist wenigstens am Beginn der Entwicklung dafür zu sorgen, dass sich alle Teammitglieder zumindest einmal persönlich kennenlernen können. Der zuvor erwähnte Sprint 0, bei dem für vieles die Basis gelegt wird, eignet sich dafür hervorragend, aber auch anschließend ist die soziale Komponente nicht zu unterschätzen und beispielsweise nach besonders wichtigen, erfolgreich umgesetzten Releases helfen Teambuilding-Maßnahmen, und wenn es nur ein gemeinsames Abendessen ist, ungemein.

Die tägliche Arbeit in einem verteilten Team kann heutzutage durch diverse technische Hilfsmittel massiv erleichtert werden. Durch Videokonferenzsysteme, sowohl auf den einzelnen Arbeitsplätzen als auch in Besprechungsräumen in allen beteiligten Lokationen, erreicht man zumindest annähernd die Qualität eines persönlichen Gesprächs. Frust bei den Teammitgliedern kann man vermeiden, wenn diese Systeme sowohl von der Qualität als auch von der Verfügbarkeit auf sehr hohem Niveau implementiert und betreut werden, ansonsten kann es leicht passieren, dass das Zustandekommen der Videokonferenz für das tägliche Stand-Up länger dauert als das Stand-up selbst.

Der soziale Aspekt

Große Erwartungen werden erzeugt, wenn man einen relativ neuen, vielversprechenden Entwicklungsprozess zum ersten Mal für das Thema Business Intelligence in einer Organisation einsetzt. Diese Erwartungen bedeuten für das ganze Team einen besonderen Druck, denn Agile BI bedeutet eine vielleicht nie gekannte Nähe zwischen Entwicklung und Business in Gestalt des Product Owners. Diese Nähe birgt auch nicht zu unterschätzendes Konfliktpotential, denn es prallen plötzlich Rollen und Persönlichkeiten aufeinander, die sich vorher vielleicht nur – eher irrtümlich – bei der Weihnachtsfeier getroffen haben. An mehreren aufeinanderfolgenden Tagen direkte Kritik wegen deutlicher Verzögerung bei der Implementierung einer komplexen Story einstecken zu müssen, wird erfahrenen Entwicklern nicht leichtfallen. Umgekehrt hat es der Product Owner vielleicht seit Tagen nicht geschafft, eine Frage bezüglich der korrekten Definition einer Metrik für die Entwicklung zufriedenstellend zu beantworten.

Für einen erfahrenen SCRUM Master wird das nicht überraschend kommen, aber auch von Seiten des Programmmanagements kann man erwarten, sich mit dieser Situation auseinanderzusetzen und bei ersten Anzeichen von persönlichen Problemen proaktiv entgegenzuwirken, gerade am Anfang eines Programms, wenn die Teammitglieder noch nicht aufeinander eingespielt sind. Innerhalb der agilen Entwicklung gibt es eine spezielle Einrichtung für derartige Themen, die sogenannte Retrospektive nach jedem Sprint. Je nach persönlicher Einschätzung und Unternehmenskultur kann man auch als Programmmanager von Zeit zu Zeit an dieser Retrospektive teilnehmen, obwohl es üblicherweise eine Einrichtung für das SCRUM Team ist.

Die Top 5 Erkenntnisse – worauf man nicht verzichten darf

Was sind nun die wichtigsten Voraussetzungen für ein erfolgreiches, agiles BI-Programm? Es gibt ganz sicher weit mehr als fünf Bausteine und auch deren Reihung ist subjektiv – nichtsdestotrotz hier meine persönlichen Top 5: