Customer Centricity durch Agile Softwareentwicklung und DevOps-Kultur

Unser Umfeld verändert sich heute kontinuierlich. Ohne Business Agility – die Fähigkeit, sich rasch an veränderliche Kundenbedürfnisse anzupassen – werden Unternehmen langfristig nicht bestehen können. Wie aber erreicht man Customer Centricity, das Ausrichten seiner Wertschöpfungskette am Kunden? Wie lernt man die Bedürfnisse des Kunden zu lesen, platziert maßgeschneiderte Produkte erfolgreich am Markt und reagiert schnell auf Veränderungen desselben?

Die Antworten lauten: Agile Softwareentwicklung und DevOps-Kultur

Keiner weiß, welches Produkt der Kunde haben will, bevor es nicht am Markt überprüft wurde. Daher besteht die einzige Chance für sichere Produktentwicklung darin, iterativ Veränderungen am Produkt (Inkremente) zu releasen und am Markt zu lernen: Treffe ich die Bedürfnisse des Kunden? Entwickle ich mein Produkt in die richtige Richtung? Das soll möglichst schnell gehen – also viele kleine Experimente (Hypothesen), kurze Zyklen, schnelles Lernen. Mit nichts geht das schneller als mit Software. Daher müssen Unternehmen mehr zu Technologie-Unternehmen werden und Technologie nicht nur als Enabler verstehen.

Agile Softwareentwicklung ist genau auf dieses Szenario ausgelegt: Es soll ein Produkt entwickelt werden, von dem man vorher nicht weiß, wie es hinterher aussehen wird – und es soll schnell gehen. Zur Umsetzung agiler Softwareentwicklung im Unternehmen gibt es etliche Frameworks, bspw. Scrum (für einzelne Teams) oder SAFe (für viele Teams). Am wichtigsten ist es jedoch, die Ideen und Prinzipien des agilen Ansatzes verstanden zu haben: Vor mehr als 20 Jahren verfasst, sind das „Manifest für Agile Softwareentwicklung“ sowie die zwölf Prinzipien dahinter bis heute aktuell.

Hierbei werden die historisch in verschiedenen Abteilungen verantworteten Bereiche „Development“ (Change) und „Operations“ (Run) verzahnt und automatisiert. Erst mit dem Deployment und Release von Features lassen sich Hypothesen am Markt mit echten Kunden überprüfen, um daraus zu lernen. Somit ist DevOps die logische Erweiterung agiler Softwareentwicklung, um die „vorne“ aufgebaute Geschwindigkeit und Agilität „auf die Straße zu bringen“. Dies macht Customer Centricity, das Entwickeln neuer Features gemäß aktueller Kundenbedürfnisse, überhaupt erst möglich.

Die Kombination aus Agiler Softwareentwicklung und DevOps-Kultur ermöglicht also, das Produkt am Kunden auszurichten, durch schnelles Lernen am Markt: „Move fast“ und – dank Automatisierung und DevOps – „don’t break things“.

Leider erleben wir immer wieder, dass sich Unternehmen beim Thema DevOps selbst etwas vormachen, wie die folgenden Beispiele aus der Praxis zeigen:

Operations heißt jetzt DevOps, sonst ändert sich nichts.

Es hilft leider nicht, seine Operations-Abteilung künftig “DevOps” zu nennen. Wichtig ist es, das Silo-Denken von Development und Operations aufzubrechen. Es gilt eine gemeinsame Kultur zu schaffen, welche es ermöglicht, einen stabilen Betrieb der Software bei gleichzeitig hoher Change-Rate zu gewährleisten.

Das hier ist unser DevOps’ler.

In jedem Feature-Team gibt es ein Mitglied mit der Rolle DevOps? Klingt erstmal nicht verkehrt, wenn es darum geht, Development und Operations zusammenzubringen. Hier kommt es auf die Ausgestaltung an. Wird DevOps über Teamgrenzen hinaus als Kultur im Unternehmen gelebt? Sind die DevOps’ler in einem Chapter organisiert? Gibt es ein gemeinsames Verständnis davon, wofür technologisch und organisatorisch Aufwand investiert wird?

Wir haben so tolle DevOps-Tools eingekauft.

DevOps ist mehr als nur Tools. Neben dem Invest in Tools und der technisch eleganten Automatisierung des Deployments wird leider häufig versäumt, das DevOps-Mindset zu pflegen und die gemeinsame Kultur aufzubauen. Warum betreiben wir eigentlich diesen ganzen Aufwand? Welchen Mehrwert schaffen die DevOps-Tools für unser Business? Welches Ziel verfolgen wir mit DevOps? Wann sind wir mit unserer CI/CD-Pipeline zufrieden? Wer hierauf keine Antwort geben kann, optimiert vielleicht in die falsche Richtung.

You Build it, You Run it, aber…

Nach anfänglicher Begeisterung erstickt der DevOps-Kulturwandel daran, dass bestehende Verträge das Model gar nicht zulassen. Außerdem lässt es sich mit dem bestehenden Rollen & Rechte-System nicht abbilden. Der Weg zur gelebten DevOps Kultur kann steinig sein. Und manche Unternehmen wähnen die Steine auf ihrem Weg so groß, dass sie an dieser Stelle aufgeben.

Mit dem Kunden machen wir eigentlich nie was.

Dank DevOps gehen ständig neue Inkremente live, Feature-Requests werden abgehakt, tatsächliches Kundenfeedback zu den ausgelieferten Inhalten, aktiv oder durch KPI-Messungen, wird aber nur in Ausnahmefällen eingeholt? Klingt ganz nach klassischem Projektvorgehen unter dem Deckmantel agiler Buzzwords – auch hier geht es wieder um die Kultur: Schnelle Deployments sind nur dann sinnvoll, wenn man Kundenfeedback ernst nimmt. Wer DevOps ohne häufiges Überprüfen von Hypothesen am Markt umsetzt, verspielt gewaltiges Potenzial und gibt in Konsequenz ziemlich viel Geld für Nichts aus.

Das dürfen wir gar nicht.

“Wir würden gerne DevOps machen, aber die Regulatorik verbietet es uns”. Diese Ausrede hören wir immer wieder. Im Banking wird gerne die MaRisk („Mindestanforderung an das Risikomanagement“ der BaFin) als Grund genannt, am Silo-Denken “Development” und “Operations” festzuhalten. Dabei kann DevOps sehr wohl auch in diesem Kontext und unter Beachtung von regulatorischen Vorgaben funktionieren: State-of-the-art DevOps-Tools bieten Policy-as-Code Schnittstellen für ein Regulatorik-konformes automatisiertes Deployment – statt manueller Freigaben via Excel und E-Mail. Auch hier kommt es auf die Kultur der Zusammenarbeit der beteiligten Abteilungen an.

Fazit

Die Conclusio aus diesen Praxisbeispielen lautet: Viele Unternehmen versuchen DevOps durch Technik und Tooling zu lösen, während der Aufbau der notwendigen DevOps-Kultur versäumt wird. Kein Wunder, denn Tools einkaufen und ein paar Buzzwords übernehmen ist einfach, in die Köpfe der Mitarbeitenden zu kommen und einen kulturellen Wandel durchzuführen ist hingegen sehr schwer.

Bei Senacor haben wir bereits viele verschiedene Kundenumfelder gesehen. Kultur entsteht dort, wo gearbeitet wird. Denn Kultur sind Menschen und was sie tun – keine PowerPoint-Charts oder Einmal-Workshops. Zwei Bausteine, welche bei der Etablierung einer DevOps Kultur unterstützen können sind: Investition in Teams und Inspect & Adapt.

Es bedarf dem intrinsisch fest in der eigenen Mentalität verankerten Wunsch, Dinge abzuarbeiten und damit verantwortlich für den gewonnenen Mehrwert der Kunden zu sein. „Assume best intent“: Niemand kommt mit dem Ziel zur Arbeit, heute mal so richtig Unfug zu treiben. Rückendeckung hierfür gibt eines der zwölf Prinzipien des Manifests für Agile Softwareentwicklung: „Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.“ Es lohnt sich, regelmäßig und langfristig, in die Teams zu investieren und auf Entscheidungen der Teams zu hören. Wofür hat man sie sonst?

Ein crossfunktionales, agiles Entwicklungsteam stellt den Kunden in den Fokus seiner Arbeit. Mittels „Inspect & Adapt“ arbeitet das Team kontinuierlich daran, das Produkt für den Kunden zu optimieren. Gleichzeitig arbeitet das Team immer wieder daran, die eigene Arbeitsweise zu verbessern. Das passende Prinzip des Manifests für Agile Softwareentwicklung lautet: „In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.“ Weil wir in komplexen Umfeldern nicht wissen können, welcher Weg zum Optimum führt, hören wir nicht auf, viele kleine Experimente zu machen und regelmäßig im Team zu reflektieren, welchen Ansatz wir weiterverfolgen sollten.

Zusammenfassend lässt sich festhalten: Unternehmen sollten das Umfeld für motivierte Individuen schaffen, in dem Mitarbeitende täglich gemeinsam in crossfunktionalen Teams an Ende-zu-Ende-Lösungen arbeiten und Kundenmehrwert schaffen können. Das Manifest für agile Softwareentwicklung sowie die zwölf Prinzipien dahinter sollte den Mitarbeitenden auf allen Ebenen des Unternehmens gut bekannt sein und Einzug ins tägliche Miteinander finden. Darüber hinaus streben Teams Stabilität an und bringen eine zukunftstaugliche DevOps-Mentalität mit: Investieren in DevOps ist nicht nur investieren in Tools, denn DevOps wird tatsächlich als Zusammenwachsen aller beteiligten Disziplinen gelebt – Fachbereiche eingeschlossen. Dabei ist der Druck nach “gutem DevOps” enorm hoch, da DevOps-Mastery als Effizienztreiber bei den Software-getriebenen Fokusthemen der kommenden Jahre fungieren wird. Ein zuverlässiger Entwicklungspartner mit langjähriger Expertise in diesem Bereich, crossfunktionalen Teams und Ende-zu-Ende-Erfahrungen ist entsprechend ratsam.
Unternehmen müssen mehr Technologie-Unternehmen werden und Technologie nicht nur als Enabler verstehen. Wozu führt das? Teams verproben Hypothesen, bekommen Feedback, lernen schnell und liefern „genau das Richtige“ für die Kunden. Und nur das sorgt dafür, dass ihr Unternehmen weiterhin erfolgreich am Markt bestehen können wird.