Über unsMediaKontaktImpressum
Edgar Kaemper 10. Oktober 2018

Eine konkrete Geschichte der Agilität im Data Warehouse

Wäre das nicht ein Traum? Anforderungen fließen durch Data-Warehouse-Projekte wie Wasser in einem Fluss. Das Ufer grenzt klar ab, was zum Fluss gehört und was nicht. Es liegen noch Steine im Weg. Das Wasser muss über die Steine oder um die Steine herumfließen. Aber das Wasser fließt: konstant, verlässlich, berechenbar. Wäre das nicht ein Traum? Konstant neue Features im DWH liefern. Verlässlich Requirements abarbeiten. Berechenbar Projektlaufzeiten einhalten. Für uns ist es nicht bei diesem Traum geblieben.

Eine konkrete Geschichte der Agilität im Data Warehouse

  • Ich beschreibe die Erfahrungen aus einem DWH-Projekt bei Bosch in Plochingen. Es ist eine konkrete Geschichte, nicht ein Gesamtüberblick aller Scrum-Erfahrungen aus dem Hause Bosch.
  • Es ist eine konkrete Geschichte, nicht Theorie, nicht erfunden. Konkrete Beispiele aus einem konkreten Projekt. Konkrete Erfahrungen, die für uns hilfreich waren.
  • Es ist eine konkrete Geschichte, nicht theoretische Abhandlung, nicht vollumfängliche Beschreibung. Kurze Einblicke in für uns wichtige Erfahrungen und Meilensteine auf dem Weg vom Traum zur Realität.

Unser Weg

Auf dem Weg, ein agiles Projektteam zu werden, haben wir verschiedene Methoden ausprobiert. Immer wieder haben wir in Retro-Meetings unser Vorgehen reflektiert und nach Verbesserungen gesucht. Nicht nur für das Produkt, sondern auch für den Scrum-Prozess. Den Umstieg auf kurze Lieferzyklen von 2 Wochen haben wir auch dazu genutzt, neue Ideen risikoarm auszuprobieren. Maximal ein Sprint oder Teile eines Sprints sind evtl. dann nicht erfolgreich, wenn die Idee keine Verbesserung bringt.

Aber wie sah unser Weg nun konkret aus? Welche Schritte sind wir gegangen? Was hat sich dadurch verändert und verbessert? Welche Schritte waren nicht erfolgreich? Abb. 1 stellt die Schritte als fortlaufenden Verbesserungsprozess dar. Und so haben wir das auch erlebt. Jeder Schritt hat in einem Teilbereich Verbesserungen gebracht. Aber jeder Schritt hat auch noch Punkte offengelassen. Oder anders ausgedrückt: Wir haben uns so sehr an die Möglichkeiten gewöhnt, alle 2 Wochen Verbesserungen einbringen zu können, dass wir mehr und mehr unseren Blick dafür geschärft haben, die Verbesserungsmöglichkeiten auch zu sehen.

Kanban

"Ich brauche mehr Transparenz." Diese Forderung unseres Projektleiters war der Ausgangspunkt für einen ersten Versuch, das Projektteam aus Projektleiter, 2 Spezifikateuren, Daten-Architekt und 2 ETL-Entwicklern agil zu organisieren. Mit dem Ziel der Transparenz war sicherlich auch der Wunsch verbunden, die große Anzahl an Requirements mit dem Team in Time und Budget zu schaffen. Aus der bisherigen Projektarbeit hatte das Team bereits gelernt:

  • Die Spezifizierung eines ETL und die Implementierung haben andere Phasen, nach denen sie ablaufen und gesteuert werden.
  • Die Spezifizierung eines ETL und die Implementierung dauern unterschiedlich lang.
  • Die Spezifizierung braucht viel Zeit (nicht Aufwand), z. B. für Abstimmtermine oder das Warten auf Antworten.
  • Die Implementierung des ETL ist in der Regel nur nach der Spezifizierung machbar.

Der Schritt zu SCRUM schien uns zu dem Zeitpunkt mangels Erfahrungen mit der Methode noch zu groß. Mit Kanban-Boards hatte fast jeder im Team schon Erfahrungen gemacht. Die Größe des zur Verfügung stehenden Boards beantwortete auch die Frage, ob 1 oder 2 Boards für ETL-Implementierung und Spezifikation. Wir haben 2 Kanban-Boards auf Vorder- und Rückseite aufgebaut.

Die Spalten waren aus den Erfahrungen der Projektarbeit schnell gefunden, als Swimlanes haben wir zunächst nur zwischen "normalen" Requirements und Defects unterschieden. Im späteren Projektverlauf kamen noch temporär Swimlanes für größere Anforderungen mit vielen Kanban-Karten dazu.
Die Forderung des Projektleiters nach mehr Transparenz haben wir zu 100 Prozent erfüllt. Das Kanban-Board stand direkt an seinem Schreibtisch. Er konnte direkt ablesen, welche Anforderungen in Arbeit waren, was bereits spezifiziert war und "nur noch" auf die Implementierung gewartet hat. Auch der Fortschritt der einzelnen Aufgaben war durch das Weiterschieben der Post-its von Spalte zu Spalte in den Statusmeetings direkt sichtbar.

Aber wie macht man ein Kanban-Board, das am Schreibtisch des Projektleiters steht, sichtbar für neue Teammitglieder an Offshore-Standorten? Wie verbessert man die Durchlaufzeiten von Aufgaben? Denn das Board macht auch klar, dass die Durchlaufzeiten sich durch die Einführung des Boards nicht einfach so mit verbessern. Ganz im Gegenteil: ein paar Post-its klebten unverändert über Wochen in der gleichen Statusspalte fest.

Scrum

Zwei Haupterkenntnisse haben wir aus den Erfahrungen mit den Kanban-Boards für die weitere Entwicklung des Teams gezogen:

  • Die Methode wird in dieser Art nicht für die Integration weiterer interner und externer Ressourcen an verschiedenen Standorten skalieren.
  • Mit der Methode gelingt es uns nicht ohne zusätzlichen Aufwand, die Durchlaufzeit von Requirements zu stabilisieren und planbar zu machen.

Durch einen neuen Kollegen kamen positive Erfahrungen mit Scrum aus einer anderen Geschäftseinheit ins Projekt. In den Diskussionen mit ihm wurde für uns deutlich, dass genau an diesen zwei Erfahrungen eine Umstellung auf Scrum als Methode Vorteile und Hilfestellungen bieten könnte.
Die Umstellung haben wir mit einem zweitägigen Workshop für das ganze Team eingeleitet. Dabei haben wir alle Grundbegriffe und Abläufe von Scrum erläutert und mit kleinen Übungen verständlich gemacht. Für das Team-Building war zusätzlich sehr hilfreich, fast alle Kollegen aus den Offshore-Standorten für diesen Workshop vor Ort zu haben.

Die ersten Sprints waren noch geprägt vom Refinement des Backlogs und der Definition of Done (DoD). Diese Phase liefert noch keinen Output im Sinne von neuen Daten oder ETL-Strecken. Sie ist aber wichtig, um das Team zu einem gemeinsamen Verständnis zu führen, wann eine Story wirklich fertig ist und welche Art von Story welche Komplexität hat.

Für die Stakeholder bedeutete die Umstellung auf Scrum auch einen Lernprozess.

  • Aufwandsschätzungen werden nicht mehr von Einzelpersonen im Schnellverfahren gemacht, sondern in Refinements im Team. Ja, das dauert länger, liefert jedoch zusätzlich zu einem sehr frühen Zeitpunkt die Aufwands- und Zeittreiber.
  • Direkte Ansprache von Entwicklern für "Sonderaufgaben" wird zu Gunsten eines priorisierten Backlogs und planbaren Durchlaufzeiten unterbunden.

In diese Phase der ersten Erfahrungen mit Scrum fiel auch der Ausbau des Teams auf 13 Personen an drei Standorten. Da immer wieder neue Personen ins Team und das Projektthema eingeführt werden mussten, kam der Aspekt "Selbstorganisation des Teams" zum Tragen. Am Anfang noch unterstützt durch entsprechende Stories vom Product Owner, übernahm das Team mehr und mehr Verantwortung, legte Templates für die Trainingspläne an, adaptierte die Pläne für die jeweiligen neuen Personen und gewährleistete die Einführung der neuen Personen selbständig.

Als Tool zur Unterstützung haben wir aus dem Angebot der zentralen IT einen Issue Tracker mit Scrum-Aufsatz sowie ein Wiki eingesetzt. Die Transparenz aus dem Kanban-Board blieb so erhalten. Durch die Umstellung auf ein Virtuelles Board haben nun alle Mitarbeiter und Stakeholder im Projekt Zugriff auf das Board und können sich einen Überblick verschaffen und ihre Statusinformationen direkt erfassen.

Eine Herausforderung blieb auch nach der Umstellung auf Scrum: Der Output des Teams skalierte nicht mit den ins Team integrierten Ressourcen. Trotz mehr und mehr Personen im Team haben wir keine adäquate Steigerung des Outputs erreichen können.

Feature Teams

Bedeutet die fehlende Skalierung das Scheitern eines agilen Ansatzes in diesem Team? Das Aufgeben von Scrum und Agilität war in der Tat eine Option in der Lösungsfindung. In den Diskussionen mit den Teammitgliedern und Retrospektiven wurden weitere Alternativen gefunden, den Scrum-Ansatz mit leicht veränderten Rahmenbedingungen beizubehalten.

Mit dem Ausbau des Teams auf 13 Personen haben wir die Empfehlung für Scrum von 5-7 Personen deutlich überschritten. In 2 Richtungen haben wir Auswirkungen auf den Erfolg und die Skalierung des Teams gesehen:

  • Es scheint einen Zusammenhang zwischen der Größe des Teams und der gefühlten Verantwortung des einzelnen für den Erfolg des Teams zu geben. Irgendwo zwischen 5 und 13 Personen im Team ist die Abnahme des Verantwortungsgefühls so groß, dass der Erfolg des Teams stagniert.
  • Genauso scheint sich die Tendenz zu erhöhen, sich sein "Spezialgebiet" zu suchen und abzustecken. Die Informationsaufnahme und das Engagement werden in der Folge auf dieses "Spezialgebiet" fokussiert. Ein Refinement im gesamten Team wird bezgl. der Aufgaben außerhalb des Spezialgebiets dann als langweilig und lästig empfunden.

Wir haben diese gefühlten Zusammenhänge nicht detailliert untersucht und auch nicht nachgerechnet. Wir haben pragmatisch ausprobiert, ob und wie uns eine Aufteilung des Teams in 2-3 Teams hilft. Bei der Aufteilung haben wir aus den anstehenden Stories im Backlog eine Aufteilung nach Datenbereichen gewählt. Da wir die Lieferung von Daten als ein Feature eines Data Warehouses ansehen, haben wir für die Aufteilung des Teams in Subteams den Begriff Feature-Team verwendet.

Die völlige Trennung der Teams und Schaffung eines Überbaus z. B. in Form von Scrum of Scrum schien uns zu viel Overhead, wir haben stattdessen die Refinements und Daily Stand-ups in den Feature-Teams gemacht. Das Review und die Retrospektiven haben wir im gesamten Team gemacht, um weiterhin den Austausch von Know-how und die Absprache von gemeinsamen Prozessänderungen organisatorisch zu verankern.

Was hat uns dieser Schritt in Richtung Feature-Teams gebracht?

  • Die Motivation in den Teams ist gestiegen, da die Fokussierung auf das Feature dem Wunsch nach einem "eigenen" Aufgabengebiet entgegenkam. Wir haben diese Auswirkung durchaus kontrovers diskutiert, steht Sie doch in gewisser Weise der Verantwortung des gesamten Teams für das gesamte Data Warehouse entgegen. Aber das war unser Weg, nicht die reine Lehre zu verfolgen, sondern einen pragmatischen Weg zu suchen, der uns hilft, erfolgreich zu bleiben.
  • Auch den Output des gesamten Teams haben wir durch die Umstellung auf Feature Teams deutlich gesteigert. Damit entsprach der Output auch endlich den Erwartungen im Hinblick auf die Größe des Teams.

Nachdem die Teams einige Sprints in diesem Modus gearbeitet und geliefert haben, war das erste Feature-Team mit der Entwicklung des Features fertig und hat dieses in die Produktion überführt. Aber Aufwand und Komplexität für die Entwicklung eines Features (z. B. Anbindung einer Datenquelle) sind deutlich höher als für die laufende Produktion und das Defect Fixing. Was macht ein Feature-Team, wenn es nicht ausgelastet ist, oder andere Stories außerhalb des Features höher priorisiert sind? Eine spannende Frage, die wir nur andiskutiert haben, aber keine Lösung dafür ausprobiert haben. Die nächsten 2 Schritte kamen dem zuvor und haben eine Lösung für das Problem unnötig gemacht.

Architecture refit

Die Motivation im Team steigt, der Output skaliert gut im Verhältnis zu den Ressourcen im Team. Wir arbeiten an Engpässen, gestalten Abläufe im Team um und beseitigen diese mit gezieltem Know-how-Transfer. Die Feature-Teams arbeiten einige Sprints in diesem Modus und liefern im Durchschnitt einen konstanten und zu den Ressourcen passenden Output. Alles gut?

Nein, denn der Architekt stellt eine wachsende Abweichung von den Architekturvorgaben und Konzepten fest. Diskussionen im Team zur Analyse der Ursachen zeigen in Richtung technischer Zwänge, Performanceanforderungen, Komplexität der Datenquellen und deren Datenqualität. Wir starten das Jahr mit einem mehrtägigen Workshop zur Architektur. Das Team stellt seine Lösungsvorschläge vor, der Architekt die Konzepte hinter den Architekturvorgaben. Im gemeinsamen Refinement der Stories zu einer großen Epic wird ein neuer Lösungsansatz geboren, flexibel genug für die Komplexität und Qualität der Datenquellen und architekturkonform. Ein Durchbruch.

Warum war dieser Durchbruch möglich? Wir halten folgende Faktoren für ausschlaggebend:

  • Standing der Teammitglieder: Ohne die Bereitschaft, die Differenzen zwischen Architekturvorgaben und Lösungsvorschlägen auch auszutragen, zu seiner Meinung zu stehen und nach einem gemeinsamen Weg zu suchen, wäre die intensive Diskussion und das Finden eines komplett neuen Lösungsansatzes nicht gelungen. Dieses Standing hat eine Vorgeschichte, die gemeinsamen Erfahrungen in dutzenden von Sprints mit Daily-Stand-ups und Retrospektiven. Dadurch wurden persönliche Beziehungen und Vertrauen gefördert.
  • Stabilität: Geholfen hat für den Durchbruch sicherlich auch die Stabilität des Teams in dutzenden Sprints ohne Fluktuation in derselben Teamkonstellation zusammen zu arbeiten.  
  • Auszeit: Der Workshop zum Jahresanfang war nur mit der Bereitschaft der Stakeholder möglich, eine "Auszeit" des Teams zu akzeptieren. Die Stakeholder haben einen Sprint ohne Lieferung von Ergebnissen akzeptiert und auch die zusätzlichen Kosten für die Anreise der Offshore-Mitarbeiter.
  • Moderation: Ein solcher Workshop braucht gute Moderation, vereinfacht wird das durch einen "externen" Moderator, der nicht in die tägliche Scrum-Arbeit involviert ist.
  • Auf den Punkt kommen: Als Abschluss des Workshops stand eine Präsentation vor den Stakeholdern an. Jeder im Team hatte die Gelegenheit, einen Teil des Teamergebnisses und dadurch auch sich selbst zu präsentieren. Das Team war gezwungen, auf den Punkt zu kommen und Diskussionen auch mit Entscheidungen und konkreten Lösungsvorschlägen abzuschließen.
  • Vor Ort: Alle Teammitglieder, auch die vom Offshore-Standort waren vor Ort. Es gab keine Beteiligung via Skype oder Videokonferenz. So hatten alle die gleiche Chance, sämtliche Aspekt der Kommunikation mitzuerleben.

Auslauf des Projektbudgets

Eine Bewährungsprobe stand dem Team noch bevor. Ein Teil der Finanzierung des Teams war als Anschub für das neue Thema gedacht und zeitlich begrenzt. Wie wird sich das Team mit Scrum in einer Phase bewähren, in der nicht neue Personen ins Team zu integrieren sind, sondern die Hälfte des Teams nach und nach das Team verlässt? Wie wird der Weggang von Know-how-Trägern kompensiert und wie geht das Team mit seiner Motivation in dieser Phase um?

Natürlich ist im Team zunächst auch Ernüchterung und eine gewisse "Schockstarre" zu spüren, wenn klar wird und zeitlich näher rückt,

  • dass die Anschubfinanzierung wirklich eine Anschubfinanzierung bleibt und die heimliche, unausgesprochene Hoffnung oder Erwartung, dass es eine Dauerfinanzierung ist, nicht erfüllt wird,
  • dass die Budgets für externe Mitarbeiter wirklich wie geplant auslaufen und nicht durch neue Budgets ersetzt werden und,
  • dass ein Teil der internen Mitarbeiter in anderen Projekten gebraucht wird und in diese wechseln und konsequenterweise auch nicht nachbesetzt werden.

Da braucht es zunächst eine klare Kommunikation, dass ein Anschub mit zusätzlichen Ressourcen nie dauerhaft sein kann und der Wegfall keine "Herabstufung" des Themas ist. Für die konstruktive Erarbeitung von Plänen für das weitere Vorgehen haben sich dann die in vielen Sprints eingeübten Scrum-Standardwerkzeuge bestens bewährt.

  • Nutzung und Anpassung der Trainingspläne, um drohende Know-how-Lücken nach dem Weggang von Know-how-Trägern zu schließen. Dabei hat sich die Praxis der Refinements im Team bewährt. Zur Aufwands- und Komplexitätsabschätzung wurden alle Stories im Team so lange diskutiert, bis jeder die Story verstanden hat und den geschätzten Aufwand und die geschätzte Komplexität mittragen konnte. So gab es nur noch wenige Lücken zu schließen.
  • Alle Requirements, auch wiederkehrende Aufgaben, werden als Story im Backlog eingeplant. So gehen keine regelmäßigen Tasks verloren. Zusätzlich wird über die Definition of Done (z. B. ein Task ist erst fertig, wenn er auch dokumentiert ist) sichergestellt, dass die regelmäßigen Aufgaben dokumentiert sind und ein anderer diese übernehmen kann.
  • Auch Aufgaben für den Know-how-Transfer werden als Story im Backlog geführt. So hat der Product Owner die Möglichkeit, rechtzeitig vor dem Weggang von Mitarbeitern den Know-how-Transfer in die Sprints einzuplanen. Und er kann auch gegenüber den Stakeholdern die Priorität für den Know-how-Transfer mit konkreten Stories einfordern.  

Es geht also doch zusammen: Einhalten der Architektur und Produktivität. 

Unsere Erfahrung in dieser Bewährungsprobe: Nach anfänglicher "Schockstarre" ist das Team in einen konstruktiven Modus zurückgekehrt und hat diese Phase sehr gut gemeistert. Die Motivation blieb im Team erhalten und es trat kein signifikanter Know-how-Verlust beim Weggang von Keyplayern auf. Bewährungsprobe bestanden!

Performance – Kann man den Erfolg von Scrum messen?

Aber kann man alle diese Erfahrungen auch sehen, messen, sichtbar machen? Ja, man kann. Sicher nicht mit mathematischer Präzision. Und auch nicht im Vergleich von Scrum-Teams untereinander. Aber doch in einer überraschenden Deutlichkeit. Als wir die Standard-Reports aus dem elektronischen Scrum-Board mit den Änderungen in unserer Methodik angereichert haben, konnten die Änderungen in der Steigung der Kurve aus den jeweiligen Änderungen der Methodik erklärt werden.

In der Aufbauphase des Teams skaliert der Output nicht mit der Größe des Teams, d. h. trotz mehr Ressourcen werden nicht mehr Issues fertig. Die Einführung von Feature-Teams liefert die erhoffte Änderung, das Team wird deutlich produktiver und skaliert. Die Auszeit für den Workshop zum Architecture Refit wird sichtbar, aber auch, dass danach die Lieferung von fertigen Issues auch bei Einhaltung der Architekturvorgaben unvermindert weitergeht. Es geht also doch zusammen: Einhalten der Architektur und Produktivität. 

Und das Auslaufen der "Anschubfinanzierung" und der Rückgang der Teamgröße zeigt sich natürlich in einem Abflachen der Kurve für die gelieferten Issues. Allerdings ist der Rückgang nicht so groß wie auf Grund der Kapazitätsrückgänge zu erwarten gewesen wäre – auch ein Erfolg der starken Team-Orientierung in Scrum. Der Weggang von Keyplayern wirkt sich nicht so stark aus, da schon frühzeitig das Team sein Know-how im Rahmen der Story Refinements shared und Know-how-Inseln vermieden werden.

Eine konkrete Geschichte der Agilität im Data Warehouse

Wie gesagt, hierbei handelt es sich um eine konkrete Geschichte. Ziehen Sie Ihre Schlüsse daraus, seien Sie mutig und probieren Sie aus, was Sie für richtig erkannt haben und teilen Sie dann Ihre Erfahrungen, Ihre konkrete Geschichte der Agilität.

Autor

Edgar Kaemper

Edgar Kaemper ist Lead-Architekt Daten- und Informationssysteme bei der Robert Bosch GmbH im Bereich Automotive Aftermarket/Automotive Service Solutions/IAM Software Engineering.
>> Weiterlesen
Das könnte Sie auch interessieren
botMessage_toctoc_comments_9210