Moin.

Wenige Tage nachdem ich einen kurzen Beitrag zum Thema der obersten Direktive veröffentlicht hatte, hat sich die Gelegenheit ergeben, das gleiche Thema mit einem Freund von mir ausführlich zu diskutieren. Mein Gast ist heute Christian Valerius. Christian ist seit einigen Jahren als Agility Coach tätig, und wir sprechen gerne, oft und lange über berufliche Dinge. Mit größter Mühe haben wir den aufgezeichneten Teil des Gesprächs bei ungefähr 30 Minuten begrenzen können.

In dieser Zeit sprechen über verschiedene Auslegungen der obersten Direktive. Man kann sie unter dem Gesichtspunkt “Wer hat ein Scheitern verursacht” verstehen oder man kann sie systemisch auslegen.

Ich stelle die Frage, was ich als Teammitglied tun kann, wenn es eine Aufgabe an anderer Stelle im Team nicht vorankommt, tun kann.

Zum Abschluss geht es darum, ob die oberste Direktive geeignet ist, psychologische Sicherheit im Team herzustellen.

Für mich war es spannend, Christians Sichtweise auf das Thema kennenzulernen und zu erfahren, was er als “Zauber der obersten Direktive” ansieht.

Insbesondere in der agilen Softwareentwicklung ist die sogenannte Oberste Direktive eine bekannte Regel für Retrospektiven. Verkürzt lautet sie: “Wir gehen davon aus, dass jeder im Team sein Bestes gibt bzw. gegeben hat.” Doch was ist, wenn die Projektziele wieder und wieder nicht erreicht werden? Was ist, wenn die Leistung Einzelner unterdurchschnittlich ist. Wie sollte ich als Teammitglied mich verhalten?

Brauchst Du Mut, um Deinen Job zu machen? Brauchst Du Mut, um das Richtige zu tun? Brauchst Du Mut, um an schwierigen Problemen zu arbeiten?

Dann stimmt etwas in Deiner Unternehmens- oder Team-Kultur nicht. Vielmehr brauchen Teammitglieder die Sicherheit, etwas Neues auszuprobieren, Experimente durchzuführen und bei Hindernissen oder negativen Ergebnissen nicht abgestraft zu werden.

Wie kann man überhaupt auf die Idee kommen, Mut zu brauchen? Ein Grund ist ein Dokument, das in der Software-Entwicklung eine wichtige Rolle spielt.

Im Jahr 2001 steht im Manifest für Agile Software-Entwicklung, "die Kunst, die Menge nicht getaner Arbeit zu maximieren, ist essenziell."

Kann ein Product Owner im Jahr 2024 Vorbild sein und Leadership ausüben, wenn er zu Feature-Requests Nein sagt und das Backlog klein hält?

Darüber und über weitere Aspekte des Backlog-Managements sprechen Kathleen Janz und Stefan Mintert in dieser Podcast-Folge.

Moin.

Wenn Software-Teams um ein Commitment gebeten werden, geht es oft darum, eine Software zu einem vorgegebenen Termin zu fertigzustellen; und manchmal ist handelt es sich nicht um eine Bitte, sondern um eine Ansage.

Warum benutzt man dabei eigentlich den englischen Begriff “Commitment”? Und was bedeutet er? Und wer muss ein Commitment abgeben, damit der nächste Termin gehalten werden kann?

Über diese Fragen und meine Antworten spreche ich in diesem Podcast-Beitrag

Moin.

Wenn Produktentwickler in einer Feature Factory nur Tickets abarbeiten, bekommen sie die Aufgaben meist vom Product Owner. Es liegt nahe, dem Product Owner die Verantwortung dafür zu geben, dass man als Entwickler die größeren Zusammenhänge der eigenen Arbeit nicht erkennen kann. Ein differenziertes Bild der PO-Rolle zeichnet dieses Gespräch, das ich mit meiner Kutura-Kollegin Kathleen Janz geführt habe.

Manchmal ist der Product Owner auch nur der Befehlsempfänger und braucht die Unterstützung seines Teams. Wenn der PO weder Fährmann noch Boten-Eule sein will, braucht er oder sie eigenständige Entwickler, die über die Brücken gehen, die der PO bauen sollte.

Was es mit Fährmann, Boten-Eule und Brückenbauer auf sich hat, erfährst Du in diesem Podcast-Beitrag.

Moin.

In manchen Sportarten haben Teams einen Kapitän. Welche Eigenschaften zeichnen einen guten Kapitän aus?

Und was kann man daraus für Software-Teams lernen? Kann es auch dort einen Captain geben? Welche Eigenschaften sind dort gefragt?

Darüber spreche ich mit dem Manager Marco Maria Gerlach, Director EMEA in einem internationalen Konzern.

Im Gespräch spricht er u.a. über Silent Leaders in Software-Teams.

Herzlichen Willkommen beim Podcast "Escape the Feature Factory". In dieser Folge stelle ich den neuen Podcast vor, der den gleichnamigen Blog bei Heise-Developer ergänzt.

Weitere Informationen über Blog und Podcast unter escapethefeaturefactory.com