Das Erste, was in solchen Situationen zu hören ist, ist meist eine Version von: "Wir haben Agile ausprobiert. Es hat hier nicht funktioniert." Dieses Unternehmen, ein Start-up für zielgerichtete Werbung, das kürzlich übernommen worden war und seine Belegschaft verdoppelte, hatte zwei Jahre lang Scrum ausprobiert. Die Zeremonien, die Rollen und die Tickets in Jira waren vorhanden. Was fehlte, waren die Vorteile. Also hatte man aufgehört.

Als externe Unterstützung eintraf, hatte die Organisation eine fest verschlossene Tür für alles, was nach einer neuen Arbeitsweise klang. Das bedeutete, dass etwas Neues sorgfältig eingeführt werden musste.

Beginnen, ohne es anzukündigen

Der verwendete Ansatz lässt sich als "Kanban im Verborgenen" beschreiben, Kanban-Praktiken einführen, ohne mit dem Namen oder der Theorie voranzugehen. Das ist keine Täuschung. Es ist Pragmatismus. Wenn eine Organisation einen starken Anti-Agile-Reflex hat, ist der schnellste Weg, ihn zu neutralisieren, das auslösende Vokabular nicht zu verwenden. Der Fokus bleibt auf dem tatsächlichen Problem: Die Arbeit dauert zu lange, Menschen können nicht sehen, was passiert, niemand kann vorhersagen, wann etwas fertig sein wird.

Die ersten Aktivitäten waren diagnostisch. Interviews mit Teammitgliedern, Führungskräften und Stakeholdern zeigten ein durchgängiges Bild: zu viele gleichzeitig aktive Dinge, unklare Prioritäten, Wissen, das auf wenige Personen konzentriert war, und wachsende Frustration über einen konstanten Strom ungeplanter Arbeit, der alles Geplante störte.

Zuerst Visualisierung

Die Organisation hatte sich vollständig auf Jira verlassen, um Arbeit zu verfolgen. Jira ist ein mächtiges Werkzeug, aber es ist leicht, sich darin zu verstecken, ein technisch vollständiges Bild der laufenden Arbeit zu haben, das niemand tatsächlich für die wichtigen Gespräche nutzt.

Die erste strukturelle Veränderung war der Wechsel zu physischen und digitalen visuellen Boards, die den tatsächlichen Arbeitsfluss greifbar machten. Stand-ups wechselten dazu, das Board von rechts nach links zu durchgehen, beginnend mit der Arbeit, die dem Abschluss am nächsten ist, und alles Blockierte oder Veränderte zu besprechen. Diese einfache Umkehrung lenkt die Aufmerksamkeit auf das Fertigstellen statt auf das Beginnen, was sich als die wichtigere Disziplin herausstellt.

Tickets wurden neu gestaltet, um verschiedene Arbeitstypen zu unterscheiden: geplante Features, ungeplante Anfragen, technische Arbeit und operative Probleme. Das klingt administrativ, hat aber eine unmittelbare praktische Wirkung: Teams können erkennen, ob ungeplante Arbeit ein kleines Ärgernis oder systematisch alles andere überwältigt. In diesem Fall war es Letzteres.

Work in Progress begrenzen

Mit wachsender Sichtbarkeit und Vertrauen wurden WIP-Limits eingeführt, zunächst informell als geteilte Disziplin, später expliziter. Das Prinzip ist einfach: Das System kann nicht unbegrenzt viel Arbeit gleichzeitig aufnehmen, ohne dass alles langsamer wird. Limits zwingen das Team, zu beenden, bevor neu begonnen wird. Sie machen Engpässe sichtbar. Sie machen die Kosten von Überlastung sichtbar.

Stakeholder in diesen Prozess einzubinden, war entscheidend. Als Kunden und interne Stakeholder den Arbeitsfluss in Echtzeit sehen konnten, hörten sie auf, ängstliche Status-Anfragen zu senden. Transparenz reduzierte den Aufwand, Erwartungen zu managen, weil Erwartungen nun auf Realität statt auf Optimismus beruhten.

Was sich verbesserte

Innerhalb weniger Monate hatten sich mehrere Dinge messbar verändert. Die Vorhersehbarkeit der Lieferung verbesserte sich deutlich. Die Anzahl der gleichzeitig laufenden Elemente sank, was den paradoxen Effekt hatte, den Durchsatz zu erhöhen: weniger aktive Dinge, mehr tatsächlich fertiggestellte. Technische Engpässe, die chronisch gewesen waren, wurden handhabbar, als sich der Wissensaustausch verbesserte.

Die Reflexion des CTO über den Prozess war aufschlussreich: Das Prinzip "mit dem beginnen, was gerade getan wird" von Kanban war der Schlüssel gewesen. Es umging den Widerstand, der entsteht, wenn Menschen gesagt wird, anders zu arbeiten. Stattdessen half es Menschen, ihre aktuelle Arbeit klarer zu sehen, und aus dieser Klarheit folgte Verbesserung ganz natürlich.

Niemand musste den Jobtitel ändern. Niemand musste ein zweitägiges Framework-Training besuchen. Es reichte, sehen zu können, was passiert, und darauf zu vertrauen, etwas dagegen tun zu können.