...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations

Das Orginal gibt es unter http://www.melconway.com/research/committees.html auf der Homepage von Mel Conway. Immer mal wieder lesenswert, auch wenn es nie hoch wissenschaftlich bewiesen wurde.

Jurgen Appelo, "So Now You’re an Agilist. What’s Next?", Agileee conference, 2009 from Alexey Krivitsky on Vimeo.

Im DD 99 setzt er sich mit Elite, deren Verantwortung auseinander und greift dabei bis auf Platon zurück. Er schließt mit:

Eigentum verpflichtet. Elite verpflichtet. Bildung verpflichtet. Adel verpflichtet, Stärkev erpflichtet.
Wer je das Privileg hatte, oben zu sein, hat damit eine Pflicht auf sich geladen. Elite ist nicht oben sein, sondern unten helfen und führen.

Gut, Dueck hat sein DD bezogen auf die Bundestagswahlen bezogen, aber greift das nicht auch auf Führung von Menschen in Unternehmen? Führung kommt von führen...

Um halbwegs vorbereitet in das Stück zugehen, wollte ich mir die wichtigsten Fakten zur Geschichte zusammengooglen, da der Roman mehr als nur einen Handlungsstrang hat und ich im Theater nicht in Gefahr kommen wollte, den Überblick zu verlieren.

Tolstoj leitet seinen Roman mit dem Satz ein: "Alle glücklichen Familien sind einander ähnlich; aber jede unglückliche Familie ist auf ihre besondere Art unglücklich." Daraus wird abgeleitet, daß für das gemeinsame Glück mehrere Dinge notwendig sind, die auch erfüllt sein müssen. Fehlt es an einem, kann es kein Glück geben.

Verallgemeinert bedeutet das:

• Für das Gelingen einer Sache sind immer mehrere Faktoren zu erfüllen.
• Fehlt einer der Faktoren, kann die Sache nicht gelingen.

Dieses Prinzip kennen wir aus unserere eigenen Erfahrung und es erklärt sehr einfach, warum Dinge wie zum Beispiel Projekte trotz vieler Erfolge und größter Anstrengungen an Kleinigkeiten scheitern können.

Jetzt endlich habe ich dafür einen griffigen Namen...

In diesem Video erklärt Prof. Kruse sehr gut, warum Veränderungsprozesse auch immer durch die oberste Ebene einer Organisation mitgetragen werden müssen und eine Änderung von unten nie erfolgreich ist. Und falls doch, dann nur, weil die Führung durch eine Reihe von Krisen so geschwächt ist, daß sie dem Änderungsdruck von unten nichts entgegen setzen können.

Für uns und unsere Projekte bedeutet dies, daß Veränderungen nur erfolgreich sind, wenn wir die Unterstützung der wichtigsten Stakeholder haben oder einfach der richtige Zeitpunkt dafür gekommen ist.

Starke widmet sich in seinem Vortrag dem Zusammenhang von Architektur und Kommunikation und weiß das überzeugend zu vermitteln.

Nach seiner Ansicht ist eine der wesentlichen Aufgaben eines Architekten die Kommunikation mit allen am Projekt beteiligten Stakeholdern. Richtig dachte ich nur während des ganzen Videos. Gute Architekturen zu entwerfenist das eine, sie zum Leben zu erwecken und zu halten etwas anderes. Dafür
müssen alle miteingebunden werden, die davon betroffen seien könnten. Und leider muß es muß auch immer wieder wiederholt werden.

Hier ein paar nebenbei notierte Aussagen von Starke:

• Architektur beschäftigt sich mit Strukturen und Konzepten.
• Implizite Annahmen treten immer da auf, wo etwas nicht
  dokumentiert ist, wo es notwendig gewesen war. (Alt bekannt!)
• Implizite Annahmen schaffen Mißverständnispotential. (Ich nenne
  das einfach mal heterogene Projektentwicklung. Klingt doch
  netter.)
• Architektur ist nicht das Kodieren von selbigen, da Code
  allein ab einer gewissen Größe keine Basis für Verständnis
  ist.
• Verständnis (von Architekturen) muß erst geschaffen werden und
  kann erst danach gefördert werden.
• Dokumentation muß minimalistisch sein, womit gemeint ist, daß
  nur die relevanten oder stabilen Punkte dokumentiert werden sollten,
  die für das Verständnis der Anwendung notwendig sind.
• Dokumentation muß wartbar sein.

Starke schafft es diese Punkte überzeugend zu vermitteln.

Fazit: Anschauen!

Wie kann das sein? Der Grund ist einfach. Niemand fühlt sich wohl beim Kritisieren von den Menschen mit denen wir täglich zusammenarbeiten und es wird versucht den dabei möglicherweise entstehenden Spannungen aus dem Weg zu gehen. Dummerweise können dadurch Fehlentwicklungen entstehen, die sonst leicht zu korrigieren wären. Letztendlich sammeln sich alle Punkte an und ergießen sich kummuliert über den Mitarbeiter, der in dieser Situation oft nicht weiß wie ihm geschieht.

Viele Punkte können leicht in einem informellen Rahmen geklärt werden, ehe sie sich zu richtigen Problemen entwickeln. Nichts eignet sich dazu so gut wie ein kurzes Gespräch an der Kaffeemaschine oder bei Mittagessen.

Hier meine Tipps für eine kontinuierliche Mitarbeiterführung:

• Schaffen Sie eine Atmosphäre, die es Ihnen erlaubt früh Ihre Mitarbeiter auf Fehler oder andere Sichtweisen anzusprechen, ohne daß diese in eine Verteidigunghaltung gehen.
  Schaffen Sie die Möglichkeit zum gegenseitigen Feedback, auch im informellen Rahmen.
• Laß Sie ihre Mitarbeiter reden und seine Sicht oder die Gründe seiner Handlungsweise erklären. Denken Sie dabei an das Sprichwort „Reden ist Silber, Schweigen ist Gold.“
• Ziehen Sie für sich auch immer in Erwägung sich zu irren.
• Lassen Sie Ihre Mitarbeiter wissen, wenn Sie unzufrieden sind.
• Lassen Sie Ihre Mitarbeiter wissen, wann Sie mit ihnen zufrieden sind.

Denken Sie daran: Vorsorge ist immer besser als Problemlösung und aufgeschoben ist nicht aufgehoben.

Dieser Witz ist mir bei der Lektüre von „Adrenalin Junkies und Formular Zombies“ von Tom DeMarco und Co eingefallen, als ich mich gefragt habe, welche Verhaltensmuster ich selber kenne, die aufgeschrieben werden sollten.

Leberwurststullen gibt es dann, wenn die Entwickler in einer Firma niemals mit dem eigenen Produkt arbeiten würden und sich wundern, daß andere es tun. Ein Beispiel hierfür war mein rumänischer Kollege Florian, der sich immer geweigert hatte Online-Banking-Systeme zu benutzen. Auf unsere Nachfrage wieso meinte er nur, daß er in einem Team zur Entwicklung von Online-Banking-Systemen gewesen wäre und wüßte wie diese geschrieben würden. So etwas macht einen dann immer sprachlos. Nach Leberwurst riecht es auch, wenn ein Team mit einer selbstentwickelten Software arbeitet, die es selber für schlecht und unausgereift hält, es aber für Kundenprojekte einsetzt.

Diese beiden Varianten haben den gleichen Ursprung, wenn auch unterschiedliche Auswirkungen. In beiden Fällen haben alle Beteiligten das bewußte oder unbewußte Gefühl, daß etwas mit der Software die entwickelt wird oder dem Softwareentwicklungsprozess nicht stimmt. Daher können sie kein inneres Vertrauen zu ihrem Produkt entwickeln, nutzen es selber nicht und es bildet sich teilweise eine leicht zynische Haltung gegenüber dem Produkt. Das ist vergleichbar mit Bankern, die bei vollem Bewußtsein Kredite an nicht zahlungsfähige Häuslebauer vergeben und uns so die aktuelle Finanzkrise beschert haben.

In unserem Falle sind aber nicht die Entwickler daran schuld. Vielmehr fehlen in solchen Firmen zwei Dinge: Zum einen eine offene Kultur der konstruktiven Kritik und zum anderen ein Bewußtsein für Qualität. Eigentlich schade, den Qualität ist eigentlich gar nicht so teuer, denn auch wenn immer mit Aufwänden argumentiert wird, entsteht Qualität in aller erster Linie durch den Willen dazu.