Die Technik war kein Problem
Diese Neuorganisation ging erwartungsgemäß nicht ohne anfängliche Diskussionen ab. Und die waren - genauso verständlich - weniger technischer Natur. Über Entwicklungs- und Automatisierungs-Tools finden sich schließlich genügend Informationen.
"Was uns aber niemand beantworten konnte, waren die Auswirkungen eines DevOps-Ansatzes auf die organisatorische Struktur ", beschreibt Sengpiehl das eigentliche Problem. Und so begann das Unternehmen mit der kompletten Neustrukturierung von Teams, deren Mitglieder nach Service-Clustern zusammengestellt wurden.
Mittlerweile arbeitet die Haufe Gruppe seit knapp 17 Monaten zu einem Gutteil im DevOps-Modus. Derzeit entwickelt und betreibt sie 40 Prozent der Web-Applikationen nach diesem Modell. Weitere 30 Prozent befinden sich in der Übergangsphase.
Es gibt aber auch Ausnahmen, wie Sengpiehl klarstellt: "Lexware-Produkte wie Financial Office oder Warenwirtschaft sind Desktop-Anwendungen. Continuous Delivery ist in diesem Legacy-Bereich nicht so einfach möglich, denn hier ist der Installationsprozess bei den verschiedenen Kunden mit ihren verschiedenen Plattformen wesentlich aufwendiger. Außerdem haben wir es da mit Anwendern zu tun, die es noch nicht gewohnt sind oder gar nicht wollen, dass sich ihre Software ständig automatisch updatet."
Vorzeigeprojekt Service-Plattform
Die interne Haufe-Group-Service-Plattform wurde hingegen von einem traditionellen auf das DevOps-Vorgehen umgestellt. Sie erbringt Services wie Lizenzzuteilungen und Identity-Management für die Kunden und ist an SAP-Anwendungen und Shop-Systeme angebunden. "Die Funktionalitäten unterliegen einem ständigen Wandel, weil sie interne Prozessoptimierungen und -erweiterungen unterstützen", beschreibt Sengpiehl die Hintergründe der Applikation.
Alle diese Prozesse sind kundengerichtet sowie Mission und Business Critical. Mehr noch: "Wenn hier irgendetwas nicht funktionieren würde, erhielten wir sofort Rückmeldungen über den Net Promoter Score", führt Sengpiehl aus."
Der Net Promoter Score oder NPS ist eine Kennzahl, mit der sich die Kundenzufriedenheit ermitteln lässt. Entwickelt wurde die Methode von Fred Reichheld, Fellow bei der Unternehmensberatung Bain & Company. Basis ist die Frage: "Wie wahrscheinlich ist es, dass Sie Unternehmen/Marke X einem Freund oder Kollegen weiterempfehlen werden?" Die am Ende resultierende Messgröße wird aus der Summe der Promotoren abzüglich der Kritiker ("Detraktoren") errechnet.
Trial & Error war erfolgreich
Das für die Haufe-Group-Service-Plattform verantwortliche Team ist im rumänischen Temeswar beheimatet. Es besteht aus Architekten, Entwicklern, Testdesignern, Testern und Operations-Mitarbeitern und existiert mittlerweile seit etwas mehr als einem Jahr.
Die Umsetzung der Plattform nach dem DevOps-Ansatz nahm nur wenige Wochen in Anspruch. "Im traditionellen Verfahren hätte das gut einige Monate länger dauern können", ist sich Sengpiehl sicher. "Unser Vorgehen war eigentlich eher hemdsärmelig." Man habe die Skills definiert, einen Teamleiter ernannt, die Prozesse aufgesetzt und dann alle Verantwortlichkeiten in die DevOps-Einheit übertragen.
Eingeflossen sind auch die Erfahrungen, die man in den vergangenen Jahren mit den agilen Entwicklungen bei der Online-Plattform "Lexoffice" gesammelt hatte. "Wer Agile Development noch nicht kann, sollte seine Finger von DevOps lassen", warnt Sengpiehl.
Nicht nur remote und virtuell
"Bei Lexoffice haben wir beispielsweise gelernt, dass die Sprint-Planung an einem virtuellen technischen Board nicht ausreichend gut funktioniert", erinnert sich der IT-Chef: "Die Teammitglieder müssen sich auch in der realen Welt treffen." Und das sei bei DevOps nicht anders: "Man kann nicht alles remote und virtuell machen."
Eine weitere Lektion, die man gelernt habe, lautet: "Mikro-Management ist der Tod jedes DevOps-Ansatzes." Selbsternannte Feuerwehrmänner und Manager in Detailfragen hätten keine Zukunft: "Wer marktfähig bleiben will, muss die Organisation ändern und in Sachen Team-Management komplett umdenken." Der Teamleiter sollte in die Aktivitäten und Sprints "hineinhören", aber sie nicht ständig kontrollieren. Er sollte als Ansprechpartner und Vermittler bei Problemen und Eskalationen dienen, denn die kämen hin und wieder vor, "wenn der Produkt-Manager oder Architekt beispielsweise feststellt, dass eine Funktion anders geplant war".
Dokumentierte Lessons Learned
Alle Lessons Learned hat das Team um Sengpiehl dokumentiert, "um nicht jedes Mal das Rad neu erfinden zu müssen". Diese Erfahrungen will der IT- und Entwicklungschef nun in einem DevOps-Manifest festhalten - mit sämtlichen Dos and Don`ts.
Darin wird auch Sengpiehls Credo zu finden sein, das da lautet: "Wenn man DevOps richtig machen will, kann man es nicht nur über die Prozesse tun, man muss es auch über die Organisation abbilden." Das rät Bernd Sengpiehl allen DevOps-Interessierten:
Konsolidieren Sie die Tool-Landschaft zu wenigen, durchgängigen Werkzeugketten mit hohem Automatisierungsgrad.
Schneiden Sie die interdisziplinären DevOps-Teams entsprechend den bestehenden Geschäftsprozessen und/oder Marktsegmenten zu.
Achten Sie bei der Auswahl der Führungskräfte (Teamleiter) stärker auf Führungserfahrung als auf Fach-Know-how.
Kontinuität bezüglich des Standorts: Wenn Teammitglieder an verschiedenen Lokationen arbeiten, sind sie praktisch ausschließlich auf digitale Kommunikation angewiesen. Das kann zu Problemen führen.
Sie brauchen weiterhin Spezialisten. Auch wenn in DevOps-Teams interdisziplinär gearbeitet wird, heißt das nicht, dass jeder alles gleich gut kann.
Wer am Thema DevOps interessiert ist oder selbst Projekte plant, dem gibt Sengpiehl gerne Auskunft.