construction

Falsch dimensioniert

Ein häufiger Grund für das Scheitern von Agilität in Unternehmen schon bei der Einführung ist eine falsche Dimensionierung. Menschen an sich sind zwar anpassungsfähig und im Kern agil,  auch wenn sie nicht immer offen für Neues sind und an Gewohnheiten hängen. Einführungsprojekte für Agilität werden aber meistens in bestehenden Unternehmensstrukturen und nicht aus dem Blickwinkel der konkret Betroffenen gedacht. Diese Unternehmensstrukturen wiederum hindern Menschen oft daran, agil zu sein.

Die falsche Dimensionierung bei Einführung und Durchführung geht in mehrere Richtungen. Viele denken zu klein, andere zu groß und die Meisten starten in irgendwie gearteten Silos.

Zu klein gedacht

Wenn Agilität als Projekt eingeführt wird, dann handelt es sich in der Regel um die Einführung eines Frameworks, meistens um Scrum. Viele Unternehmen setzen also den Wandel zur Agilität mit der Einführung von Scrum in der Softwareentwicklung gleich.  Das ist nicht verwunderlich. Denn auch wenn die Grundideen von Scrum bereits aus dem Januar 1986 stammen (“The New New Product Development Game” von Hirotaka Takeuchi und Ikujiro Nonaka), wurde das erste Scrum Regelwerk von Ken Schwaber and Jeff Sutherland erstmals 1995 auf der OOPSLA Konferenz (Object-Oriented Programming, Systems, Languages & Applications) vorgestellt und beschreibt einen Prozess für die Softwareentwicklung.

Nicht selten erlebt man nach der Einführung von Scrum Manager, die sich ein “wir sind schon agil” auf die Brust schreiben und deren Agilität sich dennoch auf “Scrum in ein paar Entwicklungsteams” beschränkt (die dann häufig nicht m al eine Ende zu Ende Verantwortung haben und abhängig sind von Test- oder Release-Teams, vom internen Betrieb oder Marketingabteilungen).

Eine agil arbeitende Softwareentwicklung reicht nicht aus. Software ist kein Selbstzweck, sondern Mittel zum Zweck und liefert losgelöst von anderen Abteilungen selten einen Wert. Wenn Release- oder Test-Zyklen, Werbekampagnen, interne Organisation oder Sales in alten Rhythmen und Strukturen unterwegs sind, wird sich die Softwareentwicklung über kurz oder lang immer schneller um sich selbst drehen, ohne für den Kunden einen deutlichen Mehrwert zu generieren. Bei der Einführung handelt es sich um einen grundlegenden Wandel der Werte und Prinzipien. Unterschiedliche Werte und Prinzipien innerhalb eines Unternehmens führen zu Reibung und Problemen. Die Einführung ausschließlich in ein paar Software-Entwicklungsteams verkommt damit zu einer lokalen Optimierung, die nicht dauerhaft tragfähig ist.

Das ist, als würde man einen modernen Tesla-Motor in einen rostiges altes Fischerboot einbauen, um mit moderner Technik mehr Fische fangen zu können. Dieser Plan geht nach hinten los.

 

In Silos gedacht

Manche Unternehmen haben nach ihren Erfahrungen mit der Einführung agiler Methoden in der Softwareentwicklung gelernt, dass es nicht reicht, wenn nur dieser Bereich agil wird. Unterschiedlichste Abteilungen und Bereiche bemühen sich, es der Softwareentwicklung gleich zu tun. Manche führen Scrum oder Kanban ein. Andere versuchen sich individuell auf Basis agiler Werte und Prinzipien zu organisieren. Dabei bleibt die in Silos organisierte Unternehmensstruktur bestehen und jede Abteilung oder jeder Bereich optimiert sich selbst. Über diesen Weg entwickeln sich gemeinsame Werte und Prinzipien. Das ist ein Schritt weiter, als sich im Kleinen nur auf eine Abteilung wie die Softwareentwicklung zu beschränken.

Aber: Auch wenn in solchen Organisationen einige oder alle Silos nach agilen Methoden arbeiten, handelt es sich dabei nur um mehrere lokale Optimierungen innerhalb der Silos und das kann bestenfalls ein nächster Schritt in der agilen Transition sein. Aufwand und Komplexität entsteht maßgeblich an Schnittstellen und damit in der Kommunikation zwischen Menschen, zwischen Teams, zwischen Abteilungen und weniger innerhalb der Silos selbst. Das Optimieren mehrerer Silos reicht dauerhaft nicht aus. Zukünftig muss in nah am Markt stehenden siloübergreifenden Netzwerken mit Ende zu Ende verantwortlichen Teams gedacht und gearbeitet werden.

Auch der Versuch, diese Silos durch eine Matrix-Struktur aufzulösen, führt nicht zu Ziel. Eine Matrix-Struktur verwässert und verkompliziert Entscheidungen und macht Verantwortung schwammig und unklar. Damit ist eine Matrix-Struktur als vermeintliche Lösung für das Aufbrechen von Silos ein Schritt in die falsche Richtung.

 

Die Organisation muss sich über die eigene Wertschöpfung und Wertströme Gedanken machen und interdisziplinäre Gruppen und Teams aufbauen, die nah an dieser Wertschöpfung schnelle Entscheidungen treffen können (Stichwort: Business Agility). Diese Gruppen und Teams müssen in sich stabil sein und gleichzeitig auf Veränderungen flexibel reagieren können – also agil organisiert sein.

Zu groß gedacht

Andere Unternehmen sind überzeugt von agilen Methoden und wissen: ohne ein gleiches Verständnis der Zusammenarbeit im gesamten Unternehmen kann sich kein Erfolg einstellen. Hier wird viel Geld in die Hand genommen, um ganze Unternehmen zu “agilisieren”. Diese Unternehmen schicken alle Mitarbeiter auf Trainings und führen Baukasten-Skalierungsmodelle wie SAFe ein, um einen agilen Standardprozess für alle auszurollen. Manche wagen sich gar an die Einführung ganz anderer Strukturen für ganze Unternehmen wie zum Beispiel Holacracy.

Klingt verlockend, ist aber für sich alleine genommen ebenso Unfug und kann auch nicht funktionieren, weil ein Kern agilen Arbeitens individuelle Lösungen für individuelle Probleme sind. So eignet sich Scrum manchmal, manchmal aber auch nicht, gleiches gilt für Kanban. Das eine Team arbeitet mit einer agilen Führungskraft gut, das andere aber nicht. Der Reifegrad ist von Person zu Person unterschiedlich und die Anforderungen an Teams und Abteilungen sind individuell sehr verschieden und abhängig von verschiedensten Faktoren müssen Arbeitsprozesse, Strukturen und Formen der Zusammenarbeit teilweise immer wieder neu angepasst werden.

Ein Unternehmen besteht aus Menschen. Es ist damit kein Betriebssystem, keine Maschine, sondern ein lebendiger Organismus und damit in sich zu komplex, um über zentral definierte und für alle ausgerollte einheitliche Prozesse funktionieren zu können.

 

Individuelle Prozesse bei gleicher Basis

Irgendwo muss man anfangen. Die Widerstände bei der Einführung eines Frameworks wie Scrum werden innerhalb der Softwareentwicklung  in der Regel gering sein. So kann das ein guter Start für die Einführung agiler Methoden sein. Andere starten im HR Bereich, der häufig auch für die Bereiche Learning und Organisationsentwicklung zuständig sind. Auch das kann sinnvoll sein.

Noch vielversprechender erscheint mir der Start in der Führungsmannschaft, weil sie als Vorbilder für ihre Mitarbeiter in klassischen Unternehmen mit mehr operativer Macht ausgestattet sind und jede Initiative fördern, blockieren oder verhindern können.

Egal wo und wie man klein startet: Das Grundverständnis muss sein, dass das nur der Start sein kann. Ziel sollte kein neuer unternehmensweiter Prozess, sondern eine Haltungsänderung bei den Mitarbeitern – ein agiles Miteinander, unterstützt durch Änderungen am System, sein.

Agile Mitarbeiter und individuelle Prozesse mit möglichst wenig Standardisierung sind nötig, um wendig agieren und reagieren zu können. Das Fundament für eine konstruktive Zusammenarbeit muss ein unternehmensweit einheitliches Wertesystem sein, das sich wie Milch im Kaffee im Unternehmen verteilt. Ohne gemeinsame Werte und von allen gelebte Prinzipien sorgen Reibungen und destruktive Konflikte innerhalb des Unternehmens für Widerstände und Behinderungen und unterstreichen eine Kultur des Gegeneinander.

 

Je größer ein Unternehmen, um so unterschiedlicher konkrete Arbeitsprozesse. Das ist gut und wichtig. Was nicht funktionieren wird, das sind unterschiedliche Werte im selben Unternehmen. Jedes Unternehmen braucht eine gemeinsame Basis von Werten und Prinzipien und eine übergreifende Vision als Kompass, die über reines Geld-Verdienen hinaus geht. Ohne das ist eine differenzierte aber reibungsarme Zusammenarbeit nicht möglich, der Fokus rückt von Kundennutzen zu internen politischen Kämpfen, die hochgradig schädlich für das Unternehmen sind.

Ergänzend ein sehr empfehlenswerter TED-Talk:

(Das verwendete Bild ist von Ivan – Vielen Dank!)

2 Comments

Leave a Comment

Schreibe deinen Kommentar

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