loslegen@agile-life.de +49 1578 499 884 8

    • HOME
    • Leistungen
    • Academy
    • Agile Trinität
    • BLOG
    • Ressourcen
      • PODCAST
      • EVENTS
      • GLOSSAR
      • GRÜNDER
        • Alex
        • Ben
    • Home
    • Agile Blog
    • Blog
    • Das zweite Prinzip von DevOps (Second way of DevOps) || DevOps Series – Episode 5
    scrum richtig skalieren
    Scrum skalieren, aber richtig – Welches ist das beste Framework? || Agile Series – Episode 12
    16. Mai 2021
    kanban board miro
    Wie funktioniert Scrum und Kanban zusammen? || Agile Series – Episode 13
    30. Mai 2021
    23. Mai 2021
    Kategorie
    • Blog
    • DevOps
    Tags
    Das zweite Prinzip von DevOps

    Das zweite Prinzip von DevOps

    Das zweite Prinzip von DevOps (Second way of DevOps) || DevOps Series – Episode 5

    In diesem Artikel erklären wir das zweite Prinzip von DevOps (Second way of DevOps). Es geht also darum, wie man Feedback-Schleifen von den Operations-Leuten zu den Entwicklern verkürzt und verbessert. Dazu werden wir auch über Telemetrie sprechen. Wir werden natürlich auch noch verschiedenste Beispiele für Feedback-Schleifen nennen.

    In der letzten Folge haben wir die wichtigsten Frameworks für die Skalierung von Scrum vorgestellt. Also LeSS (Huge), Scrum of Scrums, SAFe und Nexus. Dabei haben wir jeweils die Vor- und Nachteile genannt und das – unserer Meinung nach – beste Framework gefunden.

    Schau also unbedingt hier vorbei falls du darüber mehr lernen willst.

    Das zweite Prinzip von DevOps

    Hierbei geht es darum Feedback der Operationsteams so schnell und so gut wie möglich zu den Entwicklerteams zu bringen. Dazu gehört auch diese Schleifen zu verstehen und zu kennen. Nur so können wir können wir Probleme im System viel schneller finden und damit auch viel einfacher beheben.

    Das zweite Prinzip von DevOps

    Das zweite Prinzip von DevOps

    Das erste Prinzip von DevOps (Flow) hat sich ja auf den Fluss von den Entwicklern (Devs) zu den Operationsteams (Ops) fokussiert. Im obigen Bild ist das der untere Pfeil. Das zweite Prinzip schließt nun diesen Kreis, indem wir ebenfalls versuchen das Feedback der Operationsteams möglichst schnell und direkt zu den Entwicklern zu bekommen. In obigen Bild ist das der obere Pfeil.

    Ziel des zweiten Prinzips ist es zum einen das nötige Wissen auf beiden Seiten zu etablieren, sodass Probleme im Betrieb im besten Fall erst garnicht auftreten oder wenn doch, dass die Operationsteams möglichst viel Verständnis für den Code haben, um diese schnell zu lösen. Zum anderen ist das Ziel, dass, sollte das nicht funktionieren, die Rückmeldung über Störungen, Bugs, … im System möglichst schnell zu den Entwicklern kommen, sodass diese noch wissen, was sie getan haben und damit die Probleme schneller beheben können.

    Feedback is the breakfast of Champions. – Ken Blanchard

    Je später wir ein Problem entdecken, desto größer ist es sehr wahrscheinlich geworden und desto schwieriger und teuerer wird es dieses Problem zu beheben. Dazu kommt, dass durch ein spät entdecktes Problem der ganze Value Stream blockiert sein kann und damit unnötige und vor allem teure Wartezeiten (Waste) entsteht.

    Was bedeutet das nun in der Praxis?

    Swarming verstehen:

    In den meisten Unternehmen gibt es verschiedene Support-Level. Also z.B. Level 1 Support, die die ersten Analysen machen, dann kommt Level 2 Support, der dann wieder Ticket Ping-Pong spielt und Rückfragen stellt und so verstreicht sehr viel Zeit, bis das eventuell sehr kritische und dringende Ticket beim richtigen Support-Level landet und dann hoffentlich endlich behoben wird.

    Tiered Support Levels

    Tiered Support Levels

    Wenn man das Problem aber so schnell wie möglich lösen will, dann kommt Swarming ins Spiel. Swarming bedeutet nichts anderes als wen auch immer man benötigt für die Lösung des Problems zu mobilisieren und fokussiert an dem Problem arbeiten zu lassen, bis es gelöst ist und der gesamte Value Stream wieder weiterarbeiten kann. Gerade wenn man aber in Komponenten-Teams organisiert ist, fällt das schwer und es fehlt auch oft der Überblick, was für Auswirkungen ein Defekt in „meiner“ Komponente auf das Gesamtsystem hat. Dazu werden wir bald noch einen Artikel veröffentlichen, also unbedingt den Newsletter abonnieren 😉 .

    Dadurch verhindern wir zusätzlich, dass das Problem sich weiter ausbreitet und dann auch zu Technical Debt wird, weil wir „gerade keine Zeit haben um das zu fixen“.

    Aus Problemen lernen:

    Das bedeutet das Problem nicht einfach nur zu lösen, sondern auch das Problem zu verstehen, warum das Problem überhaupt erst entstanden ist. Das ist extrem wichtig, weil wir sonst immer und immer wieder das gleiche Problem haben werden.

    technical debt

    Technical Debt Quelle: https://www.activestate.com/blog/technical-debt-high-tech-ceos-perspective/

    Dazu gehört auch, dass man das Problem und dessen Lösung dokumentiert. Am besten in einer Wiki, damit man danach suchen kann und alle im Unternehmen davon profitieren.

    Der nächste Schritt ist dann, dass die Prozesse so angepasst (adapt) werden, dass der Fehler garnicht mehr auftreten kann in Zukunft.

    Dies ist aber nur möglich, wenn im Unternehmen eine Kultur herrscht, in der man Fehler offen ansprechen und gemeinsam lösen kann. Stichwort Psychological Safety 😉 . Nur so werden die Mitarbeiter ermutigt, dass sie sich melden sobald ein Problem entsteht.

    Ziel ist es das Problem zu lösen und nicht jemanden zu bestrafen, da Fehler in einem komplexen System unvermeidbar sind.

    Nur wenn man diese Fehler früh identifizieret und löst, kann man als Unternehmen konkurrenzfähig bleiben.

    Built-in Quality

    Dies bedeutet, dass die Verantwortlichkeit für die Qualität des Produkts möglichst nah bei der Person sein sollte, die das Produkt entwickelt. So sind zum Beispiel Peer Reviews viel effektiver als eine Genehmigung eines Qualitätsmanagers oder ähnlichem, der aber nicht das Verständnis hat, was er gerade genehmigt.

    Ebenso sind Pull-Request (PR) Reviews eine sehr gute Möglichkeit die Qualität so hoch wie möglich zu halten. Hier gilt es aber auch diese zeitnah durchzuführen, um die Entwickler nicht zu lange warten zu lassen. Um schnelles Feedback zu ermöglichen sollte die Batch Size möglichst klein sein.

    Häufig haben wir dazu nach den Dailies einen Sync etabliert in dem spätestens über die offen PR Reviews gesprochen wird.

    Blameless Post-Mortems

    An dieser Stelle darf man natürlich sogenannte Blameless Post-Mortems nicht vergessen. Wichtig ist hierbei der Zusatz „Blameless“, der leider all zu oft vergessen wird. Es geht nämlich, wie oben bereits erwähnt, nicht darum irgendjemand die Schuld zuzuweisen, sondern das Problem zu lösen.

    Schuldzuweisungen lösen nämlich keine Problem, sondern verschlimmern diese nur.

    Das gilt für alle Beteiligten im Prozess. Egal ob Entwickler, Manager,….!

    Ein blameless Post-Mortem kann quasi als eine sehr technische und sehr spezifische Retrospektive bezeichnet werden. Es wird der Kontext analysiert, in dem der Fehler aufgetreten ist und die Entstehung des Fehlers. Dies, die Lösung und abgeleiteten Maßnahmen werden dann in einem Dokument festgehalten und veröffentlicht, dass möglichst alle im Unternehmen darauf zugreifen können.

    Automatisierte Kontrollen

    Unnötige, manuelle Kontrollen können sehr viel Verzögerung in ein, an sich, gut funktionierendes System bringen. Dazu gehören z.B. auch Genehmigungen von vielbeschäftigten Linemanagern.

    Das bedeutet nicht, dass wir keine Qualitätskontrolle oder Gates benötigen. Ganz im Gegenteil. Die Kontrollen sollten alle stattfinden, aber so weit es geht automatisiert sein, um schnell Feedback zu kommen. Hier kommen Techniken, wie CI/CD-Pipelines ins Spiel, da diese helfen möglichst viel zu automatisieren und dadurch sehr schnell Feedback liefern.

    Wenn du mehr zum Thema CI/CD-Pipelines wissen willst schau unbedingt hier vorbei!

    Fazit

    Das Ziel des zweiten Prinzips von DevOps ist es Feedback-Schleifen im gesamten Systems zu etablieren und zu  verbessern. Ziel ist es dabei diese so kurz und so früh einzubauen, wie nur möglich, sodass erst gar kein Technical Debt entsteht. Voraussetzung dafür ist, dass man möglichst viele dieser Schleifen automatisiert, indem man z.B. CI/CD-Pipelines einführt.

    Der eindeutige Mehrwert dadurch ist, dass Fehler viel früher gefunden werden, bevor sie kritisch werden und dadurch auch viel einfacher zu lösen sind. Dies führt wiederum dazu, dass das Unternehmen qualitativ hochwertigere und innovativere Produkte ausliefern kann und damit auch mehr Wert für die Kunden schaffen kann, was direkt zu gesteigerten Gewinnen und mehr Kunden führt.

    Voraussetzungen dafür sind aber ein Verständnis, auf allen Ebenen im Unternehmen, für DevOps, CI/CD-Pipelines, aber auch für eine Kultur, die Wert auf Psychological Safety legt.

    Du willst noch mehr wissen und hast noch Fragen oder bist anderer Meinung?

    Schreib uns das auch unbedingt in die Kommentare und wir werden dir gerne und ausführlich antworten!

    Da das jetzt alles wieder sehr viel Input auf einmal war, haben wir eine einfache Übersicht über alles was zum Scrum Rahmenwerk gehört, für dich in einem kostenlosen Poster dargestellt. Du findest es hier:

    Dein kostenloses Scrum Übersichtsposter!

    Link zum Poster

    Damit du all die gelernten Begriffe auch schnell nachschauen kannst, haben wir dir zusätzlich einen kostenlosen Glossar auf Deutsch mit +230 Begriffen zu DevOps, Agile und Lean mit den entsprechenden englischen Fachbegriffen (macht das Googeln meist einfacher, da es noch sehr wenige vollständige deutsche Blogs zu diesen Themen gibt) erstellt.

    Und auch der ist komplett kostenlos. Du findest den Glossar hier:

    Zum Glossar

    Ausblick

    In der nächsten Folge erklären wir dir, wie Scrum und Kanban zusammen funktionieren und was das für Vorteile hat.

    Falls du das nicht verpassen willst und ein noch besserer Scrum Master/Agile Coach/Product Owner/Entwickler oder Leader werden willst, melde dich jetzt für unseren kostenlosen Newsletter an:

    Dein kostenloser Newsletter!

    Unser Podcast

    Und falls du unsere Experteninterviews und alle anderen Podcast-Folgen als erster bequem unterwegs hören willst, abonnier einfach unseren Podcast mit folgendem RSS-Feed:

    Podcast RSS-Feed

    Agile Podcast iTunes
    Google Podcast
    Agile Podcast Spotify

    Unser YouTube-Channel

    Du stehst auf bewegtes Bild und zusätzliche Grafiken und Visualisierungen? Dann ab auf unseren YouTube-Channel „Agile Coach Academy“.

    Abonniere den Channel und verpasse kein Video oder Experteninterview mehr.

    Abonnier jetzt unseren YouTube-Channel

    Jetzt abonnieren

    Wie immer freuen wir uns auch wenn du diesen Artikel mit deinen Freunden, Kollegen und Bekannten teilst und uns dein ehrliches Feedback in den Kommentaren schickst.

    Wir freuen uns auf dich in der nächsten Folge.

    Deine Agile Coach Academy Gründer Ben und Alex

    Share
    4

    Ähnliche Beiträge

    Essenz aller Frameworks 21. Jahrhundert

    Die Essenz aller Frameworks des 21. Jahrhundert.

    1. August 2021

    Die 5 Must-Have Skills für DevOps || DevOps Series – Episode 10


    Mehr erfahren
    Fähigkeiten Agile Coach

    Die 5 wichtigsten Fähigkeiten eines Agile Coaches

    25. Juli 2021

    Die 5 wichtigsten Fähigkeiten eines Agile Coach || Agile Series – Episode 17


    Mehr erfahren
    Die 6 DevOps Erfolgsfaktoren

    Die 6 DevOps Erfolgsfaktoren

    18. Juli 2021

    Die 6 Erfolgsfaktoren für DevOps || DevOps Series – Episode 9


    Mehr erfahren
    Agile Transformation Herausforderungen

    Mangelndes Training und Wissen als große Herausforderung einer Agile Transformation

    11. Juli 2021

    Agile Transformation – die 5 größten Herausforderungen || Agile Series – Episode 16


    Mehr erfahren
    5 Schritte Theory of Constraints

    Die 5 Schritte der Theory of Constraints

    4. Juli 2021

    Die Theory of Constraints erklärt || DevOps Series – Episode 8


    Mehr erfahren
    effektive scrum teams devops teams

    Effektive Teams

    27. Juni 2021

    Was macht ein effektives Scrum Team bzw DevOps Team aus? || Agile Series – Episode 15


    Mehr erfahren

    Schreibe einen Kommentar Antworten abbrechen

    Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

    Weitere spannende Impulse

    • Essenz aller Frameworks 21. JahrhundertDie 5 Must-Have Skills für DevOps || DevOps Series – Episode 10
      Lesezeit: 14 Min

      In diesem Artikel erklären wir dir was die 5 wichtigsten Skills für DevOps sind. Sowohl auf Management-, als auch auf Team-Ebene.  Wir erklären dir auch was für spezifische Skills nötig sind für die jeweilige Kategorie. […]
    • Fähigkeiten Agile CoachDie 5 wichtigsten Fähigkeiten eines Agile Coach || Agile Series – Episode …
      Lesezeit: 12 Min

      In diesem Artikel erklären wir dir was unserer Meinung nach die 5 wichtigsten Fähigkeiten eines Agile Coaches sind und wie diese einem Unternehmen helfen. […]
    • Die 6 DevOps ErfolgsfaktorenDie 6 Erfolgsfaktoren für DevOps || DevOps Series – Episode 9
      Lesezeit: 14 Min

      In diesem Artikel erklären wir dir was die 6 wichtigsten Erfolgsfaktoren für DevOps sind und was das für die Organisation allgemein bedeutet. […]
    • Agile Transformation HerausforderungenAgile Transformation – die 5 größten Herausforderungen || Agile Series …
      Lesezeit: 16 Min

      In diesem Artikel erklären wir dir was die 5 größten Herausforderungen einer Agile Transformation und wie man diese verbessern oder gar verhindern kann und natürlich auch was sich für Vorteile dann ergeben. […]
    • 5 Schritte Theory of ConstraintsDie Theory of Constraints erklärt || DevOps Series – Episode 8
      Lesezeit: 10 Min

      In diesem Artikel erklären wir dir alles rund um die Theory of Constraints von Goldratt. Also was ist ein Bottleneck (Flaschenhals) bzw. ein Constraint (Einschränkung), was die Schritte dieser Methode sind und wir werden natürlich auch ein Beispiel für die Theory of Constraint geben. […]
    Agile Coach Academy

    Agile Coach Academy

    loslegen@agile-life.de

    Zertifizierte Coaches

    PSM1-Batch PSM2-Batch SPS-Batch PSM1-Batch
    Impressum | Datenschutz
    © 2022 Agile Coach Academy

    created by

    kuss-maul-marketing-hautnah