In meinem letzten Blogbeitrag bin ich auf verschiedene Bausteine eingegangen, um Agile Business Intelligence in einer Organisation zu etablieren und zu verankern. In diesem Artikel möchte ich nun einen Aspekt aus dem Bereich „Agile Denkweise & Organisation“ aufgreifen. Es geht um die Frage, welchen Entwicklungsansatz man wählen soll, um insbesondere ein DWH (und nicht nur das BI Frontend) agil zu entwickeln. Eng damit verbunden ist die Frage nach der Schneidung von User Stories in diesem Umfeld. Ist es wirklich sinnvoll, eine User Story stets „end-to-end“ auszuprägen, d.h. von der Anbindung des Quellsystems über Staging Area, Core DWH etc. bis hinauf zum Informationsprodukt (z.B. ein Dashboard) zu schneiden? Wie Sie sich denken können, ist die oberflächliche Antwort erst einmal „es kommt drauf an“.
Form der Entwicklungsorganisation
Wenn wir uns die geschilderte Fragestellung aber mal genauer ansehen, lassen sich verschiedene Faktoren identifizieren, welche etwas mehr Licht ins Dunkel bringen. Zuerst möchte ich folgende Fallunterscheidung zur Entwicklungsorganisation machen:
- Organisationsform A) DWH und BI Frontend werden als eine Applikation betrachtet und vom gleichen Team entwickelt.
- Organisationsform B) DWH und BI Frontend werden als zwei separate Applikationen (durchaus mit enger Abstimmung untereinander) betrachtet und durch unterschiedliche Teams entwickelt.
Ausprägungen der Organisationskultur
Als nächstes wollen wir zwei mögliche Ausprägungen von Organisationskulturen unterscheiden, welche vom Begriff her dem Buch „IT Manager, gefangen in Mediokristan“ von Michael Bischoff entnommen sind (eine gute Rezension zum Buch finden Sie übrigens in diesem Blogbeitrag)
- Mediokristan: Das „Land“ Mediokristan wird als träges Umfeld beschrieben, indem Hierarchien und Rahmenbedingungen vorgegeben sind, Risiko- und Managementkonzepte dominieren. Es ist ein Sinnbild für die Erfahrung, welche ich persönlich immer wieder im Kontext von grossen Corporate IT Organisationen mache. Alles bewegt sich eher langsam, die Durchlaufzeiten sind tendenziell hoch, das Mass aller Dinge ist das Mittelmass.
- Extremistan: Das „Land“ Extremistan kann man am besten als Gegensatz zu Mediokristan beschreiben. Neue, innovative Lösungen werden frisch von der Leber weg entwickelt, es herrscht eine Atmosphäre des Aufbruchs, der Selbstverantwortung und -organisation. Was sich bewährt, wird weitergetrieben, was sich nicht bewährt, wird wieder aufgegeben. Man strebt nach dem Extrem: extrem gut, extrem flexibel, keine Rücksichte auf Verluste. Vorgaben, welche die persönliche Innovationslust behindern, werden genauso extrem abgelehnt.
Die beiden Kulturformen beschreiben wohlverstanden zwei Extrempositionen. Dazwischen liegt ein Kontinuum von möglichen weiteren Ausprägungen.
Alternativen für agile Entwicklungsansätze
Die dritte Fallunterscheidung möchte ich machen in Bezug auf die Alternativen für agile Entwicklungsansätze im DWH-Umfeld:
- Entwicklungsansatz A) Single Iteration Approach (SIA): Beim SIA werden zu Beginn einer Iteration (Sprint im Scrum-Jargon) eine bestimmte Anzahl User Stories ausgewählt mit dem Ziel, am Ende einer Iteration ein potenziell produktiv nutzbares Resultat zu erhalten. Bei der obigen Organisationsform A würde die User Story also alle Aspekte umfassen, die man „end to end“ benötigt: Anbinden des benötigten Quellsystems (falls nicht schon vorhanden), Datenmodellierung, Laden der Daten in den Staging Layer, EDWH und Datamart Layer bis hin zu einem nutzbaren Informationsprodukt. Ebenso gehört zur Bearbeitung der User Story das Entwickeln und Ausführen von Tests, das Schreiben einer angemessenen Dokumentation etc. Dieser Ansatz ist sehr anspruchsvoll und setzt in der Regel ein Team von T-Skilled People voraus, d.h. ein Teammitglied kann im Laufe der Zeit sämtliche anstehenden Aufgaben übernehmen.
- Entwicklungsansatz B) Pipelined Delivery Approach (PDA): Der PDA geht davon aus, dass in vielen Fällen die Anwendung des SIA illusorisch ist. Ein Grund dafür kann sein, dass häufig nach wie vor primär Spezialisten (und nicht T-Skilled People) zur Verfügung stehen, oder im Extremfall sogar mehrere Teams in den Entwicklungsprozess involviert sind (z.B. separate Teams von Business Analysten oder Tester). Ein zweiter Grund ist die schiere Komplexität, welche in DWH-Lösungen häufig zu beobachten ist. Eine einzige zwei- bis vierwöchige Iteration kann da schon sehr sportlich sein, vor allem wenn man sich – im übertragenen Sinne – im Land Mediokristan (vgl. oben) aufhält.
Als Alternative wird im PDA die Erstellung einer DWH-/BI-Lösung im Sinne einer Produktionsstrasse beschrieben (vgl. dazu auch das Buch von Ralph Hughes : Agile Data Warehousing Project Management: Business Intelligence Systems Using Scrum, Morgan Kaufmann, 2012). Die Produktionsstrasse (= Pipeline) besteht in der Regel aus drei Arbeitsstationen: 1. Analyse & Design, 2. Entwicklung, 3. Testing. Eine User Story durchläuft dabei jede Arbeitsstation in maximal einer Iteration. Im Idealfall wird die gesamte Produktionsstrasse durch ein und dasselbe Team betrieben, wovon wir im Folgenden ausgehen wollen:- Zu Beginn des Produktionszyklus (z.B. ein DWH-Projekt) werden an einer regulären Story Conference diejenigen User Stories priorisiert und bestimmt, welche als erstes in Angriff genommen werden sollen. Diese werden sodann in der ersten Arbeitsstation Analyse & Design bearbeitet. Nun ist offensichtlich, dass in dieser Startphase die Produktionsstrasse und damit vielleicht auch das eine oder andere Teammitglied noch nicht voll ausgelastet ist. Diese Lücken können jedoch ideal im Sinne der Inception Phase nach Disciplined Agile genutzt werden.
- Nach der ersten Iteration werden einerseits in der Story Conference die nächsten User Stories für die Bearbeitung bestimmt und an die erste Arbeitsstation weitergegeben. Gleichzeitig wandern die Arbeitsergebnisse aus der ersten Iteration weiter zur nächsten Arbeitsstation, nämlich der eigentlichen Entwicklung.
- Nach der zweiten Iteration werden erneut User Stories vom Backlog für die Bearbeitung priorisiert. Gleichzeitig bewegen sich alle Stories, welche sich bereits in der Produktionsstrasse befinden, eine Station weiter. Die User Stories der ersten Iteration kommen nun also zur dritten Arbeitsstation Testing.
- Nach der dritten Iteration stehen in der Folge das erste Mal vollständig umgesetzte, „production ready“-Lösungen zur Verfügung. Ist die Produktionsstrasse erst einmal gefüllt, werden – analog dem SIA – nach jeder Iteration neue funktionsfähige Inkremente der DWH-Lösung geliefert.
Ein wesentlicher Unterschied zwischen SIA und PDA ist, dass die Gesamtdurchlaufzeit einer User Story von Story Conference bis zur fertigen Lösung im SIA tendenziell kürzer ist als im PDA. Beiden Ansätzen gemeinsam ist die Empfehlung zur Schneidung der User Stories: Diese sind immer vertikal zu den Architekturschichten, d.h. end-to-end von der Anbindung eines Quellsystems bis hin zum fertigen Report (vgl. Organisationsform A oben) oder mindestens zum Reportinglayer im DWH (vgl. Organisationsform B oben).Während auch der PDA sämtliche agile Werte und Grundprinzipien beherzigt (mehr dazu in einem späteren Artikel), so ist der SIA im Zweifelsfalle flexibler. Die tatsächliche Umsetzung im SIA ist aber auch wesentlich anspruchsvoller und die Verlockung gross, dass User Stories plötzlich nicht mehr end-to-end sondern pro Architekturlayer definiert werden (z.B. „Analysestory“, „Staging-Story“,“Datamart-Story“, „Test-Story“).
Wann eignet sich welcher Entwicklungsansatz?
Im Rahmen dieses Artikels möchte ich zum Schluss noch einige der obigen Aspekte in Beziehung zueinander setzen.
Werfen wir einen Blick auf die „Organisationsform A) DWH und BI Frontend werden als eine Applikation betrachtet“. Befindet sich das Projektteam in Extremistan und besteht das Team primär aus T-Skilled People, stehen die Chancen gut, dass man auch eine DWH/BI-Gesamtlösung end-to-end mit dem SIA umsetzen kann. Kritisch sehe ich den SIA-Prozess, wenn sich das Team schwergewichtig in Mediokristan befindet. Organisationsinterne Abklärungen und Abhängigkeiten erfordern häufig Mehraufwand in Bezug auf Analyse und Design. Gleichzeitig müssen Governancevorgaben und juristische Aspekte berücksichtigt werden. Dies sind alles Faktoren, weswegen ich dem PDA in Mediokristan grundsätzlich grössere Erfolgschancen einräume als dem SIA. Oder positiv formuliert: Ja, auch in Mediokristan lässt sich agil arbeiten…
Ein in meiner Erfahrung häufig gesehener Umstand ist die „Organisationsform B) DWH und BI Frontend werden als zwei separate Applikationen betrachtet“. Grundsätzlich kann man sagen, die agile Entwicklung mit dem SIA fällt im BI Frontend wesentlich leichter als im DWH Backend, hängt letztlich aber auch wieder stark von der Umgebung (Stichwort Mediokristan vs. Extremistan) ab. Denkbar ist auch die Kombination der beiden Ansätze (PDA für das DWH Backend, SIA im BI Frontend), vor allem wenn das BI Frontend bereits auf ein bestehendes DWH aufsetzt und nicht für jede User Story im Frontend auch eine Anpassung am DWH nötig ist. Interessant bei Organisationsform B) ist auch die Frage nach der Schneidung der User Story im DWH Backend. Wie soll eine User Story formuliert werden, wenn gar kein konkreter User verfügbar ist und das DWH mehr im Sinne einer „Informationsgrundversorgung“ entwickelt wird? Ein interessanter Ansatz ist hier der Feature Driven Development (FDD) Ansatz, welcher u.a. im Blogartikel von Agile-Urgestein Mike Cohn beschrieben wird. Die Adaption von FDD auf die DWH-Entwicklung bietet ebenfalls Potenzial für einen weiteren Aritkel meinerseits…
Sie sehen, so falsch war die eingangs erwähnte Antwort „es kommt drauf an“ also nicht. Als unser Kunde lassen wir Sie damit aber nicht einfach im Stich. In unserer Beratungspraxis versuchen wir zusammen mit Ihnen, aus dem reichen Fundus verschiedener agiler Ansätze situationsgerecht den richtigen zu bestimmen. Gerne können Sie mich für Rückfragen auch persönlich anschreiben oder verfassen Sie unten einen Kommentar. Ich freue mich auf Ihre Rückmeldung.