Einleitung 

In einer Welt, die von ständiger Veränderung und wachsendem Wettbewerb geprägt ist, wird Innovation zu einer unverzichtbaren Triebfeder für den Erfolg von Unternehmen. Das Scaled Agile Framework (SAFe) ermöglicht es Unternehmen Innovation zu einem festen Bestandteil der täglichen Arbeit zu machen. Dies gilt natürlich auch für die Weiterentwicklung betrieblicher Prozesse, wie z.B. das Monitoring von der IT Infrastruktur eines Unternehmens. In unseren Projekten haben wir jedoch festgestellt, dass betriebliche Modernisierungen häufig keinen prioritären Stellenwert haben und somit nur selten eingeplant werden können. Daher besteht für die betrieblichen Modernisierungen die Notwendigkeit einen separaten, lokalen Innovationsprozess zu implementieren.

In diesem Beitrag werfen wir einen Blick darauf, auf welchen Grundlagen SAFe basiert und wie sich ein lokaler Innovationsprozess für betriebliche Modernisierungen nahtlos in das SAFe-Konstrukt einfügen lässt. Zudem gehen wir auf die Rahmenbedingungen ein, die notwendig sind um diesen Innovationsprozess zum Erfolg zu führen.

SAFe vs. Scrum

Im Gegensatz zu Scrum, welches agiles Arbeiten auf der Teamebene ermöglichen soll, bietet SAFe eine agile Arbeitsmethode für gesamte Unternehmen an. In SAFe werden agile Arbeitsmethoden demnach auf das gesamte Unternehmen skaliert. Auf der Teamebene innerhalb eines Unternehmens, welches SAFe im Einsatz hat, kann Scrum ebenfalls zum Einsatz kommen. Die beiden Systeme sind also kompatibel resp. ergänzen sich gut. Es ist jedoch in SAFe nicht festgelegt, welche agile Arbeitsmethode auf der Teamebene praktiziert wird. Somit sind andere agile Methoden, wie bspw. Kanban, ebenso möglich. Darüber hinaus

Darüberhinaus besteht ein weiterer Unterschied zwischen SAFe und Scrum darin, dass in Scrum immer nur ein Sprintzyklus geplant wird. In SAFe werden hingegen 4-6 Sprints geplant, welche einen Planning Planning Intervall (PI) -Zyklus darstellen.

SAFe und agile Lernzyklen 

SAFe bietet Unternehmen ein Projektmanagementframework, welches agiles Arbeiten in grösseren Unternehmen ermöglichen soll. Dabei nutzt SAFe den agilen Lernzyklus, der aus der agilen Softwareentwicklung resp. aus Scrum stammt.  

Der Lernzyklus ist als Grundprinzip von SAFe festgehalten ’Principle #4 – Build incrementally with fast, integrated learning cycles'. Mithilfe eines solchen Lernzyklus sollen die erledigten Arbeiten stetig hinterfragt und daraus Verbesserungsmöglichkeiten abgeleitet werden. Diese Verbesserungsmöglichkeiten können dann evaluiert und in der nächsten Iteration des Lernzyklus ausprobiert bzw. Implementiert werden. Somit ist der Innovationsprozess bereits in das Fundament von SAFe eingebettet.  

Praktisch kommen diese Zyklen in SAFe auf allen Ebenen des Unternehmens zum Einsatz. Innerhalb des Teams soll bspw. Scrum dafür genutzt werden, lokale, teambasierte Innovation zu ermöglichen. Auf den Ebenen der Produkte oder Release Trains, sorgt der PI Zyklus für diese Innovation.  

Der innere Kreis der oberen Grafik beschreibt den Sprint Zyklus in Scrum auf Teamebene und der äußere Kreis den PI-Zyklus, welcher 4-6 Sprints umfasst.

 Noch eine Ebene höher sorgen die sogenannten 'Strategic Themes' für die allgemeine strategische Ausrichtung des Unternehmens. Der Erfolg eines 'Strategic Themes' wird mit Kennzahlen gemessen und das Theme stetig aktualisiert, was wiederum einen Lernzyklus darstellt. All diese Lernzyklen basieren auf verschieden detaillierten Informationen, die auf der jeweiligen Ebene zur Verfügung stehen. Hier kommt ein weiteres SAFe Prinzip zum Einsatz: 'Principle #9 Decentralize decision-making'. Damit die Lernzyklen funktionieren, muss der nötige Freiraum existieren, sodass die Innovationsideen auch ausprobiert werden können. Somit sollen die Entscheidungen innerhalb einer Organisation so lokal wie möglich und so global wie nötig getroffen werden. Das bedeutet, es muss eine realistische Perspektive auf den Anwendungsbereich des jeweiligen Innovationszyklus bestehen. An dieser Stelle besteht die Gefahr, dass durch zu globale Entscheidungstätigung die Innovationsfähigkeit des Unternehmens stark reduziert wird. 

Zwischen den Innovationszyklen besteht ein regelmäßiger Austausch in Form von Reviews oder Gremien, damit auch ein Informationsaustausch zwischen den Ebenen in ausreichendem Maße stattfindet. Ein Beispiel hierfür wäre die System Demo, in der mehrmals pro PI der allgemeine Produktfortschritt präsentiert und reviewed wird. 

Epic, Capabilities, Features und Stories 

Die angestrebten Entwicklungen eines Unternehmens sind ebenfalls an die Lernzyklen angepasst und in Epic, Capability, Feature und Story aufgeteilt:

• Epics: Ein Epic beschreibt eine großflächige, signifikante Entwicklungsinitiative, die eine ganze Reihe von Anpassungen bedeutet. Beispielsweise kann die Migration von SAS auf PowerBI, also die Ablösung einer Applikation durch eine andere über ein Epic definiert werden. Ein Epic erfordert die Definition eines Minimum Viable Product (MVP), welches im Rahmen des Epics erreicht werden soll. 

• Capabilities: Aus den Epics können mehrere Capabilities abgeleitet werden. Mit einer Capability soll eine Funktionalität, die mehrere Agile Release Trains (ARTs) umfasst, innerhalb von einem PI umgesetzt werden. 

• Features: Aus den Capabilities können wiederum mehrere Features erstellt werden. Mit einem Feature soll eine Funktionalität implementiert werden, die innerhalb eines ARTs und in einem PI umgesetzt werden kann. Jedes Feature beinhaltet eine Nutzenhypothese (Benefit Hypothesis) sowie Akzeptanzkriterien. 

• Stories: Ein Feature ist gegliedert in ein oder mehrere Stories. Eine Story ist ein kleiner Teil einer Funktionalität, die durch das Feature umgesetzt werden soll. Stories sind aus der Nutzerperspektive geschrieben, betreffen immer ein SAFe-Team und können innerhalb eines Sprints umgesetzt werden. 

Diese Aufgliederung von Arbeiten innerhalb eines Epics, ermöglichen eine lokale Entscheidungsfindung. Beispielsweise wird in einem Feature nicht vorgegeben, wie genau die technische Implementation auszusehen hat.  

Warum ein weiterer Innovationsprozess? 

Lernzyklen kommen innerhalb von SAFe vielfältig zum Einsatz. Warum besteht nun die Notwenigkeit noch einen Innovationsprozess zu implementieren? 

Die oben beschriebenen Zyklen innerhalb von SAFe beziehen sich vor allem auf ‘fachliche’ Aufgabenstellungen. Mit ‘fachlichen’ Aufgaben sind die Aufgaben gemeint, die einen sichtbaren Business Value für das Unternehmen erzeugen (bspw. eine neue Funktionalität in einem Online Service). Diese Aufgaben haben eine globale Relevanz für das Unternehmen und stehen damit im Fokus.  

Im Kontrast dazu stehen betriebliche Aufgabenstellungen (bspw. die tägliche Kontrolle von Loads innerhalb eines Datawarehouse). Für diese Aufgaben wird meist eine feste Zeit pro PI reserviert, da diese Aufgaben nicht planbar sind. 

Nun müssen für das betriebliche Monitoring ebenfalls Prozesse entwickelt werden, damit das Monitoring auch effizient erfolgen kann und zeitnah auf Probleme reagiert wird. Das bedeutet, dass die Monitoringprozesse ebenfalls stetig hinterfragt und weiterentwickelt werden müssen, um eine hohe Ausfallsicherheit zu gewährleisten. Die Optimierung der Monitoringprozesse steht jedoch nicht im Fokus des gesamten Unternehmens sondern ist in der Verantwortung der einzelnen Teams bzw. der jeweiligen Abteilung. Somit muss lokal ein Innovationsprozess etabliert und gelebt werden, der möglichst gut in das SAFe-Konstrukt passt. 

Innovationsprozess für betriebliche Arbeiten 

Betriebliche Arbeiten stehen wie oben bereits beschrieben nicht im Fokus des gesamten Unternehmens sondern müssen durch die jeweiligen Teams / Abteilungen selbstständig organisiert werden. Zumeist führt dies dazu, dass für die täglichen Betriebsaufgaben eine gewisse Zeit reserviert wird und die Weiterentwicklung nur dann angegangen wird, wenn nicht genügend fachliche Aufgaben zur Verfügung stehen.  Dies führt dann wiederum häufig dazu, dass Weiterentwicklungen in diesem Bereich gar nicht angegangen werden, wenn das Team mit fachlichen Aufgaben komplett ausgebucht ist. Langfristig bauen sich hierdurch dann stärkere technische Schulden auf, die wiederum zu regelmäßigen betrieblichen Problemen führen können. 

Folgende Aspekte haben wir für einen erfolgreichen Innovationsprozess identifiziert, um diese Problematik zu entschärfen: 

• Genügend Zeit für betriebliche Innovationen reservieren: Damit Innovation überhaupt erfolgen kann muss ausreichend Zeit reserviert werden, um die Arbeiten auch vornehmen zu können. In SAFe bieten sich hierfür die Innovationssprints an, die am Ende jedes PIs einen solchen Freiraum geben sollen. Alternativ kann pro PI auch eine feste Zeit für Weiterentwicklungen reserviert werden. 

• Organisatorische Rahmenbedingungen schaffen: Es ist wichtig, dass die korrekten Rahmenbedingungen dafür geschaffen werden, dass neue Ideen auch implementiert werden können. Dazu gehört einerseits, dass Verständnis der Wichtigkeit dieser Aufgaben für die Projektmanager oder Business Owner und anderseits eine offene Diskussionskultur über die neuen Ideen. 

• Ideenaustausch etablieren: Fundamental für den Innovationsprozess sind die Ideen wie Prozesse verbessert, automatisiert oder weiterentwickelt werden können. Hierfür bietet sich ein regelmäßiger Austausch in Form einer Reflektion und kritischen Untersuchung der bestehenden Prozesse an. Allerdings haben wir in den Projekten festgestellt, dass die meisten Ideen spontan in Absprachen zu anderen Thematiken aufkommen. Daher ist es wichtig Ideen auch während des Daily Business zu sammeln, um diese dann im Nachhinein evaluieren zu können. Zudem sollte die Möglichkeit für jeden Entwickler geschaffen werden, neue Ideen auf einem zentralen Board festhalten zu können. 

• Transparenz schaffen: Sowohl die Entwickler innerhalb der Abteilung bzw. des Teams als auch die Projektleiter müssen über die aktuell anstehenden Arbeiten sowie deren Fortschritt informiert sein. Um dies zu gewährleisten kann beispielsweise in den Sprint Reviews der jeweiligen Teams über den Fortschritt dieser Arbeiten sowie zukünftig anstehende Arbeiten berichtet werden.  

• Produktziele definieren und priorisieren: Um von den neu eingebrachten Ideen zur erfolgreichen Innovation zu kommen, müssen die Ideen gesammelt und nach Wichtigkeit priorisiert werden. Hierfür bietet sich die Definition von Produktzielen an, die einen Meilenstein in der Entwicklung darstellen. Je nach Aufwändigkeit des Produktziels, kann dieses noch in Etappenziele unterteilt werden. Sind die Produktziele einmal definiert, müssen diese nach Wichtigkeit priorisiert werden. Die Priorisierung hierfür kann wie in Scrum durch den Product Owner oder alternativ über eine Abstimmung aller beteiligten Personen vorgenommen werden. Eine weitere Hilfestellung kann die WSJF-Methode aus SAFe geben. 

• Umsetzungsplan definieren: Sind die Produktziele einmal definiert und priorisiert, muss ein konkreter Umsetzungsplan ausgearbeitet werden. Dieser Umsetzungsplan kann dann in Form von Features in einem separaten Produkt Backlog hinterlegt werden. Die Definition eines Umsetzungsplans kann analog erfolgen wie die Sozialisierung aller anderen Features in SAFe (Stichwort Refinement). Die sozialisierten Features mit Aufwandsschätzungen können dann nach Priorität für das nächste PI eingeplant werden. 

• Erfolge feiern: Ist ein Produktziel oder größerer Meilenstein erreicht worden, ist es wichtig diesen Erfolg zu kommunizieren und ggfs. mit einem Apéro zu feiern. Denn der erfolgreiche Abschluss eines Produktziels zeigt auch den Erfolg des Innovationsprozesses selbst und verstärkt gleichzeitig das Vertrauen diesen Prozess. Das verstärkte Vertrauen wiederum unterstützt die Ideenfindung für zukünftige Innovationen. 

Fazit

Die genannten Aspekte zeigen, worauf es bei einem erfolgreichen Innovationsprozess für betriebliche Arbeiten ankommt. Mithilfe der Rahmenbedingungen von SAFe können diese Elemente gezielt umgesetzt werden. Dadurch werden Risiken minimiert, technische Schulden frühzeitig identifiziert und ein solides Fundament für nachhaltige Innovation geschaffen.