Begleitbeitrag zum technischen Artikel auf bbv Tech Insights: Weird C# Quirks and How to Steer Your Team Toward the Pit of Success
Kennen Sie das?
Ihr Entwicklungsteam beantragt Zeit für Aufgaben, die auf den ersten Blick nichts mit dem eigentlichen Produkt zu tun haben. Keine neue Funktion – dabei müssen Sie doch für den Markt liefern. In der aktuellen VUCA-Welt scheint Geschwindigkeit entscheidend, und agile Methoden haben genau diese Geschwindigkeit versprochen. Also entscheiden Sie sich, weiterhin auf Features zu setzen.
Ein Jahr später stellen Sie fest: Die Entwicklung eines Features, das ursprünglich auf drei Wochen geschätzt wurde, dauert plötzlich drei Monate. Fehler treten häufiger auf und die Planbarkeit von Vorhaben wird zunehmend schwieriger.
Was ist passiert?!
Ich erlebte und beobachtete dieses Muster in mehreren Umfeldern, leider mit denselben Effekten. Diese Umfelder werden als Feature Factories bezeichnet.
Wenn Sie digitale Produkte verantworten, ist Softwarequalität keine technische Nebenfrage. Sie ist eine Voraussetzung für planbare Lieferung, beherrschbare Risiken und eine hohe Wirkung Ihrer Investitionen in die Entwicklungsorganisation.
Unternehmen verlieren selten an Tempo, weil Ihren Teams Fähigkeiten fehlen. Sie verlieren an Tempo, weil Ihre Systeme mit jeder Änderung schwerer zu steuern, teurer zu warten und anfälliger für Fehler werden.
Worum es wirtschaftlich wirklich geht
Der technische Artikel spricht über Eigenheiten von C#. Für die Geschäftsleitung ist das jedoch nur die Oberfläche. Im Kern geht es um eine deutlich wichtigere Frage: Unter welchen Bedingungen kann ein Entwicklungsteam dauerhaft verlässlich liefern?
Diese Frage berührt drei Themen, die für Führungskräfte unmittelbar relevant sind:
- Planbarkeit: Wie verlässlich lassen sich Vorhaben umsetzen?
- Betriebsrisiko: Wie hoch ist die Wahrscheinlichkeit für Fehler, Nacharbeit und Störungen?
- Wirkung des Entwicklungsbudgets: Wie viel Ergebnis erzielen Sie mit Ihren Investitionen tatsächlich?
Wenn falsche technische Entscheidungen im Alltag leicht passieren, entstehen schleichend Reibungsverluste. Dann werden Änderungen langsamer, Abstimmungen häufiger und Korrekturen teurer. Was heute wie eine kleine technische Unsauberkeit wirkt, wird morgen zu einem messbaren Wettbewerbsnachteil.
Software Quality Map
Gehen Sie mit Ihrem Team auf Entdeckungsreise: Die Software Development Quality Map macht Qualität greifbar – und zeigt den Weg zu stabileren Releases.
Warum technische Details wirtschaftliche Auswirkungen haben
Der technische Beitrag zeigt Beispiele für Standardeinstellungen und Sprachkonstrukte, die beispielsweise in C# formal erlaubt sind, aber Fehler begünstigen. Für das Management ist nicht das einzelne Beispiel entscheidend. Entscheidend ist das Muster dahinter:
Ein gutes System macht es einfach, das Richtige zu tun – und unangenehm, das Falsche zu tun.
Wenn ein System das Falsche leicht macht, steigen Kosten und Risiken. Wenn ein System das Richtige erleichtert, steigt die Lieferfähigkeit.
An diesem Punkt setzt das Konzept des «Pit of Success» an. Gemeint ist ein Arbeitsumfeld, in dem gute Entscheidungen nicht vom Zufall oder vom Heldentum einzelner Mitarbeitender abhängen. Stattdessen sorgen technische Leitplanken, Regeln und automatisierte Prüfungen dafür, dass Teams im Alltag verlässlicher handeln können.
Verständlichere Beispiele sind eine automatische Kategorisierung von Geschäftsausgaben mit Anomalie-Detektion oder Projektantragsvorlagen, welche die wichtigsten Informationen wie Kundenwirkung, Kosten und Risiken abfragen, bevor ein Vorhaben überhaupt genehmigt wird.
Warum reine Funktionsorientierung teuer wird
Viele Unternehmen steuern Entwicklung noch immer vor allem über neue Funktionen. Das ist nachvollziehbar, weil neue Funktionen sichtbar sind und kurzfristig nach Fortschritt aussehen. Die Stabilisierung der Architektur, die Reduktion technischer Schulden oder der Aufbau wirksamer Qualitätsmechanismen sind dagegen für Aussenstehende oft unsichtbar.
Darin liegt das Problem.
Wer ausschliesslich auf kurzfristig sichtbare Ergebnisse optimiert, verschiebt Kosten in die Zukunft. Die Folgen zeigen sich typischerweise in folgenden Mustern:
- Neue Funktionen zu entwickeln, dauert länger als früher
- Das Team verbringt mehr Zeit mit Fehlerbehebungen
- Neue Vorhaben werden ungenauer planbar
- Der Aufwand pro Änderung steigt kontinuierlich
Das ist kein technisches Randthema, sondern ein betriebswirtschaftlicher Effekt. Interne Softwarequalität bestimmt, wie schnell ein Unternehmen auf Marktveränderungen reagieren kann, wie stabil der Betrieb bleibt und wie effizient Entwicklungsressourcen eingesetzt werden.
Mehr Klarheit für Ihre Entscheidungen
Ein Software-Architektur-Review macht Risiken sichtbar, reduziert technische Schulden und schafft eine fundierte Basis für zukünftige Entscheidungen.
Was das für Ihre Priorisierung bedeutet
Eine belastbare Entwicklungsorganisation investiert ihre Kapazität nicht ausschliesslich in neue Funktionen. Sie schützt bewusst auch Zeit für Architektur, technische Schulden und Stabilisierungsmassnahmen. Nicht aus Perfektionismus, sondern um die eigene Handlungsfähigkeit zu erhalten.
Für die Unternehmensführung bedeutet das: Die richtige Frage lautet nicht, ob Qualitätsarbeit kurzfristig sichtbar ist. Die richtige Frage lautet, ob Ihr Unternehmen es sich leisten kann, auf diese Investitionen zu verzichten.
Denn jede unterlassene Qualitätsentscheidung erzeugt später operative Folgekosten – durch langsamere Umsetzung, höhere Fehlerlast, mehr Koordinationsaufwand und sinkende Veränderungsgeschwindigkeit.
Wenn Sie die Lieferfähigkeit Ihres Unternehmens langfristig sichern wollen, sind vier Führungsimpulse besonders wirksam.
Vier Führungsimpulse für nachhaltige Lieferfähigkeit
Behandeln Sie Softwarequalität als Steuerungsfrage
Qualität ist nicht allein Sache einzelner Entwicklerinnen und Entwickler. Sie entsteht aus Prioritäten, Rahmenbedingungen und Führungsentscheidungen. Sprechen und definieren Sie mit dem Team die geforderte Qualität durch eine priorisierte Liste von Qualitätskriterien und Szenarien. Auf dieser Basis kann ein Team fundierte Entscheidungen treffen.
Verlangen Sie Transparenz über die Kosten mangelnder Qualität
Fragen Sie nicht nur nach dem Fortschritt neuer Funktionen. Fragen Sie auch nach Reibungsverlusten, Wartungsaufwand, Fehlerhäufigkeit und sinkender Planbarkeit. Diese Informationen sind entscheidend, um zu verstehen, ob Sie die Priorisierung anpassen müssen, um die langfristige Lieferfähigkeit zu sichern.
Schützen Sie Kapazität für strukturelle Verbesserungen
Wenn Architekturarbeit und der Abbau technischer Schulden dauerhaft aus dem Fokus fallen, sinkt die Wirksamkeit jeder künftigen Investition in neue Funktionen. Sorgen Sie für ein gemeinsames Verständnis der Priorisierungen, zum Beispiel durch die Nutzung des Product Backlog Prioritization Quadrants.
Vertrauen Sie Ihrem Team und hören Sie auf Warnsignale erfahrener Teams
Wenn ein erfahrenes Entwicklungsteam wiederholt auf fehlende Zeit für Qualität hinweist, ist das in der Regel kein Selbstzweck. Es ist ein Hinweis auf steigende operative Risiken. Falls diese Stimmen verschwinden, ist es oft schon zu spät, die Motivation könnte sich zu Resignation entwickelt haben. Sprechen Sie mit dem Team offen über ihre Herausforderungen und Sorgen.
Der Product Backlog Prioritization Quadrant hilft, ein gemeinsames Verständnis zu schaffen
Der Product Backlog Prioritization Quadrant zeigt, dass ein Entwicklungsteam seine Kapazität typischerweise auf vier Bereiche verteilt:
- Neue Funktionen schaffen sichtbaren Geschäftswert
- Architektur-Innovation bereitet das System auf zukünftige Anforderungen vor
- Support sichert Stabilität und Kundenzufriedenheit
- Technische Schulden zu reduzieren, hält die Entwicklung langfristig effizient
Meiner Erfahrung nach ist der Dialog nicht einfach, aber zwingend notwendig. Starten Sie mit den darunterliegenden Bedürfnissen und Zielen. Oft sind diese gar nicht so unterschiedlich, wie die Sprache auf den ersten Blick vermuten lässt. Ein gemeinsames Verständnis der Kapazitätsverteilung vereinfacht die Priorisierungen. Halten Sie jedoch auch ihr Team dazu an, dass Investitionen in die nicht-funktionalen Bereiche einen ökonomischen Treiber aufweisen müssen.
Die eigentliche Managementfrage
Der technische Artikel über C#-Eigenheiten ist deshalb für Entscheidungsträger relevant, weil er ein allgemeines Führungsthema sichtbar macht: Nachhaltige Lieferfähigkeit entsteht nicht durch Appelle an Disziplin, sondern durch Systeme, die vernünftiges Handeln unterstützen.
Sie kaufen mit Qualitätsinvestitionen nicht in erster Linie saubereren Code. Sie kaufen Steuerbarkeit, Geschwindigkeit und Risikoreduktion für Ihr Unternehmen.
Genau deshalb sollte Softwarequalität in der Geschäftsleitung nicht als technische Detailfrage behandelt werden, sondern als Teil guter Unternehmensführung.
Wenn Sie verstehen möchten, wie es um die Lieferfähigkeit Ihrer Entwicklungsorganisation steht, lohnt sich ein Blick auf unsere Software Quality Map oder ein Austausch mit unseren Expertinnen und Experten.
Marco Ravicini
DAS KÖNNTE SIE AUCH INTERESSIEREN
Microsoft Azure Zertifizierungen: Der Karriere-Boost für Cloud-Professionals
Lieferketten im Fokus: Cyber Resilience und Third-Party Risks
