DevOps: Es geht um Feedback

Es ist kein Geheimnis: Immer mehr Firmen steigen auf eine Softwareentwicklung mit agilen Methoden und DevOps um. Auf Rückfrage hören wir oft, dass die klassischen Entwicklungsprozesse zu langsam sind. Was genau heisst das?

Klassischer Entwicklungsprozess – nach Fertigstellung eines Lasten- und Pflichtenheftes wird der Auftrag in der Entwicklungsabteilung realisiert. Nach Beendigung der Aufgabe wird die Software in Betrieb genommen.

Eines ist klar: Der Weg von einer Idee bis zu ihrer Realisierung kann in klassischen Organisationen schon mal mehrere Monate bis Jahre dauern. Dies ist in Hinblick auf die steigende Komplexität in den Domänen und Prozessen auch kein Wunder. Aber worauf bezieht sich dann das Gefühl, der Entwicklungsprozess sei zu langsam? Auf die Reaktion des Kunden auf die fertige Software? Unternehmen beobachten, dass der Kunde die Software nicht nutzen will oder mit ihr unzufrieden ist, weil sie an seinen Bedürfnissen vorbeigeht.

Das ist nicht verwunderlich: Die Wahrscheinlichkeit, dass ein Softwareprodukt nicht zu den Bedürfnissen passt, steigt mit der Dauer, die es braucht, um das Produkt auf den Markt zu bringen.

Es ist klar, da muss “etwas” optimiert werden. Bei Softwareprodukten kann doch nur die Softwareentwicklung das Bottleneck sein… Oder?

Vom Umgang mit Kunden-Feedback

In klassischen Organisationsstrukturen wird Kunden-Feedback über separate Abteilungen, Call Centers oder – bei Geschäftskunden – über Key Account Manager erfasst. In Bezug auf Wissen über die (Un-)Zufriedenheit der Kunden gibt es die gesamte Spannbreite von “nicht präsent/unbekannt” bis hin zu “umfangreich und durch Studien gefestigt”.

Das Problem ist nun, wie dieses Wissen um die Kundenbedürfnisse Eingang in die Software findet. Die klassische Ablauforganisation wirft zur Lösung die gesamte Maschinerie des Projektmanagements erneut an: Wie könnte eine (neue) Lösung aussehen? Wie schaut der (veränderte) Projektplan aus? Wann stehen die (schon verplanten) Ressourcen zur Verfügung, um die Kosten, Architektur und Projekte zu planen? Wer plant das Projekt, die Umsetzungsstrategie? Wer entwickelt wann die notwendige Softwareänderung?

Ideen und Umsetzungspläne müssen von allen möglichen Fachabteilungen abgesegnet und genehmigt werden. Das Selbstverständnis ist, dass nur ein gut durchdachtes Produkt/Projekt erfolgreich sein kann. Dieser Weg kostet natürlich Zeit.
Die Umsetzung muss mit dem Projektmanagement und der Softwareentwicklung abgesprochen werden. Zwischen einer Idee und dem Beginn (!) der Umsetzung liegen auf diese Weise mehrere Wochen.

Erkenntnisse

(#1) Die Ablauforganisation selbst ist der Grund dafür, dass Informationen über veränderte Kundenwünsche sehr spät in der Softwareentwicklung auftauchen.

(#2) Eine Firma muss erheblich schneller in der Lage sein, aus Kundenfeedback Änderungen an ihrer Software ableiten zu können.

Agile Softwareentwicklung

Mit der Einführung von agilen Methoden wie SCRUM und Kanban ändert sich nun zumindest das Problem der langen Planung. Die Prinzipien des Manifests für Agile Softwareentwicklung sieht dafür u.a. eine “enge Zusammenarbeit von Fachexperten und Entwicklern” vor. In der Praxis heißt das, dass das Anforderungsmanagement (jetzt unter dem Namen Product Owner, PO) und die Entwicklung in ein Team zusammengeführt werden.

Agile – PO und Team konzipieren und entwickeln iterativ neue Versionen der Software; Zwischenstände werden als Release ausgerollt und in Betrieb genommen.

Diese Umstellung führt dazu, dass dem Unternehmen nun ein Ansprechpartner zur Verfügung steht, mit dem Änderungen an der Software besprochen werden können. Langfristige Projektpläne werden nicht mehr generiert, stattdessen werden Aufgaben kurzfristig bestimmt und umgesetzt. Das Team bestimmt selbst die Priorität und damit die Reihenfolge, mit der Aufgaben umgesetzt werden.

Für Softwareentwickler entsteht eine neue Situation: Anstelle von detaillierten Weisungen werden nun nur noch Ziele (das “Was”) grob umrissen, die Umsetzung (das “Wie”) liegt in deren Verantwortung. Das bedeutet auch eine Verschiebung im Berufsbild: Diskussionen, Streitfähigkeit, Kompromissbereitschaft und Feedback werden essenziell. Der PO kommuniziert Anforderungen an das Team und erwartet direktes Feedback.

Durch die iterative Softwareentwicklung kann der Kunde nun regelmäßig die Software begutachten und über Anforderungsänderungen informieren. Die Bereitstellung von neuen Softwareversionen wird stark verkürzt.

Dennoch gibt es Verbesserungspotenzial. Das Manifesto definiert als erstes Prinzip: “Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.”  Doch wer genau ist „der Kunde“? Viele Firmen interpretieren ihre Produktabteilung als internen Kunden, die das Produkt verwaltet und dem Kunden (= Nutzer) zur Verfügung stellt. Diese Sichtweise ist meines Erachtens falsch, denn es geht beim Feedback eindeutig um das des (zahlenden) Nutzers der Software. Leider wird durch dieses Missverständnis das Einholen von wertvollem Feedback verzögert.

Trotz vieler wertvoller Impulse gab es retrospektiv auch Kritik am Manifesto, u. a.  dafür, dass es sich ausschließlich auf die Softwareentwicklung bezieht. Dieser Fokus führt in der Praxis dazu, dass der Betrieb der Software weiterhin losgelöst von der Entwicklung organisiert wird. Interessanterweise liegt das Problem erstmals in der Kette HINTER (“downstream”) der Softwareentwicklung. Was nützt eine schnell implementierte Software, wenn sie dem IT-Betrieb nach wie vor über den Zaun geworfen wird? Das Fehlen der Kommunikation sorgt dafür, dass der IT-Betrieb Zeitpläne für die Inbetriebnahme festlegen muss. Wo wir gerade bei (Nicht-)Kommunikation sind: Probleme, die ausschließlich im Betrieb auftreten, landen aufgrund dieser Grenzen wiederum gar nicht oder verzögert in der Entwicklung. Conway’s Law lässt grüßen.

Laufzeitprobleme, wie langsame Antworten oder Serverausfälle, machen den Kunden aber genauso unzufrieden wie schlecht programmierte Software.

Erkenntnisse

(#3) Mit der agilen Softwareentwicklung stehen für Entwickler erstmals Kommunikationsfähigkeiten im Fokus.

(#4) Abteilungsgrenzen behindern den für Softwareprojekte notwendigen Austausch von Feedback.

DevOps

Die Agile Softwareentwicklung löste Diskussionen in allen IT-Abteilungen aus. Eine der bekanntesten Weiterentwicklungen ist die DevOps-Bewegung . Das Akronym aus “Developer” und “Operations” (oder kurz “OPS”) deutet den Wunsch nach einer engen Zusammenarbeit zwischen Entwicklern und Betriebsspezialisten an.

Wurden jetzt nur die Zäune der Abteilungen eingerissen? Es ist mehr: Die DevOps-Bewegung führt dazu, dass die Arbeitsorganisation zwischen IT-Abteilungen zugunsten der Zusammenarbeit von Experten in den Hintergrund tritt. Da das Produkt nicht mehr in der Verantwortung einer einzelnen Abteilung liegt, wird dies an das Team übertragen. Damit sind alle Experten eines Teams gleichermaßen für die Qualität und Bereitstellung der Software verantwortlich.

DevOps – das Team erfasst die Erwartungen des Kunden/Nutzers, priorisiert diese und entwickelt fortlaufend Features, die sofort in Betrieb genommen werden; Feedback erfolgt durch den Kunden/Nutzer

Die DevOps-Bewegung hat es ermöglicht, den Fokus auf die gesamte Wertschöpfungskette einer Software und auf Feedbackschleifen zu legen. Dies bezeichnen Gene Kim, Kevin Behr und George Spafford als den zweiten Weg ihres Konzeptes “Die drei Wege” .

Durch die Zusammenführung von fachlichen und technischen Experten stehen nun allen Mitgliedern mehr und bessere Informationen zur Verfügung. Ops-Werkzeuge wie Monitoring und Alerting liefern Feedback über den Zustand des Produktes.

Meiner Meinung nach hat die DevOps-Bewegung die entscheidenden Impulse geliefert, um das agile Prinzip “Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.” in den korrekten Kontext zu setzen. Denn in letzter Konsequenz bedeutet dies, alle Experten, die zum Erfolg des Produktes beitragen, in das Produktteam zu integrieren. Dies schließt Kollegen aus Abteilungen wie Marketing, Finance, Customer Care, IT Ops etc. mit ein.

Ich möchte noch einen wichtigen Experten für das Produkt explizit erwähnen: den (Be)-Nutzer der Software. Damit erreicht das Kunden-Feedback unmittelbar alle am Produkt beteiligten Experten.

Erkenntnisse

(#5) Um ein Softwareprodukt marktorientiert erstellen zu können, ist es notwendig, alle beteiligten Experten-Rollen in einem Team zusammenzuführen, um einen ungehinderten Informationsaustausch zu ermöglichen.

(#6) Am schnellsten erhält das Team Feedback, wenn der Software-Nutzer selbst Teil des Teams ist.

Zusammenfassung

Ich hoffe, ich konnte mit meinen Ausführungen verdeutlichen, warum ich Feedback eine so hohe Wichtigkeit für Softwareprodukte beimesse. Viele Änderungen, die das Manifest der Agilen Softwareentwicklung und die DevOps-Bewegung in die Entwicklung von Software gebracht haben, haben den Informationsaustausch gefördert und damit die Reaktionsfähigkeit vieler Firmen erhöht. Für mich sind die folgenden Erkenntnisse besonders wichtig:

• Die klassische Ablauforganisation selbst ist der Grund dafür, dass Informationen über veränderte Kundenwünsche sehr spät in der Softwareentwicklung auftauchen.
• Um ein Softwareprodukt marktorientiert erstellen zu können, ist es notwendig, alle beteiligten Experten-Rollen in einem Team zusammenzuführen, um einen ungehinderten Informationsaustausch zu ermöglichen.
• Am schnellsten erhält das Team Feedback, wenn der Software-Nutzer selbst Teil des Teams ist.

Für jeden Kollegen aus den Entwicklungs- und Ops-Abteilungen stehen neue Herausforderungen an. Es reicht nicht, Experte für das eine und/oder andere technische Thema zu sein. Das Thema “Soft Skills” verdient einen erheblich stärkeren Fokus. Neben der Fähigkeit, sich Wissen anzueignen, wird es nun wichtig, mit Experten aus den verschiedensten Fachrichtungen zu kommunizieren, sich auszutauschen, zu diskutieren, Feedback zu geben und einzuholen.

Damit möchte ich diesen Blogbeitrag gerne schließen, nicht jedoch, ohne Sie/Dich/Euch um Feedback zu bitten.