Follow my new blog

Dienstag, 8. Dezember 2015

Teaser: Der dunkle Bruder des Feedback

Feedback ist nötig. Umso mehr, je unsicherer ist, was eigentlich geleistet werden soll und ob man das schon geleistet hat. Deshalb sind in der Agilität zwei Feedbackschleifen explizit institutionalisiert: Durch automatisierte Tests bekommen Entwickler innerhalb von Sekunden oder Minuten Feedback, ob Veränderungen zu Regressionen geführt haben. Durch Reviews des Implementierten mit Stakeholdern am Ende kurzer Iterationen bekommen Entwickler Feedback innerhalb von Tagen oder wenigen Wochen, ob sie ihr Werkstück näher an die Zielvorstellung jener heranentwickelt haben.

Mit der Agilität ist das Feedback aus dem Schatten von Gevatter Plan getreten. Das ist eine zentrale Leistung der Agilität.

Doch irgendetwas stimmt nicht. Es herrscht jetzt nicht einfach Friede. Die Entwicklung schreitet nicht einfach zügig voran. Ganz merkwürdig zagt und stolpert sie immer noch – trotz des klaren, sauberen Anführers Feedback.

Das liegt an einer Kraft, die bisher unbenannt ist. Sie beeinflusst den Fortschritt stark, doch niemand benennt sie so recht. Alle kennen sie, aber man räumt ihr keinen gleichwertig offiziellen Platz neben dem Feedback ein. Ich will sie deshalb den dunklen Bruder des Feedback nennen.

[Lesen Sie weiter in meinem neuen Blog…]

Neue RSS-Feeds

Seit Oktober 2015 schreibe ich sowohl meine deutschen wie meine englischen Blogartikel nur noch im neuen konsolidierten Blog direkt auf meiner Homepage.

Wenn Sie über neue Artikel automatisch informiert werden wollen, abonnieren Sie doch einen meiner RSS-Feeds oder folgen Sie mir bei Twitter.

Freitag, 4. Dezember 2015

Teaser: Microservices verbinden in Datenflüssen

Mir hat der Blogartikel von Tobias Flohre gut gefallen, in dem er die Kommunikation zwischen Microservices mit asynchronen Events beschreibt. Er tut das als Gegenentwurf zu einer Darstellung mit BPMN und einer Implementation auf der Basis einer Workflow-Engine.

Entkoppeln mit Events

Gut gefallen hat mir der Artikel, weil Tobias damit eine Lanze für das Principle of mutual Oblivion (PoMO) bricht. Es besagt, dass Funktionseinheiten in Software nicht funktional abhängig von einander sein sollen. Logik in der einen sollte Logik in der anderen nicht kennen, nicht nutzen. Jede Funktionseinheit sollte vielmehr quasi selbstvergessen “nur ihr Ding machen” und sich nicht um die Umwelt scheren. So tut das in einem Organismus jede Zelle; warum also nicht auch jede Funktionseinheit in einer Software? (Das ist aus meiner Sicht sogar, was Alan Kay ursprünglich unter Objektorientierung verstanden hat. Hier dazu eine Artikelserie von mir: OOP as if you meant it.)

Ich schreibe hier bewusst “Funktionseinheit”, weil ich auf konzeptioneller Ebene spreche. Eine Funktionseinheit kann im Code eine Funktion oder eine Klasse… oder eben auch ein Microservice sein. Eben ein Modul als Träger von Verhalten herstellender Logik.

Eine PoMO-konforme Funktionseinheit bekommt von irgendwoher “etwas”, arbeitet daraufhin und liefert anschließend “etwas anderes” ab. Woher “etwas” kommt, wohin “etwas anderes” geht, das ist der Funktionseinheit einerlei. Das mag seltsam klingen – doch Sie sind damit ganz vertraut. Jede Funktion T f<S,T>(S s) arbeitet so.

Hier ein Beispiel für eine solche Funktionseinheit aus Tobias’ Artikel:

[Lesen Sie den ganzen Artikel in meinem neuen Blog…]

Neue RSS-Feeds

Seit Oktober 2015 schreibe ich sowohl meine deutschen wie meine englischen Blogartikel nur noch im neuen konsolidierten Blog direkt auf meiner Homepage.

Wenn Sie über neue Artikel automatisch informiert werden wollen, abonnieren Sie doch einen meiner RSS-Feeds oder folgen Sie mir bei Twitter.

Donnerstag, 3. Dezember 2015

Teaser: Ziele erreichen mit tugendhafter Emergenz

Manche Ziele scheinen mir so schwer erreichbar, dass ich denke, man kann sie gar nicht direkt erreichen.

Wie sieht es mit einem erfolgreichen Unternehmen aus? Oder was tun, um Software stets wandlungsfähig zu halten? Kann man auf diese Ziele Maßnahme für Maßnahme zugehen?

Probleme zentraler Steuerung

Es wird schwer, auf ein Ziel zuzusteuern, wenn man die dafür relevanten Teile und Aktivitäten nicht mehr überblickt. Solange man sie überblickt, kann man versuchen, sie direkt anzusteuern. Jenseits des Überblicks jedoch… das stellt sich schnell ein Gefühl des Kontrollverlustes ein – umso mehr, je stärker man glaubt, doch eigentlich zu wissen, was zu tun nötig ist.

Unabhängig vom Überblick kann es aber auch an Zeit mangeln. Selbst wenn eine zentrale Instanz wüsste, wie Teile zu steuern wären, kann es schlicht zu lange dauern, sie zu informieren und auf Antwort zu warten, um angemessen schnell zu reagieren.

Und schließlich noch die Inkompetenz. Egal wie groß die Zahl der Teile und wie lang die Kommunikationswege: wenn die Komplexität wächst, werden in Bezug zu ihr zentrale Entscheider zunehmend inkompetent. Sie können einfach nicht mehr wissen, was zu tun ist, um gewünschte Zustände durch konkrete Steuerungsmaßnahmen zu erreichen. Das ist nur möglich, solange die Situationen kompliziert sind.

[Lesen Sie weiter in meinem neuen Blog…]

Neue RSS-Feeds

Seit Oktober 2015 schreibe ich sowohl meine deutschen wie meine englischen Blogartikel nur noch im neuen konsolidierten Blog direkt auf meiner Homepage.

Wenn Sie über neue Artikel automatisch informiert werden wollen, abonnieren Sie doch einen meiner RSS-Feeds oder folgen Sie mir bei Twitter.

Dienstag, 1. Dezember 2015

Teaser: Bereiche der Schätzbarkeit

In den letzten beiden Tagen habe ich mal wieder zusammen mit Andrea Kaden einen Zeitmanagement-Workshop für Softwareentwickler gegeben. Natürlich kamen wir dabei auch auf das Thema Schätzung. Das treibt Entwickler immer wieder und immer noch sehr um. Sie empfinden schlicht großen Stress, wenn es vorhersagbar nicht klappt, Schätzungen einzuhalten. Sie fühlen sich unwohl, zur Unehrlichkeit gezwungen zu werden.

Das verstehe ich sehr gut. Deshalb bemühe ich mich, Hilfestellung bei diesem Thema zu geben. Ich versuche zu erklären, warum es mit dem Schätzen schwer bis unmöglich ist. Ich versuche, einen alternativen Weg aufzuzeigen, auch ohne Schätzungen verlässlich wertvolle Software herzustellen. Ich verweise auf andere, die auch versuchen, Entspannung zu vermitteln.

Deshalb heute auch dieser Blogartikel. Ein weiterer Versuch, Softwareschätzungen besser verständlich zu machen. Und zwar ausgehend von einer Analogie.

[Lesen Sie weiter in meinem neuen Blog…]

Neue RSS-Feeds

Seit Oktober 2015 schreibe ich sowohl meine deutschen wie meine englischen Blogartikel nur noch im neuen konsolidierten Blog direkt auf meiner Homepage.

Wenn Sie über neue Artikel automatisch informiert werden wollen, abonnieren Sie doch einen meiner RSS-Feeds oder folgen Sie mir bei Twitter.

Freitag, 27. November 2015

Teaser: Tests als evolutionäre Kraft

Warum sollte Software eigentlich eine bestimmte Struktur haben? Weil sie mit dieser Struktur den Kräften, die an ihr wirken, am besten standhalten kann.

Dass Software gewünschte Funktionalität zeigt, hat nichts mit ihrer Struktur zu tun. Dass Software gewünsche Effizienzen zeigt (z.B. Performance, Sicherheit), hat in vielen Fällen auch nichts mit ihrer Struktur zu tun. Für Funktionalität wie Effizienzen ist lediglich Logik verantwortlich – und die braucht keine Struktur, um ihren Effekt zu entfalten.

Das ist leicht zu verstehen, wenn Sie daran denken, dass im finalen Maschinencode all Ihre schönen Strukturen ja nicht mehr zu finden sind und die Software trotzdem das gewünschte Verhalten zeigt.

Was verstehe ich unter Struktur? Elemente, die in Beziehung stehen. Also eine gewisse Anordnung von Dingen. Diese “Dinge” in der Software sind zunächst einmal Module, d.h. Funktionen, Klassen, Bibliotheken usw. Und die Beziehungen zwischen ihnen sind vor allem Nutzungsbeziehungen: ein Modul kennt ein anderes, um dort eine Dienstleistung zu nutzen.
(Datenstrukturen lasse ich hier ausdrücklich aus. Die arrangieren ja keine Logik, sondern eben Daten.)

Und was sind die Kräfte, die auf die Softwarestruktur wirken? Veränderungen. Softwarestruktur soll Code wandelbar machen.

Wandelbar ist Code, wenn er leicht verständlich ist, wenn sich Veränderungen zur Herstellung neuer Funktionalität oder Effizienz leicht anbringen lassen und wenn man leicht feststellen kann, ob das Neue schon korrekt implementiert ist wie auch das Alte immer noch korrekt arbeitet. Testbarkeit ist mithin ein Kriterium für Wandelbarkeit. Tests sind ein Teil der Kraft, die auf Softwarestrukturen einwirken.

In Bezug auf Tests habe ich mich nun gefragt, wie sich Strukturen dadurch verändern? Wie setzt Software Tests möglichst wenig Widerstand entgegen?
Mir scheint es da eine natürliche Entwicklung zu geben, quasi eine Evolution.

[Mehr lesen Sie in meinem neuen Blog…]

Neue RSS-Feeds

Seit Oktober 2015 schreibe ich sowohl meine deutschen wie meine englischen Blogartikel nur noch im neuen Blog direkt auf meiner Homepage.

Wenn Sie über neue Artikel automatisch informiert werden wollen, abonnieren Sie doch einen meiner RSS-Feeds oder folgen Sie mir bei Twitter.

Samstag, 10. Oktober 2015

Gelebte inkrementelle Dekomposition

Neulich war große Freude. Ein Produktentwicklungsteam eines Kunden zeigte mir, wie es meinen Vorschlag eines anderen Umgangs mit Anforderungen umsetzt - und dadurch flüssiger arbeitet.

Inkrementelle Dekomposition

Mein Vorschlag war und ist, Anforderungen des Kunden bzw. die User Stories eines Product Owners nach einem Schema “zu zermahlen”, um für die weitere Entwicklung sehr präzise Ausgangspunkte zu bekommen.

Ausführlicher habe ich dieses Schema in einem früheren Artikel beschrieben. Deshalb skizziere ich es hier nur noch und stelle es in einen Prozesszusammenhang.

Für mich sieht ein Teil des Softwareproduktionsprozesses so aus:

image

Ein Strom von unstrukturierten Anforderungen wird von einem Product Owner im Rahmen eines so genannten Story Development durchgekaut und in User Stories transformiert. Die sind klein, konkret, wertorientiert, priorisiert.

Allerdings sind User Stories rein aus der Sicht von Kunde/Anwender formuliert. Die Programmierung kann sie nicht einfach implementieren. Vielmehr muss darauf eine Vorverarbeitung stattfinden.

Entwickler (und Tester) sitzen dafür zunächst mit dem Product Owner zusammen und analysieren die User Stories. Bisher hat ja nur der Product Owner verstanden, was zu tun ist. Dieses Wissen muss in die Köpfe der Programmierer übertragen werden. Das bedeutet, die Welt des Problems muss an die Welt der Lösung angeschlossen werden. Es müssen Bezüge hergestellt werden, ein Mapping stattfinden.

Mit meinem Ansatz plädiere ich dafür, die User Stories “in einen Problemtrichter zu stopfen”, aus dem unten einzelne Funktionen mit zugehörigen Akzeptanzkriterien heraustropfen.

User Stories stellen die Anforderungen in Form von Inkrementen vor, d.h. für den Kunden wertvolle Zuwächse an Funktionalität oder Effizienz. Slices sind Inkremente mit konkretem Bezug zur Welt der Codierung, d.h. der Lösung.

Die Problemanalyse transformiert einen Strom von User Stories also in einen Strom von Slices unterschiedlicher Dicke. Hier die Liste der wichtigsten Slices mit den ihnen entsprechenden Programmierartefakten (Module):

  • Anwendung = Bibliothek
  • Dialog = Klasse
  • Interaktion = Funktion
  • Feature = Funktion

Jede User Story entspricht dann in der Hierarchie der Slices einem oder mehreren Pfaden der Form Anwendung/Dialog/Interaktion/Feature. Das ist für die weitere Programmierung sehr, sehr viel konkreter, als eine User Story. Die Programmierung fühlt sich auf diese Weise weniger allein gelassen mit Verständnis und Übersetzung von Anforderungen. Ja, die Programmierung bekommt durch die gemeinsame Problemanalyse mit dem Product Owner sogar schon konkrete Hinweise auf eine minimale Modularisierung des Codes. Und die spiegelt dann auch noch das agile Vorgehen wider.

Während üblicherweise User Stories nach der Implementation nicht mehr im Code zu erkennen sind, bleiben bei diesem Vorgehen Inkremente als Artefakte im Code erhalten. Das ist von unschätzbarem Wert für die Nachvollziehbarkeit und Verständlichkeit von Code.

Der ursprüngliche Strom von Anforderungen wird also in zwei Schritten zerlegt in Inkremente (inkrementelle Dekomposition):

  1. Story Development -> User Stories
  2. Problemanalyse -> Slices

Beide zusammen dienen der Qualitätssicherung des Input in die weitere Programmierung. Das ist wichtig, da einer der häufigsten Engpässe bei der Softwareproduktion die Implementation oder die anschließende QA ist. Hohe Inputqualität für den Engpass ist Voraussetzung für hohe Qualität seines Output. Und die ist wichtig, damit der Engpass später nicht mit Nachbesserungen belastet wird.

Soweit die Theorie. Jetzt die Praxis.

Im realen Projekt

Als Trainer in Sachen flüssige Softwareproduktion und Clean Code Development stelle ich diese Vorgehensweise vielen, vielen Entwicklern vor. Wir üben sie dann tapfer in Workshops. Doch die Übertragung solcher “Theorie” in den Arbeitsalltag fällt den Teilnehmern immer wieder sehr schwer. Über die Gründe kann man diskutieren und lamentieren - aber nicht heute. Heute möchte ich zur Abwechslung zeigen, wie der Transfer eben auch klappen kann.

Das Team bei meinem Kunden besteht im Wesentlichen aus 2 Entwicklern, 3 Testern und 1 Product Owner. Beide Entwickler hatten an 2 Schulungstagen der Clean Code Developer School teilgenommen, an denen wir uns auf den Umgang mit Anforderungen konzentriert hatten. Dann am Ende des dritten Schulungstages luden sie mich ein, sich ihre Umsetzung des Lernstoffes in ihrem team room einmal anzusehen.

An der Wand sah ich dort diesen Notizenbaum:

image

Die Anwendung, an der das Team arbeitet, steht außer Frage. Die muss nicht explizit modelliert werden.

Der Dialog, auf den sich die (derzeit) zu realisierenden User Stories beziehen, steht ebenfalls außer Frage. Die ganze Wand konzentriert sich auf diesen Dialogentwurf:

image

Aus diesem Grund ist der Dialog auch nicht an der Wand zu sehen. Das finde ich verständlich, aber meine Empfehlung ist, ihn dennoch dort ebenfalls zu visualisieren. Dadurch wird jedes Denken über Slices konkreter. Bei Diskussionen kann man leichter Bezug nehmen, um über Interaktionen und Features zu sprechen. Niemand muss im Zweifelsfall in irgendwelchen Dokumenten nach dem aktuellen Stand des Dialog-Layouts suchen.

Aber auch ohne Dialog finde ich die Darstellung an der Wand klasse. Dort sind nämlich die von mir vorgeschlagenen Slices systematisch als Baum zu sehen:

  • Quer über die Wand stehen grüne Karten für Interaktionen des Dialogs. Jede lässt sich einem Button oder dem Klick auf eine Liste usw. zuordnen.
  • Senkrecht stehen orange und gelbe für Features der jeweiligen Interaktion. Die Darstellung der Feature-Hierarchie ist an der Wand leider begrenzt. Mit Farben wurden zwei Ebenen unterschieden und es gibt eine gewisse physische Unterordnung. Letztlich kommt hier der Umgang mit Kärtchen aber an seine Grenzen. Doch das Team ist kreativ mit seinen Mitteln umgegangen. Super!

An diese Wand kann ich herantreten, eine beliebige Karten auswählen und bin sicher, dafür eine Entsprechung im Code zu finden. Da es sich um Interaktionen und Features handelt, gibt es für jede 1 Funktion im Code.

Das ist die Sicht der Entwickler. Gleichzeitig stellt jede Karte aber auch noch Wert für den Product Owner dar! Alle Karten repräsentieren Inkremente. Zu allen Karten kann der Product Owner Feedback geben, ob das gewünschte Verhalten schon nach seinem Geschmack umgesetzt wurde.

(Zu dieser Regel gibt es nur eine Ausnahme: Die zweite grüne Karte von Links steht nicht für eine Interaktion sondern für die Datenstruktur des Dialogs, d.h. für die Steuerelemente mit den zugehörigen Datentypen und einige Validationsregeln. Dass dies visualisiert wird, ist natürlich eine gute Sache. Doch ich empfehle eine deutliche Unterscheidung von den Slices, z.B. durch räumliche Trennung oder andere Farben.)

Diese Systematik zu sehen, hat mich schon begeistert. Doch das Team zeigte mir noch mehr. Es setzt nämlich auch meine Empfehlung um, einzelne Features dem Product Owner über einen Prüfstand zum Feedback vorzulegen.

Hier der Prüfstand für den Cluster von Features, den ich an der Wand hervorgehoben habe:

image

Der Product Owner (oder auch ein Tester) kann mit dem Prüfstand wie mit einer speziellen Messsonde gezielt einen kleinen Teil des Gesamtverhaltens prüfen, ohne die ganze Anwendung oder auch nur den ganzen Dialog zu bemühen.

Das macht erstens das Feedback einfacher. Zweitens wird der Product Owner damit frei, sich Features in quasi jeder beliebigen Reihenfolge zu wünschen. Und drittens können Features, Interaktionen, Dialoge nun viel einfacher parallel entwickelt werden.

Voraussetzung für den Prüfstand ist, dass Inkrement-Wünschen des Product Owners sehr konkrete Artefakte der Programmierung zugeordnet sind. Genau das leistet die inkrementelle Dekomposition mit der Herstellung von Slices jedoch.

Das Fazit von Entwicklern wie Testern sowie Product Owner bisher: die Softwareproduktion ist viel flüssiger geworden.

Darüber freue ich mich sehr! Und ich bin überrascht. Denn so eine pragmatische und zügige Umsetzung des in der CCD School vorgestellten Ansatzes hatte ich bisher noch nicht gesehen. Hier zeigt ein Team, was möglich ist, wenn man echt etwas verändern will. Die Initiative zweier motivierter Entwickler reichte aus, die anderen Teammitglieder waren offen für eine Veränderung und die Führungsebene darüber hat den Freiraum zu solcher Selbstorganisation gegeben.

Drei notwendige Faktoren sind bei diesem Kunden also glücklich zusammengekommen. Super!

Mehr Fluss, mehr Produktivität sind möglich mit systematischerer Softwareproduktion. Das so deutlich zu sehen, spornt mich an, nicht nachzulassen bei der Vermittlung von und Suche nach besseren Methoden.

Mittwoch, 9. September 2015

Eine Chance zur Integrationshilfe

Eigentlich ist für mich als Hamburger die Flüchtlingswelle, die nach Deutschland fließt, eine recht abstrakte Größe. Am Straßenbild hat sich für mich bisher nichts verändert. Menschenbunt ist Hamburg schon lange. Nur die Medien hatten mir bisher davon berichtet, was da so zukunftsverändernd gerade massiv passiert.

Jedenfalls bis neulich. Denn da habe ich Nour Saeed aus Syrien kennengelernt.

image

Aber der Reihe nach: Eigentlich hatte ich ein kleines Programmierprojekt, das ich outsourcen wollte. Zuerst wollte ich den Entwickler in Indien wieder engagieren, mit dem ich schon einmal zusammengearbeitet hatte. Doch dann überlegte ich, dass dies vielleicht eine Chance sei, einem Flüchtling zu helfen. Unter denen gibt es doch bestimmt auch Softwareentwickler. Nur wie das herausfinden?

Da fügte es sich, dass ich einen Hinweis auf die Plattform workeer.de bei facebook sah. Manchmal ist facebook doch tatsächlich nützlich ;-) workeer.de bezeichnet sich als “Die erste Jobbörse für Geflüchtete und Arbeitgeber, die ihnen Chancen eröffnen wollen.”

Also habe ich die Liste der Jobsuchenden durchgeblättert und fand sogar einen Softwareentwickler mit C#-Kenntnissen darin: Nour Saeed. Bingo, Glückstreffer!

Nach Anmeldung bei workeer.de konnte ich mit ihm Kontakt aufnehmen. Er spricht derzeit noch kein Deutsch, aber mit Englisch ging es auch. Also begannen wir über die Konditionen zu verhandeln, wie er für mich tätig werden könnte.

Nour ist als Flüchtling anerkannt und darf in Deutschland arbeiten. Das Jobcenter stellt ihm eine Wohnung zur Verfügung und darüber hinaus noch 400€, von denen er einen Teil für die Wohnung abgibt, Elektrizität und den Internetzugang bezahlt - und dann von ca. 300€ seinen Lebensunterhalt bestreitet. Allerdings weiß Nour nicht, wie unser Arbeitssystem funktioniert. Wo ist der Unterschied zwischen Praktikum, Anstellung, Selbstständigkeit? Wohin könnte ich ihm einen vereinbarten Stundensatz überweisen? Könnte er mir eine Rechnung schreiben? Das waren Fragen, mit denen er überfordert war. Und er fühlte sich auch außerstande, sie mit seinem Jobcenter zu klären, denn dort spricht man eher kein Englisch.

Wie es sich ergab, rutschte die Priorität für mein Projekt im Verlauf der Tage, die wir per Email kommunizierten aus verschiedenen Gründen, die nichts mit Nour zu tun hatten, aber nach unten. Die Umsetzung war nicht mehr wichtig. Also auch nicht mehr die Beantwortung dieser Fragen für mich. Ich bot Nour daher alternativ an, er könne sich aber mit Code Katas des Coding Dojo der CCD-School schon einmal warmprogrammieren ;-) Ich würde ihm gern Feedback zu seinen Lösungen geben.

Dabei hätte es bleiben können. Aber dann ließ mich das Thema Flüchtlingswelle doch nicht in Ruhe und ich überlegte, ob ich mehr für Nour tun könnte. Also bot ich ihm an, einmal nach Güstrow zu kommen, wo er derzeit lebt. Mit einem Artikel in meinem Blog hoffte und hoffe ich, seine Sichtbarkeit als motivierten Softwareentwickler zu erhöhen. Vielleicht findet sich ja ein Unternehmen, dass für ihn einen Platz hat.

Nour ist derzeit 26 Jahre alt und hat seinen Bachelor in Information Systems Engineering mit Schwerpunkt in Software application development. Interessanterweise hat er den letzten Baustein zum Abschluss seines Studiums per Skype eingebaut. Denn zu dem Zeitpunkt war er schon nicht mehr in Syrien. Es war ihm einfach sehr wichtig, einen qualifizierten und international relevanten Abschluss trotz aller Widrigkeiten zu schaffen. Denn eines war klar: Wo immer er aufgenommen würde, er will arbeiten, seinen Lebensunterhalt selbst verdienen und sich weiterentwickeln.

Das Gepäck, dass er, seine zwei Brüder und seine Eltern aus Damaskus mitnehmen konnten, war naturgemäß klein. Der Vater hatte sein Geschäft verkauft, um die Flucht finanzieren zu können. Was nicht in einen Rucksack und einen Koffer pro Person passte, musste zurückgelassen werden.

Aber Nour hatte nicht nur seinen Laptop eingepackt, sondern auch C# 2.0 - The Complete Reference, d.h. das für ihn beste verfügbare Buch zum .NET Framework. Dieses seitenstarke Buch sollte ihm in den folgenden Monaten ein treuer Begleiter sein.

Als ich in seine Wohnung in Güstrow komme, sehe ich es gleich auf der Fensterbank liegen. Dass er es durch alle Strapazen der Flucht behalten hat, beeindruckt mich. So sieht Lernwille aus.

Begonnen haben Nour und seine Familie die Flucht wohl Ende 2013. Auslöser war sein bevorstehender Studiumsabschluss. Er musste fürchten, danach von der syrischen Armee eingezogen zu werden. Eine Aussicht, die ihm Angst machte, da er für dieses Regime nicht Gefahr laufen wollte, sein Leben zu opfern. Aber auch die Alternative, bei einer der vielen Gruppen von Freiheitskämpfern zu dienen, war für ihn keine Option. Im Verlauf unseres Gesprächs berichtet er davon, wie Freunde von ihm auf dieser Seite gefallen waren - und wofür? Es war nicht einmal klar, ob die jeweilige Gruppe wirklich etwas für das Volk getan hatte oder nur für eigene Vorteile.

Darüber hinaus wäre seine Familie aber auch nicht sicher vor Übergriffen der einen oder anderen “Armee” gewesen. Er berichtete von Folterungen und Tötungen auch Unbeteiligter. Sich schlicht für Freiheit auszusprechen, birgt in Syrien ein hohes Risiko. Zum Beleg zeigte er mir ein Video in der arabischsprachigen “Parallelwelt” bei Youtube, auf dem Zivilisten brutal von Soldaten der regulären syrischen Armee zu Tode gebracht werden unter höhnischen Fragen, was sie nun zu ihrer Idee von Freiheit sagen würden. Nour übersetzte - und für mich war es kaum auszuhalten, das mitansehen zu müssen.

Dass Nour und seine Brüder sich in dieser Realität dafür entschieden haben, sich und ihre Familien in Sicherheit zu bringen… Wer würde ihnen das verdenken?

Der Plan war jedoch zunächst, nach Auflösung des väterlichen Geschäfts, nur in die Türkei zu flüchten. Das schien ihnen ausreichen weit entfernt und gleichzeitig immer noch heimat- bzw. kulturnah. Der Weg führte sie mit einer normalen Ausreise nach Beirut im Libanon, von dort mit einer Fähre nach Mersin/Türkei. Dort verbrachten sie einige Zeit, um dann nach Istanbul weiter zu ziehen.

image

Insgesamt lebten sie 7 Monate in Instanbul. Dort fing Nour an, Türkisch zu lernen und versuchte, Arbeit als Softwareentwickler zu finden. Leider ohne Erfolg.

Als das mitgebrachte Geld sich dem Ende zuneigte, sah die Familie keinen anderen Ausweg, als weiterzuziehen. Sie erkundigten sich, wo es größere Chancen auf Arbeit gebe. Deutschland und Schweden wurden als Ziele auserkoren.

Mit dem unverheirateten Bruder und einigen Freunden versuchte Nour, über die grüne Grenze nach Griechenland zu gelangen. Zweimal ohne Erfolg. Beim ersten Mal, weil die Gruppe getrennt wurde. Beim zweiten Mal, weil sie geschnappt wurden. Als er das berichtet, lacht er und sagt, “But it was fun!” Bei aller Ungewissheit und Angst sei es ja am Ende gut ausgegangen. Die türkischen Soldaten, die sie aufbrachten, waren nett, hatten zwar Hunde und Gewehre - aber nur zur Abschreckung. Geladen waren die Gewehre nicht.

Nach diesem Misserfolg ging es zurück nach Istanbul. Jetzt konnte nur noch eine Schlepperbande helfen. Für mehrere Tausend Euro pro Person wurde ein Transfer erkauft, der sie über Izmir, Bodrum, Marmaris in einen Lastwagen führte. Der brachte sie bei Nacht und Nebel irgendwo an der Küste zu einem Boot, das sie nach Kalymnos übersetzte.

Von dort nahmen sie eine reguläre Fähre nach Athen, wo er sein Flugticket nach Deutschland bekam. Das galt jedoch ab Kreta, von wo er schließlich nach Berlin gelangte. Seine Brüder folgten erst später.

Die Eltern nahmen derweil die Route Italien, Kopenhagen nach Schweden.

In Berlin angekommen suchte Nour sich mit Hilfe eines türkischen Taxifahrers ein Hotel - das der sogar bezahlte. Am nächsten Tag stellte er sich bei den Behörden vor und fand nach einem weiteren Monat seinen vorläufigen neuen Heimatort: Güstrow in Mecklenburg-Vorpommern.

Das war im September 2014. Nach Monaten in der Türkei und in Griechenland, nach Reisen zu Lande, zu Wasser und in der Luft war Nour angekommen. Die deutschen Behörden haben ihn “ins System” aufgenommen. Alles läuft seinen Gang. Nour lebt mit seinem Bruder in einer Wohnung. Nebenan wohnt der andere Bruder mit seiner Frau. Die Einrichtung ist bescheiden. Aber alle sind satt und warm.

Aber das war es dann auch schon.

Denn seit September 2014 ist nichts mehr passiert. Das Jobcenter verwaltet Nour und seine Brüder, macht aber keine Angebote. Für August 2015 war ein Sprachkurs in Rostock in Aussicht gestellt - doch dann wurde das Zugticket dahin doch wieder gestrichen. Es würde demnächst ein Sprachkurs in näherer Umgebung beginnen. Welch verschenkte Chancen durch eine Wartezeit von mehr als 12 Monate auf einen simplen Sprachkurs!

Nour hat also in Deutschland ein Jahr lang im Grunde keine wirkliche Integration erfahren. Der Kontakt mit den Behörden ist umständlich, weil man dort kaum Englisch spricht. Er muss immer Bekannte um Vermittlung bitten. Während ich ihn besuche, klingelt die Postzustellerin mit einem Paket. Nur durch meine Vermittlung kann geklärt werden, was es damit auf sich hat.

Die Selbstversorgung klappt. Internet gibt es auch. Aber Kontakt besteht nur zu anderen Flüchtlingen - via Smartphone und Laptop. Ständig höre ich aus dem Nebenzimmer die Benachrichtigungstöne von Apps wie Skype, Whatsapp oder Viber.

Nours Hoffnung ist, einen Job als Entwickler in einer Großstadt zu bekommen. Berlin, Hamburg… das ist ihm egal. Er würde gern in C# arbeiten und eher serverseitig zu Web-Anwendungen beitragen. Doch auch das ist verhandelbar. Hauptsache es geht voran.

Das größte Problem für Nour und seine Brüder ist die Untätigkeit, die Langeweile. Güstrow ist auch wirklich keine Stadt, die mit Ablenkungsangeboten glänzt. Und da das Geld sehr knapp ist, sind Ausflüge in die weitere Umgegend nicht einfach.

Sein kleiner Bruder möchte weiter nach Schweden zu den Eltern. Aber Nour kann sich ein Leben in Deutschland gut vorstellen. Dass die Verhältnisse in seinem Heimatland eine Rückkehr nahelegen, sieht er nicht ab. Dort wieder angstfrei leben zu können, dort zum Wiederaufbau der Gesellschaft beitragen zu können, das ist sein Traum. Doch bis dahin will er hier für sich sorgen und etwas lernen.

In mehr als sechs Stunden Gespräch kommen wir aber irgendwie nicht dazu, mal etwas gemeinsam mit .NET zu machen. Eigentlich hatte ich gedacht, wir gehen eine kleine Aufgabe an, so dass ich mal Nours Arbeitsweise kennenlerne. Doch es gibt so viel zu fragen und zu erzählen. Außerdem will er mir noch ein syrisches Gericht servieren: Kichererbsen stundenlang gekocht mit Brotstücken in Spezialsoße nach Geheimrezept seines Vaters.

image

Da die Besorgung einer Zutat durch den Bruder etwas stockt, verschiebe ich meine Rückreise. Aber das lohnt sich, denn das Ergebnis von Nours Kochkunst ist sehr lecker.

Natürlich sprechen wir in der ganzen Zeit auch über Softwareentwicklung und sein Studium. Nour hat in Damaskus auch mit Java und C++ Erfahrung gesammelt. Doch C# hat ihm am Ende am meisten gefallen.

Und genauso natürlich kommen Kultur und Religion zur Sprache. Islam im Fernsehen ist etwas anderes als gelebter bzw. erzählter Islam von Praktizierenden.

Doch die unterschiedlichen Auffassungen in dieser Hinsicht sind am Ende unwichtig. Verbindend ist das gemeinsame Interesse an der Softwareentwicklung und vor allem an einem Leben, das von Sinn erfüllt ist und in Frieden sich entwickeln kann. Mehr sucht Nour nicht. Er möchte seine Interessen und Kenntnisse einbringen können.

Ich als Freiberufler kann ihm dabei nur begrenzt helfen. Selbst ein kleines Projekt hier und da sind ja nicht das, wonach Nour sucht. Wer könnte also mehr bieten? Wo ist ein Team, das noch etwas Verstärkung braucht? Wer kann pragmatisch helfen bei der Integration eines Kollegen aus dem fernen Syrien? Eine Email an mich genügt. Ich stelle gern den Kontakt zu Nour her. Der würde sich sehr freuen.

image

Vorschläge zur Messung von Agilität

Wann ist ein Team, eine Organisation agil? Gibt es mehr oder weniger Agilität? Das sind Fragen, die eigentlich jeden umtreiben müssten, der sich mit dem Thema Agilität beschäftigt, egal ob Enthusiast oder Skeptiker.

Was für mich den Kern von Agilität ausmacht, habe ich an anderer Stelle mal beschrieben. Darauf hat nun Volker Meurer mit einem interessanten Beitrag reagiert.

Volkers Idee, Agilität als einen Raum zu betrachten, der durch mehrere Dimensionen aufgespannt wird, finde ich anschaulich und hilfreich. Damit kommt Agilität aus der pseudowissenschaftlichen Ecke heraus, sie wird quantifizierbar(er).

Mit solchen Dimensionen würde Agilität besser greifbar. Es gäbe etwas zu messen – und das ist für jeden der bewusst seine Fähigkeiten verbessern will, immer eine gute Sache. Messungen geben Feedback über Fort- bzw. Rückschritt. Außerdem kann man sich damit Ziele setzen.

Agilität aus dem Manifest destilliert

Das Agile Manifest ist in seiner Beschreibung von Agilität schwammig; wann man agil ist, kann man nicht so genau wissen. “Individuals and interactions over processes and tools” usw.: das klingt gut, da ist eine Menge dran – aber hat man es denn schon realisiert? Ja, genau, real-isiert. Ist es schon real? Wie stellt man das für eine Organisation fest? Wie misst man das? Und ist es wichtig dafür, dass morgens alle im täglichen Standup-Chor singen? Muss man dafür Story Points schätzen?

Alles, was Scrum und XP – die beiden ursprünglichen agilen Vorgehensmodelle - vorschlagen sind nur, lediglich und nicht mehr als Mittel. Ebenso “customer collaboration” oder “individuals and interactions”. Alles nur Mittel. Aber zu welchem Zweck? Was soll durch mehr “individuals” denn “tools” erreicht werden?

Auch in meiner Beschreibung eines Kerns von Agilität habe ich vor allem Mittel genannt. Als Destillat stellten sie für mich Muster in Softwareproduktionen dar, die mir typisch für ein bestimmtes positives Gesamtverhalten, ein gutes Ergebnis schienen. Das kann man dann “agile Softwareproduktion” nennen; mir persönlich schmeckt “flüssige Softwareproduktion” allerdings besser. Doch beides sind wieder nur verkürzende Etiketten. Die Frage bleibt: Ja, was ist denn das, wofür Inkremente oder daily stand-ups oder Reflexion oder co-located teams usw. Mittel sind, es herzustellen?

Aus diesem kreiselnden Denken, aus der Gefahr des Cargo-Kults müssen wir endlich aussteigen. Wir müssen irgendeine Softwareproduktion herstellen, die was taugt. Wie die heißt, das ist egal. Also, worum gehts?

Worum geht es?

Unter einem Berg an gut gemeinten Mitteln finden sich im Agilen Manifest Hinweise. Hier die richtungsweisenden Begriffe in Reihenfolge der Fundstellen bei den Werten und den Prinzipien:

  • “Working software”
  • “responding to change”
  • “satisfy customer”
  • “welcome changing requirements”
  • “harness change for the customer’s competitive advantage”
  • “Deliver working software”
  • “Working software is the primary measure of progress”
  • “sustainable development”

Aus dieser Liste lässt sich herauslesen, wie damals die Welt der dysfunktionalen Softwareproduktion gesehen wurde. Und eben, was man daraus für Schlüsse für eine bessere Softwareproduktion gezogen hat:

  • Die Softwareentwicklung hat sich mehr um sich selbst als um den Kunden gedreht. Man war verstrickt in technische Belange. Materialien und Werkzeuge haben viel Energie absorbiert. Ob die Gründe dafür tatsächlich in einem Mangel an genügend leistungsfähiger Technologie lag oder eher in der Psyche der damaligen Softwareentwickler, sei dahingestellt. Jedenfalls rief das Manifest zu einem Umdenken auf. “Working software” (3 Nennungen) und Wert für den Kunden (“satisfy customer”, “customer’s competitive advantage”) sollten der Leitstern sein. Agil ist also, was qualitätsorientiert ist. Denn Qualität ist, wofür irgendwer bereit ist, Geld auszugeben.
  • Außerdem erschien die Softwareentwicklung damals als schwerfällig und starr. Die Erkenntnis war, dass sich Kundenwünsche schneller ändern als man darauf reagieren kann. Vielleicht, weil der Kunde tatsächlich neuen/anderen Bedarf hat; vielleicht, weil der Kunde zu Beginn der Entwicklung nicht genau wusste, was er wollte; vielleicht, weil er es wusste, aber nicht gut ausdrücken konnte; vielleicht, weil das Verständnis der Entwickler mangelhaft war oder das Ergebnis fehlerhaft. Einerlei. Jedenfalls war die Beweglichkeit der Softwareproduktion nicht groß genug. Deshalb fordert das Agile Manifest “responding to change” und “welcome changing requirements” und “harness change”. Agil ist also, wo die Softwareentwicklung schmerzfrei den Kurs ändern kann, wenn Kundenwünsche sich ändern.
  • Und schließlich hielt man die Softwareproduktion für zu sehr auf den Moment konzentriert. Weil man starr war und technikfokussiert, hinkte man der Qualität immer hinterher. Qualität herzustellen war damit quasi eine Form von kurzfristiger Reparatur. Das Ergebnis: Todesmarschprojekte und rasant wachsender Legacy Code. Dem sollte die allerdings nur einmalige Nennung von “sustainable development” entgegenwirken. Agil ist also Softwareproduktion, die nicht nur an heute denkt, sondern nachhaltig arbeitet in allen Aspekten.

In einem Satz:

Agile Softwareentwicklung ist nachhaltig reaktionsfreudig qualitätsorientiert.

Das ist doch knackig, oder? Das lässt sich twittern ;-)

Ich habe es auch bewusst ohne Kommata geschrieben, um den Zusammenhalt der Adjektive zu stärken. Agilität bedeutet eben nicht nur qualitätsorientiert zu sein, sondern das in reaktionsfreudiger Weise: reaktionsfreudige Qualitätsorientierung. Und eben nicht nur das, sondern auch auch soll diese reaktionsfreudige Qualitätsorientierung nachhaltig sein: nachhaltige reaktionsfreudige Qualitätsorientierung. Agilität gibts nur als Paket. Sie ist eben mehr als eine Aufzählung von Attributen; sie ist ein Ganzes, quasi nachhaltigreaktionsfreudigqualitätsorientiert.

Warum Agilität?

Klar, man kann noch fragen, warum sollte Softwareentwicklung agil sein. Aber darauf ist die Antwort ja einfach: agil scheint wirtschaftlicher als nicht agil. Agilität erhöht die Wahrscheinlichkeit für das Überleben eines Unternehmens - und zwar das des Kunden wie das des Softwareproduzenten. Alles andere wäre ja uninteressant.

Wie erreicht man Agilität?

Und nun, da klarer ist, was bessere Softwareproduktion als früher ist, wie erreicht man diese Art Softwareproduktion?

Das ist im Grunde völlig egal. Agilität, die sich auf bestimmte Mittel versteift, ist fehlgeleitet.

Das Agile Manifest gibt zwar Hinweise für Hilfsmittel und Verhaltensweisen. Weitere sind zusammengefasst in den agilen Vorgehensmodellen Scrum und XP. Aber letztlich können das nicht mehr als Empfehlungen sein. Es haben sich halt Muster herausgeschält, die kausal verantwortlich scheinen für Verhältnisse, auf die die obige Definition von Agilität passt. Nicht weniger, aber auch nicht mehr.

Agilität messbar machen

Viel wichtiger als die Frage nach dem Wie ist die nach dem Ob. Ob man nämlich schon die agile Vision realisiert hat? Wie ist man auf dem Weg zu Agilität vorangekommen? Wenn der Einsatz von Mitteln kein Maßstab sein darf - da wäre nur Cargo-Kult -, dann muss eine andere Messlatte her. Ohne Messlatte kein Feedback zum Fortschritt auf einem Weg.

Auftritt Volker Meurer. Genau solch eine Messlatte schlägt er vor. Ob und wie agil eine Softwareproduktion ist, soll bestimmt werden durch Messungen in drei Dimensionen:

  • Reaktionszeit
  • Aufwand
  • Wert

Diese Grundidee gefällt mir sehr gut. Und doch passt da für mich etwas noch nicht ganz. Ich glaube, das liegt daran, dass Volker von einer weniger differenzierten Definition ausgegangen ist.

Ich meine, wenn schon messen, dann das, wofür Agilität steht. Dazu müssen die Grade bestimmt werden, zu denen Qualitätsorientierung, Reaktionsfreudigkeit und Nachhaltigkeit erreicht sind.

Reaktionsfreudigkeit

Reaktionsfreudigkeit scheint der am einfachsten zu messen Aspekt von Agilität zu sein. Volkers Reaktionszeit-Dimension bezieht sich offensichtlich ebenfalls darauf.

Reaktionsfreudig/-fähig ist, wer auf eine neue Anforderung, eine Überraschung, eine unerwartete Kursänderung schnell reagiert. Das kann nötig sein, weil ein vom Support gemeldeter Bug dringend gefixt werden muss. Oder es stellt sich bei der Abnahme einer gelieferten Qualität heraus, dass die nun doch nicht auf einem zufrieden stellenden Niveau für den Kunden ist und deshalb eine baldige, wenn schon nicht unmittelbare Nachbesserung erforderlich wird.

Jeder einzelne Entwickler mag total reaktionsfreudig sein und alles stehen und liegen lassen, wenn der Kunde einen neuen Wunsch äußert. Diese Reaktionsfreude ist sogar durchaus weit verbreitet - stellt aber ein Anti-Pattern dar.

Es geht vielmehr um Reaktionsfreudigkeit des gesamten Produktionsprozesses. Und das auch noch unter einer Bedingung: Es darf dabei keine Verschwendung entstehen. Darauf bezieht sich Volkers Wert-Dimension.

In welcher Ferne liegt im Gesamtprozess der nächste Punkt zur Kursänderung, ohne bisherige Qualität zu vernichten (Regression) oder in Arbeit befindliche Qualität nicht fertig zu stellen?

Kann in 4 Stunden oder in 5 Tagen oder in 4 Wochen eine neue, dem Kunden wichtige Änderung begonnen werden? Natürlich unter Berücksichtigung begrenzter Kapazität; andere Qualitäten, deren Realisierung gestern noch als nächstes anstanden, müssen u.U. zurückstecken.

In keinem Fall jedoch wird der grundsätzliche Produktionsfluss dadurch aus der Bahn geworfen.

Reaktionsfreudigkeit ist mithin mehr als Reaktionszeit. Zu der Frage “Wie lange, bis zum nächsten ‘Unterbrechungspunkt’, damit nichts Angefangenes auf Halde gelegt werden muss?” muss die Frage treten “Wie viel existierende Qualität wird vernichtet durch diese unerwartete Kursänderung?”

Die erste Frage lässt sich mit Blick auf die Uhr bzw. auf den Produktionsplan gem. de facto Produktionsprozess beantworten.

Die zweite Frage jedoch brauch ein anderes Messinstrument. Existierende Qualität kann nur durch Tests gemessen werden. Agilitätsbestimmung setzt mithin automatisierte Tests mit angemessener Abdeckung voraus, weil sonst nicht zu jedem Zeitpunkt der aktuelle Qualitätsstand leicht gemessen werden kann.

Automatisierte Tests dienen also nicht nur als Sicherheitsnetz, sondern als Messinstrument. Ohne angemessene Testabdeckung fehlt ein Messinstrument. Und damit - so würde ich sagen - fehlt per se Agilität.

Es gibt keine Agilität ohne automatisierte Tests. Da kann man sich in Iterationen drehen, wie man will. Ohne automatisierte Tests kann man sich schlicht alles in die Tasche lügen. Verschwendung durch Qualitätsvernichtung ist dann nicht auf dem Radar.

Und noch eine weitere Frage stellt sich im Rahmen der Reaktionsfreudigkeit. Selbst wenn der nächste Unterbrechungspunkt nahe ist, selbst wenn existierende Qualität durch die Kursänderung nicht vernichtet würde, so kann die Reaktionsfreudigkeit doch suboptimal sein.

Denn der nächste Zeitpunkt zum Beginn der Arbeit an einer Anforderung ist nur oberflächlich interessant. Viel wichtiger ist, wann kann mit der produktiven Arbeit an den für die neue Anforderung relevanten Aspekten begonnen werden? Das meint Volker mit seiner Aufwand-Dimension, glaube ich.

Wenn schon in 4 Stunden die neue Anforderungen in Angriff genommen werden könnte, ohne dass Verschwendung entstünde, dann wäre das super. Weniger super wäre jedoch, wenn dann erstmal 3 Tage lang refaktorisiert werden müsste, um produktiv zu werden.

Refaktorisierung würde ich nicht als Verschwendung bezeichnen. Aber die dafür aufgewandte Zeit ist unproduktiv. Weniger davon ist besser. In Analogie zur materiellen Produktion würde ich sie als Rüstzeit bezeichnen. Sie muss sich sogar nicht nur auf das Material (Code) beziehen, sondern umfasst auch die Bereitstellung von Maschinen (Tools, Infrastruktur) und Menschen. Alles, was verändert werden muss, um die eigentlich vom Kunden gewünschte Qualität herzustellen, ist hier einzurechnen.

Wie kann man solche Rüstzeit messen? Natürlich mit der Uhr. Wenn man weiß, dass es sie gibt, dann muss man schauen, wo man Anzeichen dafür sieht, dass die Produktion sich gerade in Rüstzeit befindet. Ein Blick ins Repository kann Hinweise liefern. Refaktorisierungen sollten dort als solche gekennzeichnet sein. Aber auch eine Befragung der Entwickler hilft. Hier könnte ein daily stand-up meeting als Messinstrument dienen. “Wie viel Zeit hast du gestern mit Refaktorisierung zur Vorbereitung einer Aufgabe verbracht?” oder “Wie viel Zeit hast du gestern in das Aufsetzen von Infrastruktur zur Vorbereitung gesteckt?” oder “Wie lange haben wir gestern auf Beiträge von Dritten gewartet, um mit der neuen Aufgabe zu beginnen?” sind Fragen nach Rüstzeit.

Ein daily stand-up meeting begründet mit “individuals and interactions” ist schwach. Und die Frage “Was hast du gestern gemacht?” in einem co-located Team ist langweilig. So degenerieren stand-ups schnell zu Pflichtveranstaltungen, zu Cargo-Kult. Sich allgemein kollaborativ austauschen kann man auf andere Weise besser. Aber mit der konkreten Aufgabe “Rüstzeit messen” ist die Kraft hinter einem stand-up ganz anders. Spüren Sie das? Da weiß jeder ganz genau, worum es geht und worauf man am Tag achten muss. (Ob ein daily stand-up das beste Messinstrument ist, sei aber weiter dahingestellt. In jedem Fall ist es eines, mit dem Sie leicht beginnen können.)

Reaktionsfreudiger ist also, wer mit kürzerer Reaktionszeit und mit weniger Verschwendung und weniger Rüstzeit auf neue Anforderungen reagieren kann als andere oder vormalig er selbst.

Qualitätsorientierung

Volkers Dimensionen dienen der Bestimmung des Agilitätsgrades einer Organisation. Aber sie beziehen sich aus meiner Sicht nur auf den Aspekt der Reaktionsfreudigkeit. Der ist wichtig, aber nicht eben nicht der einzige.

Wer Agilität implementieren will, der muss mehr sein, als reaktionsfreudig. Der muss Qualitätsorientierung zeigen. Nur wie drückt die sich aus? Wie kann man die messen?

Qualität ist etwas von Wert. Dafür ist der Kunde bereit, zu zahlen. Die erste Frage muss daher lauten: Wird der Fortschritt der Produktion an werthaltigen Aufgaben gemessen?

Es gibt immer wieder Projekte, in denen Meilensteine lauten, “Kommunikationsframework eingebaut” oder “ORM entwickelt”. Natürlich zielen solche Aufgaben auf die Herstellung irgendeiner Qualität ab. Doch die Qualität selbst ist eben nicht Aufgabe. Technologien, Infrastruktur, Tools sind lediglich Mittel, um Qualitäten herzustellen.

Für den Kunden ist mit spürbarem Wert also nichts geschafft, wenn ein Kommunikationsframework eingebaut oder ein ORM entwickelt wurde. Das ist kein messbarer Fortschritt. Ob das gut getan ist, kann er nicht sagen.

Qualitätsorientierten Fortschritt gibt es nur, wenn Aufgaben Feedbackfähiges betreffen. Use Cases oder User Stories sind anerkannter Ausdruck dafür; ich würde aber lieber etwas neutraler von Inkrementen sprechen. Je mehr Inkremente den Ausgangspunkt der Produktionsplanung darstellen, desto agiler die Softwareentwicklung.

Aber dabei sollte die Messung nicht stehenbleiben. Denn wir hoch ist der Wert jeder dieser hübsch formulierten Aufgaben? Ihre Formulierung zeigt, dass sie irgendeinen Wert haben, aber nicht welchen. Weder absolut noch im Vergleich. Ohne eine Wertzuordnung ist aber nicht einschätzbar, ob die Produktion gerade viel Wert oder wenig herstellt.

Ein zweiter Maßstab für Agilität ist daher, in welchem Ausmaß Inkremente mit einem Wert versehen sind. Sehr große Aufgaben haben gewöhnlich einen vom Management oder Kunden bezifferte Wert. Aber wie steht es mit kleineren und kleinsten Aufgaben?

Wert muss dabei nicht direkt etwas mit Geld zu tun haben. Es geht nicht darum zwanghaft einen vermuteten Umsatz an eine Aufgabe zu hängen oder cost of delay zu berechnen. Auch die Zahl der Anwender, die von der Umsetzung einer Aufgabe profitieren, stellt einen Wert dar. Oder die erwartete Nutzungshäufigkeit einer Qualität. Oder ein Erkenntnisgewinn über Kundenverhalten oder Technologiefunktionalität. Der Wert an Information ist nicht zu unterschätzen. Das schließt die Ausräumung von Unsicherheiten ein.

Damit aber nicht genug. Wert allein macht auch nicht glücklich, kann man sagen. Viele kleine Verbesserungen schnell ausgeliefert können mehr bewirken als die mega Verbesserung in ferner Zukunft.

Qualitätsorientierung muss dem Wert einer Aufgabe daher einen Aufwand gegenüberstellen. Es muss also ebenfalls gemessen werden, wie weit Aufgaben mit geschätzten Aufwänden versehen sind. Die Maßeinheit ist dabei egal (Fibonacci-Zahlen oder T-Shirt-Größen). Es geht auch nicht um Vorhersagen, wie lange die Realisierung einer Qualität zeitlich dauern wird.

Lediglich eine vergleichende Schätzung von Aufgaben, die derzeit auf dem Tisch sind, ist nötig. Wichtig ist einzig der Faktor, in dem sie sich unterscheiden. Beispiel: Aufgabe A ist die kleinste, ihr Faktor ist 1. Aufgabe B braucht geschätzt doppelt so viel Aufwand, ihr Faktor ist 2. Aufgabe C braucht ca. 50% mehr Aufwand als B, ihr Faktor ist also 3.

Ob in diesem Beispiel am Ende A in 2 Tagen und B daher in 4 Tagen realisiert würde oder wurde, ist uninteressant. Die Messung im Nachhinein ist zwar möglich - aber sollte nicht zur Kalibrierung von Faktoren führen. “Aha, der Faktor 2 bedeutet 4 Tage! Beim nächsten Mal werden wir das bei der Planung berücksichtigen.” Solche Gedanken sind irrig. Sie führen konsequent in Konflikte aufgrund von falschen Voraussagen. Sie erzeugen Unzuverlässigkeit.

Außerdem sind solche Voraussagen für eine Qualitätsorientierung völlig überflüssig. Durch (nicht einhaltbare) Versprechen von einer bestimmten Qualität zu einem bestimmten Zeitpunkt wird keine Qualität hergestellt. Qualität wird ausschließlich dadurch hergestellt, dass man programmiert. Schnellstmöglich geschieht das, wenn die Reihenfolge der Aufgabenabarbeitung wertmaximierend ist.

Es ist also viertens zu messen, in welchem Umfang die feedbackfähigen Aufgaben gemäß Wert und Aufwand priorisiert abgearbeitet werden. Dazu wird der Wert durch den Aufwand geteilt. Das Verfahren heißt Weighted Shortest Job First (WSJF) und berechnet für jede Aufgabe ein Gewicht, das umgekehrt proportional zur Priorität einer Aufgabe ist: je kleiner das Gewicht, desto höher die Priorität.

Dass irgendwann irgendwer beurteilt, ob eine Aufgabe mit der erwarteten oder dann benötigten Qualität umgesetzt wurde, muss nicht diskutiert werden. Das ist auch in voragilen Zeiten so gewesen.

Echte Qualitätsorientierung braucht jedoch mehr. Sie will möglichst schnell wissen, ob sie erfolgreich ist. Es kommt also nicht nur auf die Reaktionszeit für die Aufnahme der Arbeit an einer neuen Anforderung an, sondern auch auf die Reaktionszeit des Abnehmers.

Bei der Reaktionsfreudigkeit kann es zu Verschwendung kommen. Bei der Qualitätsbeurteilung auch. Sie setzt ein, sobald die Abnahme einer fertiggestellten Qualität sich verzögert. Dann liegt Wert auf Halde. Was erarbeitet wurde, kann seinen Wert - falls es den hat - noch nicht entfalten. Es wurde ja noch nicht beurteilt.

Zu messen ist also die Zeit zwischen Fertigstellung und Abnahme. Wie lange dauert es, von dem Moment, da die Programmierung sagt “Fertig! Aufgabe umgesetzt.”, bis zu dem Moment, da der Abnehmer sich das anschaut?

Dass der Verzug möglichst klein sei, ist aber nicht nur für den Kunden von Interesse, damit er schnell Wert in die Hand bekommt. Denn nicht immer ist die gewünschte Qualität ja auch durch die Softwareproduktion erreicht. Das Vorgestellte kann einen Fehler enthalten, missverstanden sein oder aus anderen Gründen nicht recht passen. Dann muss nachgebessert werden.

Nachbesserungen reduzieren die Kapazität der Softwareproduktion für Neues. Nachbesserungen stellen Wert verspätet her. Das kann nicht im Sinne von Agilität und Flüssigkeit sein. Daraus ergibt sich eine weitere Messlatte: Wie oft kommt es zu Nachbesserungen?

Nachbesserungen können bei der Abnahme gefordert werden; es handelt sich um Bugs oder Korrekturen von Missverständnissen bzw. Unvollständigkeiten. Oder sie kommen quer herein vom Support. Je mehr es gibt, desto schlechter ist es um die Qualitätsorientierung bestellt.

Bitte bemerken Sie: Ich fordere hier keine Unit Tests oder eine QA. Auch keine Rolle für die Anforderungsanalyse. Das sind alles nur mögliche Mittel, um die eine oder andere Metrik zu verbessern. Genau das ist ja aber hier nicht der Punkt. Es geht nicht um Maßnahmen, sondern erstmal nur den Vorschlag einer Sammlung von Messlatten für die Agilität.

Eine Rolle für die Abnahme ist jedoch zwingend. Sonst kann das, worum es der Agilität geht, nicht beurteilt werden.

Qualitätsorientierter ist also, wer inkrementeller in gewichteter Weise voranschreitet und schnelleres Feedback mit weniger Nachbesserungswünschen erhält als andere oder vormalig er selbst.

Nachhaltigkeit

Zu guter Letzt die Nachhaltigkeit. Wie könnten wir die messen?

Nachhaltig handeln bedeutet, jetzt etwas tun, das unsere Optionen in der Zukunft nicht verringert, sondern bestenfalls sogar erhöht. Ressourcen, die heute zur Verfügung stehen, dürfen ihre Kapazität nicht verlieren; sie sollten sie sogar tendenziell steigern.

Nachhaltigkeit erfordert also die Beobachtung der Entwicklung von Ressourcen.

Die für die Softwareentwicklung relevanten Ressourcen sind: die Menschen, der Produktionsprozess und die implementierte Lösung, d.h. Code und nötige Infrastruktur.

Zu messen ist zunächst, ob die Beobachtung dieser Ressourcen überhaupt stattfindet.

Nach allgemeinem Sprachgebrauch würde ich sagen, dass Reviews die implementierte Lösung beobachten und Retrospektiven Menschen und Prozess.

Wie die Beobachtung in Reviews und Retrospektiven erfolgt, ist eine zweite Sache. Aber die Diskussion darüber ist nicht Teil dieser Betrachtung.

Beobachten ist gut, nur was passiert dann mit den Erkenntnissen? Sicherlich werden in Reviews und Retros Entscheidungen für Veränderungen getroffen, die umgesetzt werden müssen. Das mag für einige “einfach so” im Tagesgeschäft gehen. Um das verlässlich hinzubekommen, muss die Organisation ein Bewusstsein für und den Willen zu Verlässlichkeit haben. Hat sie das aber wirklich? Das sollte gemessen werden. Welche Versprechen werden gegeben, wie viele davon werden eingehalten, wie viele gebrochen, wie viele neu verhandelt, bevor man sie erfüllt?

Nicht alle beschlossenen Veränderungsmaßnahme lassen sich jedoch sofort umsetzen. Angesichts der Entwicklungsgeschwindigkeit unserer Branche ist zu erwarten, dass immer etwas so neu und umfangreich ist, dass die Organisationsmitglieder es sich erst außerhalb der normalen Produktion erarbeiten müssen. Dafür muss Raum zum Lernen bereitstehen - und zwar nicht nur gelegentlich, ad hoc, sondern kontinuierlich. Nur so erhält sich jeder Einzelne und die Organisation als Ganzes Zukunftsfähigkeit. Zu messen ist also mindestens der Anteil der Lernzeit an der Arbeitszeit. Besser jedoch sollte auch noch gemessen werden, wie hoch die Lernfrequenz ist.

Beobachten und Lernen ist gut, aber kann auch zu spät kommen oder nicht die gewünschte Wirkung entfalten. Zur Nachhaltigkeit gehören deshalb Puffer, um Minderleistungen bzw. Unerwartetes jeder Art abzufedern. Die Organisation darf gar nicht erst in eine Situation kommen, die ihre Existenz bedroht.

Welche Puffer es geben kann/gibt, hängt von den im Einsatz befindlichen Ressourcen ab. Naheliegend ist da der Gedanke ans liebe Geld. Oder der an Maschinen. Aber auch Mitarbeiter, deren Zeit, deren Motivation, deren Kenntnisse, deren Kreativität sind Ressourcen. Oder Kunden. Oder Zulieferer.

All das und mehr hat jeweils eine Menge, Leistungskraft, Kapazität, die für die aktuelle Produktion gerade reicht - oder eben größer sein sein. Was ist, wenn unerwartete Veränderungen in der Umwelt oder in der Organisation fordern, dass eine Ressource sich mehr als bisher einbringt? Ein Mitarbeiter will in die Elternzeit gehen, ein Mitarbeiter kündigt, ein Zulieferer fällt aus, ein Kunde springt ab, eine neue Technologie soll zukünftig verwendet werden, eine neue Anforderung erweist sich als deutlich schwieriger als angenommen in der Umsetzung… Das sind Belastungen jenseits des Normalen, für deren Bewältigung Reservekapazität, d.h. Puffer vorhanden sein müssen.

Gibt es dafür Puffer? Das sollte gemessen werden. Zugegeben, das mag nicht leicht fallen. Aber das Mindeste ist, sich überhaupt der Wichtigkeit von Puffern bewusst zu sein. Existiert also zumindest dieses Bewusstsein? Gibt es einen Willen zum Aufbau und Vorhalten von Puffern? Ich denke, das lässt sich schon in Gesprächen mit Organisationsmitgliedern herausfinden.

Nachhaltiger ist also, wer reflektierter und zuverlässiger bewusst lernend und gepuffert produziert als andere oder vormalig er selbst.

Zusammenfassung

Puh… da ist einiges zusammengekommen. Das hätte ich am Anfang nicht gedacht, als ich begann, diesen Artikel zu schreiben. Vorher wusste ich das nicht so genau, weil Schreiben für mich immer auch Nachdenken ist. Während des Schreibens entwickelt sich oft erst, was ich eigentlich denke.

Hier die Messinstrumente nochmal in der Übersicht:

  • Reaktionsfreudigkeit

    • Reaktionszeit bis zur Aufnahme der Arbeit an einer neuen Anforderung

    • Umfang der durch eine Änderung entstehenden Regression

    • Rüstzeit bis zum Beginn produktiver Arbeit an einer neuen Anforderung

  • Qualitätsorientierung

    • Prozentsatz der Aufgaben, die Inkremente darstellen

    • Prozentsatz der Inkremente, die mit einem Wert versehen sind

    • Prozentsatz der Inkremente, die mit einem Aufwand versehen sind

    • Prozentsatz der Inkremente, die nach Gewicht (Wert/Aufwand) priorisiert abgearbeitet werden

    • Wartezeit von Fertigstellung einer Aufgabe bis zur Abnahme

    • Menge der Nachbesserungen bei Abnahme und vom Support

  • Nachhaltigkeit

    • Frequenz von Reviews

    • Frequenz von Retrospektiven

    • Zahl der erfüllten, gebrochenen, nachverhandelten Versprechen

    • Prozentsatz der Lernzeit an der Arbeitszeit

    • Frequenz der Lernzeiteinheiten

    • Anzahl und Größe von Puffern

Ist das nicht ein bisschen viel? Volkers drei Dimensionen waren so schön übersichtlich.

Keine Ahnung, ob das am Ende zu viele Messinstrumente sind. Im Augenblick wüsste ich aber nicht, welches davon unnötig wäre. Sie scheinen zwar unterschiedlich wichtig zu sein, man muss wohl nicht sofort alle in Anschlag bringen. Andererseits ist ja auch nicht alles schwierig zu messen.

Wie es um Reviews steht oder ob in Inkrementen vorangeschritten wird, ist doch leicht zu messen. Rüstzeiten oder der Umgang mit Versprechen hingegen, mögen schwieriger zu beurteilen sein.

Würde es nicht reichen, einfach nur auf Scrum oder Kanban zu setzen? Scrum führt doch z.B. Retros und Inkremente ein und zwingt zu Versprechen. Damit wird doch das Richtige getan. Ja, einerseits. Dagegen ist nichts zu sagen - solange man versteht, warum (!) Scrum das macht. Solange man versteht, dass das nicht alles ist. Eine Diskussion über Kriterien und Metriken für Agilität ist eine andere als eine über Maßnahmen.

Wenn einige der Metriken hier schon wie klare Empfehlungen zu Maßnahmen aussehen, dann ist das ja nicht schlecht. Bei anderen Metriken habe ich mich aber bewusst zurückgehalten. So dachte ich z.B., dass auch gemessen werden könnte, ob/wie Zeitmanagement gelebt wird. Aber das wäre zu viel Vorgabe. Solange Zuverlässigkeit vorhanden ist, ist es egal, wie sie entsteht. Dito muss nicht gemessen werden, ob ein ProductOwner vorhanden ist, der Inkremente formuliert. Woher die kommen, wer die Werte und Aufwände bestimmt… keine Ahnung. Solange es geschieht, ist das doch egal.

Maßnahmen, wie Messwerte über die Zeit verbessert werden können, können sich Organisationen selbst überlegen oder von anderen abschauen und ausprobieren. Dafür ist die Reflexion da. Dass die da ist, muss dann jedoch gemessen werden.

Und warum reicht Kanban nicht einfach? Für meinen Geschmack stellt sich Kanban in mancher Hinsicht zu dumm. Transparenz + WIP Limit: mehr braucht es am Ende nicht. Das mag ultimativ korrekt sein - nur dauert es dann womöglich länger als nötig, um die richtigen Maßnahmen zu finden.

Bei systemischen Ansätzen soll der Klient ja die Lösung immer in sich finden. Schöner Gedanke. Natürlich muss die Lösung auch zum Klienten passen. Die Frage ist nur, wie kommt der Patient zu dieser Lösung? Ich glaube, dafür darf der Klient erstens Input von außen erhalten; ein Coach darf Vorschläge unterbreiten und Sichtweisen äußern. Und zweitens gehört dazu eben eine sehr feine Wahrnehmung. Um beurteilen zu können, was ihm taugt, muss der Klient die Effekte, die eine Idee oder probeweise Veränderung hervorruft, sehen, hören, schmecken, tasten, spüren, fühlen. Es braucht schlicht Messungen entlang vieler Dimensionen.

Ein WIP-Limit und der aus seinem Erreichen resultierende Schmerz sind mir da zu wenig und kommen womöglich zu spät. Wenn ich von einer Sache keine Ahnung habe, dann fange ich vielleicht mit diesem Minimum an. Aber von Softwareentwicklung sollten wir Ahnung haben und deshalb schon wissen, wo es haken kann. Da sollten wir dann Messpunkte einrichten. Dafür habe ich hier mal ein paar Vorschläge gemacht.

Ausgehend von einer Definition dessen, was überhaupt erreicht werden soll - reaktionsfähige nachhaltige qualitätsorientierte Softwareproduktion - sollten wir zunächst darüber sprechen, wie sich deren Güte ausdrücken könnte. Welche Attribute hat sie? Wenn wir sofort zu Maßnahmen springen, dann ist das gut gemeint, führt aber eben schnell zu Ritualen ohne Verbesserung der Attributwerte. Der Effekt ist das, was wir seit Jahren bei der Agilität sehen: Es wird Orthodoxie und Häresie gesprochen. Die Maßnahmen werden zum Problem. Das eigentliche Problem tritt in den Hintergrund.

Wenn wir uns jedoch zunächst über geeignete Messpunkte unterhalten, dann sind wir viel offener, was die Maßnahmen angeht. Vielleicht behalten manche Maßnahmen ihren Wert. Vielleicht finden sich aber auch ganz andere Maßnahmen, ohne dass man sich dafür entschuldigen müsste. Denn es zählen die Ergebnisse: bessere Messwerte. Morgens zusammen stehen oder co-location oder story point Schätzungen… Ist doch egal, solange etwas besser wird.

Die Verlagerung des Fokus auf Attribute und Messinstrumente lässt auch Raum für unterschiedliche Level an Agilität. Muss denn jeder maximal agil sein? Oder reicht es, angemessen agil zu werden für einen gewissen Kontext? Oder gibt es eben ganz unterschiedliche Maßnahmenausprägungen für Agilität je nach Kontext?

Messungen statt Maßnahmen an den Anfang zu setzen, scheint mir überfällig und zeitgemäß. Damit wird der Individualität von Organisationen mehr Rechnung getragen. Damit erhalten Organisation mehr Autonomie, den ihnen gemäßen Weg zur Agilität zu finden.

Agilität ist kein Absolutum. Sie ist ein Mittel, das dosiert einzusetzen ist, um mit Unsicherheit, mit Komplexität umzugehen. Wenn die aber unterschiedlich ist für verschiedene Organisationen, dann sollte die Agilität das widerspiegeln.

Das bedeutet: Am Anfang jeder Agilität steht die Entscheidung für eine Definition und der Wille zur Messung relevanter Attribute mit kontinuierlicher Reflexion über die Beobachtungen und Ableitung geeigneter Maßnahmen, um die Werte mehr in Einklang zu bringen mit den Notwendigkeiten, die sich aus Veränderungen im Außen und Innen ergeben.

Sonntag, 6. September 2015

Mehr Kohäsion als alternativlos erachtet

Kohäsiv ist, was zusammenhält. In der Softwareentwicklung ist es eine Tugend, das Kohäsive zu identifizieren und ihm durch ein Modul auf angemessenem Level eine Form zu geben. Module sind Container für das, was zusammengehört. Zum Zwecke der Wandelbarkeit.

Was in einem Modul zusammengefasst ist, kann sich weniger gestört durch die Umwelt weiterentwickeln. Das Modul zieht eine Grenze, einen Schutzwall.

Umgekehrt schützt das Modul die Umwelt vor den Entwicklungen in ihm. Jedenfalls wenn die Modulgrenze angemessen ausgelegt ist.

Hohe Kohäsion, lose Kopplung: das ist einer der zentralen Sätze für zukunftsfähige Softwarearchitektur.

Aber was ist kohäsiv? Und ist das, was heute zusammenhängt, morgen auch noch zusammenhängend? In „Sweet Aspects“ habe ich versucht, die Relativität und Volatilität von Kohäsion anschaulich darzustellen.

Es ist also nicht die Frage, ob es in einer Menge von Elementen Kohäsion gibt, sondern welche. Wird erkannt, was kohäsiv ist? Und wird dem Rechnung getragen.

So ist das bei Software. Aber so ist das auch bei Menschen. Menschen gehören zueinander. Anders als bei Softwareartefakten, wählen wir selbst jedoch die, die uns nahestehen. Wir modularisieren uns sozusagen autonom. Familie, Sportmannschaft, Verein, Unternehmen, Glaubensgemeinschaft, Nation... Das sind unsere ideellen Container. Die grenzen wir von anderen ab. Dafür suchen wir uns sogar physische Entsprechungen, vom Gebäude bis zum Territorium.

Und umgekehrt: Was „auf einem Haufen“ versammelt ist, hat besser hohe Kohäsion. Sonst kommt es zu Unverständnis und Spannungen. Sonst entsteht keine Gemeinschaft. Kräfte werden dann unproduktiv in Konflikten verschwendet, statt sie auf die Erreichung gemeinschaftlicher Ziele anzuwenden. Und am Ende zerfällt der nicht kohäsive Haufen in kleinere mit höherer Kohäsion.

Das ist nur natürlich. Manchmal funktioniert es besser, manchmal nicht so gut. So ist das menschliche Gemeinschaftsgefüge auch immer in Bewegung. Derzeit wieder ganz gehörig.

Die Zusammensetzung der Mitglieder in unserem hübschen Staatscontainer „Deutschland“ ändert sich gerade gewaltig. Wir haben mal geglaubt, die Zuwanderung von Gastarbeitern sei ein Problem, das zu Überfremdung führt. Doch das ist schon länger kein Thema mehr. Gastarbeiter sind keine Gastarbeiter mehr, sondern Dauerarbeiter geworden. Sie gehören zu Deutschland wie der deutsche Wald. Knapp 20% der Bevölkerung Deutschlands haben erwähnenswerten Migrationshintergrund. 10% sind sogar immer noch Ausländer. Das ist normal. Das ist gut so.

Die, die zunächst keine hohe Kohäsion hatten – Deutsche und Spanier, Griechen, Italiener, Türken, Chinesen und wer noch alles zugezogen sein mag –, haben sich zusammengerauft. Das nennt man erfolgreiche Integration. Wir haben uns auf einander zu bewegt.

Dass nicht alles eitel Sonnenschein ist, ist klar. Das war es im „ursprünglichen Deutschland“ aber auch nicht. Vor historisch gesehen kurzer Zeit haben allein wir Deutschen uns selbst und der Welt ja noch so einige Probleme bereitet.

Integration hat funktioniert. Über 20, 30, 40, 50 Jahre sind Millionen von Ausländern zu Inländern geworden. Eine großartige Leistung!

Vor allem aber auch eine nötige Leistung, denn sonst wäre der deutsche Staatscontainer auseinandergebrochen. Er hätte sich quasi selbst refaktorisiert. Extract nation hätte die Operation wohl geheißen. So wie 1990 die Operation Inline nation ausgeführt wurde: Die DDR ist der BRD beigetreten.

Exportweltmeister sind wir ja schon. Vielleicht sollten wir uns also auch Integrationsweltmeister nennen? 20 Millionen Ausländer, 20 Millionen DDR-Bürger: alles integriert – und immer noch ein Land, in dem wohl die meisten gerne leben. Ist das nicht eine großartige Leistung?

Andere finden das Ergebnis jedenfalls sehr attraktiv. So attraktiv, dass sie ebenfalls nach Deutschland kommen wollen. Sei es aus wirtschaftlichen Gründen oder weil sie schlicht Schutz für Leib und Leben suchen. Ihr Bild von Deutschland: hier gibt es Geld und/oder Sicherheit.

Können wir nicht stolz darauf sein, so ein Bild zu vermitteln? Trotz oder vielleicht sogar wegen all der Integrationsleistung, die in Deutschland vollbracht wurde, sind wir so etwas wie das gelobte Land geworden.

Dieses Bild ist sicher eine Überhöhung. Wir können ihm nicht einfach so gerecht werden. Milch und Honig fließen hier nicht. Doch woanders fließen mehr Tränen und vor allem Blut. Selbst wenn wir nur Milchpulver und Zuckerrübensirup zu bieten hätten, wäre das für viele eine deutliche Verbesserung.

Aber wollen wir das? Über diese Frage lässt sich lange diskutieren. Letztlich ist sie jedoch müßig. Die kanzlerische Alternativlosigkeit findet hier nämlich eine berechtigte Anwendung. Wir können nicht anders, als Menschen, viele Menschen an- und aufnehmen zu müssen. Sie sind schlichtweg da. Nicht nur vor der Tür, sondern schon im Flur oder gar im Wohnzimmer. Wer fragt „Wolle ma se reinlasse?“ kann das nur rhetorisch meinen.

Zwar hatten wir schon länger keine explizite Einladung mehr ausgesprochen – Deutschland ist kein Einwanderungsland, das aktiv um Zugüge im Ausland wirbt –, d.h. die, die nun schon da sind, sind keine geladenen Gäste. Deshalb ist die Frage selbstverständlich erlaubt, wen wir diesseits der Haustür wirklich bewirten wollen. Und die Antwort wird nicht für alle, die schon drin sind, positiv ausfallen.

Doch egal, wie das Gastkriterium auch formuliert ist oder werden mag, es werden viele bleiben. Und wohl vor allem schneller mehr, als in bisherigen Jahrzehnten. Das ist so. Das ist auf die eine oder andere Weise eine schlicht historische Konsequenz. Ich möchte hier sogar von Karma sprechen.

Deutschland und vor allem Europa erleben eine Bewegung, die vor Jahrzehnten oder gar Jahrhunderten angestoßen wurde. Von wem? Irgendwie wäre das schon wichtig zu eruieren, wenn man versuchen möchte, näher an der Wurzel etwas zu verändern. Andererseits führt diese Frage auch schnell in ein unendliches Fingerzeigen, das bei Obama/Bush beginnen mag und selbst bei Papst Urban II nicht enden würde.

Im Menschlichen herrscht, wie in der Physik, das Prinzip Actio und Reactio. Wer Gewalt benutzt, wird Gegengewalt erzeugen. Früher oder später. Der Abgrund ruft den Abgrund.

Aber einerlei. Es ist wie es ist. Die Tür ist auf, viele, viele Gäste strömen herein. Quasi Facebook-Party auf nationalem Niveau.

Die Frage der Stunde lautet: Was tun? Und die allererste, alternativlose Antwort ist: Integration. Jetzt! Sofort! So schnell wie möglich.

Zwei Phasen müssen wie bei jede Katastrophe schnellstmöglich durchlaufen werden:

1.     Triage
2.     Hilfe

Ursachenanalyse usw. muss auch geschehen. Parallel. Vor Ort kann es jedoch keine zwei Meinungen geben. Da sind die Ressourcen knapp und sollen bestmöglich eingesetzt werden.

Wenn es so sein kann, dass nicht alle die, die Deutschland so attraktiv finden, auch willkommen sind, dann muss das Kriterium dafür schnellstmöglich angewandt werden. Jeder Tag, den seine Anwendung später erfolgt, kostet Ressourcen, die der echten Hilfe nicht zur Verfügung stehen. Das ist Verschwendung pur. Jeder Tag Verzögerung lässt auch den Widerstand in der Bevölkerung wachsen, weil Unentschiedenheit als Führungslosigkeit gedeutet wird und Unsicherheit schürt.

Triage ist eine harte Sache. Immer. Sie wiederspricht dem Reflex des Altruismus. Aber es hilft im wahrsten Sinne des Wortes nichts: Wo Ressourcen knapp sind, müssen sie hier zugewiesen und woanders entzogen werden.

Über die Kriterien kann man ja, nein, muss man diskutieren. Aber nicht darüber, ob es Kriterien geben sollte. Und wenn man sich festgelegt hat, dann muss man sie anwenden. Zügig. Und dann muss man beobachten, ob man mit dem Ergebnis zufrieden ist. Und man muss akzeptieren, dass es zu Fehlern kommt. Es wird zu false positive und zu false negative Bewertungen kommen.

Je größer der Ansturm der Gastkandidaten, desto eher brauchen wir quasi Judge Dredd vor Ort für eine Triage. Das ist bei jeder Katastrophe so. Und die liegt vor.

Nach der Triage schnellstmögliche Hilfe. Das bedeutet in diesem Fall: Integration der Gäste. Rigoros. Alternativlos.

Denn wie lange die Gäste bleiben, ist ja unbekannt. Und angesichts des Weltenlaufs in den letzten Jahrzehnten sollten wir uns wohl eher auf länger denn kürzer einstellen. Aber selbst wenn sie nach 2-3 Jahren wieder heimreisen sollten, würden sie und wir von einer schnellen Integration profitieren. Sie nähmen in ihre Heimat nämlich ein bestätigtes gutes Bild von Deutschland mit. Deutschland wäre das Land, in dem sie so willkommen geheißen wurden, dass man sie sogar integriert hat.

Integration bedeutet natürlich vor allem Angleichung der Gäste an den Gastgeber Deutschland. Das ist für Deutsche selbstverständlich; Gäste mögen da eher zögerlich bis unwillig sein. Sie wollten doch „nur“ Geld und/oder Schutz. Aber es hilft nichts. „Nur“ gibt es nicht in dieser Größenordnung. Geschenke kann es geben im Leben – doch wie spätestens die vielen Gratisangebote im Internet auch dem letzten klar gemacht haben sollten: am Ende ist doch nichts umsonst. Und der Preis für den Empfang der Segnungen Deutschlands ist... Integrationswille. Jeder Gast ist aufgefordert, nach Kräften mitzumachen.

Doch die Integration ist keine Einbahnstraße. Es ist nicht zu vermeiden, dass auch die deutsche Gesellschaft sich den „Neuzugängen“ annähert. Es ist immer eine Co-Evolution. Anderes anzunehmen wäre naiv. Wir sehen es ja jeden Tag auf der Straße.

Wenn man das zulässt, dann ist das auch angenehm. Wer möchte auf die kulturelle Vielfalt in Deutschland denn wirklich verzichten? Nicht nur will ich in Hamburg einen Schwarzwälder Schinken genießen, ich möchte auch zum türkischen Friseur oder libanesischen Restaurant oder einem Diskussionskreis in der Moschee gehen können.

Also Integration. Aber wie?

Beim Couchsurfing im fernen Land sich nur mit Händen und Füßen verständigen, mag für ein paar Tage witzig sein. Da lernt man etwas fürs Leben.

Wenn Flüchtlinge und andere „Deutschlandfans“ jedoch nach der Triage hier bleiben dürfen, dann ist es nicht witzig, wenn sie uns und wir sie nicht verstehen. Das behindert vielmehr die so wichtige Integration. Kein gesellschaftlicher Anschluss, keine Job ohne gute Sprachkenntnisse.

Wir brauchen Kohäsion und die beginnt bei der Sprache. Sie ist die Bedingung für die Möglichkeit jedes anderen Kontaktes und damit weiterer Annäherung.

Ohne gemeinsame Sprache ist der Grundstein gelegt für den Verbleib im physischen und geistigen Ghetto. Ohne unsere Sprache können Gäste sich nicht zurechtfinden und auch nicht wirklich die Segnungen unserer Gesellschaft schätzen lernen. Vieles muss ihnen kryptisch erscheinen und bleiben. Und umgekehrt: Uns muss vieles als fremd und damit potenziell bedrohlich erscheinen.

Aber sofortige Sprachvermittlung von spätestens Tag 1 nach der Triage an ist nur der Anfang. Wie gesagt: die Bedingung für alle anderen Möglichkeiten.

Der nächste Schritt der Integration muss Bildung sein, die dazu führt, dass Gäste zu unserer Gastgebergesellschaft beitragen können.

Sicherlich gilt das in gleichem, nein, eigentlich sogar größerem Maß zunächst für schon deutsche Bürger. Da mangelt es im Grunde auch an Integration in diesem Sinn. Aber das ist ein anderes Thema. Mir geht es hier um das akute Problem der vielen Einströmenden.

Ja, ich denke, Bildung sofort tut Not. Bildung in Bezug auf unsere Kultur und gesellschaftliche Organisation. Aber auch Bildung im Hinblick auf einen möglichen Beitrag zu dem, was unsere Attraktivität ausmacht und überhaupt ermöglicht, dass wir fähig sind, Gäste aufzunehmen.

Wer kurz zu Besuch kommt, wird bedient. Das ist Ehrensache. Wer aber kommt, um unabsehbar zu bleiben... der wird vom ersten Tag an in unseren Alltag eingebunden. Das weiß jeder, der schonmal in einer WG gewohnt hat.

Aufgabe der Integration ist mithin, die Beitragsfähigkeit alle anerkannten Gäste herzustellen. In maximaler Geschwindigkeit. Jeder Tag Verzug sorgt für Verschwendung und Unsicherheit.

Wenn dann einer schneller wieder geht als gedacht, ohne einen Beitrag geleistet zu haben, dann ist die Investition in ihn auch kein Verlust. Er wird gut davon daheim berichten. Und angesichts der hohen Chance, dass er bleibt, haben wir das Richtige getan: Wir haben Aufbauarbeit geleistet für einen baldigen Beitrag. Wir haben Kohäsion hergestellt. Jeden Tag ein wenig mehr.

Denn ohne Kohäsion keine Einheit. Und wenn die Kohäsion einer Einheit sinkt durch Einflüsse von außen, dann müssen Anstrengung zu ihrer Aufrechterhaltung und Auffrischung unternommen werden. Das ist die oberste strategische Notwendigkeit. Alles andere ist ein Gefahr für die Einheit. Es ist wahrhaft Lebensgefährlich, nicht sofort in Integration zu investieren.

Softwareartefakte werden fremdorganisiert. Wir als Menschen müssen uns selbst organisieren. Die Gesetzmäßigkeiten sind jedoch dieselben: Erfolg setzt Kohäsion voraus. Ohne Kohäsion keine Kohärenz, keine Kraft zur Erreichung von Zielen.


Sinkt die Kohäsion durch Einmischung neuer Menschen, dann muss dem gegengesteuert werden. Grenzziehung hilft da nur bedingt. Vor allem muss integriert werden. Nur dann sind wir auf Dauer fähig, uns weiter mit der Welt zu wandeln – zumindest wenn wir das Modul „Deutschland“ für erhaltenswert befinden.