Der letze Beitrag zur agilen Systemadministration enthielt einen Vorschlag wie man die agilen Methoden auf das Tagesgeschäft eines Administrators übertragen kann.
Nun versuche ich einen Überblick zu geben wie Systemadministratoren in agilen Projekten involviert werden können. Dabei sind offensichtlich drei Aspekte relevant:
- Zusammenarbeit mit Menschen
- Iteratives Vorgehen
- Beraten und Coachen
Diese Punkte sind in meiner Sysadmin-Zeit immer wieder aufgetreten und haben sich in Projekten erfolgreich bewährt.
Punkt 1: Zusammenarbeit mit Menschen.
In (agilen) Projekten ist es häufig erforderlich, dass die Administratoren mit ihrem Wissen das Projektteam unterstützen. Leider gibt es Vertreter dieser Zunft, die ständig versuchen das Projektteam zu manipulieren und ihre eigenen Regeln getreu dem Motto: “Ich bin root, ich darf das” durchzusetzen. Dabei bedienen sie sich häufig starrer Regeln und Policies (ITIL sei Dank). Hier zeigt sich der grundsätzliche Konflikt zwischen Projektteam und Serviceteam. Die einen wollen ihr Projekt erfolgreich zu Ende bringen (da stören diese Richtlinien eben). Und die Anderen müssen das operative Tagesgeschäft samt Rechteverwaltung sicherstellen.
Daher stammt vermutlich auch das alte Klischeedenken, dass der Administrator der natürliche Feind des Entwicklers ist. Vielmehr muss hier auch dem Admin daran gelegen sein, das Projekt erfolgreich zu beenden und nicht zu behindern.
Punkt 2: Iteratives vorgehen.
So wie das Projektteam arbeitet, muss auch der Administrator iterativ arbeiten. Das bedeutet, dass die Systeme zuerst grundsätzlich installiert werden und in Folgeschritten die User angelegt und berechtigt werden. Eine komplette Berechtigungsliste kann man hier noch nicht erwarten. Auch kann es sein, dass Systeme während einer langen Projektlaufzeit aktualisiert werden müssen, weil das Projektteam die neuen Funktionalitäten dringend benötigt, oder das Netzwerk aktualisiert werden muss, da die Bandbreite nicht ausreicht.
Punkt 3: Beraten und Coachen.
Hier geht es darum den Entwicklern die Richtlinien und Policies zu erläutern, die für den operativen Betrieb gelten; sie von der Einhaltung der Richtlinien zu überzeugen. Der Kampf ist bereits verloren, wenn der Administrator versucht die Regeln einfach durchzusetzen. Insgesamt gilt es aber auch die bestehenden Richtlinien selbst immer wieder zu hinterfragen und zu prüfen, ob sie tatsächlich dienlich oder hinderlich sind.
Ebenso müssen dem Projektteam die Zusammenhänge der IT-Infrastruktur erläutert werden. Dies ist insbesondere dann interessant, wenn die IT-Architektur ausschließlich von dem Team festgelegt wird.
Fazit:
Gerade wenn in Projekten agil gearbeitet wird, ist es erforderlich die agilen Werte für die Zusammenarbeit auch zu leben. Das gilt insbesondere für den Urkonflikt zwischen Systemadministratoren und Programmierern. Allerdings sollte nicht nur der schnelle Projekterfolg im Auge gehalten werden, sondern auch die Gesamtheit der Maßnahmen, durch die ein stabiler und störungsfreier IT-Betrieb möglich wird.
Ich mache leider sehr häufig schlechte Erfahrungen bei der “Zusammenarbeit” der Entwicklungsteams und der Admins.
Sehr häufig fokussieren sich die Admins auf lokale (ihre) Optimierung und verstecken sich hinter Abläufen und Anforderungen. Diese werden im Vorfeld meist nicht kommuniziert – weil sie im Detail vielen Administratoren auch nicht bekannt sind. Zudem kommen – gerade bei Web-Projekten in größeren Unternehmen – komplexe Infrastrukturthemen (Netzwerke mit Loadbalancer, Timeouts und irgendwelchen Regeln). Diese werden noch nicht einmal von den meisten Administratoren verstanden, die Entwicklung soll dafür aber die passende Software schreiben. Ohne technische Requirements natürlich – und ohne Möglichkeiten Einblick in die bestehenden Konfigurationen zu nehmen.
Wenn dann alles nicht mehr hilft, dann wir darauf verwiesen, dass man für die KPIs nicht mehr gerade stehen kann und eh keine Zeit für Diskussionen hat, um gemeinsam Lösungen zu finden. Verständnis für die agilen Werte vermisse ich hierbei häufig.
Regelmäßig erlebe ich auch Situationen, in denen interne Dienstleister (z.B. Betrieb) mir erklären, was der Kunde braucht und warum keine neue (Web) Technologie eingesetzt werden müssen (“Stateless geht doch auch”). Die Vorstellungen sind weit weg von der Realität, die angebotenen Leistungen unterdurchschnittlich – aber bestens für eine lokale Optimierung geeignet. “Damit haben wir Erfahrungen, das hat schon immer so funktioniert …”.
Wahrscheinlich hilft nur, Administratoren in die Softwareentwicklungsteams zu integrieren, wie es in kleineren Unternehmen oft der Fall ist. Nur so kann Verständnis aufgebaut werden und nur so können Lösungen gemeinsam erarbeitet werden. Alternativ sollte darüber nachgedacht werden, Entwickler zeitweise in Admin-Teams mitarbeiten zu lassen.
Ziel ist es, die erstaunlich große Kommunikationsbarriere zu überbrücken und dem Kunden eine gut Lösung für seine Probleme anbieten zu können. Nur so kann das wirtschaftliche Überleben des Unternehmens langfristig gesichert werden.
Tatsächlich stehen die schnelle Produktentwicklung, und damit alle Maßnahmen zur Zielerreichung, nicht im Gegensatz aber zumindest im Spannungsverhältnis mit dem Produktbetrieb. Insbesondere wenn diejenigen, die es im Betrieb betreuen nicht an der technischen Lösung mitgearbeitet haben.
So sehe ich auch als einzige Lösung, die Administratoren mit in das Entwicklungsteam zu integrieren. Es geht also schlicht um die Zusammenarbeit von unterschiedlichen Teams/Abteilungen. Für mich ganz klar eine Aufgabe des Managements solche Zusammenarbeit zu fördern und die Struktur zu schaffen, dass Administratoren an Entwicklungsprojekten beteiligen werden, um dieses Spannungsfeld aufzulösen.