Soft skills

…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?

Ein sehr oft benötigter Soft Skill in Softwareprojekten hat mehrere Namen:

• Empathie
• Einfühlungsvermögen
• Theory of mind

Gemeint ist die Fähigkeit, sich über den mentalen Zustand eines anderen Individuums zutreffende Gedanken machen zu können. Wenn ich weiß, was mein Gegenüber denkt und fühlt, kann ich besser und erfolgreicher mit ihm kommunizieren oder erfolgreicher mit ihm konkurrieren, je nachdem.

Bisher galt dieser Skill als zutiefst menschlich und als einer der Hauptunterschiede zwischen Mensch und Tier. Seit einiger Zeit ist das nicht mehr ganz so sicher: Die Konrad-Lorenz-Forschungsstelle für Ethologie im österreichischen Almtal fand heraus, dass Kolkraben ein Verhalten an den Tag legen, aus dem man auf das Vorhandensein von Empathie schließen kann:

Kolkraben sind Aasfresser und konkurrieren z. B. mit Wölfen. Um diese zu schlagen, dürfen sie nicht dumm sein. Hat sich der Rabe die Beute gesichert, kann er nicht sofort alles fressen. Deshalb legt er Vorratslager an. Diese muss er gut verstecken, weil sich sonst andere Raben darüber hermachen. Wenn ein Rabe bemerkt, dass er beim Verstecken durch einen anderen Raben beobachtet wurde, wartet er, bis dieser weg ist und trägt dann sein eben verstecktes Futter woanders hin, offensichtlich in der Annahme, der andere Rabe wolle es ihm stehlen. Erfahrene Tiere schaffen sich dadurch einen Vorteil gegenüber den unerfahrenen, denen das Futter regelmäßig weggenommen wird.

Was lernen wir daraus? Wenn wir mit jemandem kommunizieren oder konkurrieren, sollten wir uns von ihm zunächst erzählen lassen, welche Lösungen er für typische Problemstellungen bisher gewählt hat. Anhand dieser Lösungen können wir in etwa erkennen, wie der Mitmensch “tickt” und unsere Art zu kommunizieren darauf abstimmen.

Die Frage “wie hast Du solche Dinge bisher behandelt?” kann bei neuen Themen, die im Projekt auftauchen, für einheitliches Verständnis und Empathie sorgen. Besonders gut funktioniert das mit zwei Leuten vor einem Whiteboard, doch davon ein andermal.

Can you define the word “confusion”? For me, it simply means that somebody is trying to do two (or more) different things at the same time.

Example: You work as an architect in a software project. Customers bombard you with new requirements every day. You have series of meetings with different groups of them in the same project, each meeting series has a different subject and of course, each group of customers to whom you talk thinks that their particular subject is the most important and urgent in the project.

When you walk into too many such meetings without thinking about it, your state of mind could more and more easily be described by “confusion”. (You will say: “OK, Matthias, everybody else knows that but: what should an architect do in that situation?”). More >

In recent projects, I encounter increasingly heterogeneous development teams. Some develop here, some next door, some in another city, some across the world in India. Sometimes, I watch one of those teams when they meet people from another team for the first time. In that kind of situation, they almost always question what the other team is doing, very often with little respect for the results the other team has achieved so far. You can really feel the borders between people in those situations.
Why is that so? More >

Mean trick: If someone tries to nail you down in a dialogue, simply ask him a few silly questions and he will be lost. This entry in a German psychology blog explains what happens when you do. Be sure, you will never hear such questions from me, by the way.