Brücken bauen: Die Kluft zwischen Stakeholdern und Softwareentwicklern verstehen und überwinden

Die Softwareentwicklung, insbesondere in agilen Umgebungen, wird oft als harmonisches Ökosystem vorgestellt, in dem Stakeholder und Entwickler nahtlos zusammenarbeiten, um wertvolle Produkte zu schaffen. Aber jeder, der schon einmal mehr als eine Woche in einer solchen Umgebung verbracht hat, weiß, dass Missverständnisse zwischen diesen beiden Gruppen nicht nur üblich sind, sondern fast schon zur Tagesordnung gehören. Und warum? Weil Stakeholder oft durch eine „komplizierte“ Planungslandschaft navigieren, während Entwickler in der „komplexen“ Welt der Unvorhersehbarkeit von Software arbeiten.

Die „komplizierte“ Welt der Stakeholder

Lass uns zunächst den Begriff „kompliziert“ entmystifizieren, wenn er auf Stakeholder zutrifft. Stakeholder befassen sich mit Geschäftszielen, Finanzprognosen, Markttrends und Kundenanforderungen. Diese Elemente lassen sich oft zerlegen, analysieren und einplanen. Stell Dir das wie eine Schweizer Uhrwerk vor: kompliziert, ja, aber letztlich verständlich und vorhersehbar. Mit dem richtigen Fachwissen und etwas Zeit kannst Du komplizierte Systeme zerlegen, Ergebnisse vorhersagen und Maßnahmen entsprechend planen.

Stakeholder wenden diese „komplizierte“ Denkweise oft auf die Softwareentwicklung an und erwarten, dass die Zeitpläne starr sind und die Funktionen frühzeitig festgelegt werden. Sie sehen eine verpasste Frist nicht als Schluckauf, sondern als Versagen an – eine Panne in der Maschine, die mit den richtigen „Tweaks“ korrigierbar sein sollte.

Die „komplexe“ Welt der Softwareentwickler

Entwickler hingegen haben es nicht nur mit einem komplizierten System zu tun, sondern sind in ein komplexes System verwickelt. In einem komplexen System sind die Wechselwirkungen nicht linear und die Ergebnisse sind nicht leicht vorhersehbar. Mehrere bewegliche Teile wie Änderungen an der Codebasis, Aktualisierungen von Abhängigkeiten und neue Technologien machen die Entwicklungslandschaft unberechenbar.

So kann beispielsweise die Einführung einer neuen Funktion versehentlich eine bestehende Funktion zerstören, oder eine Aktualisierung einer einzelnen Bibliothek kann weitreichende Änderungen an der gesamten Codebasis erforderlich machen. Dies ist eher mit einer Wettervorhersage als mit einer Uhr vergleichbar – man kann abschätzen, aber nicht garantieren.

Wo die Missverständnisse auftauchen

Der Kern des Missverständnisses liegt hier: Die Stakeholder, die eine „komplizierte“ Sichtweise anwenden, erwarten Vorhersagbarkeit und Präzision, während die Entwickler in einem „komplexen“ Meer segeln, das von Natur aus unbeständig ist. Wenn Stakeholder fragen: „Warum ist diese Funktion nicht fertig? Sie sagten doch, es würde zwei Sprints dauern“, fragen sie nicht nur nach einem Update, sondern offenbaren ein grundlegendes Missverständnis über die Natur der Softwareentwicklung.

In einer agilen Umgebung, die darauf ausgelegt ist, anpassungsfähig und flexibel zu sein, ist die Anwendung eines „komplizierten“ Rahmens auf ein „komplexes“ System so, als würde man einen eckigen Pflock in ein rundes Loch stecken. Dies führt zu Reibungen, verfehlten Erwartungen und gegenseitiger Frustration.

Brücken bauen – Stein für Stein

Der Schlüssel zur Lösung dieser Dissonanz liegt in der Bildung und dem Einfühlungsvermögen. Die Stakeholder müssen die unvorhersehbaren Herausforderungen bei der Softwareentwicklung verstehen, und die Entwickler müssen den geschäftlichen Druck verstehen, dem die Stakeholder ausgesetzt sind. Beide Parteien sollten die Sprachen „kompliziert“ und „komplex“ fließend beherrschen, um eine bessere Kommunikation zu ermöglichen und realistische Erwartungen zu setzen.

Tools wie Burndown-Diagramme, Produkt-Roadmaps und Risikobewertungen können als Brücke zwischen diesen beiden Welten dienen, aber sie sind nur dann effektiv, wenn beide Parteien die Grenzen und Herausforderungen des jeweils anderen Bereichs erkennen.

Wenn Du also das nächste Mal in einem Meeting über eine verpasste Frist oder eine Funktionsänderung diskutierst, denke daran: Es geht nicht nur darum, was „kompliziert“ oder „komplex“ ist, sondern darum, zu verstehen, dass diese Begriffe verschiedene Dimensionen ein und derselben Realität darstellen. Die Harmonisierung dieser Perspektiven ist der erste Schritt auf dem Weg zu einem wirklich agilen, kollaborativen Umfeld.

Beispiel: Die katastrophale Produkteinführung

Szenario:

Stell Dir ein Fintech-Startup vor, das an einer ehrgeizigen neuen Zahlungsplattform arbeitet. Die Beteiligten stellen sich eine schnelle Markteroberung vor und haben Pressemitteilungen, Marketingkampagnen und Kundeneinführungsprogramme ausgearbeitet. Sie haben einen festen Termin für die Markteinführung festgelegt, diesen öffentlich bekannt gegeben und erwarten, dass die Software bis zu diesem Datum vollständig und fehlerfrei ist.

Die Planung der Interessengruppen:

Aus Sicht der Beteiligten ist das Projekt zwar „kompliziert“, aber durchaus zu bewältigen. Sie haben die Markttrends analysiert, den Wettbewerb berücksichtigt und sogar Ressourcen für den Kundensupport und -service bereitgestellt. Alles ist bereit – die Maschinerie ist an Ort und Stelle, und alle Zahnräder müssen sich synchron drehen. Die Stakeholder kommen zu einem Treffen zusammen, um ihre Anforderungen und Erwartungen zu besprechen. Sie formulieren eine detaillierte, umfassende Liste von Merkmalen und Funktionen, die sie für die Software für unerlässlich halten. Sie betonen, dass es vor allem auf Präzision ankommt; die Software muss genau das liefern, was sie skizziert haben.

Die Realität der Entwickler:

Die Entwickler haben jedoch mit der „komplexen“ Natur der Software zu kämpfen. API-Integrationen verursachen unerwartete Verzögerungen, neue Sicherheitslücken wurden entdeckt, und der Code für eine der wichtigsten Funktionen erweist sich als weniger zuverlässig als ursprünglich angenommen.

Dazu stellen sie fest, dass einige der Anforderungen widersprüchlich sind, während andere auf veralteten Technologien beruhen.

Das Missverständnis:

Die Stakeholder, die von einer „komplizierten“ Denkweise ausgehen, können nicht verstehen, warum das Entwicklungsteam die Fehler nicht einfach schnell beheben kann, um den engen Termin einzuhalten. Wenn doch jedes Teil verstanden wird, warum können sie es nicht einfach wie eine Maschine reparieren? Die Entwickler wiederum sind frustriert, weil die Stakeholder die inhärente Unvorhersehbarkeit und Komplexität ihrer Anforderungen nicht verstehen.

Die Stakeholder und die Entwickler haben Schwierigkeiten, die Sichtweise des jeweils anderen zu verstehen. Die Entwickler fühlen sich durch das Mikromanagement der Stakeholder eingeengt, während die Stakeholder frustriert sind über das, was sie als mangelnden Fortschritt empfinden.

Das Ergebnis:

Das Produkt wird unter Zeitdruck entwickelt, um den Termin einzuhalten. Es wird an allen Ecken und Enden gespart, und die technischen Schulden häufen sich an. Die Plattform wird pünktlich auf den Markt gebracht, ist aber mit Fehlern behaftet, von denen einige die Sicherheit der Transaktionen gefährden. Die Presse lobt die Plattform nicht, sondern kritisiert sie. Die Kunden verlieren das Vertrauen, und die Beteiligten haben alle Hände voll zu tun, um den Schaden zu begrenzen.

Gelernte Lektionen

Dieses Beispiel zeigt deutlich, was schief gehen kann, wenn die Beteiligten ein Softwareprojekt als „kompliziertes“ System betrachten, das sich vollständig kontrollieren und vorhersagen lässt. Es zeigt auch die Gefahr, der sich Entwickler aussetzen, wenn sie sich nicht gegen unrealistische Erwartungen wehren, die der „komplexen“ Natur der Softwareentwicklung nicht gerecht werden.

Die Missverständnisse zwischen Stakeholdern und Entwicklern sind nicht nur lästig, sondern können zu katastrophalen Ergebnissen führen, die das gesamte Projekt oder sogar das gesamte Unternehmen gefährden. Daher ist die Überbrückung der Kluft zwischen diesen beiden Welten nicht nur eine gute Praxis – sie ist für das Überleben und den Erfolg eines jeden agilen Projekts unerlässlich.