Das Internet ist voll von Beiträgen, die behaupten, DevOps sei tot. “DevOps ist Schwachsinn.” “Platform Engineering wird DevOps ersetzen.” “SRE ist die Zukunft.” In diesem Video erkläre ich, warum all diese Behauptungen falsch sind, woher sie kommen und wie DevOps, Platform Engineering und Site Reliability Engineering tatsächlich zusammenhängen.
Wie stellt man sicher, dass die eigene Organisation nicht mit zu vielen Projekten, zu vielen Ideen und zu wenig Fokus überlastet wird? Und wie stellt man sicher, dass man das Richtige baut? Genau dafür gibt es Epics. In diesem Video erkläre ich das Konzept der Epics, zeige ein konkretes Beispiel und erläutere, warum Epics deutlich effektiver sind als traditionelle Projekte.
Gemeinsam mit meiner Kollegin Nadine habe ich eine aktualisierte Version unseres partizipativen Budgetierungsansatzes vorgestellt. Wir hatten bereits die erste Version an einem früheren Event geteilt, aber seither haben wir einiges verändert, das wir natürlich nicht vorenthalten wollten. Ein kurzer Disclaimer: Wir haben Participatory Budgeting nicht erfunden. Wir haben auf den Vorlagen des SAFe (Scaled Agile Framework) aufgebaut, daher findet ihr auch das Copyright auf den relevanten Folien. Wenn ihr selbst Participatory Budgeting bei euch einführen wollt, sind wir gerne bereit, unsere Erfahrung zu teilen, und verweisen dabei immer auf die Originalpräsentation und Originalunterlagen von SAFe.
Der erste Weg, DevOps einzuführen, besteht darin, den Value Flow von Development über Operations bis zum Kunden zu optimieren. Das ist der First Way im Three-Ways-Framework von Gene Kim — und genau dort sollte jede Transformation starten.
Ein Wertstrom ist der Weg, den Wert von der ersten Idee bis in die Produktion zurücklegt. Er ist die Summe aller Schritte, Übergaben und Wartezeiten dazwischen. In diesem Video zeige ich ein einfaches Vorgehen in sieben Schritten: einen Wertstrom identifizieren, ehrlich messen, ein Zielbild entwerfen und dann Schritt für Schritt dorthin arbeiten. Die Zahlen im Beispiel sind bewusst vereinfacht, damit die Methode im Vordergrund steht und nicht ein einzelnes Ergebnis.
Wenn du ein Entwicklungsteam fragst, wo Wert entsteht, bekommst du ein Dutzend unterschiedliche Antworten. Im Planning-Workshop. Im Sprint. Beim Demo. Beim Deployment. Sie liegen alle falsch — und genau dieser Denkfehler ist der Grund, warum die meisten DevOps-Business-Cases beim CFO auseinanderfallen.
In einer Welt voller Aufgaben, To-do-Listen und konkurrierender Prioritäten war es noch nie so herausfordernd, produktiv und fokussiert zu bleiben. Personal Kanban ist eine leichtgewichtige, visuelle Methode für Workflow-Management, die im Toyota Production System verwurzelt ist und von Jim Benson und Tonianne DeMaria Barry für den individuellen Einsatz adaptiert wurde.
