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.

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.