Wie passen das Framework zur Skalierung agiler Organisationen SAFe und DevOps zusammen? Ich habe den DevOps Trainer und SAFe Programm Consultant Falko Werner zu Gast im Podcast. Wir sprechen darüber, wie sich DevOps im SAFe wiederfindet, welche Rollen SAFe kennt und wie agil SAFe wirklich ist.
In dieser Episode diskutieren die Gastgeber und der Experte Falko Werner über die Grundlagen und Anwendungen von DevOps und SAFE. Werner definiert DevOps als eine Bewegung zur Optimierung der Lieferung von Kundennutzen und beschreibt SAFE als ein Framework zur Skalierung von Agilität in großen Organisationen. Die Diskussion beinhaltet Details zu verschiedenen Rollen innerhalb des SAFE-Frameworks, die Integration von DevOps-Prinzipien in SAFE, und die Bedeutung von Agilität auf Unternehmensebene. Darüber hinaus werden die Herausforderungen und Vorteile der Anwendung dieser Frameworks in großen Unternehmen sowie die kontinuierliche Entwicklung und Anpassung von SAFE anhand von Marktfeedbacks erörtert.
Inhalt
- Einleitung und Vorstellung von Falko Werner
- Definition und Erklärung von DevOps
- Vorstellung des SAFE-Frameworks
- Integration von DevOps-Prinzipien in SAFE
- Rollen und Struktur im SAFE-Framework
- Agile Methoden und deren Anwendung in großen Unternehmen
- Diskussion über die Entwicklung und Anpassung von SAFE
- Bedeutung von Training und Zertifizierungen im Kontext von SAFE und DevOps
- Diskussion über die Bedeutung und den Nutzen von Frameworks
- Agile Prinzipien und ihre Umsetzung in SAFE
- Abschluss und Ausblick auf zukünftige Themen
Shownotes
Webseite von Falko Werner
Webseite des SAFe Frameworks
Transkript (automatisiert erstellt, daher keine Gewähr 🙂 )
Hallo und herzlich willkommen zum Podcast DevOps auf die Ohren und ins Hirn.
Wir haben heute zu Gast Falko Werner und haben zum Thema Safe und DevOps.
Wie weit reicht die Continuous Delivery Pipeline?
Ja, die, die den Podcast regelmäßig hören, wissen, dass ich eigentlich gar nicht großartig Vorgeplänkel mache,
dass ich gar nicht großartig im Vorfeld etwas sage, sondern gerne zu meinem Gast überlenke.
Also insofern, Falco, ich würde sagen, stell dich einfach mal vor.
Ja, hallo an alle Zuhörer. Ich bin Falco Werner.
Ich bin Scrum Master in verschiedenen Projekten, bin als Trainer im Umfeld von Scrum,
und DevOps und auch Safe neuerdings ziemlich aktiv und freue mich, hier eingeladen zu sein, Dirk.
Sehr schön. Ja, eingeladen als Experte für das Thema Safe.
Safe werden wir gleich noch uns ein bisschen anhören.
Und im Titel haben wir auch drinstehen Safe und DevOps.
Und auch da wieder die Zuhörer, die den Podcast regelmäßig hören, wissen,
die erste Frage an meine Gäste ist immer,
wie definierst du DevOps? Falco, wie würdest du DevOps beschreiben oder definieren?
Ja, das ist natürlich eine interessante Frage, weil so richtig definieren tue ich mich wirklich schwer.
An sich könnte man sagen, DevOps ist Agilität auf Enterprise-Niveau oder Agile 2.0,
wenn wir in der Nomenklatur bleiben.
An sich ist es eine Bewegung zur Optimierung der Lieferung von Kundennutzen.
Letztendlich vom Kunden gedacht, über den gesamten Prozess wieder bis zum Kunden,
zurück von der Anforderung bis zur Lösung.
Und da spielt letztendlich die Business-Seite, Fachbereiche, Architektur, Entwicklung,
Qualitätsmanagement, Security, Privacy, Operations, der Betrieb und letztendlich Kundenservice
alle mit rein, sodass man sagen kann, es ist eine lange Schleife.
Ansonsten so die klassischen Definitionen in Richtung Culture, Agile, Lean, Measuring,
und Sharing mit dem Akronym CALMS ist eine Richtung.
Und ja, wer eine Definition will, kann natürlich gerne auch in der Wikipedia nach SAFE und DevOps schauen.
Da finde ich letztendlich relativ gut beschrieben, so ein Stück DevOps, eine Engineering Culture,
also eine Kultur und Praktiken, die darauf hinarbeiten, sowohl Softwareentwicklung als auch Betrieb zusammenzubringen.
Das ist quasi der erste Schritt.
Und wenn man es im Ganzen betrachtet, halt den gesamten Prozess mit allen Beteiligten so einfach,
so hoch automatisiert zu bekommen, dass man den Kundennutzen möglichst schnell zu der Anforderung entsprechend liefern kann.
Finde ich immer wieder interessant bei diesen Fragen, wie lang dann doch die Ausführungen sind,
also wie viel dann doch rüberkommt und wie viele Erklärungen man dazu braucht.
Also mir geht es ja auch so, es gibt ja nicht einen Satz, wo ich sage,
jetzt DevOps könnte man bringen, aber das ist dann immer ein ziemlich allgemeingültiger,
hochtrabender und dann auch gleichzeitig nichtssagender Satz.
Also insofern hast du ja ein paar Auswahlpunkte gebracht und ich denke,
das Thema Kundennutzen und Wertstrom oder gesamte Lieferkette,
ja, finde ich einfach sehr, sehr interessant, würde ich auch zustimmen.
Gut, jetzt haben wir ja im Thema oder im Titel stehen SAFE und DevOps
und kommen wir dann quasi zu der zweiten Frage.
Was ist denn SAFE?
Also warum haben wir in diesem Podcast SAFE und DevOps als Themen oder als Frameworks aufgeführt?
Was ist SAFE?
Na gut, fangen wir letztendlich mal an.
Also SAFE ist ein Framework für skalierte Agilität, Scaled Agile Framework
und ein E letztendlich im Rahmen des Akronyms, damit es sich sicher anfühlt.
Also für das Management ausreichend viele Artefakte, Erfahrungen, Best Practices,
die dann zusammengeführt worden sind zu einem großen Framework.
Das hat letztendlich Dean Leffingwell im Umfeld von Nokia entwickelt.
Es gab an sich die Frage, wie bekommt man die Gedanken, Erfahrungen, die positiven Ergebnisse,
die man mit agilen Frameworks wie Scrum auf Team-Ebene hat, auf ein Enterprise-Niveau gehoben.
Deswegen auch bei der Antwort auf die Frage, wie definiere ich DevOps, Agilität auf Enterprise-Niveau.
Das heißt, in einem Umfeld, wo es nicht nur ein Team, nicht nur fünf oder zehn Teams gibt,
sondern wo letztendlich Organisationen in Größenordnung von tausenden Leuten
an verschiedenen Projekten, Solutions, Produkten und Services arbeiten,
wie bekommt man die letztendlich so zusammengestellt, zusammenorganisiert,
dass sie die gleichen Effekte, die man auf Team-Ebene mit Scrum erreichen kann,
in solch einer Umgebung auf die Welt loslegen.
Da gibt es letztendlich das Framework, gibt es eine Seite auch im Internet,
die sehr viel Hintergrundinformationen dazu gibt, scaledagile.com.
Und da gibt es dann halt verschiedene Beschreibungen für Rollen, für Zusammenarbeitskonstrukte
wie einen agilen Release Train, den man wieder zusammenfasst zu verschiedenen agilen Solution Trains,
die dann halt in einem Portfolio.
Also in einem Lean-Portfolio gemeinsam an den Kundenlösungen arbeiten.
Okay. Jetzt hast du eben gesagt, im Umfeld von Nokia ist das entwickelt worden.
Jetzt könnte man, wenn man ja böse wäre, sagen, das kann es ja nichts gewesen sein,
weil Nokia gibt es ja nicht mehr in der Form.
Das ist ein naheliegender Gedanke, aber grundsätzlich ist auch da viel gelernt worden.
Und das Gelernte dann halt übertragen, angepasst, erweitert.
Und SAFE ist ein Framework, was sehr viel auch Interaktion mit den Anwendern betreibt,
sehr viel Feedback auch aufnimmt und regelmäßig Veränderungen vornimmt.
Und die Dinge, die aus dem Nokia-Umfeld gelernt worden sind,
die Dinge, die aus vielen anderen Konzernumfeldern gelernt worden sind,
sind natürlich dann auch in das Framework eingeflossen.
Jetzt kann man das natürlich negativ sagen.
Okay, SAFE und Nokia und lass das sein.
Andererseits ist es halt ein sehr weit verbreitetes.
Es ist ein Framework am Markt mit ca. 30% Marktanteil an agilen Skalierungsframeworks.
Ist das größte von denen.
Es gibt halt verschiedene andere, aber ich glaube, da kommen wir später noch drauf zu sprechen.
Und ist jetzt in der Version 4.6 aktuell quasi als Framework nutzbar.
Im Laufe des Jahres wird man die nächste Versionsstufe angehen.
Version 5.0, eine Komplettüberarbeitung.
Und auch da werden wieder viele neue Dinge,
die aus den ganzen Unternehmen, die das anwenden, wieder zurückgetragen werden, eingearbeitet.
Und aus dem Grund sehe ich es als relevant.
Einerseits, weil es am Markt relevant ist.
Und andererseits, weil halt viel Gelerntes auch quasi in das Framework eingeflossen ist.
Jetzt hast du gesagt, das ist Skalierung oder Skalieren von Scrum.
Wenn ich das so richtig weiß, dann ist gerade in der Version 4.6
sehr viel mehr auch in Richtung Lean und Kann-Man passiert.
Genau.
Also wie viel Scrum steckt drin, wie viel Kann-Man steckt drin
und wie viele andere Dinge stecken da drin aus dem agilen Umfeld?
Ja, letztendlich alles Gute steckt da drin, kann man jetzt so sagen.
Ist vielleicht ein bisschen flach und einfach geantwortet.
Generell ist es so, dass auf der Team-Ebene für gewöhnlich den Teams freie Hand gelassen wird,
in welchem agilen Framework sie sich am wohlsten fühlen,
was mit ihren Arbeitsweisen am besten übereinstimmt.
Aber…
Aber üblicherweise geht man davon aus, dass man Scrum auf der Team-Ebene einsetzt.
Wenn das nicht der Fall ist, dann halt auch gerne Extreme Programming, XP oder ein Kann-Man.
Wobei Scrum ist ja auch nur eine Form von Kann-Man.
Insofern gibt es da viele Freiheiten.
Und wie man dann diese Teams mit anderen Teams zusammenbringt,
da setzt letztendlich erst das SAVE-Framework an,
wie man die Skalierung auf die Beine stellt.
Jawohl.
Das heißt, SAVE lässt den…
Die Teams freie Hand, weitgehend freie Hand.
Klar, es muss ja wahrscheinlich ein paar Vorgaben geben,
aber an sich lässt es ihnen freie Hand.
Und die Teams entscheiden dann selber, wie sie arbeiten.
Aber die Prinzipien, die Ideen von Agilität, die werden eben auf Enterprise-Niveau angehoben.
Genau.
Okay, ja, jetzt haben wir die beiden Titelgeber, die beiden Namensgeber für den Titel erklärt.
Du hast DevOps definiert, du hast SAVE im Groben zumindest mal erklärt.
Wie hängen denn die beiden zusammen?
Die müssen ja zusammenhängen, sonst hätten wir ja diesen Titel ja nicht gewählt.
Ja, können wir gerne so sehen.
Letztendlich ist SAVE als Skalierungs-Framework offen für viele Einflüsse.
Und ein Einfluss kommt aus dem DevOps-Umfeld.
Und letztendlich ist eines von den Zielen im SAVE-Umfeld,
Produkte auf den Markt zu bringen, sie releasefähig zu bekommen.
Und man geht davon aus, dass man üblicherweise das nicht auf dem Team-Level schafft,
also in einer Größenordnung von sieben Team-Mitgliedern,
plus minus zwei Produkte auf Enterprise-Niveau auf die Straße zu bringen,
dass man da mehrere zusammenarbeiten lässt und dann auf der Ebene drüber sagt,
da liegen die Produkte.
Und die Produkte sollen halt releasefähig sein,
sie sollen schnell anpassbar und erweiterbar sein.
Und da nutzt man letztendlich die Einflüsse, die man aus den Erfahrungen von DevOps hat,
sowohl das Zusammenbringen von Team-Mitgliedern,
mit einem größeren Fokus auf Entwicklung,
andere Team-Mitglieder mit größerem Fokus auf Betrieb,
vielleicht auch einige aus dem Bereich Security oder Datenschutz oder ähnliches,
Architekten und Fachbereiche,
und bringt diese in einem Art von Release-Train,
Agile Release-Train oder Solution-Train entsprechend zusammen, um dann Produkte zu bringen.
Das heißt, in diesem SAVE-Framework gibt es ein großes Big Picture,
also ein großes Diagramm, wo man versucht, alle Ebenen so ein Stück darzustellen.
Und da platziert man DevOps als eine Kernfähigkeit auf der Produktebene
an der Grenze zwischen der Team-Ebene und dem Portfolio.
Du hast eben gesagt, dass SAVE sehr stark davon lebt,
dass es auch die Erfahrungen aus dem Markt zurückbekommt und einarbeitet.
Das heißt, auch das wäre jetzt ein Beispiel dafür,
dass die DevOps-Erfahrungen aus dem Markt dann sich in SAVE-Train quasi wiederfinden,
also entsprechend eingearbeitet werden.
Ist das richtig?
So kann man das sehen.
Letztendlich gibt es dann auch so ein Stück Umdeutung oder Erfahrungen,
die man halt in Projekten gemacht hat, die man versucht, in das Framework einzubringen.
So ähnlich, wie ich es vorhin am Rande der Definition von DevOps gesagt habe,
dass man so ein Akronym CAMS, Culture, Agile Lean, Measuring und Sharing hat,
sagt SAVE, wir haben so viel Sharing, wir brauchen das nicht speziell in diesem Akronym für uns.
Wir nehmen letztendlich so ein Element Recovery,
machen statt CAMS, CALMER.
Es gibt letztendlich auch Schulungen, die das SAVE-Framework mitbringt
oder die man im Rahmen des SAVE-Frameworks betreiben, erweitern und nutzen kann.
Da gibt es zum Beispiel auch eine Zwei-Tages-Workshop zum Value-Stream-Analyse,
Value-Stream-Mapping, einen Health-Check, einen DevOps-bezogenen Health-Check
auf so einen Agile-Release-Train, also eine Zusammenfassung von mehreren Teams,
wie diese zusammenarbeiten, wie man gemeinsam releasen kann.
Das sind letztendlich alles Dinge, die dort mit reinfließen, die auch so einen Austausch ermöglichen.
Du hast jetzt ja eben verschiedene Angebote angesprochen.
Wie muss ich mir das vorstellen?
Also wenn ich jetzt mal auf die Frameworks schaue, die ich so kenne,
in der alten Version, das waren 2000 Seiten, das waren fünf Bücher.
Ich kenne Scrum, das sind 17 Seiten Scrum Guide, quasi von der Quelle her.
Wie muss ich das machen?
Wie muss ich das machen?
Wie muss ich das machen?
Wie muss ich das machen?
Wie muss ich das machen?
Wie muss ich das machen?
Wie muss ich das machen?
Wie muss ich das machen?
Wie muss ich mir vorstellen, wie ist SAFE beschrieben?
Wie komme ich als Kunde an das SAFE-Wissen?
Der erste Ansatz ist, auf der einen Webseite, wenn wir jetzt auf Zahlen gehen,
scaledagile.com, sich diese Beschreibung des Frameworks näher anzuschauen.
Da gibt es letztendlich sehr viel auch Informationen dazu, die man sich durchlesen kann,
die man versuchen kann, auf sein Unternehmen zu übertragen.
Man kann den nächsten Schritt gehen und sagen, man lässt sich,
entweder öffentlich oder halt auch in Firmen, entsprechend schulen.
Da gibt es Trainer am Markt, die das anbieten.
Man kann da mit verschiedenen Trainingsorganisationen zusammenarbeiten.
Man kann selbst zum Trainer werden, indem man eine Schulung zu dem Framework
als SAFE-Programm-Consultant zum Beispiel macht, um befähigt zu werden,
um die verschiedenen Bereiche, wie zum Beispiel,
den gerade erwähnten Zwei-Tages-DevOps-Schulungs-Workshop,
den Architektur-Training, ein Team-Training, SAFE for Teams gibt es zum Beispiel,
die letztendlich alle in verschiedenen Unternehmen mit anbieten
und dann auch als offene Trainings alternativ am Markt anzubieten,
um das SAFE-Wissen dann auch zu verteilen und zu verbreiten.
Das sind so die Ansätze, die relevant sind.
Es gibt natürlich auch…
Bücher von den SAFE-Erfindern, sage ich jetzt mal,
oder SAFE-Wissenszusammenträgern, sind verschiedene Ansätze,
die man da wählen kann am Markt.
Aber das heißt im Prinzip, es gibt Trainings, es ist ein umfangreiches Schulungsangebot.
Ich kann mich auf der Webseite informieren.
Das ist das, wie ich an die originäre Literatur von SAFE komme.
Natürlich gibt es Bücher und andere Themen,
aber originär quasi Schulungen und das, was auf der Webseite steht.
So habe ich es.
Das habe ich bis jetzt verstanden.
Wir haben ja das Thema, so wie du es jetzt dargestellt hast,
oder ist ja aus meiner Sicht DevOps quasi ein Teil von SAFE.
Wenn ich mir das so bildlich vorstelle, da gibt es irgendwo DevOps-Teams,
oder da steht DevOps ja quasi etwas über der Team-Ebene.
Gibt es denn irgendetwas oder irgendjemanden,
der in SAFE dann quasi für DevOps zuständig ist?
Gibt es irgendeine DevOps-Rolle, eine spezielle oder mehrere DevOps-Rollen?
Wie vorhin in der Definition gesagt, ist ja DevOps keine…
Also ich habe es zumindest nie als Rolle verstanden.
Es gibt auch Organisationen, Trainings, die DevOps als Rolle verstehen,
dann aber mehr mit dem Fokus rein Automatisierung.
Bei SAFE ist es nicht so.
SAFE ist letztendlich als Framework bezogen auf DevOps mit dem Blick unterwegs,
zu sagen, das ist die Optimierung des gesamten Lieferprozesses
und bezieht halt nicht nur die initiale Stufe Entwicklung und Betrieb,
zusammenzubringen, sondern halt alle an dem Lieferprozess Beteiligten
zusammenzubringen mit einem.
Gibt es denn in SAFE auch bestimmte Rollen, also DevOps-Rollen,
wo ich wirklich konkret einer Person oder einer Rolle Aufgaben zuschreibe
in diesem SAFE-Framework?
Weil mein Verständnis ist ja immer noch, dass ich DevOps als einen Teil darin habe
und meistens gibt es ja in solchen Frameworks immer irgendwelche Rollen
und irgendwelche Verantwortlichkeiten.
DevOps hat viele Rollen.
Viele haben letztendlich einen Einfluss oder einen Bezug zu DevOps.
An sich ist der DevOps-Gedanke in allen Teams beheimatet.
Das heißt, die Teams sollten fähig sein, ihre Artefakte zu liefern,
ihre Artefakte automatisiert zu liefern, automatisiert testen zu lassen.
Um das zu unterstützen, sind die Architekten,
also in dem Fall auf der ersten Ebene über dem Team,
ist der Systemarchitekt, darüber dann Solution- oder Enterprise-Architects,
die letztendlich das Ganze mit unterstützen.
Gegebenenfalls auch in der Zusammenarbeit
auf einer eher operativen, wissensaustauschbezogenen Ebene.
Da werden in SAFE oft Communities of Practice eingesetzt,
um so einen Austausch zu ermöglichen.
Und auch so ein Release-Train-Engineer ist letztendlich mit in der Verantwortung,
mit den Teams zusammen dorthin zu arbeiten.
Das ist ein guter Fluss.
Durch alle beteiligten Teams, alle Beteiligten gibt
noch ein SAFE-Programm-Consultant ist letztendlich dort in dem Bereich mit aktiv.
Das heißt, ich habe Systemarchitekten, ich habe Solution-Architekten
und diesen Release-Train-Engineer, die quasi als Rolle über den Teams stehen
oder mit den Teams gemeinsam etwas zu tun haben,
aber die dann auch das Thema DevOps und das Thema Skalierung
verantworten und unterstützen.
Ja, mehr unterstützen, verantworten.
Schon auf der Team-Ebene.
Okay, also die Verantwortung bleibt bei den Teams, sie unterstützen entsprechend.
Jetzt haben wir ja schon über das Thema DevOps gesprochen
und du hast ja auch in deiner Definition oder in den verschiedenen Definitionen auch angeführt,
dass es sehr umfangreich sein kann.
Mein Verständnis von DevOps ist ja, dass ich da ein bisschen Scrum habe,
ein bisschen Kanban, ein bisschen ITIL, vielleicht auch ein bisschen COVID mit reinpacke.
Also das finde ich das Smarte an DevOps, also an meinem Verständnisverhältnis.
Von DevOps, dass ich einfach die verschiedenen Frameworks, die es dort gibt,
bestmöglich für mich zusammenbaue.
Wie ist das in SAFe?
In SAFe ist es so, dass man DevOps als Element sieht,
das für eine Enterprise-Agilität hilft, einen durchgängigen Fluss zu generieren,
einen durchgängigen Fluss von der Anforderung bis zur Lösung für den Kunden.
Und SAFe ist da letztendlich im Bereich,
eine zweite Skalierung im Framework, das ähnlich verwendet werden kann wie LESS.
Ja, die klassischen großen Skalierungsframeworks, weniger verbreiteter Markt,
sind dann auf Scrum.org basierend Nexus oder ursprünglich aus dem IBM-Umfeld stammend,
aber mittlerweile als Eigenständeorganisation am Markt tätig.
Disciplined Agile, Disciplined Agile Delivery als Kern.
Mit auch einem relativ umfangreichen Framework.
Und auch im SAFe-Umfeld bedient man sich halt verschiedenen anderen Themen,
zum Beispiel DevOps.
Unterstützend würde aus der Architektur zum Beispiel so ein Framework wie TOGAF,
im Compliance-Umfeld COBIT, bei den Prozessen FITSM,
so dein Steckenpferd oder auch ITIL.
Und ansonsten im Technologie-Umfeld natürlich von den Herstellern verschiedene,
Frameworks, Prozesse, Schulungen, Ausbildungen im AWS-Umfeld bei Azure oder von der Google Cloud
oder allgemeiner, so ein bisschen herstellerunabhängig mit Cloud Council,
die letztendlich auch mit anbieterunabhängigen Technologieschulungen am Markt sind.
Wenn man das alles zusammenfasst, hat man natürlich ein Riesenportfolio.
Da kann man sich auch ein Stück drin verlieren, aber es ist auf jeden Fall viel Wissen vorhanden.
Die Frage wäre natürlich dann in die Richtung, wie bekommt man,
da einen Überblick oder wie schafft man es, in diesem Wust genau das zu finden, was man braucht.
Das wäre jetzt auch meine nächste Frage gewesen.
Wenn wir erstmal auf SAFE gucken, schafft SAFE schon das Zusammenführen
dieser verschiedenen Ansätze und Frameworks?
Also hat SAFE das überhaupt als Ziel für sich formuliert?
Also soweit es mir bekannt ist, ist das Ziel von SAFE, sich auf die Skalierung zu fokussieren,
Unternehmen soweit zu befähigen.
Und zu unterstützen, dass sie eine Chance haben, in einem Umfeld,
das halt viele Teams, vielleicht viele Teams von Teams,
kundenfokussiert, lösungsorientiert arbeiten zu lassen.
Das heißt, an sich ist dann SAFE nur eins von vielen Frameworks auf der Skalierungsebene.
Und die anderen Bereiche, die ich gerade erwähnt habe, haben halt auch eine Einwirkung darauf.
Aber SAFE führt jetzt nicht alle Themen zusammen.
Zusammen, auch wenn es sich aus vielen Bereichen wie DevOps, wie Scrum, wie Compliance bedient.
Okay, das heißt also, wenn ich da einen Überblick bekommen will,
gibt es in dem DevOps-Umfeld einen Ansatz, um das zusammenzubringen.
Weil da habe ich auch gesagt, das ist ja für mich der gleiche Ansatz.
Also wo habe ich eine Chance, überhaupt einen Überblick zu bekommen?
Wie arbeiten die einzelnen Systeme zusammen, die einzelnen Frameworks?
Wo hängen sie zusammen? Wo überschneiden sie sich?
Also gibt es da noch einen Ansatz dazu?
Also einen interessanten Ansatz, den die DevOps Agile Skills Association gerade entwickelt
oder versucht auch zu platzieren, ist basierend auf dem DASA-Kompetenzmodell
verschiedene Schulungen von verschiedensten Anbietern, Framework-Anbietern,
Technologie-Anbietern, Schulungs-Anbietern, Prozess-Anbietern in ein Modell zu bringen,
zu bekommen, nennt sich dann DevOps Skills Map.
Das ist ein Trademark.
Und da werden gerade, ja, zumindest schon eine Zeit lang am Markt
verfügbare mit Zertifizierung hinterlegte Schulungen gegenübergestellt.
Und anhand dieses Kompetenz-Frameworks mit vier Soft- und acht Hard-Skills,
die für DevOps relevant sind, entsprechend bewertet auf einer Skala von 1 bis 5,
wie weit diese jeweilige Schulung aus dem einen oder anderen Framework
entsprechend des Kompetenz-Frameworks der DASA Wissen liefern.
Das heißt also, da gibt es ein paar Links, die packe ich dann in die Shownotes,
dass man da nochmal nachlesen kann und das ein bisschen verfolgen kann.
Und du hast es, glaube ich, gesagt, bei dieser Initiative der DASA bist du auch mit dabei,
also dass du dort mit zusammenträgst.
Genau. Also ich habe mich jetzt ein Stück auf die Save,
auf Rollen und Save-Trainings sowie auf die Scrum.org-Trainings und Zertifizierungen,
die es dort gibt, gestürzt.
Es gibt dann verschiedene andere Unternehmen und Beteiligte,
die sich dann auf zum Beispiel Technologien oder andere Prozesse,
zum Beispiel ITIL oder andere Skalierungs-Frameworks wie LESS oder Nexus dann
und ihren Schulungen, die es dort gibt, entsprechend fokussieren.
Um dann mal einen großen Überblick über den Schulungsmarkt,
der in irgendeiner Form Relevanz oder Bezug zu DevOps hat, zu bekommen.
Also ich finde es sehr interessant und deswegen unterstütze ich auch diese Initiative.
Insofern ist da da ein bisschen Leben drin und dann kann ja der Link in den Shownotes
sich quasi auch entwickeln oder das, was hinter dem Link dann entsprechend steckt.
Genau. Das ist jetzt die ersten, glaube ich, zehn Schulungen auf der DevOps-Seite,
auf der DevOps-Webseite entsprechend veröffentlicht werden sollen.
Ich weiß nicht genau, wann das der Fall sein wird.
Wir arbeiten gerade in der Größenordnung von 100 bis 200 Schulungen.
Also da kommt noch eine ganze Menge nach.
Ich kenne das. Ich habe das im anderen Umfeld auch mal getan,
dass wir auch versucht haben, so etwas zusammenzubringen, zu vergleichen,
eine Übersicht zu erstellen.
Das ist schon eine Menge Arbeit, weil man ja nicht einfach nur irgendwelche Überschriften nehmen kann.
Also da muss man ja schon ein bisschen genauer reinschauen.
Also ja, viel Spaß weiterhin.
Ich bin gespannt, was dabei dann auch rauskommt.
Jetzt hast du ja wirklich viele Frameworks aufgezählt.
Ihr bringt die zusammen. Ihr macht einen Überblick dazu.
Jetzt könnte man ja, wenn man nur böse wäre, sagen, es gibt viel zu viele Frameworks.
Oder wie ich es sage, es gibt genug Frameworks. Wir müssen sie nur anwenden.
Also vielleicht können wir nochmal ein bisschen über das Thema,
den Nutzen von Frameworks sprechen.
Aus deiner Sicht, aus meiner Sicht.
Was bringen denn?
Was bringen diese Frameworks überhaupt?
Aus meiner Sicht entwickeln sich Frameworks aus guten Erfahrungen, die man gemacht hat.
Wenn man sie in verschiedenen Bereichen anwendet, werden sie reifer.
Man kann letztendlich aus den Themen, die so ein Framework mitbringt,
für sich selbst etwas lernen.
Man kann Ideen bekommen, die vielleicht andere schon in die Tat umgesetzt haben,
die ihnen was gebracht haben.
Man kann sich da letztendlich von bedienen.
Sie bringen oft Ressourcen.
Also Erfahrungen, Dokumente, Best Practices, Erfahrungsberichte von anderen Unternehmen,
die es eingesetzt haben, und eine Form von Verständnis mit.
Sie bieten dann darüber hinaus eine Plattform zum Erfahrungsaustausch.
Also bei vielen Frameworks, die weitläufig im Einsatz sind, auf Team-Ebene Scrum,
auf Enterprise-Ebene, DevOps oder Save oder Less, haben letztendlich auch Communities,
die dort da sind, um voneinander zu lernen, miteinander zu lernen.
Es gibt zum Teil weltweite Konferenzen oder regionale Konferenzen zum Austausch.
Und dieses Miteinander und Voneinanderlernen, das sind Dinge, die man vielleicht ohne die Frameworks
so in der Form auf klassischen Konferenzen vielleicht so gar nicht erleben würde
oder gar nicht mitbekommen würde.
Das sind für mich letztendlich die Dinge, die so ein Framework im Großen mitbringen.
Eine Plattform, auf der ich auch ganz gern unterwegs bin, ist die von Michael Cohn eingerichtete
Agile Mentors Community.
Das ist ein amerikanisches Projekt, um Scrum Master zum Beispiel zusammenzubringen
mit Product Ownern und Erfahrungen auszutauschen zu verschiedenen Themen.
Da gibt es zum Beispiel auch einen Buchclub, wo einmal im Monat ein Buch gemeinsam gelesen
und vorgestellt wird.
Dann gibt es oft eine Videokonferenz am Ende des Monats.
Mit dem Autor, man kann den Autor mal persönlich kennenlernen, man kann auch mal eine Frage
zu dem Buch stellen.
Das sind alles Themen, die im Rahmen von so Frameworks entstehen und sich entwickeln
und wirklich interessant sind.
Da, wo Menschen zusammenarbeiten, teamübergreifend, unternehmensübergreifend, macht halt auch
so eine Motivation aus, bringt auch Spaß, bringt Drive-In auch in Unternehmen von außen rein,
dass man an sich…
Erstmal mit dem Framework selbst, vielleicht gar nicht erreicht hätte, aber mit dem Austausch,
mit den Erfahrungen, mit dem Miteinander, seine gelernten Themen mit anderen Unternehmen,
unternehmensübergreifend zu verbreiten, ist natürlich fast, wenn man sich jetzt mal an
Gene Kims drei Wege erinnert, fast sowas wie ein vierter Weg, nachdem man halt so das
ersten Weg Flow im Unternehmen, zweiten Weg Feedback schleifen, aufbauen, dritten Weg
Unternehmensintern.
Ja, unternehmensintern voneinander zu lernen, zum Beispiel übergreifend über Teams oder
übergreifend über Abteilungen oder Bereiche, jetzt als vierten Schritt quasi das Ganze
über die Unternehmensgrenze hinaus zu treiben und unternehmensübergreifend zu lernen.
Das ist für mich so ein nächster Effekt, den man letztendlich mit Frameworks wie Safe
oder Less oder Scrum oder DevOps halt wirklich in die Welt bringt.
Die man erleben kann.
Ja, du hast es ja gesagt, das könnte man ja auch machen, wenn man das ohne solche Frameworks
macht.
Meine Erfahrung ist aber dann, es hilft immer, wenn man jemanden dabei hat, der das Ganze
organisiert, der das antreibt, der quasi schon ein Eigeninteresse daran hat, dass das stattfindet
und von daher auch ein bisschen startet und mit unterstützt an der Stelle.
Ja, das hat man halt mit den Frameworks.
Eine klare Zeit man da als Unternehmen so ein Stück auch für, für die Zertifizierung,
für die Trainings.
Und Ähnliches.
Aber man kommt auch eine ganze Menge zurück.
Okay, Falko, jetzt haben wir ein bisschen über die Frameworks gesprochen, über Vorteile,
über Safe und über DevOps, was in Safe drin steckt.
Jetzt kommt noch ein Punkt, den ich immer mal wieder höre und dann gibt es Leute, die
sagen, dieses A in dem Scaled Agile Framework, dieses Agile, das ist falsch da.
Also das ist gar nicht agil.
Was denkst du denn darüber?
Wie agil ist denn Safe?
Ja, Safe ist letztendlich ein relativ detailliertes Framework, das ziemlich viele Vorgaben macht.
Zum Beispiel, wie man ein Portfolio aufbaut, wie man Teams in agilen Release Trains, wie
Safe das nennt, zusammenfasst, wie man diese agilen Release Trains in Solution Trains zusammenfasst.
Es hat ein relativ enges Framework, was Zeiten angeht.
Sowas wie teamübergreifende,
Iterationen, eine Kadenz mit, auch vorgeschlagen, zwei Wochen im besten Fall, vielleicht auch
drei Wochen, sodass man in diesem Rhythmus gemeinsam getaktet arbeitet, ist halt sehr
preskriptiv.
Ist aber ein guter Ansatz, um überhaupt in das agile Leben, Denken und Planen reinzukommen.
Es gibt im Safe-Umfeld ein Programmingrement Planung.
Das ist eine Big Room Plan.
Planning-Veranstaltung, eine üblicherweise Zwei-Tages-Veranstaltung, wo ein ganz agiler
Release Train, also irgendwo so in der Größenordnung 50 bis 120, 130 Teammitglieder in einem großen
Raum, vielleicht auch mit Räumen drumherum, um mal ein bisschen Ruhe zu haben und Themen
an der Seite zu diskutieren, aber in einem großen Raum zusammenkommen, an zwei, zweieinhalb
Tagen, wo sie dann einen Zeitraum von vier,
fünf, sechs Sprints gemeinsam planen.
Und das ist natürlich ein Zeitraum, den man dann entsprechend überdenken muss, wo dann
die Reaktion, was das Agile ja ausmacht, auf den Markt reagieren können, eingeschränkt
ist.
Und je nachdem, wie viel Details man dort schon plant, umso weniger Zeit und Fähigkeit
auf Veränderungen am Markt zu reagieren, hat man natürlich.
Das heißt, man plant auch bis zu einem Vierteljahr.
Das ist jetzt nicht so weit weg von einem Wasserfall, auch wenn da Projekte eher so
in drei Jahre geplant werden und dann Releases so halbjährlich laufen.
Und SAFE hat im Gegenzug gesagt, man sollte halt schon innerhalb so einem Programm-Inkrement,
also so einem Vierteljahr, nicht nur einmal releasen, sondern halt mehrfach.
Aber vielleicht kann die Organisation das zu dem Zeitpunkt noch nicht und man lernt es
und geht in die Richtung.
Deswegen ist das Agile in SAFE eher…
Ja, das Ziel als der Startpunkt.
Und SAFE an sich mag auch nicht der Endpunkt von so einer agilen Transition sein, sondern
kann halt auch als Zwischenschritt verstanden werden und sagen, okay, wir bedienen uns dem
Framework, wir versuchen, in das Laufen zu kommen, wir versuchen, eine Organisation
von mehreren hundert oder mehreren tausend Mitarbeitern zu bewegen.
Das sind ja oft Tanker, die man letztendlich versuchen muss, in irgendeiner Form einen
zum Halten, zum Drehen, zum Wenden, zum Agieren zu bekommen.
Und das ist natürlich ein guter Anfang, mit SAFE zu starten.
Ja, okay.
Wenn ich noch mal meine Sicht auf Agile auch nehme, ich glaube, dass manche Leute Agile
eben genau als interpretieren, ich kann machen, was ich will.
Das manche ist auch gar nicht ironisch oder irgendwie despektierlich.
Also Agile wird ja…
Ich kann es an vielen Stellen, wie ich es auch immer erlebe, als eine etwas so, ja, ich
mache mal so, ich gucke mal, ich schaue mal, interpretiert.
Und wenn ich Scrum nehme als das agile Framework, was die meisten wahrscheinlich kennen, würde
ich auch sagen, da gibt es genug Regeln.
Also Scrum an sich hat ja auch schon sehr viele Regeln und ist ja auch das Ziel von
Scrum, durch Regeln, durch Sätzen von Leitplanken, die natürlich ein bisschen breiter sind,
aber trotzdem mit Leitplanken.
Also das Ziel ist schon, flexibel zu sein, anpassungsfähig zu sein, aber das kriege ich
ja eben nicht hin, indem ich einfach sage, macht, was ihr wollt, sondern indem ich mit
Regeln arbeite und immer da, wo Menschen zusammenarbeiten, wo Menschen voneinander
etwas erwarten, brauche ich Regeln, um eben aufzuschreiben, was kannst du von mir erwarten,
was bin ich denn bereit oder fähig zu liefern.
Also das Thema, was ist agil, darüber gehört wahrscheinlich auch stundenlang in so einem
Podcast reden und wenn ich dich richtig verstanden habe, würdest du auch sagen, dass
dieses A zu Recht in dem Safe drinsteht, in der Abkürzung drinsteht und dass man das
eben, dass agil eben nicht heißt, ich habe keine Regeln, ich habe keine Planung an der
Stelle.
Also ich stimme dir zu, dass agil nicht heißt, man hat keine Planung und keine Regeln.
Man will letztendlich reaktionsfähig sein auf Veränderungen am Markt, man will letztendlich
auch in einem großen…
In einem großen Unternehmen, in einem Konzern auf dem Markt noch reagieren können und man
versucht das letztendlich mit einem Satz von Regeln und aufbauend auf bestehenden Best
Practices und insofern ist das A von Agile in der Abkürzung von Safe, Scaled Agile Framework
halt schon da, aber man braucht natürlich auch da die Menschen, die das Ganze umsetzen.
Man muss letztendlich ein gemeinsames Verständnis für das Produkt, für die Ziele, für den
Markt auch auf hunderte oder tausende Mitarbeiter entsprechend bekommen und da hilft letztendlich
so ein Framework, die Zusammenarbeit zu organisieren, eine gemeinsame Sprache auch zu haben, ein
gemeinsames Miteinander, das sich in vielen anderen Bereichen halt als mit guten Erfahrungen
gut übertragbar bereits gezeigt hat.
Und es sagt ja auch keiner, dass selbst wenn man in so einem Programm-Inkrement in Safe
über ein Vierteljahr plant, dass man so eine Planung dann entgegen dem agilen Manifest halt
von Anfang bis Ende 1 zu 1 umsetzen muss, sondern dass man auch da sagt, plan vielleicht
zu Anfang dieses Programm-Inkrements keine 100% Kapazitätsauslastung ein, lasse dir
Zeit, um auch Veränderungen zu ermöglichen, um eine Planung auch anzupassen, nimm dir die
jeden Sprint, jedes Inkrement sagt Safe und überlege dir, ob der Plan, den du für dieses
Inkrement oder für den restlichen Teil des Programm-Inkrements gemacht hast, ob der noch
aktuell ist, ob der relevant ist und auch das hat man im klassischen Projektmanagement,
da macht man halt auch nicht den Plan am Anfang des Projekts und am Ende nach einem definierten
Zeitraum von zwei Jahren hat man genau das geliefert, was man geplant hat, auch da ist
es ja die schönen Gantt-Diagramme, die man so gezeigt hat.
Ein guter Projektmanager aktualisiert die jeden Tag, jede Woche, zumindest sehr häufig
und genau so geht man letztendlich auch in dem Umfeld Safe und sagt, mache dir einen
Plan, überlege, wo du hinkommen willst, aber lasse dir auch die Möglichkeit, darauf zu
reagieren.
Eine Erfahrung, die wir gemacht haben, wir planen jetzt zum Beispiel bei den meisten
unserer Teams halt eher in der Größenordnung 70% unserer Kapazität im Rahmen des Safe-Programm-Inkrements
ein.
Und die restlichen 30% nehmen wir uns halt Zeit, um auf Veränderungen zu reagieren,
um auf Dinge, die wir während des Programm-Inkrements gelernt haben, halt dann auch umzusetzen
in Veränderungen im Plan und das macht das letztendlich möglich.
Ein weiterer Aspekt, den Safe mitbringt, so ein Programm-Inkrement besteht nicht nur
aus inhaltlichen Umsetzungen, also fachlichen Anforderungen, die umgesetzt werden, also
Features, sondern halt auch am Ende dieses Programm-Inkrements.
Das ist ein Programm-Inkrement mit einem Innovations- und Planungssprint.
In diesem Sprint ist vorgesehen, dass man sich Zeit nimmt für Themen wie Hackathons, für
Themen wie Erfahrungsaustausch, Schulungen, Trainings, in dem man aber auch sich Zeit
nimmt, die Dinge, die vielleicht nicht ganz nach Plan gelaufen sind, fertig zu bekommen
und andererseits natürlich auch für das nächste Programm-Inkrement zu planen.
Und so einen zwei Wochen Zeitraum, den man letztendlich hat, den man sich regelmäßig
auch nimmt.
Den bringen wenig andere Frameworks mit.
Ja, das stimmt.
Das würde ich auch so sehen.
Und wenn ich mal überlege, es ist ja auch so, das ist für mich ja auch ein wichtiger
Punkt, agil kann ja nicht das Ziel sein.
Also ich bin agil und arbeite toll nach agilen Prinzipien.
Das Ganze muss ja dem Kunden einen Wert bringen an der Stelle.
Also insofern würde ich auch mal sagen, unseren Kunden, unserem Business ist es egal, wie
wir arbeiten.
Hauptsache, wir liefern vernünftige Dinge.
Und insofern kann ich damit leben, wenn der eine oder andere sagt, das A in safe ist falsch.
Ich denke, du hast ganz gut dargestellt, dass es eben dann doch seinen Sinn hat und seine
Berechtigung.
Und selbst wenn, Hauptsache, es funktioniert und es kommt was Vernünftiges bei raus.
Genau.
Also das A kann falsch sein, ist letztendlich eine Sichtweise von Personen und mit denen
kann man sich gerne austauschen und man kann auch voneinander lernen.
Und die Gedanken, die dahinterstehen, sind vielleicht nicht allen bekannt.
Die Gedanken sind vielleicht auch in safe so vielleicht nicht von Anfang an enthalten
oder gedacht gewesen und haben sich halt ein Stück mehr entwickelt.
Und so wird sich auch safe in Zukunft weiterentwickeln.
So wird sich DevOps weiterentwickeln und viele andere Frameworks, die eingesetzt werden, auch.
Das Einzige, was sich selten weiterentwickelt, sind Frameworks, die nicht eingesetzt werden.
Das stimmt.
Die werden dann vielleicht irgendwo weiterentwickelt im stillen Kämmerlein, aber sicherlich nicht
für die breite Maßnahme.
Und das hast du ja auch gesagt, das ist ja ein Vorteil von Frameworks.
Dass man einfach breit zugänglich das Wissen hat an der Stelle.
Gut.
Hattest du noch irgendwas, was du ansprechen würdest, was wir noch nicht diskutiert haben?
Also für mich ist das eine runde Sache aktuell.
Ja, okay.
Gut.
Dann würde ich sagen, herzlichen Dank.
Für mich ist ja immer der Punkt, ich lerne ja bei diesen Podcast-Aufnahmen auch immer
irgendetwas oder nicht nur irgendetwas, sondern etwas.
Und ich denke, wir haben auch ein paar Themen besprochen.
Ich würde sagen, vielen Dank, dass du dir die Zeit genommen hast, darüber ein bisschen
was zu erzählen, was du auch tust mit der DASA an der Stelle.
Und ja, bis demnächst.
Vielen Dank an alle Zuhörer.
Vielen Dank, Dirk, dass du mich eingeladen hast.
Ich höre gerne deinem Podcast zu.
Ich habe bis jetzt alle Folgen gehört.
Sehr viele interessante Themen dabei.
Ich habe auch jedes Mal was gelernt.
Und ich hoffe, es geht so weiter.
Ach, du bist das, der also schon gehört hat.
Okay.
Das weiß ich ja endlich.
Okay.
Nein, Spaß beiseite.
Das ist, ich glaube, ich nähere mich jetzt auch der 25.
Folge und bin mal gespannt, wie das so mit den einzelnen Themen weitergeht.
Ich habe da ein paar interessante Dinge in der Pipeline, die jetzt aufsetzen.
Spotify-Modell werde ich demnächst noch mal ein bisschen intensiver diskutieren.
Ich habe auch jemanden aus dem Lean-Bereich.
Also, wie du auch sagtest, es bringt ja immer den Zuhörern immer ein bisschen was.
Ich lerne auch was dabei.
Also, insofern.
Ja, vielen Dank an der Stelle noch mal.
Und dann bis demnächst.
Bis zum nächsten Mal.