Slack ist nicht alles

Slack sei das ultimative Tool für Kaizen – soll Arne Rook in einem Vortrag bei Immobilienscout24 in Berlin gesagt haben. Davon berichtet Stefan Haas in seinem Blog-Artikel “Slack is a Culture Shock”.

Dass Slack - also Spielraum, Freiraum, Autonomität - ein sehr wichtiger Aspekt jeder Arbeit ist, finde ich auch. Voll ausgelastete und allemal überlastete Systeme haben schlicht keine Puffer. Wenn es anders kommt als geplant, knirscht es sofort oder explodiert gar. Und ohne Slack gehen Motivation und Innovation zurück. Wer könnte auf die aber verzichten?

Als Lektüre zum Thema empfehle ich Spielräume von Tom DeMarco, Drive von Dank Pink und Why Work Sucks and How to Fix It von Ressler und Thompson.

So weit bin ich also ganz dabei. Slack ist wichtig, ja, unverzichtbar. Ohne Slack keine Selbstorganisation. Ohne Slack keine kreative kontinuierliche Verbesserung.

Aber Slack ist nicht alles.

In einem traditionellen Unternehmen über Slack zu sprechen, mag wie Ketzerei klingen: “Menschen sollen mit (mehr) Freiraum besser arbeiten? Nein, nein, das kann nicht sein.” Solcher Widerstand löst dann schnell den Missionarsreflex aus: “Ich bringe euch das Heil mit Slack; wenn ihr das nicht einsehen wollt, dann erst recht.”

Leider geht dabei zweierlei unter:

• Menschen müssen es durchaus lernen, mit Freiräumen umzugehen.
• Menschen brauchen ein Ziel.

Slack zunächst einmal zulassen, d.h. Spielraum vor allem in Bezug auf Zeit geben, aber auch beim Geld, bei Entscheidungen, bei der Arbeitsplatzausgestaltung oder –ortswahl, bei der Fortbildung usw. ist nur ein erster Schritt. Im zweiten muss dieser Spielraum auch genutzt werden. Da sehe ich aber immer wieder Zögern oder gar Unfähigkeit.

Zug zum Spielraum

In vielen Unternehmen klagen die Mitarbeiter über einen Mangel an Spielräumen. Das soll natürlich verbessert werden. Aber ich kenne auch eine ganze Reihe von Unternehmen, in denen es Spielräume gibt – die ungenutzt bleiben. Da wird Zeit gewährt für “Forschung” – nur nimmt sie sich niemand. Da steht Geld für Fachliteratur bereit – nur nutzt das niemand, um Bücher oder Zeitschriften Abos zu kaufen. Da wird sogar Fortbildung angeboten, womöglich um weitere offizielle Qualifikationen zu erlangen – aber keiner macht sich auf den Weg.

Paradiesische Zustände führen also nicht automatisch zu Entfaltung und Aufblühen. Warum? Weil Menschen es aus unterschiedlichen Gründen eben lernen müssen, sie zu nutzen. Was das für Gründe sein mögen, darüber will ich hier nicht spekulieren. Und ich will auch nicht in Zweifel ziehen, dass die Spielraumangebote ehrlich gemeint sind. Was nun? Ist doch schade um den schönen Slack, der da ungenutzt bleibt.

Mein Vorschlag: Die Nutzung von Slack sollte immer wieder nachgefragt werden. Man muss an den Menschen ziehen. Pull ist also nicht nur für die Softwareentwicklung ein wichtiges Prinzip. Auch die Mitarbeiterentwicklung braucht es. Immer wieder muss der Slack-Geber klar machen, dass er wünscht, dass der Spielraum genutzt wird.

Fragen wie “Warum hast du den Slack nicht genutzt?” sind da allerdings weniger hilfreich als “Was hast du in deinem Slack gemacht?” Erstere sind nämlich wieder mehr oder weniger subtil drohend/kontrollierend, Letztere hingegen interessiert und in sich wiederum freistellend.

Slack-Nutzung vorleben und Slack-Nutzung interessiert nachfragen, das scheint mir sehr wichtig, um Menschen anzuleiten, mit Freiräumen umzugehen.

• Was hast du zuletzt “erforscht” in der Zeit, die dir das Unternehmen dafür bietet?
• An welchem Fach-/Sachbuch liest du gerade, das du dir von dem Literaturbudget des Unternehmens gekauft hast?
• Was hast du auf der letzten Fortbildung gelernt, die die das Unternehmen ermöglicht hat?
• Wie hast du deinen Entscheidungsspielraum genutzt, den dir das Unternehmen bietet?

Das Medium, um Zug in dieser Weise auszuüben, ist für mich “die Runde”, also ein ungezwungenes, allerdings fokussiertes Treffen. Zeit für solche Runden ist im Wochenkalender für alle vorzusehen. Das ist Führungsaufgabe. Und da wird dann nachgefragt, ausgetauscht und Slack gelebt.

Zugziel

Zu glauben, dass durch Slack einfach alles besser würde, weil Menschen dann von selbst aufblühen, finde ich naiv. Ich habe ein optimistisches Menschenbild, doch dass “einfach so” nur durch Freiraum alles gut würde, glaube ich nicht. Er ist wichtig, nur eben nicht allein seligmachend.

Vor allem nützt er nichts, solange unklar ist, wofür er gut sein soll. Was tun mit dem ganzen Slack? Wohin die Energie, die dadurch frei wird, richten? Wohin blicken?

Ohne ein klares Ziel geht es nicht. Wer mag, kann auch Vision oder Mission dazu sagen. Oder auch Zweck. Stefan Haas hat das nur nebenbei angesprochen: “In an environment, where the purpose is clear…”, da werde Slack zur Wunderwaffe.

Leider treffe ich so selten auf Teams, Abteilungen, Unternehmen, die ein wirklich klares Ziel haben. Und ich meine 1 Ziel, 1 Mission, 1 Zweck. Wirklich nur 1. Für alle. Und auch noch sonnenklar.

Der Mangel an klarem Ziel scheint mir sogar noch ein größeres Problem zu sein als der Mangel an Slack. Ich sehe sogar die Gefahr, dass Slack als ein weiteres Mittel gesehen werden könnte, die Unklarheit oder Ambivalenz in Bezug auf ein Ziel zu kaschieren. Doch das kann nur nach hinten losgehen – und würde den Slack als Schuldigen anprangern.

Slack ist auch nur ein Mittel, um das 1 Ziel besser zu erreichen. Genauso wie Selbstorganisation oder Scrum oder ein Team Room oder Collective Code Ownership oder was sonst noch in der Softwareentwicklung.

Aber zu welchem Zweck soll dieses Mittel eingesetzt werden? Solange darüber unterschiedliche Meinungen herrschen, ist nicht zu erwarten, dass das Mittel sein Potenzial entfaltet. Dasselbe gilt für Kaizen. Wohin soll denn eine Organisation sich verbessern? Verbesserung ist kein Selbstzweck. Sie muss dem Organisationszweck dienen. Doch welcher ist das?

Ganz, ganz weit oben auf der Prioritätenliste steht für mich deshalb immer wieder die Zweckdefinition. Wofür gibt es das Unternehmen, die Abteiltung, das Team, das Projekt? Ohne glasklaren Zweck entsteht keine Kohärenz in dem, was die vielen Menschen in einer Organisation tun.

Und weil dabei Menschen eine Rolle spielen, kann diese Frage nicht beantwortet werden ohne zu klären, was diese Menschen eigentlich für sich selbst wollen. Der Zweck einer Organisation muss mithin immer im Einklang mit den Bedürfnissen der sie konstituierenden Menschen stehen.

Das, so scheint mir, ist noch ein größerer Kulturschock für viele Manager. Sich klar werden darüber, was man selbst will und was die Organisation will? Und dann auch das in Einklang bringen mit dem, was die Mitarbeiter wollen?

Ja, ich glaube, ohne geht es nicht mehr. Zumindest, wenn man ernsthaft besser werden will. Und wenn man ernsthaft CSR betreiben will. Die beginnt nämlich wie vieles andere auch bei sich selbst, bei den Mitarbeitern des eigenen Unternehmens.

Wenn ich es in einem Satz sagen sollte, dann vielleicht so: Purpose first, slack second.

Wieviel Entwurf ist genug Entwurf?

Endlich die Antwort auf die Frage, wie viel Entwurf einer Implementierung vorausgehen sollte.

Immer wieder wird darüber ja gerätselt. Seit agile Softwareentwicklung aufgekommen ist, herrscht Unsicherheit. Ein “Big Design Up-Front” (BDUF) ist zu vermeiden. Heißt das jedoch, dass gar nicht mehr entworfen werden soll? [1]

Wie ist dieses Dilemma aufzulösen?

Ich versuche es mal mit einer Analogie:

Mit dem Entwurf ist es wie mit der Gesunderhaltung: Wenn man nicht aufpasst, dann gibt es kein Halten.

Wann haben Sie genug für Ihre Gesundheit getan? Schon genug Sport getrieben? Schon genügend Vorsorgeuntersuchungen machen lassen? Schon genügend Blicke in den Körper werfen lassen mit Ultraschall, CT usw.? Schon genügend Blutanalysen machen lassen? Schon ausreichend auf die Ernährung geachtet? Und wie ist’s mit der spirituellen Seite der Gesundheit?

Es ist ein Fass ohne Boden, was man alles für die Gesundheit tun kann. (Nicht umsonst gibt es eine wachsende Gesundheitsindustrie.) Also müssen Sie Ihren Aufwand bewusst begrenzen. Sie können nicht den ganzen Tag darauf verwenden.

Aber es wäre auch falsch zu sagen, dass Sie nichts dafür tun müssten, weil sich alles von allein ergibt. Ich hoffe, da sind wir uns einig.

Das bedeutet, Sie tun am besten täglich ein bisschen. Vielleicht sind das nur 15-30 Minuten “Fitnesstraining” irgendeiner Art. Schon ein regelmäßiger forscher Spaziergang soll ja Wunder wirken. Dazu ein bisschen Obacht bei der Ernährung. Und dann noch alle Jahre wieder ein paar Vorsorgeuntersuchungen. Plus etwas Meditation zwischendurch.

Was bedeutet das für den Entwurf in der Softwareentwicklung?

• Entwerfen Sie regelmäßig
• Entwerfen Sie in einer Timebox

In der Regelmäßigkeit steckt die Wiederholung. Es gibt also keinen einmaligen Entwurf, der alles vorherbestimmt. Entwerfen ist vielmehr eine kontinuierliche Aufgabe wie Codieren. Bei neuen Erkenntnissen, muss auch neu entworfen bzw. der bisherige Entwurf überprüft und angepasst werden.

Und in der Timebox steckt die Begrenzung, damit Entwurf kein schwarzes Ressourcenloch wird. Es stimmt ja: Bubbles don´t crash. Und mit einem Entwurf ist noch kein Kunde glücklich gemacht worden. Deshalb muss das Entwerfen immer wieder ein Ende haben, um es in auslieferbaren und nützlichen Code zu überführen, zu dem der Kunde Feedback gibt – das wiederum Einfluss auf den Entwurf haben kann.

Ist Ihnen das genug Empfehlung zur Menge des Entwurfs bei der Softwareentwicklung?

Wenn nicht, dann hier konkrete Zahlen. Die werden Sie natürlich provozieren. Die meine ich auch nicht so, dass sie für alle Softwareprojekte heute und in Zukunft gelten. Natürlich nicht. Aber ich meine sie trotzdem ernst, sozusagen als Tendenz und Denkanstoß:

• Entwerfen Sie am Anfang eines Projektes max. 2 Tage.
• Entwerfen Sie anschließend jede Woche max. 4 Stunden.
• Entwerfen Sie außerdem jeden Tag max. 2 Stunden.

Und das jeweils im Team.

Wie klingt das? Konkret, oder? Und nicht gerade BDUF. Sondern agil, weil kontinuierlich. Außerdem steckt da Kommunikation drin, weil das Team zusammen entwirft (Collective Design Ownership). Und es wird Architekturbewusstsein verkörpert.

Sie sehen, die Antwort auf die immer wieder gestellte Frage ist eigentlich ganz einfach. Wieviel Entwurf ist nötig? Im Schnitt sind es ca. 2-3 Stunden pro Tag. That´s it. Nicht die schiere Menge Entwurf ist wichtig, sondern die Regelmäßigkeit.

Fragt sich jetzt nur, was man während dieser Zeit tut? Aber das ist ein Thema für ein anderes Mal.

Fußnoten

[1] Was Entwurf nun genau ist im Vergleich zum Codieren, lasse ich mal dahingestellt. Soviel sollte aber klar sein, dass beim Entwurf eben kein Code geschrieben wird. Das heißt nicht nur, dass die Programmiersprache dabei keine Rolle spielt, sondern auch, dass das Abstraktionsniveau über der Programmiersprache liegt. Flow-Charts und Structogramme sind für mich daher eher keine Entwurfsmittel, sondern nur graphische Programmiersprachen.

Der Fortschritt in Datenflüssen

Datenflüsse sehen einfach aus, sind es auch in gewisser Weise – dennoch haben sie es in sich. Da habe ich neulich gemerkt, als ein Programm, das ich mit Flow-Design locker entworfen hatte, sich dann doch nicht so verhielt, wie erwartet. Es hat funktioniert, das war kein Problem. Aber sein Output war irgendwie, hm, strange.

Deshalb will ich hier einmal die Frage beleuchten, wie denn eigentlich die Verarbeitung in Datenflüssen fortschreitet. Oder besser: Welche unterschiedlichen Fortschrittsweisen kann es denn geben?

Ein Beispielszenario soll die unterschiedlichen Fortschrittsweisen vergleichbar machen. Es ist ganz einfach:

Nachrichten, die von einer Funktionseinheit verarbeitet werden, bezeichne ich mit deren Namen: a(x) kommt “von draußen” und wird von a() verarbeitet, b() erzeugt c(y), die von c() verarbeitet wird usw. Nachrichten tragen also das Ziel und nicht die Quelle im Namen. Für das Beispiel reicht das als Identifikation.

Ausgehen von einer Nachricht a() erzeugen die Funktionseinheiten nun diese Nachrichten:

• a(1)
• b(11)
• c(111)
• e(1111)
• e(1112)
• d(111)
• c(112)
• e(1121)
• b(12)
• d(121)
• d(122)
• c(121)
• b(13)
• c(131)
• e(1311)
• e(1312)
• d(131)
• c(132)
• e(1321)
• d(132)
• d(133)
• c(133)
• e(1331)
• e(1332)
• d(134)

Dieser Baum beschreibt Input-Output-Zusammenhänge, z.B. Input b(12) an b() führt zum Output d(121), d(122) und c(121). Das bedeutet auch, das c(121) nach d(122) erzeugt wird.

Allerdings steckt keine Aussage darüber in dem Baum, wann die Nachrichten verarbeitet werden. Verarbeitet c() die Nachricht c(132) während b() noch weiteren Output generiert oder erst nachdem d(134) ausgegeben wurde?

Darauf geben die Fortschrittsweisen Antwort.

Depth-first

Die naheliegende Vorstellung vom Fortschritt der Verarbeitungsweise des Flows ist wohl, dass jede Nachricht sofort verarbeitet wird. Auf einen Zeitstrahl aufgetragen sieht das so aus:

Hier spiegelt sich der Baum direkt wider. So würde die Verarbeitung auch verlaufen, wenn der Datenfluss als Call Stack interpretiert würde, also die Funktionseinheiten sich geschachtelt aufriefen.

Eine Schachtelung im Sinne einer Servicehierarchie soll ja aber gerade mit Flow-Design vermieden werden. Die Funktionseinheiten a()..e() sollen sich nicht kennen; c() soll nicht von e() abhängen, b() nicht von c() und d(), a() nicht von b().

Alternativ kann diese Fortschrittweise aber auch mit Event-Based Components (EBC) erzielt werden: Wenn a() mit b(11) einen Event feuert, dann arbeitet b() als Event-Handler den erst ab, bevor a() dazu kommt, b(12) auszugeben. Wenn b() währenddessen c(111) erzeugt, arbeitet c() die Nachricht erst ab, bevor b() d(111) erzeugt usw.

Alle Nachrichten werden also erstens sequenziell verarbeitet, d.h. nacheinander und auch noch streng in der Reihenfolge, in der sie erzeugt wurden. Und zweitens werden sie synchron verarbeitet, d.h. während der Verarbeitung wartet die erzeugende Funktionseinheit.

Die synchron-sequenzielle Verarbeitungsweise geht depth-first vor. Die Verarbeitung jeder Nachricht fließt sofort soweit nach rechts durch wie möglich.

Breadth-first

Ist der depth-first Fortschritt der richtige, der beste, der einzig wahre Fortschritt für Datenflüsse? Ich glaube nicht. Er mag der naheliegendste sein, doch das scheint mir für eine Bewertung zu wenig. Denn warum soll es richtiger sein als etwas anderes, Nachrichten sofort in der Tiefe zu verarbeiten und dabei Quellfunktionseinheiten darauf warten zu lassen?

Ich denke, zunächst einmal gleichberechtigt ist die breadth-first Verarbeitung von Nachrichten:

Die hervorgehobenen Nachrichten zeigen den Unterschied gegenüber dem depth-first Fortschritt. a() erzeugt die Nachrichten b(11), b(12) und b(13) und die werden zuerst komplett abgearbeitet, bevor deren Output dran kommt. Und auch der wird zuerst abgearbeitet, bevor sein Output dran kommt usw. Die am weitesten rechts stehende Funktionseinheit e() erhält also hier als letzte Arbeit, weil sie am tiefsten im Baum liegt als der der Fluss angesehen werden kann, wenn man ihn um 90°dreht.

Die Verarbeitung eilt damit nicht mehr bei jeder Nachricht zum Ende der Verarbeitung, sondern schreitet sequenziell über alle “Flussarme” hinweg fort. Ich stelle mir das als eine breite Welle vor.

Vorteil von depth-first ist, dass nach Anstoß eines Flows schnell erste Ergebnisse am Ende heraustropfen. Das bedeutet aber nicht, dass die Verarbeitung von weit vorangeschritten ist. Bei breadth-first hingegen können Sie sicher sein, dass Arbeitsschritte abgeschlossen sind, wenn ihre Ergebnisse verarbeitet werden.

Das fühlt sich für mich mehr nach Datenfluss an: Ein Input kommt bei einer Funktionseinheit “auf dem Tisch”, wird verarbeitet, dabei wird Output erzeugt – und wenn das alles fertig ist, dann geht es bei der nächsten Funktionseinheit weiter.

Zumindest empfinde ich das als “fluss-mäßiger”, wenn ich die Verarbeitung als synchron denke. Weder findet Verarbeitung auf mehreren Threads innerhalb einer Funktionseinheit statt, noch arbeiten mehrere Funktionseinheiten parallel. Wenn Funktionseinheiten ihre Arbeit abschließen können, bevor ihr Output verarbeitet wird, dann sind sie auch hübsch unabhängig von einander.

Synchrone Verarbeitung ist für mich der default beim Flow-Design. Sowohl Flow-Design Implementierungen mit EBC wie mit der Flow Runtime folgen dem auch – auch wenn sie sich in der synchronen Verarbeitung unterscheiden, wie Sie hier sehen.

Dennoch war ich damit nicht zufrieden. Denn dieser breadth-first Fortschritt hat sich in der eingangs erwähnten Anwendung als etwas merkwürdig angefühlt. Warum?

Solange am Anfang eines Flusses nur eine Nachricht steht, macht breadth-first kein Problem. Dann läuft die große Welle langsam in die Tiefe.

Falls auf a(1) jedoch noch a(2), a(3) usw. folgen und a(i) nicht komplett in der Tiefe verarbeitet ist, bevor a(i+1) eintrifft, kann es zum Stau kommen [1]. Es geht dann zwar alles ganz gerecht zu im Sinne sequenzieller Verarbeitung. Doch solche Gerechtigkeit ist nicht in allen Fällen wünschenswert. Manchmal wäre es gut, wenn Nachrichten einander überholen könnten – zumindest wenn sie in unterschiedlichen Flussarmen fließen. Warum muss ein d(2…) auf ein e(1…) zwangsläufig warten?

Round-robin

Angesichts des merkwürdigen Verhaltens der Anwendung habe ich einen Mittelweg zwischen depth-first und breath-first Verarbeitung gesucht. Eingefallen ist mir eine round-robin Verarbeitung von Nachrichten. Um das zu verstehen, hier die grundsätzliche Arbeitsweise der Flow Runtime:

Nachrichten kommen von außen zur Flow Runtime, die sie asynchron verarbeitet. Nachrichten, die bei der Verarbeitung entstehen, fließen entweder hinaus, weil sie Endergebnisse darstellen – oder sie fließen zurück in die Runtime, um von folgenden Funktionseinheiten verarbeitet zu werden. a(i) ist eine Nachricht, die von außen zur Runtime kommt. b(i) usw. sind Nachrichten, die die Runtime quasi an sich selbst schickt.

Jede Nachricht, die bei der Runtime eintrifft, wird auf deren einzigem Thread abgearbeitet; das symbolisiert der Kreis in der Funktionseinheit. Sie ist insofern autonom gegenüber ihrer Umwelt.

Immer wenn eine Funktionseinheit eine Nachricht verarbeitet hat, schaut die Runtime nach, ob weitere Nachrichten zur Verarbeitung anliegen. Die stehen in einer Queue, über die die Runtime in einer Schleife läuft. Der Inhalt dieser Queue sieht für das Beispiel über die Zeit so aus (von links wird angehängt, von rechts entnommen):

Das erklärt die breadth-first Verarbeitung: Jede Funktionseinheit wird für eine Nachricht abgearbeitet und stellt ihren Output ans Ende der Queue. Der kommt dann erst dran, wenn der Output vorheriger Funktionseinheiten verarbeitet wurde.

Dieses System habe ich nun aufgebrochen, indem nun jede Funktionseinheit eine eigene Queue besitzt:

Über diese vielen Queues läuft nun die Flow Runtime im round-robin Verfahren. Das bedeutet, für jede Nachricht geht sie eine Queue weiter. Es entsteht folgendes Muster:

Sie sehen, die Verarbeitung wird Nachricht für Nachricht gleichmäßig über die Funktionseinheiten verteilt. Die Verarbeitungsreihenfolge hat im Grunde nichts mehr mit der Tiefe einer Funktionseinheit im Fluss zu tun. Wo Output erzeugt wird, da wird er auch abgearbeitet.

Käme nun ein a(2) zwischendurch an, so würde es alsbald zur Verarbeitung gebracht, wenn seine Queue an der Reihe ist. Es müsste nicht warten, bis alles, was vorher schon aufgelaufen war, abgearbeitet ist.

Dieses Verfahren scheint mir noch gerechter als breadth-first. Es hat allerdings eine Besonderheit, derer man sich bewusst sein muss: Aufs Ganze betrachtet, erfolgt die Abarbeitung der Nachrichten nicht mehr notwendig streng in Erzeugungsreihenfolge. Nachrichten können einander überholen: e(1112) wird zum Beispiel vor b(13) verarbeitet.

Bei depth-first Fortschritt ist b(13) noch nicht erzeugt, wenn e(1112) abgearbeitet wird. Bei breadth-first wurde b(13) erzeugt und schon abgearbeitet lange vor e(1112). Bei round-robin jedoch steht b(13) noch unverarbeitet in der b()-Queue, während e(1112) schon in Arbeit ist.

Asynchron im Kreis

Auch bei round-robin findet innerhalb der Flow Runtime noch keine Parallelverarbeitung statt. Trotzdem geht es überall voran, sobald die Runtime Gelegenheit hat, eine Nachricht zu verarbeiten. Das ist kein pre-emptive Multitasking, weil ja jede Funktionseinheit so lange an einer Nachricht herumlaborieren darf, wie sie mag. Insgesamt auf den ganzen Fluss gesehen, fühlt es sich dennoch so an, als würde quasi parallel gearbeitet.

Richtig ernst wird das, wenn einzelne Funktionseinheiten asynchron arbeiten. Dann kann der Output während ihrer Laufzeit von der Runtime schon weiterverarbeitet werden.

Beispielhaft setze ich mal b() auf asynchrone Verarbeitung, damit Sie sehen, wie sich das Muster dann verändern könnte. Die Länge der Nachrichtenkästen soll nun die Verarbeitungsdauer andeuten.

 

Jetzt kommt es natürlich auch darauf an, wann b() Output erzeugt. c(111) wird parallel abgearbeitet und erzeugt e(1111). Währenddessen arbeitet b() weiter! Wann fließt dort aber d(111) heraus? Während c() am Werk ist und e(1111) generiert oder erst später? Denn danach richtet sich, ob auf c() unmittelbar e() folgt wie im Bild oder zuerst d().

Fazit

Die Verarbeitung in Datenflüssen ist anders als die in Servicehierarchien. Anders, doch deshalb nicht schlechter. Sie müssen sich umgewöhnen. Das mag schwer fallen, weil die “Stack-Denke” so tief in uns allen drin steckt. Doch ich meine immer noch, dass sich das lohnt.

Denn anders bedeutet hier chancenreich. So strange das Verhalten der eingangs erwähnten Anwendung war, es hat mich wieder beeindruckt, wie leicht die Flow-Operationen zu testen waren, weil sie unabhängig von einander sind. Und es war ganz leicht, individuell für jede zu entscheiden, ob sie synchron oder asynchron laufen soll.

Und letztlich finde ich es auch gut, überhaupt die Wahl zu haben zwischen Verarbeitungsweisen. Die könnte eine Runtime womöglich sogar zur Auswahl anbieten. Sogar den depth-first Fortschritt hatte ich schon einmal implementiert.

Fußnoten

[1] Dass weitere Nachrichten vor Abarbeitung beim Fluss eintreffen, setzt natürlich bei aller Synchronizität seiner Funktionseinheiten voraus, dass der Fluss als Ganzes gegenüber seiner Umwelt asynchron arbeitet. Das ist bei der Flow Runtime der Fall.

Warum es nicht besser wird

Neulich im Hochseilgarten: Einweisung in Gurt und Sicherungsanlage ausschließlich in großer Gruppe. Viele Personen werden gleichzeitig eingewiesen, dann wandern viele Personen gleichzeitig zu einem Hochseilparcours, dann warten viele-1 Personen, dass sie mit der ersten Station beginnen können.

Es staut sich überall: Vor der Einweisung solange, bis mit der großen Gruppe begonnen wird, vor dem Hochseilparcours und auch noch im Hochseilparcours auf den Plattformen zwischen den Stationen.

Überall Nadelöhre, Flaschenhälse, Engpässe. Manche davon unvermeidlich: aus Sicherheitsgründen darf zu jeder Zeit nur eine Person eine Station absolvieren. Andere aber selbstgemacht: das Warten vor der Einweisung und beim Einstieg in die Parcours.

Doch warum wird das nicht besser? Denn das war nicht nur am letzten Wochenende so, sondern auch schon vor zwei Jahren. Es kommt nur schwer zu einem Fluss der Besucher durch die Stationen. Meist stockt es – auch wenn der Hochseilgarten noch nicht ausgelastet ist.

Das ist für mich als Besucher nervig. Den Hochseilgarten als Organisation scheint es aber nicht zu stören. Dort konzentriert man sich auf lokale Effizienz statt globalen Fluss. Es ist wichtiger, dass Mitarbeiter die Einweisung nicht so häufig machen, statt dass die Besucher nach Ankunft flüssig in die erste Station einsteigen können.

Denn nichts anderes soll ja die Einweisung großer Gruppen bewirken, als dass man dabei Personal-Zeit spart. Sie dauert immer gleich lang, egal ob sie für 2 oder 20 gemacht wird. Dann doch besser für 20, oder?

 

Neulich im Restaurant: Da sitzen Kollege Stefan Lieser und ich in der Schweiz an einem sehr lauen Sommerabend an der murmelnden Limat draußen beim Italiener. Die Bedienung ist zuvorkommend, die Bestellung wird zügig aufgenommen, das Essen wird bald gebracht – aber beim Bezahlen dauert es lange, sehr lange. Die Bedienung vergisst uns, die Bedienung vergisst, dass wir mit Karte bezahlen wollen, die Bedienung kann mit dem Kartenlesegerät nicht recht umgehen. So war es am ersten Tag und so war es am zweiten Tag. Da erlaube ich mir anzunehmen, dass es sonst nicht anders ist. Warum ist das aber so?

Als Gast bin ich an Aufmerksamkeit während meines gesamten Besuchs interessiert. Nicht nur möchte ich bald mein Essen haben, ich will auch gehen können, wenn ich gehen will.

Aus Restaurantsicht ist das jedoch anders. Die Organisation interessiert sich für mich anscheinend nur solange sie noch Umsatz machen kann. Das ist ja vorbei, wenn ich zahlen will. Also muss sie uns keine Aufmerksamkeit mehr schenken. Glaubt sie. Anscheinend.

Und wieder ist das eine lokale Optimierung. Die Bedienung denkt nur für den Moment. In dem hat sie soviel Umsatz gemacht, wie sie kann. Weiteren Aufwand in uns zu investieren, könnte bedeuten, andere Gäste, die noch länger bleiben wollen, zu vernachlässigen.

Wenn sie allerdings über den Moment hinaus blickte, würde sie erkennen, dass selbst eine zügige Abwicklung des Bezahlens vorteilhaft für das Geschäft sein kann. Erstens wäre der Tisch wieder frei für neue Gäste. Zweitens – und viel wichtiger – wären wir rundum zufrieden, würden das Restaurant in guter Erinnerung behalten, keinen solchen Blogeintrag schreiben und schließlich gern wiederkommen.

Neulich beim Arzt:Ich rufe an, um einen Termin zu bekommen. Aber ich komme nur in die Warteschleife und am Ende nur zum Anrufbeantworter. Das mache ich zwei Mal ohne Nachricht - und wünsche mir beim dritten Mal doch einen Rückruf.

Man ruft zurück, erreicht mich aber gerade nicht. Also wähle ich wieder den Arzt an – und komme in die Warteschleife und bitte wieder um um Rückruf. Denn asynchron kann man mit Arztpraxen keinen Termin abmachen. Die bieten kein Tool auf ihrer Homepage dafür an und wenn ich ihnen einen Doodle-Link schicken würde, schlügen sie die Hände über dem Kopf zusammen. Nein, nein, dass der Patient Terminvorschläge macht, das geht ja gar nicht.

Warum ist das aber so? Dass ich nicht sofort drankomme, wenn ich einfach so in der Praxis auftauche, verstehe ich ja. Aber für einen Termin, dessen Länge ja keiner abschätzen kann und der kaum anders geplant würde, egal, was ich am Telefon sage, für einen solchen Termin, der allen Beteiligten Planungssicherheit gibt, muss ich nun großen Aufwand treiben. Wieder bin ich als Servicenehmer unzufrieden.

Dabei ist das doch ein uraltes Problem. Ärzte können ja nicht überrascht sein von Patientenanfragen. Und auch ihr Fließbandbusiness überrascht nicht einmal mehr mich. Warum ist da die Terminierung so schwierig? (Dass ich dann selbst mit Termin allermeistens immer noch 20-40 Minuten warten muss, will ich hier gar nicht anbringen.)

Wieder ist eine lokale Optimierung im Spiel. Da bin ich mir sicher. Diesmal verstehe ich sie aber nicht. Denn gerade an einer Terminvereinbarung als Einstieg bzw. Fortführung einer Behandlung, also einer Reihe von Umsätzen, sollte den Arzt doch sehr interessieren. Sie könnte fast schon als seine Visitenkarte angesehen werden. (Naja, dazu müsste dann auch noch der Termin mit max. 5-10 Minuten Verzug verlässlich eingehalten werden. Aber ich will nicht zuviel auf einmal fordern.)

Optimieren da die Sprechstundenhilfe etwas für sich? Vermeiden Sie vielleicht Ärger jetzt, weil sie etwas am Tresen nicht tun, da sie am Telefon hängen, zugunsten von Ärger, den sie gar nicht zu spüren bekommen, weil ich genervt zu einem anderen Arzt gehe? Hm… ich weiß nicht.

Blind für den Servicenehmer

Drei ganz unterschiedliche Erlebnisse für mich als Servicenehmer. Aber drei ähnliche Ergebnisse: mein Durchfluss durch den Service stockt. Allerorten stecke ich im Warten: in der Warteschlange beim Hochseilgarten, im Warten auf die Abrechnung, in der Warteschleife am Telefon.

Für mich ist das nervig. Wie ist das jedoch für die jeweilige Organisation? Ist das aus ihrer Sicht ein bewusst hergestellter Zustand? Sie weiß, dass ich genervt bin, aber ihr ist das egal. Oder weiß sie es, aber es ist ihr nicht egal, doch sie hat keine Ahnung, wie sie es besser machen könnte? Oder weiß sie es nicht, doch wenn sie es wüsste, wäre es ihr nicht egal? Hm… keine Ahnung.

Aber vielleicht ist das auch nicht so wichtig. Denn was zählt ist, dass die Organisation existiert. Sie kann es sich offensichtlich leisten, dass ich genervt bin. Zumindest im Augenblick. Glaubt sie.

Sie ist quasi sehbehindert, leidet darunter aber nicht. Denn sie zeigt mir nicht, dass sie meine Frustration wahrnimmt oder gar bedauert. Das erinnert mich an Rindenblindheit (Blindsight): Dabei ist der Patient blind, bemerkt es aber nicht unbedingt.

Qualität außerhalb des Zwecks

Ist solche “Sehbehinderung” kritikwürdig? Aus meiner ganz persönlichen Servicenehmersicht natürlich. Aber wenn ich mal einen Schritt zurücktrete, mal versuche die Situationen neutral zu sehen, nicht in Bezug auf mich zu werten… dann sehe ich Ursache und Wirkung.

Die Wirkung ist, dass Servicenehmer in Warteschlangen stecken. Und was ist die Ursache?

Ich glaube, der Grund für die Warteschlangen, die die Organisationen nicht zu bedauern scheinen, liegt im Zweck der Organisationen. Der ist so formuliert, dass Warteschlangen für Servicenehmer davon keine Abweichung darstellen. Die Warteschlangen sind unterhalb des Radars des Organisationszwecks.

Beispiel Hochseilgarten:

Wenn der Zweck des Hochseilgartens wäre “Menschen ein naturnahes Hochseilgarten-Erlebnis bieten, bei dem sie sicher selbstbestimmt vorankommen”, dann wären die Warteschlangen auf dem Radar. Denn zu einem selbstbestimmten Vorankommen gehört nicht nur, dass ich entsprechend meinem Selbstvertrauen Stationen durchlaufe, sondern auch dass ich nicht in Warteschlangen gezwungen werde.

So ist der Zweck aber bestimmt nicht definiert. Stattdessen – da bin ich mir sicher – steckt im Zweck das Geldverdienen drin. Er lautet also vielleicht “Heute Geld verdienen mit einem Hochseilgarten-Erlebnis”.

Ganz bewusst habe ich aus dieser Zweckdefinition sogar die Sicherheit rausgelassen. Denn die muss nicht drin stehen, wenn das Geld darin vorkommt. Sie ergibt sich sozusagen, weil es mit dem Geldverdienen schnell vorbei sein kann, sobald die Sicherheit nicht berücksichtigt wird.

Der Unterschied zwischen den beiden Zwecken liegt also darin, dass der eine Qualitätsmerkmale enthält und der andere nicht.

Ich glaube, die Warteschlangen sind eine Folge dessen, dass die Organisationen in ihrem Zweck mehr auf Funktionalität und aufs Geld achten, als auf Qualität. Qualität ist sozusagen nur ein notwendiges Übel, damit über die Funktionalität das ersehnte Geld reinkommt. Solange das passiert, ist die Qualität egal. Um die kümmert man sich erst wieder, wenn es beim Geld stockt.

Das ist ein legitimer Ansatz. Vielleicht ist das auch ein ökonomisch sinnvoller, zumindest verständlicher Ansatz. Kurzfristig allemal.

Mich als Servicenehmer befriedigt er allerdings nicht.

Zweck braucht Werte

Wenn meine Diagnose in die richtige Richtung gehen sollte, dann finde ich das zunächst persönlich frustrierend. Darüber hinaus glaube ich aber auch, dass sich Unternehmen keinen Gefallen tun, wenn Sie Ihren Zweck ohne Qualitätsansprüche formulieren. Und sogar, wenn zu diesen Qualitäten nicht “flüssige und verlässliche Beantwortung der Servicenachfrage” gehört.

Früher, ja, früher mag es ohne gegangen sein. Da herrschte Mangel allerorten. Jeder war froh, wenn er als Servicenehmer überhaupt irgendwie und irgendwann bedient wurde. Der Kunde war Bittsteller. Nicht anders ist es ja zu erklären, dass er heute als König ausgerufen wird. Diese krasse Bewertung macht nur Sinn als Gegenentwurf zu einem vormalig konträren Zustand.

Es ist so ähnlich wie bei der Post: Früher hieß es beim Telefon “Fasse dich kurz!”, dann hieß es “Ruf mal wieder an!” Mal steckte der Mangel in der Infrastruktur, dann in der Zahl der Servicenehmer.

Irgendwo ist also immer Mangel. Früher bei den Angeboten. Aus der Zeit stammen die husch-husch formulierten Zwecke vieler Unternehmen. Doch heute ist der Mangel eben nicht mehr bei den Angeboten, sondern bei den Kunden. Die vielen, vielen Angebote dürstet es nach den knappen Kunden.

Kein Angebot kann sich damit mehr sicher sein, dass es nachhaltig ein Bedürfnis erfüllt. Es mag heute ein Bedürfnis erfüllen – doch was ist morgen? Da hat das Bedürfnis des Publikums womöglich schon wieder gewechselt.

Es gibt inzwischen viele Hochseilgärten selbst in/um Hamburg, es gibt schon lange Unmengen an Restaurants und auch Ärzte gibt es genügend in Hamburg. Keines der Unternehmen kann es sich also eigentlich erlauben, die Qualität nicht im Zweck festgeschrieben zu haben. Und damit meine ich nicht nur die essenzielle Qualität in Bezug auf das Produkt – hohe Plattformen und sicherer Parcours beim Hochseilgarten oder moderne Diagnose und Therapie beim Arzt –, sondern auch die “ambiente” Qualität, das Drumherum.

Zu den ambienten Qualitäten gehören dann aber nicht nur schicke Praxisräume oder freundliche Kellner, sondern eben auch… Flüssigkeit in der Bedienung meiner Nachfrage. Denn Flüssigkeit schont die ultimativ knappe Ressource der Kunden.

Die Zukunft gehört der Zeit

Platte Befriedigung ist out. Fundamentale Löcher müssen nicht mehr gestopft werden. Seit wir aus dem Mangel heraus sind, geht es um etwas anderes. Als Kunden müssen wir nicht mehr um wenige Angebote kämpfen. Umgekehrt können sich die vielen Angebote nicht mehr wie Herrschaften den Kunden gegenüber verhalten.

Wer heute Kundschaft nicht nur anziehen, sondern auch halten will, der muss ihr daher mit Respekt begegnen. Dazu gehört für mich im Kern die Rücksicht auf das wertvollste, das Kunden haben: Zeit.

“Zeit ist Geld” ist der Leitspruch von Generation von Unternehmern. Die Frage ist heute allerdings, wessen Zeit damit gemeint ist. Bisher war es die der Unternehmen. Ich glaube aber, dass es in Zukunft die der Kunden sein sollte.

Unter genügend ähnlichen guten Angeboten gewinnt das, welches mit meiner Zeit als Servicenehmer am respektvollsten umgeht. An der Zeit hängen meine Aufmerksamkeit und mein Geld.

Wer mir das Gefühl vermittelt, insgesamt “eine gute Zeit” während der Nutzung seiner Angebote zu haben, der gewinnt.

Der Umgang mit der Zeit des Kunden gehört damit für mich ausdrücklich in den Zweck jedes Unternehmens. Solange das nicht der Fall ist, wird es nicht besser in den genannten Fällen.

Aber wenn er da angekommen ist, dann verschwinden die Warteschlangen beim Hochseilgarten, im Restaurant und beim Arzt. Und wenn sie nicht verschwinden sollten, dann wird zumindest mit mir als Kunde anders in Bezug darauf umgegangen.

Vielleicht finde ich die Warteschlange beim Hochseilgarten – falls sie wirklich, wirklich nicht zu vermeiden sind - ja gar nicht mehr so schlimm, wenn man mich währenddessen zu einem Kaffee einlädt? :-)

 

PS: Was das für die Softwarebranche bedeutet sollte klar sein. Nicht nur Performance und Skalierbarkeit der Software sind wichtig. Es gilt vielmehr, schlechte Usability und die vielen Gründe für Supportanrufe auch als Zeitfresser zu erkennen.

Jede Entscheidung der Entwicklung, die Kunde oder Anwender Zeit kostet, widerspricht einem Unternehmenszweck, der sich respektvollen Umgang mit der Zeit seiner Servicenehmer auf die Fahne geschrieben hat.

Event-Based Components mit Ruby

Zunehmend bin ich begeistert von dem, was so in der Softwarewelt passiert – aber erst spät in der .NET Welt ankommt. .NET ist immer noch cool – aber was mal leading edge war, fühlt sich für mich immer behäbiger an. Microsoft ist ein Flaschenhals (geworden) und schon gar nicht führend in vielen Aspekten der Softwareentwicklung.

Mono bringt manchmal Erleichterung, zum Beispiel beim Thema Infrastruktur in der Cloud oder iOS Programmierung. Doch noch mehr weitet sich der Horizont mit anderen Plattformen. Deshalb habe ich jetzt mal einen Vorstoß in Richtung Ruby gewagt.

• F# ist interessant, reizvoll, verlockend… aber am Ende doch zu Microsoft. In der weiten, weiten Welt passiert damit zu wenig.
• Java ist keine Option. Dazu bedarf es kaum einer Erklärung, oder?
• Python ist mir inzwischen schon zu alt.
• Scala mag ein würdiger Java-Nachfolger und hochaktuell sein, aber fühlt sich für mich immer noch zu instabil an. Bleeding edge will ich mir nicht antun. Dafür habe ich keine Zeit.
• Clojure ist mir ebenfalls noch zu blutig.

Was bleibt ist, ist aus meiner Sicht Ruby. Es mag schon einen Hauch in die Jahre gekommen zu sein. Clojure is the new exciting kid on the block. Aber für mich ist Ruby gerade gut abgehangen. Tools und Technologien sind stabil, scheint mir.

Auf meinem Macbook Air ist Ruby schon installiert. Da kann ich auf der Kommandozeile mit einer REPL rumspielen. Zusätzlich habe ich mir RubyMine von JetBrains installiert. Das ist ne solide IDE für meine Zwecke.

Also bin ich jetzt im Lern- und Bastelmodus. Eine neue Welt kennenlernen. In kleinen Schritten. Aber natürlich nicht ohne Flow-Design!

Wenn schon ein Ausflug auf eine neue Plattform, dann muss ich Flow-Design Entwürfe dort leicht umsetzen können. Geht das mit Ruby? Ja, das geht. Hier das Listing der Implementation eines ganz einfachen Flows:

Ich habe den Flow bewusst mit Event-Based Components realisiert, um ein Gefühl für den Unterschied zu C# zu bekommen. Ich bin begeistert! Das macht Laune mit Ruby. Es geht ganz einfach, wie Sie sehen.

Nach ein paar Stunden zugebracht mit der Lektüre von Ruby Büchern und Rumspielen mit der IDE ist mein derzeitiges Urteil: Ruby fühlt sich schlank an und bietet manches, was ich lange in C# vermisst habe, z.B. geschachtelte Funktionen.

Wenn das so weitergeht, dann kann es sein, dass Sie hier im Blog ab und an Ruby-Code zu lesen bekommen :-)

Architekturbewusstsein verkörpern

Gibt es wirklich keine Zukunft für Software-Architekten? Ilker Cetinkaya hat in seinem Blog-Artikel so geurteilt.

Wohlgemerkt meint er die Rolle bzw. Position des Software-Architekten, nicht den Aspekt Software-Architektur. Im Gegenteil!

"[Ich empfinde] es als absolut notwendig, die Aufgaben der Architektur nicht auf Positionen oder Personen zu restriktieren, sondern sie als allgemeines Aufgabenfeld in der Software-Entwicklung zu betrachten."

"Schlußendlich sollte es in einem agilen Team meiner Auffassung nach das Ziel sein, auch die Aufgaben der Architektur gemeinschaftlich im Team umzusetzen. "

Ich finde Ilkers Beitrag besonnen. Sein Standpunkt gefällt mir. Ich sehe es grundsätzlich genauso. Deshalb ist mir auch wichtig, mit einem Training wie dem für Agile Architektur Entwickler zu adressieren. Wenn alle zusammensitzen und Architektur planen, kommen mehr Ideen zusammen, das geteilte Verständnis für die Architektur steigt und das gemeinsame Verantwortungsgefühl für das Ergebnis ist höher.

Nichts schlimmer als Astronautenarchitekten, die keinen Bezug zur Entwicklung mehr haben. Nichts konfliktträchtiger als Architekturen, die nach dem Motto "friss oder stirb" über einen Organisationszaun den Entwicklern vor die Tastaturen gekippt werden. Die Entfremdung zwischen Architektur und Anforderungen und Code lauert überall.

Und dennoch... Ein bisschen zucke ich noch bei Ilkers Ergebnis. Weil ich fühle, dass was Ilker beschreibt, für mich an den Persönlichkeiten und Kompetenzen der real existierenden Entwickler vorbeigeht. Ich zucke, weil ich eine Differenz zwischen Wollen und Können sehe.

Viele wollen das, was Ilker beschreibt. Es klingt in der Sache richtig und es hat Appeal für die Persönlichkeit vieler Entwickler, die pragmatisch sind und sich nicht lange mit Organisation aufhalten wollen. Sie sind sensibel für die Verluste, die Distanz zwischen den Beteiligten erzeugen kann.

In meiner Beratungs- und Trainingspraxis sehe ich dann allerdings, dass eben nicht alle Entwickler gleich sind. Sie unterscheiden sich in ihrer technischen Kompetenz, sie unterscheiden sich in ihrer Methodenkompetenz, sie unterscheiden sich in ihrem Charakter und in ihren Bedürfnissen. Und das ist ja auch gut so. Teams, die gemischt zusammengesetzt sind, liefern bessere Ergebnisse.

Verschiedenartigkeit ist grundsätzlich zu begrüßen - sie führt aber auch zu Konflikten und es bleiben blinde Flecken. Wie wird das kompensiert? Wer führt Konflikte zu einem Ergebnis? Wer leuchtet blinde Flecken aus?

Für die Konflikte gibt es Moderatoren. Das weiß inzwischen jeder. Die können aus einer Gruppe kommen oder von außen. Sie stellen sicher, dass Gruppentreffen eine zielführende Form haben. Moderator ist gewöhnlich 1 Person. Dass eine Gruppe sich selbst durch gleich verteilte "Eingriffe" aller Mitglieder moderiert, ist eher selten. Meist gibt es einen de facto Moderator, der nicht mal ausgebildet sein muss. Dennoch erkennt ihn die Gruppe an.

Dieses Muster ist akzeptiert. Im besten Fall dominiert dieser Moderator die Gruppe nicht, sondern kann eine Balance halten zwischen seinem Mitgliedsstatus und seiner Moderatorenrolle. Er ist nur temporär Erster unter Gleichen in Bezug auf eine Aufgabe.

Ein Moderator verkörpert den Aspekt "Kommunikationsform", ohne dessen Berücksichtigung das Ergebnis einer Besprechung schnell suboptimal ausfällt.

Ich denke auch, wir können uns darauf einigen, dass nicht jeder die Rolle eines Moderators gleich gerne und/oder gut ausfüllt - selbst wenn der Aspekt allen Gruppenmitgliedern wichtig ist. Es braucht dafür eben eine gewisse Kompetenz.

Und wer leuchtet blinde Flecken aus? Die gibt es ja unweigerlich und sei es nur temporär. Wenn die Diskussion hoch her geht, dann fällt der eine oder andere Aspekt gern mal unter den Tisch. Ein Übriges tut dann das Tagesgeschäft mit seinem Druck in Richtung bestimmter Aspekte - und Ignoranz gegenüber anderen.

Einer dieser Aspekte ist aus meiner Sicht die Architektur. Architektur ist ein nicht-funktionaler Aspekt der Softwareentwicklung. Und darüber hinaus auch noch einer, dessen Qualität nicht so schnell zu einem Feedback vom Kunden führt. Wenn die Performance der Software nicht stimmt oder die Usability, dann sagt steht der Kunde sehr schnell auf der Matte. Rückkopplungszeit Stunden oder Tage.

Wenn aber die Architektur nicht stimmt... dann ist die Rückkopplungszeit Wochen, Monate oder gar Jahre. (Ja, ich glaube, man kann nicht-funktionale Anforderungen wie Performancelimits erfüllen, auch wenn die Architektur suboptimal ist. Das passiert sogar häufig.)

Weil nun die Rückkopplung bei der Architektur vergleichsweise lange auf sich warten lässt, fällt sie leicht unter den Tisch. Manager haben dafür oft wenig Sinn. Sie sind es aber, die sich letztlich durchsetzen. Jedenfalls normalerweise. Heute noch ;-)

Bei gegebener schlechter Ausbildung in puncto Softwareentwurf - das schließt für mich Architektur ein - und gegebenem Tagesgeschäftfokus ist für mich die Realität von Teamsitzungen, dass Architektur schnell zu einem blinden Fleck wird. Nicht sofort, nicht immer, aber tendenziell.

Dazu kommt, dass die Kompetenzen, die für den Entwurf von Software-Architektur nötig sind, nicht gleich verteilt sind bei Entwicklern. Es ist damit wie mit den Moderatorenkompetenzen. Das ist also ganz natürlich.

Und daraus leite ich nun wiederum ab, dass es wichtig ist, darauf zu achten, dass der Aspekt Software-Architektur verlässlich verkörpert wird.

Wie diese Verkörperung aussieht, ist mir egal. Es muss keine Position eines Software-Architekten geben. Es muss auch niemand zwangsläufig fix die Rolle eines Software-Architekten innehaben. An irgendwem muss das Thema jedoch hängen, glaube ich. Und zwar nicht am ganzen Team, sondern an einer Untermenge.

Alle sind mit der Plattform und der Domäne und hoffentlich Clean Code Developer ;-) vertraut. Jenseits dessen beginnen dann allerdings die Unterschiede. Es ist immer so, dass einer die GUI-Technologie besser beherrscht als andere. Und eine kann besser mit dem Build-Tool umgehen als andere. Und manche fühlen sich eher zum Umgang mit Datenbanken hingezogen als andere.

Genauso denkt eine konzeptioneller als andere. Und einem ist das big picture wichtiger als anderen.

Ich glaube, diese ganz selbstverständlichen Unterschiede sollten wir nicht leugnen. Wir sollten auch nicht glauben, sie wegschleifen oder auffüllen zu können. Dafür geht gerade das Thema Software-Architektur zu sehr an Persönlichkeitsmerkmale, die schon früh geprägt werden.

Um also nicht davon überrascht zu werden, dass das kollektive Kümmern um Architektur irgendwie nicht funktioniert hat, sollte jedes Teams schauen, dass es möglichst schnell herausfindet, wie es den Aspekt Architektur am besten verkörpert.

Manchmal mag es einen Entwickler geben, der sich den Schuh anzieht - und die anderen sind froh drüber, dass er sie beim Thema an die Hand nimmt. Manchmal mag es eine kleine Gruppe innerhalb des Teams sein. Oder vielleicht rotiert die Aufgabe durch das Team, so dass bei jeder Besprechung ein anderer das "Architektur-Gewissen" ist?

Eine andere Verkörperung muss natürlich in der Zeit stattfinden. Sie muss für alle Entwickler fester Bestandteil ihrer Wochenkalender sein. Das ist der erste Schritt.

In Summe helfen Experimente. Solange die dafür sorgen, dass die Verkörperung der Architektur nicht in eine außerkörperliche Erfahrung ;-) umschlägt, d.h. abhebt und entfremdet von Code und Anforderungen, solange ist alles erlaubt.

Software-Architektur geht alle an. Da bin ich ganz dabei. Allerdings möchte ich daraus ungern eine zwingende Form ableiten: weder eine Position des Software-Architekten, noch die komplette Abwesenheit jeder Rolle oder anderer Form von Kompetenzkonzentration oder Interessenverteilung. Architekturbewusstsein verkörpern, in geeigneter Form, darum geht es.

Solange am Ende das ganze Team ein solides Verständnis der Architektur hat und sie mitträgt, ist alles gut.

Es geht um Organisationsgesundheit

Was soll das eigentlich mit der Beratung, dem Coaching, dem Training? Das frage ich mich immer öfter. Was will ich damit bewirken? Worum geht es dabei in den Softwareteams? Erneuten Anstoß für diese Überlegungen hat mir ein Zahnarztbesuch vor einiger Zeit gegeben.

Dass ein Training WPF Kompetenz aufbaut oder Clean Code Developer Prinzipien vermittelt oder das Scrum-Rad ins Rollen bringt… das ist offensichtlich, aber nicht, was ich meine. Mir geht es um etwas, das dahinter steht. Denn: Warum soll aufgebaut, vermittelt, ins Rollen gebracht werden?

Ein Begriff fällt mir dazu dann immer wieder ein: Zweck. WPF, CCD, Scrum, TFS, .NET 4.5, XMPP, NoSql sind Mittel des Aspektes Softwareentwicklung in einer Organisation, damit die ihren Zweck erfüllen kann.

Nehmen wir als Beispiel ein kleines Softwarehaus. Das arbeitet seit 6 Jahren mit .NET, vorher mit VB. Erst hat der Chef selbst programmiert, jetzt hat er 6 Entwickler (die natürlich auch Support machen), dazu noch einen Mitarbeiter im Vertrieb und noch jemanden fürs Büro.

Was ist der Zweck dieses Unternehmens?

Ich denke nicht, dass die Antwort lautet, "Geld verdienen". Nein, das ist eben nicht der Zweck. Geld ist ebenfalls nur ein Mittel, um den Zweck zu erfüllen. Ein notwendiges Übel.

Ein möglicher Zweck könnte aber sein "CRM-Software für die PR-Branche herstellen". Aus diesem Grund gibt es das Softwarehaus. Das ist seine Bestimmung, mit der es der Inhaber einmal gegründet hat.

Dass "Geld verdienen" nicht zum Zweck gehört, wird Ihnen auch klar, wenn Sie einmal annehmen, dass die Firma immer noch nötig wäre, wenn ein Milliardär auf die Idee käme, sie aus seiner Portokasse einfach so zu finanzieren. Jedes Jahr bekäme der Geschäftsführer einen Scheck über 1.000.000 EUR zugestellt, der es ihm erlaubte, alle Kosten zu decken. Umsatz wäre nicht mehr zu machen. Und dennoch wären weiterhin alle Mitarbeiter nötig; Software würde immer noch geschrieben werden müssen. Denn sonst könnte der Zweck nicht erfüllt werden. Nur könnte die Software dann verschenkt werden.

Leider müssen die meisten Unternehmen ohne einen solchen Mäzen auskommen. Deshalb ist Umsatz nötig. Das bedeutet aber nicht, dass Geld verdienen der Zweck des Unternehmens ist. Der Zwang zum Umsatz ist vielmehr eine zu berücksichtigende Bedingung, unter der der Zweck erfüllt werden muss. Andere Bedingungen sind, dass Software durch Menschen hergestellt wird oder dass sie Marketing braucht, um ihre Anwender zu finden, oder dass jährlich eine Bilanz zu erstellen ist.

Der Zweck von etwas, ist diesem Etwas inhärent. Er gehört zu ihm, klebt an ihm, kommt und geht mit ihm. Deshalb ist auch "Den Lebensunterhalt sichern" kein Unternehmenszweck. Die Formulierung drückt vielmehr aus, dass das Unternehmen von jemandem als Mittel gesehen wird. Damit wird es austauschbar. Wer einen großen Lottogewinn macht, braucht das Unternehmen nicht mehr, um seinen (!) Zweck zu erfüllen.

Mir geht es ja aber eben nicht um den Zweck einer Person (oder ihr Sinnempfinden), sondern um den Zweck einer Organisation. Der kann nur in ihr stecken bzw. aus ihr heraus sich entwickeln.

Nun zurück zur Ausgangsfrage: Was soll das eigentlich mit der Beratung, dem Coaching, dem Training?

Ich denke, dabei geht es immer mehr oder weniger direkt darum, dass eine Organisation ihren Zweck besser erfüllen kann - und zwar im Rahmen gewisser Bedingungen. Innerhalb einer Umwelt bestehend aus einer Vielzahl von Bedingungen soll es der Organisation also besser gehen. Das bedeutet für mich: es geht um Gesundheit.

Ja, genau, mir scheint deshalb, mein Job ist sozusagen der eines Arztes oder Therapeuten für Organisationen.

Damit will ich mir nun keinen besonderen Nimbus andichten und ich brauche weder Kittel noch Stethoskop. Mit der Wahl der Analogie versuche ich lediglich, besser zu verstehen, was Organisationen für Probleme haben und wie die gelindert werden könnten.

Das erste, was aus der Analogie folgt ist - auch wenn es sich nicht schön anhört -, dass, wenn irgendwo der Schuh drückt und "der Berater" gerufen wird… dass dann die Organisation wohl krank ist. Das muss ja nicht immer gleich ein Herzinfarkt sein; Menschen gehen auch mit einem Schnupfen zum Arzt. Aber krank ist eben krank. Die Organisation leidet. Irgendetwas schmerzt - und zwar so sehr, dass man Hilfe sucht.

Aber was ist Krankheit? Oder umgekehrt: Wann ist eine Organisation nicht krank, sondern gesund? Was ist Gesundheit?

Mit der Frage begebe ich mich natürlich in einen Sumpf. Es gibt soviele Definitionen für Gesundheit. Allen voran die der WHO, die so allgemein ist, dass sie mir untauglich erscheint. Denn danach, so scheint mir, kann es keine gesunden Menschen geben:

“Gesundheit ist ein Zustand vollständigen körperlichen, psychischen und sozialen Wohlbefindens und nicht nur das Freisein von Beschwerden und Krankheit.”

Deshalb versuche ich mich einmal an einer eigenen kleinen pragmatischen Definition. Für meine Arbeit als Berater/Coach/Trainer möchte ich ja zumindest eine Chance haben, Gesundheit bei meinen Kunden herzustellen.

Gesundheit braucht Kontext

Zu meinen Gesundheitsbegriff, der ja auch nicht für Menschen, sondern Organisationen gedacht ist, gehört zunächst der Zweck. Gesundheit gibt es nur im Hinblick auf einen Zweck.

Und Gesundheit gibt es nur im Hinblick auf eine Umwelt, d.h. Bedingungen unter denen der Zweck erfüllt werden soll.

Mithin ist Gesundheit ein relativer Begriff. Ob eine Organisation gesund oder krank ist, kann nur beurteilt werden, wenn man Zweck und Umwelt kennt. "Organe" oder Kompetenzen nach einer absoluten Checkliste abzuhaken, kann zu falscher Diagnose führen.

• Analogie Tierwelt: Ist ein Tier krank, wenn es nicht sehen kann? Nicht unbedingt. Wenn es seinen "Lebenszweck" in seiner Umwelt problemlos ohne Sehfähigkeit erfüllen kann, ist es nicht krank, wie der Grottenolm beweist.
• Beispiel Unternehmen: Ist ein Unternehmen krank, wenn es sich nicht mit Social Media auskennt? Nicht unbedingt. Wenn es seinen Zweck in seiner Umwelt problemlos ohne Social Media erfüllen kann, ist es nicht krank. Lebender Beweis ist Schuhmacher Schwartau in meinem Stadtteil in Hamburg.

Gesundheit braucht Funktionstüchtigkeit

Bei gegebenem Zweck in gegebener Umwelt stellt sich natürlich die Frage, ob eine Organisation überhaupt in der Lage ist, ihn zu erfüllen. Kann sie, was immer erforderlich sein mag? Ist die Organisation grundsätzlich funktionstüchtig?

Wenn der Zweck eines Unternehmens Schuhreparatur ist, aber niemand weiß, wie das geht… dann ist das Unternehmen fundamental krank. Ob das eine somatische oder eher eine psychische Krankheit genannt werden sollte, lasse ich mal dahingestellt.

Wenn Schuhmacherkompetenz vorhanden ist, aber das Unternehmen über seine Verhältnisse lebt, also mehr ausgibt als einnimmt… dann ist das Unternehmen ebenfalls krank. Es fehlt ihm die Fähigkeit mit einem Aspekt der Umwelt umzugehen.

Zur Gesundheit gehört also auch, dass Methoden, Techniken, Werkzeuge in geeigneter Weise bedient werden können. Welche das sind, bestimmen nur Zweck und Umwelt. Es gibt keine Pflicht zu Social Media, Cloud Computing, NoSql, Mobile Clients, Kanban, Selbstorganisation usw. Sie sind lediglich Mittel zur Erfüllung des Zwecks unter bestimmten Bedingungen. Und wenn nicht klar erkennbar ist, wie das eine oder andere Mittel den Zweck befördert oder den Umgang mit Bedingungen verbessert, dann muss es nicht genutzt werden.

Zur Funktionstüchtigkeit gehört natürlich auch, dass die "Organe" eines Unternehmens angemessen verbunden sind. Gesunde Organe verpackt in Transplantationsbehälter nützen nichts. Sie müssen in einem Rahmen, Körper, aufgehängt sein, der ihr Zusammenspiel in Hinsicht auf den Zweck befördert. Auch das ist eine Kompetenz der Organisation, auch das ist wiederum ein "Organ".

Krankheit ist somit nicht notwendig das Problem eines Teiles. Wenn das Schuhreparaturgeschäft nicht läuft und der Schuhmacher sich nicht an Damenschuhe herantraut, dann ist die Diagnose einfach, falls das Geschäft nicht läuft. Hier führt ein Teil zur Krankheit des Ganzen.

Wenn aber Schuhannahme, Schuhreparatur und Reparaturausgabe eigentlich kompetent sind und es trotzdem nicht läuft… dann kann es noch daran liegen, wie sie im Firmenrahmen verdrahtet sind. Falls nämlich die Übergabe der Schuhe zwischen den Funktionen mittels eines großen Haufens geschieht, weil die Geschäftsführung kein Geld für Regale ausgeben will… dann kann es zu unschönen Verzögerungen kommen, weil Aufträge nicht geordnet abgearbeitet werden. Hier führt der Rahmen zur Krankheit des Ganzen.

Ein anderes Beispiel für ein Problem im Rahmenwerk könnte sein, dass der Chef verlangt, dass der Schuhmacher jedes Mal, wenn er eine Reparatur beginnt/beendet, zu ihm in den 4. Stock heraufkommt. Es muss doch kontrolliert werden, dass der Schuhmacher immer beschäftigt ist. Wenn der also nicht alle 15-20 Minuten im 4. Stock zu sehen ist… dann trödelt er. [1]

Aber stopp: Ich habe gesagt, dies sei ein Beispiel für ein Problem. Ist das aber gewiss? Die Regel hört sich nicht zweckförderlich an - doch vielleicht gibt es Bedingungen, unter denen sie nicht schädlich für die Gesundheit des Unternehmens ist. Ich denke, dafür müssen wir offen sein, bis wir Zweck und Bedingungen genau kennen. [2]

Gesundheit braucht Kompensationsfähigkeit

Alles wäre ja gut, wenn Zweck sowie Bedingungen einmal klar gemacht werden könnten, um dann einmal die Funktionstüchtigkeit darauf abzustellen.

So ist die Welt aber nicht. Unternehmen laufen nicht auf Schienen. Die Umwelt ist ständig in Bewegung. Am Zweck mag ein Unternehmen von sich aus festhalten können; doch die Bedingungen, unter denen es ihn erfüllen muss, wandeln sich. Mal gemächlich, mal plötzlich.

Zur Funktionstüchtigkeit muss daher noch eine weitere Eigenschaft kommen: Kompensationsfähigkeit. Und eben die habe ich beim Zahnarztbesuch im Gespräch kennengelernt.

Gesund ist ein System, wenn es Störungen kompensieren kann. Sich verändernde Bedingungen sollten die Zweckerfüllung möglichst nicht sofort kompromittieren.

In dieser Hinsicht finde ich die Definition von Gesundheit der WHO unzureichend. Sie sagt, ich sei gesund, wenn ich in vollständigem Wohlbefinden in meinem Bett liege.

Was aber, wenn ich dann aufstehen will und das nicht kann, weil meine Muskeln atrophiert sind oder mein Kreislauf versagt? Klar, dann bin ich nicht mehr gesund. Ich fühle mich nicht mehr wohl. Aber Sekunden vorher war ich es noch still liegend im Bett?

Kaum. Denn wenn mich ein völlig üblicher Bewegungswunsch über die Grenzen meiner Leistungsfähigkeit bringt, dann kann ich nicht gesund sein. Ein gesunder menschlicher Körper kann den Wechsel von Bettruhe zu Aufstehen kompensieren. Ein gesunder Körper kann auch die plötzliche Anforderung, das Ausrutschen auf einer Bananenschale zu kompensieren, mühelos erfüllen. Ebenso kann ein gesunder Körper eingedrungene Schnupfenviren kompensieren.

Gesundheit ist mehr als die Abwesenheit von Schnupfen. Sie ist die Anwesenheit von Kompensationsfähigkeit - so dass Schnupfen gar nicht erst entsteht.

Krankheit im üblichen Sinn ist also erst die Folge eines vorherigen Mangels an Kompensationsfähigkeit. Für mich beginnt Krankheit im unüblichen Sinn deshalb schon früher. Krank ist ein System schon dann, wenn es Kompensationsfähigkeit nicht aufgebaut hat oder verliert.

Wie viel Kompensationsfähigkeit nötig ist, hängt wieder vom Zweck im Rahmen einer Umwelt ab. Hier müssen Annahmen gemacht werden. Von einem Erwachsenen erwarten Sie zurecht, denke ich, dass er den Sturz über eine Bananenschale kompensieren kann. Ein Sturz aus 10m Höhe jedoch liegt jenseits gesunder Kompensationsfähigkeit.

Hier wird nun der Zweck von Angst deutlich. Sie bewahrt uns vor Situationen, die unsere Kompensationsfähigkeit übersteigen. Wir haben Angst, wenn wir am Rande einer 10m hohen Klippe ohne Brüstung stehen; deshalb vermeiden wir solche Situationen oder sind dann zumindest sehr vorsichtig. Aber wir haben keine Angst, unser Haus zu verlassen - auch wenn es sein kann, dass wir auf dem Bürgersteig auf einer Bananenschale ausrutschen.

Kompensationsfähigkeit bedeutet, Puffer zu haben. Das können physische oder psychische sein. Ein physischer Puffer ist Muskelkraft oder Fett. Ein psychischer ist Humor oder ein religiöser Glaube.

Und bei Unternehmen? Da sind zum Beispiel Geld, Motivation, Lagerbestände oder schlicht Überkapazitäten jeder Art Puffer.

Wo Geld vorhanden ist, da kann eine Umsatzdurststrecke abgepuffert werden. Wo Motivation vorhanden ist, da kann eine Auftragsspitze durch Mehrarbeit abgefedert werden. Wo Lagerbestand vorhanden ist, da kann eine Nachfragespitze ohne Verzögerung befriedigt werden. [3]

Zwischenstand

Bei der Beratung im weitesten Sinne geht es aus meiner Sicht immer um die Gesundheit des Unternehmens. Sie soll verbessert werden. [4]

Diese Analogie hilft mir. Ich finde sie pragmatisch. So liefert mir die Analogie z.B. eine Analysecheckliste. Wenn ein Unternehmen über Probleme klagt, kann ich schauen, wo die liegen:

• Mangelt es an Zweckverständnis?
• Mangelt es an Bedingungsverständnis?
• Mangelt es an der Fähigkeit, Bedingungen zu bewältigen?
• Mangelt es an Funktionstüchtigkeit?
• Mangelt es an Kompensationsfähigkeit?

Und daraus kann ich dann "Therapievorschläge" ableiten.

Ebenso ist die Analogie für mich eine Brille, durch die ich auf Tools, Technologien, Methoden, Konzepte schauen kann. Ich kann sie klassifizieren. Ich kann beurteilen, zu welchem Gesundheitsaspekt sie etwas beitragen. Wird mit WPF die Funktionstüchtigkeit erhöht oder das Zweckverständnis? Trägt Scrum etwas zur Bewältigung von Bedingungen bei oder steigt damit die Kompensationsfähigkeit?

Sicherlich hat jede Analogie ihre Grenzen. Aber derzeit glaube ich noch nicht, dass die bei der Gesundheitsanalogie erreicht sind. Sie scheint mir vielmehr gerade in puncto Kompensationsfähigkeit noch einiges zu bieten. Darüber muss ich weiter nachdenken.

Einstweilen können Sie sich ja mal fragen: Wie gesund ist das Team, das Unternehmen, in dem Sie arbeiten?

Fußnoten

[1] Oder ist es müßig, zwischen Rahmen und darin aufgehängten "Organen" zu unterscheiden? Am Ende sind Rahmen und "Organe" ein Ganzes und gleichberechtigt. Ohne Rahmen kein Ganzes, keine Zweckerfüllung nur durch die "Organe". Und ohne "Organe" nützt der schönste Rahmen auch nichts.

[2] In diesem Zusammenhang fällt mir die Agilität ein. Auch wenn ich meine, dass agile Entwicklung gesundheitsförderlich für viele Softwareentwicklungsorganisationen ist, so muss ich offen dafür sein, Zwecke und Bedingungen kennenzulernen, unter denen das nicht gilt. Deshalb ist es mir wichtig hinter die Fassade von Methoden und Konzepten zu schauen. Ich möchte verstehen, Mittel zur Bewältigung welcher Umweltbedingungen sie sind.

Hype entsteht insofern immer dann, wenn Mittel empfohlen werden ohne Ansehen ihrer Bindung an Zwecke oder Bedingungen.

[3] Nach fest kommt ab. Das kennen Sie als Heimwerker, oder? Ich denke, es gilt aber genauso: nach schlank kommt krank.

Denn wo der Schlankheitswahn im Unternehmen um sich greift, wo gekürzt und beschnitten wird, um Kosten zu reduzieren… da kann Gesundheit unbemerkt in Magersucht umschlagen - und der Patient hat typischerweise keine Krankheitseinsicht. Wo Puffer konsequent verkleinert werden, droht die Kompensationsfähigkeit zu leiden - und damit die Gesundheit. Auch und gerade, wenn doch heute noch alles zu funktionieren scheint.

Die nächste Änderung der Bedingungen kommt gewiss… Dann ist die Frage, ob die Organisation sie kompensieren kann.

[4] Ich bin übrigens nicht der einzige, der sich "im Dienste der Gesundheit von Unternehmen" fühlt. Bob Marshall, dessen Blog Think Different ich sehr schätze, bezeichnet sich schon als Therapeut und denkt über organizational health nach.

In dieselbe Richtung zielt das Buch "The Advantage" von Patrick M. Lencioni.

Und auch das Buch "Working Whole Systems" von Julian Pratt et al., das Organisationen als lebendig beschreibt, geht für mich in dieselbe Richtung.