"Mit SAFe machen wir einen massiven Schritt über Scrum hinaus"

Fiscal-IT, Nachfolger von Insieme, ist das erste, nach SAFe entwickelte Projekt des BIT. Wir haben nachgefragt, wie, was, wo, warum.
 
"Agil heisst, fortlaufend bereit zu sein, den Kurs auf die Erkenntnisse anzupassen. Agil heisst, in kleinen Schritten grosse Wege zu gehen. Agil heisst, zwischen Fach und IT gemeinsam fortlaufend den zu beschreitenden Weg zu verstehen und zu vereinbaren", der dies sagt, ist Giovanni Conti, Direktor des Bundesamts für Informatik und Telekommunikation BIT. Und er meint damit auch SAFe.
 
Bei Banken und Versicherungen oder Swisscom ist das agile Framework SAFe sehr verbreitet und Coaches sagen, die entsprechenden Schulungen laufen gut. Auch das BIT setzt jetzt auf SAFe, und dies bei einem grossen wie prestigeträchtigen Programm, nämlich Fiscal-IT. Das Programm will die IT der Eidgenössischen Steuerverwaltung (ESTV) grundlegend erneuern und steht unter verschärfter Beobachtung, ist es doch das Insieme-Nachfolgeprojekt.
 
"Das Prinzip von SAFe in Fiscal-IT funktioniert vereinfacht beschrieben so: Das übergeordnete Ziel besteht und die Anforderungen sind benannt und als User Stories beschrieben", erläutert das BIT in der neuesten Ausgabe der eigenen Kundenzeitschrift 'Eisbrecher'. Wie interpretieren das BIT und die ESTV aber das umfangreiche Framework mit seinen vielen Modulen konkret? Was ist mit HERMES? Im Gespräch konkretisiert Markus Hänsli, stellvertretender Direktor des BIT, den Einsatz.
 
Inside-it.ch: Warum haben Sie SAFe eingeführt?
Markus Hänsli: Wir haben im BIT 2010 in der Software-Entwicklung in einigen Projekten mit Scrum begonnen und es in der Entwicklung von Software erfolgreich eingesetzt. SAFe ist ein weiterer Entwicklungsschritt, um die wachsende Komplexität und Grösse der Projekte zu bewältigen.
 
Wer hat entschieden, SAFe einzusetzen?
Basierend auf dem Antrag der Projektverantwortlichen Fiscal-IT und den guten Erfahrungen mit agilen Methoden beim BIT haben die ESTV und das BIT diese Entscheidung gefällt.
 
Wie ist das Business, also die ESTV, in Fiscal-IT und via SAFe involviert?
Die Business-Owner kommen aus dem Fach. Und im Programme Increment Planning (PI-Planning) sind Product Owner, Business Owner, die BIT-Projektleiter, Scrum-Master, die Entwickler und das System-Team, also die Plattform-Verantwortlichen, im Projekt dabei.
 
Zu welchem Zeitpunkt fallen Entscheide über Anforderungen? Relativ früh oder spät?
Die Prozesse und Grobanforderungen werden zu Beginn definiert, das Team beginnt, wenn es das einzelne Geschäft, beispielsweise die Mehrwertsteuer-Veranlagung, verstanden hat. Anschliessend geht es in die technische Implementierung. Dabei kann es in der Lösungsarchitektur noch Anpassungen geben.
 
Im PI-Planning, wenn die Schnittstellen zu den Kerntechnologien abgesprochen sind und wenn die Arbeitspakete klar sind, ist die Umsetzung dann in der Regel fix.
 
Beim User-Interface können sich die Anforderungen noch später verändern, wenn Nutzererfahrungen vorliegen. Aber wie ein Geschäft funktioniert – und dies ist ein wichtiger Unterschied zur Privatwirtschaft – ist vergleichsweise früh bekannt, weil die Geschäfte durch ein Gesetzeswerk definiert sind. Das ist ein Unterschied zu Projekten im Markt.
 
Wie sieht der Releasezyklus aus? Gehen regelmässig Features in Produktion? Wie oft gehen mindestens fertige Features in eine Staging-Umgebung?
Wir planen zurzeit alle sechs Monate einen neuen Release, gehen damit also zwei Mal pro Jahr in die Produktion. Staging in der Vorproduktion findet natürlich viel öfter statt, in dieser Phase mit jedem Sprint. In dieser Phase wird jedes Programmincrement dem Kunden gezeigt. Umgekehrt führt aber nicht jedes Programmincrement zu einem Release.
 
In der Theorie definiert man möglichst kleine Features und liefert regelmässig signifikanten Mehrwert für Kunden. In welche "Päckli" wird Fiscal-IT portioniert?
Viele Geschäfte werden aktuell durch Fachapplikationen abgebildet, beispielsweise bei der Mehrwertsteuer oder bei der Umsetzung des automatischen Informationsaustauschs mit anderen Ländern. Ein Paket kann auch sein, wenn wir bislang Papier-Dokumente scannen müssen und dann elektronisch weiterverarbeiten. Dies zu digitalisieren ist auch ein Päckli, das signifikanten Nutzen bringt.
 
In der Wirtschaft kann man in der Regel kleinere Pakete schnüren, wir können das wegen der gesetzlich vorgegebenen Rahmenbedingungen nicht beliebig.
 
Gehen Sie priorisiert nach Business-Value vor?
Ja, der Business-Value der Steuerverwaltung liegt jedoch nicht wie bei einem Unternehmen darin beispielsweise neue Märkte zu erschliessen, sondern darin, die Aufgaben effizienter und effektiver durchzuführen. Es wird also in der Regel nach zwei Kriterien priorisiert: Wie lösen wir ein System ab, das am Ende seines Lebenszyklus steht und wo können wir den bisherigen Aufwand reduzieren?
 
Experten sagen, bei SAFe bestehe die Gefahr, dass man am Top-Down-Approach, am traditionellen Management-Denken festhalte. Wie sieht dies bei Ihnen aus?
Wir arbeiten nicht mehr ausschliesslich nach HERMES und reinem Wasserfall-Modell. Die Phasen Realisierung und Einführung werden nach SAFe abgewickelt. Die Kunden, die Business-Owner, steuern die Inhalte in Fiscal-IT. Wir arbeiten also nicht mehr in den klassischen Linienorganisationen, sondern in Rollen. Die Teams sind interdisziplinär zusammengesetzt, die Mitglieder stammen aus unterschiedlichen Linienfunktionen und die Product Owner und Scrum Master leiten die jeweiligen Teams.
 
Welche Entscheidungskompetenzen haben die einzelnen Teams?
Sie entscheiden in der PI-Planung über die zu realisierenden Schritte im Increment, müssen aber innerhalb der Architektur- und Technologie-Vorgaben bleiben. Sie können beispielsweise nicht über die Technologie entscheiden, weil wir deren Anzahl möglichst klein halten wollen.
 
Es gibt Rahmenbedingungen, welche gesetzt sind, wie beispielsweise Technologien, Architekturvorgaben oder betriebliche Aspekte. SAFe soll dazu dienen, agiler vorzugehen und zu lernen. Und wir setzen alles aus SAFe ein, was dem Projekt hilft. Man lernt mit jedem Program Increment, was man besser machen kann und wir werden weiter lernen. Diese Philosophie wird bei uns nun zum Normalfall.
 
Welche Rolle spielen Requirement Engineers bei SAFe bei Ihnen: Werden diese nicht überflüssig?
Sie sind zu Beginn nach wie vor wichtig. Die Kunden müssen in ihrer eigenen Sprache reden können, damit man ihre Anforderungen abholen kann. Und dann müssen Fachleute sie in Requirements umformulieren können. Das ist zu Beginn des Projektes wichtig, wenn der Rahmen abgesteckt wird. Die Methode des Aufschreibens macht auch bei SAFe noch Sinn, aber die Requirement Engineers haben eine andere Ausprägung, indem sie in den Prozess integriert sind.
 
Wer ist die starke Person bei Ihnen, die es laut SAFe-Experten zur erfolgreichen Umsetzung benötigt?
Bei der Entscheidung und Einführung von SAFe müssen starke Persönlichkeiten dahinter stehen. Diese waren in der Einführungs-Phase auch hierarchisch hoch angesiedelt. SAFe wird von beiden Amtsdirektoren gestützt. Und das muss sein, damit SAFe funktioniert. Wir haben mit Scrum angefangen und heute machen wir mit SAFe in Fiscal-IT erstmals einen massiven Schritt über Scrum hinaus.
 
Gibt es bei Ihren Mitarbeitenden noch individuelle Ziele?
Es gibt sie noch, aber die Teamziele werden immer wichtiger. Zum Teil ist dieser Wandel schon gemacht, zum Teil wird er noch kommen. Dies ist Teil des Veränderungsprozesses.
 
Was sind die bisherigen Lehren, die Sie in Sachen SAFe ziehen?
Die Dynamik, die Agilität muss sich durch die ganze Organisation hindurchziehen. Alle in der Organisation müssen Rollen in der agilen Arbeitsweise bekleiden können, auch wenn sie sonst in ihrem Alltag mehrheitlich auf die herkömmliche Weise arbeiten. (Interview: Marcel Gamma)