Als Entwicklungsleitung sind wir es seit Jahren gewohnt, mit räumlich verteilten Teams zu arbeiten. Der Austausch mittels Mails, Chat, Telefon- und Videokonferenzen hat sich zwar etabliert, aber:
Verteiltes und autonomes Arbeiten führt auch weiterhin zu unterschiedlichen/widersprüchlichen Interpretationen von Anforderungen und Aufgaben.
Wir haben uns daher bewusst dazu entschieden, in allen Projekten “20 Minuten tägliches Grundverständnis” zu vermitteln. “Grundverständnis” ist laut Literatur die “Fähigkeit, sich in etwas bzw. jemanden hineinzuversetzen, jemanden, etwas zu verstehen; innere Beziehung zu etwas; Einfühlungsvermögen aufzubauen”. Verstehen ist nicht nur die bloße Kenntnisnahme eines Sachverhalts, sondern die intellektuelle und fachliche Erfassung der Zusammenhänge. Wer versteht kann erklären und vor allem lösen.
Was hat das in der Softwareentwicklung zu suchen? Wir glauben fest daran, dass Projekterfolg davon abhängig ist, dass alle Projektbeteiligten ein klares “Grundverständnis” zu den fundamentalen Fragen haben:
In unseren Team-Meetings lassen wir jeden Tag ein Teammitglied sein Grundverständnis zum Projekt in 5 Minuten beschreiben. Danach erfolgt zusätzlich in 5 Minuten die Erklärung des Teammitglieds zu seinen eigenen Aufgaben. Auch noch ungeklärte Fragestellungen sind hier ausdrücklich erwünscht, damit verhindern wir unabgestimmte Interpretationen. Nach diesem aktiven Part des Team-Mitglieds bleiben noch 10 Minuten für Reflexion der Gruppe, jeweils einzeln und ohne Unterbrechung bzw. Rechtfertigung.
Bildquelle: You X Ventures,
Unsplash
In Gruppengrößen mit bis zu 9 Personen ist dieses Vorgehen praktikabel. In einem größeren Umfeld mit bis zu 150 Beteiligten haben wir das zweistufig gemacht. In Einheiten bis zu 9 Personen gibt es das tägliche Gespräch, und jede Gruppe entsendet wöchentlich wechselnd einen Sprecher, der übergreifend im größeren Rahmen das “Grundverständnis” darlegt. Im Ergebnis haben wir mit dem Grundverständnis und der bewussten Kontext-Aufbereitung die Qualitätsprobleme senken können. Auch wurden in der Phase der Integrationstests und in der Anlaufunterstützung signifikant kürzere Bug-Fix-Zeiten gegenüber anderen Projekten erzielt.
Vielleicht ein Ansatz, der Sie in Zeiten von umfangreichen Remote-Tätigkeiten vor teuren Folgefehlern bewahrt? Lassen Sie uns Ihre Erfahrungen wissen.
Christoph Lefkes