Die Kulturrevolution – „So machen wir das hier.“ – Teil 1

 

 

Inhalt: Teil 1 – Teil 2 – Teil 3  Teil 4 – Teil 5

 

Kampf zwischen revolutionärer und evolutionärer Innovation?

 

Eine Blog Reihe auf DevOps.ch zu kulturellen Herausforderungen in Unternehmen im Zuge der digitalen Veränderung, von Sven Ossenberg

 

„Culture eats strategy for breakfast.“

 

 

Die allermeisten von Euch haben diesen viel zitierten Satz, der Peter Drucker zugeschrieben wird, gelesen, gehört oder sind ihm irgendwo einmal begegnet. Doch stimmt dieser Satz, der seit gefühlt 20 Jahren umherschwirrt eigentlich noch? Und was ist die Kernaussage dazu?

 

Ich finde, nach wie vor beschreibt das Zitat mehr denn je vor welchen kulturellen Herausforderungen Unternehmen im Zuge des digitalen Wandels stehen.
Die beste Innovationsstrategie ist zum Scheitern verurteilt, wenn dahinter nicht eine gelebte und akzeptierte Innovationskultur steht.

 

Kultur ist, was zahlreiche Befragungen besonders in Unternehmen zu Tage bringen, meist etwas sehr Unkonkretes und Nichtgreifbares.

Die Kultur in Unternehmen jedoch beschreibt Werte, Einstellungen und Elemente des täglichen Miteinanders in Organisationen. Unternehmenskultur ist dabei immer etwas sehr besonderes und abhängig vom jeweiligen Unternehmen und in großen Teilen auch beeinflusst vom übergreifenden Kulturkreis, in dem das Unternehmen ansässig ist. Ich drücke es wie Bright und Parkin mal stark
verkürzt aus: 

 

 

“This is how we do things around here.”

 

Doch wie wird es gemacht, wer macht was und wissen alle, warum es gemacht wird?

 

Veränderungen

 

Schauen wir uns die aktuelle Entwicklung im DevOps Umfeld einmal nüchtern betrachtet an.
Es ist Zeit für eine neue Art von Leadership, eine mit den Fähigkeiten und Kenntnissen, in einem sich schnell verändernden Umfeld zu agieren und dabei die Ziele der Organisation im Auge zu behalten.

Die Person, die sich dazu befähigt fühlt, soll das Team motivieren und zur Zusammenarbeit befähigen. Es ist Zeit für neue Rollen, deren Fähigkeiten sich auf die Transformation von DevOps konzentrieren. Agilität als Buzz Word unserer Zeit hat im Gegensatz zu immer wieder auftauchenden Mythen klare Regeln und Frameworks. Hier braucht es dringend Fähigkeiten als Coach bzw. als «Facilitator». Letztere Rolle ist nicht zu unterschätzen, ist sie doch eine der Schlüsselpositionen.

Im Folgenden schauen wir uns verschiedene innovative Modelle und Ansätze an und wie neu geschaffenen Positionen im DevOps Umfeld helfen, Teams und Organisationen zu transformieren.

Wer soll/kann/muss diese Rolle übernehmen?

Lebhafte Diskussionen und Auseinandersetzungen zu diesem emotionalen Thema sind vorbestimmt und gewünscht.

Dafür soll ein Blog ja auch da sein 😊

 

Auf zu neuen Ufern

 

Viele von uns, wie auch ich, kennen sicher noch die Probleme unserer eigenen IT-Vergangenheit.
Wir kannten das Gefühl der Unlösbarkeit von Problemen und wie sie sich hartnäckig hielten.

Software-Projekte liefen über Monate oder Jahre und überschritten dann aufgrund einer Vielzahl von Problemen die Release-Termine. Wir haben jahrelang mit diesen Problemen gelebt und wussten, dass es einen besseren Weg geben musste, aber wir wussten nicht, an wen wir uns wenden sollten.

 

Und dann kam Agiles Development daher und schien die Situation zu verbessern.
Doch diese neue Art der agilen Arbeitsweise war nur der Anfang.

Bald hatten wir die gesamte Bandbreite von DevOps Praktiken und Prinzipien kennengelernt, um Agilität auf die nächste Stufe zu bringen. Kürzere Arbeits-Zyklen, häufigere Deployments, Automatisierung der Build- und Deployment-Strecken.
Nach Jahren – sogar Jahrzehnten – des Kampfes mit schwerfälligen Prozessen bahnte sich ein revolutionärer Wandel an.

 

Diese neue Art der Herangehensweise veränderte die IT Kultur, sowie langjähriger zementierter Praktiken, die nicht mehr dem modernen Geschäftstempo entsprachen.
Schnell erkannte man, dass es bei einer DevOps Transformation eben nicht nur um Technologie und Methodik geht; es geht um Menschen und eine bessere Arbeitsweise. Eine neue Form der Arbeitskultur zog ein.

 

Die Idee, dass die Entwickler an einem Ort sitzen und eifrig Code produzieren, während der Betrieb darauf wartet, dass dieser fertig wird, bevor er getestet und bereitgestellt wird, war eine der Schwächen der alten Herangehensweise.

Die Änderungen, die erforderlich waren, um zu Continuous Integration und Continuous Delivery zu gelangen, machten die Code-Blöcke kleiner und der Betrieb, sowie das Testteam zu einem integralen Bestandteil des frühen Entwicklungsprozesses.
Kleine Teams, die iterativ in kurzer Zeit testbare Ergebnisse erreichen, wurde bald Normalität.

Bezeichnenderweise ändert DevOps nicht die von der IT-erbrachten Leistung an sich, sondern die Art und Weise, wie die IT diese erbringt.
Das bedeutet im Umkehrschluss jedoch auch, dass sich auch die Art und Weise, wie die Erbringung gehandhabt wird, ändern muss. Die sich daraus ergebenden Möglichkeiten machen es zu einer idealen Gelegenheit, um in der IT eine Vorreiterrolle zu spielen und zu einer noch besseren Gelegenheit bei DevOps eine Führungsrolle in der gerade stattfindenden Transformation zu übernehmen.

 

 

Nächste Woche beschäftigen wir uns mit den Unterschieden zwischen dem DevOps Ansatz und dem traditionellen IT-Management