In dieser Folge haben wir André Claassen zu Gast. Wir sprechen über OKR (Objectives & Key Results) und die Verbindung zu DevOps. Was sind OKRs und wie kann man sie im DevOps-Umfeld nutzen. Sind OKRs nur etwas für größere Unternehmen oder kann man sie auch in kleineren Organisationen oder sogar Start-Ups nutzen? Wofür werden OKRs überhaupt eingesetzt?
In dieser Episode diskutieren Luca Ingianni und Dierk Söllner zusammen mit dem Gast André Claassen die Schnittstelle zwischen DevOps und OKR und vertiefen sich darin, wie diese Rahmenwerke in der Praxis integriert werden können. Klaassen betont die Bedeutung von zielorientierter Planung und deren Einsatz zur Förderung organisatorischen und kulturellen Wandels. Er bietet Einblicke in die Messung von Ergebnissen statt Outputs und die Notwendigkeit, Strategien anzupassen, um einen agileren und effektiveren Ansatz für Projektmanagement und Softwareentwicklung zu fördern. Die Diskussion berührt auch Herausforderungen und Chancen bei der Anwendung von OKR im DevOps-Kontext.
Inhalt
- Einführung in den Schwerpunkt der Episode auf DevOps und OKR.
- André Claassens Hintergrund und Expertise in agiler Arbeit und Digitalisierung.
- Diskussion über Objectives and Key Results (OKR) und deren Integration in DevOps.
- Die Bedeutung kultureller, organisatorischer und technischer Aspekte bei der Implementierung von OKR in DevOps.
- Einblick in das Konzept der ergebnisorientierten Planung.
- Die Relevanz messbarer Schlüsselergebnisse und der Fokus auf Ergebnisse statt Outputs.
- Herausforderungen und Strategien bei der Anwendung von OKR in verschiedenen organisatorischen Kontexten.
- Empfohlene Ressourcen und Literatur für die weitere Erkundung von OKR und DevOps.
Shownotes:
Buchempfehlung: Outcome over Output von Josh Seiden
Präsentation Roadmaps are Dead
Podcast Ziele setzen, Ziele erreichen mit OKR
Webseite von André Claassen
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
DevOps. Auf die Ohren und ins Hirn. Ein Podcast rund um DevOps. Von Luca Injani 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 Injani und Dirk Söllner. Ich freue mich,
dass Luca heute dabei ist, denn er hat eigentlich aktuell Wichtigeres zu tun. Also
hallo Luca, freut mich, dass du zu Beginn und hoffentlich auch zu Ende dabei bist.
Ja, hallo ihr beiden.
Gut, was das Wichtigere ist, darf ich auch noch kurz erwähnen. Luca sitzt auf heißen
Kohlen, weil er so etwas wie einen Entbindungstermin hat. Also wie gesagt, freut mich, dass du
dabei bist. Luca und ich sind DevOps-Trainer und Coaches. Wir haben langjährige Erfahrung
und für uns ist der Punkt, DevOps immer, dass wir…
Kulturelle, organisatorische und technische Aspekte damit reinbringen. Heute reden wir
ein bisschen was über Kultur, über organisatorische Punkte eventuell auch. In dem Podcast diskutieren
wir das immer mit Experten aus der Praxis oder Luca oder ich auch gemeinsam in einer
Folge, wo wir uns einfach nur ein bisschen unterhalten. Aber heute haben wir einen Experten
aus der Praxis und mit dem werden wir uns hoffentlich auch gut unterhalten. Wir haben
heute das Thema DevOps und OKR. DevOps ist ja schon seit Jahren so ein Modewort, ein
Hype-Thema.
OKR kommt langsam auch in diese Regionen. Also insofern freuen wir uns, dass wir diese
beiden Themen zusammenbringen können. André Klaassen ist unser Gast. André war schon
mal vor zwei Jahren da bei uns zu Gast im Podcast. Insofern, André, würde ich sagen,
stell dich einfach mal ganz kurz vor. André Klaassen
Ja, mein Name ist André Klaassen. Ich freue mich, dass ich heute bei euch dabei sein darf.
Heute mit einem anderen Thema. Vor zwei Jahren haben wir, glaube ich, über das Thema agile
Arbeit im Allgemeinen gesprochen und Digitalisierung. André Klaassen, du hast ja auch schon gesagt,
du hast ja auch schon gesagt, du hast ja auch schon gesagt, du hast ja auch schon gesagt, du hast
gesagt, du hast noch PAR 찬 agreee’t und gesagt. Heute geht es um das
Thema Objectives and Key Results, was meine Passion geworden ist, oder als dahin zu sprechen.
Also ein Framework zur Zielvereinbarung und Umsetzung, auch im agilen Kontext. André
Klaassen
Ich selbst habe über 30 Jahre Erfahrung in Projektmanagement, IT-Projekten, aber
auch Organisationsberatung und Strategieentwicklung. Meine Heimatbranche war lange Zeit Public Sector,
öffentliche Verwaltung, aber ich bewege mich mittlerweile auch in ein Normales Projekt.
André Klaassen
Genau.
Let’s get into it, Herr irregular급àngなんか.
André Klaassen
In anderen Gefilden Mittelstand, Energiesektor und Automotive und freue mich sehr auf das heutige Gespräch, wo es sicher die eine oder andere Idee gibt, über die wir dann gerne reden können.
Sehr schön. Ja, und in dem Vorgespräch, in der Vorbereitung haben wir auch schon festgestellt, dass es ein Thema ist, was vielleicht noch gar nicht so viel Praxiserfahrung mitbringt, wo es auch vielleicht noch gar nicht so viel, sag ich mal, Literatur oder Blogbeiträge dazu gibt, wie zu anderen Themen.
Aber wenn man mal schaut, was du so alles schon mal zusammengetragen hast an Themen, dann glaube ich, wird uns nicht langweilig in dieser dreiviertel Stunde Stunde.
Und insofern, André, wir freuen uns.
Wir fangen bei unseren Gästen immer damit an, dass wir sie fragen, wie sie DevOps definieren würden.
Wir haben uns jetzt nicht die Mühe gemacht, zu gucken, wie du DevOps vor dem letzten Podcast definiert oder beschrieben hast, aber einfach nochmal frei raus, wie würdest du DevOps beschreiben?
Ja, ich bin ganz ehrlich, das ist ein Begriff, der sich für mich auch weiterentwickelt, wie auch das Thema agile Arbeit oder Objectives and Key Results.
Heute.
Würde ich sagen, also für mich ist der DevOps die Übersetzung der Prinzipien des Lean Management, also tatsächlich ein Stück weit aus dem Toyota Production System heraus in die Welt der IT.
Also die Idee ist, Wertschöpfung mit Kundennutzen zu generieren, einen Fluss an Lösungen zu etablieren in cross-funktionaler Arbeit.
Da sind Dev, also Developer Operations drin, für mich aber auch noch andere Experten.
Die notwendig sind, um den Wertefluss zu etablieren und um diesen Wertefluss auch gut umsetzen zu können, zählt auch das Thema Automatisierung rein.
Ich kann aber auch vielleicht sagen, was DevOps für mich nicht ist.
DevOps ist für mich nicht die meisterhafte Beherrschung von Integration Tools oder Kubernetes oder sonstigen Dingen.
Also, weil das habe ich oft festgestellt, dass in dem Kontext der technischen Automatisierung.
Das Thema sehr stark ist.
Ich sehe es genau wie du es gesagt hast, Dirk und Luca.
Es ist auch ein kulturelles Thema, weil ich brauche tatsächlich ein Stück weit eine andere Geisteshaltung, um DevOps richtig gut machen zu können.
So, jetzt habe ich sehr lange Monologen gesichert über DevOps.
Ist alles falsch oder was sagt ihr dazu?
Also ich sage ja immer, es gibt nicht falsch und es gibt nicht richtig, es gibt passend oder nicht passend.
Aber zum Thema Kultur und Technik, da hat Luca ja auch seine Meinung.
Ja, also ich sehe das nämlich ganz genau so.
Technologie ist an dieser Stelle halt nur ein Mittel zum Zweck.
Ja.
Und Kubernetes ist gut und schön, aber wenn du es nicht unterfütterst mit entsprechenden passenden Ansätzen, was Methoden angeht und so weiter,
dann hast du halt einfach nur ein neues Problem ans Bein gebunden, aber eigentlich nichts gelöst.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Okay.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Du kannst also bei OKRs tatsächlich, wenn du jetzt nur auf die Methode schaust, nur auf, vielleicht sogar auch nur auf Tools,
jetzt gibt das gar nicht so heiße sophisticated Tools, ja, sondern es sind am Ende reden wir hier über Performance Management Tools,
aber wenn du nur auf die Tool- und Methodenecke schaust, dann kann OKR ein Klotz am Bein werden.
Dann kann OKR ein Bürokratiemonster sogar.
werden, indem ich nämlich anfange, Ziele zu verwalten,
statt Ziele umzusetzen. Und
hier brauche ich, genau wie bei DevOps, einfach ein Stück weit eine andere
Kultur, ist übrigens auch das Thema, was ich mitgebracht habe,
nämlich das Denken in Wirkung. Was will ich denn wirklich
erzielen und was will ich denn wirklich bewirken mit meinen Lösungen?
Und diese
Geisteshaltung, tatsächlich ergebnisorientiert zu
denken, ich sage jetzt mal flapsig, das ist ja etwas, was man unserer Bundeskanzlerin
unterstellt, also von hinten zu denken, das hat
eine hohe Ernsthaftigkeit. Und da können
OKRs sehr helfen, aus meiner Sicht auch und gerade bei
DevOps. Aber wenn ich das nicht kultiviere, sondern nur
meine klassischen Projekte,
meine Aufgaben, meine Outputs, meine Features, vielleicht auch meine Roadmaps einfach nur in Form
eines OKRs darstelle, ja, dann habe ich erstmal gar nichts gewonnen, sondern
vielleicht wäre sogar noch ein gutes Stück mehr Arbeit aufgeschafft. Aber sind wir
vielleicht schon sehr, sehr weit in dem Thema? Vielleicht sollten wir erstmal vorne anfangen.
Ja, ja, ist aber
ein kleiner Teaser, dass alle, ah, da kommt noch was und da,
okay. Also, du hast die Frage dir selbst gestellt. Lass uns
vorne anfangen. Was ist dieses OKR eigentlich?
Ja, OKR steht für Objectives and Key Results, also
Ziele und Schlüsselergebnisse. Und das scheint
ja auch erstmal sehr, sehr einleuchtend zu sein. Historisch ist es tatsächlich
eine Erweiterung des Management
by Objective and Self-Control, also ich wiederhole
and Self-Control von Peter Dracker. Peter Dracker,
Management-Papst der 60er, 70er,
und 80er Jahre, hat eben überlegt, wie kann ich
Wissensarbeit, die immer wichtiger wird und die einen immer größeren
Anteil an Arbeit umfasst, wie kann ich die besser organisieren?
Und eine Idee war, die hat er sogar ein Stück weit
von dem preußischen General
Herrn Moltke übernommen, zu sagen, eine
Idee ist es eigentlich, Aufgaben vom Ergebnis
her aus zu beschreiben, also den,
Ziel zu beschreiben, aber nicht zu viel Lösungen zu beschreiben.
Und diese Ziele gut vereinbart ermöglichen Self-Control,
also Selbstmanagement und Selbstorganisation.
Das war die ursprüngliche Idee von MBO.
Alles, was wir heute unter Performance Management und Zielvereinbarung sehen,
ist die methodische Ableitung, die aus meiner Sicht auch teilweise
überhaupt nichts mehr mit dem Planen dieser Idee zu tun hat.
Und daraus wurde ein objektives,
ein Key Result auf eine sehr pragmatische Weise.
Das hat Andy Goof, ehemaliger Manager von Intel,
weiterentwickeln hat gesagt, er muss mal zu Andy Goof auch sagen,
Manager des Jahres, weiß ich nicht, 1996.
Also wirklich sehr erfolgreicher Manager, aber von Natur aus Chemiker,
also pragmatischer Naturwissenschaftler, hat gesagt Egal, was wir hier bei Intel tun,
ich brauche einfach irgendwie ein Kriterium, woran ich erkenne,
sind die Dinge fertig oder nicht?
Also wirklich jetzt mal ganz basal.
Und er hat dieses Thema OKR dann kultiviert bei Intel und hat gesagt,
es geht überhaupt nicht darum, ob ihr Ziele verfehlt oder erreicht.
Es geht einfach nur darum, dass wir wissen, wo wir gerade stehen und mit welchem Tempo
wir gerade unterwegs sind.
Und er hat die Idee von Peter Dracker, also das Management by Objectives in Self-Control
aufgegriffen, hat es zu OKRs weiterentwickelt.
Und das war einfach so die Form des Berichtswesens bei Intel, aber auch in Form von Transparenz.
Das heißt also, diese Ziele, diese Objectives und die messbaren Schlüsselergebnisse,
die waren tatsächlich in dem Unternehmen überall präsent und die konnte auch jeder einsehen.
Wichtig ist halt das Thema, also das betonte Andy Groove auch immer wieder,
es ist keine Performance Management, es ist keine Leistungsüberwachung von Teams oder
Personen, sondern es ist einfach nur ein Tool.
Um letztendlich Klarheit in der Sache zu schaffen.
Heute sind wir aber viel weiter und das OKR hat sich weiterentwickelt.
Es ist auch ein offenes System.
Es gibt also keine Firma oder Institution, die definiert, was OKR macht.
Ich glaube, das ist ein bisschen ähnlich wie bei DevOps, wo es meines Wissens auch
keine Firma gibt, die da die Hand drauf hat.
Und OKR ist halt insofern ein offenes Framework und dient heute.
Im Jahr 2018.
Ja.
Und ich glaube, das ist auch ein offenes System, das wir in den nächsten Jahren,
im Jahr 2021, dazu Strategien umzusetzen und zwar auf agile Art.
Die Idee ist, ich setze mir in einer Kadenz, beispielsweise in drei Monatsintervallen,
das können aber auch andere Widmen sein, Wirkungsziele.
Das heißt, ich überlege mir, was möchte ich in drei Monaten fokussiert an Wirkung
bewegen?
Wo ist der große Hebel in meinem Business?
Wo ist der große Kundennutzen, den ich heben möchte?
Und daraus entwickle ich ein sehr kleines, knackiges OKR-Set, aus meiner Sicht maximal
drei Ziele, vielleicht sogar nur ein Ziel, den großen Hebel, und den beschreibe ich
dann in Objectives & Key Results.
Gleich nochmal zu den Key Results, Messschlüsselergebnisse.
Hier geht es darum, tatsächlich Messbarkeit darzustellen, also ein Key Result ohne Zahl
ist kein Key Result.
Das ist platt dahergesagt.
Aber das ist ein Key Result.
Aber das ist tatsächlich sehr, sehr wichtig, weil ich auch in meiner Praxis ganz oft feststelle,
dass das ein Punkt ist, wo tatsächlich ein Stück weit Übung erforderlich ist.
Ja, also viele Aufgaben sind entweder erledigt oder nicht, und das ist eigentlich kein gutes
Key Result.
Gleich möchte ich, wenn ihr mich lasst, aber das werden wir dann sehen, auf das Thema Outcome
zu sprechen kommen, weil das ist aus meiner Sicht das kleine Geheimnis hinter OKR.
Okay.
Aber nicht.
Darf ich kurz dazwischengrätschen?
Ja.
Weil nämlich, also bevor ich dich über Outcomes reden lasse, würde ich mir wahnsinnig wünschen,
dass du das vielleicht noch ein bisschen konkreter machst, wie so ein OKR aussieht.
Ich bin mir nicht sicher, ob unsere Hörer sich das wirklich gut vorstellen können.
Was ist denn das?
Ist das ein Projektantrag?
Ja, es ist erstmal, es ist kein Projektantrag, sondern OKR ist ein Ziel, das ich mir in einem
Team oder in einer Organisation vorstelle.
Das OKR hat aus meiner Sicht jetzt nicht die Absicht, alle Themenfelder, die es gibt,
jetzt abzudecken, sondern eigentlich den Hebel zu finden, also die Fokussierung auf bestimmte
Themen, die wir in einem Quartal erzielen wollen.
Jetzt ist es natürlich nicht ganz so einfach.
Jetzt generische OKRs zu nennen, ich nenne mal jetzt, weiß ich nicht, ein Beispiel aus
meiner eigenen Praxis.
Ich bin ja auch Solopreneur, also selbstständig, aber letztendlich auch Einzelunternehmer und
ich mache diesen, mache regelmäßig Podcasts, um Sichtbarkeit und Expertentum einfach auch
darzustellen.
Ja.
Und.
Das zahlt ein Stück weit möglicherweise hoffentlich auch auf das Business ein, dass
also Leute mich ansprechen und sagen, hey, André, wir haben auch Interesse an Zielsystemen,
kannst du uns unterstützen?
Das Outcome, also die langfristige Wirkung, die ich eigentlich erzielen möchte, ist,
dass ich Kundeninteresse wecke und auch Sichtbarkeit erziele.
Um das zu tun, könnte ich jetzt als OKR beispielsweise formulieren.
Ich möchte.
Ich möchte meine Sichtbarkeit, meine Expertise erhöhen und ein Ziel in diesem Jahr wäre
es, weiß ich nicht, fünf Podcastgespräche durchzuführen.
Ja, weil wenn ich diese Gespräche durchgeführt habe, dann habe ich eine Wirkung erzielt oder
oder einen Indikator dafür erzielt, dass ich halt sichtbarer bin.
Aber ich merke gerade so richtig gut ist das Beispiel auch nicht.
Vielleicht nehme ich mal ein anderes Beispiel aus dem.
Aus dem Supermarkt.
Aus dem Support und lege auch mal so ein bisschen die wichtigsten Kernbegriffe auseinander.
Im Support könnte es sein, dass wir sagen Hey, wir müssen mal im Support Kosten sparen.
Ja, wir haben irgendwie zu viele Support Gespräche im Support.
Das Thema Kosten sparen oder das Reduzieren von Support Gesprächen, das ist etwas, das
bezeichne ich als langfristige Wirkung.
Auf Englisch Impact.
Also die langfristige Wirkung ist eigentlich die, die ich haben möchte, dass ich möglichst
wenig Support mache.
Ich sage sogar mal extrem, am schönsten wäre es, man müsste überhaupt keinen Support
machen.
Stimmt.
Also ich habe ein Produkt, das ist so wartungsfrei und so selbsterklärend und so robust und
so trivial, dass das Telefon gar nicht klingelt und dass das Ticketsystem verweist, ja, ist
eine Utopie.
Ja.
Aber eine Wirkung, die ich tatsächlich langfristig erreichen könnte.
Ich könnte sogar eine Mission daraus abbilden und sagen, unsere Mission ist es, unsere Produkte
so klar, einfach und wartungsarm zu machen, dass wir keine Support Anfragen bekommen.
Jetzt haben wir aber in der Praxis festgestellt, doch, wir haben natürlich eine ganze Menge
Support Anfragen.
Die Support Anfragen drehen sich um fünf Schlüsselthemen, die immer und immer und immer wieder benannt
werden.
Und diese fünf Schlüsselthemen sind im Produkt.
Das sind Produktprobleme.
Ein Outcome wäre jetzt zu sagen, auch im Sinne eines OKRs, wir möchten diese fünf
Produktprobleme lösen.
Ja.
Und wir messen das dadurch, dass wir nicht nur diese fünf Produktprobleme angepackt
haben, sondern wir messen das dadurch, dass wir, und das ist die Wirkung, die wir erzielen
wollen, die Anfragen zu diesen fünf Themenfeldern von X auf Y zurückgehen.
Das wäre das Key Result, das wir wirklich haben wollen.
Die Anzahl der Support Anfragen für diese fünf Produktthemen gehen von X, also heute
1000 pro Monat auf, weiß ich nicht, 500 pro Monat zurück.
Das ist die Wirkung.
Der Frühindikator, also die Metrik, die wir selbst in der Hand haben und die uns eine
Indikation darüber gibt, dass wir das auch wirklich erreichen, ist, tatsächlich diese
fünf Produktprobleme zu lösen.
Das wäre das Frühindikator.
Und das zweite Key Result, wir lösen die fünf Produktprobleme.
Auch das möchten wir in diesem OKR formulieren.
Und dann könnte man vielleicht nochmal ein drittes Key Result reinnehmen mit Kundenwirkung,
dass wir zu diesen fünf gelösten Kundenproblemen nochmal ein qualifiziertes Kundenfeedback
einholen, um einfach zu schauen, ob wir hier eine nachhaltige Wirkung erzielt haben.
Und das wäre ein Thema, Fokussierung auf ein Themenfeld, Überlegung, was ist das, was
ist die nachhaltige Wirkung, die wir erreichen wollen?
Messbar.
Das wäre Key Result eins, Überlegung, was können wir selbst tun, von dem wir glauben,
dass es diese nachhaltige Wirkung befeuert?
Key Result zwei und vielleicht nochmal ein Key Result drei, um das Ganze abzurunden aus
Sicht der Kundensicht.
Also das wäre so etwas, was ich als gutes OKR bezeichnen würde.
Okay.
Ich finde das ja super als Beispiel, weil das mir wirklich das nochmal klar macht und
weil für mich dabei auch rauskommt, diese Ergebnisorientierung, das, was du eben genannt
hast, wenn man da so eine Arbeitsgruppe bilden würde oder wie auch immer man das nennt, dann
würde man ja, würden die meisten ja sofort überlegen, was können wir machen, um das
zu erreichen?
Also man denkt dann sofort in den, in den Maßnahmen, anstatt zu beginnen, was sind
wirklich die Themen, die uns bewegen?
Also wo wollen wir nachhaltig eben Ergebnisse erzielen?
Okay.
Und das wirklich eben von hinten nach vorne das Pferd aufzuzäunen.
Sehr schön.
Und das ist eben gar nicht so einfach, wie sich das anhört und auch nicht einfach
auszuhalten.
Wenn ich über Ergebnisse rede, die ich erzielen will und das wichtigste Ergebnis ist die Reduktion
der Support-Anfragen.
Das ist eigentlich das, was richtig spannend ist.
Die fünf Produktprobleme ist, die ich lösen möchte, also dieser Frühindikator ist eine
Hypothese.
Es kann sein, dass ich nach Beleuchtung des Problems herausstelle, das ist eigentlich ein
ganz anderes Problem.
Wir haben immer gedacht, das sind die fünf Produktprobleme.
Quatsch.
Da war nun Readme falsch.
Ja.
Die Punkte sind wunderbar gelöst.
Es ist nur ein oder zwei Fehler drin gewesen in der Produktbeschreibung.
Ja.
So.
Das heißt also, diese Fokussierung auf die Wirkung, das ist eigentlich die Schlüsselmetrik.
Wir wollen die Support-Aufwände runterkriegen.
Und Ihr Team überlegt euch jetzt.
Ja.
Ja.
Was wäre aus eurer Sicht die beste Maßnahme, um dieses Delta zu erzielen?
Das ist halt spannend, da hinzukommen und das zu erarbeiten.
Die Formulierung lösbarer, aber interessanter Probleme, die einen Nutzen fürs Business
haben.
Mhm.
Und wenn ich das jetzt mal mit meinen Erfahrungen aus der Praxis vergleiche, wie ich OKR wahrnehme,
dann ist das auch ein Unterschied für mich.
Und das kann man ja auch gleich nochmal erklären.
Für mich ist OKR häufig auch in der Anwendung, dass man das nutzt, um Unternehmensziele, die
man erreichen möchte, quasi runterzubrechen auf Bereichsziele, auf Mitarbeiterziele, also
wirklich von oben nach unten Ziele runterzubrechen.
Ja.
Was ja erstmal, finde ich, sehr, sehr plausibel ist.
Was ja auch dazu führen würde, dass sich die Unternehmensleitung wirklich Ziele überlegt,
die sie erreichen wollen.
Und in der Regel, wenn man dann die Ziele, die sie erreichen wollen, dann muss man ja
erreichen wollen und in Ergebnissen denkt und dann versucht, zu gucken, wer, in welchem
Bereich kann man das, mit welchen Mitarbeitern, mit welchem Wissen erreichen.
Aber eben im Unterschied zu deinem Beispiel, quasi ein System, was ich auf ein gesamtes
Unternehmen ausdehne, wie ist denn da so, was ist denn da richtig sozusagen?
Also, ich kann OKR sehr, sehr gut nutzen, um Unternehmensstrategien umzusetzen.
Ja.
Es ist aber in dieser Zielkaskade, die du beschreibst, die auch sehr, sehr häufig gemacht
wird und die auch für viele Unternehmen erstmal der einfachste Weg ist in Richtung OKR, ein
Stück weit das Problem, dass wir dann sehr stark auf die Aufbauorganisation gucken.
Ja.
Das heißt also, es geht tatsächlich genau in der Aufbauorganisation runter.
Die meisten spannenden Stellen.
Probleme oder Herausforderungen bei Unternehmen sind aber eher in der Ablauforganisation zu
finden, als im Wertestrom.
Und daher ist es spannend, auch bei der Nutzung von OKRs eine Kultur zu etablieren, die darauf
abzielt, die Aufbauorganisation ein Stück weit zu ignorieren, um das mal beispielhaft
zu machen.
Ja.
Ich habe jetzt als Unternehmensziel.
Ja.
Ich nenne das jetzt, weil es ist ja kein schönes Ziel, Kosten zu sparen, ist eigentlich kein
gutes OKR, aber angenommen, es ist wirklich jetzt ein Thema, wir müssen jetzt Kosten
sparen, ist jetzt wirklich kein gutes OKR, dann ist dieses Ziel nicht gut operationalisierbar
in den unterschiedlichen Bereichen.
Was aber cool wäre, wäre, wenn wir sagen, okay, wir haben alle erkannt, das ist wirklich
gut, das ist jetzt nicht nur irgendwie eine Plattitüde, sondern wir müssen das tun, ja,
dass wir dann auf der Ebene der Unternehmensleitung und vielleicht auch zwei Ebenen darunter gemeinsam
überlegen, was können wir jetzt tun, um dieses Ziel maximal zu befeuern, auch vor dem
Hintergrund der Mitarbeiter, auf dem Hintergrund der langfristigen Ziele und lasst uns Ideen
entwickeln.
Das heißt, ich ignoriere bewusst mal dieses.
Ja.
Nicht nur das jetzt mal an die Bereiche und die geben das an die Abteilung weiter, sondern
wir überlegen gemeinsam mit der Intelligenz des Unternehmens, was können wir denn jetzt
tun, um das tatsächlich zu tun, was wären die wirksamsten Hebel und sinnvollsten Hebel,
um das zu tun.
Und deshalb finde ich es auch bei einer Unternehmenshierarchie, sogar auch bei Konzernen sehr, sehr spannend,
auch nicht in die Bereiche zu gehen, also der, weiß ich nicht, der Vorstand beschließt
ein OKR und das gibt ihr dann an die Bereiche, sondern ein Team zu bilden, das dann gemeinsam
überlegt, okay, was können wir denn jetzt wirklich auch auf dieser Ebene tun, um das
jetzt konkret umzusetzen und was, und da bin ich jetzt auch bei den Key Results, was sind
Dinge, bei denen wir selbst wirksam erkennen können, dass wir Fortschritt machen in dem
Thema.
Ja.
Wir kommen weiter und es tut uns gut und das sind andere Lösungen.
So, und dann funktioniert das auch auf der Unternehmensebene gut, wichtig ist, ich habe
keine Inflation an Zielen, sondern ich habe tatsächlich Fokussiele, ich habe, ich benutze
OKR, um die Hebel in Bewegung zu setzen, die jetzt aktuell am meisten drücken und am stärksten
auf die langfristigen Ziele einsetzen, das ist also wichtig, das zu finden.
Ja, weiß nicht, wie ich mir das überlege, weil du sagst jetzt, wir ignorieren die Auffahrorganisationen,
das ist für mich der Punkt, weil du vorhin sagtest, das ist eigentlich ganz einfach beschrieben,
aber schwierig umzusetzen, weil das hört sich jetzt so wunderschön im Podcast an und
ist auch sicherlich eine gute Idee, aber ich denke, man kann ja, oder es wird schwierig,
Realitäten, nämlich da ist eine Auffahrorganisation, die kann man ja insofern nicht ignorieren,
aber als Ziel.
Als Gedankenexperiment und auch als Prämisse finde ich das schon ein sehr schöner Ansatz
und das ist das, was ich jetzt hier heute schon gelernt habe, das ist letzten Endes
genau, also man kann das nutzen, wie du auch gesagt hast, aber man sollte auch mal über
den Tellerrand blicken und eben zum Beispiel auch sagen, wir gehen jetzt nicht in einer
klassischen Aufbauorganisationshierarchie runter, sondern wir haben irgendwelche Themen,
die wir erreichen wollen, übergreifend und wir setzen dann ein, ich nenne es mal OKR-Team,
das kannst du vielleicht gleich nochmal ein bisschen diskutieren.
Wir setzen ein OKR-Team zusammen und sagen, wie kriegen wir dieses Ziel erreicht?
Ja, es hängt von der Unternehmensgröße ab, das ist ganz klar.
Wenn ich ein Großkonzern habe, dann ist das, was ich sage, möglicherweise auch nicht sinnvoll.
Ich muss dann schon in Bereichen denken, weil die einfach auch unterschiedliche Rollen haben,
aber die Botschaft, die ich loswerden will, ist, das Design der Unternehmensziele mit
so zu denken, dass ich bei der Gestaltung auch ein Stück weit die Intelligenz habe,
die ich in der Unternehmensgröße habe.
Dass ich die Intelligenz des erweiterten Führungsteams nutze und die Intelligenz auch von Experten,
die helfen können, dass ich das einfach noch benutze, jetzt mal ein Stück weit.
Hier ist übrigens Indy Goof, Manager von Intel, ganz hilfreich, weil er sagte, Führungskräfte
sind in meinem Verständnis natürlich die Manager der Aufbauorganisation plus die Fachexperten
in den verschiedenen Units.
Er sagt, ich kann auf diese Experten aufhören.
Ich kann auf diese Expertise überhaupt nicht verzichten, wenn ich strategische Entscheidungen,
die intelligent sind, entwickeln werde.
Das heißt, für mich sind das genauso Führungskräfte im Sinne von Führung des Unternehmens in die
Zukunft.
Und was er damit sagen will, ist, Strategieentwicklung ist ein Stück weit auch Unternehmenssache,
wenn sie gut sein soll.
Das ist etwas, was Kollaboration erfolgt.
Die Umsetzung der Strategie.
Die ist natürlich dann immer auf den verschiedenen Ebenen durchzuführen.
Aber die große Entscheidung, da empfehle ich tatsächlich ein Stück weit mehr Kollaboration,
mehr Diversität, ein Stück weit auch Einladung von Subject-Meta-Experts, die also da auch
nochmal beitragen, wenn ich das OKR auf dieser Ebene gut designe und letztendlich auch mit
einer kollaborativen.
Aspekt gut designe, dann habe ich das in den wichtigsten Schritt geschafft.
Dann habe ich nämlich etwas geschafft, was Wirkung, Nutzen und auch Nachvollziehbarkeit
hat.
Und das ist dann mein Nordstern für die nächsten drei Monate im Unternehmen und den kann ich
dann auch aushalten.
Denn eins muss man wissen, bei dem Thema OKR auf Unternehmensebene reden wir eigentlich
immer über Strategieumsetzung und das größte Problem bei Strategien ist die Umsetzung.
Strategien kann jeder.
Aber ganz viele Unternehmen klagen auch, wir haben so eine tolle Strategie gemacht,
aber wir kommen nicht vorwärts.
Wir kommen nicht vorwärts.
Warum passiert das nicht?
Und das liegt einfach daran, dass die Wucht und Brutalität des Tagesgeschäfts jede Strategie
umhaut, wenn die nicht super klar, super plausibel und super fokussiert ist.
Die Strategie hat tatsächlich das Tagesgeschäft ein Stück weit umgesetzt.
Das ist eine sehr wichtige Sache.
Das ist eine sehr wichtige Sache.
Die Strategie hat tatsächlich das Tagesgeschäft ein Stück weit als Feind, ja, und braucht
eine gewisse Bestandskraft, Resilienz dagegen und die kriege ich nur hin, wenn die mit Sinn,
Verstand und vor allem mit einer maximalen Reduktion erarbeitet worden ist.
Das heißt also mit anderen Worten, wenn ich mehr als drei strategische Ziele habe, habe
ich schon kaum noch eine Chance, die zu erreichen, weil das einfach versetzt wird.
Ja, das fand ich auch interessant, weil du eben sagtest, Ziele, also Zielinflation, das
waren wirklich OKRs.
Ja.
Und das ist dann vielleicht so, wie ich jetzt nicht auch verstehe, einfach, ich sage mal,
punktuell einsetzt.
Punktuell einsetzt, weil bestimmten, natürlich bei den wichtigen Zielen und das nicht einfach
flächendeckend eben einsetzt, weil dann kommt man zu dem, was du eingangs sagtest, dann
habe ich wieder Verwaltung, dann habe ich Management, dann muss ich Tools pflegen, dann
habe ich viele Gespräche, um den Prozess zu unterstützen, um auch zu reporten, dass
ich den Prozess ja nicht blockiert habe.
Das heißt, so wie ich das bei dir verstehe, eigentlich eher so ein bisschen als Möglichkeit,
als, ich sage mal, leichtgewichtige Möglichkeit, Themen umzusetzen, sei es eine Strategie,
sei es andere wichtige Themen.
Ich muss dazu sagen, bei einer Strategieumsetzung gilt so ein Stück weit so die Faustregel,
je größer das Unternehmen ist, umso besser ist es, um so einen klaren Fokus zu haben
und wenige Ziele zu haben.
Bin ich ein Start-up, also bin ich mit fünf, sechs Leuten unterwegs, dann kann ich OKR
wunderbar dazu nutzen, die ganzen wilden Themen abzudecken.
Ja.
Weil ich habe eine superhohe Dynamik und ich brauche einfach Verbindlichkeit.
Das ist ein Problem bei Start-ups, dass wir einfach ein Stück weit mit Strukturfragen
kämpfen.
Das heißt, da würde ich OKRs vielleicht ein Stück weit anders nehmen und sagen, komm,
lass uns mal drei Monate klarziehen, was wollen wir insgesamt in den drei Monaten machen.
Bei einem Konzern, wo ganz viele Regel- und Standardprozesse da sind, da nutze ich OKRs
für den Hebel des Changes.
Da geht es um Veränderung.
Und zwar um den punktuellen, starken Hebel.
Und da würde ich tatsächlich mit wenigen OKRs arbeiten.
Okay.
Ja.
Und dann vertragen die sich übrigens wunderbar mit anderen Strategie-Umsätzen oder mit klassischen
Methoden wie einer Balanced Scorecard oder einem klassischen KPI-Berichtssystem, weil
ich dann nämlich sage, ich will gar nicht alles damit machen, sondern ich will an den
neuralgischen Punkten, an denen ich dramatisch besser werden will, da setze ich ein OKR drauf
und den Hebel draufzusetzen.
Mhm.
Das ist übrigens auch die Art und Weise, wie Google mit OKRs arbeitet.
Google ist ja so ein bisschen ein Posterschein, da muss man auch ein Stück weit kritisch
draufschauen.
Also Google ist das bekannteste Großunternehmen, das seit der Gründung kontinuierlich mit OKRs
arbeitet, aber auch kulturell das Thema immer weiterentwickelt hat.
Das heißt, die arbeiten heute mit OKRs ganz anders als noch vor 20 Jahren, aber für die
sind OKRs der große Hebel.
Ja.
Mhm.
Der Moonshot.
Genau.
Hier setzen wir einen Moonshot-Hebel drauf.
Hier wollen wir dramatisch besser werden.
Entschuldigung, wir scheinen wieder so ein bisschen lag zu haben.
Aber jetzt möchte ich gerade noch mal nachhaken, wie vertragen sich OKRs dann mit Tagesgeschäft?
Weil ich denke, es macht wenig Sinn, dass man sein Tagesgeschäft dann irgendwie in
einem Objective abbildet, oder?
Also wie gesagt, bei ganz kleinen Organisationen finde ich das richtig, aber wenn ich ein Start-up
bin, wo ganz viel Dynamik ist und ganz wenig situierte Prozesse, dann ist das nicht so richtig.
Ja.
Ja.
Ja.
Genau.
Ja.
Ja.
Die schnellen Prozesse würde ich die Dynamik tatsächlich in OKRs einfangen, einfach um
Struktur reinzubringen.
Habe ich aber ein Business, das stark durch Standards geprägt ist, ne?
Das könnten jetzt auch im Service-Management sein, beispielsweise.
Dann setze ich die OKRs auf das Thema Change und Improvement.
Das heißt also, dann kann ich die OKRs tatsächlich benutzen, um Wirkungsziele zu definieren,
die das Tagesgeschäft kontinuierlich besser machen.
Ja.
Zum Beispiel eine Möglichkeit oder eine strategische Veränderung, die im Unternehmen da ist, zu flankieren.
In so einem Setting benutze ich gerne ein sogenanntes OKR 0.
Das OKR 0 hat keine Key Results, also in Form von Schlüsselergebnissen, sondern bildet die wichtigsten KPIs des Tagesgeschäfts ab, die ich unter Kontrolle haben muss.
Also mehr oder weniger das Business, das ich gesund halten möchte.
Und den Change, also die Veränderung, die vielleicht auch Freiräume braucht, die auch ein bisschen Zeit braucht, das wäre dann mein OKR 1.
Und da habe ich meine Key Results drin für den Change.
Und möglicherweise sind da auch Key Results drin, die mir Luft verschaffen, im Tagesgeschäft diesen Change überhaupt durchzuführen.
Und so vertragen sich also OKRs.
Das heißt auch mit dem Tagesgeschäft, dass ich sage, ich habe einen Anteil an Standard und Prozessen, den möchte ich gesund halten, weil davon lebe ich und das muss gut funktionieren.
Da habe ich KPIs drauf, an denen ich erkenne, dass das Business gut läuft.
Und ich habe einen Change, der in der Regel eine Verbesserung, ein Improvement oder eine Veränderung darstellt.
Und das ist dann mein zweites OKR.
Vielleicht gibt es auch noch mein drittes.
Aber so würde ich, das ist so meine Empfehlung, Tagesgeschäft und OKRs zu verheiraten.
Man muss einfach schauen, wie viel Dynamik habe ich.
Bin ich jetzt in der Produktentwicklung, bin ich jetzt in der Innovation, bin ich jetzt in einem sehr dynamischen Umfeld,
dann helfen mir die OKRs genau diese Outcomes, die ich erzielen will, mit dem Team zu fassen.
Dann habe ich mehr OKRs.
Bin ich in einem sehr, sehr standardisierten, prozessualen, stabilen Umfeld,
dann haben die OKRs Zeit.
Tatsächlich einen kleineren Anteil.
Dann geht es einfach nur um Change von dem, also besser machen von dem, was wir ohnehin tun.
Vielleicht sind wir da schon ein bisschen bei DevOps.
Ja, wir haben noch gar nicht großartig über DevOps gesprochen, aber das kommt ja vielleicht gleich noch.
Du wolltest doch was zu Outcome sagen.
Ja, hinter diesem ganzen Thema OKR verwirkt sich, und das ist die Schule, die ich vertrete, das Outcome-Based Planning.
Also die Idee, dass ich…
Eine Planung nicht mehr auf Projektebene, Features und Arbeitsergebnisse durchführe, sondern auf Outcomes.
Hintergrund ist so ein bisschen meine Sicht auf das Thema Digitalisierung.
Dirk, du weißt, da habe ich mich auch so ein bisschen mit beschäftigt.
Das, was wir so gemeinhin als Digitalisierung bezeichnen, also auch die Vernetzung, gesellschaftliche Veränderung, Büroautomation,
ist ja ein Riesenpotpourri, und am Ende ist es ja auch ein Passwort,
ist für mich…
Aus meiner Sicht die Durchdringung unserer Welt mit Software.
Software hat immer größerer Anteil an der Wertschöpfung.
Das merkt zurzeit ganz stark die Automobilindustrie.
Denn das, was jetzt bevorsteht, ist nicht nur der Wechsel eines Antriebsstrangs,
sondern das ist die Veränderung der Intelligenz, der Automobilität insgesamt.
Und jedes Unternehmen ist aus meiner Sicht, und auch jede Behörde,
in irgendeiner Form im Software-Business.
Einige haben es noch nicht verstanden, viele merken es mittlerweile.
Wir sind alle irgendwo im Software-Business.
Und Software ist im Unterschied zu Fertigprodukten eigentlich nie fertig.
Sondern wir reden hier immer über Produkte, die immer besser werden.
Und um überhaupt Fortschritt zu erkennen, reicht es nicht mehr aus, einfach ins Backlog zu gucken
und zu schauen, wie viele Storys haben wir abgearbeitet,
sondern ich brauche…
Ich brauche ein anderes Maß.
Und das sind für mich die Outcomes.
Das ist das Maß, woran wir erkennen, ob wir Fortschritt in der Digitalisierung machen.
Die Wirkung, die wir erzielen.
Und jetzt kommt meine Sicht, was ist denn ein Outcome?
Ein Outcome ist die gewünschte Veränderung des Verhaltens von Menschen,
die meinem Business zuträglich ist.
Es geht um Menschen.
Und es geht um einen Schwerpunkt.
Es geht um einen Change, der dem Business zuträglich ist und der messbar ist.
Ich hatte eben das schöne Support-Beispiel genannt.
Ja, wir haben zu viele Sofort-Anfragen.
Das Verhalten, was ich verändern möchte, ist, dass die Leute anrufen.
Das ist das Outcome, das ich eigentlich erzielen will.
Mein Outcome ist nicht, für einen Fehler rauszumachen.
Mein Outcome ist die Verhaltensänderung, dass die Menschen weniger im Support anrufen.
Weil dieses Outcome, das zahlt auf mein Business ein,
weil dann brauche ich nicht mehr so viel Aufwand im Support.
Und jetzt kommt die Frage, wie kann ich das messen?
Ganz einfach.
Hier ist es ja super einfach.
Ich beobachte einfach, was passiert denn?
Woran kann ich denn erkennen, dass die Leute weniger Support in Anspruch nehmen?
Ja, es gibt weniger Tickets.
Es gibt weniger Telefonanrufe.
Und das sind die Dinge, die ich messen kann.
Das Schöne bei dieser Definition,
wenn ich also die Verhaltensänderung von Menschen betrachte,
ist, dass ich viel einfacher in die Messbarkeit komme.
Weil Verhaltensänderung ist etwas,
was ich mir tatsächlich irgendwie immer gut visuell vorstellen kann.
Ja, ich gucke einfach auf die Menschen und überlege mir,
woran kann ich denn das gewünschte Verhalten erkennen?
Und wie sieht das aus?
Das hat auch was mit Visualisierung zu tun.
Und dann erkenne ich irgendwann, oh, ja, es ist ganz einfach.
In dem Support-Beispiel rufen einfach weniger an.
Und die Verhaltensänderung,
die ich jetzt hier mit dem Podcast haben möchte, ist,
ich möchte einfach, dass Leute mich ansprechen und sagen,
hör mal, André, ich habe diesen tollen Podcast mit Dirk, Luca und dir gehört.
Lass uns mal ins Gespräch kommen.
Das ist eine Wirkung, die ich total wichtig finde.
Nicht, dass wir den Podcast durchgeführt haben.
Nicht, dass wir miteinander gesprochen haben.
Sondern die Verhaltensänderung von Menschen.
Und ich behaupte, das ist die Schlüsselfrage,
die sich im Produktmanagement und im Changemanagement immer gut stellen lässt.
Und ich behaupte, jetzt gehe ich sogar so weit
und nähere mich aber auch einer, vielleicht auch ein Stück weit einer Grenze.
Das ist die Schlüsselfrage, die ich beim Thema DevOps stelle.
Was will ich verändern bei den Nutzern,
beim Kunden, bei Mitarbeitern, bei Stakeholdern?
Oder wen auch immer?
Und wie kann ich erkennen, dass diese Verhaltensänderung eingetreten ist?
Wenn ich das als Outcome formuliere und sage, so Team,
das ist das Outcome, das wir jetzt erzielen wollen.
Überlegt euch, wie ihr das hinkriegt.
Keine Ahnung, ob das über Veränderungen der Software,
über Veränderungen der Prozesse, über Veränderungen der Kommunikation erfolgt.
Eigentlich egal.
Aber das ist das Outcome, das wir jetzt brauchen.
Ich erweitere den Lösungsraum.
Habe aber ein wunderbares Maß dafür zu erkennen,
habe ich das Thema gelöst oder nicht?
So war jetzt meine Bergpredigt zum Thema Outcome.
Wenn du mich jetzt sehen würdest, würdest du sehen,
wie ich hier ganz gespannt sitze und das, was du gerade alles sagst,
sozusagen verfolge und verarbeite.
Ich fange mal mit dem Einfachen an.
Was ich herausgenommen habe, ist, dass meine Sicht auf DevOps zumindestens
mit der von OKR quasi sozusagen total,
total übereinstimmt.
Es geht mir nicht darum, eine Organisation zu verändern,
also Dev und Ops in ein Team zu setzen.
Das ist eine Maßnahme, die ich machen kann,
aber die ich nicht machen muss.
Es geht darum, Verhalten zu verändern
und dass das zu einem besseren Ergebnis führt,
also zu einem besseren Outcome an der Stelle.
Insofern, das kann man sicherlich nochmal später beleuchten,
weil das passt jetzt in die Zeit von diesem Podcast nicht mehr rein.
Aber das war das Erste, was ich so rausgehört habe.
Aus deiner Bergpredigt eben.
Also da war ganz viel, ganz viel guter Input drin.
Das Erste habe ich eben zusammengefasst.
Luca, hast du noch ein paar Punkte, die dir eben so aufgefallen sind
bei Andrés Bergpredigt?
Ja, also aufgefallen in dem Sinne, weiß nicht.
Aber ich stelle halt fest, dass das wahnsinnig gut
zu unserer Perspektive von DevOps passt,
so wie du gesagt hast, Dirk.
Das ist diese Wertperspektive.
Das ist die Wertstromperspektive.
Das ist die Wichtigkeit von Feedback.
Alle diese Themen, weißt du, die drei Wege von DevOps.
Ja.
Die finden sich da eins zu eins wieder.
Und ich finde das ganz toll, was du gesagt hast, Dirk,
dass DevOps vielleicht gar nicht darin bestehen muss,
dass man die Dev- und die Ops-Leute in ein Team zusammenpackt.
Wenn man das macht, dann ist das ja vielleicht schön und nützlich.
Aber letzten Endes ist die Frage, bewirkt das was im Hinblick auf DevOps?
Bewirkt das was im Hinblick auf die Ziele, die wir uns gesetzt haben?
Ja.
Und das Interessante ist, wenn ich an meine Projekte denke,
da habe ich immer mal wieder Initiativen im DevOps-Bereich,
die auf mich zukommen, die aus diesen Fachbereichen kommen.
Das wollte ich vorhin noch sagen, zu der Sichtweise von Andy,
was für uns Führungskräfte sind.
Natürlich die Manager, aber auch die Fachleute.
Und ich habe immer, nee, nicht immer, das ist anders,
aber ich sehe häufig, dass die Fachleute,
also die Devler oder die Opsler, das ist unterschiedlich,
dass die ein besseres Ergebnis erzielen wollen.
Die sehen, dass es irgendwo nicht läuft,
dass der Kunde unzufrieden ist,
dass auch intern Maßnahmen nicht ein gutes Ergebnis bringen.
Das wird vielleicht nach außen hin kaschiert,
ist mindestens mal böse durch irgendwelche Manager oder wie auch immer.
Aber die Fachleute, die wissen, wo es brennt
und die wissen, wo es auch knackt, sag ich mal.
Und die kommen dann genau auch mit der Idee,
das zu verändern.
Und manchmal werden sie leider auch ausgebremst
durch die Aufbauorganisation.
Das ist das, was ich vorhin sagte.
Die kann man ja nicht ignorieren.
Aber insofern sind da viele, viele tolle Parallelen,
dieses Werkzeug umzusetzen.
Und das hast du ja vorhin auch, oder zu nutzen.
Das hast du ja vorhin auch gesagt.
Das sehe ich als eine sehr wichtige Parallele von Dev, Ops und von OKR.
Es gibt, es ist eine Art Philosophie.
Es ist Community getrieben.
Jeder bringt so seine Erfahrungen ein.
Und es gibt nicht einen, der sagt, so geht Dev, Ops.
Und so musst du das machen.
Also natürlich gibt es im Dev, Ops Umfeld Institutionen,
die Schulungen anbieten und Zertifikate anbieten.
Da sind wir ja auch mit dabei, Luca, Falco und ich.
Das machen mache ich aber quasi nur,
weil es manchmal so gewünscht wird.
Mir wäre es viel lieber, keine Zertifikate
und kein allmächtiges Wissen oder keinen Anspruch.
Genauso musst du das machen.
Es muss natürlich zum Kontext passen.
Ich sitze jetzt gerade hier im Dev, Ops Podcast
und stresse auch jetzt das Thema Outcome ein Stück weit
auch mit der Sicht von Produkten und Change.
Meine Definition von Outcome mag jetzt in einem Strategiekontext
nicht immer tragen, aber ich arbeite damit immer gerne,
weil es so wunderschön von der Innensicht ablenkt,
indem ich sage, was will ich denn draußen verändern?
Und weil die Veränderung menschlichen Verhaltens
für uns in der Regel auch immer gut vorstellbar ist,
wie man das in irgendeiner Form quantifizieren kann.
Ja, da kann man sich tatsächlich vorstellen,
was ist, wenn wir es einfach so lassen?
Das wäre dann die Baseline.
Und was ist, wenn ich mal die Idee maximal drehe?
Wir würden es extrem gut hinkriegen.
Wie würden sich die Leute dann verhalten?
Und das ist Variante B.
Und in der Regel kommen dann super schnell die ersten Ideen
für Konkrete, für Messbarkeit.
Die Messbarkeit ist für mich überhaupt kein Selbstzweck,
sondern passt für mich zu der Idee der agilen Arbeit.
Also empirisch vorzugehen, datengetrieben vorzugeben,
Experimente zu wagen, die diesem Outcome hoffentlich näher kommen,
die aber manchmal auch scheitern,
und dann ein anderes Experiment zu wagen.
Und dafür brauche ich einfach, da bin ich komplett bei Andy,
Messbarkeit.
Um zu erkennen, hey, haben wir das jetzt geschafft oder nicht?
Ja.
Ja gut, jetzt haben wir das Thema,
was wir, wie gesagt, nicht mehr diskutieren können aufgrund der Zeit.
Diese Messbarkeit kann natürlich auch falsch verwendet werden
oder falsch interpretiert werden.
Du sprichst, hast du vorhin angesprochen, Zielvereinbarungen.
Das lassen wir jetzt mal außen vor.
Vielleicht können wir das ja zu einer späteren Folge nochmal machen.
Oder vielleicht machen wir da irgendwie nochmal einen Artikel draus oder so.
Denn ich habe vorhin eingangs gesagt,
dass wir im Vorgespräch, du auch herausgefunden hast,
OKRs und im Kontext von DevOps hast du nichts oder nur wenig gefunden.
Ist das so oder gibt es, das ist wirklich so,
oder gibt es nicht wirklich irgendwo mal so eine Art Geheimtipp
von anderen Klassen versatiert?
Das finde ich gut.
Also können wir unseren Zuhörern noch ein paar Dinge mitgeben,
die wir auch in die Shownotes packen, wo sie etwas nachlesen können
oder nachschauen können.
Also was ich mittlerweile gelernt habe, ist,
was beim Thema OKR ist, ist auch wirklich ein Tipp von mir.
Schaut nicht so sehr nach Beispielen aus dem Internet,
weil es gibt keine guten generischen Beispiele.
Es passt in der Regel nicht zu den eigenen Fragestellungen.
Also was ich jetzt bei DevOps wieder mal gesehen habe,
sind so konkrete Beispiele, die sich um technische Fragen reden.
Erhöhung der Verfügbarkeit von 90 auf 95 Prozent und solche Dinge.
Oder Reduktion der, weiß ich nicht,
Antwortzeiten XY.
Ja, auch das kann ich als OKR formulieren.
Aber das ist so weit weg von dem, was ich als Outcome bezeichne.
Was ist denn das Outcome?
Was wird da erreicht worden?
Was ist die Verhaltensänderung, die uns dazu führt,
auf diese Idee zu kommen?
Und die möchte ich gerne formulieren.
Also die DevOps-Beispiele sind ganz oft genau da,
wo ich auch das Thema DevOps nicht sehen möchte.
Bei der untersten Maschinenschraube, sage ich jetzt mal.
Und da gefallen mir OKR-Beispiele.
Da gefallen mir OKR-Beispiele genauso wenig wie DevOps-Beispiele.
Auch wenn ich diese Maschinenschrauben beherrschen können muss,
um diesen Impact, diese Wirkung zu erzielen.
Also ich will das nicht kleinreden.
Aber das ist nicht die Ebene oder die einzige Flughöhe,
über die ich nachdenken darf.
Und im Sinne von OKR ist es wahrscheinlich die letzte Flughöhe.
Was ich aber gefunden habe und was mir sehr, sehr gut gefällt,
ist ein Buchtipp in dem Zusammenhang.
Das ist das Buch Accelerate, an dem auch der Gene Kim mitgeschrieben hat.
Da wird der Begriff OKR überhaupt nicht benutzt.
Also werdet ihr keine OKRs finden.
Aber da wird das Thema Outcome und Messbarkeit thematisiert
im Zusammenhang mit DevOps.
Und darum geht es.
OKRs sind am Ende des Tages nur ein Framework,
das euch ein Stück weit hilft, in dieses Denken besser reinzukommen.
Aber was ich wirklich brauche, ist ein Gefühl dafür zu entwickeln,
okay, was ist denn die wirkliche Wirkung,
die wir mit den Produkten erreichen wollen?
Wie können wir die hart messbar machen?
Und dann letztendlich die gesamte Wertschöpfungskette verbessern.
Also mein Buchtipp ist Accelerate.
Kommt auch in die Buchtipps rein.
Dann habe ich ein schönes Video gefunden,
das das Thema Outcome basiert.
Das Thema Outcome-Based Planning.
Nicht so sehr aus DevOps-Sicht,
aber aus Sicht von Produktmanagement beschreibt.
Präsentation heißt Roadmaps are dead.
Wunderbare Präsentation.
Also ich habe ganz viele Aha-Erlebnisse gehabt.
Kann man wirklich empfehlen.
Zehn Minuten super gut investierte Zeit.
Auch für das Thema DevOps wird ganz knallhart.
Werden die wichtigsten Learnings, die wir alle mittlerweile haben,
durchexhaustiert.
Und dann kommen drei goldene Tipps.
Die haben alle was mit Outcomes zu tun.
Ja, ansonsten ein bisschen Eigenwerbung.
Kommt gerne auf meine Seite andrejklaassen.de.
Und ich habe natürlich auch einen Podcast zu dem Thema OKR.
Und werde übrigens ein kleiner Teaser jetzt auch in den nächsten Monaten
stärker auf das Thema Produkte schauen,
das Thema Outcome nochmal mehr beleuchten.
Übrigens auch mein Lieblingsthema Messbarkeit.
Da gerne auch drauf schauen.
Sehr schön.
Gut, also Eigenwerbung ist immer erlaubt.
Zumindest auf gute Themen.
Und wir haben dich ja in den Podcast eingeladen,
weil wir glauben, dass du da ein Experte bist.
Und dann darf auch Eigenwerbung erlaubt sein.
Du hast noch was von einem Buch erzählt von Josch Seiden.
Ah ja, genau.
Josch Seiden.
Also das, was ich hier in meiner Bergpredigt formuliert habe,
ist in Wirklichkeit die Bergpredigt von Josch Seiden.
Und jetzt Gotthelf.
Das sind zwei englische Experten,
die sich seit ganz vielen Jahren mit dem Thema
Inspect and Adapt, Sense and Response und Outcomes beschäftigen.
Es gibt ein Buch, das braucht wirklich nur 40 Minuten.
Outcome over Output.
Da wird diese Outcome-basierende Planung von A bis Z durchgespielt.
Auch das Thema OKR findet da Raum.
Auch das Thema DevOps wird dort erwähnt.
Mein Feedback zu dem Buch ist, jede Seite ist Gold wert.
Die beiden, man merkt denen einfach deren unfassbare Kompetenz an.
Und für mich ist das so etwas, wo alle Koryphäen oder Leute,
die ich so ein bisschen als Koryphäen sehe,
stückweit zusammenkommen.
Eben in diesem Denken, ob es ein Dan Norris ist,
ich weiß nicht, ob der bekannt ist,
Urgestein der agilen Szene,
der schon 2006 gesagt hat,
wir brauchen eigentlich ein fünftes Prinzip im agilen Manifest.
Das ist das Prinzip Outcome.
Ob es Jeff Sutherland ist,
der ja Scrum miterfunden hat,
der immer wieder auf das Thema Outcome,
wenn man dem mal zuhört, zu sprechen kommt.
Oder jetzt hier der Josh Seiden.
Es gibt auch noch ganz viele andere, die ich empfehlen kann.
Da habe ich aber jetzt nicht Mike Burrows unbedingt zu.
Man hat so viel zu erzählen.
Es geht genau um dieses Thema.
Und was ich schön finde an dem Buch Outcome over Output,
es beschreibt auch ganz klar,
warum Führungskräfte sich so schwer tun mit dem Thema.
Denn es hat auch was mit Kontrollverlust zu tun.
Und das wäre aber ein eigener Podcast.
Allerdings.
Das ist keine böse Absicht,
sondern das ist einfach ein Stück weit auch,
hier kommt so ein Punkt, wo auf einmal
ein ganz anderes Führungsverständnis erforderlich ist.
Etwas, was ja auch DevOps schwer macht
oder richtige agile Arbeit.
Und das ist auch ein Thema in dem Buch.
Also bevor ihr auf meine Webseite geht,
dieses Buch lesen.
Okay.
Jetzt war Luca wahrscheinlich aus gutem Grund
immer so ganz still.
Jetzt kommt meine Werbung für Luca.
Wenn du also in deinem Podcast jemanden suchst,
der das Buch Accelerate gelesen hat,
intensiv gelesen hat und auch verstanden hat,
dann kann ich dir Luca Njani als Gesprächspartner empfehlen.
Vielleicht kann man da auch was rausziehen.
Gerade weil du gerade sagst,
dass da ja nichts über OKRs drinsteht,
aber trotzdem ganz viel Übermessung drinsteht.
Also insofern Werbung für meinen lieben netten Kollegen Luca.
Dankeschön.
Gut.
Dann sage ich aus meiner Sicht,
ich habe keine Fragen mehr.
Es kommt ja von mir häufig die Frage,
gibt es noch irgendwas Wichtiges,
was wir nicht angesprochen haben?
Aber ich glaube, André,
du hast so viel angesprochen,
dass du auf jeden Fall die wichtigsten Themen,
die du so platzieren wolltest,
die für dich wichtig sind,
dass du die angesprochen hast, oder?
Ich glaube, wir sind durch.
Wir haben jetzt eine Stunde gesprochen.
Enough is enough, würde ich sagen.
Ganz herzlichen Dank an euch beiden,
dass ich heute bei euch zu Gast sein durfte.
Sorry, dass ich so viel geredet habe.
Ich hätte vielleicht doch keinen Kaffee
vor dem Podcast trinken sollen.
Vielleicht ein bisschen eher Beruhigungstee oder so.
Aber mir hat es gefallen.
Und ich habe immer die Frage,
ob man dem Gespräch,
ob man der Aussage,
dem Monolog,
ob man dem gut zuhören kann.
Und ich konnte dir zuhören,
weil da zum Beispiel wenig Äs oder Äms drin waren,
weil man einen klaren Gesprächsfluss hatte und so weiter.
Also insofern, du hast vielleicht viel gesprochen,
aber ich fand es nicht störend.
Ich fand es im Gegenteil sehr, sehr,
ich sage mal unterhaltsam und sehr, sehr lehrreich.
Und ich konnte dir gut zuhören.
Und ich hoffe,
dass das dann den Teilnehmern auch so geht.
Wunderbar.
Ganz herzlichen Dank an euch beiden.
Und vielleicht hören wir uns ja nochmal in dieser Runde,
in diesem oder in dem.
Oder in einem anderen Podcast.
Ja, das wäre doch cool.
Ich dachte, du sagst in diesem Podcast oder in einem anderen Leben.
Ja, ja.
Okay, gut.
Alles klar.
Bis bald.
Alles Gute.
Und André, dir noch einen schönen Tag.
Und Luca, dir auch alles Gute bei dem,
was du jetzt vielleicht irgendwie nochmal tust.
Ja.
Tschüss.
Genau.
Dankeschön.
Macht’s gut.
Danke für das Gespräch, André.
Ciao.
Danke.
Tschüss.
Tschüssi.
Ciao.
Tschüssi.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.