Wenn Prozesse Teams zum Stillstand bringen

Das Konzept steht, die Architektur ist klar, der Code an sich unproblematisch. Es geht also fast nur noch um die Umsetzung.

In früheren Projekten wäre das in wenigen Tagen durchgewesen. Programmierung, Build, Anbindung der Services, Deployments auf verschiedene Umgebungen – das Team hat es selbst gemacht. Wenn in einer Sandbox etwas schiefgelaufen ist, wurde es selbst abgeräumt und neu gestartet. Meist eine Sache von Minuten.

Heute sieht das anders aus. Für die meisten Schritte muss das Team Menschen aus anderen Teams einschalten. Ein fehlerhaftes Deployment in einer Dev-Umgebung kann nicht mehr selbst bereinigt werden. Stattdessen wandert es in einen Request, ein Ops-Team nimmt es auf, und irgendwann – oft erst nach einer Erinnerung – wird aufgeräumt.

Die eigentliche Arbeit dauert unverändert Minuten. Der Weg dorthin dauert im Durchschnitt einen halben Tag.

Versprochen wurden Qualität und Sicherheit

Die Absicht hinter den neuen Prozessen ist seriös. Qualität soll steigen, Fehler sollen früh erkannt werden, niemand soll blind Änderungen in ein System werfen. Skalierung braucht Regeln, das ist kein neuer Gedanke.

Dazu kommt Sicherheit als eigene Anforderung. Wer auf welche Umgebung zugreifen darf, ist keine Teamfrage mehr. Berechtigungen werden eng geschnitten, Zugänge laufen über definierte Wege, jede Änderung ist einem Namen zuordenbar. Das erklärt auch, warum ein Team seine eigene Sandbox nicht mehr aufräumen kann: Die Rechte dafür liegen inzwischen woanders.

Ein Teil der Gates ist ohnehin nicht verhandelbar. Wo Audit-Pflichten gelten, muss nachweisbar sein, wer eine Änderung freigegeben hat und wann sie in Produktion ging. Das ist eine Anforderung von außen, keine Frage des Stils.

Für den Rest klingt die Begründung in der Theorie plausibel: Je mehr Stellen prüfen, desto weniger kann schiefgehen. Je klarer ein Prozess definiert ist, desto weniger hängt von individuellem Wissen ab. Verantwortung wird sichtbar verteilt.

Das ist erstmal nicht falsch.

Geliefert wurde Abhängigkeit

In der Praxis entstehen aus verteilter Verantwortung fachlich abgeschottete Stellen und aus Zuständigkeiten eine Warteschlange.

Früher konnte das Team eine Änderung vom Code bis zur Umgebung eigenständig begleiten. Heute steht an vielen Stellen eine andere Person zwischen Absicht und Ergebnis. Bewegung kostet dadurch Zeit – nicht weil jemand langsam arbeitet, sondern weil jeder Schritt auf eine Zusage wartet. Eine Aufgabe, die früher in Eigenregie erledigt war, braucht jetzt mehrere Handoffs und Geduld.

Dazu kommt, dass dieses Warten nirgends vereinbart ist. Es gibt keine zugesagte Reaktionszeit, keinen gemeinsamen Termin, keine Abstimmung zwischen den Planungen. Das andere Team hat eigene Prioritäten und einen eigenen Sprint – dort landet der Request als Störung, nicht als eingeplante Aufgabe.

Für das wartende Team heißt das: Der Zeitpunkt ist nicht vorhersehbar. Dieselbe Anfrage ist manchmal in zwei Stunden erledigt und manchmal in drei Tagen. Damit lässt sich nicht planen. Die Aufgabe wird beiseitegelegt, das Team wechselt das Thema und baut sich den Kontext bei der Rückkehr neu auf. Ausgebremst wird es dabei weniger von der Dauer als von der fehlenden Absprache darüber.

Irgendwann kippt das Verhältnis. Wer einen Request schreibt, ihn nachverfolgt, an ihn erinnert und die Rückmeldung einarbeitet, verbringt mehr Zeit mit dem Prozess als mit der Änderung. Prozessarbeit wird zur Hauptaufgabe. Im Statusbericht fällt das kaum auf: Der Request existiert, er ist in Bearbeitung, der Prozess läuft.

Unklare Verantwortung wiegt schwerer

Verteilte Verantwortung ist dabei noch das kleinere Problem. Schwerer wiegt unklare Verantwortung.

Der Fall sieht so aus: Ein Team fühlt sich für eine Komponente verantwortlich. Es pflegt sie, kennt ihre Eigenheiten und wird bei Fehlern gefragt. Gleichzeitig greifen andere Teams darauf zu, ändern Konfigurationen, ziehen Abhängigkeiten nach oder passen eine gemeinsame Umgebung an – unangekündigt. Die Folgen trägt das Team, das sie nicht verursacht hat.

Die fehlende Absprache wirkt also in beide Richtungen. Das Team wartet auf andere, und es wird von anderen überrascht.

Diese Kombination ist besonders zäh. Wer verantwortlich ist, aber nicht kontrolliert, was passiert, verbringt seine Zeit mit Rekonstruktion: Was hat sich geändert, wer hat es geändert, seit wann. Die Fehlersuche beginnt nicht am Fehler, sondern bei der Frage, wer zuletzt etwas angefasst hat.

Auf Dauer erzeugt das eine Haltung, die dem Stillstand entgegenkommt. Wer mehrfach für Entscheidungen geradestehen musste, die er nicht getroffen hat, hört auf, Verantwortung zu übernehmen. Ein Zuständigkeitsgefühl lässt sich nicht anordnen. Es verschwindet, wenn es wiederholt bestraft wird.

Stillstand verkleidet sich als Qualität

Unter all dem liegt ein Paradoxon. Prozesse werden eingeführt, damit niemand mehr blind handelt. Wenn sie aber so weit gehen, dass niemand mehr handeln darf, entsteht genau das Gegenteil: Menschen folgen blind Regeln, weil sie nicht mehr selbst entscheiden können.

Wer keine Autonomie hat, braucht auch kein Urteilsvermögen mehr. Wer nicht urteilt, lernt es nicht. Das ist gefährlich, vor allem in technischen Bereichen, in denen Kontext und Erfahrung wichtig sind.

Daraus wird eine schleichende Erosion von Fähigkeiten. Dinge, die früher zum Alltag gehörten, werden delegiert und verlernen sich. Das Team weiß immer weniger über den eigenen Stack, weil es ihn nicht mehr selbst bedienen darf. Prozesse ersetzen nach und nach nicht nur Entscheidungen, sondern auch die Kompetenz, sie zu treffen.

Der umgekehrte Fehler

Zu wenig Prozess führt zum selben Ergebnis. Das Video 8 Regeln für den totalen Stillstand sammelt diese Gegenseite. Eine der Regeln: Führung entweder komplett kontrollieren oder plötzlich völlige Freiheit geben. Eine andere: Ziele und Veränderungen nur informell und als Gerüchte laufen lassen. Wo kein verbindlicher Rahmen existiert, bleibt ebenfalls alles stehen – dort wartet niemand auf eine Freigabe, sondern auf Orientierung.

Stillstand entsteht also an beiden Enden der Skala. Damit ist die Dosierung das eigentliche Thema, nicht die Frage nach Prozess oder keinem Prozess.

Feedbackkanäle trocknen aus

Ein Detail fällt im Projektalltag besonders auf: Feedback wird gesammelt, aber nicht eingebaut.

Teams erleben, dass ihre Hinweise auf Reibungsverluste nichts verändern. Nach einiger Zeit melden sie weniger. Das ist naheliegend: Warum auf etwas hinweisen, wenn klar ist, dass nichts passiert? Damit verliert eine Organisation genau die Information, die sie bräuchte, um die Dosierung zu korrigieren.

Was würde helfen

Nicht jeder Prozess ist schlecht. Aber ein guter Prozess ist ein Geländer, kein Schienensystem.

Die Trennlinie lässt sich am Eingangsbeispiel ziehen. Eine kaputte Sandbox zurücksetzen: Self-Service für das Team, kein Request. Einen Service in einer Dev-Umgebung anbinden: ebenfalls Teamsache. Ein Deployment nach Produktion: hier ist eine Freigabe sinnvoll, und wo Nachweispflichten gelten, ist sie vorgeschrieben.

Sicherheit spricht dabei nicht gegen Autonomie. Ein Team kann Schreibrechte auf seine eigene Dev-Umgebung haben, ohne dieselben Rechte in Produktion zu bekommen. Das ist eine Frage des Zuschnitts von Berechtigungen, und die löst sich über Rollen, nicht über Wartezeit.

Für geteilte Umgebungen genügt eine schlichte Regel: Wer etwas ändert, das andere nutzen, kündigt es vorher an. Das kostet eine Nachricht und spart die halbe Fehlersuche. Und Verantwortung braucht einen klaren Zuschnitt – ein Team, das für eine Komponente geradesteht, muss auch entscheiden dürfen, was mit ihr passiert.

Als Faustregel: Ein Gate ist dort gerechtfertigt, wo ein Fehler über die eigene Umgebung hinaus wirkt, wo das Team ihn nicht selbst reparieren kann oder wo eine Nachweispflicht es verlangt. Alles andere gehört in die Hand derjenigen, die die Arbeit machen.

Fazit

Stillstand kommt nicht immer von fehlender Motivation oder zu wenig Personal. Manchmal kommt er von zu vielen gut gemeinten Regeln – manchmal von zu wenig Verständigung darüber, wer was entscheiden darf.

Zwei Fragen für das nächste Team Meeting: Welche Regel bremst gerade mehr, als sie nützt? Und wofür steht das Team ein, ohne es entscheiden zu dürfen?

Quellen

• „8 Regeln für den totalen Stillstand“ (2008): YouTube