Haben sie das Potenzial ihrer Umstellung auf Agilität schon voll ausgeschöpft? Haben sie beispielsweise ihre Ziele für „Time-to-Market“ schon erreicht? Sind sie schnell genug?
Stellen Sie sich einen Entwicklungsprozess für technische Funktionen vor, der
- ein neues Feature im Vertrieb oder im Produktmanagement entstehen lässt,
- dann eine Engineering-Abteilung involviert,
- als definierte Anforderung in einem Umsetzungsteam landet,
- in einer Testabteilung auf Kundentauglichkeit geprüft wird
- und schließlich einen Rollout im operativen Betrieb braucht.
Und weil das in einer großen Organisation üblicherweise eine zentrale Prozesssteuerung erfordert, findet zwischen den einzelnen Schritten oft ein Freigabeprozess statt. So oder so ähnlich, sind viele Prozesse in große Organisationen aufgebaut. Ganz einfach, weil zentrale Steuerung bei überschaubarer organisatorischer Komplexität über sehr lange Zeit genauso gut funktioniert hat.
Und weil der Prozess nun aufgrund der hohen Erwartungshaltung der Kunden viel zu langsam läuft, beginnt man damit, die Entwicklungszeit von Innovationen in den Entwicklungsteams zu verbessern. Das klingt auf den ersten Blick sehr logisch. „Die Entwicklung ist zu langsam, da muss man schneller werden!“, ist das Argument, das man oft hört.
Jetzt nehmen wir als Beispiel an, eine Firma hätte einen solchen Prozess mit einer Durchlaufzeit von, sagen wir einmal, 6 Monaten für eine neue Anpassung am Produkt. Oft dauert die eigentliche technische Entwicklung davon vielleicht nur 6 Wochen.
Und stellen Sie sich weiter vor, man könnte in dem Prozess die Entwicklungsphase um etwa 20% verkürzen. Ich meine, nur die technische Entwicklungszeit. Was eine großartige Verbesserung für den einen Prozessschritt in der Entwicklung wäre.
Aber, um wieviel schneller hätten man eine neue Funktion damit insgesamt umsetzen können?
Ich erlebe diese Entscheidungslogik immer wieder. Es geht dann oft darum, dass man in der IT agile Teams schneller machen will. Daher haben Agilitätsinitiativen bisher oft in der IT gestartet. Aber nur in der IT.
Klaus Leopold, ein österreichischer Kanban-Pionier und wahrscheinlich einer der erfahrensten Lean und Agile-Experten für die Wissensarbeit, hat in seinem Buch „Agilität neu denken“ diesen Effekt sehr schön und einfach illustriert. Denn auch er hat das in seiner Erfahrung so erlebt.
Er beschreibt in dem Buch, dass es „Business-Agilität“ braucht, nicht nur Agilität in den Entwicklungsteams. Agile Formen der Zusammenarbeit, über den gesamten Wertschöpfungsprozess hinweg, können die Durchlaufzeit einer Innovation verändern. Wenn jedoch viele einzelne Teams zentral gesteuert werden und teilweise einzelne Teams dabei für sich abgeschlossen „Agil“ arbeiten, bleibt es doch durch das mittlere Management zentral gesteuert.
Damit verändert man den Gesamtablauf nicht wesentlich genug, um schnell zu werden. Denn oft ist es gar nicht nur die Summe der Arbeitsschritte, die Durchlaufzeit verbraucht, sondern es sind auch die Entscheidungsprozesse über die Organisation hinweg, die viel Zeit in Anspruch nehmen.
Agil oder nicht agil, das macht in dem Zusammenhang leider vielleicht keinen allzu großen Unterschied. Man könnte sich die Frage stellen, ob es eine agile Methode in den für sich getrennten Teams dann überhaupt braucht, wenn man die Möglichkeiten der agilen Zusammenarbeit dabei ohnehin nur sehr eingeschränkt nützt. Um Einzelprozessschritte zu optimieren, könnte auch eine Prozessverbesserung genügen. Wer jedoch ganzheitlich verändern will, kommt an den neuen Arbeitsmethoden wahrscheinlich nicht vorbei.
Denken Sie Agilität nicht nur für einzelne Teams. Denken Sie Agilität aus Sicht der gesamten Organisation. Möglicherweise ist der Grund, weshalb sie auf Agilität setzen, nicht die Tatsache, dass sie Agilität einführen wollen – es sind wahrscheinlich Geschäftsfaktoren, wie ein schnelleres „Time-to-Market“, die Sie dazu antreiben.
Mehr zum Thema Orientierung finden Sie auf unserer Homepage unter https://www.coverdale.at/services/orientierung
Recent Comments