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 abarbeiten 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 Development Teams, ein „Done“ Inkrement des Produkts am Ende jedes Sprints abzuliefern. Das Development Team ist damit verantwortlich für die Qualität des Produktes. Hier ist nun genau die Frage, welche Qualität hier genau gemeint ist. Natürlich ist das Development-Team 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 Schuld aufzuhäufen. Auch für den Teilaspekt Fehlerfreiheit der „äußeren Qualität“ ist klar, dass das Development Team dafür die Verantwortung trägt. Wie sieht es aber mit anderen Aspekten wie Usability, Sicherheit oder allgemein mit dem Thema „Zufriedenheit des Anwenders“ aus? Kann ein Development Team 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 das Development Team eine Leidenschaft für das Produkt haben muss. Die Entwickler müssen zunächst das Interesse haben, ein gutes Produkt zu entwickeln, das die Anwender begeistert. 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, mit unserer 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, aber wenn das Development Team das Gefühl hat, 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 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, wenn 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. Um Kundenreaktionen kümmern sich andere Personen.
Hier ist mehr Kreativität gefragt, wie wir Kundenfeedback direkt bis in das Development Team hinein transparent machen können, ohne dass der Aufwand dafür explodiert. Dieses kann zum Beispiel im Sprint Review erfolgen oder durch Telemetriedaten die die Nutzung durch die Anwender visualisieren oder durch soziale Medien oder, oder. Dem Product Owner erwächst hier eine zusätzliche Aufgabe. Er muss die Leidenschaft für das Produkt bei den Entwicklern wecken, indem er die Ziele und Vision erklärt, indem er Success-Stories mit den Entwicklern teilt und auch indem er Fehlschläge oder Misserfolge direkt kommuniziert. 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?
Darüber hinaus ist auch wichtig, dass das Development Team an dieser Stelle einheitlich agiert. Sollten nur einzelne Teammitglieder diese Leidenschaft für das Produkt besitzen, 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. Ä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.
Aber letztendlich macht für mich das eine Gruppe von Personen erst zu einem Team – wenn sie ein gemeinsames Ziel haben, das sie verfolgen. Für das jeder sich engagiert und seinen Beitrag leistet. Wo wir möglicherweise unterschiedlicher Meinung sind, wie wir das gemeinsame Ziel am besten erreichen. Wo wir aber diese Meinungsvielfalt nutzen, um aus verschiedenen Optionen die besten auszuwählen. Und dieses gemeinsame Ziel eint am Ende des Tages Product Owner, Development Team und Scrum Master zu einem gemeinsame Scrum Team wo jeder seinen Beitrag leistet, damit wir gemeinsam ein Ziel erreichen können das keiner von uns alleine erreichen könnte.
Vielleicht lohnt es sich für sie auch einmal die Frage zu stellen, ob ihre Softwareentwickler Leidenschaft für ihr Produkt haben und wie sie diese evtl. wecken oder steigern können. Denn letztendlich ist diese Leidenschaft nichts Anderes als Motivation und wer möchte denn nicht motivierte Mitarbeiter? Leidenschaft und Motivation werden aber nur entstehen, wenn den Teams auch Gestaltungsmöglichkeiten eingeräumt werden und nicht alles von außerhalb vorgegeben ist.