Wie wir Softwareentwicklung besser machen – Mehr Wirkung statt mehr Output
1. Wenn guter Output nicht reicht
In vielen Teams wirkt Softwareentwicklung heute auf den ersten Blick erstaunlich gut organisiert und kontrollierbar. Die Abläufe sind etabliert, die Zusammenarbeit mit dem Fachbereich funktioniert, und die Arbeit ist klar strukturiert.Anforderungen werden in Refinements gemeinsam analysiert, in Stories zerlegt und anschließend in Iterationen geplant. Mit der Zeit entwickeln Teams ein sehr gutes Gefühl dafür, wie viel sie leisten können, welche Aufgaben aufwendig sind und wie sich ihre Kapazität realistisch einschätzen lässt. Planung wird dadurch verlässlicher, der Fortschritt sichtbar und die Lieferung vorhersehbar.
Es ist einfach zu sehen, was umgesetzt wurde, aber deutlich schwieriger zu beurteilen, was diese Umsetzung tatsächlich bewirkt hat.
In diesem Umfeld werden Teams sehr gut darin, ihren Output zu organisieren und zuverlässig zu liefern. Das Team wird zu einem gut funktionierenden System, das Stabilität und Orientierung bietet.
Ein Bruch entsteht aber an der Schnittstelle zur Organisation. Früher oder später stellt sich dort die Frage, wie gut die Teams tatsächlich arbeiten. Welche Teams sind besonders leistungsfähig, wo entstehen Engpässe und welche Investitionen lohnen sich? Diese Fragen sind notwendig, weil sie die Grundlage für Entscheidungen über Prioritäten, Budgets und strategische Ausrichtung bilden. Ohne sie kann eine Organisation nicht sinnvoll steuern.
Genau an diesem Punkt zeigt sich jedoch ein strukturelles Problem. Während Teams sehr gut darin sind, ihren Output sichtbar zu machen, fehlt häufig eine belastbare Grundlage, um den tatsächlichen Effekt dieser Arbeit zu bewerten. Es ist einfach zu sehen, was umgesetzt wurde, aber deutlich schwieriger zu beurteilen, was diese Umsetzung tatsächlich bewirkt hat. Die Veränderung im Verhalten der Benutzer, die Verbesserung von Prozessen oder der geschäftliche Nutzen lassen sich nicht in gleicher Weise direkt erfassen.
In dieser Situation entsteht eine Lücke zwischen dem, was leicht beobachtbar ist, und dem, was eigentlich relevant wäre. Um diese Lücke zu schließen, greifen Organisationen auf das zurück, was verfügbar ist. Output ist messbar, vergleichbar und meistens ohne großen Aufwand aus bestehenden Systemen ableitbar. Die Anzahl gelieferter Features, abgeschlossener Stories oder umgesetzter Story Points lässt sich jederzeit darstellen und über Zeit hinweg beobachten. Damit wird Output schrittweise zur Grundlage für eine Bewertung. Dieser Schritt ist nachvollziehbar, weil er eine scheinbare Objektivität schafft und Vergleichbarkeit ermöglicht. Wenn sich Wirkung nur schwer messen lässt, erscheint es sinnvoll, zumindest die gelieferte Arbeit als Referenz zu nutzen. Man folgt der Devise "Besser irgendwas als nichts".
Besonders deutlich wird diese Verschiebung am Beispiel der Velocity. Sie beschreibt die Menge an Arbeit, die ein Team innerhalb einer Iteration abschließt, typischerweise gemessen in Story Points oder einfach nur abgeschlossenen Stories. Eigentlich dient sie dem Team als internes Hilfsmittel, um die interne Planung zu verbessern und ein Gefühl für die eigene Leistungsfähigkeit zu entwickeln. Wird sie jedoch zur Bewertung durch externe Stakeholder herangezogen, verändert sich ihre Rolle grundlegend. Aus einem Werkzeug zur Selbststeuerung wird eine Kennzahl zur Bewertung von Leistung.
Sobald Output auf diese Weise zur Grundlage von Bewertung wird, beginnt er das Verhalten zu beeinflussen. Das geschieht selten bewusst, sondern ergibt sich aus der Situation heraus. Wenn bestimmte Kennzahlen beobachtet und interpretiert werden, entsteht ein impliziter (und manchmal auch expliziter) Druck, diese Kennzahlen zu verbessern. Im Fall der Velocity ist das vergleichsweise einfach möglich, weil ihre Grundlage nicht objektiv vorgegeben ist, sondern durch das Team selbst definiert wird. Schätzungen können angepasst, Arbeit anders geschnitten oder Einheiten neu strukturiert werden, ohne dass sich an der tatsächlich geleisteten Arbeit oder am geschaffenen Mehrwert etwas ändert.
Das Ergebnis ist eine Verschiebung, bei der sich die Zahlen verbessern, während die Realität unverändert bleibt. Für die Organisation entsteht dadurch ein Bild von Fortschritt und Leistungsfähigkeit, das sich gut darstellen lässt, aber nur begrenzt aussagekräftig ist. Teams können scheinbar verglichen werden, Entwicklungen erscheinen nachvollziehbar, und Entscheidungen wirken datenbasiert. Gleichzeitig bleibt unklar, ob die zugrunde liegende Arbeit tatsächlich den gewünschten Effekt erzielt.
Aus einem Werkzeug zur Selbststeuerung wird eine Kennzahl zur Bewertung von Leistung.
Damit entsteht eine Situation, die für beide Seiten unbefriedigend ist. Die Organisation versucht, auf Basis der verfügbaren Kennzahlen zu steuern, erreicht damit aber nur begrenzt die gewünschte Wirkung. Teams liefern zuverlässig Output, werden jedoch anhand von Größen bewertet, die ihre tatsächliche Leistung nur unzureichend abbilden. Es entsteht Friktion zwischen dem, was gemessen wird, und dem, was eigentlich zählt.
Der Kern des Problems liegt nicht in einzelnen Prozessen oder Kennzahlen, sondern in einer grundlegenden Unklarheit darüber, was überhaupt gemessen und bewertet wird. Solange Output als Ersatz für Wirkung dient, wird sich dieses Muster immer wiederholen. Teams optimieren das, was sichtbar ist, Organisationen bewerten das, was messbar ist, und beide Seiten verlieren den Blick darauf, ob die Arbeit tatsächlich den gewünschten Effekt hat.
Um dieses Muster zu durchbrechen, reicht es nicht aus, einzelne Metriken anzupassen. Es braucht ein klares Verständnis dafür, welche unterschiedlichen Ebenen in der Softwareentwicklung existieren und welche Aussagen sich auf welcher Ebene treffen lassen.
2. Output, Outcome und Impact: Warum wir die falschen Dinge messen
Um zu verstehen, warum Output so häufig zur zentralen Bewertungsgröße wird und warum das zwangsläufig zu Fehlsteuerungen führt, lohnt es sich, die unterschiedlichen Ebenen unserer Arbeit klar voneinander zu trennen. Denn nicht alles, was wir im Kontext von Softwareentwicklung beobachten oder messen können, beschreibt das Gleiche. Im Gegenteil, es handelt sich um grundlegend unterschiedliche Perspektiven, die in der Praxis jedoch häufig vermischt werden.
Eine hilfreiche Unterscheidung besteht aus drei Ebenen: Output, Outcome und Impact.
Output beschreibt das, was ein Team unmittelbar erzeugt. Es sind die Features, die Stories, die Bugfixes und technischen Verbesserungen, die innerhalb einer Iteration umgesetzt werden. Output entsteht vollständig innerhalb des Entwicklungssystems und ist damit direkt kontrollierbar. Genau deshalb lässt er sich so einfach messen. Tickets werden abgeschlossen, Features werden umgesetzt, Releases werden durchgeführt. Diese Sicht auf die Arbeit ist notwendig und sinnvoll, weil sie Planung, Struktur und Verlässlichkeit ermöglicht.
Gleichzeitig beantwortet Output nur eine sehr begrenzte Frage: Was haben wir gebaut? Er sagt nichts darüber aus, ob das Gebaute tatsächlich einen Unterschied macht.
Diese Wirkung beginnt erst auf der nächsten Ebene, dem Outcome. Outcome beschreibt die Veränderung, die durch die Software im Verhalten der Benutzer entsteht. Eine Funktion hat keinen Wert, weil sie existiert, sondern weil sie genutzt wird und eine bestimmte Wirkung entfaltet. Ein Prozess wird schneller, weil weniger Schritte notwendig sind. Eine Funktion wird häufiger genutzt, weil sie leichter zugänglich ist. Oder eine bestehende Funktion wird bewusst weniger verwendet, weil eine bessere Alternative geschaffen wurde. Outcome beantwortet damit eine andere Frage: Was hat sich durch unsere Arbeit verändert?
Im Unterschied zum Output ist Outcome nicht mehr vollständig innerhalb des Teams kontrollierbar. Er entsteht im Zusammenspiel zwischen Software und ihrer Nutzung im realen Kontext. Damit wird er schwerer greifbar. Es reicht nicht mehr aus, interne Daten zu betrachten. Es braucht ein Verständnis für die Benutzer, ihre Ziele und ihre Arbeitsweise. Messungen sind möglich, aber sie erfordern bewusste Entscheidungen darüber, was überhaupt beobachtet werden soll.
Noch einen Schritt weiter geht der Impact. Impact beschreibt die Auswirkungen dieser Veränderungen auf die Organisation als Ganzes. Während Outcome das Verhalten verändert, beschreibt Impact den Effekt auf das Ergebnis. Eine Verbesserung in der Nutzung kann dazu führen, dass mehr Operationen durchgeführt werden, dass Prozesse schneller durchlaufen werden oder dass Kosten reduziert werden. Im besten Fall zeigt sich Impact in betriebswirtschaftlichen Kennzahlen wie Umsatz, Effizienz oder Kundenzufriedenheit.
Impact beantwortet damit die Frage: Warum lohnt sich das Ganze?
Die Beziehung zwischen diesen drei Ebenen ist naheliegend, aber nicht so stabil, wie sie oft angenommen wird. Output verändert das System, Outcome verändert das Verhalten und Impact verändert das Geschäft. Diese Kette ist in der Praxis jedoch weder linear noch zuverlässig. Viel Output kann zu wenig Outcome führen, wenn Features nicht genutzt werden oder am eigentlichen Problem vorbeigehen. Viel Outcome kann zu geringem Impact führen, wenn die beobachtete Veränderung keinen relevanten Effekt für die Organisation hat. Gleichzeitig können kleine Änderungen im Output eine große Wirkung entfalten, wenn sie an der richtigen Stelle ansetzen.
Genau an dieser Stelle entsteht ein zentrales Missverständnis. In vielen Organisationen werden diese Ebenen nicht bewusst getrennt. Stattdessen wird implizit angenommen, dass mehr Output automatisch zu mehr Wirkung führt. Diese Annahme ist attraktiv, weil sie einfach ist und sich gut messen lässt. Sie ist jedoch in vielen Fällen falsch.
Der Grund dafür liegt in den Rahmenbedingungen: Output ist leicht messbar, Outcome und Impact sind es typischerweise nicht. Organisationen stehen jedoch unter dem Druck, Entscheidungen treffen zu müssen. Dafür werden Kennzahlen benötigt. Wenn die relevanten Größen schwer zu erfassen sind, wird auf das zurückgegriffen, was verfügbar ist. Damit entsteht eine Verschiebung. Es wird nicht das gemessen, was wichtig ist, sondern das, was messbar ist.
Diese Verschiebung hat weitreichende Konsequenzen. Kennzahlen, die eigentlich nur eine interne Perspektive abbilden, werden für Fragestellungen verwendet, für die sie nicht geeignet sind. Output wird genutzt, um Aussagen über Wirkung oder geschäftlichen Erfolg zu treffen. Gleichzeitig entsteht der Eindruck, dass diese Aussagen objektiv und belastbar sind, weil sie auf Zahlen basieren.
Besonders problematisch wird es, wenn eine einzelne Kennzahl mehrere Fragen gleichzeitig beantworten soll. Eine Output-Kennzahl wird genutzt, um Produktivität zu bewerten, Fortschritt zu messen und gleichzeitig Rückschlüsse auf den geschäftlichen Nutzen zu ziehen. In diesem Moment verliert die Kennzahl ihren klaren Bezugspunkt. Sie wird überladen und damit zwangsläufig missverstanden.
Hinzu kommt der Wunsch nach Vergleichbarkeit. Organisationen möchten Teams gegenüberstellen, Entwicklungen bewerten und Ressourcen gezielt einsetzen. Output bietet hierfür eine scheinbar einfache Lösung. Zahlen lassen sich nebeneinanderstellen, Unterschiede werden sichtbar, und es entsteht der Eindruck, dass Leistung objektiv messbar ist.
Es wird nicht das gemessen, was wichtig ist, sondern das, was messbar ist.
Doch dieser Eindruck hält einer genaueren Betrachtung nicht stand. Unterschiedliche Teams arbeiten in unterschiedlichen Kontexten, lösen unterschiedliche Probleme und bewegen sich in unterschiedlichen technischen und fachlichen Rahmenbedingungen. Ihre Zahlen sind zwar vergleichbar dargestellt, aber nicht vergleichbar in ihrer Bedeutung.
Der eigentliche Denkfehler liegt darin, dass unterschiedliche Fragen mit der gleichen Art von Messung beantwortet werden sollen. "Wie viel liefern wir?", "Was verändert sich dadurch?" und "Welchen Effekt hat das für die Organisation?" sind drei grundlegend verschiedene Fragestellungen. Sie erfordern unterschiedliche Perspektiven und unterschiedliche Formen der Bewertung.
Solange diese Unterschiede nicht klargemacht werden, muss die Steuerung unscharf bleiben. Output wird weiterhin als Ersatz für Wirkung dienen, und Entscheidungen werden auf Basis von Größen getroffen, die nur einen Teil der Realität abbilden.
Wenn wir Softwareentwicklung sinnvoll steuern wollen, müssen wir akzeptieren, dass es keine einzelne Kennzahl gibt, die alle relevanten Aspekte abbildet. Stattdessen braucht es ein bewusstes Zusammenspiel dieser drei Ebenen. Output bleibt wichtig für Planung und Umsetzung, Outcome macht sichtbar, ob die Arbeit eine Wirkung entfaltet, und Impact zeigt, ob diese Wirkung für die Organisation relevant ist. Erst wenn diese Ebenen bewusst getrennt und gleichzeitig zusammengedacht werden, entsteht ein realistisches Bild. Damit verschiebt sich der Fokus weg von der Optimierung einzelner Zahlen hin zur bewussten Betrachtung von Zusammenhängen.
3. Wie Softwareentwicklung wieder wirksam wird
Wenn klar wird, dass Output allein keine verlässliche Grundlage für Steuerung ist, entsteht zwangsläufig die nächste Frage: Was bedeutet das konkret für unsere tägliche Arbeit?
Die Antwort darauf liegt nicht in neuen Methoden oder zusätzlichen Prozessen. Die meisten Teams verfügen bereits über alle notwendigen Strukturen. Was sich ändern muss, ist der Blick auf die eigene Arbeit. Statt sich primär an Aktivität zu orientieren, muss der Fokus auf Wirkung verschoben werden.
Dieser Perspektivwechsel beginnt bei der Art und Weise, wie Anforderungen verstanden werden.
In vielen Teams werden Anforderungen als Aufgaben betrachtet, die umgesetzt werden müssen. Sie werden beschrieben, geschätzt und in Arbeitseinheiten zerlegt. Ziel ist es, sie effizient und verlässlich zu liefern. Dieser Ansatz ist sinnvoll, solange es darum geht, Output zu organisieren. Er greift jedoch zu kurz, wenn es um Wirksamkeit geht.
Eine Anforderung ist nicht nur eine Beschreibung von Arbeit, sondern immer auch eine Annahme darüber, was durch diese Arbeit erreicht werden soll. Sie impliziert, dass sich durch ihre Umsetzung etwas verändert. Genau diese impliziten Annahmen bleiben in der Praxis jedoch häufig unausgesprochen.
Ein wirkungsorientierter Ansatz macht diese Annahmen explizit. Er verschiebt die zentrale Frage von "Was bauen wir?" hin zu "Was soll sich dadurch verändern?" Damit wird jede Anforderung zu einer Hypothese über den Zusammenhang zwischen Output, Outcome und Impact.
Diese Hypothesen sind selten richtig oder falsch. Sie basieren auf Erfahrung, Kontextwissen und Annahmen über Benutzer und Organisation. Genau deshalb ist es entscheidend, sie nicht nur zu formulieren, sondern auch zu überprüfen.
Damit verändert sich die Rolle von Feedback. Feedback ist nicht mehr nur eine Rückmeldung zur Qualität der Umsetzung, sondern eine Rückmeldung zur Wirksamkeit. Es geht nicht mehr nur darum, ob etwas funktioniert, sondern ob es den gewünschten Effekt erzielt. Dafür braucht es gezielte Rückkopplung aus der Nutzung der Software. Nutzungsdaten, Beobachtungen, Rückmeldungen von Anwendern oder Veränderungen in Prozessen liefern Hinweise darauf, ob eine Annahme trägt oder nicht.
Diese Hinweise sind selten schwarz oder weiß. Sie liefern keine Beweise, sondern Indikatoren. Dennoch sind sie ausschlaggebend, um Entscheidungen anzupassen und den nächsten Schritt besser zu wählen.
Eine Anforderung ist nicht nur eine Beschreibung von Arbeit, sondern immer auch eine Annahme darüber, was durch diese Arbeit erreicht werden soll.
Damit verändert sich auch die Bedeutung von Planung. Planung bleibt notwendig, um Arbeit zu strukturieren und Verlässlichkeit zu schaffen. Gleichzeitig verschiebt sich ihr Fokus. Es geht nicht mehr nur darum, möglichst viel Arbeit in einer Iteration zu erledigen, sondern darum, die richtigen Dinge umzusetzen. Priorisierung orientiert sich stärker an erwarteter Wirkung als an Umsetzbarkeit allein.
Das bedeutet nicht, dass Effizienz an Bedeutung verliert. Sie bleibt wichtig, ist aber nicht mehr das alleinige Kriterium für gute Entscheidungen.
Auch die Rolle des Product Owners ändert sich in diesem Kontext. Ein Product Owner, der sich primär auf Output konzentriert, verwaltet Arbeit. Er priorisiert Backlogs, koordiniert Anforderungen und sorgt dafür, dass das Team liefern kann. Diese Aufgaben bleiben wichtig, greifen jedoch zu kurz.
Ein wirkungsorientierter Product Owner verbindet die Ebenen von Output, Outcome und Impact. Er stellt sicher, dass hinter Anforderungen eine klare Vorstellung von Wirkung steht und dass diese Wirkung in Entscheidungen einfließt. Er hinterfragt Anforderungen, macht Annahmen sichtbar und integriert Feedback systematisch in die Priorisierung.
Damit bewegt er sich im Spannungsfeld zwischen Benutzer und Organisation. Er muss sowohl verstehen, welche Probleme für Benutzer relevant sind, als auch, welche Effekte für die Organisation entscheidend sind. Diese Perspektiven sind nicht immer deckungsgleich, müssen aber gemeinsam betrachtet werden.
Auch für das Team verändert sich die Perspektive. Ein Team, das sich ausschließlich auf Output konzentriert, optimiert seine Umsetzung. Es sorgt dafür, dass Anforderungen technisch sauber realisiert werden und dass Prozesse effizient funktionieren. Ein Team, das Wirksamkeit ernst nimmt, erweitert diesen Blick.
Es betrachtet Anforderungen nicht nur als Arbeitsauftrag, sondern als Hypothese. Es interessiert sich intensiv dafür, ob die eigene Arbeit den gewünschten Effekt erzielt, und hinterfragt, ob die gewählte Lösung tatsächlich geeignet ist, das zugrunde liegende Problem zu lösen.
Es entsteht eine neue Definition von guter Arbeit. Es geht nicht mehr nur darum, etwas korrekt zu implementieren, sondern darum, einen Beitrag zur Wirksamkeit des Produkts zu leisten.
Diese Veränderungen betreffen nicht nur einzelne Rollen, sondern die Zusammenarbeit insgesamt.
Teams, die sich auf Output fokussieren, optimieren ihre Aktivität. Teams, die Outcome und Impact bewusst einbeziehen, optimieren ihre Wirkung.
Wenn Wirkung im Mittelpunkt steht, können und dürfen Entscheidungen nicht isoliert getroffen werden. Fachbereich, Product Owner und Team müssen gemeinsam verstehen, welches Problem gelöst werden soll und welche Wirkung erwartet wird. Das führt zu mehr Abstimmung, aber auch zu besseren Entscheidungen, weil unterschiedliche Perspektiven zusammengeführt werden.
Wichtig ist dabei, dass all diese Veränderungen kein neues Framework erfordern. Die notwendigen Strukturen existieren bereits in den meisten Teams. Refinements, Plannings und Reviews bieten ausreichend Raum, um diese Perspektive zu integrieren.
Der Unterschied liegt darin, wie diese Formate genutzt werden. Statt ausschließlich Output zu organisieren, werden sie genutzt, um Wirkung zu verstehen, Annahmen zu formulieren und Feedback auszuwerten.
Am Ende lässt sich der Unterschied einfach zusammenfassen: Teams, die sich auf Output fokussieren, optimieren ihre Aktivität. Teams, die Outcome und Impact bewusst einbeziehen, optimieren ihre Wirkung.
Beides ist notwendig. Ohne den Blick auf Wirkung bleibt die Steuerung jedoch unvollständig. Genau hier liegt der entscheidende Hebel, um Softwareentwicklung nicht nur effizienter, sondern tatsächlich besser zu machen.
4. Verantwortung übernehmen
Die beschriebenen Probleme sind kein Spezialfall einzelner Teams oder Organisationen. Sie entstehen überall dort, wo versucht wird, komplexe Arbeit mit einfachen Kennzahlen zu steuern. Die Mechanismen dahinter sind nachvollziehbar, die Auswirkungen deutlich sichtbar.
Die entscheidende Frage ist daher nicht, ob wir es besser machen könnten, sondern ob wir bereit sind, es tatsächlich zu tun. Es wird keinen Zeitpunkt geben, an dem alle Voraussetzungen erfüllt sind. Outcome und Impact werden immer schwerer zu messen sein als Output. Daten werden unvollständig bleiben, Zusammenhänge nicht eindeutig und Entscheidungen mit Unsicherheit behaftet. Das ist die Realität von Softwareentwicklung.
Veränderung beginnt nicht mit perfekten Messgrößen oder neuen Prozessen, sondern mit einem anderen Umgang mit der eigenen Arbeit. Sie beginnt dort, wo wir aufhören, Output als Ersatz für Wirkung zu verwenden und anfangen, bewusst zwischen diesen Ebenen zu unterscheiden.
Das bedeutet, andere Fragen zu stellen. Nicht nur: Was bauen wir als Nächstes?
Sondern: Warum bauen wir es, und woran erkennen wir, ob es wirkt?
Diese Verschiebung ist kein organisatorisches Programm, sondern eine Entscheidung im Alltag. Sie liegt in der Hand von Product Ownern, von Entwicklungsteams und von allen, die an der Gestaltung von Software beteiligt sind.
Niemand wird diese Veränderung vollständig vorgeben. Sie entsteht dort, wo Menschen beginnen, ihre Entscheidungen bewusster zu treffen und ihre Arbeit an Wirkung auszurichten.
Wenn guter Output nicht reicht, dann ist das kein Problem, das gelöst werden muss.
Es ist ein Hinweis darauf, dass wir an der falschen Stelle optimieren.
Und genau das können wir ändern.
