Hast du schon einmal von “Organisatorischen Schulden” gehört? Wir nutzen den Begriff in Analogie zu “Technischen Schulden” und beziehen uns damit auf organisatorische “Abkürzungen”, das (bewusste) Weglassen von Scrum Elementen oder einer Vernachlässigung agiler Ideen und Prinzipien in Organisationen, die langfristig zu Problemen und damit natürlich auch zu Kosten führen. In dieser Podcast-Episode beschäftigen sich Tim und Oliver mit diesem Thema und zeigen vor allem auf, wie organisatorische Schulden auch deinen Erfolg als Product Owner beeinflussen können.
Als Product Owner oder agile Produktmanager bist du möglicherweise schon mit den Herausforderungen konfrontiert worden, die sich aus der Einführung von Scrum oder anderen agilen Methoden in deine Organisation ergeben können. Mal gibt es noch keinen Scrum Master, mal fehlt die Zeit für Reviews oder Retrospektiven. Oder du musst als Product Owner für drei oder vier Scrum Teams parallel wirken.
Oliver und Tim erklären zunächst ihr Verständnis vom Begriff der “Organisatorische Schulden” und zeigen die Vorteile und Nachteile auf, wenn ich Organisationen im Rahmen der agilen Transformation oder bei der Einführung von Scrum in die organisatorische Schuld begeben. Denn, wenn man dies ganz bewusst macht, kann dies absolut Sinn machen – genau wie bewusst eigegangene “Technische Schulden”, um ein Produkt oder Feature schneller an den Markt zu bekommen und mit ihm früher Outcome erzeugen zu können.
Die beiden zeigen dann im Hauptteil eine ganze Reihe von Beispielen für organisatorische Schulden auf, die sie in ihrer Arbeit als agile Coaches und Berater erlebt haben. Dabei diskutieren sie, wie man sie erkennt und vor allem wie sie auf die Product Owner Rolle wirken.
Natürlich gibt es aber auch wieder konkrete Tipps, wie du als Product Owner oder agiler Produktmanager mit organisatorischen Schulden umgehen kannst.
Also, hör rein in die neueste Episode “Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner” und erfahre, wie du dich als PO von ihnen nicht aus der Erfolgsspur bringen lässt.
Im Gespräch werden folgende ältere, aber immer noch wertvolle, Episoden aus unserem eigenen Podcast rund um dieses Thema erwähnt:
- Product Owner ohne Scrum Master – geht das?
- Technische Schulden und wie wir als Produkt Owner damit umgehen
- Dein Freund der Scrum Master
Hast du dich schon mal bewusst mit dem Begriff der Organisatorischen Schulden beschäftigt? Wie geht ihr in eurer Organisation damit um – egal ob ihr das Phänomen so oder anders benennt? Wir freuen uns, wenn du eure Erfahrungen aus der Praxis mit uns in einem Kommentar hier oder auf unserer Produktwerker LinkedIn-Seite teilst.
2 Kommentare zu „Organisatorische Schulden beeinflussen deinen Erfolg als PO“
Hallo!
Da ich diese Folge nicht bei LinkedIn finde, kommentiere ich mal hier.
Für mich bildet diese Folge zusammen mit den „erklärungsbedürftigen Produkten“ mit Bernadette von Wittern und dem Rant auf die Stellenanzeigen einen gemeinsamen Block. Die Folge mit zu den Hardwareprodukten habe ich am Wochenende noch einmal in Ruhe gehört, weil ich beim Joggen schon immer ganz hibbelig wurde. Mir kreiste die ganze Zeit der Gedanke im Kopf herum, dass dort genau besprochen wird, warum die Stellenanzeigen so sind wie sie sind. Und jetzt schon wieder das gleiche. Zum Beispiel das leidige Thema PO-Verantwortlichkeit und Platz in der Hierarchie. Wie viele Leute habe ich schon kennengelernt, die heute noch die Personalführung abgeben würden, wenn sie könnten. Und jetzt versucht die Organisation mit einem mal agil zu werden. Es werden POs frisch von der Uni angestellt, die mit vermeintlichen Entscheidungskompetenzen ausgestattet werden. Und wenn etwas schief geht, wird der Vorgesetzte der Entwickler wieder herangezogen, weil er das Projekt doch früher auch geleitet hat. Da bleiben so einige mittleren Alters frustriert im mittleren Management zurück, die jetzt nur noch die ungeliebte Personalführung behalten und dem oder der neuen PO aus dem Product Office den Arsch retten sollen, wenn es mal wieder kurz vorm Knall steht. Die „Herabstufung“ zum PO macht man dann auch nicht, weil das in den Unternehmen, die ich kenne, mit 20-30 k€/a Gehaltseinbußen verbunden ist.
Natürlich sollte man das nach Scrum (oder vermutlich allen agilen Frameworks) anders machen. Aber eine Organisation mit >10k Leuten im Back Office (Personal, Marketing, Buchhaltung, Entwicklung, 2nd Level Support, etc.) transformiert man nicht innerhalb von fünf Jahren. Es sei denn, das C-Level-Management steht voll dahinter und sieht einen Mehrwert darin, agil zu sein.
Ein anderer Gedankengang: Nicht überall, wo Product Owner draufsteht, ist auch Scrum drin. Ein Freund hat mal bei einer Firma gearbeitet, die Satelliten für die Forschung gebaut hat. Lauter Einzelstücke. Die haben irgendwann den Projektleiter zum PO gemacht, um zu verdeutlichen, dass dort die gesamte Entscheidungsmacht für den jeweiligen Satelliten gebündelt ist. Mit Agilität hatte das nichts zu tun. Die haben weiterhin den strengsten Changeprozess gehabt, den ich kenne. Dort war die Gefahr von “ups, haben wir vergessen, dich über die Änderung zu informieren?“ viel zu groß.
Ansonsten: weiter so! Trotz eurer starken Fokussierung auf Scrum in Reinform, fallen in jeder Folge spannende Gedankengänge und Selbstreflexionen für mich ab.
Hallo Christoph,
Vielen Dank für Deinen Kommentar. Hast übrigens Recht: bei LinkedIn gibt’s den Blogpost noch nicht (wg Ostermontag) – der kommt dann wohl heute oder morgen.
Sehr interessant, wie Du diese drei Folgen verknüpft. Das hatten wir selber so gar nicht gesehen.
Ja, dass wir die PO Rolle oft nah an Scrum diskutieren stimmt, denn da kommt sie u.W. her und ist einzig dort definiert (ok, inzwischen auch in SAFe). Aber wir bewegen uns in unseren Diskussionen auch immer mehr von put Scrum weg und betrachten immer mehr die Rolle agiler Produktmanager – was ein PO ja eben auch sein sollte.
Die Satelliten sind da ein spannendes Thema. Ich hab vor 3 Jahren mit PO‘s für Defibrillatoren gearbeitet – da hängen dann sogar Menschenleben dran. Sowas erfordert mE halt noch mehr Discovery und Risk Mitigation. Eine Haltung von „upps, haben wir vergessen“ sollte aber eh kein PO einnehmen. Egal was für ein Produkt verantwortet wird. 😉