Diskussionen zwischen Entwicklung und Produktmanagement über technische Schulden sind richtig und wichtig, denn nicht jede technische Schuld muss direkt beglichen werden. Was relevant ist und was nicht, lässt sich tatsächlich am besten im gemeinsamen Gespräch ermitteln.

Es fällt aber immer wieder auf, dass sich auch erfahrene Entwickler schwer damit tun, technische Schulden gut zu kommunizieren und auch den Wert von Refactorings klar zu formulieren. Das Produktmanagement sieht hier oft nur die Kosten und nicht den Nutzen, was natürlich zu einer klaren Abwehrhaltung führt.

Also, wie können Entwickler technische Schulden gut kommunizieren? Aus unserer Sicht gibt es zwei Kernpunkte zu beachten:

1. Gegenseitiges Verständnis und Vertrauen aufbauen

Vertrauen ist die Basis für eine gute Zusammenarbeit innerhalb jedes (Scrum-)Teams [1, 2]. Fehlt das Vertrauen, ist jegliche Zusammenarbeit schwierig und zäh. Wie baut man daher Vertrauen auf?

Als erstes ist es wichtig die Situation des Gegenübers genau zu verstehen [3]. Jeder Mensch möchte gehört und verstanden werden. Für eine offene Kommunikation ist es daher wichtig, hier den ersten Schritt zu tun. Statt direkt zu versuchen, die eigenen Ideen durchzudrücken, hilft es zuerst die Position des Gegenübers genau zu hören und wirklich offen zu sein für dessen Sichtweise. Nur so kann man gemeinsam eine Lösung entwickeln, die die Bedürfnisse beider Seiten berücksichtigt.

Im nächsten Schritt beschreibt man das Problem und den Nutzen klar und einfach [3]. Auf dieser Basis kann man dann gemeinsam eine Lösung suchen. Das Ergebnis wird vermutlich etwas anders sein, als das, was man ursprünglich vor Augen hatte. Dennoch es ist ein Ergebnis, das von beiden Seiten verstanden und akzeptiert wurde. Das ist extrem viel wert, da dadurch ein gemeinsames Verständnis geschaffen und die Beziehung gestärkt wird.

Dabei ist es hilfreich klein anzufangen. Gerade wenn es starke Widerstände gibt, ist es für beide Seiten leichter das Risiko klein zu halten. Kleine Schritte können hier helfen Vertrauen aufzubauen, den Mehrwert des Abbaus von technischen Schulden zu verdeutlichen und Ängste und Befürchtungen auf beiden Seiten abzubauen.

2. Technische Schulden als Investition sehen und den Mehrwert des Umbaus klar verdeutlichen.

In manchen Situationen kann die Metapher der technischen Schulden recht hinderlich sein. Während sie auf der einen Seite die zusätzlichen Kosten der weiteren Entwicklung gut verdeutlicht, erschwert sie auf der anderen Seite die nutzenbasierte Diskussion. Daher ist es umso wichtiger in der Kommunikation mit dem Produktmanagement, die Bekämpfung von technischen Schulden als Investition zu beschreiben.

Konkret bedeutet das, klar den Mehrwert aufzuzeigen, den der Abbau technischer Schulden bringt und diesen mit der Abschätzung des Aufwands für den Umbau abzugleichen. Also Fragen zu beantworten, wie:

  1. Welche der geplanten Features lassen sich durch den Umbau einfacher umsetzen?
  2. Welche Features können dann überhaupt erst umgesetzt werden?
  3. Wie stark reduzieren sich Störfaktoren bei der täglichen Arbeit?

All das lässt sich abschätzen und auch mit einem Wert für das Unternehmen versehen. Dadurch entsteht eine Diskussion über den Wert des Umbaus im Vergleich zu anderen Anforderungen, mit der sich eine Priorisierung des Umbaus durchführen lässt.

Ist es auf der anderen Seite nicht möglich bzw. sehr schwer einen Nutzen für den Umbau zu benennen, liegt der Verdacht eines “goldenen Wasserhahns” nahe. Nur damit der Code etwas schöner wird oder das Architekturdiagramm ansprechender aussieht, lohnt sich ein größerer Umbau des Systems nicht [4]. Softwareentwicklung ist kein Selbstzweck und es gilt das Gleichgewicht zwischen Weiterentwicklung und dem Abbau technischer Schulden zu halten (Drei Missverständnisse über technische Schulden).

Ein positiver Nebeneffekt einer nutzenbasierten Diskussion über technische Schulden ist, dass die Umbauten mit dem größten Mehrwert für das Unternehmen automatisch die höchste Priorität bekommen. Sprich, wenn technische Schulden bearbeitet werden, sind es auch die mit dem größten Einfluss auf die tägliche Arbeit. Gute und relevante Ergebnisse schaffen auch hier Vertrauen.

Fazit

Eine gewisse Reibung zwischen Produkt Management und Entwicklung ist absolut normal und auch notwendig. Wenn die Diskussionen auf gegenseitigem Respekt und Vertrauen beruhen und das gemeinsame Ziel im Vordergrund steht, ist es auf dieser Basis möglich, den besten Weg für das Team und damit auch für das Unternehmen zu finden.

Referenzen

[1]: The Five Dysfunctions of a Team: A Leadership Fable, Patrick M. Lencioni

[2]: The Speed of Trust: The One Thing that Changes Everything, Stephen M. R. Covey

[3]: The 7 Habits of Highly Effective People, Stephen M. R. Covey

[4]: Software Architektur TV - Folge 37: Technische Schulden, Eberhard Wolff

Live Webinar: Softwareentwicklung skalieren, ohne sich im Wachstumsprozess aufzureiben

„Im Webinar wurden genau die Pain Points angesprochen, die in unserem Wachstum gerade auftreten. Bei stetig steigender Zahl an Mitarbeitern im Dev & Product Team mussten wir selbst feststellen, wie schwierig es ist, eine sinnvolle Struktur aufzubauen, die bei jedem das Maximum an Effizienz und Leistung hervorbringt und gleichzeitig zu einer gesunden Arbeitsatmosphäre führt.”
Pascal von Briel, Co-Founder & CPO @ exporto GmbH