Agile Schnittstellen sind die Übergänge zwischen agilen Teams und dem übrigen Unternehmen: Governance und Entscheide, Budget und Finanzierung, Einkauf und Verträge, Betrieb und Sicherheit, Fachbereich sowie klassisch geführte Projekte. Sie funktionieren, wenn für jede Schnittstelle Takt, Informationsbedarf und Entscheidungsrechte vereinbart sind — etwa Meilensteine am Ende von Iterationen, Budgets für Teams statt für Einzelprojekte und eine gemeinsame Definition of Done mit dem Betrieb.
Warum Schnittstellen das eigentliche Problem sind
Innerhalb eines Teams lässt sich Scrum oder Kanban vergleichsweise schnell einführen. Schwierig wird es an den Rändern. Das Team plant in Sprints, das Controlling in Jahresbudgets. Das Team liefert alle zwei Wochen, der Betrieb nimmt nur quartalsweise Änderungen ab. Das Team priorisiert laufend neu, der Einkauf braucht ein festes Pflichtenheft. Jede dieser Reibungen bremst — und oft wird dem agilen Vorgehen angelastet, was eigentlich eine ungeklärte Schnittstelle ist.
Die sechs zentralen Schnittstellen
| Schnittstelle | Typische Reibung | Lösungsansatz |
|---|---|---|
| Governance und Entscheide | Gremien erwarten Phasenberichte, Team liefert Inkremente | Entscheidungspunkte auf Iterations- oder Release-Enden legen |
| Budget und Finanzierung | Projektbudgets pro Vorhaben vs. stabile Teams | Budget für Team-Kapazität, Steuerung über Prioritäten |
| Einkauf und Verträge | Festpreis mit fixem Umfang vs. offene Anforderungen | Rahmenverträge, Aufwandsmodelle, Ausstiegspunkte |
| Betrieb und Sicherheit | Häufige Releases vs. kontrollierte Änderungen | Gemeinsame Definition of Done, Automatisierung, frühe Einbindung |
| Fachbereich | Fehlende Verfügbarkeit für Reviews und Priorisierung | Feste Product-Owner-Rolle mit Mandat und Zeit |
| Klassische Projekte | Unterschiedlicher Takt und unterschiedliche Planungstiefe | Gemeinsame Meilensteine und Abhängigkeitsplanung |
Governance: Entscheide im richtigen Takt
Gremien brauchen Entscheidungsgrundlagen, keine Sprintberichte. Bewährt hat sich, übergeordnete Entscheide auf natürliche Einschnitte zu legen — das Ende eines Releases oder mehrerer Iterationen —, an denen ein integrierter, vorführbarer Stand vorliegt. So entscheidet ein Lenkungsausschuss auf Basis dessen, was wirklich funktioniert, statt auf Basis von Planständen. HERMES sieht genau diese Einbettung vor: Das agile Vorgehen läuft innerhalb, die Steuerung setzt an definierten Punkten an.
Budget: Teams finanzieren statt Projekte
Klassische Budgetierung bewilligt Geld für ein Vorhaben mit definiertem Umfang. Agile Arbeit ändert den Umfang laufend. Viele Organisationen lösen den Widerspruch, indem sie stabile Teams über einen Zeitraum finanzieren und über Prioritäten steuern, was diese Teams liefern. Die Kontrolle verschiebt sich von der Frage «Wurde der Umfang erfüllt?» zur Frage «Liefert das Team den erwarteten Nutzen?».
Wo Budgetprozesse nicht geändert werden können, hilft ein Zwischenweg: ein Projektbudget mit klaren Zielen und einem priorisierten Backlog, dessen Umfang innerhalb des Budgets angepasst werden darf. Der Auftraggeber entscheidet an Meilensteinen, ob weitere Mittel sinnvoll sind.
Einkauf: Verträge für veränderliche Anforderungen
Ein Festpreis mit detailliertem Pflichtenheft verträgt sich schlecht mit Anforderungen, die sich erst während der Umsetzung klären. Alternativen sind Rahmenverträge mit Abrufen, Aufwandsmodelle mit Kostendach, Festpreise pro Iteration oder Release und vereinbarte Ausstiegspunkte. In der öffentlichen Beschaffung sind die Spielräume enger, aber vorhanden: Zuschlagskriterien können Vorgehen und Teamqualität stärker gewichten als ein vollständiges Pflichtenheft.
Betrieb: gemeinsam definieren, was «fertig» heisst
Die Reibung zwischen schnellen Releases und stabilem Betrieb verschwindet, wenn der Betrieb früh Teil der Definition of Done wird: Monitoring, Dokumentation, Sicherheitsprüfungen und Rückfallpläne gehören dann zu jedem Inkrement, nicht in eine Übergabephase am Ende. Automatisierte Tests und Deployments machen häufige Änderungen beherrschbar.
Klassische und agile Projekte im selben Portfolio
In den meisten Organisationen laufen agile und klassisch geführte Vorhaben nebeneinander und hängen voneinander ab — etwa eine agile Softwareentwicklung und eine klassisch geplante Infrastrukturbeschaffung. Die Verbindung gelingt über gemeinsame Meilensteine und eine explizite Abhängigkeitsplanung: Welche Lieferung wird wann gebraucht? Ein Werkzeug, das Boards und Meilensteine in derselben Sicht zeigt, macht diese Abhängigkeiten für beide Seiten sichtbar.
Vorgehen: Schnittstellen bewusst gestalten
- 01Schnittstellen auflistenMit welchen Einheiten arbeitet das Team zusammen, wo entstehen Wartezeiten?
- 02Bedarf klärenWelche Information braucht die Gegenseite, in welchem Takt, in welcher Form?
- 03Entscheidungsrechte festlegenWer entscheidet was — im Team, beim Product Owner, im Gremium?
- 04Vereinbarung festhaltenTakt, Formate und Rechte schriftlich vereinbaren und nach einigen Iterationen überprüfen.
Häufige Fragen
- Was sind agile Schnittstellen?
- Die Übergänge zwischen agilen Teams und dem übrigen Unternehmen, etwa zu Governance, Budget, Einkauf, Betrieb, Fachbereich und klassisch geführten Projekten.
- Wie passen agile Teams und Lenkungsausschüsse zusammen?
- Indem Entscheide auf natürliche Einschnitte wie Release- oder Iterationsenden gelegt werden, an denen ein vorführbarer Stand vorliegt.
- Wie finanziert man agile Teams?
- Häufig über Budgets für stabile Teams über einen Zeitraum, gesteuert über Prioritäten statt über einen fixen Umfang.