Kooperation in Softwareprojekten! Lohnt sich das? (Teil 1)

Spannungen zwischen IT- und Fachseite. Wer jemals in einem Softwareprojekt gearbeitet hat kennt sie zur Genüge. Vorteilhaft sind sie nie. Jedenfalls nicht wenn man das Projekt als Ganzes betrachtet. Im Gegenteil: Wenn beide Seiten nicht in der Lage sind vernünftig zusammenzuarbeiten verlieren fast alle Beteiligten. Die einen verlieren Geld, andere ihre Nerven. Viele verlieren beides.

Warum entstehen diese Spannungen immer wieder? Eine einfache Antwort gibt es nicht. Vielleicht liegt es daran, dass beide Parteien unterschiedliche Ziele verfolgen und deshalb sehr egoistisch handeln.

Gehen wir einfach davon aus, dass dies so ist, und wir es wirklich mit Egoisten zu tun haben. Diese haben nur ihr eigenes Ziel vor Augen und es ist ihnen dabei egal ob die andere Partei auf der Strecke bleibt oder nicht.

Ich möchte im Folgenden darstellen, dass es sich gerade in einer Welt voller Egoisten fast immer lohnt, mit der anderen Partei zu kooperieren. Auch wenn dies zunächst wie ein Widerspruch klingt, es ist keiner.

Beginnen wir mit einem Paradoxon, dem Gefangenendilemma.

Spieltheorie am Beispiel des Gefangenendilemmas

Das Gefangenendilemma ist ein zentraler Bestandteil der Spieltheorie. Bei diesem Paradoxon handelt es sich um ein klassisches symmetrisches „Zwei-Personen-Nicht-Nullsummen-Spiel”, das in den 1950er Jahren formuliert wurde. Es ist schnell erklärt.

Zwei Personen, nennen wir sie Jens und Wolfgang, sitzen in Untersuchungshaft. Sie werden beschuldigt einen Bankraub begangen zu haben. Die Höchststrafe hierfür beträgt fünf Jahre. Der Untersuchungsrichter lässt beide vorführen und bietet jedem einen Handel an.

Wenn einer gesteht und somit seinen Partner mitbelastet, kommt er ohne Strafe davon – der andere muss die vollen fünf Jahre absitzen. Entscheiden sich beide zu schweigen, bleiben nur Indizienbeweise, die aber ausreichen, um beide für zwei Jahre einzusperren. Gestehen aber beide die Tat, erwartet jeden eine Gefängnisstrafe von vier Jahren.

Umgehend nach dem Angebot des Richters werden beide abgeführt. Sie kommen sofort in Einzelzellen und haben keine Möglichkeit mehr sich abzustimmen.

Jens sitzt in seiner Zelle und denkt sich: Falls Wolfgang gesteht, reduziere ich mit meiner Aussage meine Strafe von fünf auf vier Jahre; falls er aber schweigt, dann kann ich mit meiner Aussage meine Strafe von zwei Jahren auf Null reduzieren! Er kommt zu dem Entschluss auf jeden Fall zu gestehen.

Jens entscheidet dieses Problem zunächst aus seiner alleinigen Sicht heraus. Er lässt Wolfgangs Verhalten außen vor. Spieltheoretisch handelt er dominant.

Betrachten wir jetzt aber Jens und Wolfgang als Gruppe, ergibt sich ein anderes Bild: Würden beide nämlich schweigen gingen sie insgesamt nur für vier Jahre ins Gefängnis. Jede andere Kombination führt aber zu längeren Strafen, nämlich fünf bzw. acht Jahre Haft. Die bessere (Gruppen-) Strategie lautet also: Nicht aussagen. Diese Strategie ist aber riskant und kann durch „Verrat“ leicht ausgehebelt werden.

Fassen wir zusammen: Die erste von Jens vorgenommene Analyse der Situation erscheint vernünftig und verleitet ihn dazu zu gestehen. Ist Wolfgang ebenso vernünftig ist das Ergebnis für beide als Gruppe betrachtet aber schlecht. Das bessere Ergebnis könnten beide erreichen, indem sie schwiegen, also kooperierten. Diese Strategie ist wie gesehen aber anfällig für Verrat.

Die Strategiekombination (Gestehen/Gestehen) ist übrigens ein Beispiel für ein Nash-Gleichgewicht. Es wurde von John Forbes Nash Jr. in den 50er Jahren entdeckt. Der eine oder andere kennt ihn vielleicht aus dem Film A Beautiful Mind.
Kommen wir zurück zu unserem Softwareprojekt. Das Gefangenendilemma zeigt, dass Kooperation theoretisch für beide Parteien eine gute Strategie darstellt, auch wenn sie eigentlich nur auf ihr eigenes Wohl bedacht sind. Sie setzt jedoch ein großes Maß an Vertrauen voraus und kann durch hinterhältige Machenschaften leicht durchkreuzt werden.

Ist eine kooperative Strategie also empfehlenswert und praxistauglich? Dazu mehr im zweiten Teil von Kooperation in Softwareprojekten! Lohnt sich das?

Meine Links zum Thema bei del.icio.us:

Blogged with Flock

Tags:

Kooperation in Softwareprojekten! Lohnt sich das? (Teil 2)

Im ersten Teil dieses Beitrages wurde das Gefangenendilemma vorgestellt. Es zeigt, dass es Situationen gibt, in der die jeweils beste Strategie vom Handeln anderer Personen abhängt. Die Frage, ob ich kooperativ sein oder besser entschlossen meinen eigenen Vorteil suchen soll, lässt sich demnach nicht aus der eigenen subjektiven Sicht allein heraus beantworten.

Wie soll man sich jetzt aber im echten Leben verhalten? Ist das Gefangenendilemma überhaupt in der Praxis anwendbar?

Die letzte Frage kann man eindeutig mit Ja beantworten. Es gibt viele Situationen, die mit dem Gefangenendilemma vergleichbar sind oder waren. So stellte man im ersten Weltkrieg fest, dass in den Schützengräben viele Soldaten auf Kooperation setzten, anstatt sich gegenseitig zu vernichten. So wurden an bestimmten Tageszeiten Feuerpausen eingelegt oder man schoss einfach in die Luft.

Den Soldaten auf beiden Seiten, die täglichem Feuer ausgesetzt waren, wurde nämlich eines sehr schnell klar: Wenn die eigene Seite eine Stellung bombardierte und fünf Feinde tötete, dann antwortete die Gegenseite mit einer Salve und tötete dadurch fünf eigene Kameraden. Spieltheoretisch ist das kein Problem. Im echten Leben dagegen schon.

Verbrüderungen dieser Art waren keine Einzelfälle. Die Generalität begegnete diesem Phänomen mit drastischen Strafen. Wer mit dem Feind kooperierte, wurde erschossen. Doch selbst diese Maßnahme beendete die Kooperation nicht. Erst als man begann, kooperative Truppenteile zu verlegen und an anderen Frontabschnitten einzusetzen, hörten die Verbrüderungen auf. Die Soldaten wurden mit neuen Feinden konfrontiert von denen sie nicht wussten, ob sie kooperieren würden oder nicht. Das Gefangenendilemma begann so zu sagen immer wieder von neuem. Anschauen kann man sich das ganze im Film Joyeux Noël von Christian Carion.

An dieser Stelle sei angemerkt, dass es einen großen Unterschied gibt, wie oft das Gefangenendilemma wiederholt wird. Beim ersten Mal kenne ich meinen Gegner überhaupt nicht. Beim zweiten Mal weiß ich jedoch, wie er sich in der Vergangenheit verhalten hat, und ich kann meine Schlüsse daraus ziehen. Diese Variante nennt sich iteratives Gefangenendilemma.

Zurück zur Frage, wie man sich im echten Leben verhalten sollte. Die geschilderten Verbrüderungen legen ja die Vermutung nahe, dass Kooperation sehr gut funktioniert. Ganz so einfach ist es aber nicht!

Man stelle sich nur einmal vor, wie leicht es wäre, eine auf Kooperation eingestellte Kompanie von Soldaten zu besiegen. Die eigenen Verluste wären nahezu bei null, die des Gegners wären maximal. In der ursprünglichen Geschichte ist dies die Kombination Freispruch und 5 Jahre Gefängnis.

Um herauszufinden, welche Strategie die beste für das iterative Gefangenendilemma ist, veranstaltete Robert Axelrod, ein US-amerikanischer Politikwissenschaftler, ein Computerturnier. Hierzu lud er Im Jahr 1980 die damals bekanntesten Spieltheoretiker ein. Jeder von ihnen entwickelte eine individuelle Strategie für das Gefangenendilemma, die dann jeweils in ein einfaches Computerprogramm umgesetzt wurde. Jedes Programm trat dann in genau 200 Zügen gegen alle anderen und auch gegen sich selbst an.

Die teilnehmenden Programme verfolgten von Beginn an sehr unterschiedliche Strategien. Einige waren sehr einfach, andere basierten auf komplexen statistischen Verfahren. Manche waren kooperativ, also „nett“, andere setzten auf Verrat, waren also „nicht nett“.

Die Siegerstrategie war eine echte Überraschung. Sie stammte von Anatol Rapoport, einem Professor für Psychologie und Mathematik an der University of Toronto, und gehörte zu den einfachsten Programmen im Feld. Sie hieß Tit for tat, auf Deutsch „Wie du mir so ich dir“.

Tit for tat gehörte zu den „netten“ Programmen. Es kooperierte bei jeder ersten Begegnung und richtete sein weiteres Verhalten danach aus, wie sich der andere bei dieser Begegnung benahm. War der Gegner kooperativ, war auch Tit for tat kooperativ. War der Gegner es nicht, sah auch Tit for tat keine Veranlassung „nett“ zu sein. Das vorangegangene Verhalten des Gegners wurde also kopiert. Überrascht von diesem Ergebnis wurde ein zweites, größeres Turnier veranstaltet. Doch auch hier hieß der Sieger Tit for tat.

Insgesamt wurden fünf Turniere gespielt. Bei fast allen gewann Tit for tat. Soweit ich weiß, gab es zum Ende eine bessere Strategie, die jedoch auf der Grundidee von Tit for tat basierte. Nachzulesen ist das ganze übrigens in Axelrods Buch, Die Evolution der Kooperation.

Was aber bedeuten die Ergebnisse dieses Turnier für unser Ausgangsproblem. Führt Kooperation nun automatisch zum Erfolg?

Kooperative Strategien sind meiner Ansicht nach immer dann erfolgreich, wenn wir uns in Situationen befinden, in denen Menschen sich zunächst freundlich begegnen. Leider gilt dies nicht immer für Softwareprojekte. Sehr oft sind Projekte sehr zerfahren und ihre Protagonisten alles andere als freundlich zueinander. Wer nichtsdestotrotz gleich von Beginn an versucht, auf Kosten Anderer zu leben, wird im Einzelfall vielleicht erfolgreich sein. Auf Dauer aber nicht.

Der Erfolg von Tit for tat zeigt auch deutlich, dass unkooperatives Verhalten auf keinen Fall toleriert werden darf. So standen alle rein kooperativen Programme in Axelrods Turnier von Anfang an auf verlorenem Posten. Mit anderen Worten: Wer sich ständig über den Tisch ziehen lässt, ist selber Schuld.

Auf der anderen Seite verdeutlicht Tit for tat aber auch, wie wichtig es ist zu verzeihen. Wer einen Fehler einsieht und wieder kooperativ ist, verdient eine immer eine zweite Chance.

Prima, dann haben wir es ja jetzt: Wie du mir so ich dir und alles ist in Butter!

Nun ja, ganz so einfach ist es nicht. Zugegeben, Tit for tat ist eine gute Wahl aber lange nicht die Beste. Aus meiner Sicht hat diese Strategie einen entscheidenden Fehler.

Welchen? Das erfahrt ihr im dritten und letzten Teil von Kooperation in Softwareprojekten! Lohnt sich das?.

 

Meine Links zum Thema bei del.icio.us:

Blogged with Flock

Tags:

Kooperation in Softwareprojekten! Lohnt sich das? (Teil 3)

Im zweiten Teil dieses Beitrags wurde eine sehr erfolgreiche kooperative Strategie vorgestellt: Tit for tat oder auf Deutsch Wie du mir so ich dir.

Tit for tat zeigt uns, dass es sich durchaus lohnt, kooperativ zu sein, um seine eigenen Ziele zu erreichen. Zumindest sollte man am Anfang kooperativ sein und nicht gleich alle Kollegen vor den Kopf stoßen. Bei Leuten, die nicht kooperativ sind, einem also nicht nett begegnen, ist eine andere Strategie angesagt – Vergeltung. Am Ende zeigt sich Tit for tat aber wieder versöhnlich. Denn man sollte in der Lage sein, zu verzeihen und beim nächsten Zusammentreffen wieder nett zu einander sein.

Ich finde diese Strategie als Grundlage sehr gut. Auf jeden Fall sollte man in Softwareprojekten zunächst jedem Kollegen seine Chance geben. Und auf gar keinen Fall darf man kooperative Kollegen hintergehen. Durch die Beachtung dieser beiden Grundsätze bin ich in der Lage, ein kooperatives Arbeitsklima aktiv zu gestalten.
Axelrod, der Veranstalter des Computerturniers, spricht in diesem Zusammenhang von Reformern, d.h. Personen die Umgebung und damit die Spielregeln schaffen.

Eben diese Spielregeln sind von entscheidender Bedeutung. Wir mussten immer wieder feststellen, dass fehlende Spielregeln in Softwareprojekten zu fatalen Ergebnissen führen. Leider kann man solche Spielregeln nicht einfach festlegen, man muss sie vorleben. Also selber Vorbild sein.

Die wichtigste Regel lautet dabei: Bestrafe jeden Verrat in aller Konsequenz!

Dolchstoß

Diese Regel ist wie wir gesehen haben in Tit for tat fest verankert. Sie führt bei „nicht netten“ Kontakten evtl. zu einem Strategiewechsel. Beachte ich diese Regel nicht, werde ich immer wieder mit „nicht nettem“ Verhalten konfrontiert werden. Dies gilt für Einzelpersonen gleichermaßen wie für Gruppen.

Ich sage an dieser Stelle bewusst nicht, dass die Bestrafung von Verrat automatisch dazu führt, dass sich mein Gegenüber beim nächsten mal anders verhält. Das muss nämlich nicht so sein. Aber dazu später mehr. Sollte ich jedoch auf eine Bestrafung verzichten, zeige ich meinem Gegenüber, dass seine „nicht nette“ Strategie erfolgreich ist.

Nur meinem Gegenüber? Nein, andere Personen und Gruppen merken sehr schnell, wie es um mich bestellt ist. Sie fangen an zu lernen. Sie lernen, dass „nicht nette“ Strategien in diesem Projekt zum Erfolg führen. Haben erst genügend Projektteilnehmer diese Erfahrung gemacht, versagt übrigens auch Tit for tat, die Ausgangsstrategie.

Mit anderen Worten: Befinden sich erst genügend – und jetzt wechseln wir das Wort – „böse“ Spieler im Projekt, ist Hopfen und Malz verloren. Mittelfristig verlieren in dieser Situation alle. Die Schuld hierfür wird der jeweils anderen Partei zugeschrieben. Man merkt nämlich meistens gar nicht, dass man selber böse ist.

Bitte achtet daher immer auf die Spielregeln in euren Projekten. Dies gilt für alle Teilnehmer und Rollen, also Entwickler, Architekten, Projektleiter etc. Ich fasse diese Spielregeln noch einmal kurz zusammen:

– Verrate nicht als erster,
– Erwidere sowohl Kooperation als auch Verrat,
– Sei nicht neidisch,
– Sei nicht zu raffiniert.

Zur letzten Spielregel noch ein Wort. Wenn ich raffiniert bin, verschleiere ich meine Absichten. Dies im Guten wie im Bösen. Meine Raffinesse erschwert es damit anderen Personen, mich richtig einzuschätzen. Auf diese Art und Weise entstehen die berühmten Missverständnisse, die, wenn man sie nicht schnell aus der Welt schafft, ebenfalls zu schwerwiegenden Problemen im Miteinander führen können.

Vorsicht!

Unsere Ausgangsstrategie, Tit for tat, hat meiner Meinung nach jedoch einen schweren Fehler. Dieser liegt im Verzeihen.

Sicherlich ist es wichtig einen Fehler zu verzeihen, wenn die andere Seite einsieht, dass sie einen Fehler begangen hat und diesen auch bereut. Doch was geschieht, wenn dies häufiger passiert? Was mache ich, wenn die andere Seite Fehler nur eingesteht, weil sie meine Strategie kennt und damit genau weiß, dass der nächste Verrat wieder zum Erfolg führen wird?

Das Problem ist, dass es sehr viele Menschen gibt, die gelernt haben, dass sich Betrug und Intrige auszahlen. Egal ob raffiniert oder nicht, wer einmal gelernt hat, sich so zu verhalten wird schwerlich davon Abstand nehmen. Für solche Personen gilt die Regel zu verzeihen nicht. Ein derartiges Verhalten darf man nicht tolerieren. Am besten man isoliert diese Personen oder entfernt sie ganz aus dem Projekt. Dabei darf es keine Rolle spielen, wie qualifiziert ein solcher Jemand ist.

Fazit:

Kooperation ist für mich ich die einzige Strategie, die in Projekten zum Erfolg führt. Man erreicht sie jedoch nicht, in dem man selber nur kooperativ ist. Im Gegenteil, manchmal muss man selber böse sein, damit die Spielregeln gewahrt bleiben und Kooperation eine Chance hat.

 

Meine Links zum Thema bei del.icio.us:

Blogged with Flock

Tags:

Gute Führung mit Stil

Wenn man sich mit dem Thema Unternehmensführung befasst, stellt man sehr schnell fest, dass viele Konzepte schon einige Jahre auf dem Buckel haben. Für viele Menschen ist solches Wissen veraltet und nicht mehr auf die Praxis anwendbar. Schließlich hat sich die Welt seit den 60er Jahren entscheident verändert. Damals begann man zum ersten mal sehr intensiv über das Thema Management nachzudenken.

Aber ist denn richtig, dass sich die Welt seit dieser Zeit entscheident verändert hat? Ich denke nicht. Die grundlegenden Probleme der Arbeitswelt bestanden damals wie heute. Die Lösungsansätze, die vor 50 Jahren gefunden wurden sind nicht veraltet. Sie sind vielmehr elementar. Kleines Beispiel gefällig:

“Enterprises are paid to create wealth, not to control costs.”

Gem. dieser Aussage von Peter Drucker geht es für ein Unternehmen primär um den Aufbau von Vermögen, nicht an erster Stelle die Senkung von Kosten. Dieser Grundsatz wurde in letzter Zeit leider im wahrsten Sinne des Wortes mit Füßen getreten. Aber das ist eine andere Geschichte.

Managerial Grid

Ich möchte im folgenden ein etwas angestaubtes Führungsmodell vorstellen. Es handelt sich hierbei um das Konzept des „Managerial Grid“ im deutschen auch oft als „Verhaltensgitter“ bezeichnet. Es beruht auf Forschungsergebnissen der US-amerikanischen Ohio State University und wurde 1964 im Rahmen eines Führungstrainings für das Unternehmen Exxon Mobil von Robert R. Blake und Jane Mouton entwickelt.

Das Verhaltensgitter besitzt zwei Achsen auf denen zwei grundsätzliche Orientierungsgrößen abgetragen werden. Die waagerechte Achse steht für die vorrangige Ausrichtung an den Ergebnissen von Arbeit. Die senkrechte Achse stellt im Gegensatz hierzu den Menschen in den Mittelpunkt und wird deshalb auch als sozioemotionale Dimension bezeichnet.

In Kombination der beiden Achsen ergeben sich nun mehrere mögliche Führungsstile. Die klassischen Einteilung kennt 81 Felder, von denen aber nur fünf besonders betrachtet werden müssen.
Im ersten Feld 1.1 kümmert sich ein Vorgesetzter weder um seine Mitarbeiter noch um ihre Arbeitsergebnisse. Er tut als eigentlich gar nichts! Und deshalb müssen wir über diesen Stil auch nicht weiter reden. Eine sehr hohe Betonung der Arbeitsergebnisse bei gleichzeitig geringem Interesse an den eigenen Mitarbeitern stellt das Feld 9.1 dar. Man spricht auch vom „Befehl-Gehorsam-Management“. Mitarbeiter sind in diesem Stil ausschließlich als Mittel zum Zweck zu sehen. Selbstverwirklichung und Spaß gibt es hier nicht.

ausschließliche Ausrichtung an Arbeitsergebnissen

Das genaue Gegenteil finden wir im Feld 1.9. Hier stehen die Arbeitsergebnisse absolut im Hintergrund. Wichtig ist es, dass alle Freude bei der Arbeit haben. Man befindet sich sozusagen ständig im Country Club. Keine Frage, dass man hier lieber arbeitet als im ersten Beispiel, oder?

Ausschließliche Ausrichtung an Mitarbeiterzufriedenheit

Im Feld 9.9 versucht man beide Dimensionen gleichermaßen zu betonen. Also gute Arbeitsergebnisse zu erzielen und gleichzeitig ein tolles Klima aufrechtzuerhalten.

Dieser Zustand ist leider nur schwer zu erreichen. Deshalb gibt es ein weiteres Feld 5.5, in dem man beide Dimensionen kombiniert und einen Ausgleich zwischen Arbeitsergebnissen und Mitarbeiterbedürfnissen herstellt. Die Kombinationen 5.5, 5.9, 9.5 und 9.9 sind nach Blake & Mouton geeignete Führungsstile.

Ganz einfach oder?

Leider nicht. Die beiden Extremformen 9.1 und 1.9 kommen immer wieder in der Praxis vor. Insbesondere das „Befehl und Gehorsamsmodell“ wird in vielen Softwareprojekten bevorzugt. Manche Menschen beherrschen eben nur eine der beiden Varianten. Und damit komme ich zur Kernaussage dieses Modells.

Man muss in der Lage sein auf beiden Achsen zu operieren.

Denn den idealen Führungstil gibt es nicht. Führung ist situationsabhängig und nicht umgekehrt.

Trotz allem sind mir die Leute lieber, die ihre Mitarbeiter mehr schätzen als ihre Ergebnisse. Sie tragen einer wichtigen Veränderung der heutigen Zeit Rechnung. Hierzu noch einmal ein Zitat von Herrn Drucker. Der hats schon früher gewusst.

“Altogether, an increasing number of people who are full-time employees have to be managed as if they were volunteers. They are paid, to be sure. But knowledge workers have mobility. They can leave. They own their ‘means of product,’ which is their knowledge.”

Wenn man gute Leute nicht verlieren will, sollte man sie schätzen lernen und entsprechend führen. Wer das nicht kann ist selber schuld.

Blogged with Flock

Tags: , , , ,