Warum wollen KMU agil werden?
Die Gründe sind vielfältig: Kunden erwarten schnellere Ergebnisse und mehr Mitsprache, Märkte verändern sich rascher, Fachkräfte suchen Arbeitsumfelder mit mehr Eigenverantwortung, und Projekte scheitern an starren Plänen, die von der Realität überholt werden. Agiles Arbeiten verspricht, auf diese Herausforderungen besser zu reagieren: durch kurze Zyklen, regelmässiges Feedback und Teams, die selbst entscheiden, wie sie ihre Arbeit erledigen. Das Agile Manifest fasst diese Haltung in vier Werten zusammen, etwa Reagieren auf Veränderung mehr als das Befolgen eines Plans [1].
Wichtig ist, das eigene Warum klar zu formulieren. «Wir wollen agil werden» ist kein Ziel. «Wir wollen Kundenprojekte mit weniger Nacharbeit abschliessen» oder «Wir wollen neue Angebote schneller am Markt testen» sind Ziele, an denen sich die Transformation messen lässt. Ohne klares Ziel werden Methoden eingeführt, ohne dass sich Ergebnisse verbessern, und nach einiger Zeit macht sich Enttäuschung breit.
Welche Vorteile und Hürden haben KMU?
| Vorteile | Hürden |
|---|---|
| kurze Wege und wenige Hierarchieebenen | Schlüsselpersonen arbeiten in vielen Projekten gleichzeitig |
| schnelle Entscheidungen durch die Geschäftsleitung | Geschäftsleitung entscheidet oft selbst über Details |
| direkter Kundenkontakt | Kunden erwarten Festpreise und feste Zusagen |
| überschaubare Teams, die sich kennen | wenig Budget für Schulung und externe Begleitung |
| Veränderungen sind schnell spürbar | Tagesgeschäft lässt wenig Raum für Experimente |
Die Vorteile überwiegen oft, wenn die Geschäftsleitung die Transformation aktiv trägt. In KMU entscheidet die Haltung weniger Personen darüber, ob agiles Arbeiten gelingt. Eine Geschäftsleitung, die Teams Entscheidungen überlässt, Fehler als Lerngelegenheit versteht und selbst an Reviews teilnimmt, beschleunigt den Wandel erheblich.
In welchen Phasen verläuft eine agile Transformation?
| Phase | Inhalt | Dauer (Orientierung) | Ergebnis |
|---|---|---|---|
| Verstehen | Ziele klären, Ausgangslage erheben, geeignetes Pilotprojekt wählen | einige Wochen | Warum, Pilotprojekt, Unterstützung der Geschäftsleitung |
| Pilotieren | ein Team arbeitet mit Scrum oder Kanban, begleitet und ausgewertet | drei bis sechs Monate | Erfahrungen, angepasste Arbeitsweise, erste Ergebnisse |
| Anpassen | Rahmenbedingungen ändern: Budgetierung, Verträge, Rollen, Werkzeuge | parallel und danach | Organisation unterstützt agile Teams |
| Ausweiten | weitere Teams starten, Erfahrungen weitergeben, Abstimmung zwischen Teams | fortlaufend | agiles Arbeiten als Normalfall in passenden Bereichen |
Die Phase Anpassen wird oft unterschätzt. Ein Pilotteam kann agil arbeiten, stösst aber schnell an Grenzen, wenn Budgets jährlich mit festem Umfang vergeben werden, Kundenverträge nur Festpreise kennen oder Mitarbeitende nach individuellen Zielen beurteilt werden, die Teamarbeit nicht belohnen. Diese Rahmenbedingungen müssen sich mit der Arbeitsweise verändern, sonst bleibt die Transformation an der Oberfläche.
Wie wählt man ein geeignetes Pilotprojekt?
- Unsichere Anforderungen, bei denen frühes Feedback einen sichtbaren Unterschied macht.
- Ein überschaubarer Umfang von einigen Monaten, damit Ergebnisse bald sichtbar werden.
- Ein motiviertes Team, das sich freiwillig auf die neue Arbeitsweise einlässt.
- Ein Auftraggeber oder Kunde, der regelmässig Zeit für Reviews hat.
- Wenig Abhängigkeiten zu anderen Bereichen, damit das Team weitgehend selbstständig arbeiten kann.
- Ausreichend Bedeutung, damit Erfolg wahrgenommen wird, aber kein existenzielles Risiko.
Ob agil oder klassisch für ein Vorhaben überhaupt passt, lässt sich mit dem Punkteraster im Beitrag Agil oder klassisch? prüfen. Für den Start des Teams bietet flenio.ch eine Checkliste zum Start eines agilen Teams.
Welche Rolle spielen Führungskräfte?
Agile Teams sind laut Scrum Guide selbstmanagend: Sie entscheiden intern, wer was wann und wie tut [2]. Für Führungskräfte bedeutet das einen grundlegenden Rollenwechsel. Sie setzen Ziele und Rahmen, sorgen für die nötigen Ressourcen, beseitigen Hindernisse, die das Team nicht selbst lösen kann, und schaffen ein Umfeld, in dem Probleme offen angesprochen werden. Sie verteilen keine Aufgaben mehr und kontrollieren nicht den täglichen Fortschritt.
Dieser Wechsel ist für viele Führungskräfte die grösste Herausforderung der Transformation. Hilfreich ist, wenn sie die neue Arbeitsweise selbst erleben, etwa indem sie an Reviews teilnehmen und dort Entscheidungen treffen, oder indem die Geschäftsleitung ihre eigenen Vorhaben in einem Kanban-Board führt. Die Seite Agile Leadership auf flenio.ch vertieft das Thema. Auch HERMES beschreibt für die Verwaltung, wie Steuerung und agile Umsetzung zusammenspielen [3].
Welche Stolpersteine sind typisch?
| Stolperstein | Folge | Gegenmittel |
|---|---|---|
| Methode ohne Ziel | Rituale ohne Wirkung | klares Warum mit messbaren Zielen |
| Flächendeckender Start | Überforderung, wenig Lernen | mit einem Pilotteam beginnen |
| Führung gibt keine Entscheidungen ab | Teams warten auf Freigaben, keine Eigenverantwortung | Entscheidungsbereiche klar übertragen |
| Rahmenbedingungen bleiben klassisch | Pilot stösst an Budget- und Vertragsgrenzen | Budgetierung, Verträge und Beurteilung anpassen |
| Halbes Scrum | Probleme werden Scrum zugeschrieben | erst vollständig anwenden, dann bewusst anpassen |
| Keine Begleitung | typische Fehler werden wiederholt | erfahrene Person intern oder extern für die ersten Zyklen |
Der Stolperstein «halbes Scrum» verdient besondere Aufmerksamkeit. Der Scrum Guide hält fest, dass Scrum unveränderlich ist; wer nur Teile umsetzt, kann das tun, aber das Ergebnis ist nicht Scrum [2]. Viele Enttäuschungen entstehen, weil Teams genau die Elemente weglassen, die Veränderung bewirken, etwa die Retrospektive oder einen Product Owner mit echter Entscheidungsbefugnis. Mehr zur vollständigen Anwendung im Beitrag Scrum Guide 2020 verständlich erklärt.
Woran messen Sie den Erfolg der Transformation?
- Zeit von der Idee bis zur Nutzung durch Kunden oder Mitarbeitende.
- Anteil der Projekte, die ohne grössere Nacharbeit abgenommen werden.
- Zufriedenheit der Kunden mit Zusammenarbeit und Ergebnissen.
- Zufriedenheit und Fluktuation im Team.
- Durchlaufzeiten und Durchsatz der Teams als Flussmetriken.
Wichtig ist, eine Ausgangsbasis zu erheben, bevor die Transformation beginnt. Ohne Vorher-Werte lässt sich später nicht zeigen, ob sich etwas verbessert hat. Die Zahl eingeführter Events oder geschulter Personen ist dagegen kein Erfolgsmass; sie misst Aktivität, nicht Wirkung.
Beispiel: Ein Beratungsunternehmen mit 30 Mitarbeitenden
Ein Beratungsunternehmen möchte interne Digitalisierungsprojekte schneller abschliessen, die bisher oft monatelang verzögert wurden. Die Geschäftsleitung wählt als Pilot die Einführung eines neuen Kundenportals, ein Team aus vier Personen arbeitet in Sprints von zwei Wochen, ein Partner übernimmt die Verantwortung des Product Owners. Nach drei Monaten liegt eine erste Version im Einsatz, die Kunden geben regelmässig Rückmeldung. Die Retrospektiven zeigen, dass der Product Owner zu wenig Zeit hat; die Geschäftsleitung entlastet ihn von einem Kundenmandat.
Im zweiten Schritt werden die Erfahrungen auf zwei weitere interne Projekte übertragen, und die Geschäftsleitung führt ihre eigenen strategischen Vorhaben auf einem Kanban-Board mit WIP-Limit. Nach einem Jahr ist die durchschnittliche Dauer interner Projekte deutlich gesunken, und die Zahl gleichzeitig laufender Vorhaben hat sich halbiert. Kundenprojekte werden weiterhin teils klassisch, teils agil geführt, je nach Auftrag.
Werkzeuge in der Transformation
Werkzeuge ersetzen keine Haltung, können aber die Transformation erleichtern. Ein gemeinsames Werkzeug für Boards, Backlogs, Zeiterfassung und Berichte macht Arbeit sichtbar und schafft eine gemeinsame Sprache zwischen agilen Teams und Geschäftsleitung. In Flenio lassen sich agile Boards und klassische Projekte mit Phasen nebeneinander führen, sodass Teams im eigenen Tempo umstellen können. Den Gesamtzusammenhang zeigt der Leitfaden Agiles Projektmanagement in der Praxis.
Wie wird die Transformation kommuniziert?
Veränderungen der Arbeitsweise lösen Unsicherheit aus. Mitarbeitende fragen sich, was sich für sie ändert, ob ihre Rolle bestehen bleibt und wie sie künftig beurteilt werden. Eine offene Kommunikation ist deshalb entscheidend: Warum verändern wir uns, was genau probieren wir aus, was bleibt gleich, und wie können sich alle einbringen? Bewährt haben sich regelmässige, kurze Updates der Geschäftsleitung, offene Reviews des Pilotteams, zu denen alle eingeladen sind, und ein ehrlicher Umgang mit Rückschlägen.
Wichtig ist auch, Befürchtungen ernst zu nehmen. Wer bisher als Projektleiter Aufgaben verteilt hat, fragt sich, welche Rolle er in einem selbstmanagenden Team spielt. Wer gerne allein arbeitet, fragt sich, wie viel Abstimmung künftig nötig ist. Solche Fragen lassen sich nicht mit Präsentationen beantworten, sondern nur im Gespräch und durch Erfahrung. Viele ehemalige Projektleitende finden in Rollen wie Product Owner, Scrum Master oder in der Steuerung hybrider Vorhaben neue, oft befriedigendere Aufgaben.
Wie bleibt die Veränderung nachhaltig?
Viele Transformationen verlieren nach den ersten Erfolgen an Schwung. Die Begleitung endet, neue Projekte setzen andere Prioritäten, und alte Gewohnheiten kehren zurück. Nachhaltig wird die Veränderung, wenn sie in Strukturen verankert ist: in der Budgetierung, in Verträgen, in Rollenbeschreibungen, in der Beurteilung und in den Werkzeugen. Hilfreich ist zudem eine interne Gemeinschaft, in der Scrum Master, Product Owner und interessierte Mitarbeitende Erfahrungen austauschen, etwa in einem monatlichen Treffen.
Ebenso wichtig ist die regelmässige Überprüfung der Ziele vom Anfang: Haben sich die Ergebnisse verbessert, für die die Transformation gestartet wurde? Wenn ja, wird das sichtbar gemacht und gefeiert. Wenn nicht, wird ehrlich analysiert, woran es liegt, und das Vorgehen angepasst. Eine Transformation ist kein Projekt mit Enddatum, sondern der Übergang in eine Arbeitsweise, die sich selbst laufend verbessert.