Eine DevOps-Transformation ist keine Magie. Jede Firma kann sie schaffen. Den Unterschied macht, wen du in das erste Team setzt — denn dieses Team muss den Beweis liefern, dass DevOps in deinem Kontext tatsächlich funktioniert.
Klein anfangen, dann das Team auswählen#
Bevor du Leute auswählst, wähle das richtige Projekt. Starte mit etwas Kleinem bis Mittelgrossem. Entscheidungen haben weniger Tragweite, weniger Stakeholder müssen abgestimmt werden, und das Team kann schnell genug liefern, um Momentum aufzubauen. Mit einem überschaubaren Scope auf dem Tisch kannst du gezielt entscheiden, wer dazustösst — statt einfach diejenigen zu nehmen, die gerade verfügbar sind.
Generalisten vor Spezialisten#
Die goldene Regel beim Staffing eines DevOps-Teams: Generalisten vor Spezialisten. Ein Team aus T-shaped Leuten, die Build, Test, Deploy, Monitoring und Incident Response übernehmen können, schlägt ein Team aus tiefen Spezialisten, die ihre Arbeit über die Wand werfen. DevOps geht es darum, Loops zu schliessen — und Loops schliessen sich schneller, wenn dieselben Leute den nächsten Faden aufnehmen können.
Das heisst nicht, dass du Spezialisten verbannst. Es heisst, der Schwerpunkt liegt bei Generalisten, und Spezialisten werden für konkrete Probleme dazugeholt. Besteht dein erstes Team mehrheitlich aus Silo-Experten, ziehen die Silos mit ins neue Arbeitsmodell ein.
Innovatoren, Early Adopters und respektierte Stimmen#
Das Team braucht drei Sorten von Menschen. Innovatoren, die wirklich einen neuen Ansatz ausprobieren wollen. Early Adopters, die schnell folgen und andere mitnehmen. Und mindestens eine oder zwei Personen, die im Unternehmen Gewicht haben — Engineers oder Leader, auf die andere hören. Die ersten beiden geben dir Energie. Die dritte gibt dir Glaubwürdigkeit. Ohne Glaubwürdigkeit wird jedes Resultat als Spezialfall abgetan.
Vollständig freistellen#
Das neue Team muss von jeder anderen Arbeit freigestellt werden. Keine Teilzeit-DevOps-Experimente. Kein “die helfen nebenbei mit”. Sind die Leute auf mehrere Verpflichtungen verteilt, bekommt die Transformation die Reststunden — und Reststunden reichen nicht.
Wo möglich, bring sie an einen Ort. Co-Location ist im Jahr 2020 und danach nicht zwingend, aber Kommunikationsreibung zu reduzieren ist in der Anfangsphase wichtiger als fast irgendwo sonst. Die Leute erfinden eine neue Arbeitsweise — sie müssen sich umdrehen und einander Fragen stellen können.
Von alten Regeln befreien#
Sei bereit, das Team von Konzernregeln und Guidelines zu befreien, wo immer möglich. Change Requests, ticketgetriebene Handoffs, verpflichtende Architecture Review Boards — diese Prozesse wurden für das alte Arbeitsmodell gebaut. Wenn du das neue Team in sie hineinzwingst, testest du, ob der alte Prozess DevOps überleben kann. Das ist das falsche Experiment. Das richtige Experiment ist, ob das Team mit einer neuen Arbeitsweise schneller und sicherer Wert liefern kann. Governance führst du später wieder ein — neu gebaut um das, was das Team gelernt hat.
Kritische Masse#
Sobald das erste Team die gewünschten Verbesserungen am ersten Produkt geliefert hat, nimmst du das nächste Produkt und beginnst von vorn. Mit jedem weiteren Team erreichst du kritische Masse. Allianzen entstehen, Erfolgsgeschichten verbreiten sich, weitere Transformationen werden einfacher — weil du jetzt Beweise statt Versprechen hast.
Key Takeaways#
- Erst das Projekt wählen, dann das Team. Kleiner bis mittlerer Scope hält das Experiment ehrlich und die Feedback-Schleife eng.
- Generalisten vor Spezialisten. Loops schliessen braucht Leute, die den nächsten Teil der Arbeit übernehmen, nicht weiterreichen.
- Innovatoren, Early Adopters und respektierte Stimmen mischen. Energie plus Glaubwürdigkeit lässt Resultate stehen.
- Team von allem anderen freistellen. Teilzeit-DevOps funktioniert nicht. Voller Fokus oder kein Fokus.
- Von alten Regeln befreien. Teste die neue Arbeitsweise, nicht ob der alte Prozess sie überlebt.
- Wiederholen bis zur kritischen Masse. Jedes transformierte Produkt macht das nächste leichter.