PREMIERE! PREMIERE! PREMIERE!

/Begrüßung und Setup

Es war ein Abend voller Neuerungen.

Zunächst der Ort. Wir waren erstmalig bei COMPAREX, die sich nun pünktlich zu diesem Abend SoftwareONE nennen. Der Grund ist vermutlich ein anderer.

Dann das Pitching. Ursprünglich hatten wir Platz für 2×7 Sessions. Dank der üppigen Ausstattung am Standort waren bis zu 7 Meetingräume verfügbar.

Rolf begann mit meinem Favoriten des Abends, “User Story Mapping”. Leider hatte niemand eine ‘real-life’ story dabei und so kam das Thema nicht zustande.

Es wurden dann die drei Fragestellungen der Gastgeber. Darüber hinaus wurden keine Themen vorgebracht, die Klärungsbedarf beinhalteten oder Gesprächsbereitschaft auslösten.

Wobei … mal schauen, ob Rolf und ich beim nächsten Mal unser Spontanthema “Mods & Rockers in der Software-Industrie” vorschlagen.

Und nun standen wir da mit unserem leeren Board. Der zündende Einfall kam von Katja. Sie schlug vor, Worldcafé anstelle von Open Space zu nutzen. Und nach einer kurzen ‘No-dissent’-Abstimmung wechselten wir das Format.

Die Session-Hosts verbleiben als Fragesteller bei Worldcafé in den ausgewählten Meetingräumen und die Diskutanten wechseln zwischen den Räumen in drei Durchgängen. Zu diesem Zweck bildeten wir Gruppen “1-2-3, 1-2-3, …”. Und so kam es, dass ich zwischen Angelika und Sören stehend, zum Mitglied von “Gruppe 2” wurde.

Eine weitere Premiere betraf mich eher persönlich. Angelika schaffte es erstmalig, an einem Treffen von agiLE teilzunehmen. Aus Budget-Gründen endete mein Auftrag in ihrem Unternehmen mit einer Skywalker-Situation. Das Budget für eine Weiterbeauftragung wird in der aktuellen Unternehmenssituation nicht bewilligt. Bedarf an meiner Begleitung wird weiterhin gesehen. Im Verlauf des Abends hatte ich dann mehrere Gelegenheiten, um den aktuellen Stand zumindest in Grundzügen zu erfahren. Es freute mich zu hören, dass die Fortschritte bei der Agilisierung weiter Gestalt annehmen und das eine oder andere, was wir uns ausgedacht haben, beginnt Wirklichkeit zu werden.

Auf geht’s!

/1: Priotizing the Backlog

Meine erste Session drehte sich um Verfahren, Methoden, Werkzeuge und Praktiken, um Ordnung in das Backlog zu bekommen.

Wenn man es tut, wie es die “reine Lehre” vorsieht, so müsste sich zu oberst im Backlog die wichtigste Story befinden. Dann die nächst wichtigere usw. Das adressiert ein fundamentales Fehlverständnis im Zusammenhang mit agilen Methoden. Viele nehmen zunächst an, das Team setzt das um, “was es will”. Das ist soweit korrekt im Sinne von “Commitment” oder auch “Selbstverpflichtung”. Wozu sich das Team nicht selbst verpflichten kann, das wird auch nicht getan.

Die Aufgabe des PO ist aber wiederum, genug Material in der vereinbarten Qualität bereitzuhalten, so dass sich das Team ruhigen Gewissens dazu verpflichten kann, die DoD zu erfüllen.

Und so schlug ich DoE, DoR und DoD als Kriterien zur Unterscheidung vor. Die ‘DoD’ ist recht bekannt. Sie umfasst alle Akzeptanzkritrieterien und constraints die immer erfüllt sein müssen. Die ‘DoR’ enthält die Kriterien für die Beurteilung der Umsetzungsreife. Nur PBIs, die der ‘DoR’ entsprechen sind überhaupt qualifiziert, um in die Umsetzung zu gelangen. Ein gutes Beispiel für ein solches Kriterium ist die Schätzung. Erst wenn ein PBI im Umfang “Story” geschätzt wurde, ist es umsetzungsreif. Viele halten auch die Story selbst bereits für umsetzungsreif. Ich hingegen sehe die Story erst als umsetzbar an, wenn mindestens ein Task zu ihrer Verwirklichung beiträgt. Die ‘DoE’ wiederum drückt aus, ob ein Thema überhaupt wert ist, als Story oder Epic ausformuliert zu werden. Wenn man einen entsprechenden Filter (‘DoR’ erfüllt und ‘DoD’ nicht erfüllt) verwendet, dann hat man zumindest die Menge der PBIs, die zur Umsetzung anstehen.

Allerdings entsteht daraus noch keine Reihenfolge.

Nun ist es an der Zeit, die PBIs so zu sortieren, dass der höchste Wert durch die Umsetzung geschaffen wird. Oder anhand des geringsten Aufwands, der erwartet wird. Oder ein Impediment gelöst wird. Oder die Umsetzungsfähigkeit weiterer PBIs initial ermöglicht. Oder etwas gelernt wird.

Sehr schön fand ich den Beitrag von Karsten. Er hatte aus einer Veranstaltung mit Jeff Patton mitgebracht “Learnings before Earnings”.

Ich selbst habe berichtet, wie wir einst “Confluence Votes” verwendet haben, um einerseits ein Quorum zur Relevanz eines Themas zu erhalten. Nur, wenn in unserem Fall 5 unterschiedliche Personen für die UImsetzung gestimmt haben, dann wurde die Anforderung überhaupt erst als PBI aufgenommen. Andererseits kann man solche “Community Votes” auch verwenden, um die Wichtigkeit zu bestimmen. Bspw. würde die Reihenfolge durch Anzahl Stimmen ein primäres oder sekundäres Sortierkriterium darstellen.

Schön fand ich dann auch noch die Doppeldeutigkeit von “Order”. “Ordnung” kann man ja auch durch Reduzierung der Elemente erreichen. Ein probates Mittel ist dabei Löschen. Ein anderes wäre maximal restriktive Eingangskriterien. Bspw. maximal 3 PBIs überhaupt im Backlog zu haben, so wie es Boris einst propagiert hat.

Einig waren wir uns darin, dass ab spätestens 100 Einträgen die Übersicht schwierig wird. Rolf hat dabei die “Dunbar-Zahl” ins Spiel gebracht. 150 Mitglieder der Sippe kann man vielleicht noch gerade so kennen. Persönlich bekannt sind maximal 50. 😉

Nach drei Durchgängen kam das alles zusammen:

/2: Friends of, Gilden, CoP

In meinem zweiten Durchgang ging es um Zusammenschlüsse, die das verfügbare Wissen erschließen helfen. Ab einem bestimmten Komplexitätsgrad in der Organisation braucht es zusätzliche Struktur. Sobald es mehr als ein Projekt, mehr als ein Team, mehr als ein Produkt gibt, wird Struktur erforderlich und bildet sich in irgendeiner formalisierten oder informellen Form aus.

An dieser Stelle wird sowohl die alltägliche Arbeit als auch das Heimat-Team verlassen, um Wissen zu teilen oder fremdes Wissen zu erlangen. Spätestens an dieser Stelle geht es dann nicht nur um die unmittelbaren Kollegen. Der Anteil der Organisationsentwicklung wird ab hier für die Produktentwicklung maßgeblicher.

Von Rolf erführen wir, dass CoP – Community of Practice auf Chrysler zurück gehe. Dort habe man feststegestellt, immer wieder Bremsen und dergleichen erfinden zu müssen. Und so habe man allen Bremsenerfindern ein Forum gegeben, um ein gemeinsames Vorgehen zu bestimmen, wie man bei Chrysler Bremsen erfindet. Das Zugangskriterium war hier also “Bremsenerfinder”.

Ich berichtete darafuhin von Netresearch, wo einstmals Jan Graf den ‘Dev Samurai’ eingeführt hatte. Dort treffen sich alle interessierten Entwickler, um Technologien und dergleichen vorzustellen. Zugangskriterium: Entwickler.

Seinerzeit war mir die Zusammensetzung des ‘Dev Samurai’ zu homogen. Es betraf zwar den Kern des Geschäfts – Auftragsentwicklung – nach meiner Einschätzung wurde eine Menge Potenzial des Unternehmens auf dem Weg zum Code verschenkt.

Deshalb initierte ich eine zweite Veranstaltung, die sich sowohl an COder als auch alle anderen richtete. Ich nannte es ‘Culture Hackspace’. Es ging dabei darum, aus der eigenen und der Perspektive der anderen, eine Kultur der Gemeinsamkeit zu entwickeln. Es ging darum, das Potenzial freizusetzen, was jenseits des Auftragscodings in der Organisation steckt.

Aus dieser Zeit stammt bspw. das up2u-Protokoll. Es ist eine Sequenz, die signalisiert, wann es um mehr geht als die Zielerreichung … nämlich die Zielbestimmung, bevor man sich auf den Weg zu dessen Erreichung macht.

Die Erkenntnis, die diese Session bei mir herbeiführte war:

#Communities sind Gremien zur Normgebung. Click To Tweet

Das mag jetzt keinen Leser vom Hocker hauen, mich selbst hat es getroffen wie der Blitz.

Die sog. “Norming”-Phase ist die letzte und damit wichtigste Hürde auf dem Weg in die Phase 4 nach Tuckman. Das ist, wo alle immer sein wollen. Sowohl die Stakeholder als auch die Entwickler wollen ja “eigentlich” nichts anderes als

#Performance!

Dummerweise steht uns das Leben mit all seinen Menschen darin im Weg. Wir selbst, hach!, wir könnten ja so Vieles erreichen, wenn da nur nicht die anderen wären …

Die anderen bringen uns auf Ideen, teilen ihr Wissen, ihre Erfahrung und ihre Auffassungen mit uns. Und damit sind sie der Schlüssel zu dem, was wir allein niemals erreichen können. Alles das, was nur einen Hauch größer ist, als die eigene Summe an Fähigkeiten hängt davon ab, wie ich mit anderen umgehe.

Und hier ist eben die “Norm”, die implizite oder explizite, situative oder grundsätzliche Art wie wir es für am besten halten, die Norm, an der wir uns alle orientieren.

Eine Gilde, eine Community oder ein Treffen unter Freunden ist der Ort, an dem Kultur entsteht und Stil gelebt wird. Egal, wie dieser im Einzelfall ausgeprägt sein mag.

Die Art und Weise, wie es in einer Organisation gelingt, solche Zusammenschlüsse Gleichgesinnter zu ermöglichen und zu befördern, entscheidet über ihren zukünftigen wirtschaftlichen Erfolg.

Das beruhigende dabei: das, was passiert, wird das einzige sein, was passieren kann.

Es hilft, den Fokus vom “Wollen” hin zum “Können” auszurichten.

Machen ist wie Wollen, nur krasser. Click To Tweet

Unser Host Stefan, hat “einfach mal gemacht”. Mich hat schon am Abend beeindruckt, dass er sich bei seinen beiden Kollegen bedankt hat. Er berichtete von seiner anfänglichen Skepsis. Die zwei anderen haben ihn durch ihre Ermutigungen dazu gebracht, das Thema anzubieten.

Und mehr noch: er hat die Erkenntnisse aus den drei Durchgängen verschriftlicht. Er nutzt damit die selbe Methode, wie ich auch: “durch die Hand ins Hirn”. Indem man ein Protokoll führt oder einen Bericht verfasst, passiert Bemerkenswertes. Einerseits, wenn man sich schon zu Beginn zur Lieferung verpflichtet (‘comitted’), schärft das die Aufmerksamkeit. Andererseits, verfestigt sich das Erlebte. Man durchlebt es beim Schreiben wieder und wieder.

Darüber hinaus Stefan teilt sein Ergebnis-Dokument mit uns.
Hier: 2019-04-02 Meetup – Guilds and Community of Practice ist es.

/3: DDD – Domain Driven Development

Im letzten Durchgang ging es für uns um DDD  -Domain Driven Development.

Rene stellte uns zunächst die Ergebnisse der bisherigen zwei Durchgänge vor. Das nahm schon eine ganze Weile in Anspruch.

Rolf brachte die “Stimmungslage der agilen Community” ein. Als Nonplusultra werden Feature Teams angesehen und Component Teams als sub-optimal angesehen. Mit echtem DDD hatten wenige der Teilnehmer bisher Erfahrung. Auch ich habe mich da zurück gehalten, weil die Domains mit denen ich zu tun habe so groß sind, dass sie kaum mit dem vorgestellten Setup vergleichbar sind.

Ich selbst bevorzuge das juristische Verständnis, eine Domain sei ein Hoheitsgebiet mit eigenen Namen über das uneingeschränkte Kontrolle bestehe. Nun ja, war hier nicht wirklich der Fall.

Dann fragte ich danach, ob die vorgestellten Teams Fachthemen behandeln, die für sich genommen eigenständig seien. Ich sah es wie Rolf, dass der Domänen-Schnitt hier nicht überzeugen könne. Man hatte Dinge in ein Produkt vereint, die fachlich trennbar und separat überlebensfähig sein könnten.

Die tatsächliche Grenze vollzig sich aber anhand technologischer und territorialer Erwägungen. Jeder Standort hatte eine technische Kompetenz, die er exklusiv zum Produkt beisteuert.

Das hat einige Implikation. Bspw. muss Fachkompetenz immer mit der Bereitschaft Zusammenfallen, an diesem konkreten Standort mit diesen konkreten Personen zusammenarbeiten zu wollen.

Das Gefühl von Rene, es ginge alles irgendwie zäh und langsam kann ich voll nachvollziehen.

Rene berichtete noch, warum es diese Aufteilung gäbe. Vorher wäre die Kommunikation über Standortgrenzen schwierig und die Performance noch geringer gewesen.

Mich wundert das nicht. Früher sprachen die Beteiligten Code, heute sprechen sie Schnittstelle. Ein Praxis-Beispiel für Conway’s Law par excellence.

Ich würde denken, hier gibt es keine wirklich abgrenzbaren Domains. Vielmehr würde ich die Teams als Ansammlung von Komponenten-Teams halten, die ein Produkt verwirklichen.

/Und sonst noch?

Auf dem Rückweg haben Sören und ich dann noch einen weiteren der 4 Alexanders des Abends mitgenommen. Es gab die Gelegenheit, auch seinen Blick auf den Abend mit einzubeziehen.

What happened in the Multivan stays in the Multivan.

/Medien

Die Fotos habe ich gemacht. Wer mag, kann sie gern weiterverwenden (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.