Softwareentwicklung ist in der Tat so komplex, dass sie Zielvereinbarungen schnell überholt und unwirksam macht. Die Ursache liegt in fehlender “requisite variety”.
W. Ross Ashby (Kybernetiker) hat 1956 das Law of Requisite Variety (Gesetz der notwendigen Vielfalt) formuliert, das auch hier anwendbar ist: “Nur Varietät kann Varietät zerstören”. Wenn ich ein komplexes System (z.B. einen lebenden Organismus oder eine Landschaft von durchzuführenden SW-Projekten) habe, so hat dieses System essenzielle Variablen, deren Werte innerhalb bestimmter Bereiche bleiben müssen, damit das System lebensfähig bleibt. Störungen von außen verändern die Werte dieser Variablen. Ein Regulator versucht, diese Störungen zu blockieren, so dass die essenziellen Variablen im Wertebereich bleiben. Dieses Blockieren ist eher ein Kompensieren und daher ein Akt der Kommunikation, der Regulator ist de facto ein Kommunikationskanal. Als solcher muss er (vom Prinzip her wie nach Shannon) eine mindestens so hohe Varietät haben wie die Störung, die eintrifft, sonst kann er sie nicht erfolgreich neutralisieren.
Was bedeutet das für das Thema Zielvereinbarungen? Die Störungen sind Einflüsse, die auf das System “Softwareprojekt” einwirken und den Satz essenzieller Variablen wie Termin, Qualität, Kosten, Umfang aus dem zulässigen Wertebereich treiben, wenn man nichts dagegen tut. Mitarbeiter sind wie Regulatoren, die mit Hilfe von Zielvereinbarungen “programmiert” werden sollen (ich übertreibe die kybernetische Sprechweise hier ein wenig). Das Problem ist nun, dass die Regulatoren mit angemessener Varietät auf die Vielfalt der Störungen reagieren müssen – die Zielvereinbarung kann diese Varietät jedoch nicht aufweisen, sonst müsste sie im Zielvereinbarungsgespräch bereits vorhergesehen werden, was nicht möglich ist. Sie ist also als “Programm” für den Regulator ungeeignet (zu geringe Varietät).
Besser ist es, auf Selbstorganisation der Mitarbeiter zu setzen, da diese Selbstorganisation eine ähnlich hohe Varietät entwickeln kann wie die der eintreffenden Störungen. Beispielsweise kann in einem Daily Scrum das Team kreativ die Optionen besprechen, mit denen auf eine eintreffende Störung (Fehler in einem verwendeten SW-Framework, Änderung einer Anforderung, usw.) reagiert werden kann. Alle Mitarbeiter werden zu Regulatoren, die sich selbst programmieren, ohne Zielvereinbarungen dazu zu brauchen. Die Kenntnis der Zusammenhänge über die essenziellen Variablen reicht aus. Die Führung muss diese Zusammenhänge allerdings liefern!
Führungskräfte sind die, die mit Komplexität umgehen können. Mitarbeiter sind die, die komplizierte Aufgaben lösen können. Wenn nun die Führung das Verständnis über die komplexen essenziellen Variablen des Systems herstellen kann, können die Mitarbeiter all die komplizierten Maßnahmen einleiten, die notwendig sind, um Varietät zur Neutralisierung der komplexen Störung aufzubauen – ganz ohne Zielvereinbarungen.
Frage an meine Blog-Leser: Wie regelt man dann das Thema “variabler Gehaltsanteil”, wenn einfache, messbare Ziele plötzlich wegen zu geringer Varietät ihre Nützlichkeit im Altag der Softwareentwicklung verlieren?
Diese Beiträge könnten Sie noch interessieren:
- Inhaltsorientiert führen – die “Möglichmacher”
- Kanban im Supermarkt [OOP 2011]
- Lösung ohne das zugehörige Problem?
- Selbstorganisation in kleinen Scheiben
- Fernseh-Feedback
Berater, Coach und Trainer für effektive Produktentwicklung
Hallo,
das ist in der Tat ein komplexes Thema. Als Personalleiter habe ich selbst erlebt, dass in agil arbeitenden Softwareentwicklungsteams “normale Zielvereinbarungen und Leistungsbeurteilungen” nicht klassisch funktionieren. Und schon gar nicht auf Jahresbasis, wie es in den meisten Unternehmen üblich ist. Erfahrungsgemäß verfügen die Personaler aber über zu wenig Know-how im Bereich Scrum, um adäquate Lösungen bieten zu können.
Grundsätzlich gibt es ja Ziele, nämlich je Sprint. Der ScrumMaster hat aber idealerweise die Ziele des Teams im Blick (und das Team selbst auch). Zusätzlich muss aber ein Weg gefunden werden, um über individuelle Ziele (Karriereentwicklungen, etc.) sprechen zu können.
Variable Gehälter damit zu verknüpfen halte ich für äußerst fragwürdig. In den meisten Unternehmen wird es falsch umgesetzt. Das Resultat: unzufriedene Führungskräfte und Mitarbeiter sowie eine überforderte Personalabteilung. In den meisten Fällen ist es für agile Teams am besten alle Bonussysteme abzuschaffen, mindestens aber alle individuellen Vergütungsanreize.
Weitere Anregungen gibt es in Kürze auch in dem Buch “Erfolgreich mit Scrum – Einflussfaktor Personalmanagement”, in dem ich mit Boris Gloger die Auswirkungen von agilen Methoden (beispielhaft Scrum) auf alle Personalprozesse aufgearbeitet habe.
Viele Grüße
André Häusling, Scrumjobs
Hallo Herr Häusling,
gut, dass Sie sich dieses Themas sogar in einem Buch annehmen! Scrum hat ja die Schnittstelle zwischen Product Owner, Scrum Master und Team sehr schön definiert – sehr praktisch für das Team vor allem!
Leider werden dadurch auch Belange der anderen berührt, insbesondere Linienverantwortliche und Personalabteilungen. Diese beiden einzubinden, erfordert mitunter den Bruch mit liebgewordenen Traditionen, z.B. der Meinung, man müsse Mitarbeiter extrinsisch motivieren (Zielvereinbarungen und Boni sind ja extrinsische Motivationsfaktoren).
Intrinsische Motivation, die im Mitarbeiter selbst entsteht, durch das Gefühl von Autonomie, von Sinnhaftigkeit der Arbeit und von der Möglichkeit, sich selbst immer weiter bis zur Meisterschaft entwickeln zu können, wird erst nach und nach von Führungskräften und Personalverantwortlichen verstanden. Sie passt hervorragend zum agilen Vorgehen – beides unterstützt und bedingt sich gegenseitig.
Dank also schon mal an Sie, falls Sie auch “in dieses Horn tuten”!
Schöne Grüße,
Matthias Bohlen
Hallo Herr Bohlen,
das deckt sich absolut mit meiner Ansicht. Leider ist es die Erkenntnis nicht neu, wird in der Praxis trotzdem selten umgesetzt. Es findet derzeit aber ein langsames Umdenken statt. Mal sehen, was wir bewegen können.
Viele Grüße
André Häusling