Effizienz oder Effektivität? Wenn die Softwareentwicklung optimiert werden soll, wird häufig an der falschen Stelle angesetzt. Die Lösung liegt mit Blick auf zwei Studien und unter Anwendung des Pareto-Prinzips auf der Hand. Die Produktivität der Softwareentwicklung kann so um das bis zu Fünffache gesteigert werden – allerdings nicht durch schnelleres Tippen …

© Schwarze Consulting GmbH

Inhalt

• Inhalt
• Einleitung
• Effizienz – wie entwickelt wird
  • Multitasking
• Effektivität – was entwickelt wird
  • Lösungsansätze
• Fazit

Einleitung

Die Softwarekrise ist auch rund 50 Jahre nach ihrer offiziellen Feststellung noch nicht überstanden. Jede Softwareentwicklungseinheit steht vor der Herausforderung, dass es mehr Bedarf beziehungsweise Anforderungen als Entwicklungskapazität gibt. Um dem entgegenzuwirken, liegt der Fokus von entsprechenden Optimierungsversuchen häufig auf Produktivitäts- beziehungsweise Effizienzsteigerungsmaßnahmen. Salopp gesagt, wird versucht, durch “schnelleres Tippen” mehr Software in kürzerer Zeit entwickelt zu bekommen.

Dies funktioniert aus verschiedenen Gründen nicht. Einerseits wird bei Effizienzsteigerungsversuchen häufig an der falschen Stelle angesetzt und der echte Hebel in der Softwareentwicklung, die Effektivität, wird andererseits viel zu selten betrachtet.

Effizienz – wie entwickelt wird

Softwareentwicklung ist zu einem hohen Anteil eine geistig-kreative Tätigkeit. Natürlich muss auch ein Schriftsteller zügig schreiben können, der Fertigstellungstermin eines Romans ist aber nur zu einem geringen Anteil von der reinen Schreibgeschwindigkeit des Schriftstellers abhängig. Gleiches gilt für die Softwareentwicklung. Es gibt zwar noch wenige Studien hierzu, die bestätigen allerdings unsere Projekterfahrung. Demnach umfasst ein Großteil der gesamten Entwicklungszeit für eine einzelne Software-Funktion Wartezeit und nur ein geringer Anteil ist Arbeits- beziehungsweise eben “echte” Entwicklungszeit:

© Darstellung: Schwarze Consulting GmbH – © Daten: Kanban University: https://leankanban.com/flow-efficiency-a-great-metric-you-probably-arent-using/

Die sogenannte Flow Efficiency, also die Dauer für die Entwicklung einer Funktion geteilt durch die reine Arbeitszeit, beträgt üblicherweise 15 %; Organisationen, die sich noch gar nicht mit dem Thema befasst haben, liegen häufig bei nur 1-2 % und am anderen Ende gibt es wenige Entwicklungseinheiten, die auf eine Flow Efficiency von bis zu 40 % kommen. Der Normalverteilung folgend, darf man hier aber guten Gewissens erstmal die üblichen 15 % ansetzen.

Der ABC-Analyse oder auch dem Pareto-Prinzip folgend, sollte man sich bei einer Wartezeit von 85 % natürlich zunächst um diesen großen Hebel kümmern. Bei entsprechenden Produktivitäts- beziehungsweise Effizienzsteigerungsmaßnahmen der Softwareentwicklung wird er aber unserer Erfahrung nach nahezu kategorisch ignoriert. Vermutlich weil die Wartezeiten schwerer zu greifen sind, als die eigentliche Arbeitsleistung. Dabei sind sie auch einer der Gründe, warum die Umsetzungsdauer von Entwicklungsvorhaben schwer zu schätzen ist, beziehungsweise entsprechende Schätzungen häufig daneben liegen: Wartezeiten sind kaum vorhersehbar, geschweige denn solide abschätzbar. Was ich zu entwickeln habe, kann ich als Entwickler sicherlich sehr gut mit etwas Erfahrung einschätzen. Aber wann ich wie lange auf was oder wen dabei zu warten habe, ist nicht deterministisch.

Selbst wenn man mit viel Aufwand die Entwicklungsgeschwindigkeit um 50 % erhöht bekäme, so hat man auf die übliche Flow Efficiency doch dann gerade mal 7,5 % an Umsetzungsdauer gewonnen¹. Die Fertigstellung einer einzelnen Funktion wird durch “schnelleres Tippen” des Entwicklers also nur unwesentlich beschleunigt.

Und wenn man ehrlich ist, so wird in vielen Organisationen durch eine Vielzahl von Hürden für den Entwickler die Entwicklungsgeschwindigkeit sogar eher noch mutwillig reduziert. Als Beispiele seien hier die Team-übergreifend einheitlich zu verwendende IDE zu nennen, die den einzelnen Entwickler eher verlangsamt. Oder Internet-Proxys, die einen daran hindern, notwendige Entwicklungsbibliotheken zu beziehen, nicht vorhandene Admin-Rechte auf dem Entwicklungsrechner, quälende langsame Test-Suiten, für die niemand Zeit zum Aufräumen bekommt, und so weiter.

Nicht, dass das falsch verstanden wird. Es ist extrem wichtig, in die Entwicklungseffizienz durch vernünftiges Tooling, individuelle IDEs und schnelle Feedback-Zyklen zu investieren, um einem Entwickler eine optimale Arbeitsumgebung zur Verfügung stellen zu können und so insbesondere die Entwicklungsqualität zu erhöhen. Die Umsetzungsdauer eines Features wird dies aber, wie gezeigt, nicht signifikant reduzieren.

Multitasking

Ein Entwickler wechselt bei entsprechender Wartezeit natürlich zu einer anderen Aufgabe, zum Beispiel der Entwicklung eines zweiten Features:

© Schwarze Consulting GmbH

Dieses Task-Switching ist aber sowohl grundsätzlich als auch bei Entwicklungstätigkeiten im Besonderen ein Produktivitäts- und Qualitäts-Killer. Jeder, der schon mal versucht hat, eine Aufgabe zu erledigen, die eine gewisse Konzentration erfordert und dabei permanent unterbrochen wurde, sollte das leicht nachvollziehen können. Und bis ein Entwickler das mentale Modell einer umfangreichen Codebasis “in den Kopf geladen” hat, können auch schon mal Stunden vergehen, bevor eine Zeile verändert wird. Blöd, wenn er dann kurz vorher gestört wird. Es ist also extrem wichtig, ein Arbeitsumfeld für Entwickler zu schaffen, in dem sie durchaus mehrere Stunden ungestört sind.

Sind dann mehrere Entwicklungsaufgaben parallel in Bearbeitung, um die Wartezeit zu optimieren, kommt es häufig zu Situationen, in denen der Entwickler eigentlich an beiden Features gleichzeitig arbeiten müsste, was natürlich nicht geht. Somit entsteht an einer Stelle eine zusätzliche Wartezeit (⚠️) und die Umsetzungsdauer erhöht sich entweder beim einen (Entwicklungsdauer Feature 1 = 100 % + x) oder beim anderen Feature (Entwicklungsdauer Feature 2 = 100 % + y) entsprechend. Die Umsetzungdauer jedes einzelnen Features, welches parallel zu anderen entwickelt wird, verlängert sich durch Multitasking also.

Untersuchungen zeigen, dass ein Entwickler trotz dieser Task-Wechsel aber auch nur 25-50 % seiner Zeit pro Tag mit reinen Entwicklungstätigkeiten verbringt. Unter Annahme der üblichen Flow Efficiency von 15 % schafft ein Entwickler es also, an 2 bis 3 Features parallel zu entwickeln; mit entsprechenden Zeit- und Qualitätseinbußen. Also liegt auch unter Einsatz von Multitasking das angenommene Effizienzpotential durch “schnelleres Tippen” bei nur 18,75 % ² und somit immer noch unter der Pareto-Schwelle.

Effizienz in der Softwareentwicklung ist also nicht der Heilsbringer, da ihr Hebel gering ist und ihre Optimierung, beispielsweise durch Multitasking auch negative Auswirkungen mit sich bringt.

Effektivität – was entwickelt wird

Die Effektivität, also die Frage, was beziehungsweise ob das Richtige entwickelt wird, ist bei der Optimierung von Softwareentwicklungsvorhaben unserer Erfahrung nach häufig nur von nachrangiger Bedeutung. Dabei werden nur 20 % der Anforderungen wirklich benötigt:

© Darstellung: Schwarze Consulting GmbH – © Daten: Universität Karlsruhe: https://ps.ipd.kit.edu/downloads/za_2007_schlanke_produktionsweisen_moderne_softwareentwicklung.pdf

Auch hier springt einen die ABC-Analyse oder das Pareto-Prinzip wieder geradezu an. Durch die richtige Auswahl dessen, was entwickelt wird, also über die Effektivität, lässt sich die Softwareentwicklung offensichtlich wesentlich leichter verbessern als über die Effizienz: der Hebel ist hier mit 80 % beim “Was” entwickelt wird viel höher als die oben weiter genannten 15 % beim “Wie”.

Zugegebenermaßen etwas polemisch formuliert, müsste eine Entwicklungseinheit, da bei 20% ja nur jedes fünfte umgesetzte Feature auch wirklich zum Einsatz kommt, kalkulatorisch auch “einfach” nur fünf Mal so groß sein, um die fehlende Effektivität zu kompensieren. Wir sind mit dem Vorschlag leider noch bei keinem Budgetverantwortlichen durch gekommen …

Bei Umsetzungen im Kundenauftrag ließe sich natürlich argumentieren, dass der Kunde doch alle Anforderungen bezahlt und damit doch wohl auch alle Anforderungen benötigt werden. Doch auch hier ist der Bedarf meist größer als die Entwicklungskapazität oder das Entwicklungsbudget. Und auch in diesem Fall stellt der Auftraggeber früher oder später fest, dass das eine oder andere Feature vielleicht doch nicht oder zumindest nicht so gebraucht wird, weshalb man auch hier drauf achten sollte, was entwickelt wird.

Weniger ist in der Softwareentwicklung also wirklich mehr, auch wenn es zunächst abwegig erscheint und abgedroschen klingen mag. Optimierungsversuche sollten hier also immer zuerst auf die Effektivität abzielen.

Lösungsansätze

Wie kann ich aber nun die Effektivität meiner Softwareentwicklung erhöhen, also dafür sorgen, dass möglichst viel von dem umgesetzt wird, was auch wirklich benötigt wird und möglichst wenig von dem, was nicht wirklich benötigt wird?

Wir erleben immer wieder Product-Backlogs, die voll von uralten Features sind. Wissend, dass 80 % davon nicht wirklich gebraucht werden, kann man also guten Gewissens davon ausgehen, dass die wichtigen Features schon umgesetzt wurden und die, die eine gewisse Zeit lang nicht zur Umsetzung kamen, auch nicht mehr gebraucht werden. Trotzdem müssen diese Features dann häufig umgesetzt werden, wodurch knappe Entwicklungskapazität unnötig gebunden wird. Effektive Softwareentwicklung ist keine “Supermarktkasse”, wo jeder früher oder später dran kommt. Um effektiver zu werden, müssen die Anforderungen sich jeden Tag aufs Neue hinsichtlich ihrer Priorität beweisen; Anforderungen, die nicht wichtig genug sind, sollten auch nicht “dran kommen”, wenn man mehr (des Richtigen) aus der Entwicklung bekommen möchte.

Anders herum erleben wir auch immer wieder, dass die Priorisierung von Features darüber erfolgt, welcher Anforderer “am lautesten schreit”. Wenn 80 % der Features aber nicht benötigt werden, wird so wiederum wertvolle, da knappe Entwicklungskapazität für unnötige Themen verschwendet, weil der, der am lautesten schreit, noch lange nicht der wichtigste Anforderer ist. Gibt man denen nach, entsteht natürlich der Eindruck, dass aus einer Entwicklungseinheit nicht genug heraus kommt, da eben nicht genug des Richtigen heraus kommt. So lange die Entwicklungseinheit sich selbst die Aufgaben priorisiert, wird sie immer Teil des Problems sein. In diesem Fall ist es genau wie an einer Supermarktkasse: Wenn ich vorgelassen werden möchte, kann das nicht der Mitarbeiter an der Kasse, also die Entwicklungseinheit entscheiden, sondern ich muss der Reihe nach alle vor mir Stehenden fragen beziehungsweise davon überzeugen, dass mein Anliegen dringender ist.

Wichtig ist in solchen Fällen, dass die üblicherweise vielen verschiedenen Stakeholder der Softwareentwicklung das Problem unter sich lösen. Hierzu haben wir schon erfolgreich unterschiedliche Ansätze, üblicherweise Gremien-orientiert in verschiedenen Organisationen implementiert. Alternativ wird es durch einen entsprechend “starken” Product Owner erledigt:

© Scrum.Org: https://www.scrum.org/resources/blog/evolution-product-owner

Die Rolle des Product Owners ist zwar mittlerweile in vielen Organisationen, die sich mit Softwareentwicklung beschäftigen, besetzt. Unserer Erfahrung nach aber noch eher selten im Sinne eines »Unternehmers im Unternehmen« (“Entrepreneur”), der auch alleine und vollumfänglich über die Roadmap und Features “seines” Produktes entscheiden kann. Dabei ist eine seiner Hauptaufgaben, “Nein” zu den meisten Anforderungen zu sagen und das Entwicklungsteam so effektiv und produktiv entwickeln zu lasssen. Alle anderen der oben gezeigten Ausprägungen der Rolle Product Owner werden üblicherweise einen konsens-orientierten Ansatz mit ihren Stakeholdern zur Priorisierung finden müssen. Wobei auch einem “starken” Product Owner dieser Weg durchaus angeraten sein kann.

Fazit

Eine effiziente Softwareentwicklung ist heutzutage ein Hygienefaktor. Über die Effizienz lässt sich die Produktivität in der Entwicklung, wie wir gezeigt haben, mit unter 20 % auch nur begrenzt steigern. Wenn das Thema Effizienz in der Softwareentwicklung angegangen wird, empfehlen wir, Wartezeiten zu reduzieren, da diese üblicherweise den Großteil der Entwicklungszeit eines Features ausmachen.

Wer wirklich mehr aus seiner Softwareentwicklungseinheit heraus bekommen möchte, sollte tatsächlich weniger entwicklen, nämlich weniger der nicht benötigten Features. Über die Effektivität lässt sich die Produktivität in der Entwicklung um das bis zu Fünffache steigern! Dann ist auch wieder ausreichend Kapazität für die wichtigen Features vorhanden. Hierzu wird jemand in verantwortlicher Position gebraucht, der “Nein” sagen kann – beispielsweise ein entsprechend “starker”, also befähigter und ermächtigter Product Owner.

Fussnoten: