Die Kulturrevulotion– „So machen wir das hier.“ – Teil 5

 

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

 

Jenseits vom Silodenken

 

 

 

 

 Wie versprochen geht es heute um die altbekannten Silos. Ein für mich tolles Thema von daher auch ein wenig ausführlicher…

Einer der schwierigsten Teile der Bewältigung des Wandels ist es, die Kommunikation zu verbessern und die IT so umzugestalten, dass sie besser funktioniert, um den Zielen und Bedürfnissen der Organisation gerecht zu werden.

 

 

Für angehende DevOps-Manager gibt es gute Beispiele und Prozesse, die ihnen bei der Gestaltung der Transformation helfen können. DevOps Leader sind im Stande, die Chance rechtzeitig zu erkennen, die sich bietet, um die nötigen Massnahmen, die es für die Neugestaltung braucht, einzusetzen. Eine ebenso wunderbare Chance, die DevOps Strukturen vorzustellen und den Groove ins Unternehmen zu bringen.

 

 

Silos aufbrechen ist der Anfang – nicht das Ende

 

Der positive Nutzen der Intensivierung der Kommunikation innerhalb von Crossfunctional Teams und des Aufbrechens traditioneller IT-Silos besteht in der Verbesserung des Ablaufs der Softwareentwicklung und in der verbesserten Deployment Fähigkeit.

 

Eine verstärkte Kommunikation allein reicht jedoch nicht aus, denn DevOps ist vielmehr eine Entwicklungsreise, die versucht, den Gesamtprozess und die daraus resultierenden Inkremente stetig zu verbessern.

 

Kurz um, das Ziel von DevOps ist es, das Business besser zu bedienen.

 

Das Ergebnis der Implementierung von DevOps ist ein Softwareprodukt (natürlich auch jedes andere Produkt), damit gewünschte Funktionen schneller implementiert werden können und im gleichen Masse weniger Fehler bei der Auslieferung verursacht. Hier sehen wir im Besonderen, wie Kultur und Automatisierung zusammenkommen und sich einander bedienen.

 

Die Hauptprofiteure dieser Veränderungen sind diejenigen, die sich bei der Führung des Unternehmens auf die IT verlassen – nämlich das Management des Unternehmens.

Wir sollten jedoch nicht unterschätzen, welch grosse Vorteile es für die IT Teams selbst hat.

 

Weniger Arbeit und effizientere Fehlerbehebung, weniger „waste of time“, da zu jederzeit die Ressourcen effektiv eingesetzt werden. Dies alles geschieht, um das tägliche „Doing“ innerhalb der IT zu verbessern.

 

Hier kommt nun endlich Mr. Conway ins Spiel. Wenn man das Conway-Gesetz betrachtet, ist es wichtig, die eigene Vision zu sehen und zu verstehen. Das Gesetz von Conway ist eine nach dem US-amerikanischen Informatiker Melvin Edward Conway benannte Beobachtung, dass die Strukturen von Systemen durch die Kommunikationsstrukturen der sie umsetzenden Organisationen vorbestimmt sind.

 

Es wurde von Conway 1968 folgendermaßen formuliert:

 

„Organisationen, die Systeme entwerfen, […] sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.“

 

Das Gesetz von Conway basiert auf der Überlegung, dass für die Definition der Schnittstellen zwischen getrennten Softwaremodulen zwischenmenschliche Kommunikation notwendig ist. Daher haben die Kommunikationsstrukturen der Organisationen einen großen Einfluss auf die Strukturen dieser Schnittstellen. Von daher muss die Organisation der IT dahingehend optimiert werden, um genau die Engpässe zu vermeiden, die den Wert beeinträchtigen. Wo wir wieder bei den Value Streams sind.

 

Schön, dass sich der Kreis wieder einmal schliesst.

 

Ein Vorreiter in der agilen Transformation dürfte uns als Musikliebhaber die Firma Spotify sein (wobei ich gerade meine alte Liebe zu den Drei ??? wieder entdeckt habe und diese momentan meiner elektronischen Musikleidenschaft vorziehe,….zumindest im Zug 😊)

 

Es geht um das Spotify Prinzip, welches sich zu meiner Freude auch viele Gaming-Design-Studios zu Eigen machen:

 

https://www.growly.io/spotify-engineering-model-with-squads-tribes-chapters-and-guilds/ 

 

 

 

Squads, Tribes, Chapters, and Guilds

 

 

In Anlehnung an das Conway-Gesetz sollte die Organisation der IT die Bedürfnisse der Produkt- und Anwendungsportfolios, die die IT erstellt, widerspiegeln.

 

Spotify verwendet ein Modell, dass die traditionelle Art und Weise der Strukturierung der IT innerhalb des Software Developments neu organisiert. Das allgemeine Prinzip von dem Modell der Squads, Tribes, Chapters, and Guilds besteht darin, dass sich ein Squad auf ein bestimmtes Arbeitsfeld oder eine Plattform konzentriert, z.B. den IPhone-Client für eine speziell zu betreuende Applikation.

 

Squads sind das Äquivalent von Teams im traditionellen IT-Modell. Eine Gruppe von Squads, die – wie alle UI-Teams einer Produktfamilie – den gleichen Fokus haben, bilden die Tribes. Diese tauschen Themen, Prozesse und Ideen aus.

 

Ein Chapter ist das, was die traditionelle IT den „Subject Matter Expert“ nennen würde:

 

Die Mitarbeiter, die über vertiefte Kenntnisse eines Tools verfügen oder spezialisierte Skills haben, können ihr Wissen darüber einbringen, wie man Abläufe rationalisieren oder neue Wege zum Erreichen von Zielen beschreiten kann.

 

Guilds können sich auf all die Themen konzentrieren, die zusätzlich mit den Zielen des Unternehmens zusammenhängen und ermöglichen somit den Austausch von Informationen über spezifische Themen, die ausserhalb der Squads, Tribes und Chpaters anfallen.

 

 

Wertschöpfung innerhalb einer vielseitigen Organisation

 

 

Der Schlüssel zu Spotifys Struktur besteht darin, dass sie die Entscheidungsfindung und Verantwortung, wo es möglich ist, auf die Squad Ebene verteilen. Die Teams erhalten allgemeine Vorgaben und müssen dann die Ziele der Organisation im Auge behalten und gleichzeitig Probleme lösen, die auf dem Weg zum Erreichen der Ziele auftauchen.

Die Flexibilität in der Organisation und die Unabhängigkeit der einzelnen Gruppen machen diese Struktur anpassungsfähig, um sich in der gleichen Weise zu verändern, wie das Unternehmen sich an die Marktfluktuation anzupassen hat.

 

Es erlaubt der IT-Organisation, in dieselbe Richtung wie das Business zu ziehen, anstatt das Ruder ein wenig hinter dem Boot baumeln zu lassen und es mit langsamen Reaktionszeiten und unzureichenden Bewegungen vom Kurs abzuziehen.

 

Wenn sich in der Zwischenphase eines Großprojekts das Geschäftsumfeld ändert und die Unternehmensführung die zu liefernde Software zu ändern hat, ist es im DevOps-Modell weitaus einfacher, die Änderung in Gang zu setzen und die Bedürfnisse des Unternehmens wirklich zu unterstützen als bei monolithischen Entwicklungs- und Einsatzmethoden.

 

Auch die Behebung kritischer Probleme ist einfacher. Nicht, dass das Debugging plötzlich einfacher wird, aber es gibt weniger Fehlerbehebungen, so dass ein kritisches Problem sofort Aufmerksamkeit erfährt, ohne dass andere Fehler ignoriert werden müssen.

 

In diesem Sinne wünsche ich Euch eine schöne Zeit beim Computer spielen, oder Hörbuch hören..

 

Bis nächste Woche, Euer Sven