Verteilte Entwicklungsteams richtig führen

Verteilte Teams scheitern weit häufiger an Führungsgründen als an technischen oder kulturellen. Die Distanz erzeugt die Probleme nicht; sie entfernt den informellen Reparaturmechanismus, der sie verdeckt hat.

Ein Team am selben Ort mit unklarer Zuständigkeit löst das, indem sich jemand umdreht und fragt. Ein verteiltes Team kann das nicht, also wird aus der Unschärfe eine Verzögerung. Alles Folgende schliesst diese Lücken ausdrücklich.

Ziele setzen, die sich ohne Sie überprüfen lassen

Das häufigste Führungsversagen ist eine Vorgabe, die für die schreibende Person klar war.

Was ein Ziel über Distanz tragfähig macht:

• Umfang als das, was enthalten ist, und das, was nicht. Die Ausschlüsse leisten mehr als die Einschlüsse.
• Abnahmekriterien als Szenarien, nicht als Adjektive. «Geht angemessen mit Fehlern um» ist nicht überprüfbar; «gibt bei fehlgeschlagener Validierung einen 422 mit dem Feldnamen zurück» schon.
• Nicht-funktionale Erwartungen benannt — Antwortzeit, Datenmengen, gleichzeitige Nutzende. Lokal werden sie vorausgesetzt, verteilt müssen sie gesagt werden.
• Der geschäftliche Grund. Ein Team, das weiss, warum etwas gewünscht ist, entscheidet die hundert kleinen Fragen besser, die Sie nie sehen.

Die Prüfung: Könnte jemand, der nicht im Gespräch war, verifizieren, dass es fertig ist? Wenn nein, haben Sie eine geteilte Annahme — und geteilte Annahmen überstehen keine Zeitzonengrenze.

Ergebnisse messen, nicht Aktivität

Der Reflex bei einem Team, das man nicht sieht, ist, Aktivität zu messen — Stunden, geschlossene Tickets, Commits. Jede dieser Zahlen ist leicht zu erzeugen und sagt nichts über Wert.

Vier, die sich schlecht manipulieren lassen:

• Durchlaufzeit einer Änderung — von «wir haben entschieden» bis «es ist live»
• Fehlerquote von Änderungen — der Anteil der Releases, die eine Korrektur brauchen
• Nacharbeitsquote — als nicht-fertig zurückgegebene Arbeit, meist ein Spezifikations- und kein Könnensproblem
• Nach dem Release gefundene Fehler, als Anteil der vorher gefundenen

Die Nacharbeitsquote ist die verteilungsspezifische Diagnose. Ist sie hoch, liegt der Reflex bei der Fähigkeit. Fast immer liegt die Ursache am Anfang des Prozesses: «fertig» war nicht klar genug definiert.

Aufschreiben, wer was entscheidet

In einem Team am selben Ort sind Entscheidungsrechte implizit und funktionieren meist. Verteilt bedeutet implizit, dass standardmässig alles eskaliert — was die Arbeit bremst und, schlimmer, dem Team beibringt, nicht zu entscheiden.

Drei Kategorien, schriftlich:

• Entscheidet allein — technische Umsetzung innerhalb eines abgestimmten Ansatzes, Refactoring im eigenen Bereich, Werkzeugwahl
• Schlägt vor, Sie bewilligen — Architekturänderungen, alles mit Wirkung auf andere Teams, Abwägungen beim Umfang
• Eskaliert sofort — Sicherheitsbefunde, Datenschutzbedenken, alles, was eine Zusage gefährdet

Die erste Kategorie füllen Organisationen zu knapp. Ein Team, das nichts entscheiden darf, ist eine Warteschlange mit Löhnen — und die besten Leute verlassen sie zuerst.

Kommunikation: Überlappung schlägt Werkzeuge

Die meisten Ratschläge hier handeln von Werkzeugen. Die Werkzeuge sind in Ordnung; die strukturellen Grössen sind andere.

Überlappungsstunden sind der wichtigste einzelne Faktor. Review, Demo und Antworten am selben Tag sind der Unterschied zwischen einem Team und einer Warteschlange. Ein 24-Stunden-Umlauf pro Frage macht aus einer Zweitagesaufgabe eine Woche — und das summiert sich über einen Rückstand. Deshalb zählt die Überlappung zur MEZ mehr als die Entfernung; ausgeführt in Qualitätssicherung in verteilten Entwicklungsprojekten.

Entscheidungen auffindbar aufschreiben. In einem Raum lebt die Entscheidung im Raum. Verteilt wird eine nicht festgehaltene Entscheidung drei Wochen später von jemandem neu verhandelt, der nicht dabei war.

Widerspruch günstig machen. Das teuerste Fehlerbild verteilter Lieferung ist ein Team, das etwas gebaut hat, das es für falsch hielt, weil Widerspruch aufwendig schien — ein Statusgefälle, eine Sprachhürde oder schlicht: niemand hat es je vorgelebt. Die Diagnose ist, ob Ihnen kürzlich jemand widersprochen hat. Wenn nicht, nehmen Sie an, dass der Kanal zu ist, und nicht, dass Sie recht hatten.

Kontakt kurz und häufig halten statt lang und selten. Fünfzehn Minuten täglicher Überlappung bringen Probleme schneller hoch als ein zweistündiges Wochenreview — und ein am ersten Tag erkanntes Problem kostet einen Bruchteil desselben Problems am neunten.

Dem Team geben, was Verantwortung überhaupt möglich macht

Das ist die strukturelle Voraussetzung hinter jeder Praxis oben: Ein Team, das die Folgen seiner Arbeit nicht sieht, kann keine Ergebnisse verantworten.

Praktisch heisst das Zugang zu Produktionsdaten, zur Ticket-Warteschlange, zu realen Nutzungsdaten und — wo möglich — zu den Nutzenden. Das vorzuenthalten und dann Verantwortung zu verlangen heisst, etwas zu verlangen, das nicht verfügbar ist.

Die damit mögliche Reifeentwicklung steht in Ein Global Capability Center nach Schweizer Massstab.

Die Schweizer und DACH-Besonderheiten

Der Datenzugriff gehört vor den Start geklärt. Engineers in einer anderen Rechtsordnung, die Personendaten berühren, sind eine echte Frage nach revDSG/nDSG und DSGVO. Pseudonymisierte Datensätze, dokumentierte Zugriffskontrollen und Nachweise zur Unterauftragsverarbeitung beantworten sie — aber nicht rückwirkend.

Dokumentation ist Teil der Lieferung, kein Overhead. In jedem regulierten Umfeld ist der Nachweispfad eine Anforderung, und ihn aus der Pipeline zu erzeugen kostet fast nichts, während ihn später zusammenzustellen viel kostet.

Zusagen werden wörtlich genommen. Ein Datum, das einer Schweizer Kundin genannt wird, ist ein Datum. Wo ein verteiltes Team Unsicherheit einbringt, gehört diese in die Schätzung und nicht in die Entschuldigung.

Weiterführend

• Den richtigen Softwareentwicklungspartner auswählen
• Ein Global Capability Center nach Schweizer Massstab
• Dedizierte Entwicklungsteams

Wenn ein verteiltes Team nicht liefert, was Sie erwartet haben, vereinbaren Sie ein Gespräch. Unverbindlich.