itemis + TypeFox = Xtext!

Wie viele wissen, hat sich Anfang dieses Jahres etwas sehr entscheidendes im Eclipse Xtext Projekt verändert. Unsere Kollegen in Kiel haben sich entschlossen itemis zu verlassen und haben ein eigenes Unternehmen gegründet, TypeFox.

typefox

Damit basiert das Xtext Projekt nun mehr auf zwei großen Säulen und nicht mehr nur auf einer.

Um ehrlich zu sein sind wir bei itemis nicht gerade glücklich gewesen über diese Entwicklung. Und wie immer geht eine Trennung nicht ohne Reibereien ab.

Nichtsdestotrotz werden wir unser Open Source Commitment im Allgemeinen und unser Eclipse Xtext Engagement im Speziellen nicht aufgeben. Im Gegenteil, wir werden uns verstärkt beiden Themen widmen und uns weiterhin voll auf das Thema Language Engineering konzentrieren.

Dabei freuen wir uns auf die Zusammenarbeit mit unseren Ex-Kollegen von TypeFox, deren Kompetenz wir nach wie vor sehr schätzen. Wir sind uns sicher, dass das Xtext Projekt mehr denn je auf einem soliden Fundament steht und auch in Zukunft das sein wird was es immer war: Ein verdammt gutes Framework.

Vielen Dank an alle die in der Vergangenheit hierzu beigetragen haben und es in Zukunft tun werden.


As you might have noticed there was a very crucial change in the Eclipse Xtext project at the beginning of this year. Our colleagues in Kiel have decided to leave itemis and have founded their own company, TypeFox.

typefoxThe Xtext project is now based on two major pillars and not just on one.

To be honest, we at itemis were not were happy about this. As always, a separation does not take place without personal frictions.

None the less we will continue our Open Source Commitment, in particular our commitment to Eclipse Xtext.

We decided to increasingly focus on the broader topic of Language Engineering, in addition to the specific technology of Xtext.

We are looking forward to working with our ex-colleagues of TypeFox, whose expertise we still value very much. We are sure that the Xtext project is more than ever on a solid foundation and will be in the future what it always was: A damn good framework.

Thanks to all who have contributed to this in the past and will do it in the future.

Wie funktioniert Usability Engineering

Letztes mal ging es um das Thema agile Softwareentwickung. Agile Methoden sind heute sehr wichtig in der Softwarentwicklung, benötigen jedoch eine wichtige Ergänzung: Usability Engineering.

Wie funktioniert Usability Engineering?

Gutes Usability Engineering setzt den Benutzer eines Softwaresystems in den Mittelpunkt der Entwicklungsanstrengungen. Ohne gutes Usability Engineering sind auch die besten agilen Entwicklungsprojekte zum Scheitern verurteilt.

Wie gutes Usability Engineering funktioniert erfahrt ihr in einem Blog Artikel von meiner Kollegin Jasmin Kuhn.

Sie stellt zunächst einmal klar, worum es beim Usability Engineering eigentlich geht:

„Beim Usability Engineering geht es nicht nur um ein gutes Gefühl und Intuition bei der Gestaltung, sondern es geht vor allem um Normen (z. B. ISO 9241), Gestaltungsregeln, Heuristiken und Design Patterns, die uns dabei helfen ein System gebrauchstauglich zu gestalten.“

Im weiteren Verlauf des Post stellt sie dann die grundlegenden Prozesse, ihre Reihenfolge und bestmögliche Umsetzung vor.

Am Ende des Artikels kann man sein frisch erworbenes Wissen dann testen. Die 10 Fragen allerdings sind nicht ohne. Wer sie alle richtig beantwortet, kann sich schon fast als Experte bezeichnen. Wer weitere Fragen hat, kann sich auch gerne an Jasmin wenden. Die kennt sich nämlich richtig gut aus.

Veröffentlicht unter Agile

Was ist eigentlich Scrum?

scrum itemis

Eigentlich ist Scrum ja schon ein alter Hut. Dennoch ist es aus der heutigen IT-Welt nicht mehr wegzudenken. Scum ist das bestimmende Modell, wenn man über Agilität spricht. Kanban & Co. kommen da nicht mit. Und eigentlich hat sich in den letzten Jahren doch einiges getan.

Aus diesem Grund haben wir uns bei itemis überlegt, unseren Scrum Auftritt mal komplett zu überarbeiten. Den Anfang machen wir mit einer Reihe von Beiträgen in unserem Agile Blog. Hier erklären wir das ganze Modell von vorne bis nach hinten.

Für alle die es besonders genau wissen wollen, haben wir zur Lernkontrolle jeweils eine Reihe von Prüfungsfragen angehängt. Mit ein bisschen Mühe ist man so auch ohne Zertifizierungskurs für die Prüfung zum Scrum Master oder Product Owner nach scrum.org vorbereitet. Hängt das bitte nicht an die große Glocke, schließlich verdienen wir bei itemis unser Geld mit diesen Kursen 😉

Die ersten beiden Artikel sind übrigens schon fertig. Nummer eins gibt eine kompakte Scrum Einführung. In Nummer zwei geht es um den Scrum Prozess. In Kürze erscheinen dann weitere Artikel.

Wir werden auch unsere scrum-kompakt.de Seite komplett überarbeiten. Über diese Seite kann man dann demnächst einige wirklich nützlich Scrum Utensilien bestellen, die nicht nur nützlich sind, sondern auch viel Spaß machen. Demnächst an dieser Stelle mehr.

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: , , , ,