Zu Gast haben wir heute George Romanenko, einen Experten für SAFe. Mit ihm überlegen wir, inwieweit DevOps und SAFe das selbe sind oder nicht, ob das Eine das Andere benötigt, und ähnliche Fragen um die Beziehung zwischen den beiden.
In dieser Podcast-Episode diskutieren die Gastgeber mit dem Agile Coach und SAFe-Experten George Ramanenko über die Integration von DevOps in das Scaled Agile Framework (SAFe) und dessen Rolle in großen Unternehmen. George betont, dass DevOps mehr als nur ein technisches Tool ist und vielmehr einen Kulturwandel darstellt, der auf Zusammenarbeit und kontinuierlicher Verbesserung basiert. Die Diskussion umfasst die Unterschiede und Gemeinsamkeiten zwischen SAFe und anderen agilen Frameworks, die Bedeutung von DevOps innerhalb von SAFe, und die Herausforderungen bei der Implementierung in großen, traditionell organisierten Unternehmen. Es wird auch auf die Wichtigkeit von Kundenorientierung und die kontinuierliche Lieferung von Mehrwert hingewiesen.
Inhalt
- Einführung und Vorstellung von George Ramanenko
- Definition und Bedeutung von DevOps
- Integration von DevOps in das Scaled Agile Framework (SAFe)
- Unterschiede und Gemeinsamkeiten zwischen SAFe und anderen agilen Frameworks
- Die Rolle von DevOps innerhalb von SAFe
- Herausforderungen bei der Implementierung von SAFe und DevOps in großen Unternehmen
- Bedeutung von Kundenorientierung und kontinuierlicher Wertlieferung
- Diskussion über verschiedene Skalierungsframeworks und Modelle
- CALMS vs. CALM im Kontext von SAFe und DevOps
- Abschlussdiskussion und Empfehlungen für die Implementierung von SAFe und DevOps
Shownotes:
George’s LinkedIn: https://www.linkedin.com/in/george-romanenko-mba-1799402b/
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
DevOps. Auf die Ohren und ins Hirn.
Ein Podcast rund um DevOps.
Von Luca Ingiagni und Dirk Söllner.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingiagni, Dirk Söllner und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Heute wollen wir sprechen über das Thema DevOps in skalierter Umgebung.
Dazu haben wir als Gast heute George Ramanenko bei uns.
George ist Agile Coach, Safe Program Consultant, Safe Trainer mit langjähriger internationaler Erfahrung
in skaliertem Umfeld und führt selbst als Release Train Engineer einen agilen Release Train.
Hallo George, willkommen bei uns.
Hallo Luca.
Erstmal vielen Dank für die Einladung und ich freue mich sehr, heute dabei sein zu dürfen.
Ja, ganz toll, dass das geklappt hat.
Wir haben ja immer so eine kleine Startfrage für alle unsere Gäste im Podcast,
nämlich nachdem sich niemand zu einigen können scheint, was die Definition von DevOps ist,
fragen wir einfach jeden Einzelnen nach seiner Definition von DevOps.
Insofern George, was ist für dich DevOps?
Für mich ist DevOps ein Kulturwandel.
Manche sagen, es geht nur um Tools zur Verbesserung.
Es geht um Software Delivery, Software Maintenance oder Performance, aber für mich bedeutet es eigentlich viel, viel mehr.
Es entsteht aus der veränderten Denkweise einer Kultur, der gemeinsamen Verantwortung,
dass Entwicklung und Betrieb zusammenarbeiten, um unseren Kunden kontinuierlich Business Values liefern zu können.
Wunderbar, dankeschön.
Und heute wollen wir, wie ja schon angekündigt, über Safe sprechen und vor allen Dingen Safe,
ich sage jetzt mal in seinem Zusammenhang,
mit DevOps, aber bevor wir da mitten reinspringen, ist es vielleicht angebracht, wenn wir noch mal kurz erklären,
was ist denn Safe eigentlich gleich nochmal?
Ja, ich versuche es sehr kurz, weil normalerweise dauert ein Safe-Training irgendwie drei Tage.
Ich glaube, so viel Zeit haben Sie nicht.
Das CAD-Ager-Framework oder kurz Safe ist eine frei verfügbare Wissendatenbank
mit bewährten, integrierten Prinzipien und Praktiken für Lean-Ager und,
was uns heute besonders interessant ist, DevOps, die Unternehmen nutzen können,
um ihren Kunden in kürzester, nachhaltiger Vorlaufzeit einen fortwärtigen Mehrwert zu bieten.
Safe wurde 2011, also noch gar nicht so alt, von Dean Levenwell geschaffen.
Es hat erkannt, dass Scrum, eine weitere äußerst populäre Struktur aus dem Bereich des agiles Denkens,
mit Anstrengungen verbunden war.
Also die Anstrengungen kommen meistens bei den Kunden, aber die Anstrengungen kommen meistens bei den Kunden.
Also die Anstrengungen kommen meistens bei den Kunden, aber die Anstrengungen kommen meistens bei den Kunden.
In großen Entwicklungsunternehmen mit mehr als ein paar hundert, zweihundert,
ich sage ehrlich auch mit hundert Mitarbeitern, zum Tragen.
Scrum ist gemacht für kleine agile Teams.
Und wir reden halt im Scrum von Teams bis elf Teilnehmer.
Und in großen Unternehmen wäre es nicht möglich, ein cross-funktionales Produkt in so ein kleines Team zu liefern.
In großen Unternehmen gäbe es schon bald Dutzende solcher Scrum Teams.
Diese Teams brauchen eine begreifende Struktur, dass sich sonst niemand merken kann, wie gerade woran arbeitet.
SAFe bietet eine solche Struktur.
Übrigens, das ist gleichzeitig auch das, was viele an SAFe kritisieren.
Es wäre nicht sehr agile, Teams in eine große Struktur anzuwenden.
Aber in der Praxis stellen wir jedoch fest, dass diese Struktur, dass es genau was notwendig ist, um Chaos zu vermeiden.
Aber in der Praxis stellen wir jedoch fest, dass diese Struktur, dass es genau was notwendig ist, um Chaos zu vermeiden.
Ähm, SAFe fordert auch die Abstimmung.
Ähm, SAFe fordert auch die Abstimmung.
Zusammenarbeit und Ausführung über zahlreiche agile Teams hinweg.
Das hören wir immer so, ähnliche Begriffe schon auch mit dem DevOps.
Im Mittelpunkt stehen dabei drei Themenbereiche.
Agile Softwareentwicklung, Lean Product Entwicklung und Systemdenkweise.
Wenn Unternehmen wachsen, liefert SAFe einen strukturierten Ansatz zur Skalierung von Agile.
Es gibt vier SAFe Konfigurationen.
för verschiedene Skalierungsebenen.
Essential SAFe.
Da sagen wir halt, das passt sehr gut für das Unternehmen.
Oder für das Team bis zu 120, 130 Mitarbeiter.
Large Solution, wo können halt schon mehrere Agile Students arbeiten.
Portfolio SAFe und FaoSAFe.
Ich könnte natürlich noch lange von SAFe erzählen, wie gesagt, aber ich fürchte,
dann haben wir zu wenig Zeit für die andere Frage.
habe simplesmente zu wenig Zeit für die andere Frage.
Vielleicht noch einen Satz.
Vielleicht noch einen Satz.
Ähm, banner av Fort Guers.
SAFE ist tatsächlich der beliebteste Einsatz zum Skalierung Agile Marketing.
Der beliebteste oder der beste?
Der beste ist natürlich auch die Geschmackssache, aber wenn wir prüfen tatsächlich auf dem Markt,
wie viele verwenden zum Beispiel LESS oder SAFE, dann sehen wir, das ist der beliebteste.
Also ich bin ein großer Fan von SAFE.
Und sonst bin ich ja auch die SAFE-Coach und ich glaube, das ist der beste Einsatz zum Skalieren.
Aber wie gesagt, das ist meine persönliche Meinung, aber die Fakten bestätigen einfach diese Äußerung.
Hast du schon Erfahrungen mit anderen Skalierungsframeworks im realen Leben gemacht?
Ja, ich habe auch LESS versucht. Wir haben auch Spotify Modell, sagen wir so, versucht.
Aber auch Spotify selbst sagt ja,
das Spotify Modell funktioniert nur bei Spotify.
Und wir haben es versucht.
Ich glaube, mit SAFE haben wir viel bessere Ergebnisse geschafft.
Nichtsdestotrotz muss man auch sagen, auf Team-Ebene,
alle diese Modelle bieten mehr oder weniger die gleichen Methoden.
Wenn wir aber darüber hinausgehen,
dann wäre SAFE für mich, in meinen Augen, die beste.
By the way, nur SAFE so offen spricht von DevOps.
DevOps ist quasi Bestandteil.
Ja, SAFE.
SAFE spricht von DevOps, sagst du.
Die Frage ist natürlich, wie siehst du das Zusammenspiel zwischen DevOps und SAFE?
Was sind die Zusammenhänge? Was sind die Unterschiede?
Ja, es gibt natürlich auch die Unterschiede, aber lass uns erstmal mit Zusammenhang reden.
DevOps ist Teil der Agile Product Delivery Kompetenz in SAFE.
Die Unternehmen, die Scale Agile Framework implementieren, implementieren DevOps,
um organisatorische Silos aufzubrechen, um ein Continuous Delivery Pipeline zu entwickeln.
Eine leistungsstarke Innovationsmaschine,
die marktführende Lösungen mit der Geschwindigkeit bereitstellen kann.
Was jedes Prinzip von SAFE, es gibt ja 10,
aber von Prinzip Nummer 1, wirtschaftliche Sichtweise,
bis zum Prinzip Nummer 10, Value System Organization, gilt für DevOps.
Weil auch in DevOps reden von Kundenorientierung, von Zusammenarbeit, von Risikotoleranz.
Bei DevOps-Kulturen belohnen Risikobereitschaft,
kontinuierliches Lernen und unermüdliche Verbesserung,
von Wissen Austausch, also alles das,
um diese Kunden innerhalb von SAFE und DevOps zu finden.
Es gibt aber auch kleine Unterschiede.
Und zwar, in DevOps, wir reden von CALMS Framework.
Und bei CALMS meinen wir Culture, Automation, Lean, Measurement und Sharing.
SAFE teilt diese Überzeugungen, aber mit kleinen Modifikationen.
Laut SAFE,
Sharing, also Teilen, ist ein natürlicher Bestand der Kultur.
Wenn wir reden um offene Kultur,
dann Sharing, ob es unsere Erfolge oder Responsibilities,
Verantwortung sind, das ist tatsächlich Teil der Kultur.
Dafür präsentiert aber SAFE ein neues Element, Recovery, Widerstehen.
Also Unternehmen sollen in der Lage sein, sofort einen Rollback durchzuführen,
wenn es notwendig ist.
Also in SAFE reden wir von CALM Culture,
Automation, Lean, Measurement, also bis jetzt ist es das Gleiche,
aber dann um Recovery.
CALMS und CALM, die beiden Modelle, die ich gerade erwähnt habe,
von DevOps und SAFE DevOps, beide decken die gleiche Idee ab.
Meiner Meinung nach könnte der Unterschied zwischen CALMS und CALM
eine Frage der Fokus sein.
Vielleicht lag der anfangliche Fokus von CALMS darauf,
die Bedeutung von Knowledge Transfer,
beziehungsweise Wissenaustausch zu betonen.
Während CALM die Notwendigkeit betont,
eine fehlgeschlagene Änderung rückgängig zu machen.
So oder so und in dem Stich sind CALMS und CALM vielleicht nicht ganz gleich,
aber sie sind definitiv gleichwertig.
Und vielleicht noch eine Kleinigkeit,
in SAFE bedeutet DevOps eigentlich DevSecOps.
Wir schützen unsere Kunden, Mitarbeiter und unser Unternehmen.
Ja, das ist immer das Übliche.
Eigentlich müsste man DevOps dann Dev, Test, Sec, Spec,
was weiß ich noch, alles Ops nennen.
Und genauso ist es auch mit CALMS versus CALM.
Ich könnte mir auch noch eine ganze Menge andere Buchstaben überlegen,
die ich da ganz gerne mit reinhaben möchte,
aber auf irgendwas muss man sich halt beschränken.
Ja, auch in SAFE sagen wir DevOps.
Meinen wir natürlich auch Security.
Aber ich glaube, heute Tage, wenn man von DevOps auch allgemein spricht,
wird Security natürlich auch dabei sein.
Genau, dass es auch dabei ist, denke ich, sind wir alle der Meinung.
Ich finde aus den ein oder anderen SAFE Schulungen heraus,
die Sicht auf DevOps, dass sie halt den gesamten Wertstrom abbilden,
von der Anforderungserhebung bis hin in den Betrieb.
Und da gehört natürlich nicht nur Security
neben Entwicklung und Operations dazu,
sondern halt der gesamte,
der gesamte Prozessfluss.
Insofern, ja, stimme ich da mit dir überein,
dass Security auf jeden Fall dazu gehört.
Ja, definitiv.
Also überhaupt in SAFE, wir reden von Value Streams.
Ja, quasi von allen, die beteiligt sind im Prozess,
um diese Value zu liefern.
Und DevOps ist natürlich ein großer Bestandteil.
Und das ist halt alle diese Beteiligten,
also ob es Betrieb,
ob es Development,
ob es Security.
Aber wie gesagt,
ich glaube heutzutage auch ohne SAFE,
diejenigen, die halt DevOps erwähnen,
meinen auch schon die drei.
Ist einfach, DevOps ist schon ein Begriff,
die quasi schon Security dabei hält.
Ja, das ist immer das Schwierige daran.
Ich denke, man impliziert mittlerweile sehr viel,
gerade wenn man DevOps sagt.
Deswegen zum Beispiel haben wir auch gefragt,
was ist deine Definition von DevOps?
Weil jeder meint irgendwie was Eigenes.
Es ist immer lustig,
mal auf die Wikipedia-Seite zu schauen über DevOps,
wo sie ganz offiziell zugeben,
es tut uns leid,
wir haben keine allgemeingültige Definition.
Hier sind ein paar,
sucht euch die raus, die euch am besten gefällt.
Wenn ich in einem Wort den DevOps beschreiben sollte,
da würde ich überhaupt nur Philosophie sagen.
Weil das ist Philosophie von Zusammenarbeit.
Und da können wir sagen,
ob es Betrieb und Development
oder Philosophie von Zusammenarbeit,
von Development Security und Betrieb,
Hauptsache, dass wir zusammenarbeiten,
um diese Value an unsere Kunden zu liefern.
Und am Ende des Tages, wie gesagt,
hier ist wieder diese Schnittstelle zwischen Safe und DevOps.
Ja, eben, weil Safe ist ja auch ein,
ich sage jetzt mal ein Vehikel,
um Zusammenarbeit zu fördern.
Genau.
Inwiefern passt für dich die Perspektive,
die Safe auf DevOps hat,
und deine Perspektive zu DevOps zusammen?
Hast du da eigene Meinung?
Eigene Sichten?
Oder sind da Parallelitäten zu erkennen?
Also ich stimme rein, absolut.
Wie gesagt, wir haben gerade auch die Kunden erwähnt.
Das ist eigentlich die gleiche Philosophie.
Nur das Safe ist,
fängt ja etwas nach vorne.
Also DevOps macht die Dinge einfacher
und kostengünstiger.
Besonders, wenn sie skalieren.
Wenn die Aufgaben automatisiert werden
und es viel schneller Feedback an Entwickler
und Betriebs-Team gibt,
was schnell wachsende Unternehmen brauchen.
Je schneller die Feedback-Schleife,
desto schneller lernt das Unternehmen
und desto schneller wird es keine Konkurrenten.
Und das wollen wir am Ende des Tages.
Wir wollen uns auf den Markt positionieren.
DevOps macht Continuous Delivery möglich.
Unternehmen, die ihren Kunden und Stakeholdern
einen wirklich kontinuierlichen Mehrwert bieten möchten,
müssen die Denkweise
und die technischen Praktiken von DevOps beherrschen.
Diese Ära ständiger digitaler
Description und Innovation
sind diese Fähigkeiten auf dem Tisch.
Und das ist nicht einfach,
Continuous Delivery zu erreichen,
im besonders großen Maßstab.
Der Develop-Einsatz von Safe-Hits-Unternehmen
diese Komplexität zu bewältigen.
Continuous Delivery Pipelines sind das Ergebnis
der effektiven Anwendung von DevOps
auf Value-Streams.
Heute stehen Unternehmen sowieso
immer in ständigem Druck,
neue Features schneller als je zuvor zu releasen,
um in ihren Markten
relevant zu bleiben.
Diese Features haben keinen Wert,
also die haben ja keinen Wert,
bis sie veröffentlicht sind,
aber hier, deswegen sage ich ja auch,
dieser Recovery-Element von Safe, von DevOps,
ist mir wichtig.
Sobald die Unternehmen unter diesem Druck stehen,
die können auch was releasen,
was vielleicht noch nicht so optimal
oder nicht so wie gewünscht funktioniert.
Und dieser Recovery ist ein extrem wichtiger Teil
von DevOps,
um diese Rollback
so schnell wie möglich zu machen.
Okay.
Safe spricht viel von Continuous Delivery Pipeline.
Was hältst du von Continuous Deployment?
Das ist letztendlich,
was ist der Unterschied für dich
zwischen Continuous Delivery
und Continuous Deployment
und inwiefern
ist es hilfreich
in diese Richtung zu denken?
Safe
spricht gerade auch darüber.
Also wir sagen, es ist extrem wichtig
diese Fähigkeiten zu haben
von Release und Demand.
Continuous Delivery
und Continuous Deployment
ist noch nicht alles.
Wir sollen auch in der Lage sein,
von Demand auch releasen zu können.
Und Safe spricht immer
und explizit darüber.
Deswegen, das ist wie gesagt wieder
ein Punkt,
wo Safe
und DevOps
sich trifft.
Weil wie gesagt, Release und Demand
ist ein extrem wichtiger Teil von Safe.
Das heißt, Feature Flags
und Dark Deployments
sind für dich letztendlich
wichtig und Teil der ganzen
Arbeitsweise, aber
das Releasen
an die Endkunden sollte trotzdem noch
von einer Person
entschieden und freigegeben
werden. Ist das richtig?
Nein, das muss ja nicht von einer Person
entschieden werden. Es kann auch sein,
dass das Team
es praktischer findet,
auf Daily Basis
zu releasen, weil es einfach keine
Nutzung gibt, sondern sagen wir so,
einmal in drei Tagen.
Deswegen, wir sollen ja in der Lage
sein, zu releasen,
wann wir das entschieden haben.
Das muss aber nicht auf Tagesbasis
erfolgen, auch wenn wir in der Lage sind.
Das ist immer halt
auch die Frage von der Nutzung
auf Tagesbasis
zu releasen.
Wenn es keine Nutzung bringt oder vielleicht
unsere Kunden wünschen auch nicht ständig
die Veränderung, sondern
die wünschen halt, dass wir mal pro Woche
das releasen, dann sollen wir auch in die Lage
sein, das auch zu machen.
Also ich denke da
überhaupt selten darüber nach,
wann ein guter Zeitpunkt für ein Release
ist. Wenn man es
kontinuierlich macht und
jede Codeänderung zu einem Release
bis hin in die Produktivumgebung
reicht, dann bräuchte man sich überhaupt
keine großen Gedanken darüber machen.
Ist das
eine
Veränderung, mit der
du schon in Kontakt
gekommen bist?
Ja, das ist aber sehr unterschiedlich
vom System.
Wenn wir jetzt von einem Billingsystem
reden, das sind sehr schwierige
und massive Systeme, die am Ende des Tages
unsere Endkunden nicht sehen.
Ich würde sagen, es ist nicht unbedingt
auch sinnvoll auf Tagesbasis
zu deployen und releasen.
Das könnte
halt wirklich zu Instabilität führen.
Wenn wir reden natürlich von
etwas, was unsere Kunden profitieren
wollen, von unseren Features, die wir an
Kunden liefern wollen, dann ist es natürlich
ein ganz anderes Thema und da wünschen wir
uns tatsächlich Continuous Delivery,
Continuous Deployment und Release
on Demand fast wirklich so schnell
wie möglich. Von mir aus mehrmals
pro Tag. Aber dass es wirklich unterscheidet
sich von den großen Konzernen,
großen Unternehmen, ist natürlich auch
diese Backend-Systeme
eine große Rolle spielen.
Und da, wie gesagt,
sehr oft, wir finden uns in der
Lage, dass wir können halt auch
auf Tage, auch täglich releasen,
ist aber nicht gewünscht.
Wer profitiert am meisten
von der Integration von DevOps
in SAFe? Die Teammitglieder?
Die Organisation?
Oder vielleicht sogar die Kunden?
Alle. Das ist
Win-Win-Situation.
SAFe und Agile Praktiken
und die Prozesse selbst sind schon
sehr mächtig. Und die Konstruktionierung,
eine Vision
oder ein Produkt bis hin zum
Product Road Mapping, Release Planning
und Product Backlog
und Entwicklung des Product Features.
Aber von dort aus sehen wir
normalerweise organisatorische
Anstrengungen.
Bei Development Organisationen
behält sich die Feature in Produktion
zu bringen. Das ist ja uns bekannt.
Aber die Operation,
Operational Teams haben
Mühe, Brände in Produktion zu löschen
und die Stabilität zu schaffen.
Während sie gleichzeitig versuchen
neue Features zu deployen, die schon in die
Organisation sind.
Also das ist das typische DevOps Problem.
Hier kommt genau dieses DevOps ins Spiel.
Und unterstreicht
den Punkt, dass
Entwicklung und Betrieb Hand in Hand gehen
und zusammenarbeiten müssen,
während sie auf ein Ziel
hinarbeiten. Nämlich
die Releasing Business Value zusammen.
Also wie gesagt, das ist Win-Win
Situation, wo die Teammitglieder
selbst, wo die Organisation
profitiert. Aber noch wichtiger,
wie du gerade auch gesagt hast,
davon profitieren unsere Kunden.
Die Kunden profitieren von den neuen Features
oder den Dienstleistungen.
Ist wieder natürlich abhängig von der Firma.
Inwieweit sind denn jetzt tatsächlich
Safe und DevOps verschiedene
Sachen, wenn ich dich reden höre?
Also
ist natürlich sehr unterschiedlich.
Weil, ich habe ja gerade
erwähnt ja,
Safe startet ja viel
früher. Und dieser
Prozess von Konzeptionierung
und überhaupt von Produktvision,
welche Produkte möchte ich
ja auf den Markt bringen?
Damit beschäftigt sich DevOps nicht.
Daher sage ich ja, DevOps
ist der wichtige Anteil,
der startet etwas
von besonderem, von gewissem Punkt.
Safe macht
das gesamte Prozess.
Die ersten Gedanken von Vision
sondern, wir reden sogar nicht von Produkt.
Im Rahmen von Safe, wir
besprechen überhaupt unsere Vision, ein Produkt.
Wir beschreiben
das Produkt, wir machen die
Konzepte und
von vorne
bis zu
unseren Kunden.
Wir reden von Value Stream.
Unsere Kunden wollen etwas
und wir versuchen diese Value zu liefern.
In DevOps, wir reden schon natürlich
von der Entwicklung
und Betrieb. Natürlich mit dem
Security. Aber das ist schon
die zweite Hälfte
der Kette. Wir müssen ja
anfangen sogar von der ersten
Visionierung. Und da
DevOps spielt noch
keine Rolle. Daher sage ich ja,
DevOps ist Bestandteil des
Safes, das ist klar.
Aber Safe ist natürlich das
macht die Coverage von der gesamten
Kette und DevOps ist
ab gewisser Stelle.
Okay, also
Safe, hast du auch gesagt, gehört zur
Product Delivery Kompetenz.
Eher auf Team und Release
Train Ebene und Safe
als Framework geht ja dann viel weiter.
Geht in das Portfolio
Management, geht in
die Large Solution
Entwicklung
und weit über die
Team Ebene hinaus. Genau, okay.
Es muss aber
nicht in Large Solution gehen. Es gibt auch
diese Essential Safe, bevor wir
von Large Solution reden.
Aber auch da, wir reden erstmal
von Visionen, von den
Konzepten, von
Konzeptionierungen.
Und wie gesagt,
bevor es überhaupt zu
Firmen kommt. Es gibt schon ein paar Sachen,
die gemacht werden sollen.
Und Continuous Integration.
Und deswegen sage ich ja,
DevOps ist ja,
das ist ein Teil
der Azure Product Delivery Kompetenz,
aber ist natürlich nur ein Teil von
einer Kompetenz. Es gibt ja viel mehr.
Okay, das heißt,
ist
DevOps dann doch wieder
ein rein technisches Thema geworden?
Weil, ich sage jetzt mal,
alles was in Richtung Produktmanagement geht
und so weiter, das gehört ja dann
aus dieser Perspektive nicht mehr zu
DevOps dazu. Nein,
definitiv nicht. Wie gesagt,
das wäre immer ein Fehler,
DevOps als nur ein
technischer Teil gesehen, weil das ist
Kulturwandel und das ist die
Cultural Change. Aber
wie gesagt, DevOps beschäftigt sich
sehr wenig mit der Vision des Produktes
oder Auswahl des Produktes.
DevOps startet etwas später
in dem Prozess.
Nämlich dann, wenn es um die Umsetzung der, der
Ideen geht, der Visionen geht,
die man etwas früher schon
dann erarbeitet hat, ne?
Ja, also, wie am Ende des Tages,
wir wollen unsere Kunden
fragen, was sie da wollen.
Wir wollen
den Bedarf auf dem Market nachforschen
und das passiert viel früher,
als DevOps ins Spiel kommt.
Wenn ich ja eine Frage mache
und meine Customer frage,
was eure wünschen,
ja, was wollen wir, sollen
wir unseren Service verbessern oder was
sind die neuen Features,
die ihr geil findet?
Da hat ja DevOps noch wenig
was zu bieten.
Okay, das bedeutet, dass
DevOps, ich sage jetzt mal,
separat von Safe auch
ein wichtiges Thema ist,
mit dem sich zum Beispiel das Management befassen muss.
Verstehe ich das richtig?
Definitiv. Also, DevOps
kann auch implementiert werden ohne Safe.
Ich sage nur für die
größeren Unternehmen, es macht natürlich Sinn,
Safe implementieren, weil damit implementieren wir
irgendwie auch den DevOps.
Aber es gibt ja auch
dutzende Unternehmen, hunderttausende Unternehmen,
die implementieren DevOps,
brauchen vielleicht den Safe auch nicht,
weil die sind auch nicht so groß.
Also, wenn wir reden von einem Startup mit 20
Leuten, würde ich ja nie empfehlen, auch Safe
implementieren, da kann man auch nur DevOps implementieren.
Mhm, und
neugehalber, also DevOps ohne
Safe geht, geht auch Safe ohne DevOps?
Nein, DevOps ist
Bestandteil des Safes, also
bei der Definition, weil das ist wieder,
das ist einfach kulturelle Change
und das wollen wir haben.
Wir wollen nicht mehr, dass die Leute in
eigenen Silos arbeiten,
in die Silos denken.
Ich glaube, keine Organisation wünscht sich,
dass Leute Operationals sind
und Development Teams
wieder separat arbeiten
und keine,
und nicht miteinander sprechen.
Das wollen wir auf keinen Fall. Und wie gesagt,
für mich, DevOps ist in erster Linie
dieser kulturelle Wandel und
Zusammenarbeit und nicht nur Pipeline zu bauen.
Das ist aber auch sehr wichtig.
Ich sage nicht, dass Pipeline ist
nicht nötig. Das wollen wir natürlich auch
haben. Aber in erster Linie diese
Zusammenarbeit und das ist auch,
was ist in Safe wichtig.
Was macht für dich die
Pipeline aus?
Das ist, das
macht ja viel. Also, das ist
auch eine Sache, womit man auch
sehr viel auch unser
Management bewerben kann.
Weil, wenn wir von Pipeline reden,
natürlich auch reden von
der Möglichkeit, die Arbeit schneller
machen, billiger, also
kostengünstiger. Man liefert
mit höherer Qualität,
bessere
Predictability und einfach
mit höherer Produktivität.
Also Safe DevOps bietet uns die Möglichkeit,
fast notwendig ist auch schnellere
Recovery, also Widerstellung zu machen.
Wie gesagt, was ist extrem
wichtig, um diesem ständigen Druck
neue Features in Produktion zu bringen.
Und das ist eigentlich
im Wesentlichen die wahre
Position von Business Engineering.
Und by the way,
wenn man DevOps für
den Management verkaufen möchte,
ist manchmal sehr schwierig
machen mit dieser kulturellen Change.
Aber mit dem
schnelleren und kostengünstigen
Lieferungskette, das funktioniert
besser.
Hast du da ein paar
Zahlen und Daten,
Fakten vielleicht im Hintergrund,
wie viel schneller man mit
DevOps werden kann, wie
billiger es wird? Kannst du das
irgendwie quantifizieren?
Ich kann nur sagen,
ich habe die Zahlen jetzt nicht ad hoc gebracht,
weil ich
das natürlich von Kunden zu Kunden
unterschiedlich ist. Ich kann nur
sagen, ohne
zum Beispiel diese Zusammenarbeit
und ohne diese Pipeline,
das wäre unmöglich,
die Bugfixing im Rahmen von
halbe Stunde
in Produktion fixen. Wenn du es alles
manuell machen musst, du hast ja keine
Chance. Wenn die Betriebleute
und die Werbung nicht zusammen reden
wollen, du hast ja auch keine Chance.
Und in den Unternehmen, wo ich ja auch
unterstütze, wir schaffen
es,
Minuten Bugfix
zu finden, das zu fixen,
mit Abstimmungen, die sofort erfolgen,
weil die Teams, ist sogar nicht die Teams,
das ist ein Team. Die reden
ein mit anderen und wenn einfach Klick auf
einen Knopf, das geht in die Produktion.
Du musst ja nicht mehr jetzt irgendwie ein Ticket
erstellen, die erstmal bei
Operation Team lernt, die haben
irgendwie ein paar Tage SLA
und dann, die bearbeiten
das ja oder nein und dann
kriegst du Meldung oder auch nicht.
Also das
gehört nicht zu unserer Zeit,
das gehört nicht zur Digitalisierung,
das gehört nicht zu den Unternehmen,
die attraktiv auf die Marken bleiben.
Genau und ich glaube, es ist wichtig
an der Stelle nochmal herauszustreichen,
dass wenn du meinst, das Problem ist innerhalb von
ein paar Minuten behoben, meinst du damit nicht,
man hat schnell schnell eine Push-Lösung hingewurschtelt,
die einem dann am nächsten Tag nochmal um
die Ohren fliegt, sondern wirklich eine
nachhaltige, irgendwie
handwerklich solide gemachte Lösung.
Genau, also und das ist eben auch einfach,
tatsächlich einfach, wenn du hast einfach eine
gut funktionierende auch
Pipeline, die auch testautomatisiert
durchläuft, die
das in Container packt,
die wie gesagt schon geprüft und
getestet worden und dann einfach
vielleicht erstmal in
Prod-Umgebung landet, da könnte man
bei Bedarf, wenn es gibt und wenn es so
kritische System ist, vielleicht sogar
überprüft werden und dann geht es
in Produktion. Das war früher aber
nicht der Fall. Also früher sollte
so ein Ticket erstellen,
die Leute sollten das Ticket bearbeiten
und da definitiv haben die gewisse
SRAs und vielleicht wenn das
schneller gehen sollte, müsste es eskalieren
oder wenn ihr ein paar Telefonate machen,
das existiert
ja nicht mehr. Die Leute arbeiten zusammen,
die wissen, dass das Problem besteht,
die arbeiten gemeinsam an der Lösung und
bei einem Klick, es geht einfach
um die richtige Umgebung.
Hast du Erfahrungen
mit Blameless Postmortems
als Fehler,
Lösung und Dokumentationsansatz?
Nein, ehrlich gesagt nicht.
Vielleicht kannst du dazu was sagen, das wäre auch
interessant für mich. Das ist ein Ansatz, der
letztendlich aus dem
Site Reliability Engineering
kommt,
dass Google als
seine Software Engineering
basierten Implementierung von
DevOps sieht und
ja
publiziert hat und zwar
geht es halt darum, ähnlich wie man das
bei cross-funktionalen DevOps Teams hat,
alle Beteiligten, die an einem
Ausfall, an einem Problem in
irgendeiner Form
einen Anteil hatten zusammenzubringen,
eine gemeinsame Timeline
der verschiedenen
zum Problem geführten
oder parallel zum Problem
auftretenden
Themen zu dokumentieren,
dann zu schauen,
welches von diesen Maßnahmen
hat dann zur Auslösung des Problems
geführt, was hat letztendlich dazu
beigetragen, welche
weiteren Effekte gab es und
wie kann man daraus am besten
lernen, wie kann man
sicherstellen, dass diese Ursachen
beseitigt werden, dass
solch ein Problem möglichst nicht wieder
auftritt. Das Ganze dann halt auch
so zu dokumentieren, dass man es
unternehmensweit recherchierbar hat.
Das heißt, falls an einer anderen Stelle ein ähnliches
Problem auftritt, dass man dann halt
auch wieder auf die
Fehlerursachen
aus anderen Bereichen, auf die Maßnahmen,
die in anderen Unternehmensbereichen dazu
eingeführt worden sind,
reagieren kann.
Also auch eine Art des
Lernens aus
im gesamten Unternehmen.
Okay, sehr cool.
Dann musst du, glaube ich, weiter den Podcast hören, George, weil
auf meiner Liste von Themen habe ich auch schon
das Thema Blameless Postmortems.
Da möchte ich gelegentlich mal eine Folge
dazu machen.
Haben Sie bereits jetzt Provo gemacht.
Genau, perfekt. Aber ich bin so ein bisschen
neugierig, weil
wir haben uns ja jetzt sehr, ich sage es mal,
allgemein und theoretisch unterhalten über
Safe. Aber ich frage
mich, wie führt
man denn Safe überhaupt in ein
Unternehmen ein? Und vielleicht als
Detailfrage, insbesondere im Hinblick auf
den Aufhänger Safe und
DevOps, sollte man, ich weiß auch nicht,
mit DevOps starten und sich dann weiterentwickeln
in Richtung Safe? Oder sollte man
beides parallel machen? Oder
wie fängt man es denn an?
Also, sobald man Safe
einführt, wird da schon
mit Safe diese
Kulturwandel kommen. Weil
bei Safe kannst du auch nicht anders arbeiten.
Alle arbeiten, und das ist eigentlich
alles, alle Mitglieder
ist ein großes Team.
Du hast ja natürlich Teams von Teams,
du hast ja auch dieses Scrum-Team bis elf
Team-Members,
aber am Ende des Tages, wir sind ja alle ein Team.
Und da sind sowieso schon alle Leute
dabei, die wir brauchen, um die
Values-Team zu schaffen,
um die Values-Kunden zu liefern.
Das heißt, da sind sowieso schon
auch die Developers
dabei, da sind sowieso schon auch
Betriebsleute dabei, da sind sowieso schon Security-Leute
dabei, und wir sind ja ein Team.
Wir sind schon gespielt in diese
konventionellen Teams, wo wir alle diese
Kompetenzen auch haben. Das heißt,
du musst ja nicht
anfangen mit dieser kulturellen Änderung,
was du in DevOps,
wenn du noch DevOps einführen möchtest,
damit musst du dich nicht mehr beschäftigen.
Du hast es schon.
Wie gesagt, deswegen sage ich ja immer,
wir implementieren uns schon gleichzeitig
mit Save auch DevOps.
Und sobald du diesen Kontakt
hast, und du hast diese
Wand schon
zerbrochen zwischen den beiden,
das ist schon natürlich viel einfacher.
Und dann reden wir natürlich nicht nur halt
um diese kulturelle Change, weil das haben wir
schon geschafft, dann haben wir natürlich auch
andere Komponenten. Also wir können
ja reden jetzt von Pipeline-Entwicklung,
was natürlich uns alle weiterbringt,
und nicht vergessen, wir reden jetzt nicht wieder
nicht von 11 Leute, es kann auch
sein 100 Leute, die entwickeln
natürlich auch ständig und viel, und das muss
ja auch relativ schnell getestet und deployed werden.
Und bei Bedarf auch released.
Daher müssen wir halt machen.
Und
deswegen sage ich ja, die wichtigste
und die schwierigste Anteil von
DevOps ist eigentlich
sofort mit der Einführung von Save.
Diese Zusammenarbeit. Und dann
kommen wir halt für den Bedarf,
die spezifischen Themen zu besprechen, aber
auch über das Pipeline oder wie auch immer.
Aber diese Basis hast du
damit schon geschafft.
Eine Sache, die mich auch interessiert, ist,
wenn ich mich umhöre in
agilen Kreisen, gibt es ganz viele,
die über Save schimpfen und sagen, oh,
Save ist ganz schrecklich und ist überhaupt nicht
agil und es ist total
furchtbar und es ist einfach nur Wasserfall,
gelb angemalt.
Was ist deine Antwort auf
diese Leute?
Ja, ich habe es
auch kurz schon erwähnt, dass es die
Vorteile, die Save bietet,
auch oft benutzt wird
bei den Kritikern. Ich sage,
es ist mega geil, sofort zu starten
wie so ein Unternehmen wie
Amazon oder Netflix oder
Spotify, die so klein
gestartet und gewachsen sind,
aber immer schon von vorne in diesem
agilen Umfeld.
Die wissen ja nichts anderes.
Diese Kultur, das war immer der Bestandteil
des Unternehmens. Es ist eine ganz andere
Nummer, so Agilität einzuführen
in große Konzerne. Die haben schon
jahrelang
Wasserfallmethoden verwendet
und haben schon diese
Silos überall.
Dann kann man natürlich sagen,
oh, wie wollen wir Google sein? Ja, cool.
Kannst du das?
Nein. Also bevor du laufen kannst,
musst du auch den ersten Schritt erst
machen. Und ich finde,
dass Save genau
dieses Framework, mit dem du
diese Schritte machen
kannst. Du kannst einfach nicht
sich von heute auf morgen
von einem großen
Konzern, der komplett auf Wasserfallmethoden
basiert, plötzlich
sagen, oh, ich mache jetzt wie
Netflix. Das wird einfach nicht funktionieren.
Du kannst ja, du hast ja diese
Zusammenarbeit nicht, du hast diese kulturellen
Change und Wandel noch nicht.
Das kannst du einfach nicht machen.
Also du kannst es versuchen,
du kannst davon träumen,
du kriegst das nicht hin.
Und Save ist genau das richtige Framework,
um diesen
Move zu schaffen.
Daher sage ich ja, es kann natürlich
viel noch kritisiert werden.
Es kann auch natürlich viel verbessert werden,
deswegen sage ich ja, obwohl Save
nur 2011 eingeführt, wir haben schon
die vierte Version von Save,
die wird auch dieses Jahr noch
eingeführt. Und das gibt ja immer
große Änderungen. Save
ist keine Bible.
Also das entwickelt sich,
das ändert sich, weil unsere Welt
ist auch ändert, permanent.
Und Save ist einfach,
die Sammlung von Bestpraktiken.
Und du kannst auch sagen, okay, diese Praktiken
passen für mich und diese nicht.
Das ist auch vollkommen in Ordnung.
Ja, aber wie gesagt,
kritisieren ist natürlich immer
einfacher. Und ich würde mir
auch wünschen, vielleicht so ein großes
Konzert sofort in einem Tag wie
Netflix oder wie Google machen.
Das geht nicht. Und wir brauchen
halt gewisse Framework, die bietet uns
diese Möglichkeit von Wasserfall
und Unternehmen, die halt in
Serials funktionieren erstmal,
umwandeln und agile Methoden
halt beizubringen. Und wie gesagt,
für mich, da gebe ich ja mehrere
unterschiedliche Frameworks und Modellen
benutzt habe, Save ist
nicht optimal. Genau,
also da stimme ich dir auch völlig zu,
weil mir geht es ähnlich wie dir,
die Leute, die so fürchterlich über
Save schimpfen, die machen sich
vielleicht ein bisschen einfach. Weil
man kann darüber streiten, ob Save
in allen Fällen das Richtige ist, oder
ob sie nicht manchmal auch ein bisschen, ich weiß nicht,
noch mutiger sein könnten in Richtung Agilität
oder sowas. Aber genau wie du sagst,
man würde bestimmt die Unternehmen, die
gedacht sind als, wie soll ich
sagen, als die Kunden von Save, als
die Anwender von Save, würde man schlicht und ergreifend
überfordern. Genauso wie du sagst.
Es ist nicht nur überfordern. Also
die Teams in Save arbeiten
genau laut Scrum-Modell.
Manche Teams arbeiten
mit Kanban-Modellen, manche arbeiten
mit Scrum-Modellen. Ist auch in Ordnung,
aber Scrum ist sowieso. Die
treffen eigene Entscheidungen und machen
halt, was die
sich hier halten, nach dem Wunsch von
Customers und unseren Kunden.
Das Problem ist, in so einem komplexen
Unternehmen mit
dutzendtausend Mitarbeitern,
du schaffst kein Produkt in ein oder
zwei oder sogar auch in drei Teams.
Und auch hier brauchst
du gewisse Koordination von Teams.
Beziehungsweise du brauchst Minimum
Alignment zwischen den Teams.
Und, weil die Teams entscheiden ja
selbst in Ordnung, aber wir brauchen halt
irgendwie zentrale Priorisierung.
Es bringt mir ja nicht, wenn ein Team arbeitet,
auf Feature A, brauchen aber
dafür vielleicht etwas von Team B
und Team B hat das überhaupt nicht priorisiert.
Daher, wir brauchen diese
gemeinsame Priorisierung. Und zum Beispiel
ich bin gerade, wie du
schon auch gesagt hast, ich bin Release Training
Engineer, ich hab acht Teams.
Dann brauchen wir gewisse Alignment zwischen die acht.
Sonst kriegen
wir am Ende des Tages nicht das
gute Produkt. Es reicht
mir nicht, dass vier Teams haben was
priorisiert, aber die anderen vier gar nicht
im Radar gehabt.
Daher, diese gemeinsame Priorisierung,
gemeinsame Vision des Produktes,
es muss ja transparent für alle Teams sein.
Und diese Transparenz und diese
Alignment, das ist genau, was SAFe uns
bringt. Ich könnte
bis jetzt nicht finden,
was SAFe weniger
agil macht. Also,
vielleicht liegt es daran, wie tief
die Leute in SAFe Freiburg
einsteigen. Da ist so ein
Besammeln von allen Methoden,
ich habe noch keinen Nachteil gesehen.
Was jetzt wichtig ist vielleicht,
noch dazu zu sagen, das, was
ich immer auch in meinen Trainings sage,
one size doesn’t fit all.
Du kannst ja nicht sagen,
okay, ich habe hier
SAFe eingeführt,
ich mache das gleiche jetzt in anderen Unternehmen.
Das funktioniert eben nicht.
Alle haben unterschiedliche Produkte,
alle haben ein bisschen unterschiedliche
kulturelle Änderungen von Unternehmen zu
Unternehmen. Und wie gesagt, aber hier
auch ein zusätzlicher Vorteil von SAFe,
wie gesagt, es ist nur die Sammlung von den Praktiken
und Methoden. Du kannst immer, wenn du
gut bist und du kennst die ja,
die passende finden von Unternehmen zu Unternehmen.
Und das funktioniert auch
sehr erfolgreich. Kann man dann überhaupt sagen,
dass es das eine SAFe gibt?
Weil es klingt jetzt ein bisschen so, als ob es ein
ich sage jetzt mal ein SAFe für, ich weiß auch nicht,
für Daimler gibt und ein SAFe für die Deutsche Bank
und ein SAFe für, ich weiß nicht,
Deutsche Telekom. Und es steht zwar überall
SAFe drauf, aber vielleicht ist jedes Mal was ganz anderes
drin. Das ist
eine sehr interessante Frage,
weil das ist natürlich,
kann man auch nicht so, wie auch die
anderen beantworten. Wieso? Es gibt
ja immer die Elemente, die sein müssen,
um das überhaupt SAFe zu nehmen.
Du musst zum Beispiel DevOps haben.
Du musst PI-Pläne
durchführen. PI-Pläne durchführen.
Du musst Innovation & Planning haben.
Du musst permanent Transparency & Adapt
haben. Du musst in klarer
Kadenz arbeiten. Du musst ja Transparenz
haben und so weiter und so fort. Es gibt gewisse
Sachen, die müssen sein.
Aber zum Beispiel, du musst ja nicht
sagen, dass
alle müssen Scrum nutzen. Ist auch in
den Teams ja kann man nutzen, wenn die
das für die richtig halten.
Und die sagen, es kann sein, dass SAFe
bei einer Firma sieht ganz
anders wie bei anderen. Aber gewisse
Elemente müssen das sein.
Und das beobachte ich ja auch sehr oft,
wenn ich komme und mir sagen die
Customer zum Beispiel, wir arbeiten
nach SAFe und ich komme und sage,
nein, das ist nicht SAFe.
Also du kannst es nehmen,
wie du möchtest, aber SAFe ist es
nicht. Die Tatsache, dass du
plötzlich da Daily machst,
und irgendwelche Events machst,
quasi BI Training ähnlich,
das macht es doch nicht SAFe.
Wenn du aber immer noch in
Silos arbeitest und
du hast ja alle Rollen von deinem
Department
mit Leuten von deinem Department besetzt
und du sprichst aber mit Kunden nicht und
du weißt doch gar nicht, was die Kunden wollen,
dann ist es nicht SAFe. Du kannst die Rollen
benennen, du kannst die Events haben,
aber es ist immer noch nicht SAFe,
ist nicht Agile, aber ich glaube,
dass es unabhängig von SAFe, das wäre genau
so im Scrum. Ich habe auch gesehen,
die Leute sagen, oh, ich habe Product Owner
und ich habe Scrum Master, aber die machen
genau, was die Vorgesetzten gesagt haben.
Das ist auch nicht der Scrum, auch wenn du
die Rollen hast und du die Events hast.
Also das ist wie gesagt, auch
hier, ich habe ja in einem Wort gesagt,
DevOps für mich ist eine Philosophie,
auch Agilität ist eine Philosophie und
unabhängig von welchem
Framework wir reden, ob es
SAFe, ob es Spotify Modell ist,
Scrum, da muss einfach
diese Change
erfolgen. Ohne
wird es nicht funktionieren. Deswegen
für deine Frage, ja, SAFe
kann unterschiedlich aussehen,
es gibt aber gewisse Elemente,
die müssen sein. Anderesrum,
wir können es auch SAFe nennen, aber das ist
nicht SAFe. Okay,
sehr interessant. Und das klingt
jetzt für mich auch danach,
dass eigentlich der vielleicht
klassische Fehler, den man machen kann bei einer SAFe
Einführung, dass man genau eben
nur die Rollen
sich aneignet, nur
die Events durchführt,
aber nicht den notwendigen
Mindset-Change mitmacht und sagt, wir
reden nicht nur anders miteinander,
wir nennen uns anders, sondern wir arbeiten
jetzt auch anders miteinander. Genau.
Also ich glaube, wie gesagt,
jetzt sage ich ja etwas, wir reden von SAFe,
aber das ist genauso
für jede Agile Framework oder Methode.
Die größte und die wichtigste
Änderung ist in unserem Mindset.
Du kannst Tools einführen,
du kannst Prozesse
einführen, wie gesagt, ob es
Daily, Retro oder
Inspector Adapt und BI Planning sind.
Du kannst es auch benennen, aber wenn du
wirklich nicht zusammenarbeitest,
wenn du immer noch in deine
eigenen Silos denkst,
an eigene Ziele und nicht um
gesamte Ziele des Unternehmens,
wenn du nicht um Value
denkst, was du an Kunden
liefern, sondern an deine spezifischen
Ziele von deiner Abteilung,
dann bringt das ja nichts.
Das ist egal, wie du das nennst
und es ist egal, welche Rolle du
also ich habe ja auch gesehen, dass die
IT-PLs haben einen Namen gekriegt,
ob Scrum Master oder RT
oder die
PLs haben plötzlich Product Management
gewesen oder Product Owners.
Das spielt ja keine Rolle, du kannst
ja auch Bananen-Apfel nennen, das schmeckt aber
nicht anders.
Also
nur um die Rollen
zu benennen und die
deine irgendwie Jurafix jetzt
BI Planning oder Daily
zu nennen, das ändert ja nicht.
Die gesamte Änderung und
wie gesagt, das gilt genauso für DevOps
wie für Scrum oder für Save,
startet im Mindset. Und
im Gesamt, wenn wir
zurück zum Save gehen, du brauchst
auch hier quasi immer erstmal
überlegen, dass du das tatsächlich
cross-functional bildest.
Wenn du jetzt nur ein Team von
Developern stellst und da auch BI und Scrum
Master nennst, aber die wirklich in
Silo arbeiten, dann wird das auch nicht safe.
Und du brauchst auch
die Leadership, die dich unterstützt
in diesem Wandel.
Und die unterstützt und
proaktiv auch
diesen Wandel treibt.
Dann kannst du Save auch erfolgreich
implementieren. Und wie gesagt, bei
Implementierung von Save, implementierst du auch
in DevOps.
Dann haben wir jetzt schon sehr viel über
Save gehört und über den Zusammenhang zwischen
Save und DevOps. Und ich glaube, es ist
langsam auch ein guter Zeitpunkt, um diesen
Podcast dann am Ende zuzuführen.
Aber vielleicht als letztes Geschenk,
an die Hörerinnen und Hörer.
Gibt es einen besonders
wichtigen Tipp, den du den Hörerinnen
und Hörern mitgeben könntest, wenn sie
vielleicht gerade versuchen, eine
Transformation in Richtung Save
vorzunehmen? Ja, ich versuche es.
Also, wir haben jetzt
sehr viel von Values
gesprochen. Und Value Delivery
beginnt mit einer Idee
oder einer Hypothese darüber, was
Kunden brauchen. Das müssen wir
immer als erstes betrachten.
Und Save spricht immer von
Customer Centricity. Diese Bedürfnisse
müssen dann kontinuierlich untersucht und
bewertet werden, um sicherzustellen,
dass ein Produkt dem Menschen, dem
Kunden entspricht. Sonst, wie gesagt,
haben wir auch nicht erreicht, wenn wir
nicht die richtigen Produkte aber einfach schnell
zur Macht mitgebracht haben.
In diesen Zeiten
müssen dann agile Teams diese Systeme und
Lösungen kontinuierlich erstellen
und integrieren und die kontinuierlich
in die Produktion bereitstellen.
Dort werden sie validiert und auf
die Business Entscheidung, ob die
Produkte released oder vielleicht nicht,
warten werden. Ein häufiger
Fehler besteht darin,
eine agile Transmission
ohne DevOps zu versuchen.
Oder umgekehrt. Deswegen auch hier
sage ich ja, Safe Framework
ist schon
bestimmt,
beeinhaltet schon DevOps. Deswegen, wenn wir
Safe schon einführen, dann werden wir DevOps
nicht vergessen. Agile ohne DevOps
schafft nur diese
Qualitätsarbeit, die nicht schnell
genug an den Kunden geliefert werden kann.
Und daher nicht zu den ultimativen
wirtschaftlichen Erlebnissen führt.
Umgekehrt, mit DevOps
ohne Agile bestenfalls
eine nicht ausgelastete
Pipeline. Im schlimmsten Fall
liefert agile Teams
die falschen Dinge schneller. Das heißt,
wenn wir nur DevOps haben, das kann
implementiert werden. Aber wenn wir überhaupt
nicht die Wünsche der Kunden betrachten,
dann liefern wir schnell, aber
falsch. Das hat uns auch
relativ wenig gebracht. Man braucht sowohl
Agile als auch DevOps,
um einen Mehrwert zu erzielen.
Und wie gesagt, wiederhole ich mich,
deswegen bin ich ja auch Fan
von Framework. Sonst würde
ich ja vielleicht Trainer von einer anderen
Framework sein. Eine der
schwierigsten Fragen, mit denen Unternehmen
bei DevOps Transformation konfrontiert sind,
ist die Entscheidung, womit
die überhaupt
anfangen sollen.
Und an dieser Stelle muss ich ja sagen,
der Safe DevOps Kurs beantwortet
genau diese Frage.
Dieser Erfahrungskurs ermöglicht es,
den Teilnehmern ihre
bestehende Lieferpipeline
abzubilden und
die Zeit und die
Qualitätsengpässe zu identifizieren.
Also wir arbeiten einfach zusammen,
wir austauschen, und das ist auch sehr hilfreich,
die Leute von unterschiedlichen
Unternehmen halt
diesen Austausch zu machen.
Wir verwenden
alle zusammen Safe DevOps
Health Radar, um ihren
Reifengrad in jeder der
- Unterdimensionen
und Demand
zu prüfen. Und wir dann
identifizieren einfach die Endpässe
und nehmen die
Punkte mit, die wir auch dann
in unserem Unternehmen verbessern sollen.
Und wie gesagt, am Ende
haben die Teams die drei wichtigsten
Verbesserungspunkte identifiziert,
die in ihrer Umgebung
die besten Ergebnisse auch liefern
würden. Und
erfahrungsgemäß, und das ist
immer witzig, dann am Ende zu sehen,
dass die Leute die Endpässe
an Orten finden, wo die überhaupt
nicht erwartet haben. Also ich empfehle
am Ende des Tages
die Unternehmen, die diese Schritte wagen, die
Safe oder DevOps zu implementieren,
in einer Safe DevOps Schulung
teilzunehmen, um
sich ein besseres Verständnis zu schaffen.
Auch von Zusammenarbeit,
auch um silofreien Gedanken,
aber natürlich auch von
Pipeline zu verstehen. Anschließend
erstellen sie auch in
dieser Schulung
einen zukünftigen Statuspipeline,
in dem sie Fähigkeiten
in den vier Dimensionen
die Bereitstellungspakete identifizieren.
Continuous Exploration, Continuous Integration,
Continuous Bereitstellung
und Resonance machen.
Also wie gesagt,
das wäre wirklich mein Tipp.
Und bitte auch nicht vergessen,
das startet einfach von Mindset Change.
Gut, ich würde mal vorschlagen,
dann haben wir
eine ausgezeichnete Folge
gerade aufgenommen, in den Kasten gebracht.
Ich denke, wir sollten auch darauf hinweisen,
George, dass du natürlich auch
Unternehmen, Organisationen dabei hilfst,
safe einzuführen. Haben wir
vorher gesagt, als Coach, als Trainer.
Und ich schlage vor, wir
packen einen Link zu deiner
Webseite in die Shownotes, sodass
Leute, die sich dafür interessieren, mit dir
in Kontakt zu kommen, da die Möglichkeit
haben, dich zu finden.
Sehr gerne.
Wunderbar, dann
bleibt mir nichts anderes übrig, als
mich sehr herzlich zu bedanken, dass du dir heute die Zeit
für uns genommen hast. Ich weiß, es ist gerade eine stressige Zeit für dich.
Umso toller, dass es heute geklappt hat.
Vielen Dank dafür und vielen Dank
für diese spannende Folge.
Danke euch. Es ist mir eine Freude
und ich werde zugleich heute dabei sein dürfen.
Alles klar. Bis zum nächsten Mal, George.
Wunderbar.
Ciao. Ciao.
Ciao.