Hilfe, mein Team ist blockiert

Inhaltsverzeichnis

Moin!

Escape the Feature Factory: Stefan Mintert

Stefan Mintert arbeitet mit seinen Kunden daran, die Unternehmenskultur in der Softwareentwicklung zu verbessern. Das derzeit größte Potential sieht er im Leadership; unabhängig von einer Hierarchieebene. Die Aufgabe, dieses Potential zu heben, hat er sich nach einem beruflichen Weg mit einigen Kurswechseln gegeben. Ursprünglich aus der Informatik kommend, mit mehreren Jahren Consulting-Erfahrung, hatte er zunächst eine eigene Softwareentwicklungsfirma gegründet. Dabei stellte er fest, dass Führung gelernt sein will und gute Vorbilder selten sind. Es zeichnete sich ab, dass der größte Unterstützungsbedarf bei seinen Kunden in der Softwareentwicklung nicht im Produzieren von Code liegt, sondern in der Führung. So war es für ihn klar, wohin die Reise mit seiner Firma Kutura geht: Führung verbessern, damit die Menschen, die die Produkte entwickeln, sich selbst entwickeln und wachsen können. Für Heise schreibt Stefan als langjähriger, freier Mitarbeiter der iX seit 1994.

“Wir sind durch externe Abhängigkeiten blockiert.” Wie oft habe ich diese Aussage von einem Team schon gehört? Die möglichen Gründe sind zahlreich, und folglich glaube ich nicht an eine Patentlösung.

Im Folgenden beschreibe ich einen von mehreren Fällen, die ich beobachten konnte, und biete eine erste Lösung an. Ich glaube zwar, dass es noch besser geht, aber es kommt selten auf Perfektion an. Eine praktikable Lösung, die die Blockade auflöst und Verantwortlichkeiten sichtbar macht, ist schon viel wert.
Hier das Szenario: Ein Team soll eine große Aufgabe G bearbeiten. Die Umsetzung soll in drei Schritten A, B und C erfolgen. Der Schritt B stellt eine externe Abhängigkeit zu einem anderen Team dar.

Und so läuft die Arbeit ab: Das Team zieht das Ticket G auf seinem Board in die Spalte “in progress” und implementiert den ersten Schritt A. Der zweite Schritt B ist von jemandem außerhalb des Teams zu erledigen. Bedauerlicherweise passiert das aber nicht zeitig, sodass das Ticket G tage- oder wochenlang “in progress” bleibt. Manche Teams “lösen” dieses Problem, indem sie eine dedizierte Spalte auf dem Board anlegen. Sie bekommt dann etwa die Überschrift “Blocked” oder “Extern” oder so etwas Ähnliches. Damit ist klar, dass man wartet.

Warum ist das ungünstig?

Zuerst einmal ist es nicht schön, zu arbeiten und nicht fertig zu werden. Einen Abschluss zu haben, signalisiert Fortschritt. Fortschritt bedeutet Zufriedenheit (im Hirn wird Dopamin ausgeschüttet). Des Weiteren hat es etwas mit Wertschätzung für die Arbeit des Teams zu tun. Wenn ein solches Ticket wochenlang auf dem Board verrottet, kann die Arbeit offensichtlich nicht wertvoll sein. Ich habe mit Teams gearbeitet, bei denen Jira eine durchschnittliche Cycle Time von 20, 25 oder gar 30 Wochen angezeigt hat. Selbst wenn man bei der Ermittlung der Cycle Time mit Jira viele handwerkliche Fehler machen kann, ist eine solche Durchlaufzeit ein klares Indiz für ein tieferliegendes Problem.

Besonders negativ ist der Fall dann, wenn ein Vorgesetzter dem Team die Aufgabe G aufzwingt (“dringend”, “muss” usw. sind die Vokabeln der Wahl) und der Zwischenschritt B darin besteht, dass genau dieser Vorgesetzte Feedback zur Implementierung des ersten Teils A geben soll. Bleibt dieses Feedback auf der Strecke, ist die Frustration vorprogrammiert. Das ist kein fiktives Beispiel; ich habe das bei einem Kunden beobachtet.

Eine erste Lösung

Eine kurzfristige Lösung sieht so aus: Das Team splittet die Aufgabe G in die Bestandteile A, B, C. Alle drei Teile legt man als normale Tickets (keine Sub-Tickets) an, wobei das Ticket B nicht ins Backlog des Teams gehört, sondern dorthin, wo die Arbeit erledigt werden soll (anderes Team, Vorgesetzter, externer Dienstleister usw.). Anschließend plant man ausschließlich die Erledigung von A. Auf die Erledigung von Teil B hat das Team keinen Einfluss und Teil C ist nicht “ready” für die Implementierung, nicht “ready for sprint” oder ähnlich. Mit der Implementierung des Tickets A ist etwas in Arbeit, das das Team allein erledigen kann. Die Möglichkeit einer Blockade des eigenen Teams ist verschwunden, es gibt keine externe Abhängigkeit, und die Aufgabe B liegt dort, wo jemand daran arbeiten kann.

Ist das Augenwischerei oder ein echter Gewinn?

Ich bin der Meinung, dass die Vorgehensweise eine reale, positive Wirkung besitzt. Man bekommt die eigenen Aufgaben fertig und im Idealfall auch zügig.

Das explizite Anlegen eines Tickets B macht deutlich, wer hier zu arbeiten hat, um den Gesamtfortschritt zu erzielen. Wenn das Team keine Rechte hat, um das Ticket auf dem fremden Board anzulegen, genügt auch eine freundliche Nachricht an die andere Partei, dass ein entsprechendes Ticket wünschenswert ist. Bei Jira könnte man B und C mit einem Link der Art “has to be done before” verbinden, sodass die zeitliche Abfolge deutlich erkennbar ist.

Die Cycle Time der eigenen Aufgaben wird durch das Warten auf externe Zuarbeit nicht beeinträchtigt. In einer Umgebung, in der Vorgesetzte gerne über die “Performance ihrer Teams” reden, ist es hilfreich, die eigene Durchlaufzeit mit Daten belegen zu können.
Außerdem ist es wichtig, dass das Team die Lösung in den eigenen Händen hat.

Als nachteilig sehe ich bei dieser Vorgehensweise nur einen Punkt an: Wenn es sich bei Ticket G um eine gut ausgearbeitete User Story oder ähnlich handelt, ist die Chance hoch, dass sich A, B und C nicht mehr sinnvoll als User Story ausdrücken lassen; A, B und C sind oft Fragmente eines größeren Themas, deren einzelne Implementierung keinen eigenen Nutzen bringt. Ich halte das aber für einen geringen Preis, wenn man dafür die blockierende Abhängigkeit im eigenen Team loswird.

Wenn man auf das vorgeschlagene Splitting verzichten möchte, weil ja schließlich erst nach Implementierung der Gesamtaufgabe G ein echter Nutzen erreicht wird, habe ich einen weiteren Ansatz im Angebot: Alle Beteiligte, also das eigene Team plus die Personen, die Teil B erledigen, planen gemeinsam und geben zusammen ein Commitment für die Umsetzung ab. Nun stellt sich die Frage, welcher Ansatz einfacher zu realisieren ist. (rme)