Scrum & BI – Eine Hassliebe mit Zukunft?

Scrum hat sich überall in der Softwareentwicklung etabliert. Überall? Nein! Unbeugsame BI-Experten leisten standhaft Widerstand. Natürlich haben auch sie Scrum in ihre Arbeitsweise integriert, aber eben auf ihre ganz spezielle Art und Weise. Und dafür haben sie gute Gründe. Drei Wesentliche wollen wir hier beleuchten.

I) BI-Entwickler brauchen Fachwissen

Ein „normaler“ Softwareentwickler muss vor allem sein Handwerk beherrschen. Fachwissen ist meist nicht spielentscheidend. Ganz anders sieht das bei einem BI-Entwickler aus – er muss vor allem das „Business“ verstehen, in dem er arbeitet. Häufig bleiben BI-Entwickler jahrelang in derselben Branche, da sie sich wertvolles Branchenwissen angeeignet haben. Wie haben sie das gemacht?

• Datenanalyse: Sie haben mit viel Geduld Daten analysiert, um die dahinter liegenden Geschäftsprozesse zu verstehen.
• Gespräche mit dem Fachbereich: Sie arbeiten eng mit den Anwendern aus den Fachbereichen zusammen und konzentrieren sich oft auf bestimmte Themen, um sich tief in die Materie einzuarbeiten.
• Langjährige Erfahrung in einer spezifischen Branche: Ihr Wissen ist so wertvoll, dass es mit einer eigenen Ausbildung vergleichbar ist.

II) BI-Entwickler müssen die Geschäftsprozesse verstehen

Nicht nur auf der Anwendungsseite, sondern auch hinsichtlich der Datenentstehung müssen BI-Entwickler tiefes Kontextwissen aufbauen. In einer Organisation verstehen sie oft die Prozesse am besten, da sie die Quelldaten interpretieren müssen. BI-Entwicklung beginnt nicht auf der grünen Wiese, sondern baut auf bestehenden Datenlandschaften und Prozessen auf. Die Einarbeitung ist oft mühsam und zeitaufwendig – ein Generalist kann nicht ohne weiteres zwischen verschiedenen BI-Systemen und Branchen wechseln.

Warum ist das ein Problem für Scrum?

Scrum erfordert Generalisten. Die Idee ist, dass Entwickler gemeinsam an Stories arbeiten, sich wechselseitig helfen und überprüfen, um die Stories fokussiert abzuschließen. In der Softwareentwicklung ist das meist gut realisierbar – in der BI-Entwicklung jedoch nur mit Einschränkungen. Ein Entwickler, der sich monatelang in Sales-Prozesse eingearbeitet hat, kann nicht einfach bei der Integration von Betriebsdaten unterstützen. BI-Entwickler haben nicht nur unterschiedliches IT-Know-how, sondern auch spezialisiertes Branchenwissen.

Wie gehen wir damit um?

Akzeptanz der Spezialisierung

Zunächst ist es wichtig, diesen Konflikt zu erkennen und zu respektieren. Scrum-Master sollten nicht dogmatisch auf Generalistentum bestehen, denn BI-Entwickler haben über Jahre hinweg tiefgehendes Wissen aufgebaut, das nicht entwertet werden sollte. Gleichzeitig darf Spezialisierung nicht so weit gehen, dass sie den Wissensaustausch verhindert.

Die agile Forderung nach Transparenz und Wissensweitergabe stößt nicht immer auf Begeisterung. Doch in der Regel verstehen Entwickler, dass es notwendig ist, Wissen zu teilen und sich im Team breiter aufzustellen – solange dies nicht bedeutet, dass jeder alles beherrschen muss.

Wissensmatrix aufstellen

Es ist hilfreich, die Wissensgebiete zu erfassen und herauszuarbeiten, wer sich bei welchem Thema am besten auskennt. Daraus kann ein Plan entwickelt werden, um Wissenslücken zu schließen.

Team-Wissenslücken schließen

Wissen kann organisch im Daily Business weitergegeben werden:

• Pair Programming oder gemeinsames Debugging: Am besten lernt man im Tun! Setzt euch doch einfach mal mit einem „Experten“ vor eine User Story – besonders in Themengebieten, die euch noch neu sind. Klar, das dauert am Anfang länger, aber hey, ihr lernt dabei, und oft bringen genau eure Fragen und Anmerkungen neue Anstöße oder sogar bessere Lösungen.

• Code Reviews durch „Neulinge“: Neue Entwickler übernehmen gezielt Code-Reviews, um sich in Themen einzuarbeiten.
• Regelmäßige Wissensrunden: Teaminterne Schulungen helfen dabei, Wissen zu verteilen, sollten aber nicht einfach „nebenbei“ laufen. Am besten packt der Product Owner sie als User Stories direkt in den Sprint. Denn klar ist: Wissensverteilung kostet Zeit, bringt aber langfristig allen etwas – also lieber einplanen, statt darauf zu hoffen, dass es „schon irgendwie passiert“.

Themenrotation ermöglichen

Um zu verhindern, dass nur einzelne Entwickler Experten für bestimmte Themen sind, solltet ihr Themen regelmäßig rotieren. Ein positiver Nebeneffekt: Entwickler dokumentieren sauberer und programmieren strukturierter, wenn sie wissen, dass andere ihren Code übernehmen werden.

Fachliche Dokumentation als Schlüssel

Gute Dokumentation ist im BI-Bereich essenziell. Neben Entwicklungs- und Anwendungsdokumentation ist die fachliche Dokumentation besonders wichtig. Die Interpretation der Daten ist oft schwieriger als deren technische Verarbeitung – eine fundierte Beschreibung der datengenerierenden Prozesse ist daher unerlässlich.

III) BI-Entwickler entwickeln sehr wenig

Das eigentliche Coding nimmt nur einen geringen Anteil der täglichen Arbeit eines BI-Entwicklers ein. Meistens analysiert er Daten und konzipiert Lösungen, die er testet. Bevor die erste Umsetzung für einen Fachanwender steht, vergeht häufig viel Zeit. Scrum bevorzugt jedoch schnelle Entwicklungszyklen mit Features, die direkt Mehrwert bieten. Dieser Widerspruch ist herausfordernd.

Wie gehen wir damit um?

Runterbrechen von fachlichen Anforderungen in Epics und User Stories: Der BI Product Owner muss die Anforderungen der Anwender so strukturieren, dass sie in Sprints realisiert werden können. Bewährt hat sich dabei, die Anforderung eines Fachbereichs als Use Case – also als Epic – zu formulieren. Dieses Epic wird dann in mehrere User Stories aufgeteilt, die Schritt für Schritt umgesetzt werden.

• Epics einen technischen Verantwortlichen zuordnen: Wir haben sehr gute Erfahrungen damit gemacht, jedem Epic einen Entwickler als technischen Verantwortlichen Er eignet sich für „seinen“ Use Case das tiefste Fachwissen an, behält die Gesamtlösung im Blick, kümmert sich um die Konzeption und steuert die zugehörigen User Stories. Die Umsetzung der einzelnen Stories kann dann von anderen Entwicklern übernommen werden.

• BI-Reviews sind keine klassischen Sprint-Reviews: In der BI-Entwicklung entstehen durch das Runterbrechen fachlicher Anforderungen oft Zwischenprodukte, die für Anwender zunächst wenig Mehrwert bieten. Das steht im Widerspruch zum agilen Prinzip des Minimal Viable Product (MVP).

Dadurch leiden auch die klassischen Sprint-Reviews: Häufig gibt es nichts wirklich „Vorzeigbares“, das die Fachanwender begeistert. Bis echter Mehrwert geschaffen ist, wurden sie bereits mehrfach für Tests und Abnahmen kontaktiert – sodass das finale Feature für sie keine Überraschung mehr ist.

Deshalb macht es im BI-Scrum Sinn, Reviews flexibler zu gestalten: Statt eines großen Sprint-Review-Meetings mit allen Stakeholdern ist es oft effektiver, gezielt einzelne Anwender einzubeziehen. Die BI-Abteilung liefert Berichte und Daten für verschiedene Fachbereiche – viele davon sind nur für einen bestimmten Kreis relevant. Ein zentrales Review-Meeting wird deshalb oft als langweilig und wenig produktiv empfunden.

Fazit

Passt man agile Prinzipien an die BI-Entwicklung an, können auch unsere unbeugsamen BI-Entwickler mit den „Römern“ arbeiten. Teams können nicht einfach als Generalisten aufgestellt werden – wer das versucht, erntet erbitterten Widerstand. Doch mit gezieltem Wissensaustausch, klar definierten technischen Verantwortlichkeiten und guter fachlicher Dokumentation kann Scrum auch in BI-Teams erfolgreich eingesetzt werden. Die wichtigste Erkenntnis: Agilität bedeutet nicht, dass jeder alles können muss, sondern dass Wissen nachhaltig verteilt und weiterentwickelt wird.

✍️ Über den Autor:

Dr. Katharina Wirtz ist Gründerin von SKET22 GmbH und Scrumkitchen, Trainerin, zertifizierte Coachin (dvct | cSBC) und agile Transformationsberaterin.