Leadership in Zeiten von Scrum und autonomen Teams

INNOVATIONEN FÖRDEN : JA, JUGEND FORSCHT: NEIN

Als ich noch als "reiner" Coder unterwegs war, mochte ich überhaupt nicht, wenn mein Drang dazu, jede neue durchs Dorf getriebene Sau einmal probezureiten, durch diese geizigen IT-Controller gestoppt wurden. Kam mir vor, als würde Daniel Düsentrieb von Dagobert Duck an die Zügel genommen.

Doch auch wie beim Bullenreiten im Western, kam es nicht selten vor, dass mich das Biest abgeworfen hat. Sprich: Die Technologie war noch nicht reif, oder ich nicht.

Auch heute noch bin ich skeptisch, wenn es darum geht, Innovation nicht durch grundlose Ablehnung von Ideen zu ersticken. 

Heute als leitender Softwarearchitekt würde ich jedoch ein klares ABER hinzufügen. Zwar bin ich noch immer dafür, dass es Gründe geben sollte für Innovationsausbremsungen. Genauso sollte es auch Gründe dafür geben, Innovationen auszutesten. Und die sollten nicht alleine aus dem Jugend-Forscht-Drang bestehen. 

Denn in den Projekten, in denen ich unterwegs bin, bezahlt nicht die Uni unsere Arbeit, sondern der Kunde. Und der will nicht immer Ado Goldkante, sondern schlichtweg eine funktionierende Gardine vorm Fenster. Und die soll auch dann funktionieren, wenn mal keine Sonne auf den neuen fancy IoT-Solar-AI-Button scheint.

Nimm Microservices als Beispiel. Die sind aus meiner Erfahrung heraus in vielen Projekten das Maß aller Dinge, ohne dass sich um die Konsequenzen geschert wird, auch Microdienssteuer genannt: Verlagerung der Komplexität von den einzelnen Services hin zum Zusammenspiel und Deployment der Services. Da laufen noch alte VMs, die bei einem Drittanbieter mit Vorlauf von zwei Wochen bestellt werden müssen, aber die feuchten Träume gehen in Richtung hochskalierbares Kubernetes-Cluster. Dass dieses wiederum hochgradig spezialisierte DevOp-Engineers benötigt, dass wird erst mal ausgeblendet. Genauso die Tatsache, dass der Endkunde, der bislang eine Exe bekam, sicher keine Freudentränen rausheulen wird, wenn ihm plötzlich 50 Clusterhülsen vor die Tür gelegt werden. Frohes Fest!

Genauso wie die steile Lernkurve für alle im Team in Bezug auf Event Driven Architecture und Domain Driven Design. Denn wie will man denn Microservices schneiden, wenn nicht domänengetrieben? 

Ein anderes Beispiel gefällig? Wenn man GraphQL verwendet, obwohl REST ausgereicht, bekommt man oft eine Kopplung von Frontend und Backend, die einen Wechsel der UI-Technologie unmöglich macht, und eine Codebasis, die durch Typgenerierung unnötig aufgebläht wird. 

Das Ergebnis solcher Experimentierfreudigkeit:

Akzidentielle Komplexität wird eingeführt. 

Das übelste Übel. Eigentlich nur durch (Senior-)Exorzisten zu beseitigen.

Das erste Symptom der Komplexität ist, dass eine scheinbar einfache Änderung Code-Modifikationen an vielen verschiedenen Stellen erfordert. Change amplitude genannt.

Das zweite Symptom der Komplexität ist der cognitive load, der sich darin ausdrückt, wie viel Entwickler/innen wissen müssen, um eine Aufgabe zu lösen. Eine höhere kognitive Belastung bedeutet, dass mehr Zeit für das Erlernen der erforderlichen Informationen aufgewendet werden muss und demzufolge ein größeres Risiko besteht, dass sich Fehler einschleichen. 

Das dritte Symptom der Komplexität ist, dass es nicht offensichtlich ist, welche Codestücke modifiziert werden müssen, um eine Aufgabe zu erledigen, oder über welche Informationen ein Entwickler verfügen muss, um die Aufgabe ausführen zu können. Von den drei Manifestationen der Komplexität sind die unknown unknowns die schlimmsten.

Am Ende können Projekte daran scheitern. 

Und dann bezahlt keiner mehr die Jugend-Forscht-Projekte. 

Wie kann man hier entgegenwirken?

1. Nicht zu juniorig staffen, denn alte Hasen erkennen in der neusten Sau, die durchs Dorf getrieben wird oft den alten Wein in neuen Schläuchen und / oder die tickende Zeitbombe. Nimm nur das Microfrontendframework Mosaic. Vor Jahren hotter als hot. Jetzt toter als tot.
   

2. Die Führungskraft muss ein Bewusstsein dafür schaffen, dass derjenige, der die Musik bezahlt, auch bestimmen muss, was gespielt wird. Stichwort: Klare Ziele und Erwartungen setzen. 

SCRUM: MANCHMAL ZU SOFT => GELEGENTLICH BEDARF ES TISCHPLATTENERUPTIONEN

Was meine ich damit? 

Als ich selbst noch Entwickler war, hätte ich das auch nie gesagt, aber heute sehe ich das etwas anders. Ein Growth Mindset zeichnet sich dadurch aus, dass es dazu lernt. Ok, Neuroplastizität klingt noch geiler...

Ich hatte mal ein extrem diskussionsfreudiges Team in einem Projekt. Und wenn ich extrem sage, dann meine ich auch extrem. Da konnte es schon mal passieren, dass stundenlange Diskussionen ohne Ergebnis geführt wurden, ein Grund, warum ich mittlerweile für viele Meetings das Lean Coffee Konzept verwende, zumal ich auch gerne mal ein bisschen herumplaudere, was ja nur menschlich ist. 

Lean Coffee hat aber auch noch einen weiteren großen Vorteil: Durch die Begrenzung der Redeanteile finden auch die Stillen Gehör. Und die haben oft viel mehr beizutragen als ihnen zugetraut wird. Leider. Nicht "leider", weil sie mehr beizutragen haben, sondern "leider", weil wir oft still mit weniger wissend gleichsetzen. Und sagt ein Extrovertierter wie ich. Aber ich weiß, wie sich das anfühlt. Bei mir ist es meine Kampfsportvisage und -figur, die einige an meiner Intelligenz zweifeln lassen. Wir Menschen haben halt noch genug Steinzeit in uns. Du bist nicht in meinem Fellclan, du bist ein Doofie. 

Aber zurück zu den Diskussionen. Wenn man diesen nämlich kein Ende setzt, dann passiert folgendes: 

"Excessive complexity is nature’s punishment for organizations that are unable to make decisions." 

(c) https://architectelevator.com/gregors-law/ (letzter Besuch @: 2023-12-20 - 16:59)

Damit hätten wir wieder das Problem der eingekauften Komplexität.

Und jetzt kommt der Bogen zu Scrum. Wenn man nun ein solches Team hat, bei dem eben diese Diskussionen zu verzögerten oder gar verhinderten Entscheidungen führen, dann wächst die Komplexität. Du erinnerst dich, der (Senior-)Exorzist, der gerufen werden müsste? Was nun bei autonomen Teams?

Ja, ich lass dir Zeit zum Nachdenken. Ich habe Sie auch benötigt, als ich tatsächlich vor einer solchen Situation stand. 

Meine Antwort: Auf den Tisch hauen oder hauen lassen. Ich bin ja als Architekt und dann auch noch als Freiberufler kein Disziplinarvorgesetzter der Teammitglieder. Der oder die muss dann aber einschreiten, denn wie das nicht geschieht, dann gibt es bald kein Team mehr, weil es kein Projekt mehr gibt. 

Das zumindest ist meine Ansicht. 

Und eine kleine Anekdote noch dazu: Als ich damals in der Staatsanwaltschafts-Station (schon gefühlte hundert Jahre her) im Jura-Referendariat war, da hat ein Intensivstraftäter (Jugendstrafrecht) sich bei mir dafür bedankt, dass ich der erste Staatsanwalt (in Ausbildung) gewesen sei, der endlich mal Jugendstrafe für ihn gefordert hätte, ansonsten wäre er vermutlich nie von seinen Schandtaten abgekommen. Ich war damals völlig verblüfft. Als ich dieses Auf-den-Tisch-Hauen in dem vorhin erwähnten Projekt habe durchführen lassen, war die Reaktion fast genauso. Die Leute haben sich bedankt, dass endlich eine Lösung herbeigeführt wurde und das Dauerdiskutiere ein Ende hätte.

Ich war genauso verblüfft wie damals. 

Aber im positiven Sinne. 

SEELENKEKSE UND KEINE KLASSENKEILE BEI KRITIK

Für mich ist die Wertschätzung für gute Arbeit (oder zumindest das Bemühen darum) eines

der wichtigsten Elemente, denn jeder Mensch braucht Anerkennung, auch die Stillen, die nicht immer danach krähen. 

Es muss außerdem eine Kritikkultur geschaffen werden, in der sich auch die Introvertierten trauen, ihre Sorgen loszuwerden. Sonst kommt es zur stillen Kündigung. 

Deshalb halte ich persönlich die Retrospektive für eines der wichtigsten Meetings im Scrum Framework.

Das waren meine 2 Cents zu diesem Thema. Ich würde mich sehr freuen, wenn ich in den Kommentaren deine Meinung dazu erfahren würde.