Twilight Zone  

... oder warum so viele an Agilität scheitern

Nahezu alle Unternehmen älter als 20 Jahre sind klassisch sozialisiert – Agilität erfordert aber eine neue Denkweise. Diese Veränderung braucht Zwischenschritte und Zeit. Sie kann nicht von jetzt auf gleich herbeigeführt werden.

Wissen bedeutet nicht gleich Können. Etwas in einer Schulung erlernt zu haben reicht nicht aus. Für Können braucht es auch Erfahrung. Erfahrung macht man durch Fehler. Wichtig hierbei, aber besonders schwierig. Agile Lernzyklen können nur genutzt werden, wenn die Veränderung zur „Fehlerkultur“ damit einhergeht.

Kompetenzmodell. Angewendet nach Anleitung bedeutet noch nicht, wirklich verstanden. Das große Risiko der unbewussten Inkompetenz ist der häufigste Grund für das Scheitern von agilen Vorhaben.

The Big Ball of Mud Agile 

In der Informatik bezeichnet ein Big Ball of Mud ein Programm, das keine erkennbare Softwarearchitektur besitzt. Die häufigsten Ursachen dafür sind ungenügende Erfahrung, fehlendes Bewusstsein für Softwarearchitektur, Fluktuation der Mitarbeiter sowie Druck auf die Umsetzungsmannschaft. Die Softwarearchitektur ist so eng miteinander verzahnt, dass eine Änderung oft Auswirkungen auf das Gesamtsystem hat, welche nicht direkt ersichtlich sind.

Überträgt man nun diese Analogie auf Agile, wird man feststellen, dass es auch hier viele Dimensionen gibt, an die man am Anfang nicht gedacht hätte. Ein bisschen Scrum bei den Teams wird es schon richten. Mit jedem Mitarbeiter, der sich mit dem Thema beschäftigt, wandelt sich aber die Kultur im Unternehmen. In dieser Phase entscheidet es sich, wie lange der Wandel zur Agilität dauert und ob er erfolgreich sein sind. Wird die Veränderung vom Management gefördert oder behindert? Verhindern kann man die begonnene Veränderung in den seltensten Fällen. Das ist wie Milch im Kaffee, einmal drin, bekommt man sie nicht mehr raus, egal, wie viel ich rühre.

Wie oben beschrieben, beginnen die agilen Initiativen häufig im Kleinen und starten mit Methoden wie Scrum. Nach einer gewissen Zeit und Reife beschäftigt sich das Team mit seiner Haltung, also dem Mindset. Dort fängt die erste Veränderung in der Kultur an. Jetzt werden viele Fragen an die Organisation gestellt, da die Grenzen des Teams transparent werden. Sind die Teams nach Disziplinen (Plan-Build-Run) aufgestellt, wird schnell ersichtlich, dass der Fluss nicht optimal ist.

Im ersten Schritt wurde wahrscheinlich der Informationsfluss betrachtet. Fachbereich schreibt Konzept → Übergabe an Entwicklung → Entwickeln → Übergabe an Fachbereich zu Test und Abnahme. Hat sich an der Haltung, dem Mindset noch nichts verändert, entstehen bei Einführung von Scrum kleine Wasserfälle.

Richtig wäre: Das Konzept wird in deutlich kleinere Stücke geschnitten und unmittelbar je Stück in kürzeren Intervallen entwickelt und geliefert. verprobt und dann angepasst.

An dieser Stelle kommen die Grenzen der „normalen“ agilen Ansätze wie Scrum auf, da sie das Umfeld nicht konsequent miteinbeziehen und in einer agilen Blase verbleiben. Denn zur Verprobung müssen weitere Unternehmensbereiche, Stakeholder, Dienstleister oder sogar Kunden mit in die agile Vorgehensweise eingebunden werden.

Es wird immer klarer. Alles ist miteinander verwoben, und nur wenn alle Beteiligten mitspielen im agilen Spiel, wird es wirklich funktionieren. Dies stellt in vielen Unternehmen die Sollbruchstelle dar, an der Agilität im Unternehmen infrage gestellt wird.

Hier genau setzt FAST an und bietet einen ganzheitlichen Ansatz für alle Bereiche im Unternehmen und bei externen Dienstleistern – und ganz wichtig bis hin zum Topmanagement.