…zumindest nicht in der Software-Entwicklung. Eine oft gehörte Beschwerde, und ich finde, sie stimmt tatsächlich!
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?