Macht ihr DevOps richtig?

Einer der häufigsten Fehler bei einer DevOps-Transformation besteht darin, sie ausschließlich als technologische Aufgabe zu betrachten. Dieser enge Fokus kann dazu führen, dass Fähigkeiten entwickelt werden, die lediglich möglichst schnell Deployments produzieren sollen. Eine hohe Deployment-Frequenz bedeutet jedoch nicht automatisch, dass ihr die Strategie vorantreibt oder Mehrwert für Stakeholder schafft. Manchmal bewegt ihr euch dadurch nur schneller und effizienter in Richtung Nirgendwo.

Was braucht es für hochwertige Software?

Woher wissen wir, ob die Software, die wir releasen, tatsächlich Mehrwert für Kunden schafft? Das Modell „Desirability, Feasibility & Viability“ aus dem Design Thinking bietet eine sehr gute Grundlage, um zu beurteilen, ob ihr voraussichtlich Mehrwert schaffen werdet. Das Beste an diesem Modell: Es ist wirklich einfach.

Die drei typischen Fehlerquellen sind:

Der Service geht nicht auf die Schmerzpunkte der Nutzer ein oder ist zu umständlich in der Anwendung, was zu einer geringen Akzeptanz bei Endnutzern führt – fehlende Desirability
Der Service würde alle Anforderungen erfüllen, ist aber nicht umsetzbar, weil der Entwicklungsaufwand unrealistisch ist oder Prozessänderungen nicht umgesetzt werden können – fehlende Feasibility
Der Service erfüllt die Nutzerbedürfnisse und ist umsetzbar, würde der Organisation aber nicht genug geschäftlichen Mehrwert bringen – fehlende Viability

Einfach vorzupreschen ist nicht Lean genug

Im vergangenen Jahrzehnt hat sich die Lean-Produktentwicklung als unendlicher Zyklus aus „Build – Measure – Learn“ etabliert. Dieser Ansatz kann zu einer Kultur führen, in der Konzepte ungeprüft in die Entwicklung gegeben werden. Dadurch kann Entwicklungsaufwand für Arbeit entstehen, bei der die einzige validierte Erkenntnis lautet: Das Konzept hat nicht funktioniert. Im schlimmsten Fall fließt der Großteil des Entwicklungsaufwands in Verschwendung – das Gegenteil von Lean.

Die Softwareentwicklung ist häufig der Engpass, der bestimmt, wie schnell eine Organisation ihre Services weiterentwickeln kann. Fähigkeiten für häufige Releases zu entwickeln, ist wichtig. Genauso wichtig ist es jedoch, die Art und Weise weiterzuentwickeln, wie Services konzipiert und Anforderungen definiert werden. Die gute Nachricht: Ihr müsst nicht gleich ein Agile Framework für die gesamte Organisation einführen. Tatsächlich könnt ihr mit diesen drei Praktiken einen großen Unterschied machen.

Kontinuierliche Validierung zahlt sich aus

Erstens: Validiert vor der Entwicklung. Punkt. In der Regel reichen die Finger einer Hand, um die für die Validierung benötigten Arbeitstage zu zählen. Auf Feature-Ebene lassen sich damit potenziell Monate an Aufwand sparen, bei Konzepten sogar Jahre.

Ihr spart viel unnötigen Aufwand und Ärger, wenn ihr eine Kultur schafft, in der die Validierung von Servicekonzepten vor dem weiteren Vorgehen ein selbstverständlicher erster Schritt ist. Außerdem solltet ihr Features kontinuierlich validieren, bevor sie in Entwicklungssprints gelangen.

In ihrer einfachsten Form kann kontinuierliche Validierung Folgendes umfassen:

Viability: Sehen wichtige Stakeholder, einschließlich Partnern und Vertriebskanälen, einen Mehrwert in dem Feature, und ist die erforderliche Veränderung beherrschbar?
Desirability: Wie fällt das Urteil beim Nutzertest des Prototyps aus? Ist er ansprechend, funktional und für die Nutzer relevant? Anders gesagt: Ist die Reaktion „Wow“ oder „Hä“?
Feasibility: Bestehen die kritischen Punkte im Architekturplan den technischen Proof of Concept, und ist der Service mit vertretbarem Aufwand umsetzbar?

Wie gründlich ihr Features validieren solltet, erfordert ein ausgewogenes Vorgehen und etwas Übung. Wie gründlich müsst ihr zum Beispiel die verschiedenen Varianten eines User Flows bei kleineren Features validieren? Das wird etwas Experimentieren erfordern, denn die Validierungsprinzipien, die für andere funktionieren, sind nicht immer auf euch übertragbar.

Funktionsübergreifende Zusammenarbeit

Der einfachste Weg, Desirability, Viability und Feasibility sicherzustellen, besteht darin, Design, Business und Entwicklung zusammenarbeiten zu lassen. Am besten beginnt ihr das Design eines Features beispielsweise mit Product Owner, Designer und Entwickler vor einem Whiteboard oder in einem Remote-Workshop.

Jeder, der am Service arbeitet, sollte verstehen, wie die eigene Arbeit mit der Arbeit anderer zusammenhängt. Methoden und Tools, die die Zusammenarbeit effizient machen – etwa ein Design Sprint –, sollten bei Bedarf eingesetzt werden. Zusammenarbeit reduziert nicht nur Verschwendung, sondern verbessert auch die Qualität eurer Ideen, weil ihr sofort Feedback zu Desirability, Viability und Feasibility erhaltet.

Wenn ihr daran denkt, Design, Business und Entwicklung in jede Phase eures Projekts einzubeziehen, habt ihr die besten Erfolgschancen. Auch die ersten Schritte zur Verbesserung eurer Prozesse und Arbeitsweise sind nicht schwer (mehr dazu in unserem Digital Product Building Toolkit).

IT muss weiter nach links rücken

Shift Left bezeichnet die Praxis, Probleme zu vermeiden und die Qualität zu verbessern, indem mehr Aufgaben an den Anfang der Wertschöpfungskette verlagert werden. Im DevOps-Kontext bedeutete das traditionell, sich auf die Qualität von Akzeptanztests zu konzentrieren oder Continuous Deployment zu ermöglichen. Beides ist sehr wichtig, doch IT muss noch weiter nach links rücken.

Es ist entscheidend, dass Design, Business und Entwickler entlang der gesamten Wertschöpfungskette und über den Lebenszyklus einer Anforderung hinweg effektiv zusammenarbeiten. Es reicht nicht aus, wenn sich die IT nur auf das „Management von Anforderungen“ konzentriert. Sie muss sich an der konzeptionellen Erkundung und am Design von Features beteiligen.

Wenn ihr damit beginnt, Konzepte, Design und Entwicklung kontinuierlich zu validieren und die bereichsübergreifende Zusammenarbeit zu verbessern, seid ihr auf dem besten Weg, mehr Mehrwert zu schaffen und zugleich Verschwendung sowie Reibungsverluste zu reduzieren. Außerdem könnt ihr eure Design- und Entwicklungsarbeit besser neu ausrichten oder sogar die gesamte Roadmap anpassen.