Mein Erfolgsrezept als Platform Owner – Meine 25 wichtigsten Glaubenssätze

Fehlendes „Mindset“ ist die größte und dümmste Ausrede der agilen Transformation.

Auch der DevOps-Transformation.

Und der täglichen Arbeit.

Als Platform Owner ist es für mich dennoch wichtig, meine innere Haltung (also mein Mindset) zu verstehen. Diese innere Haltung besteht vordergründig aus Werten, Prinzipien, Denkmustern und Glaubenssätzen.

Die Krux an der Geschichte: Mein Regierungssprecher (Bewusstsein) hat eigentlich keine Ahnung davon, wie mein Unterbewusstsein wirklich denkt und welche Entscheidungen es trifft. Der Regierungssprecher gibt lediglich eine möglichst rationale Erklärung dafür ab. Vor allem bei meinen Werten und Prinzipien belügt er mich schamlos, weil es eher einem Wunschkonzert als der Realität entspricht. (Wenn Sie mehr über den Regierungssprecher und die Regierung erfahren möchten, lesen Sie gerne das Buch „Schnelles denken, langsames Denken“ von Daniel Kahneman)

Deshalb bin ich einen anderen Weg gegangen. Ich habe über Wochen immer wieder beobachtet, wie ich mich verhalte und welche Glaubenssätze mein Verhalten steuern.

Die 25 wichtigsten Glaubenssätze, die meine Denk- und Handlungsweise steuern, habe ich für Sie zusammengetragen.

Der Bonus-Glaubenssatz ist ein echter Augenöffner.

Disclaimer: Die meisten grundlegenden Ideen stammen natürlich nicht von mir, sondern von den großen Denkern (die es meist auch nur weiterentwickelt haben). Deshalb habe ich die Quellen verlinkt, die mein alltägliches Denken und Handeln prägen. Es handelt sich explizit NICHT um affiliate Links. Ich verdiene also nicht an Ihrer nächsten Amazon-Bestellung mit.

Meine 25 Glaubenssätze, die meine innere Haltung bestimmen.

Hier sind sie:

1. Als Platform Owner bin ich ein Teil des Teams und habe gleichzeitig eine fachliche Führungsrolle. Mein Beitrag zum Arbeitsergebnis des Teams ist es, wichtige Entscheidungen zu treffen (und dafür geradestehen) und die Priorisierung der Arbeit.
2. Ich nehme “The One Thing” sehr ernst, sodass jeder Sprint nur genau ein Ziel hat. Auch die Vorarbeiten (Refinement, Planung) eines Sprints haben immer ein Fokusthema. Die Nachbar-Sprints zahlen in der Regel immer auf ein höheres Ziel mit ein.
3. Ich lege Wert darauf, dass Dinge erst einmal fertig gemacht werden, bevor neue gestartet werden. (Stop starting – start finishing)
4. Ich halte mich strikt an die Positionierung der Platform, die ich mit den Stakeholdern vereinbart habe. Reagieren auf Veränderungen wird leider meist so ausgelegt, dass sich die Positionierung ständig ändert. Das führt zu sich ständig ändernden Prioritäten. Und das führt zu einer chaotischen und kostenintensiven Arbeitsweise. Das Ergebnis: Eine Frankenstein-Plattform. Kostengünstiger und wertvoller ist es, die Positionierung und damit die Prioritäten nur sukzessive und nur bei wirklich guten Gründen anzupassen.
5. Ich weiß, dass es beim Aufbau einer Platform extrem viele sehr wichtige Themen gibt. Ich weiß aber auch, dass wir das nicht alles gleichzeitig umsetzen können. Unwichtige Themen ignoriere ich und plane nur die wichtigen anhand der Prioritäten.
6. Abbau technischer und architektureller Schulden ist für mich wichtiger als Entwicklung neuer Features. Fehler müssen beseitigt oder als technische Schulden dokumentiert und als solche behandelt werden.
7. Erst den Prozess verstehen, dann den Prozess vereinfachen und erst dann automatisieren. (Motto: “Wenn sie einen Scheiß-Prozess digitalisieren, haben Sie einen digitalen Scheiß-Prozess” – Thorsten Dirks, CEO der Telefónica Deutschland AG). Automatisierte Prozesse sind teure und starre Gebilde. Sind sie ausgereift und gut entwickelt, dann sind sie eine große Hilfe – sind sie es nicht, werden sie ganz schnell zur Kostenfalle.
8. Für unsere tägliche Arbeit bevorzuge ich einfache Automatisierungen statt der Entwicklung von Tools (leider verstehen nur sehr wenige den Unterschied zwischen Tools und Automatisierung.)
9. Ich akzeptiere den Status Quo als ausreichend gut, wodurch ich selten ins Jammern abgleite und der Konjunktiv (hätte, könnte, sollte) bei mir im Urlaub ist.
10. Ich steuere die Weiterentwicklung mehr, als dass ich konkrete Stories schreibe. Die Architektin und die Entwickler schreiben, abgestimmt mit mir, die meisten Stories selbst. Mein Job ist es, diese einzufordern, qualitätszusichern, zu priorisieren, zu verwerfen oder einzuplanen.
11. Als Platform Owner akzeptiere ich, dass meine Arbeit hochgradig Shallow Work ist (Meetings über Meetings), während die Erstellung von guten Epics, Stories und Plänen Deep Work benötigt. Architekten (mit konkretem Auftrag des PO) und Business Analysten (das gleiche, nur mit stärkerem fachlichem Fokus) sind eine gute Unterstützung. Diese müssen aber vom PO gesteuert werden, sonst ist das Ergebnis beliebig.
12. Als PO agiere ich als besser bezahlter First-Level Support-Mitarbeiter und fachlicher Filter, der das Team vor Überlastung und Shallow Work schützt. Als PO gebe ich alle wichtigen Informationen zur angemessenen Zeit weiter.
13. Ich lege den Fokus der Weiterentwicklung auf Reduktion: Weniger Code, weniger unnötige Features, höhere Qualität. (vermeidet Muda – “Arbeit für die Katz” und Muri – Kognitive Überlastung)
14. Ich lege Wert darauf, dass der Sprint entspannt, abgearbeitet werden kann, sodass es zu keiner Überlastungssituation kommt. 50% bis maximal 80% Auslastung bei der Planung sind optimal, sodass wir flexibel auf Veränderungen und unvorhergesehenes reagieren können oder aus Versehen das Commitment völlig übererfüllen (vermeidet Muri – Überbeanspruchung). (Bild im Kopf: Wenn ich in stürmischer See unterwegs bin, fahre ich nicht Vollgas bzw. setze ich nicht alle Segel. Das macht die Fahrt nur unsicher und bei einer blöden Welle zum Himmelfahrtskommando.)
15. Ergebnisse sind mir wichtiger als Vollauslastung. Wenn die Ergebnisse besser werden, wenn ein Kollege fast nichts zu tun hat, dann soll er diese Zeit lieber als Slack-Time nutzen und sinnvolle Verbesserungen an anderer Stelle herbeiführen.
16. Ich lege Wert darauf, dass sich das Wissen und die Erfahrung im Team verbreitet, sodass es keine Wissensmonopole gibt. Mir ist wichtig, dass das Team selbst eine ausgeglichene Basis hat, mit der es prinzipiell alle wichtigen Tätigkeiten ausführen kann. Dafür fordere ich die gemeinsame Arbeit an Stories (Pair-/Mob-Programming, gemeinsamer Review, explizite Workshops, nutzbare Dokumentation) ein. Stars haben keinen Platz in meinem Team! “Die Macht des Durchschnitts!” (vermeidet Mura – Unausgeglichenheit)
17. Ich nutze in der Regel den konsultativen Einzelentscheid als Entscheidungsstrategie – Ich lasse mich durch die anderen Teammitglieder beraten, höre ihnen zu und füge die Informationen in mein mentales Modell ein. Dann treffe ich die Entscheidung, die aus meiner Sicht am sinnvollsten ist. Alternativ nutze ich gerne den Konsent-Entscheid – Wenn es keinen besseren Weg gibt, dann nehmen wir den vorgeschlagenen Weg.
18. Ich hinterfrage die gut gemeinten Ratschläge meiner Berater (Scrum Master, Partner-Team-Pos, Teamleitung, Architektin, Partner-Team-Architekten) und entscheide selbst, ob ich das sinnvoll finde.
19. Ich nutze das Prinzip “Schon am Anfang das Ende im Blick haben” und nehme immer folgende Perspektive ein: “Wenn das in Produktion ist – wie funktioniert dann unser Betrieb? Welchen konkreten Wert schaffen wir gerade? Wie wirkt sich das auf unsere Verteidigung (IT-Security) aus?”
20. Wenn ich priorisiere, habe ich immer ein mentales Bild vor Augen, wie der Zielzustand meines Produkts aussehen soll und steuere dementsprechend die Themen ins Team.
21. Ich respektiere, wenn Teammitglieder langsamer arbeiten oder wir generell nicht so schnell vorankommen. Neben der Hängematte gibt es zu viele Gründe, warum jemand oder das ganze Team nicht wie gewohnt/erwartet performt. Beispiele aus meinem Alltag: Schwere Krankheit von Familienmitgliedern, ungeplante Kinderbetreuung oder andere private Gründe.
22. Ich delegiere Aufgaben, die ich nicht schaffen kann. Dabei nutze ich mental die 7 Stufen der Delegation aus dem Planning Poker in Management 3.0, um das Thema komplett abzugeben oder mich stattdessen eng “im Loop” zu halten.
23. Steuern! Nicht selbst machen! Selbst machen skaliert nicht. Und es hilft niemandem, wenn der Platform Owner der Bottleneck im Team ist.
24. Ich respektiere die Betriebsprozesse und verfolge die Null-Fehler-Strategie. Entweder akzeptiere ich einen Fehler und kümmere mich (nie wieder) darum, oder ich lasse ihn so schnell wie möglich reparieren.
25. Ich nutze meine frühere Erfahrung als Softwareentwickler, Platform Engineer, Scrum Master und Projektleiter, gepaart mit dem Agile Coach-Mindset a la Robert C. Martin (Clean Agile). Dazu mixe ich noch meine Erfahrungen in der Produktentwicklung (Business Canvas Model, Value-Proposition Design), Lean Startup, als Unternehmer und als Führungskraft. Dieser einzigartige Cocktail bestimmt meine Arbeitsweise.

Bonus: Ich akzeptiere, dass die Platform Engineers wie im dunklen Maschinenraum eines Dampfers oft Kohle schippen und das große Ganze aus den Augen verlieren. Als Kapitän des Schiffs erkläre ich in Reviews deshalb immer auch den Zusammenhang, warum eine Änderung notwendig war, was sie bewirkt und wie sie uns hilft, in Zukunft ein wenig besser zu arbeiten (Kaizen-Prinzip).

Das war es, mein persönliches Erfolgsrezept.

Meine Erkenntnisse

Versuchen Sie es doch auch einmal, Ihre 25 Punkte herauszufinden, die Sie im Alltag leiten. Ich für meinen Teil habe einige wichtige Erkenntnisse aus dieser Reflexion gezogen.

Die beiden wichtigsten:

1. Meine Arbeitsweise ist individuell geprägt. Ich kann die dahinterliegenden Prinzipien vermitteln, kann Ihnen Werkzeuge an die Hand geben und kann im Rahmen eines Interim Product Owner-Einsatzes diese innere Haltung vorleben.
2. Ich kann dazu beitragen, eine Transformation in Ihrem Team anzustoßen, indem ich Sie als Platform Engineering Lotse immer wieder dazu ermuntere, gewisse traditionelle Glaubenssätze loszulassen und sich auf das Lean und agile getriebene Mindset einzulassen.

Deshalb biete ich meinen Kunden, zu denen Sie auch gehören können, diese zwei Dienstleistungen an. Weil ich sehe, wie schwer es sich viele Platform Owner tun, ihre Arbeitsweise zu ändern. Und weil ich sehe, wie sehr sich neue Platform Owner damit tun, ihre neue Rolle auszufüllen.

Kommen Sie gerne auf mich zu, dann schauen wir, ob und in welcher Form wir zusammenarbeiten können.