Kolumne

DevOps Stories: Zuckerbrot und Peitsche – Die Gefahr von Belohnungen

Konstantin Diener

©s&s_media

Agilität, Management 3.0, New Work oder DevOps – all diese Bewegungen verändern die Art und Weise, wie Softwareentwicklung organisiert wird. Wenn man ihren Denkmustern und Ideen konsequent folgt, beeinflussen sie stark die Kultur des Unternehmens. Über solche Kulturveränderungen möchten wir gerne in dieser Kolumne berichten.

Kurz vor der Sprint Review ist das MusicStore-Team eifrig mit den letzten Arbeiten an den User Stories beschäftigt. Erik, der Product Owner, ist ebenfalls mit im Raum und versucht, die Entwickler zu unterstützen:

  • Lukas: „Ok, ich mache schnell noch die beiden Fixes für die Timeline und pushe das dann.“
  • Christian: „Ich werde mich darum kümmern, dass die letzten Macken aus der CI-Pipeline rauskommen.“
  • Erik: „Super!“
  • Julia: „Ich denke, ich bekomme die Animation im Slider noch bis zur Review rund.“

Martin hat als einziger im Team Kopfhörer auf, ein Buch neben seiner Tastatur liegen und werkelt in Stillarbeit vor sich hin.

  • Julia: „Können wir Martin jetzt stören?“
  • Christian: „Na, vor der Review ist definitiv keine Stillarbeitsphase! Martin …“
  • Martin: „Heh, was?“
  • Christian: „Wir sind gerade die letzten To-dos vor der Review durchgegangen …“
  • Martin: „Ach so.“
  • Christian: „Wie, ‚ach so’? Was hast du denn bis nachher noch auf der Liste?“
  • Martin: „Ich bin raus.“

Individuelle Ziele führen zu lokaler Optimierung

Wie oft gibt es in Unternehmen diese seltsamen Situationen? Mitarbeiter tun Dinge, die sowohl aus Sicht des Unternehmens als auch aus der Sicht ihres eigenen Teams vollkommen überflüssig erscheinen. Das Team ist mit dem konzentrierten Abschluss des Sprints beschäftigt und kann eigentlich jede helfende Hand gebrauchen, aber Martin sitzt an seiner Zertifizierung. Er hat mit seiner Führungskraft ein Ziel festgelegt, das nicht mit den kurz- und langfristigen Zielen seines Teams in Verbindung steht. Mit diesem Ziel ist aber vermutlich eine Bonuszahlung oder Gehaltsanpassung verbunden. Da sich Martin erst in einem halben Jahr (Halbjahresgespräch) wieder die Möglichkeit bietet, diese „Belohnung“ zu erreichen, lässt er sein Team mit dem Sprint-Abschluss allein.

DevOpsCon Whitepaper 2018

Free: BRAND NEW DevOps Whitepaper 2018

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

Individuelle Ziele für einzelne Mitarbeiter führen immer zu lokalen Optimierungen. Sinnvoller ist es, Ziele für Bonuszahlungen etc. auf Teamebene anzusetzen. Firmen wie Toyota treiben dieses Prinzip insofern auf die Spitze, als dort alle Mitarbeiter das gleiche Ziel haben: Die Gratifikation ist an den Unternehmenserfolg gekoppelt [1]. Von daher ist die Zielsetzung für das Team schon ein wenig sinnvoller aufgesetzt. Dessen Performance wird offenbar daran gemessen, ob sie die zugesagte Anzahl von Story Points einhalten können. Auf Mitarbeiterebene wäre dieses Ziel verheerend. Jeder Einzelne wäre nur darum bemüht „seine Tasks“ umzusetzen. Ein solches Ziel erstickt Kooperation im Keim.

Tatsächlich ist dieses Ziel auf Teamebene aber nur wenig besser. Wenn das Team weiß, dass es an dieser Metrik gemessen wird, wird es beispielsweise aufhören, Mitgliedern aus anderen Teams zu helfen. Diese Hilfe wäre zwar für das Unternehmen sinnvoll, würde aber das Ziel gefährden, die zugesagten Story Points zu „liefern“. Hierbei handelt es sich auch wieder um eine lokale Optimierung.

Produktivitätsmetriken sind in der Softwareentwicklung kontraproduktiv

Die Metrik ist aber noch aus einem anderen Grund gefährlich – wie alle Produktivitätsmetriken misst sie zum einen das Falsche und lässt sich zum anderen sehr leicht austricksen. Julia hat ja direkt die Idee, dann einfach weniger Stories in den Sprint zu ziehen, um im Sinne der Metrik gut auszusehen.

Larman und Vodde [1] haben dazu ein anderes schönes Beispiel. Sie diskutieren Lines of Code (LOC) als Produktivitätsmetrik. Zunächst nehmen sie an, dass eine hohe Anzahl von LOC eine gute Performance bedeutet. Diese Metrik wird dazu führen, dass Copy-Paste-Programmierung und Code-Duplication stark zunehmen werden. Also wäre es vielleicht eher erstrebenswert, eine bestimmte Funktionalität mit möglichst wenigen LOC umzusetzen. Vermutlich hat jeder Entwickler schon einmal Code gesehen, der dieses Ziel verfolgte. Meist ist solcher Code völlig unleserlich. Larman und Vodde weisen in diesem Zusammenhang auf den sogenannten Obfuscated C Code Contest hin, der dieses Mantra zur Perfektion erhoben hat.

Produktivitätsmetriken haben den Nachteil, dass sie den Output eines Teams messen. In der Softwareentwicklung sagt der Output aber in der Regel nichts darüber aus, ob die Arbeit des Teams erfolgreich ist. Selbst wenn das MusicStore-Team in jedem Sprint die geplante Anzahl an Story Points umsetzt und sich möglicherweise sogar von Sprint zu Sprint steigert, sagt das noch nichts darüber aus, ob die Benutzer die neuen Funktionen überhaupt benutzen. Was in der (Produkt-)Entwicklung eigentlich interessiert, ist nicht der Output, sondern der Outcome [2]. Der Name sagt es schon, Produktivitätsmetriken sind zur Messung des Outcomes ungeeignet.

Belohnungen und Bestrafungen von Wissensarbeiten töten intrinsische Motivation

Produktivitätsmetriken entspringen einer wirtschaftlichen Denkweise, die stark durch die Industrialisierung geprägt ist. Arbeit besteht hierbei fast ausschließlich aus Tätigkeiten, die Daniel Pink in seinem Buch „Drive“ als „algorithmisch“ bezeichnet [3]. Bei der Produktion von Industriegütern müssen dieselben Tätigkeiten immer wieder mit hoher Geschwindigkeit und hoher Qualität ausgeführt werden. Die Produktivität drückt sich also in der Anzahl fehlerfrei hergestellter Werkstücke in einer gewissen Zeitspanne aus (Stückzahl). Es gibt einen gewissen Richtwert, welche Stückzahl von einem Arbeiter erwartet wird. Liegt der für ihn gemessene Wert darunter, wird er bestraft, liegt er darüber, belohnt. All diese Maßnahmen dienen dazu, die Stückzahl zu maximieren.

In der Softwareentwicklung gibt es aber kaum algorithmische Tätigkeiten. Sie besteht zum Großteil aus heuristischen. Bei diesen Tätigkeiten funktioniert das klassische Vorgehen aus Bestrafungen und Belohnungen nur scheinbar. Tatsächlich zerstört es langfristig sogar die intrinsische Motivation der Mitarbeiter. Bei algorithmischen Tätigkeiten kann die Motivation nicht untergraben werden, weil die meisten Menschen für diese Art von Beschäftigung gar keine haben, sagt Pink.

Zunächst einmal führen Belohnungen und Bestrafungen bei heuristischen Tätigkeiten zu Frustration, weil wir Menschen durch diese „Wenn-Dann-Belohnungen“ einen Teil unserer Eigenständigkeit aufgeben [3]. Eigentlich geht es uns dabei auch nicht um die zu erledigende Aufgabe oder das zu Grunde liegende Ziel, sondern nur um die Belohnung. Martin möchte den Bonus oder die nächste Gehaltsstufe erhalten. Es geht ihm vermutlich weniger um das Interesse an der Programmiersprache, die er schnell noch lernt. Er lernt sie vermutlich auch nur gerade ausreichend, um das Zertifikat zu erhalten und damit den Schlüssel zur Belohnung.

DevOps Stories

„Agilität“, „Management 3.0“, „New Work“ oder „DevOps“ – all diese Bewegungen verändern die Art und Weise, wie Softwareentwicklung organisiert wird. Und wenn man ihren Denkmustern und Ideen konsequent folgt, beeinflussen sie stark die Kultur des Unternehmens. Über solche Kulturveränderungen berichtet Konstantin Diener (CTO von cosee) in dieser Kolumne. Doch wie lassen sich Erfahrungen zu Veränderungen der Unternehmenskultur transportieren? Er ist der Meinung, so wie die Menschheit seit Jahrtausenden Erfahrungen transportiert: durch Geschichten, den DevOps Stories.

Gehen wir mal davon aus, dass Martin – wie die meisten Entwickler – eigentlich gerne neue Programmiersprachen lernt. In der Vergangenheit reichten ihm immer der Spaß am Lernen und die Möglichkeiten der neuen Sprache als Belohnung. Wenn er in Zukunft für das Erlernen einer neuen Sprache keine Belohnung bekommt, wird er es sich zweimal überlegen, ob er Zeit in diese Tätigkeit investiert. Der Bonus oder Gehaltsschritt hat seine intrinsische Motivation geschwächt oder zerstört.

Aber warum ist das so? Unser Gehirn reagiert auf finanzielle Belohnungen mit der Ausschüttung von Dopamin. Es reagiert also ähnlich wie bei der Einnahme von zum Beispiel Koffein, Kokain, Nikotin oder Amphetaminen. Die finanzielle Belohnung steigert damit kurzfristig die Leistung. Genau wie die genannten Stoffe führt sie aber zu einem Abnutzungseffekt. Martin möchte in Zukunft nicht nur für jede neu erlernte Programmiersprache, sondern auch für andere Dinge belohnt werden. Auch für diese anderen Dinge zerstört die Belohnung die intrinsische Motivation („Warum sollte ich es einfach so tun, wenn ich auch Geld dafür bekommen könnte?“). Seine Führungskraft muss ihn künftig also immer mit Belohnungen locken. Er gerät in eine Abwärtsspirale. Daniel Pink beschreibt in seinem Buch Beispiele, in denen Probanden die Lust an Aufgaben verloren haben, sobald man sie für deren Lösung bezahlt hat. Außerdem beschreibt er ein Experiment, in dem Künstler bezahlte und unbezahlte Arbeiten ausgeführt haben. Die bezahlten taten genau das, wofür sie eine Vergütung erhielten und die unbezahlten schufen wesentlich bessere Kunstgegenstände.

Nach Ende des Sprints hat Ruben, der Scrum Master des Teams, mit den Führungskräften der Teammitglieder gesprochen und sie von der Abschaffung von individuellen Zielen im Zusammenhang mit finanziellen Belohnungen überzeugt. Mit den Stakeholdern aus dem Businessboard wird es einen Workshop geben, um gemeinsam eine sinnvollere Lösung für die Darstellung des Produktstatus zu erarbeiten.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: