Kann Heldentum zu nachhaltigen Ergebnissen führen?

von Edwin Hanegfraaf | Jul. 17, 2020 | Blog

Heldentum in der Softwareentwicklung

Viele Agilisten auf der ganzen Welt wissen sehr viel über Ansätze und Techniken, wie wir uns mit agilen Techniken einer besseren, ja sogar perfekten Welt nähern können. Es gibt eine Menge Artikel zu diesem Thema. Zusätzlich gibt es auch eine Menge Kritik an vielen Ansätzen, die in Postings beschrieben werden. Viel zu wenig Postings implizieren Neugierde, Empirie und die Durchführung eines Inspektions- und Anpassungszyklus über beobachtete Verhaltensweisen.

Um die Frage „Kann Heldentum zu nachhaltigen Ergebnissen führen?“ zu beantworten, müssen verschiedene grundlegende Fragen beantwortet werden, wie z.B. was ist es und welche Elemente beeinflussen es. Auf der Grundlage beobachteter Experimente kann definiert werden, wann es vorteilhaft und wann destruktiv sein kann. Um den Artikel leichtgewichtig zu halten, werden nur die relevantesten Elemente berücksichtigt.

Nachhaltige Ergebnisse
Ein Ergebnis ist laut einem Wörterbuch „eine Sache, die durch etwas anderes verursacht oder erzeugt wird; eine Folge oder ein Ergebnis“, also im Sinne der Softwareentwicklung typischerweise eine brauchbare Software, die eine bestimmte vereinbarte Funktion erfüllen kann. Nachhaltig ist, laut Wörterbuch, „in der Lage, in einem bestimmten Tempo oder auf einem bestimmten Niveau gewartet zu werden“. Im Sinne der Softwareentwicklung bedeutet dies typischerweise, dass Änderungen an der Software die Nutzbarkeit der Software nicht verschlechtern. Sie ist implizit auf eine längere Zeitspanne ausgerichtet.

Heldentum
Im Wörterbuch steht, dass Heldentum „große Tapferkeit“ bedeutet, und ein Held ist „eine Person, die für ihren Mut, ihre herausragenden Leistungen oder ihre edlen Eigenschaften bewundert wird“. Im Zusammenhang mit diesem Artikel wird jemand als Held bezeichnet, wenn eine bestimmte Person ein Projekt „gerettet“ hat, indem sie unter dem Druck bestimmter Fristen oder Budgets ein funktionierendes Produkt geschaffen hat, das an vielen Hürden, wie z.B. Bugs, zu scheitern schien. Da die Behebung von Bugs häufig vorkommt, werden solche Helden auch als Feuerwehrmänner bezeichnet.

In der Regel bezeichnet das Management, dessen Status und Boni vom Projekterfolg abhängen, diese Personen als Helden, da sie eine „herausragende Leistung“ erbracht haben.

Beobachtetes Heldentum
Mit 25 Jahren Erfahrung in der Softwareindustrie in mehr als 10 verschiedenen Unternehmen konnte in jedem von ihnen Heldentum beobachtet werden. In den meisten Fällen begann ein Entwickler oder eine sehr kleine Gruppe von Entwicklern mit der Arbeit an einem Produkt, oft ein Proof of Concept. Zu einem bestimmten Zeitpunkt setzt der Projektdruck ein, und dann werden oft viele Probleme gefunden. Der erfahrenste Entwickler behebt dann in der Regel die meisten dieser Probleme, rettet das Projekt und wird zum Helden.

Agilität
Eine der wichtigsten Säulen innerhalb der Agilität ist die Durchführung von Inspektionen und Anpassungen. Die Arbeit an komplexen Systemen (anwendbar auf viele Softwares) erfordert einen Rückblick und das Lernen aus gemachten Fehlern. In diesem Fall sind die meisten Unternehmen immer noch damit beschäftigt, den Erfolg zu feiern, und meistens vergessen die Menschen, einen kritischen Blick auf das Erreichte zu werfen. Die Angst, einen Bonus zu verlieren (Management) oder Credits innerhalb des neu erworbenen Status zu verlieren (Held), sind Gründe dafür, nicht zurückzublicken. 

Ein Rückblick hilft zu verstehen, wie der Erfolg erreicht wurde. Welche Abkürzungen wurden genommen, um das angestrebte Ziel zu erreichen? Was hätte in einem früheren Stadium besser gemacht werden können? Ist die Software- und Designqualität aus Sicht der Nachhaltigkeit gut genug?

Persönlichkeit
Normalerweise ist ein sehr guter Entwickler derjenige, der zum Helden geworden ist. Viele Hard-Core-Softwareentwickler sind introvertiert und haben ein gutes Auge für Details. Die meisten Helden gehören zu dieser Gruppe, weil Präzision (beim Beheben von Bugs) hilfreich ist, um Probleme schnell zu beseitigen und so zum vermeintlichen Erfolg beizutragen.

Wie steht es mit dem Blick auf das große Ganze (Design)? Und eine gute Retrospektive zu machen? Beides kommt seltener vor. Meistens führt ein erfolgreiches Projekt zu einem Nachfolgeprojekt, an dem sehr viel mehr Software und Software-Ingenieure beteiligt sind. Der Held wird natürlich Teil des neuen Teams sein.

Qualität
Alle sind sich einig, dass Qualität der Schlüssel zu einem nachhaltigen Ergebnis im Software-Engineering ist. Da wir meistens in komplexen Bereichen arbeiten, denken wir darüber nach, wie wir die Qualität verbessern und damit die Risiken bei der Erstellung eines Produkts, das fehlerhaft ist oder nicht den Kundenwünschen entspricht, mindern können. Qualitätsdenken erfordert also, so früh wie möglich Feedback über diese Risiken zu erhalten, also agil zu denken. Es geht um das Testen, es geht um die richtige Zusammenarbeit mit dem Kunden, es geht um das richtige Vorgehen bei Änderungen.

Meistens wird der Held Teil des neuen Teams, und das Management erwartet von ihm, dass er den gleichen „erfolgreichen“ Trick noch einmal macht. Wie bereits angedeutet, wurde oft keine Retrospektive durchgeführt, so dass wir nicht wissen, wo die Qualität versagt haben könnte. Wie alle menschlichen Wesen neigen Helden dazu, zu erwarten, dass die Menschen auf die gleiche Weise auf die Welt schauen wie sie selbst, so dass auch das Team dieselbe Sichtweise und dasselbe Verständnis hat. Aus diesem Grund wird die Qualität, einschließlich des Designs, oft nicht in Frage gestellt. Der Zeitpunkt, an dem viele Bugs auftauchen, ist typischerweise in den späten Phasen der Entwicklung.

Skalierbarkeit
Die Entwicklung eines größeren Produkts erfordert in der Regel mehr Entwicklungskapazität. Es sind also mehr Menschen beteiligt. Wie bereits erwähnt, sind die besten Entwickler oft introvertiert, was bedeutet, dass Kommunikation nicht ihre stärkste Fähigkeit ist. Und nun sollten sie ihr Wissen über das vorherige Produkt teilen und diskutieren. Außerdem lieben einige Helden den neuen Status des Experten, so dass sie die meisten Informationen für sich behalten.

Und was passiert, wenn die Bugs auftauchen? Die Standardreaktion des Managements ist es, Kapazität hinzuzufügen, also mehr Entwickler. Es sollte inzwischen bekannt sein, dass dies niemals eine gute kurzfristige Strategie ist; in die zugrunde liegende Qualität zu investieren, ist im Grunde der beste Ausweg, wobei Investitionen in die Verbesserung der Kommunikation innerhalb des Teams sehr hilfreich sind. Von allen beobachteten Heldentumsprojekten ist der Teil, in dem diese beiden Elemente angegangen wurden, viel erfolgreicher geworden, auch wenn es einige Zeit dauerte, bis es soweit war.

Fazit
Im Allgemeinen wird Heldentum nicht zu nachhaltigen Ergebnissen führen, insbesondere dann nicht, wenn ein Produkt anschließend umfassend erweitert wird und mehr Menschen involviert sind. Die Hauptrisiken sind Qualität und Kommunikation. Dennoch, wenn der Held – der diesen Status durch das Management erhalten hat – diese Risiken wirklich versteht und bei ihrer Minderung unterstützt, könnte ein erfolgreiches Heldenprojekt dennoch zu einem nachhaltigen Ergebnis führen. Angesichts der Zahl der „wenn“ wird dies aber nur selten der Fall sein. Und selbst in der Phase, in der viele Fehler auftauchen, ist es spät, die Strategie zu ändern, aber niemals zu spät…

Das Schreiben dieses Artikels wirft eine weitere Frage auf: Warum glauben so viele Manager an Heldentum?

Lesen Sie weitere Beiträge von Edwin Hanegraaf auf LinkedIn.

Interesse an agile Methoden?

Wir helfen Ihnen dabei, Ihre Projekte durch den Einsatz agiler Methoden effektiver und effizienter durchzuführen. Dazu steht Ihnen ein hervorragend ausgebildetes und äußert erfahrenes Team an agilen Experten von Alter Solutions Deutschland zur Verfügung.

Teilen Sie den Beitrag oder lesen Sie jetzt weitere Beiträge

Ihnen hat der Beitrag gefallen? Dann teilen Sie Kann Heldentum zu nachhaltigen Ergebnissen führen? jetzt auf Social Media oder lesen Sie hier weitere Beiträge.