Lange habe ich mich gegen Deadlines in der agilen Softwareentwicklung ausgesprochen, da sie meiner Meinung nach unnötigen Druck und Stress in den Teams verursachen. Von einigen Ausnahmen, wie z.B. einer gesetzlichen Vorgabe mit festem Zeitpunkt, abgesehen, erscheinen die meisten Deadlines als künstlich und willkürlich festgelegt. Warum also sollte sich ein Team unter Umständen ausbrennen und bis zur Erschöpfung arbeiten, nur um ein imaginäres Ziel zu erreichen? In der agilen Softwareentwicklung geht es unter anderem darum in einer kontinuierlichen, haltbaren Geschwindigkeit Mehrwert zu liefern, also sich explizit nicht so zu verausgaben (z.

“Bevor wir das jetzt live nehmen, müssen wir uns noch mit dem C-Level abstimmen. Das kann starke Implikationen auf unsere Sales haben.” “Da muss ich mich noch mit meinem Head abstimmen.” “Das betrifft das andere Team. Wir müssen noch klären, ob das so okay für sie ist.” “Wir warten noch auf den Input der Agentur, aber dann müssen wir sofort loslegen sonst läuft uns die Zeit davon. Könnt ihr nicht schon was vorbereiten?

Im ersten Teil unserer Serie über Accelerate haben wir beschrieben, wie die Unternehmen, die in der Softwareentwicklung zu den Top Performern zählen, in den 4 Key Metriken um Größenordnungen besser abschneiden. Bleibt die Frage - wie bekommen sie das hin? Softwareentwicklung ist eine komplexe Angelegenheit, daher sind Schlussfolgerungen “Das Team ist erfolgreich, weil es X und Y gemacht hat” schwierig. Im Rahmen von Accelerate haben die Autoren in ihren Studien jedoch 24 Eigenschaften und Fähigkeiten (Capabilities) ermittelt, die statistisch signifikant zu Verbesserungen der Software-Entwicklungsgeschwindigkeit beitragen 1.

Bei vielen Talks und Artikeln, die sich mit der Skalierung der Softwareentwicklung beschäftigen, kann man eine grundlegende Verbesserung, abseits von anekdotischen Schilderungen, meist nur schwer erkennen. Vielmehr bleibt oft eher die Frage: Hilft das wirklich? Ganz anders verhält es sich bei den Erkenntnissen, die Forsgren, Humble & Kim im Buch “Accelerate” 1 beschreiben: Hier wurde auf Basis von groß angelegten Umfragen ermittelt, welche Eigenschaften mit hoch performanten Softwareentwicklungs-Teams korrelieren und welche nicht.

Sind flexible Teamstrukturen gut oder schlecht? Auf der einen Seite wünscht sich (meist) das Management Flexibilität bei den Teamstrukturen, damit die richtigen Leute an den wichtigsten Themen arbeiten können. Auf der anderen Seite ist Stabilität über einen längeren Zeitraum notwendig, um ein Hochleistungsteam zu entwickeln. Was machen wir mit diesem Zielkonflikt? Flexibilität - Woher kommt der Wunsch? Der Bedarf Teams flexibel zusammenzustellen entsteht genau dann, wenn die Skills zur Bearbeitung eines Themas nicht zu den Skills des Teams passen.

Ein Work in Progress Limit hilft den Fokus zu halten und so den gewünschten Kundennutzen schneller zu liefern, statt viele Dinge über einen langen Zeitraum parallel zu bearbeiten. Abbildung 1 illustriert die Idee (siehe Die Illusion von Fortschritt - Unproduktive Geschäftigkeit). Abbildung 1: Ein WiP Limit schafft Fokus und führt zu schnelleren Ergebnissen. Aber was, wenn das so nicht funktioniert? Wenn man sich auf ein Thema fokussiert, das sich dann aber trotzdem über einen langen Zeitraum zieht, wie in Abbildung 2?

Was meine ich mit ‘Prozessgefrickel’? Ideen umsetzen wie sie reinkommen. Man hört oder liest etwas und setzt es im Unternehmen oder Team um, manchmal mit externer Unterstützung, ohne zu überlegen, ob die Voraussetzung überhaupt gegeben sind. Es macht (meiner Meinung nach) zum Beispiel überhaupt keinen Sinn, einen Discovery-Delivery Prozess im Team einzuführen, wenn man kein echtes crossfunktionales Team mit einer gewissen Reife hat. Punktuelle Problemlösung. Im Grunde werden hier Lösungen für Symptome gesucht, statt den Ursachen nachzugehen.

Wir haben im Blog schon öfter Literatur zu verschiedenen Themen betrachtet, wie zum Beispiel Legacy Code oder Dysfunktionen in Teams. Team Topologies geht auf die Ebene des Organisationsdesigns und der Team-Interaktion ein, denn auch diese ist für effektive Software-Teams notwendig. Man könnte jetzt denken, das ist hauptsächlich ein Thema für Manager und Organisationsentwickler, aber die zugrunde liegenden Prinzipien gelten für alle Team-Mitglieder in Softwareentwicklungs-Teams und sind daher auch für sie interessant.

Unproduktive Geschäftigkeit Arbeitet ein Team an zu vielen Themen gleichzeitig, spezialisieren sich irgendwann die Mitarbeitenden auf einzelne Themen. Das hat desaströse Konsequenzen für das Team: Wissenssilos: Fällt eine Person aus, steht das Thema solange komplett still, bis sie wieder da ist und weiterarbeiten kann. Suboptimale Lösungen: Arbeitet nur eine Person an einem Thema, fehlt die Diskussion über verschiedene Lösungswege, es gibt kein Pair Programming und Reviews sind oberflächlicher. Damit steigt die Wahrscheinlichkeit, dass einfachere und bessere Lösungswege übersehen werden bzw.

A Leadership Fable - Kathryn & ihr Team Der Großteil des Buches kommt als fiktionale Business-Novelle daher. Das kann man mögen oder nicht, aber es hilft, sich die Konflikte und Probleme in der Teamarbeit anschaulich vor Augen zu führen. Das Buch behandelt den CEO Kathryn und ihr Leadership-Team der fiktionalen Silicon-Valley-Firma DecisionTech, Inc. Kathryn ist frisch auf den CEO-Posten berufen wurden, nachdem die Firma — 150 Mitarbeiter groß, die Gründer teilweise noch selbst an Bord — immer mehr interne Probleme anhäuft.