Agile Praktiken, die in Schweizer Teams standhalten

Agilität ist in Schweizer Softwareteams lange genug Standard, dass die interessante Frage nicht mehr lautet, ob man sie einführt. Sie lautet, welche Teile noch Arbeit leisten — und welche Rituale sind, die überlebt haben, weil niemand die Sitzung abgesagt hat.

Warum es weiterhin zählt, ehrlich gesagt

Das Argument für Agilität ist nicht Geschwindigkeit. Teams, die sie einführen, liefern pro Monat selten mehr als vorher.

Das Argument ist der Rückmeldeabstand. Ein Team, das alle zwei Wochen erfährt, ob es richtig lag, entscheidet besser als eines, das es nach neun Monaten erfährt — und die Kosten des Irrtums sinken mit dem Abstand. Das ist der ganze Mechanismus, und jede Praxis unten verkürzt diesen Abstand oder eben nicht.

Das ist zugleich ein nützlicher Filter. Eine Praxis, die den Rückmeldeabstand nicht verkürzt und kein Risiko senkt, ist eine Gewohnheit.

1. Hybride Frameworks, gewählt statt geerbt

Reines Scrum ist in Schweizer KMU-Teams selten — und das ist meist richtig, nicht ein Mangel an Disziplin.

Was die meisten funktionierenden Teams betreiben, ist eine Mischung: iterative Planung mit einem Kanban-Fluss für Support und Unterbrechungen, weil dasselbe Team beides bearbeitet und alles andere zu Sprints führt, die am Mittwoch aufgegeben werden.

Zwei Regeln halten eine Mischung ehrlich:

• Unterbrechungsarbeit ist sichtbar. Steht Supportarbeit nicht am Board, ist Kapazitätsplanung Fiktion und jeder Sprint überbucht.
• Der Takt hat einen Zweck. Löst die Sprintgrenze keine Entscheidung aus — ausliefern, Richtung ändern, aufhören —, ist sie ein Kalender und kein Takt.

2. KI in der Planung: nützlich für den langweiligen Teil

Der realistische Einsatz von KI in der Lieferung ist nicht die Vorhersage von Ergebnissen. Es ist die Beseitigung manueller Arbeit an den Rändern: Release Notes entwerfen, Störungen zusammenfassen, eingehende Tickets nach Bereich vorsortieren, ähnliche frühere Fälle finden.

Überschätzt wird die Schätzung. Ein Modell, das auf Ihren historischen Tickets trainiert ist, lernt Ihren historischen Optimismus — und gibt ihn selbstsicher wieder.

Ausprobieren lohnt sich: Erstsortierung und Klassifizierung. Skepsis lohnt sich: bei allem, was ein Datum mit einer Vertrauenszahl daneben nennt.

3. DevSecOps: Sicherheit in der Pipeline, nicht danach

Für Schweizer Teams trifft hier Agilität auf eine Pflicht, die nicht verhandelbar ist.

Nach revDSG/nDSG und DSGVO sowie nach FINMA-Erwartungen bei Finanznähe brauchen Sie Nachweise: Zugriffskontrollen, Prüfpfade, dokumentierten Umgang mit Personendaten. Eine Sicherheitsprüfung am Ende eines Release-Zyklus erzeugt diese Nachweise langsam und verzögert das Release.

In der Pipeline ist es nahezu kostenlos:

• Abhängigkeits- und Schwachstellenprüfung bei jedem Build
• Erkennung von Zugangsdaten vor dem Commit, nicht nach der Veröffentlichung
• Infrastruktur als Code, damit die Konfiguration prüfbar ist
• Zugriffe planmässig überprüft, nicht nach einem Vorfall

Nichts davon ist exotisch. Es ist der Unterschied zwischen Compliance als Liefersteuer und Compliance als Nebenprodukt.

4. Kennzahlen, die etwas bedeuten

Die meisten agilen Kennzahlen messen den Prozess statt das Ergebnis. So optimieren Teams am Ende die Velocity — eine Zahl, die sich verbessern lässt, indem man anders zählt.

Vier, die sich schlecht manipulieren lassen:

• Durchlaufzeit einer Änderung — von «wir haben entschieden» bis «es ist live». Die aussagekräftigste Zahl, die ein Lieferteam hat.
• Auslieferungsfrequenz — ein Hilfswert für die Losgrösse. Kleine Lose scheitern kleiner.
• Fehlerquote von Änderungen — der Anteil der Releases, die eine Korrektur brauchen.
• Zeit bis zur Wiederherstellung — weil Ausfälle sicher sind und die Erholungsgeschwindigkeit der steuerbare Teil ist.

Zwei Dinge sind zu vermeiden. Velocity als Ziel ist eine vom Team definierte Arbeitseinheit; ein Ziel darauf garantiert, dass sich die Definition verschiebt. Individuelle Kennzahlen verwandeln ein gemeinsames System in einzelne Anreize, und die Zusammenarbeit geht zuerst.

5. Kultur ist der Teil, der sich nicht übertragen lässt

Jede Praxis oben lässt sich von einem Team einführen, das nichts davon hat — und das Versagen sieht immer gleich aus: Die Praxis ist da, das Verhalten, auf dem sie beruht, nicht.

Eine Retrospektive, in der niemand etwas Unbequemes sagt, ist eine Sitzung. Ein Standup, das nach oben Status meldet, ist ein Statusbericht. Eine Definition of Done, die unter Druck ausgesetzt wird, ist ein Vorschlag.

Die Verhaltensweisen, die es tatsächlich tragen:

• Schlechte Nachrichten reisen schnell und ohne Strafe
• Die Person, die der Arbeit am nächsten ist, entscheidet
• Fertig heisst fertig — getestet, dokumentiert, auslieferbar

Diese lassen sich nicht installieren. Man kann sie nur sicher machen — und schnell merken, wenn sie es nicht sind.

Was im Schweizer Umfeld anders ist

Drei Anpassungen lohnen sich bewusst.

Dokumentation ist hier kein Overhead. Die agile Vorliebe für funktionierende Software gegenüber Dokumentation wird oft als Erlaubnis gelesen, sie wegzulassen. In einem regulierten Schweizer Umfeld ist die Dokumentation Teil der Lieferung, und sie als Verschwendung zu behandeln erzeugt später ein Prüfungsproblem.

Zusagen werden wörtlich genommen. Eine Schweizer Kundin, die «zwölf Wochen» hört, hört zwölf Wochen. Sagen Sie zwölf bis vierzehn, wenn das die Wahrheit ist — eine vorsichtige Schätzung kostet weit weniger als ein verpasster Termin.

Verteilte Teams brauchen Überlappung, nicht nur Werkzeuge. Liegt Lieferkapazität ausserhalb der Schweiz, hängen die Praktiken oben an Abstimmung am selben Tag. Reviews und Demos innerhalb des Arbeitstags sind der Unterschied zwischen einem Team und einer Warteschlange — ausgeführt in Tech-Teams in der Schweiz ohne Verzögerung skalieren.

Weiterführend

• Sieben Veränderungen der digitalen Transformation 2026
• Dedizierte Entwicklungsteams
• Softwareentwicklung

Wenn Sie eine Aussensicht darauf möchten, welche Ihrer Praktiken noch Arbeit leisten, vereinbaren Sie ein Gespräch. Unverbindlich.