Vor kurzem habe ich mit einem Team die interessante Frage aufgeworfen, ob Softwareentwickler Leidenschaft für das Produkt, das sie entwickeln benötigen oder ob Leidenschaft für Technologie wichtiger ist. Und wie wirkt sich diese Frage auf die Zusammenarbeit im Team aus? Hintergrund der Frage ist, dass viele Teams, mit denen ich zusammenarbeite, zwar Scrum nutzen, aber im Grunde genommen ihre Aufgabe im Sprint darin sehen, Backlog Items abzuarbeiten und am Ende des Sprints ein Inkrement an den Product Owner zu liefern. Bewusst oder unbewusst haben die Entwickler aber sehr wenig Kontakt mit Personen außerhalb des Scrum Teams. Und daraus ergibt sich die Frage, was ist das Ziel des Teams? Nach Definition des Scrum Guides ist das Ziel eines Scrum Teams, ein Done Inkrement des Produkts spätestens am Ende jedes Sprints zu erstellen. Die Developers sind dabei für die Qualität des Produktes verantwortlich. Hier ist nun die Frage, welche Qualität hier genau gemeint ist. Natürlich sind die Developers verantwortlich für die „innere Qualität“ des Produktes, also für die Wartbarkeit und Erweiterbarkeit des Codes und dafür, möglichst wenig technische Schulden aufzuhäufen. Auch für den Teilaspekt Fehlerfreiheit der „äußeren Qualität“ ist klar, dass die Developers dafür die Verantwortung tragen. Wie sieht es aber mit anderen Aspekten wie Usability, Sicherheit oder allgemein mit dem Thema „Zufriedenheit des Anwenders“ aus? Können Developers sich ausschließlich auf die technischen Aspekte fokussieren und das Generieren von Mehrwert dem Product Owner überlassen? Schließlich ist das genau die Aufgabe dieser Rolle. Der Product Owner wird oft ja auch als „Value Maximizer“ bezeichnet.

Nach der Diskussion mit dem Team bin ich überzeugt, dass Developers eine Leidenschaft für das Produkt haben müssen. Die Entwickler müssen zunächst das Interesse haben, ein gutes Produkt zu entwickeln, das die Anwender begeistert und auf das sie selbst stolz sein können. Die Erstellung von gutem Code allein darf hier nicht genügen. Hier kommt mir ein Vergleich mit einer Fußballmannschaft in den Sinn. Wenn alle Spieler nur das Ziel haben, technisch perfekt zu spielen und persönlich möglichst keine Fehler zu machen, wird das möglicherweise nicht ausreichen, das Spiel zu gewinnen. Wir brauchen also ein übergeordnetes Ziel. Im Fußball ist es, das Spiel zu gewinnen. In der Software ist es, unsere Software Anwender zu begeistern oder wenigstens zufrieden zu machen.

Damit übernehmen die Entwickler auch eine gewisse Kontrolle, dass der Product Owner einen guten Job macht. Er trifft zwar letztendlich die Entscheidungen darüber, was umgesetzt werden soll, aber wenn die Developers das Gefühl haben, dass die falschen Schwerpunkte gesetzt werden und dass Potenziale nicht ausgeschöpft werden, dann muss es darüber zumindest eine Diskussion geben. Diese wird aber nur dann stattfinden, wenn sich die Entwickler nicht als reine Umsetzer verstehen, die einen Arbeitsauftrag bekommen und diesen möglichst gut umsetzen. Sie müssen sich mit Leidenschaft für den Erfolg ihres Produktes einsetzen - also nicht nur für das Produkt des Product Owners. Diese Leidenschaft wird aber nur entstehen, wenn die Entwickler verstehen, wie ihre Software genutzt wird und wie damit ein Mehrwert beim Anwender generiert wird. Dafür ist zwingend erforderlich, dass sie direkt Feedback von Anwendern bekommen und selbst verstehen, wie auf bestimmte Funktionen reagiert wird. Und hier beginnt in vielen Unternehmen das Problem - das Entwicklungsteam wird weitgehend von der Welt „da draußen“ abgeschottet, damit sie in Ruhe entwickeln können. Die Kommunikation mit Anwendern und Kunden wird von anderen Personen übernommen. Oft sind die Entwickler damit auch gar nicht unglücklich.

Um bei den Entwicklern so etwas wie Anwenderempathie zu entwickeln, muss einiges investiert werden, eine Investition, die sich aber durch bessere Produkte, höhere Anwenderzufriedenheit und auch mehr Produktivität mehr als auszahlt. Das Ganze beginnt zunächst einmal mit dem Product Owner. Schafft sie oder er es, die Developers für die Produktvision zu begeistern? Dafür sind vor allem immer wieder auch Geschichten wichtig, Erlebnisse mit Kunden, Lob oder Kritik, was mit dem Produkt erreicht wurde und welche Opportunitäten sich momentan ergeben. Dieses kann zum Beispiel im Sprint Review erfolgen, wenn ja auch die Stakeholder anwesend sind. Darüber hinaus kann mit etwas mehr Kreativität auch das Kundenfeedback direkt bis zu den Developers transparent gemacht werden, ohne dass der Aufwand dafür explodiert. Auch Telemetriedaten können hier hilfreich sein, die die Nutzung durch die Anwender visualisieren. Die Leidenschaft für das Produkt wird bei den Entwicklern jedenfalls nur dann entstehen, wenn sie sich mit dem Produkt identifizieren, wenn sie an Erfolgen und Misserfolgen teilhaben können.

Und es ist sicher auch hilfreich, wenn Entwickler direkten Kundenkontakt haben. Warum also nicht einmal den Entwickler zu einer Inbetriebnahme oder einem größeren Update zum Kunden schicken? Warum nicht den Entwickler an einem Vertriebsgespräch teilnehmen lassen. Warum nicht immer wieder Entwickler Hotline-Support machen lassen, so dass sie die Probleme und Nöte der Anwender hautnah mitbekommen?

Dabei gibt es allerdings auch gewisse Herausforderung innerhalb des Teams. Sollten nur einzelne Teammitglieder diese Leidenschaft für das Produkt entwickeln, so sind soziale Spannungen bereits vorprogrammiert. Wenn ich das tollste Produkt aller Zeiten entwickeln möchte und ich gleichzeitig das Gefühl habe, dass der Kollege ein anderes Ziel hat und seine persönliche Agenda verfolgt, wird das nicht reibungslos funktionieren. Letztendlich zeichnet ein gutes Team gerade aus, dass es ein gemeinsames Ziel besitzt und sich alle Mitglieder des Teams für dieses Ziel engagieren und ihre persönlichen Präferenzen eher zurückstellen. Es gibt idealerweise Meinungsvielfalt innerhalb des Teams, jedoch nutzt das Team dies konstruktiv, um aus verschiedenen Optionen die besten auszuwählen. Und dieses gemeinsame Ziel eint am Ende des Tages Product Owner, Developers und Scrum Master zu einem gemeinsame Scrum Team in dem jeder seinen Beitrag leistet, damit das gemeinsame Ziel erreicht werden kann, das keiner alleine erreichen könnte.

Ähnlich wie bei dem zuvor genannten Beispiel aus dem Fußball gehört natürlich auch die Fähigkeit und die Kompetenz auf technischer Ebene dazu. Nur so werden wir in der Lage sein, das Spiel zu gewinnen bzw. ein gutes Produkt zu bauen. Aber es ist eben nicht unser primäres Ziel. Um ein gutes Produkt zu erstellen, gehört noch mehr dazu, als Technologie zu beherrschen. Die Technologie-Kompetenz ist letztendlich nur Mittel zum Zweck.

Vielleicht lohnt es sich für dich auch einmal die Frage zu stellen, ob die Leidenschaft für das Produkt vorhanden ist und wie diese evtl. ausgebaut werden kann. Denn letztendlich ist diese Leidenschaft nichts Anderes als Motivation und wer möchte denn nicht motivierte Teams? Leidenschaft und Motivation werden aber nur entstehen, wenn den Teams auch Gestaltungsmöglichkeiten eingeräumt werden und nicht alles von außerhalb vorgegeben ist.