Agile Transformation: Beratung von der Standortbestimmung bis zur messbaren Wirkung

Hier ist Agilität selten neu — und genau das ist die Schwierigkeit. Scrum läuft seit Jahren, die Teams sind eingespielt, und trotzdem dauert ein Release Wochen. Der Engpass liegt meist im Zusammenspiel: gemeinsame Komponenten ohne klare Eigentümerschaft, Freigabeprozesse aus der Zeit vor der Automatisierung oder ein Produktmanagement, das mehr startet als die Teams schaffen. Wir klären Produktschnitt und Abhängigkeiten und bringen Entwicklung und Betrieb zusammen. Gemessen wird an Durchlaufzeit, Release-Frequenz, Fehlerquote nach dem Deployment und Anteil ungeplanter Arbeit.

Agile Produktentwicklung außerhalb der Software hat eine harte Randbedingung: Hardware lässt sich nicht wöchentlich ausliefern. Trotzdem funktioniert vieles: kurze Lernschleifen an Prototypen, integrierte Teams aus Konstruktion, Elektronik und Software, sichtbare Priorisierung statt paralleler Vollauslastung. Nicht funktioniert das unveränderte Übertragen eines Software-Frameworks auf einen Prozess mit Werkzeugbau und Freigaben. Wir trennen, welche Teile iterativ laufen können und welche einen festen Takt brauchen, und verbinden beides über eine gemeinsame Planung. Gemessen wird an Entwicklungszykluszeit, Anzahl später Änderungen und Termintreue zum Serienstart.

Der Anteil Software im Fahrzeug und in der Maschine wächst schneller als die Organisation dahinter. Bereiche, die über Jahrzehnte auf Baureihen und Meilensteine ausgelegt waren, sollen jetzt Funktionen kontinuierlich liefern — bei unveränderten Anforderungen an Sicherheit und Nachweisführung. Skalierungsframeworks wie SAFe sind hier verbreitet, weil sie den Takt über viele Teams synchronisieren; sie ersetzen aber nicht die Klärung, wer über eine Funktion entscheidet. Wir arbeiten am Schnitt zwischen Programm und Funktionsteams und daran, wie Zulieferer eingebunden werden. Gemessen wird an Integrationsaufwand, Zykluszeit je Funktion und Anzahl der Blockaden an Schnittstellen.

Kaum eine Branche hat so sichtbar umgebaut — und so oft erlebt, dass der Umbau auf halber Strecke stehen bleibt. Die Beispiele großer Banken zeigen beides: dass ein Zuschnitt in Tribes und Squads Entscheidungswege verkürzen kann, und dass er ohne veränderte Steuerung nur eine neue Kästchenordnung ist. Dazu kommt die Nachweispflicht: Jede Änderung muss prüfbar sein — was iteratives Arbeiten nicht ausschließt, aber gestaltet werden muss. Wir bringen Regulatorik und kurze Takte zusammen, statt eines gegen das andere auszuspielen. Gemessen wird an Bearbeitungszeit je Vorgang, Zeit bis zur Produktivsetzung und Prüfaufwand je Änderung.

Agile Verwaltung ist kein Widerspruch, beginnt aber an anderer Stelle: Haushaltsrecht, Vergaberegeln und Zuständigkeitsordnungen sind gesetzt und lassen sich nicht durch ein Vorgehensmodell ersetzen. Wirksam ist der Zuschnitt kleiner, abgegrenzter Vorhaben mit einer benannten verantwortlichen Person, sichtbarer Priorisierung und regelmäßiger Rückkopplung mit den späteren Nutzern. Wir arbeiten daran und an Ausschreibungen, die iteratives Arbeiten mit externen Partnern überhaupt zulassen. Gemessen wird an Bearbeitungsdauer, Anteil digital abgeschlossener Vorgänge und der Zeit bis zur ersten nutzbaren Fassung. Vergabe- und haushaltsrechtliche Fragen ordnen wir ein, ersetzen aber keine Prüfung im Einzelfall.

Handel und Konsumgüter steuern über mehrere Kanäle in kurzen Zyklen — Sortiment, Preis, Kampagne und Verfügbarkeit hängen zusammen und ändern sich wöchentlich. Agile Arbeitsweisen setzen hier weniger bei der Softwareentwicklung an als bei der Frage, wie schnell eine Entscheidung über Kanäle hinweg wirksam wird und wer sie treffen darf. Cross-funktionale Teams aus Category Management, Marketing, Logistik und IT wirken stärker als eine Umstellung der IT allein — geschnitten entlang von Kundenanlässen statt entlang von Abteilungen. Gemessen wird an Time-to-Market je Kampagne, Verfügbarkeit und der Zeit, die eine Sortimentsänderung bis in alle Kanäle braucht.