Hi, herzlich willkommen in dieser kompakten Lektion, in der wir uns mit der kleinsten Skalierung von SAFe beschäftigen.
Welcher Inhalt wird in dieser Lektion behandelt?
Wir sprechen in den nächsten Minuten über:
- die Situationen, in denen sich das Essential SAFe anbietet,
- welche Ebenen es gibt,
- welche Rollen es gibt und welche grundlegenden Aufgaben welche Rolle hat,
- wie sich das Essential SAFe von den anderen Skalierungen abgrenzt,
- welche Teamarten es gibt,
- wir sprechen auch über Sprints und Produkt Inkremente,
- über die Objective, die Vision und die Roadmap,
- auch über den Release Train,
- und über Continuous Exploration, Integration und Deployment.
Doch nun zum Inhalt dieser Lektion:
Wo wird das Essential SAFe angewendet?
Das Essential SAFe findest Du entweder in überschaubaren Unternehmensgrößen mit bis zu etwa 50 Projektteam-Mitgliedern oder abgekapselten Projekten in derselben Größe ohne große Interaktion mit externen Schnittstellen. Diese Skalierung geht im Gegensatz zu Scrum bereits davon aus, dass das Projekt als Programm (hier in der Programm Ebene) angelegt ist und von mehreren Teams (hier in der Team Ebene) mit mehreren Produkten realisiert wird. Aus diesem Grund gibt es einen Program-Backlog und mehrere Team-Backlogs. Alle Teams arbeiten einem gemeinsamen Release Train mit der Gesamtlösung zu. Der Release Train Engineer (auch RTE genannt) koordiniert die Scrum Master und Product Owner der Teams so, dass die abgelieferten Arbeitsergebnisse der Teams zu funktionierenden Releases führen. Zudem verteilt er Good Practices innerhalb von Teams in die anderen Teams und berät die Scrum Master. Der Release Train Engineer in deshalb der Programm-Ebene zugeordnet.
Auf Program Ebene sorgt das Produkt-Management dafür, dass die Produkte der Product Owner eine funktionierende und die Anforderungen erfüllende Gesamtlösung ergeben. Der Systemarchitekt übernimmt die Entwicklung der Lösungs- und IT-Basis für das gesamte Programm, auf der die Teams dann ihre Produkt-Lösungen entwickeln können. Die Business Owner repräsentieren im Projekt die Interessen der Fachbereiche, aber auch kaufmännische Interessen.
Wie wird das Management im Essential SAFe berücksichtigt?
Das Essential SAFe verzichtet auf die Einbindung der obersten Management-Ebene und beinhaltet deshalb auch keine strategischen Lösungsansätze. Zudem geht diese Skalierung davon aus, dass es nur eine zu entwickelnde Lösung gibt und nicht mehrere Lösungen für eine Gesamtlösung notwendig sind. Hier gibt es deshalb keinen Solution Train und auch keinen Value Stream. Im Essential SAFe gibt es nur eine Lösung – den Solution Context.
Im Anhang an diese Lektion findest Du ein PDF im A3-Format mit der Essential SAFe Übersicht. Du kannst Dir das je nach der bei Dir angewendeten Projekt-Skalierung gerne ausdrucken und in Deinem Projektraum als Diskussions- und Erklärungsgrundlage für das Team an die Wand hängen.
Was bedeutet die Vision im SAFe?
Vor einer Lösung ist stets die Definition einer Vision (dem Ziel der zu entwickelnden Lösung), ein grober Plan diese Lösung zu erreichen (die Roadmap) und die Sicherstellung der Infrastruktur (das System Team) für die zu entwickelnde Lösung notwendig. Auch die Anforderungsermittlung ist fest im SAFe-Modell verankert, genauso wie die agilen Prinzipien der Kundenorientierung.
Wie sieht die Lösungsentwicklung im SAFe aus?
Die Lösungsentwicklung erfolgt in Iterationen von mehreren Sprints pro Product Inkrement. Jedem Program Inkrement geht eine PI-Planung (Program Inkrement Planung) voraus – wobei die PI-Planung auch gemeinsam mit der Sprint-Planung vor jedem Einzelsprint erfolgen kann. Über die Vor- und Nachteile dieser Alternativen gehen wir später noch genauer ein. Jedes PI hat auch ein festgeschriebenes Ziel, das in den PI Objectives festgehalten wird, so dass dieses im Verlaufe der Sprints nicht aus den Augen verloren geht. Jedem Sprint folgt die Verifizierung, ob das PI-Ziel noch eingehalten wird sowie eine Vorführung der neu entwickelten Funktionalität gegenüber dem Kunden im laufenden System. Ein oder mehrere Product Inkrements fließen in den Release Train ein – idealerweise in Form eines automatisierten Continuous Integration und Deployment-Prozesses in die Entwicklungs-, Demo-, Test-, Schulungs- und Integrationsinstanz. Zu ausgewählten Zeitpunkten können dann neue Releases ins Produktionssystem deployed werden. Ganz große Schule ist dann natürlich, wenn auch das Deployment von Releases ins Produktionssystem vollautomatisiert und in kurzen Zeitabständen – im Extremfall täglich – durchgeführt wird.
Ist DevOps mit dem SAFe vereinbar?
Da eine Continuous Integration eine enge Zusammenarbeit von Entwicklung mit dem Betrieb der Softwarelösung voraussetzt, ist auch DevOps Bestandteil von SAFe. Dieser Punkt ist so speziell und weitläufig, dass ich an dieser Stelle nicht näher darauf eingehen möchte. Ich plane jedoch in Zukunft einen eigenen Kurs dafür zur Verfügung zu stellen. Im SAFe-Diagramm kannst Du Dir Grundlegendes zu DevOps in SAFe anlesen.
Wird die Qualitätssicherung im SAFe berücksichtigt?
Und zu guter Letzt finden wir in SAFe auch die Qualitätssicherung, in der die Qualitätsbereiche und Testmethoden beschrieben sind – auch ein sehr weitläufiges Thema mit unterschiedlichsten Ansätzen zur Integration in den Projektablauf. Auch darauf gehen wir im Verlauf der Kursreihe noch genauer ein.
Fassen wir nun zusammen, was wir in dieser Lektion behandelt haben:
- wir wissen jetzt, für welche Situationen sich das Essential SAFe anbietet,
- welche Rollen in der Team- und Programm-Ebene ganz grundsätzlich was machen,
- wie sich das Essential SAFe von den anderen Skalierungen abgrenzt,
- dass es neben den Projektteams auch noch Systemteams gibt,
- dass Sprints in Produkt Inkrementen gebündelt und vorher geplant werden,
- dass es den PIs übergeordnet auch noch Objectives, eine Vision und eine Roadmap gibt,
- dass es da so etwas wie einen Release Train, Continuous Integration und Continuous Deployment gibt,
- und dass wir auf die Einzelheiten im Verlauf der Kursreihe noch ganz genau eingehen werden – genau dann, wenn die Themen im Projektverlauf anstehen.
Nachdem wir uns jetzt mit der kleinsten SAFe-Skalierung mit der Programm-Ebene beschäftigt haben, erweitern wir diese in der übernächsten Lektion um die Large Solution-Ebene, in der eine Gesamtlösung aus mehreren Einzellösungen entstehen kann.
Doch zuvor gibt es für Dich wieder eine kleine Überraschung: Die folgende Lektion beinhaltet ein kurzes Quiz, bei dem Du für Dich selbst prüfen kannst, welche Inhalte aus dieser Lektion bei Dir hängengeblieben sind. Ich wünsche Dir dabei viel Spaß, wir sehen uns in der übernächsten Lektion wieder!
