Business Intelligence nach dem Scrum-Prinzip

Scrum in der Praxis: Agile Entwicklung im Business-Intelligence-Umfeld

Philipp Lenz

Agilität ist in aller Munde – viele Organisationen und deren Teams nutzen Scrum in jeder Geschäftsebene. Egal ob im Management oder in der Entwicklung, dieses Rahmenwerk kann effizient eingesetzt werden. Software-Entwicklungsteams verwenden Scrum meist sehr erfolgreich – sie verbessern damit die Geschwindigkeit und steigern die Qualität in der Entwicklung oder können Produkte besser instand halten. In Business-Intelligence(BI)-Teams ist es jedoch eher selten zu sehen. Dieser Artikel gibt einen Einblick in die richtige Anwendung des Rahmenwerks Scrum, damit Scrum in der Business-Intelligence-Entwicklung wirksam unterstützen kann.

Und wenn doch, nennt man es meistens Scrum, selbst wenn es selten etwas damit gemeinsam hat. Dies liegt häufig daran, dass die Teams zu klein sind und der Aufwand für die Besetzung der jeweiligen Rollen aus Kosten- sowie Kapazitätsgründen gescheut wird. Aus technischer Sicht ist ein häufig genannter Grund, dass sich viele Tätigkeiten nicht effizient parallelisieren lassen. Das wiederum erklärt in zahlreichen Kontexten die geringe Teamgröße, durch die der ursprünglich intendierte agile Ansatz dann doch in „getarnten“ Wasserfallprinzipien endet.

Scrum? Agile? – bitte was?!

Leider ist sehr häufig zu beobachten, dass das Rahmenwerk Scrum zwar namentlich bekannt ist und danach mutmaßlich gearbeitet wird, aber es dennoch in der Anwendung scheitert, da häufig zu wenig Erfahrung darin besteht oder nur die Begrifflichkeit „Agil“ einen Manager „verführt“ hat. Das Rahmenwerk wird ebensooft fälschlicherweise als Prozess oder Technik missverstanden. Denn einer der Merksätze bei Scrum ist: „Es ist einfach zu verstehen, jedoch schwierig zu meistern.“

Scrum als solches ist keine Neuerfindung, obwohl es von vielen als neu wahrgenommen wird. Bereits in den 1990ern wurde das Rahmenwerk Scrum, welches durch Ken Schwaber und Jeff Sutherland entwickelt wurde, eingesetzt. Scrum nutzt einen Ansatz, um inkrementell sowie iterativ die Optimierung in der Planbarkeit sowie eine Kontrolle der Risiken herbeizuführen, um die Entwicklung und Erhaltung komplexer Software zu ermöglichen. Und richtig eingesetzt, kann dies auch zum Erfolg führen. Unter anderem ist es immens wichtig, dass das Management einer Organisation ebenso darüber Bescheid weiß, wie ein direkt Beteiligter und diesen auch so unterstützt.

Rollen, die immer in Scrum genutzt und ausgefüllt werden müssen

Scrum als Rahmenwerk beschreibt in erster Linie Events (siehe Abbildung 1) und Rollen. Zu den Rollen gehören der Product Owner, der Scrum Master sowie das Entwicklungsteam.

Abbildung 1: Scrum-Rollen und Events (eigene Darstellung)

Auch wenn die Stakeholder keine feste Rolle in Scrum haben, sollten diese weder übersehen noch als Rolle ausgespart werden. Diese Personen sollten in BI-Entwicklungsprojekten immer gut ausgewählt und identifiziert werden. Denn in der Regel haben nicht nur die Führungsebenen Interesse an der Lösung, um analytische Prozesse zu unterstützen. Es gehören auch die Betreiber zu den Vorsystemen, die Datenbank-Administratoren sowie die Datenschützer zu den wichtigen Personen, die immer vom jeweiligen Product Owner mit eingebunden werden sollten. Dieser wird häufig in BI-Projekten aus der „Technischen Ecke“ besetzt. Hier ist aber dringend empfohlen, die Person aus der Fachabteilung in diese Rolle zu heben. Denn gerade BI-Projekte dienen primär der Beantwortung fachlicher Fragestellungen und der Management Unterstützung – diese Fragen können meist am besten aus der Fachabteilung gestellt werden. Ebenso liegt die Bedienung des Werkzeugs in der Hand dieser Abteilung. Sie kennt in der Regel die Regularien sowie Rahmenbedingungen, die jemand aus dem technischen Bereich meist nicht kennen kann. Dies bringt in der Regel ein großes Hindernis mit sich – die Verfügbarkeit. Ein Product Owner sollte demnach dem Entwicklungsteam zu 100 Prozent zur Verfügung stehen, um fachliche Fragestelllungen, wie beispielsweise Filterungen in Kennzahlen oder Einblicke in die Datenqualität zu bringen. Dies funktioniert aber in der Regel nicht vollumfänglich, denn was hat jemand aus einer Fachabteilung für ein technisches Projekt nie übrig? – Zeit. Demnach sollte dies intern gut diskutiert und abgewogen werden, bevor man überstürzt in ein agiles Projekt startet.

Der Scrum Master, der häufig viel mit der Organisation und der Durchführung der Events und der Organisation von Scrum beschäftigt ist, kann jedoch hervorragend als technischer Coach mit fungieren. Er kann entsprechend weniger entwicklungserfahrenen Teams zur Seite stehen und bei Fragestellungen in der Architektur und Implementierung beraten. Dies wird häufig von der Kostenstelle legitimiert, die meist fälschlicherweise als Overhead betrachtet wird. Ebenso ist es eine Aufgabe dieser Rolle, den Product Owner zu unterstützen. Da dieser hier aus dem fachlichen Bereich entstammen sollte, kann er ebenso bei der „Übersetzung“ sowie Formulierung von User Stories für das Entwicklungsteam unterstützen.

Auch die Größe des Entwicklungsteams sollte gut bedacht werden. Rein von der Lehre des Scrum Guides ausgehend wird hier eine Größe von mindestens drei Personen und ein Maximum von neun Personen vorgegeben. Dies trifft hervorragend bei einer reinen Software-Entwicklung zu, wie zum Beispiel bei CRM-Systemen. BI-Projekte haben jedoch häufig einen limitierenden Faktor: die Parallelisierung. Bevor die erste Kennzahl für den Fachbereich aus einem Analysewürfel purzelt, ist viel Grundlagenarbeit zu leisten. Unter Umständen ist erst ein Data-Warehouse zu entwickeln, dann die ETL-Strecken in den Data Mart, anschließend der OLAP Cube zur Bereitstellung und Berechnung der Kennzahlen sowie der Geschäftslogik und das anschließende Berichtswesen.

Wenn man beispielsweise die Microsoft-Business-Intelligence-Entwicklungswerkzeuge als Grundlage nimmt, sind die jeweiligen Schritte unter Umständen nicht gut in großen Teams zu bewältigen. Die Entwicklung von ETL-Strecken mit Integration-Services oder das Erstellen eines OLAP Cubes mit Analysis Services sowie das Berichtswesen mit Power BI sind Aufgaben, die meist jeweils nur von einer Person zu entwickeln sind. Da es jedoch selten in einer Iteration zu allen Tätigkeiten kommt, wäre ein zu großes Team eher von Nachteil und Viererteams haben sich hier sehr bewährt.

Der Methodenbaukasten und das Fachliche Toolset für ein erfolgreiches Projekt

Um erfolgreich sowie effizient in ein BI Projekt zu starten, empfiehlt es sich, sich gut aus dem Methodenbaukasten zu bedienen, um im Voraus so viele Hindernisse wie möglich zu identifizieren und diese aus dem Weg zu schaffen.

Abbildung 2: Der Methodenbaukasten

Es bietet sich ebenso für den Start eines solchen Vorhabens an, einen sogenannten „Interaction Room“ durchzuführen. So werden alle Stakeholder und Beteiligten auf das Projekt fokussiert, Anforderungen eingesammelt und in initiale Epics überführt sowie Schwierigkeiten identifiziert und gegebenenfalls beseitigt. Ebenso hat jeder Beteiligte die Chance, Risiken oder Mehrwerte zu skizzieren und mit einzubringen.

Ebenso geht das Requirements Engineering (RE) mit einem solchen Projekt einher: Hierbei sollte eine in dieser Methodik geschulte, erfahrene sowie idealerweise zertifizierte Person den Product Owner in der Erhebung von User Stories oder Epics unterstützen. Es empfiehlt sich, dass der Requirements Engineer Erfahrungen im BI-Kontext hat, um so mit dem Product Owner Kennzahlen, Dimensionen sowie möglicherweise schon Beziehungen zwischen den Daten herauszuarbeiten. Zu beachten ist hier, dass RE keine einmalige Sache ist, sondern das Projekt stets und dauerhaft unterstützt wird. Das gilt auch für den Scrum Master. Denn wie heißt es so schön: „Eine Fußballmannschaft benötigt immer einen Trainer, auch wenn sie gerade die Champions-League gewonnen hat.“

Ein ebenso wichtiger Baustein ist der sogenannte „Sprint 0“ – welcher eigentlich formal nicht existent ist, jedoch der Vorbereitung sehr dienlich ist –, der das Lösen von technischen wie personellen Hindernissen durch den Scrum Master umfasst. Dazu zählt unter anderem das technische Bereitstellen einer Quellcode-Verwaltung sowie das Klären des Entwicklungs- sowie Bereitstellungsprozesses. Hier empfiehlt es sich, mit drei Ebenen zu arbeiten:

  1. Entwicklungsebene mit Testdaten, um das Entwickeln so effizient wie möglich zu gestalten
  2. Konsolidierungsebene, um nach jeder Iteration das Inkrement der Fachabteilung zum Testen bereitzustellen und das Produkt mit einem vollen Datenbestand auszutesten
  3. Produktionsebene

Ein personelles Hindernis ist meist die Verfügbarkeit sowie die räumliche Trennung der Mitarbeiter. Nach Möglichkeit sollte ein Entwickler zu 100 Prozent dem Projekt zugeordnet sein. Wenn dies nicht möglich ist, sollte jedoch klar geregelt sein, zu welchen Anteilen er einsetzbar ist. Ebenso empfiehlt es sich, insbesondere bei einem nicht so erfahrenen Team, dass das Entwicklungsteam nah beieinander und bestenfalls in einem Raum zusammensitzt und arbeitet.

Ein oft ebenso unterschätztes Problem ist die Unkenntnis der agilen Vorgehensweise. Demnach bietet es sich an, das Team und alle Beteiligten in Scrum zu schulen, um so ein gemeinsames Verständnis aufzubauen. Am besten werden agile BI-Projekte mit einer zwei- bis dreitägigen Schulung begonnen, in der neben dem agilen Mindset und dem Scrum-Framework auch ein besonderer Fokus auf die Besonderheiten des agilen Anforderungsmanagements gelegt wird.

Wie wird Business Intelligence in agilen Projekten in der Praxis angewendet?

Wie eingangs erwähnt, ist Scrum einfach zu verstehen, jedoch schwierig zu meistern. Nicht ohne Grund wollen immer mehr Organisationen agil entwickeln, da ein Großteil der Wasserfallprojekte scheitert (vergleiche CHAOS Manifesto der Standish Group 2012). Doch insbesondere BI-Projekte haben Eigenheiten, die in der Praxis manchmal immense Schwierigkeiten mit sich bringen. Manchmal sehen User Stories vor, die doch eher deutlich größere Epics sind, dass neue Datenquellen eingebunden werden sollen, diese aber architektonisch gegebenenfalls nicht in den vorhandenen Data Mart passen. Dies führt unter Umständen zu immensen Klimmzügen und frustriert vielleicht auch das Team. Somit ist es unerlässlich, dass das grobe Ziel bekannt ist und regelmäßig kommuniziert wird. Dies kann unter anderem durch eine Story Map erfolgen, die kontinuierlich – mindestens zu jeder Iteration – durch den Product Owner gepflegt wird. So wissen nicht nur die Projektbeteiligten umfassend Bescheid, sondern auch Außenstehende erhalten Transparenz über die laufenden Projekte und deren Fortschritt. Es empfiehlt sich außerdem, die Story Map an einem allgemein zugänglichen Ort zu platzieren und diese ständig zu pflegen.

Abbildung 3: Iterationsfolge

Ein weiterer zu berücksichtigender Punkt ist die Auslieferung neuer Inkremente aus den jeweiligen Sprints. In vergangenen Projekten hat sich eine Iterationsdauer von drei Wochen als praktikabel erwiesen. Insbesondere in BI-Projekten ist häufig viel an Grundlagenarbeit zu leisten, indem die darunterliegenden Schichten des Berichtswesens erst aufgebaut werden müssen. Diese technischen User Stories werden Spikes genannt und treten insbesondere in den ersten Iterationen vermehrt auf. Dies strapaziert meist den Product Owner sowie die Stakeholder, da der sogenannte Business Value erst in späteren Iterationen spürbar ist. Wenn das dreistufige System genutzt wird, werden Inkremente aus Sprints erst drei Wochen nach Fertigstellung ausgeliefert. Umso wichtiger ist es, alle Beteiligten mit der Vorgehensweise vertraut zu machen, für Transparenz zu sorgen sowie, egal in welcher Rolle, agil zu arbeiten und für Akzeptanz für die Vorgehensweise zu sorgen.

Geschrieben von
Philipp Lenz
Philipp Lenz
Philipp Lenz ist als Senior Consultant Business Intelligence bei der adesso AG am Standort Köln tätig und verfügt seit mehr als 15 Jahren über Erfahrung im BI-Umfeld. Mit Beginn von Microsoft Power Pivot für Excel sowie Microsoft SQL Server Reporting Services hat er seine Leidenschaft für Microsoft-Business-Intelligence-Technologien entdeckt. Seit Mitte 2016 führt er als Gründungsmitglied die Microsoft Power BI Usergroup in Köln und ist Chapter Leader der SQL PASS Mittelrhein.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: