Alles ist relativ – vor allem in der Softwareentwicklung

Zu Beginn meiner Beraterlaufbahn hatte ich recht klare Überzeugungen davon, wie gute Software gebaut werden sollte. Ich hatte „meinen“ Weg gefunden – und versuchte entsprechend, meine Kunden davon zu überzeugen, dass genau dieser Weg der richtige ist.

Relativ schnell musste ich allerdings feststellen, dass mein Ansatz eben nicht in jeder Situation gut funktioniert. Viel zu oft ertappte ich mich dabei, bei einem Problem beim Kunden reflexartig in meine mentale Schublade zu greifen und eine bekannte Musterlösung hervorzuholen – statt mir zunächst wirklich Zeit zu nehmen, das konkrete Problem und seinen Kontext zu verstehen.

Irgendwann lernte ich dann die klassische Beraterantwort:
„Es kommt darauf an.“

Ja, natürlich – es kommt darauf an. Aber worauf eigentlich? Und funktioniert das wirklich so mechanisch: Wenn A und B und C, dann passt Lösung X? Auch diese Sichtweise greift zu kurz.

Mit der Zeit wurde mir klar: Arbeitsweisen, Praktiken, Methoden oder Patterns sind nicht per se gut oder schlecht. Entscheidend ist fast nie das "Ob"", sondern das "Wie viel". Wie intensiv wenden wir etwas an? Wie konsequent? Und vor allem: Passt das zu unserer aktuellen Situation, zu unserem Produkt, zu unserem Team?

Im Kern geht es also darum zu erkennen, wovon wir mehr und wovon wir weniger brauchen, um sowohl das Produkt als auch den Entwicklungsprozess zu verbessern.

Aus diesen Überlegungen heraus habe ich gemeinsam mit meinem guten Freund Peter Götz (www.pgoetz.de) das Konzept der Balance entwickelt. Die zentrale Frage lautet dabei fast immer: Haben wir bei diesem Thema eine gute Balance – oder sollten wir nachsteuern?

Ein Beispiel: Code-Qualität

Schauen wir uns das Thema Code-Qualität an. Intuitiv würde man sagen: Mehr Code-Qualität ist immer besser.

Aber stimmt das wirklich?

Ab einem gewissen Punkt kann es kippen. Wenn man sprichwörtlich „in Schönheit stirbt“, wird man langsam. Entscheidungen dauern länger, Änderungen werden teuer, und die Time-to-Market leidet massiv. Softwareentwicklung wird dadurch schnell unverhältnismäßig teuer.

Es geht also nicht um maximale, sondern um angemessene Code-Qualität.

Peter hat dazu das Bild der absurden Extreme entwickletentwickelt:
Jedes Thema wird absurd, wenn man es nur weit genug treibt. Und jedes Thema hat dabei zwei Extreme – die beiden Enden einer Skala.
Beim Thema Code-Qualität könnten diese Extreme zum Beispiel so aussehen:

  • Extrem 1:
    Wir achten peinlich genau darauf, immer alle Clean-Code-Regeln einzuhalten. Code, der unseren hohen Standards nicht genügt, darf nicht eingecheckt werden.
  • Extrem 2:
    Um möglichst schnell zu sein, achten wir zunächst gar nicht auf Code-Qualität. Code wird erst dann verbessert, wenn es konkret Probleme gibt.
Die meisten Teams bewegen sich irgendwo zwischen diesen beiden Polen. Aber genau hier wird es spannend:
Wo genau stehen wir?
Und noch wichtiger: Ist diese Position für unser Team und unser Produkt aktuell die richtige?

Balance sichtbar machen

Um genau diese Diskussionen in Teams zu unterstützen, haben wir das Konzept der Balance-Skala entwickelt. Ziel ist es, gemeinsam zu reflektieren, ob man bei einem Thema gut unterwegs ist – oder ob Veränderungsbedarf besteht.

Dabei hilft die Visualisierung, die in der Grafik dargestellt ist. Jedes Teammitglied markiert seine persönliche Einschätzung auf der Skala.

  • Blau:
    Diese Person hat den Eindruck, dass das Team zu stark auf Code-Qualität fokussiert ist und dadurch möglicherweise zu langsam wird.
  • Grün:
    Diese Person empfindet den aktuellen Umgang mit Code-Qualität als ausgewogen und sieht keinen Änderungsbedarf.
  • Pink:
    Diese Person glaubt, dass Code-Qualität zu oft vernachlässigt wird und dass das Team hier stärker investieren sollte.
Schon dieser einfache Schritt schafft Transparenz. Plötzlich wird sichtbar, dass ein Thema sehr unterschiedlich wahrgenommen wird – obwohl alle im selben Team arbeiten.

Unterschiedliche Perspektiven verstehen

Im ersten Schritt geht es dabei ausdrücklich nicht darum, recht zu haben oder eine Position durchzusetzen. Entscheidend ist zunächst, ein gegenseitiges Verständnis für die unterschiedlichen Einschätzungen zu entwickeln.

Wie kann es sein, dass ein Teil des Teams glaubt, es werde zu viel in Code-Qualität investiert, während Andere den Eindruck haben, es sei zu wenig?

Vielleicht ist die blaue Markierung vom Product Owner, der erlebt, dass Erwartungen am Markt oder bei Stakeholdern nicht erfüllt werden können.
Und vielleicht stammt die pinke Markierung von einer Senior-Entwicklerin, die Sorge hat, später für Wartungsprobleme oder technische Altlasten verantwortlich gemacht zu werden.

Diese Transparenz ist enorm wichtig. Bleiben solche unterschiedlichen Sichtweisen unausgesprochen, führen sie im Alltag schnell zu schwelenden Konflikten. Entwickler werfen dem Product Owner vor, nur neue Features zu treiben und Qualität zu opfern. Der Product Owner wiederum empfindet die Entwickler als technikverliebt ohne dabei wirtschaftliche Rahmenbedingungen der Softwareentwicklung zu berücksichtigen.

Von der Diskussion zur Veränderung

Hat das Team einen gemeinsamen Konsens darüber gefunden, in welche Richtung sich die Balance verschieben sollte, lassen sich daraus konkrete Maßnahmen ableiten.

Nach einigen Wochen kann das Thema erneut bewertet werden, um zu prüfen, ob die getroffenen Maßnahmen die gewünschte Wirkung erzielt haben. Balance ist dabei kein statischer Zustand, sondern etwas Dynamisches, das sich mit Produkt, Team und Umfeld verändert.

Mehr als nur Code-Qualität

Code-Qualität ist dabei natürlich nur ein Beispiel. Nahezu alle Themen in der Softwareentwicklung lassen sich unter diesem Blickwinkel betrachten.

Wir haben eine kleine Auswahl solcher Themen zusammengestellt, die Teams als Inspiration nutzen können – und die sich jederzeit um eigene, teamspezifische Fragestellungen ergänzen lassen. So kann beispielsweise in jeder Retrospektive ein Thema gezielt auf seine Balance hin reflektiert werden.

Auch wenn man bei einem Thema einmal zu dem Schluss gekommen ist, dass die Balance stimmt, lohnt es sich, nach einiger Zeit erneut hinzuschauen. Rahmenbedingungen ändern sich – und mit ihnen die richtige Balance.

Fazit

Wir hoffen, mit dem Balance-Konzept ein einfaches, aber wirkungsvolles Werkzeug geschaffen zu haben. Eines, das Teams dabei unterstützt, gezielt Verbesserungen zu identifizieren, bewusste Entscheidungen zu treffen – und nicht zuletzt den einen oder anderen Konflikt frühzeitig zu entschärfen.
Denn am Ende gilt auch hier: Nicht das Extrem macht gute Software, sondern die richtige Balance.

Probiert es aus.

Stellt in eurer nächsten Retrospektive doch mal das Konzept der richtigen Balance vor. Wählt dann aus unserem Themenkatalog ein einzelnes Thema aus und diskutiert es mit Hilfe der Balance-Skala. Markiert eure persönlichen Einschätzungen, sprecht über die Unterschiede und leitet eine kleine, konkrete Veränderung ab.

Oft reicht schon diese gemeinsame Reflexion, um festgefahrene Diskussionen zu versachlichen und neue Perspektiven zu eröffnen.

Und bei der nächsten Retro schaut ihr dann, welches das nächste Thema ist, bei dem die Balance korrigiert werden sollte - entweder ein Thema von unserer Liste oder eines das euch ganz individuell gerade beschäftigt.