„Das Projekt Cross Solution Center (XSC) ist gemeistert und ich bin stolz, dass aus einer vagen Idee eine neue Einheit mit sieben starken Teams entstanden ist. Ich freue mich sehr, dass ich ab der ersten Minute dabei sein durfte und danke von Herzen unseren tollen Teams, die mit viel Herzblut die Pionierarbeit für unsere neue Einheit XSC geleistet haben.“
Mit diesem Fazit beendet Christos Christopulos nach gut eineinhalb Jahren den Projektstatus des XSC, das nun eine dauerhafte Einheit wird. Damit ist der Auftrag des Vorstands aus dem April 2018 abgeschlossen: Es ging darum, schnelle und flexibel einsetzbare Entwicklerressourcen für kurzfristige und wichtige Teilprojekte bereitzustellen. Aus dieser Anforderung ist eine Einheit entstanden, in der interdisziplinär aufgestellte Teams klar abgegrenzte Arbeitspakete von anderen Entwicklungseinheiten übernehmen. Damit leistet das XSC einen wichtigen Beitrag dazu, dass die Gesamtorganisation zügiger auf Marktveränderungen reagieren kann. Gleichzeitig war und ist das Projekt XSC ein Experimentierraum, wie Julia Bangerth als Mitglied des Vorstands betont:
„Mit dem XSC haben wir Raum zum Experimentieren und Lernen geschaffen, um von den Erfahrungen auch in anderen Bereichen des Unternehmens zu profitieren – sowohl in Hinblick auf Zusammenarbeits- und Raumkonzepte, als auch auf Weiterbildungs- und Recruitingprozesse sowie die Organisation selbst.“
18 Monate hatte das Projekt Zeit, um das XSC von der Idee zu einer Einheit mit sieben Teams plus Supportorganisation zu entwickeln – und mittlerweile hat auch das achte Team bereits angefangen. Alle drei Monate starteten neue, interdisziplinär und crossfunktional besetzte Entwicklerteams und arbeiteten jeweils quasi ab dem ersten Tag produktiv an Arbeitspaketen. Innerhalb eines Arbeitspakets wird in Sprints gearbeitet. Ein Sprint entspricht in der Regel zwei Wochen Entwicklungsarbeit. Danach gibt es einen Review: Entwickler und Auftraggeber setzen sich zusammen, prüfen, ob es in die richtige Richtung geht und setzen gemeinsam Ziele für den nächsten Sprint.
Nach drei Monaten mussten die Pakete abgeschlossen und wieder an die Fachabteilung übergeben werden. So wurden mittlerweile 15 Pakete bearbeitet – und viele weitere werden folgen. Der Dreimonatsrhythmus erfordert von den Teams eine hohe Flexibilität: Jedes Arbeitspaket kommt mit völlig neuen inhaltlichen und technologischen Anforderungen daher. Florian Tauber, Product Owner eines der XSC-Teams, blickt in einem internen Blogbeitrag im Dezember 2019 nach rund eineinhalb Jahren auf die vergangenen Arbeitspakete zurück:
„Am Ende wird alles gut. Das war nun bereits unser viertes Arbeitspaket und einerseits lässt sich eine gewisse Routine feststellen: Die Wechsel werden schneller und runder, der Umgang mit neuen Anforderungen gewohnter und das Umdenken einfacher. Auf der anderen Seite lernen wir immer noch sehr viel dazu: Wie arbeiten andere Teams, wie gehen wir am besten mit ungeplanten oder unvorhersehbaren Situationen um (als Team) und schlussendlich welche Technologie wird wie und warum eingesetzt. Auch in Bezug auf die Zusammenarbeit, die Rahmenbedingungen, wie dem strikten Timeboxing, sowie dem „richtigen“ Schneiden von Arbeitspaketen lernen wir dazu: Funktional gesehen war der Umfang des Pakets theoretisch möglich, unterschätzt wurden zusätzliche Aufwände hinsichtlich spezieller Anforderungen bei der Qualitätssicherung, Risiken bei Erstimplementierung sowie Abhängigkeiten durch prozessorale Gegebenheiten (wie paralleles Arbeiten an gleichen Projekten, Delay durch Code-Reviews). Dies und viele weitere Faktoren sind beim Zuschnitt der Arbeitspakete nicht zu unterschätzen. Also, wieder was gelernt!“
Beim Zuschnitt der Pakete ist es also wichtig, darauf zu achten, dass die Aufgaben innerhalb von drei Monaten machbar sind. Dafür ist auch die Fachabteilung verantwortlich, die Unterstützung sucht – denn sie bestimmt, was das XSC-Team entwickeln soll. Und auch von ihrem Input hängt es ab, ob das Paket erfolgreich abgeschlossen und danach reibungslos in das Gesamtprojekt integriert wird. Sie muss etwa an Reviews teilnehmen und für Nachfragen erreichbar sein. Der erste Auftraggeber in der Projektphase des XSC war Sascha Deeg mit einem Arbeitspaket für die Rechteverwaltung online. Er hat die Zusammenarbeit mit den agilen Entwicklerteams sehr zu schätzen gelernt – auch, weil die Teams alle Schritte von den Anforderungen über den Betrieb bis zum Test aus einer Hand anbieten können:
„Vor allem das verteilte, breite Wissen im Team ist für die Arbeit im XSC ein großer Vorteil: In den Build Pipelines werden alle wesentlichen Punkte gleich von Anfang an berücksichtigt. Da wurde beispielsweise Security direkt in die Konzeption einbezogen, so dass die abschließenden Penetrationstests keine Überraschungen verursacht haben. Oder ein anderes Beispiel: Gleich zu Beginn wurde sichergestellt, dass die neueste Version des Spring-Frameworks für die Entwicklung verwendet wurde. So musste nicht auf halber Strecke noch umgesattelt werden. Diese Kompetenzvielfalt hilft unheimlich, von vorne herein im Projekt fokussiert und effizient zu agieren.“
Dazu kommt, dass in der Supportorganisation, die den Entwickler-Teams etwa mit Expertenwissen zur Seite steht, teilweise ganz neue Rollen entstanden sind. Zum Beispiel der Corporate Learning Coach (CLC). Er soll dafür sorgen, dass sich die Kolleginnen und Kollegen kurzfristig und quasi nebenbei weiterbilden können. Wer sich alle drei Monate auf eine völlig neue Aufgabe einlässt, muss sich schließlich sehr oft und sehr schnell in neue Themen und Technologien einarbeiten. Der Coach prüft deswegen schon vor Beginn eines neuen Arbeitspaktes, ob die nötigen Kompetenzen im Team vorhanden sind. Wenn nicht, organisiert er zum Beispiel interne Workshops oder auch mal einen externen Experten. Die Entwickler entscheiden dabei selbst, was sie brauchen:
„Dieses Modell trägt Früchte und kommt bei den Teammitgliedern super an“, sagt Corporate Learning Coach Jürgen Latteyer.
Ohne Vertrauen in die eigenen Mitarbeiter geht es also nicht. Aber genauso wenig ohne Vertrauen zwischen Auftraggeber und XSC-Teams. Denn beide Seiten kennen sich meistens nicht – sie wissen also nicht genau, auf was sie sich einlassen. Die Verantwortung für das Produkt hat dagegen am Ende nur der Auftraggeber. Aus Angst, dass etwas schiefgehen könnte, schrieben deswegen anfangs einige Fachabteilungen umfangreiche Richtlinien und wollten alle Vereinbarungen dokumentieren. Damit bremsten sie die Arbeit der Entwickler aus. Was also tun, um von Vornherein eine Vertrauensbasis zu schaffen? Dieser Frage ist Christina Frauenknecht, Product Owner im XSC, nachgegangen:
„Im Prinzip bleibt uns bei einem Arbeitspaket von 3 Monaten Dauer zu wenig Zeit, um gegenseitiges tiefes Vertrauen aufzubauen. Wir benötigen eine Art ‚Vertrauensvorschuss‘ von den Auftraggebern. Und da in dem Sprichwort ‚Für den ersten Eindruck gibt es keine zweite Chance‘ ja doch ein Funke Wahrheit steckt, haben wir beschlossen, unseren Kick-Off mit den Auftraggebern zu nutzen, um dieses Vertrauen zu schaffen: Wir stellten uns als Team, unsere Arbeitsweise und die bisherigen Projekte vor. Um sowohl echten Kundennutzen zu erreichen als auch dem Auftraggeber-Team eine zukunftsfähige Lösung zu bieten, achten wir insbesondere auf eine standardisierte, wartbare und einfache Umsetzung.“
Inzwischen sind viele DATEV-Mitarbeiter von diesen neuen Wegen der Zusammenarbeit überzeugt: Es gibt immer mehr Anfragen an das XSC, Arbeitspakete zu übernehmen. „Ich bin dankbar, dass Julia Bangerth und Prof. Dr. Christian Bär von Anfang an an die Idee geglaubt haben und die Vision hatten, ausgetretene Pfade zu verlassen und neue Wege zu gehen“, sagt der ehemalige Projektleiter Christos Christopulos. Er kann also entspannt durchatmen – und widmet sich heute neuen Aufgaben im Außendienst.
Hier schreibt für euch:
