Seit Jahren hat die DevOps-Kultur wird zum Standard und immer mehr Unternehmen wenden sich diesem agilen Modell zu. Ist diese Methode für IT-Dienstleistungsunternehmen geeignet, die historisch gesehen Outsourcing betreiben?
Sobald wir diese Kultur übernommen haben, stellen wir fest, dass es einige Abweichungen gibt, insbesondere in Bezug auf Fristen und Kosten. Was auf dem Papier offensichtlich erscheint, funktioniert nicht unbedingt wie beschrieben: Oft wird es im Zusammenhang mit einem Produkt verwendet, aber es ist manchmal schwierig, seine Teams und seine Organisation dazu zu bringen, sich zu beteiligen, wenn man eine Dienstleistung erbringt oder wenn nicht alle Werkzeuge und Kompetenzen bereits im Unternehmen vorhanden sind. Mehr noch, dieser Paradigmenwechsel kann teuer werden, um ein möglichst effizientes Ökosystem aufzubauen.
Die starke Beschleunigung der öffentlichen Cloud hat diese Kultur noch wichtiger gemacht: Eine bessere "time to market", die Vorteile von CI/CD und die "on demand"-Infra sind heute unerlässlich, um wettbewerbsfähig zu bleiben, schnell zu experimentieren und schneller zu liefern.
Allerdings stellen wir heute fest, dass es einen Kulturschock zwischen ITIL und AGILE gibt. Beide haben ihre Vor- und Nachteile: Während ITIL die Kontrolle von Veränderungen und die Beherrschung von Terminen propagiert, betont AGILE die iterative Vorgehensweise, das Experimentieren und die Geschwindigkeit der Implementierung.
Bei der Anwendung eines agilen Ansatzes im Rahmen des IT-Outsourcing haben wir Risiken und Verschiebungen auf der Planungsebene festgestellt. Das Argument: "Verstehen Sie, lieber Kunde, wir können das Projekt nicht rechtzeitig fertigstellen, weil die User Story in den nächsten Sprint gerutscht ist", kommt nur schwer an...
Das historische Metier von Cloud Temple ist das Hosting in der privaten Cloud und das Outsourcing nach den ITIL-Standards. Seitdem sind Kompetenzen rund um die Public Cloud und die Softwareentwicklung hinzugekommen.
Natürlich mussten wir unsere Organisation umgestalten, um das beste Gleichgewicht zu finden. Da unsere technischen Experten für die öffentliche Cloud DevOps sind, sind sie "von Natur aus" agil.
Auf dem Weg zu einer hybriden Organisation
Um diese Unternehmenstransformation durchzuführen und so DevOps mit der Einhaltung der Vorgaben unserer Kunden zu kombinieren, haben wir wie viele andere auf das bekannte Spotify-Modell geschaut. Nachdem wir deren Organisation anhand zahlreicher Artikel analysiert hatten, stellten wir fest, dass die große Mehrheit der Elemente in unserem Kontext nutzbar war, jedoch nicht ohne tiefgreifende Anpassungen.
Wir wollten auch agil bleiben, aber die Vielzahl an Prozessen, Meetings und Tools begrenzen. Daher wandten wir uns an den Modern Agile die darin besteht, das "klassische" Agile zu bereinigen, um sich auf die Werte dieser Methodik zu konzentrieren.
Unsere Organisation ist daher um Squads, Gilden und ein einziges Tool zur Projektsteuerung herum aufgebaut: Azure Boards.
Die Cloud Temple Squads
Als echte Kompetenzzentren haben wir uns dafür entschieden, alle unsere Experten in autonomen und starken Teams zusammenzufassen, die sich im technischen Bereich selbst verwalten. So hat jeder Public Cloud Provider (Azure, AWS, GCP, Alibaba) einen gewidmete Squad deren Mitglieder gemeinsam Fortschritte machen, sich gegenseitig unterstützen, herausfordern, überprüfen und ihr Wissen und ihre Erfahrungen im Laufe der Projekte austauschen.
Die Rollen innerhalb der Squads sind klar definiert: Architekten, builders, runners. Aber die Nähe der Menschen zueinander und ihr Zusammenschluss ermöglichen den täglichen Austausch von Informationen und Wissen, sodass alle Fortschritte machen können. So haben wir einen echten Teamgeist und Solidarität mit einem gemeinsamen Ziel geschaffen : weiterkommen jeden Tag, um die Qualität unserer Dienstleistungen ständig zu verbessern.
Natürlich ist die Verteilung der Aktivitäten klar und wir wissen, wie viel wir jeden Monat produzieren können. Dennoch ermöglicht diese Nähe, dass Runner und Builder zu den Architekturen beitragen können. Ebenso wissen unsere Architekten und Builder, dass sie pro Eskalation runnen werden. Die Abbau von Schranken und gegenseitige Unterstützung sind zu Grundwerten unserer Kultur geworden.
Die Gilden, die Konformitätsgarantie
Jeder Experte ist also Teil einer Squad, die ihn 80% seiner Zeit in Anspruch nimmt, um unsere Kunden bei unseren verschiedenen Leistungen zu begleiten. Parallel dazu ist jeder auch Teil von ein bis zwei Gilden, die ihn 20% seiner Zeit in Anspruch nehmen.
So mischen sich die Experten der verschiedenen Squads (Azure, AWS, etc.), um zur Standardisierung, Dokumentation und Verbesserung der strukturierenden technischen Elemente beizutragen, die allen unseren Kunden dienen werden (Monitoring, Backup, Template, Container, Industrialisierung, etc.). Diese Zeit wird von jedem völlig autonom in Abhängigkeit von den Kundenprojekten verwaltet; es schien uns unerlässlich, die Qualität der Standards bei den strukturierendsten Elementen zu gewährleisten und einen kontinuierlichen Verbesserungsprozess zu fördern.
Jedes Gildenthema wird für jeden unserer Kunden einheitlich implementiert. Dadurch wird die Build-Phase vereinfacht und optimiert, da sie von den von den Gilden erstellten Standards profitiert. Auch der Run profitiert von diesen Best Practices, da die Implementierungen von einem Projekt zum anderen einheitlich sind.
Wir arbeiten in viermonatigen Iterationen mit einem Kick-off, bei dem die Ziele jeder Gilde und der Wert, den sie für das Unternehmen bringen wird, festgelegt werden. Es wird ein Backlog mit Prioritäten erstellt.
Im Verlauf der Sprintplanungen der einzelnen Squads weiß jeder, dass er User Stories in Höhe von 20% seiner Kapazität aufnehmen muss.
Ein Synchronisationspunkt findet jeden Monat statt, um den Fortschritt zu überprüfen. Am Ende einer Iteration findet ein Review vor den Teams statt, um die geleistete Arbeit zu teilen, die für alle Projekte verwendet wird. Das Wissen wird also bei der Präsentation zusätzlich zu der erstellten technischen Dokumentation verbreitet.
Natürlich haben die Einsätze unserer Kunden weiterhin Vorrang, und es kann sein, dass der Gildenbeitrag bei einem Erdrutsch ausfällt. Er wird dann in einer ruhigeren Phase nachgeholt. Das Ziel ist nicht, die Experten in der Gilde unter Druck zu setzen (sie haben genug Druck bei Kundenprojekten).
Welche Rolle spielen unsere Projektmanager?
Wir haben bei Cloud Temple auch einen unternehmensübergreifenden Stab von Projektmanagern. Sie sind die Garanten für die Zeitpläne und die Steuerung unserer Projekte.
Ebenso wie die technischen Squads sind sie in ihrer Organisation autonom, aber die Nähe stimuliert eine Vereinheitlichung der Werkzeuge, Methoden und Medien, die für die verschiedenen Projekte verwendet werden.
Wenn also ein Projektmanager einem Projekt zugewiesen wird, stimmt er sich mit dem Leiter des technischen Teams auf die verfügbaren Ressourcen ab und plant die Arbeit gemäß den Meilensteinen, für die er gegenüber dem Kunden bürgt. So gewährleisten wir eine Planung im Vorfeld der Phase, wobei die Sprints entsprechend den Herausforderungen des Kunden gefüllt werden und weniger nach dem Zufallsprinzip wie beim klassischen Scrum.
Außer wenn der Kunde Stichtage in seiner Planung hat, bleiben die technischen Experten natürlich frei in der Organisation ihrer Arbeit, solange sie sich an den Sprintumfang und die Projektplanung halten. Sie behalten diese agile Autonomie, aber mit einem gewissen Rahmen, der die Einhaltung der Kundenherausforderungen garantiert. Wir haben also keinen Scrum Master in unseren Teams, da die Projektmanager die Sprints je nach Kapazität füllen und so die Durchführbarkeit der Operationen sicherstellen.
Azure Boards ist unser Werkzeug zur Steuerung von Projekten. Hier werden die User Stories ab dem Zeitpunkt der Projektunterzeichnung geplant, die wichtigsten Termine von Anfang an markiert und wir haben so für jede Ressource einen Überblick über mehrere Wochen. Mithilfe von Teambeiträgen und einigen Dashboards fassen wir im Tool unseren Activity Report (ARC) zusammen und haben einen klaren Überblick über unsere Projektionen und unsere Kapazität. Dies ermöglicht es, die Anzahl der Tools zu begrenzen und ein gemeinsames Referenzsystem zu haben.
Eine Formel, die funktioniert!
Also ja, wir haben das agile Manifest und das Spotify-Modell "verdreht", um nur das zu behalten, was wir wollten. Wir haben uns dafür entschieden, uns wieder auf die Werte zu konzentrieren, in denen sich unsere Mitarbeiter und Kunden wiederfinden, anstatt ein vorgefertigtes Schema zu kopieren und einzufügen. Dadurch konnten wir unser Know-how weiterentwickeln und eine effiziente Organisation aufbauen.
Wir sind heute davon überzeugt, dass das Modell, das wir für unser Unternehmen entwickelt haben, unser Geschäft mit der Kultur unserer Mitarbeiter in Einklang bringt und gleichzeitig einen Mehrwert für unsere Kunden schafft. Unsere zahlreichen Public-Cloud-Projekte ermöglichen es uns jeden Tag, diese Organisation zu erproben und unsere Kunden bei ihren Transformationsprojekten zu unterstützen.
