Agile

Agile Scaling – Agil anwenden oder Agil sein?

SCRUM, Kanban und Co sind nicht nur leere Schlagworte in unserer IT. Seit Jahren werden mehr und mehr Projekte agil abgewickelt, nicht immer allerdings von Erfolg gekrönt. Auch Agile Vorgehensmodelle können versagen. Vor allem, wenn sie nicht richtig angewendet und ihr größter Vorteil, die Flexibilität und Anpassbarkeit, ausgespielt wird. Agile Scaling Methoden versuchen, dem vorzubeugen. Dennoch gibt es einen gravierenden Unterschied zwischen Agil anwenden und Agil sein.
Hirn

Die Flexibilität bezieht sich dabei auch auf die rasche Anpassbarkeit an die verschiedenen Projekte und Umgebungen. Dazu müssen aber beinahe alle agilen Vorgehen skaliert werden. Die immer umfangreichere Literatur – teilweise mit Kochrezepten für das garantierte Gelingen ihres agilen Vorhabens – und immer wieder neue oder adaptierte Methoden bieten heute ein Regelwerk, das dem agilen Gedanken in vielen Bereichen widerspricht. An dieser Stelle wird unter Skalierung die Anpassbarkeit des agilen Vorgehens an die entsprechenden Situationen verstanden:

  • Upscaling: Übertragen und Anpassen von Vorgehen und Methoden, die ursprünglich für kleine Teams entwickelt wurden (wie Scrum) auf den Unternehmensweiten Einsatz. Dazu gehören auch übergeordnete Strukturen, die unter anderem Redundanzen verhindern und die Kommunikation erleichtern sollen.
  • Downscaling: Anpassen des agilen Vorgehens und der Vorgaben (auch Unternehmensinterne) wie Large Scale Scrum – kurz LeSS – an das jeweilige Projekt und Team

War bis vor kurzem mit Skalierung hauptsächlich gemeint, dass die ursprünglich für kleinere Teams entworfenen Methoden unternehmensweit eingesetzt werden können (Stichwort Scrum of Scrums), so hat in den letzten Jahren das Downscaling an Bedeutung gewonnen.

Agil ist eine Einstellung

Viele Unternehmen wenden Agile Methoden an, übersehen dabei allerdings, dass Agil sein ein Mindset, eine Einstellung, bedeutet, welches nicht von jedem geteilt wird und auch nicht über Nacht erlernt werden kann. Während Agil anwenden also die Prozess-Seite meint, bedeutet Agil sein, dass alle Mitarbeiter die entsprechende (Projekt-)Einstellung haben.

Wenn man aber die Prozesssicht auf der einen und das Mindset auf der anderen Seite nimmt, stellt sich die Frage, ob Agil überhaut skalierbar ist?

Prinzipiell ergeben sich wie weiter oben angesprochen zwei Möglichkeiten: es wird nach oben oder nach unten skaliert. Die meisten Agilen Vorgehen beziehen sich auf ein Projekt mit relativ kleinen Umsetzungsteams. Werden nun unreflektiert dieselben Prinzipien hinaufskaliert – also auf das gesamte Unternehmen übertragen – ergeben sich einige Problemfelder:

  • Mindset und Unternehmenskultur ändern sich nur langsam: Ein freiwilliges Pionier-Projekt, welches im Unternehmen das erste Mal ein agiles Vorgehen einsetzen möchte ist relativ schnell gefunden. Und eines der 12 agilen Prinzipien lautet: „Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.“ Im Pionier-Projekt werden sich diese Individuen sammeln. Wird hingegen ein agiles Vorgehen dem gesamten Unternehmen aufoktroyiert, regt sich Widerstand.
  • Abhängigkeiten zwischen Projekten und Teams: Vereinfacht gesagt: Je mehr Projekte und/oder Teams beteiligt sind, desto mehr formale Dokumentation wird benötigt. Neben der teamübergreifenden Kommunikation ist dabei auch in Betracht zu ziehen, dass einige Unternehmensbereiche (noch) nicht agil arbeiten und die agilen Vorgehen dahingehend angepasst werden müssen.
  • „In guten Zeiten kennen wir unsere Freunde, in schlechten Zeiten lernen wir sie kennen“ – der Sinn von Verträgen: Agile Vorgehen setzen auf Vertrauen (siehe auch das Prinzip aus dem vorangegangenen Punkt). Das wiederum ist leichter zwischen Personen, die sich kennen, zu erlangen. Und ist Vertrauen vorhanden, besteht eine geringe Notwendigkeit für Kontrolle und Verträge. Doch je mehr Personen, Bereiche oder Unternehmen beteiligt sind, desto schwieriger wird es, vertrauen in alle handelnden Akteure aufzubauen. Verträge werden daher weiterhin Bestandteil unserer Projektlandschaft bleiben.

Projekten Spielraum geben

Auf dem ersten Blick scheint es einfacher zu sein, die Prozesse und die Ergebnisse an die entsprechende Projektsituation anzupassen. An die Projektsituation wohlgemerkt! Denn Unternehmensweite Vorgaben, welche agile Vorgehen im Zuge eines Downscaling in ein starres Korsett zwängen, sind kontraproduktiv. Sollen bzw. müssen dennoch projektübergreifende Vorgaben erstellt werden, so empfiehlt es sich, diese allgemein zu halten und den Projekten Spielraum zu lassen. So hatte der originale SCRUM Guide von Jeff Sutherland und Ken Schwaber 16 Seiten. Die unternehmensweite Skalierung sollte daher nur erfolgen um Transparenz, gleiche Methoden und eine Sicht auf das Projektportfolio zu erreichen. Weitere Skalierungsmaßnahmen wie etwa Umfang von Dokumentationen, Kommunikationskanäle, Zeitpunkt von Meetings, Sprintdauer etc. sollen den Projekten überlassen werden.

Passende Artikel

Antwort schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*