Agile Prozesse einführen / 6 Grenzen agiler Prozess-Welten

Eine agile Prozessgestaltung bietet viele valide Argumente, die Unternehmen davon überzeugen, agile Methoden tatsächlich auszuprobieren und die eigenen Prozesse agiler werden zu lassen. Hierbei gibt es durchaus unterschiedliche Ansätze mit entsprechenden Vor- und Nachteilen bei der Einführung von beispielsweise Scrum. Ob Top-Down (mit dem Mandat des Managements), Bottom-Up (Initiative aus einzelnen Teams heraus) – die Möglichkeiten sind vielfältig^[11]. In den seltensten Fällen kommt es allerdings zu einem massiven Umbruch, vielmehr wird zu Beginn zunächst im kleinen Maßstab experimentiert. Oft wird ein erstes Scrum-Team installiert, in dem dann Erfahrungen im Umgang mit den neuen Methoden gesammelt werden können. In der Regel fallen diese positiv aus. Recht schnell wird deutlich, dass die Prozesse an Geschwindigkeit und Fahrt aufnehmen, ohne dass die Qualität des Produkts darunter leidet. Im Gegenteil, oft werden sogar in kürzerer Zeit bessere Ergebnisse erzielt. Und auch die beteiligten Teams empfinden die Veränderungen als bereichernd. Bei den Mitarbeitenden entsteht ein grundsätzlich positiveres Grundgefühl und Zufriedenheit mit den neu geschaffenen Arbeitsumständen. Endlich darf man sich selbst tatkräftig in der Produktgestaltung einbringen und spürt den eigenen Beitrag deutlich mehr, da die Ergebnisse der eigenen Arbeit ständig transparent verfügbar sind.

Nicht jeder kann (und will) agil arbeiten

Durch das Umsatteln auf agile Prozessmethoden ist aber nicht sofort eitel Sonnenschein. Es können sich für die Teams im Gegenteil auch neue Herausforderungen und Schwierigkeiten ergeben. Es ist bestimmt nicht für jedes Teammitglied sofort eine Erleichterung und Verbesserung, nun so stark mitbestimmen zu können. Vielmehr erfordert die neue Freiheit, mit der auch ein höherer Grad an Verantwortung verbunden ist, zunächst eine gewisse Gewöhnung. Hierbei gelangt man mitunter zur Frage, ob "agil" wirklich für jeden Mitarbeiter das Mittel der Wahl ist bzw. sein sollte. Der Gebrauch agiler Methoden setzt, wie Agilität allgemein, ein bestimmtes Denken voraus. Dies kann nicht bei jedem Mitarbeiter, insbesondere wenn er oder sie einer klassischen Prägung entstammt, vorausgesetzt werden. Es muss vielmehr erlernt werden.

Darüber hinaus beginnt das Team unter Umständen, Scrum nicht nur als sakrosankt hinzunehmen, sondern die Methode auch kritisch zu hinterfragen und über mögliche Anpassungen, Verbesserungen und Veränderungen im Prozess nachzudenken. Meistens werden die Prozesse angepasst, weil "Workarounds" gefunden werden müssen für hierarchische Strukturen, Misstrauenskulturen oder schlechte Führungsansätze.

Letztlich erreichen viele Unternehmen eine Art gläserne Decke, denn das agile Vorgehen lässt sich nicht einfach auf die gesamte Organisation skalieren und übertragen. Die Produktentwicklungsbereiche erleben Herausforderungen an den Schnittstellen zu anderen Organisationsbereichen, die mit agilen Ansätzen bisher noch nicht vertraut sind. Selbst die Vermittlung dieser Ansätze auf Managementebene gerät zur Herausforderung. Eine Einführung agiler Methoden birgt schließlich eine ganze Reihe von Implikationen für die Organisation. Wenn sich eine Abteilung oder ein ganzes Unternehmen beispielsweise entschließt, konsequent nach dem Scrum-Framework zu arbeiten, bedeutet dies auch die Schaffung neuer Rollen. Es entsteht ein Scrum-Team, zu dem das eigentliche Team, aber auch Scrum Master und Product Owner gehören. Zusätzlich gibt es noch die bisherige Führungskraft. Teamschnitt, Rollen und Verantwortlichkeiten unterscheiden sich aber von jenen in der bisherigen Struktur. Ein konsequentes Leben nach den Grundsätzen von Scrum verlangt auch Anpassungen und Veränderungen auf struktureller Ebene. Aufgrund unterschiedlicher Entwicklungsstadien auf kultureller Ebene tritt in diesem Zusammenhang häufig ein unterschiedliches Verständnis von Agilität und deren Wirkungskraft innerhalb der Organisation zutage. Dies liegt unter anderem daran, dass in vielen Fällen Agilität nach wie vor ausschließlich mit IT und Produktentwicklung in Verbindung gebracht wird. Eine Übertragung der Ansätze in andere Bereiche ist u. a. für das Management oftmals noch nicht ohne Weiteres vorstellbar.

[11] Vgl. Maximini, Dominik (2013): Scrum – Einführung in der Unternehmenspraxis. Springer-Verlag, Berlin, S.11 ff.