IT-Agilität für Schweizer Finanzteams: Scrum, Kanban und der Weg dazwischen

Agilität ist ein ganzheitlicher Ansatz, um in einer dynamischen Digitalwelt schneller und kundenorientierter zu arbeiten. Diese Definition klingt gut, aber sie erklärt wenig darüber, was eine Buchhaltungsabteilung in Zürich konkret tun soll, wenn der Geschäftsführer nach dem letzten Transformationsseminar beschliesst, "agil zu werden".

In meiner Arbeit mit Schweizer Finanzteams erlebe ich diesen Moment regelmässig. Die Motivation ist echt: Prozesse sind träge, Entscheidungen dauern zu lang, IT-Projekte liefern zu spät und zu teuer. Agilität verspricht Abhilfe. Das Problem beginnt meist damit, dass "agil werden" mit "Scrum einführen" gleichgesetzt wird, ohne zu verstehen, was Scrum ist, warum es entwickelt wurde, und ob es zum eigenen Kontext passt.

Zwei Begriffe, die oft verwechselt werden: Iterativ und Inkrementell

Bevor ich auf konkrete Methoden eingehe, möchte ich eine Unterscheidung ansprechen, die in der Praxis fast immer verwischt wird: den Unterschied zwischen iterativ und inkrementell.

Iterativ bedeutet: Das System wird schrittweise verbessert. Man baut eine erste Version, erhält Feedback, überarbeitet, verbessert, überarbeitet wieder. Jeder Zyklus produziert eine vollständigere oder bessere Version des Gleichen. Ein Beispiel: Das Team baut einen Bericht, zeigt ihn dem Nutzer, erhält Rückmeldungen ("Die Spalte Betrag sollte in CHF gerundet sein, nicht in Rappen"), überarbeitet ihn, zeigt ihn erneut. Das ist Iteration.

Inkrementell bedeutet: Das System wird Stück für Stück aufgebaut. Jede Lieferung fügt ein neues, eigenständig nutzbares Element hinzu. Das Gesamtprodukt entsteht durch Addition, nicht durch Überarbeitung. Beispiel: Das Team baut zuerst nur das Dashboard, liefert dieses produktiv aus, baut dann den Export, liefert ihn aus, baut dann die Automatisierung.

Die meisten agilen Methoden kombinieren beides, aber das Verhältnis variiert stark. Scrum ist stark iterativ. Continuous Delivery ist stark inkrementell. Wer nicht unterscheidet, setzt oft das falsche Werkzeug ein.

Scrum: Wofür es gemacht wurde und wofür nicht

Scrum wurde in den frühen 1990er-Jahren für Softwareentwicklungsteams entwickelt, die komplexe Produkte unter sich ändernden Anforderungen bauen. Der Kern ist bekannt: ein Backlog mit priorisierten Anforderungen, Sprints von typischerweise zwei Wochen, tägliche kurze Meetings (Daily Scrum), Sprint Reviews und Retrospektiven.

Was Scrum gut kann: komplexe, neue Probleme unter Unsicherheit lösen. Wenn niemand weiss, wie die Lösung aussehen soll, helfen kurze Iterationszyklen, schnell zu lernen und den Kurs zu korrigieren.

Was Scrum schlecht kann: repetitive Wartungsarbeit, Notfallbearbeitung, und Tätigkeiten mit stark schwankenden Prioritäten. Eine Finanzabteilung, die täglich neue Zahlungsfreigaben, Anfragen von Lieferanten und Ad-hoc-Auswertungen verarbeitet, kann keinen Sprint planen, weil der Backlog von aussen bestimmt wird und die Puffer-Logik von Scrum mit dieser Realität kollidiert.

Ein Fehler, den ich in der Schweizer Praxis mehrfach gesehen habe: Ein Finanzteam führt Scrum ein, weil der CIO es angeordnet hat. Die zweiwöchigen Sprints werden beibehalten, aber die Hälfte jedes Sprints wird für Dinge verbraucht, die "eigentlich nicht geplant waren". Die Retrospektiven drehen sich immer um dieselben Themen: zu viele Unterbrechungen, unrealistische Sprint-Commitments, Frustration auf allen Seiten. Das liegt nicht daran, dass das Team schlecht arbeitet. Es liegt daran, dass Scrum für diesen Kontext nicht passt.

Kanban: Die unterschätzte Alternative

Kanban kommt aus der Fertigungsindustrie, genauer aus dem Toyota Production System der 1950er-Jahre. Die Übertragung auf Wissensarbeit und IT wurde in den 2000er-Jahren durch David Anderson entwickelt. Das Grundprinzip ist elegant: Arbeit wird als Fluss visualisiert. Aufgaben bewegen sich von "To Do" über "In Progress" zu "Done". Die entscheidende Regel: Begrenzung der gleichzeitig laufenden Arbeit (Work in Progress Limit, kurz WIP-Limit).

WIP-Limits erzwingen Fokus. Wenn das Team maximal drei Aufgaben gleichzeitig in Bearbeitung haben darf, und vier Aufgaben vorliegen, muss eine warten. Das fühlt sich kontraintuitiv an, ist aber der Kern von Kanbans Wirksamkeit: Es macht Engpässe sichtbar, statt sie zu verstecken.

Für Schweizer Finanzteams mit stark schwankenden Prioritäten und viel operativer Arbeit ist Kanban oft die bessere Wahl als Scrum. Es gibt keine fixen Planungszyklen, keine Sprint-Commitments, und die Methode lässt sich schrittweise einführen, ohne den bestehenden Arbeitsablauf komplett zu verändern.

Ein konkretes Beispiel aus der Praxis: Ein fünfköpfiges Finanzteam einer Industriegruppe in der Zentralschweiz hat 2023 auf Kanban umgestellt. In den ersten vier Wochen wurde nur die Visualisierung eingeführt: ein physisches Whiteboard mit Haftnotizen, drei Spalten. In Woche fünf wurde das erste WIP-Limit eingeführt: maximal zwei Aufgaben pro Person in "In Progress". Das Team brauchte drei Monate, um die Methode zu verinnerlichen. Nach sechs Monaten hatte sich die durchschnittliche Bearbeitungszeit von Finanzdokumenten von neun auf vier Arbeitstage halbiert.

Lean: Der übergeordnete Rahmen

Neben Scrum und Kanban ist Lean eine dritte Methode, die in Finanzteams zunehmend diskutiert wird. Lean fokussiert auf die Eliminierung von Verschwendung in Prozessen. Die sieben Verschwendungsarten aus der Lean-Theorie (Überproduktion, Wartezeiten, unnötiger Transport, Überbearbeitung, Lagerbestände, unnötige Bewegungen, Fehler) lassen sich direkt auf Finanzprozesse übertragen.

In meiner Arbeit nutze ich Lean häufig als Diagnose-Werkzeug, bevor ich mit einem Team über Scrum oder Kanban spreche. Die Frage "Wo sind Ihre grössten Wartezeiten?" ist oft der direkteste Weg zu den wichtigsten Verbesserungschancen. Und manchmal stellt sich heraus, dass die grösste Verbesserung nicht durch eine neue Methode entsteht, sondern durch die Abschaffung eines Berichts, den seit Jahren niemand mehr liest.

Typische Fehler bei der agilen Einführung

In der Beratungspraxis sehe ich immer wieder dieselben Fehler, wenn Schweizer Finanzteams agile Methoden einführen.

Der erste und häufigste Fehler ist fehlender Leadership-Buy-in. Agilität verändert die Arbeitsweise der direkten Führungsebene grundlegend. Wenn Teamleitende und Abteilungsleiter die Methode nicht verstehen und aktiv unterstützen, scheitert die Einführung unabhängig von der Qualität der Schulung. Ich beginne Einführungsprojekte daher immer mit einem halbtägigen Workshop für Führungskräfte, der die eigene Rolle in einem agilen System klärt.

Der zweite Fehler ist das Überstürzen von Zeremonien. Scrum-Meetings (Daily, Review, Retro, Planning) haben eine klare Funktion. Teams, die diese Meetings mechanisch durchführen, ohne ihren Zweck zu verstehen, erleben sie als Zeitverschwendung. Der Daily Scrum ist kein Statusbericht für die Führungskraft. Er ist eine kurze Selbstkoordination des Teams: Was habe ich gestern getan, was mache ich heute, was blockiert mich? Wenn die Führungskraft im Daily die meiste Redezeit hat, ist die Funktion nicht verstanden.

Der dritte Fehler ist Widerstand gegen Transparenz. Agile Methoden machen Arbeit und Fortschritt sichtbar. Das ist in vielen traditionellen Unternehmenskulturen ungewohnt. Ein Kanban-Board zeigt nicht nur, was erledigt wurde, sondern auch, was seit drei Wochen nicht vom Fleck kommt. Diese Sichtbarkeit wird von manchen Mitarbeitenden als Kontrolle empfunden. Hier ist Führung gefragt: Transparenz dient der Selbststeuerung des Teams, nicht der Überwachung durch Management.

Der vierte Fehler ist zu schnelle Skalierung. Ein Team führt Kanban ein, es funktioniert gut, und sofort wird entschieden, die gesamte Abteilung auf die Methode umzustellen. Agilität skaliert nicht wie ein Software-Feature. Was in einem fünfköpfigen Team funktioniert, muss für eine 50-köpfige Abteilung vollständig neu konzipiert werden.

Der richtige Startpunkt für Schweizer Finanzteams

Wenn mich Finanzteams fragen, wo sie beginnen sollen, ist meine Antwort fast immer dieselbe: klein, konkret, und mit einem echten Problem.

Wählen Sie einen Prozess, der Sie wirklich frustriert. Nicht den grössten, nicht den strategisch wichtigsten, sondern den, bei dem alle im Team sagen: "Das könnte so viel besser sein." Visualisieren Sie diesen Prozess auf einem Whiteboard oder mit einem digitalen Tool wie Trello oder Jira. Führen Sie ein WIP-Limit ein. Halten Sie zwei Wochen lang täglich eine kurze Runde von 10 Minuten, in der das Team bespricht, was den Fluss blockiert. Dann messen Sie: Hat sich die Bearbeitungszeit verändert?

Wenn ja, haben Sie etwas Wichtiges gelernt: nicht, ob Kanban oder Scrum besser ist, sondern dass Ihr Team in der Lage ist, sich selbst zu verbessern, wenn es die richtigen Strukturen hat. Das ist das Fundament von Agilität, und von dort aus lässt sich alles weitere aufbauen.

Quellen und weiterführende Literatur

• Scrum Guide (2020) — Ken Schwaber und Jeff Sutherland, die offizielle Scrum-Referenz
• David J. Anderson: Kanban — Successful Evolutionary Change for Your Technology Business (2010) — Grundlagenwerk für Kanban in der Wissensarbeit
• Lean Enterprise Institute — Ressourcen zu Lean-Methoden und Verschwendungsanalyse
• ZHAW — Digitalisierung im Schweizer Finanzsektor — Institut für Finanzdienstleistungen Zug, Forschung zur Digitaltransformation
• Swiss Digital Report — Jährlicher Bericht zum digitalen Reifegrad Schweizer Unternehmen

---

Haftungsausschluss: Dieser Artikel dient ausschliesslich zu Informationszwecken und stellt keine Finanzberatung dar. Die beschriebenen Methoden sind allgemeine Managementpraktiken und ersetzen keine individuelle Organisationsberatung. Konsultieren Sie einen zugelassenen Finanzberater, bevor Sie Anlageentscheide treffen.