Da waren sie wieder.

Nein, nicht meine Probleme.
Die meisten Teilnehmer des zweiten Scrum Meetings trafen sich bereits am Donnerstag vor dem 19. Juni beim agiLEipzig Meetup #17.
Der einzige neue im Teilnehmerkreis war Stephan.
Knapp die Hälfte der Zusagen blieben unerfüllte Versprechen.

Ich selbst traf erst gegen 19:30 ein. Anne las gerade den von ihr eingebrachten Artikel vor. Es handelt sich dabei um die These von Erik Meijer, agile Methoden seien ein “Krebsgeschwür”.

Ich hielt den Artikel für gut gewählt, um eine kontroverse Diskussion in Gang zu bringen. Ich hatte meine Position bereits im Vorfeld bestimmt und war gespannt auf die der anderen.

Es fing ganz interessant an. Stephan brachte ein Messinstrument ins Gespräch, mit dem er das Code-Gewicht bestimmen könne. Peter ging auf die Diskussion ein und die beiden näherten sich dem Themenbereich Code-Quality.

Im Nachhinein denke ich mir, ich hätte es noch etwas laufen lassen sollen.
Hätte ich ahnen können, dass mein Beitrag so verheerende Folgen haben würde?

Ich fragte

Wen interessiert Code?

Falk stimmte sofort ein und auch für Peter schien das Thema Code nicht mehr so recht relevant zu sein. Alle bekräftigten, dass Funktionalität zähle.

Falk berichtete von seinem Verständnis der PO-Rolle. Er sieht sich als Bindeglied zwischen

• dem, was der Auftraggeber glaubt, das der Nutzer gebrauchen könnte
• dem, was das Entwicklungsteam umsetzen möchte, weil es meint der Nutzer könnte das brauchen

Code und auch Code-Qualität seien für ihn auch deswegen unerheblich, weil es mehrere Qualitätssicherungstufen bei netresearch gibt.
Schlechten Code zur Auslieferung zu bringen bedarf dort eines Versagens mehrerer Parteien nacheinander. Wahrscheinlichkeit: nahezu ausgeschlossen.
Vielleicht ist netresearch auch kein Maßstab für das, was Erik Meijer dazu bewogen hat, seine These zu formulieren. Gespräche “über Code” verlaufen dort teamübergreifend, projektübergreifend in einem eigenen Format. Das Treffen “Dev-Samurai” hatte mein Vorgänger dort, Jan Graf, ins Leben gerufen.
Code-Diskussionen finden dadurch nach meiner Wahrnehmung außerhalb der agilen Methodik statt. Für diesen Austausch der Entwickler miteiander ist das Vorgehensmodell ohne Belang.

Ich selbst habe in jeder anderen Umgebung, in der ich mit agilen Mechanismen vorgegangen bin, keinerlei Diskussion über Code erlebt.
Was es sehr wohl gab und gibt sind Diskussionen über technische Vorgehensweisen wie Continuous Integration oder das Vorgehen nach Test Driven Development. Überhaupt ist Test-Automation ein Dauerthema, das aus irgendeinem Grunde in seinem Wert durch Entwickler nicht erkannt wird.
DevOps ist ebenfalls ein weitgehender Standard. Alle diese Themen sind technischer Natur. Sie haben überhaupt nichts mit Programmiersprachen, Code und dessen Qualität zu tun.

Was wir alle verwenden ist Code als Hilfmittel zur Kommunikation. Wir bedienen uns der menschlichen Sprache, Zahlen, Symbolen, Diagrammen und noch vielem mehr, um miteiander in Austausch zu treten. Das ist auch Code. Das meinte aber der Honorarprofessor für Programmiersprachen-Design wohl nicht.

Ich interpretiere Meijers Aussagen unter dem Eindruck einer Session beim 2017er Barcamp. Dort berichtete Steffen Kastner am zweiten Tag davon, dass es in der Findungsphase von Projekten bei UnternehmerTUM schwer sei, die Softwareentwickler bei der Sache zu halten. Die Coder wollen machen, wo noch gar nicht fest steht, was denn überhaupt zu tun ist. Üblicherweise wird das in einer längeren Vorlaufstufe geklärt.

Ich rate in dieser Phase auch dazu, die Expertise der Entwickler einzubeziehen und die DevOps-Perspektive bereits bei der Formulierung der Anforderungen einzunehmen. Wenn wir aber eine stabile Entwicklungsgrundlage haben, wir also recht genau wissen, was zu tun ist, dann ist auch das nicht mehr nötig. Das einzige, was dann noch zählt ist das Verständnis dessen, was erreicht werden soll.

Das gemeinsame Verständnis des Ziels ist sehr erheblich.
Leider wird vor lauter Aktionismus wenig Zeit in das Verstehen investiert.
Aus meiner Sicht ist das ein Hauptziel des agilen Manifests.

In der täglichen Praxis wird jedoch wenig Zeit darauf verwandt.
Dieses Phänomen beobachte ich so häufig, dass ich es mittlerweile als Normalzustand empfinde. Es gibt Ausnahmen, die sind jedoch selten.

Ich habe diesem Phänomen mittlerweile einen Begriff gewidmet.
Ich nenne das den #EffizienzIrrtum, bzw. #EfficiencyError.
Es handelt sich dabei um den Glauben, sich nicht mit den Zusammenhängen beschäftigen zu müssen.

Ein Ergebnis des Effizienzirrtums ist selbstverschuldete Dummheit. Das könnte man akzeptieren und meinen, es sei die Sache jedes Einzelnen, wie klug er durch die Welt geht. Wir arbeiten allerdings nunmehr nicht als Gruppen an mehreren Instanzen einer Sache. Es geht nicht darum, dass wir Produktionsstraßen parallelisiert haben. Es sind keine minimalen Arbeitsschritte, die beliebig angelernte Kräfte ausführen können.

Bei der agilen Softwareentwicklung geht es darum, die Vielfalt der Beteiligten, die “Diversity of Equals” zur Wirkung zu bringen. Wenn es nicht gelingt, die Sichtweise eines Beteiligten zu nutzen, seine Expertise und Kompetenz zu integrieren, dann fehlt diese im Produktergebnis. Dann braucht man sich mit dieser Person auch gleich gar nicht zu beschäftigen. Sie fügt dem Produkt und seiner Entwicklung keinen Wert hinzu.

Was Meijer nach meinem Verstehen eigentlich bemängelt ist, das zu viel geredet und zu wenig getan wird.
Das hat aber nichts mit agilen Methoden zu tun. Auch nicht mit Beratern und Märkten und was dort sonst noch so in dem Artikel vorkommt.
Es hat etwas mit “Ownership” zu tun.

Beteiligt sich jemand und macht sich die Sache zusammen mit den anderen zu eigen?
Ist er “Contributor” oder nur Konsument in der gemeinsam verbrachten Zeit, also “Participant”?
Genau dieser Unterschied wird viel zu selten beachtet und noch weniger praktisch umgesetzt

In der heutigen Organisationswelt herrscht (noch) überwiegend eine Leader-Follower-Kultur vor.
Die meisten eingeübten Kommunikationsmuster verlaufen nach dem “Command & Control”-Muster ab.

Do, what I told ya!

Bei dem Gegenstand der agilen Softwareentwicklung geht das so nicht. Zumindest dort, wo Scrum sinnvoll ist und nicht nur Code generiert werden muss. Mit Scrum begeben wir uns behutsam und vorsichtig auf vollkommen unbekanntes Terrain.

Es gibt niemanden, der genau weiß was zu tun ist. Es gibt deshalb niemanden, der etwas allein-entscheidend vorgeben sollte. Stattdessen gilt es, Gründe für ein bestimmtes Vorgehen transparent zu machen. Wenn sich die Situation ändert – und das wird sie – kann man aufgrund dieser Transparenz in Bezug auf die Kausalität bestimmen, ob eine Situationsänderung erheblich ist und eine Anpassung im Vorgehen erfordert.

So können wir nur vorgehen, wenn uns zuvor miteinander ausgetauscht haben.

Wir müssen reden!

/Und was sonst noch?

Das eigentliche Thema des Abends war damit ziemlich bald abgefrühstückt.
Das Gespräch selbst endete sehr viel zügiger als es durch meine ergänzenden Ausführungen den Anschein erwecken mag.
Ich habe hier mehr als den unmittelbaren Austausch dargelegt. Ich habe die Anknüpfungspunkte zum Anlass genommen es mit dem anzureichern, das ich kenne und wo ich Verbindungen sehe.

Die Runde teilte sich nach meiner Erinnerung in mindestens zwei Kreise auf. Ich fand die Beiträge von Stephan spannend und vertiefte mich in ein Gespräch mit ihm.
Darin lernte ich unter anderem den Begriff “Organisation des Zusammenwirkens”.

Das fand ich spannend. Ich erkenne darin eine Parallele zu dem, was ich derzeit “Co-Effecting” nenne. Nach meinem Verständnis ist das der Oberbegriff zu

• Co-Working
• Co-Creation
• Co-Operation
• Collaboration

Der Begriff scheint etwas in die Jahre gekommen und vielleicht auch durch seine Herkunft aus der DDR etwas diskreditiert.
Möglicherweise war aber nicht alles schlecht …
Ich werde der Sache weiter auf den Grund gehen.

Im parallelen Gespräch ging es um “irgendwas mit Startups”, also das Entwickeln von Ideen zu ersten Prototypen. Anne berichtete von ihren Erfahrungen aus einer anderen Stadt. Dort sei sie vielen “Luftpumpen” begegnet.
In Leipzig sei das anders.
Als guten Einstieg empfahl sie den Leipziger Ableger des Startup-Weekend.
Hier finden sich Teams zusammen, die über ein ganzes Wochenende eine Idee verfolgen. Manche davon beziehen danach SpinLab, Social Impact Lab oder Räume im Basislager. In diesem Jahr fand es bereits im März statt.
Mal schauen, was die 2019er-Ausgabe hervorbringen wird …

Was ist das “Geheimnis” an diesen Veranstaltungen? Die Leute finden sich am ersten Tag um eine Idee zusammen. Neudeutsch: “Pitch”. Bis zum Abend des Sonntag zählt dann nur noch diese Idee – und ein paar biologische Grundbedürfnisse. Schlaf wird in solchen Situationen ohnehin überbewertet.

Und warum funktioniert das? Die Beteiligten haben “Skin-in-the-Game” und empfinden “Ownership”. Zumindest für die 54 Stunden bis zur Pokalüberreichung.
Und schon passte es wieder zu dem, was ich im ersten Teil meiner Ausführungen beschrieb.

Die vielen anderen Glanzlichter des Abends spare ich jetzt aus.
Komm einfach beim nächsten Mal, mach mit und bring Dein Licht zum Leuchten.

/Nachlese

Im Nachgang zu dem Treffen regt die meetup-Plattform an, eine Bewertung abzugeben.

Falk kommentierte, ihm sei das Treffen zu strukturlos und unfokussiert im Vergleich zu agiLEipzig. Das bot den Aufhänger, um das Format noch einmal deutlich herauszuarbeiten.

Das Scrum Meeting Leipzig ist ausdrücklich als Stammtisch-Format gedacht.
Es geht darum einen größeren Zeitrahmen für das zu bieten, was bspw. bei agiLEipzig zwischen den Sessions stattfindet.

Die zeitliche Nähe ist mglw. etwas unglücklich gewesen. Für meinen Geschmack dürfen zwischen den Terminen gern auch ein paar Wochen liegen.

/etc

Die Zeit zwischen solchen Gemeinschaftstreffen hat Einfluss darauf, wie solche Gespräche verlaufen. Einige meiner Impulse und Fundstücke teile ich. Was auch immer ich für beachtenswert halte, ist am einfachsten zugänglich über meinen twitter-Kanal.

/Weiterführendes

• Scrum Meetup Leipzig
• The Power of Code
• Turn the Ship Around! – einstmals eine Empfehlung von Conrad Giller
• Das Kunden-Lieferanten-Anti-Pattern
• Rage against the Machine – Killing in the Name of

/Medien

Das verwendete Foto stammt von mir und darf unter Namensnennung weiterverwendet und verändert werden. CC-BY-SA.

/lebewohl

Lebe lang, in Frieden und Wohlstand.
Mögen sich alle Bedürfnisse in Realität auflösen.

/berühmteletzteworte

Verläuft Dein Leben im Kreis?

Das Leben verläuft in Kreisläufen. Manche sind größer, andere kleiner.
An Ihrem Ende findet sich kein Ende – nur ein neuer Anfang.

Sprich zu denen, die es angeht. Teile, was Dir wichtig ist.