Follow my new blog

Samstag, 26. Juni 2010

Kollektiv intelligent codieren

Wenn ein einzelner Entwickler etwas codiert, dann hat das Ergebnis eine gewisse Qualität. Und wenn mehrere Entwickler zusammen etwas codieren, dann sollte das eine höhere Qualität haben. Oder?

Wie die sprießenden Coding Dojos zeigen, ist das nicht der Fall. Da mag der Spaß noch so groß sein, da mag die Motivation hoch fliegen – die Ergebnisse sind meist schlechter, als wenn ein einzelner Entwickler dasselbe probiert. Wenn nach 2 Stunden zwei 5zeilige Tests stehen und noch vielleicht 10 Zeilen Domänenlogik, ohne dass abzusehen wäre, wann die Aufgabe ganz gelöst sein wird, dann ist das ziemlich wenig.

Wie kann das aber sein, was geht schief beim Coding Dojo? Warum bleibt das Kollektiv der Dojo-Teilnehmer hinter Einzelleistungen verlässlich zurück? Oder sehe ich das ganz falsch und nichts geht schief? Ist das einzig schiefe der Sitz meiner Brille, durch die ich das Coding Dojo sehe?

Die anhaltende Diskussion (s. z.B. hier oder hier oder hier) über Sinn und Zweck von Coding Dojos lässt mich nun vermuten, dass die Diskutanten (mich eingeschlossen) aneinander vorbei reden.

Also setze ich heute mal meine übliche Brille erstmal ab und stecke mir eine Lupe aufs Auge.

Struktur von Dojo-Problemlösungen

Worum geht´s denn beim Dojo überhaupt? Es wird ein Szenario präsentiert, zu dem die Teilnehmer zusammen eine Lösung in Form von Code entwickeln sollen. Ob der Code durch einen Stellvertreter (Code Monkey) eingegeben wird, den die Gruppe “fernsteuert” oder ob Gruppenmitglieder reium den Code eingeben, ist an dieser Stelle nicht so wichtig. Ebenfalls noch nicht so wichtig ist, dass Dojos einen bestimmten Weg der Implementation favorisieren: das TDD.

Entscheidend ist die Art der Aufgabe: Übersetzung von Anforderungen in Code.

Diese Art der Aufgabe hat es nämlich in sich. Sie besteht aus zwei Phasen, die auch mehrfach durchlaufen werden können:

  • Phase 1: Kreativphase
  • Phase 2: Umsetzungsphase

Zwischen Anforderungen und “Produkt” steht mithin eine Barriere. Das ist der Entwurf des Produktes. Wie ein Produkt aussieht, ergibt sich nämlich nicht einfach so. Bevor man ein Produkt bauen kann, muss man eine Vorstellung davon haben, wie es aussehen soll.

Ein Bild vom Produkt, von der Lösung zu entwickeln, das ist nun ein kreativer Prozess. Aus den scheinbar oder tatsächlich möglichen Lösungen ist eine auszuwählen.

Ist die Auswahl getroffen, kann sie umgesetzt werden. Umsetzung erfordert also Klarheit in der Vorstellung, was umgesetzt werden soll.

Lösungsfindung und Umsetzung sind ganz verschiedene Tätigkeiten. Sie sind so verschieden, dass die Psychologie dafür zwei Arten des Denkens unterscheidet: divergentes Denken (oder auch laterales Denken) und konvergentes Denken.

image

Divergentes Denken ist in der Kreativphase nötig, konvergentes Denken in der Umsetzungsphase. Die Umsetzung ist also kein “no brainer”, sondern erfordert auch Denken. Denn selbst wenn die Lösungsstruktur grundsätzlich klar ist, bedarf die Umsetzung durchaus noch weiterer Entscheidungen. Umsetzung kann weit entfernt von “Malen nach Zahlen” sein. Umsetzung braucht Erfahrung und Kompetenz.

image

Sind Erfahrung und Kompetenz nicht aber auch für die Lösungsfindung (Kreativphase) wichtig? Interessanterweise sind Erfahrung und Kompetenz, also Expertentum, überbewertet, wenn es um kreative Lösungen geht. Lösungssuchende Gruppen sollten sich daher um Heterogenität bemühen; sonst schmoren Experten zu sehr in ihrem eigenen “Denksaft”. Der Horizont von homogenen Gruppen ist schlicht enger als der von heterogenen.

Fazit bis hierher: Wenn ein Coding Dojo daran interessiert ist, Anforderungen mit Code umzusetzen, dann ist es gut beraten, die zwei grundsätzlichen Phasen auf dem Weg dahin zu beachten. Ein Dojo muss sich also überlegen, wie es divergentes und konvergentes Denken herstellt.

Divergentes Denken in der Gruppe

Kollektive können gut divergent denken. Kollektive Intelligenz kann bei Problemen, die divergentes Denken erfordern, individueller Intelligenz relativ leicht überlegen sein. Ein Coding Dojo ist also gut aufgestellt, schöne Lösungsansätze für die gegebenen Anforderungen zu finden, da die Teilnehmergruppe gewöhnlich sehr heterogen ist.

Allerdings braucht es dafür eine Voraussetzung: das Dojo muss überhaupt eine Kreativphase durchlaufen. Nach Verständnis der Anforderungen muss es eine Phase geben, in der die kollektive Intelligenz divergent denkt. Ob diese Phase 3 Minuten oder 30 Minuten dauert, sei dahin gestellt. Das hängt ja auch vom Problem ab. Aber ohne eine solche Phase, d.h. einen Zeitraum im “Divergenzdenkmodus”, gibt es keinen Lösungsansatz.

Und wie sieht eine solche Kreativitätsphase aus? Was tun die Gruppenmitglieder da? Meine Vorstellung davon sieht so aus:

  • image Am Anfang der Kreativphase steht eine Stillarbeitsperiode. Jeder überlegt für sich, wie er/sie die Lösung gestalten würde. Warum Stillarbeit, wenn doch alle in der Gruppe sitzen? Weil sonst bei der folgenden Diskussion leicht die “Lauten”, die “Redseligen”, die “Schnelldenker” sich durchsetzen. Wird ohne einen Moment der stillen Besinnung gleich das kreative Getümmel eröffnet, haben “Leise” und “Langsame” wenig Chance, ihre womöglich besseren Ansätze zu Gehör zu bringen. Ohne Stillarbeit reduziert das Kollektiv also sein Potenzial – und nicht unbedingt auf die Kompetentesten. Hierzu mehr in “Group Genius”.
  • Auf die Stillarbeit folgt die Diskussion der verschiedenen Lösungsansätze. Die Gruppe trägt zusammen, was die Heterogenität ausgebrütet hat. Dabei sollten am besten alle (!) Teilnehmer gehört werden. Auch das wieder eine Maßnahme, um kompetente Zurückhaltende nicht zu verlieren.
  • Die Sammlung der Lösungsansätze erfolgt am besten am Flipchart/Whiteboard. Visual Studio oder eine Diagrammsoftware haben hier keinen Platz. Sie sind schlicht zu beschränkend. Die Kreativitätsphase braucht alle Freiheit und Flexibilität, die sie bekommen kann. Mit einem Stift in der Hand auf einer großzügigen Fläche ist sie am größten.
  • image Lösungsansätze sind keine Programme. In der Kreativphase wird nicht codiert. Es geht um ein Denken auf hohem Abstraktionsniveau. Es geht ums Modellieren. Stefan Lieser hat dafür ein Beispiel in seinem Blogartikel gebracht: eine Sequenz von Kullern (Funktionseinheiten mit klarer Verantwortlichkeit) war sein Modell für die Kata BankOCR. In seiner Lösungsskizze ist keine Klasse zu sehen. Und er hat sich auch nicht durch VS oder TDD oder C# behindern lassen. Wo ein konkreter C# Typname auftaucht, ist der auch nicht ganz scharf als Programmiersprachenkonstrukt gemeint. Er ist für Stefan eher nur ein Platzhalter oder ein Ausrutscher in eine andere Sprache. Ein Idiom, dass knackig eine Intention ausdrückt. Mehr nicht.
  • Damit die Kreativphase auf eine Lösung hin konvergiert, muss am Ende irgendwie gefiltert werden. Entscheidungen sind zu treffen. Wie Stefan bin ich der Meinung, dass dafür ein Konsens (Abstimmung) der denkbare falsche Ansatz ist. Im Konsens steckt nämlich kein Bezug zur Sache. Warum jemand die Hand bei einer Abstimmung hebt oder nicht, ist nicht erkennbar. Vielleicht ist sie von einer Lösung überzeugt, vielleicht genervt (und will deshalb schnell einen Mehrheitsbeschluss, damit es weitergeht), vielleicht unentschieden, aber von einem anderen Teilnehmer persönlich beeindruckt. Eine Abstimmungsmehrheit sagt nur aus, dass für einen Lösungsansatz aus irgendwelchen Gründen mehr Leute die Hand gehoben haben als für einen anderen. Das war´s. Alles andere ist eine hübsche Illusion. Konsens/Demokratie gehört in den Bereich der Politik und nicht in den der Wissenschaft oder des Ingenieurwesens.
    Aber was dann? Statt für Konsens plädiere auch ich für Konsent. Der Begriff kommt aus der Soziokratie und ist hier und hier und hier näher beschrieben. Bei Konsententscheidungen geht es nicht darum, eine Mehrheit für einen Vorschlag zu finden. Wer dafür ist, ist quasi egal. Stattdessen sucht der Konsent nach Widerstand. Er wird daher auch die “Herrschaft des Arguments” genannt. Damit kommt die Sache ins Entscheidungsbild. Widerstände müssen sich nämlich auf den Vorschlag und die Sache bzw. ihren Kontext beziehen. Müdigkeit oder persönliche Beeindruckung haben da keinen Platz. Wer Widerstand leistet, d.h. einen begründeten Einwand hat, der muss auch persönlich hervortreten und sich erklären; damit auch hier keine Stimme untergeht, wird im Konsentprozess ebenfalls jedes Gruppenmitglied befragt. Das fokussiert die Diskussion ungemein. Konsententscheidungen sind daher effizient und effektiv. Das kann man von Abstimmungen nicht so einfach behaupten. Denn Mehrheit bedeutet nicht Effektivität (das Richtige entscheiden) und Mehrheit bedeutet auch nicht Effizienz (schnell entscheiden). Wie wir aus der Politik wissen, kann es bis zu einem Konsens lange dauern. Mehr zum Thema z.B. in meinem Vortrag “Agile Entscheidungen” auf dem Mathema Herbstcampus.

Zweck der Kreativphase ist es, den umzusetzenden Lösungsansatz zu finden. Dabei stolpert die Gruppe selbstverständlich über Lücken oder Divergenzen im Verständnis der Anforderungen. Die Kreativphase überlappt daher mit der vorgelagerten Phase der Anforderungserfassung. Die habe ich oben jedoch nicht aufgeführt, weil sie nicht direkt mit der Softwareentwicklung zu tun hat. Softwareentwickler erheben keine Anforderungen, sondern müssen sie “nur” verstehen. Wer mag, darf aber gern Phase 0: Anforderungserfassungsphase vor die Kreativphase setzen.

imageNicht nur durch die Diskussion und weiterentwicklung verschiedener Lösungsansätze, sondern auch den “Rücksprung” in die Anforderungserfassung ist die Kreativphase also kein linearer Prozess. Sie ist “non routine work” und damit auch außerhalb der Reichweite von üblicher motivations-/produktivitätsfördernden Maßnahmen. Zuckerbrot oder Peitsche wirken nicht, um die Kreativitätsphase zu befördern. Im Gegenteil. Soviel als Anmerkung zur Arbeit in Projekten, die ja noch ausgeprägtere Kreativitätsphasen brauchen. Wer das nicht glaubt, der siehe hier.

Fazit: Lösungsansätze in der Softwareentwicklung entstehen nur in einem kreativen Prozess. Heterogene Kollektive können in so etwas gut sein. Allerdings braucht es dafür Raum und Struktur. Drauflosreden und Abstimmungen sind nicht genug. Gerade divergentes Denken muss also moderiert werden. Das Kollektiv soll sich ja auf den Inhalt konzentrieren, nicht auf die Form. Auch hier gilt wieder das Single Responsibility Principle.

Konvergentes Denken für die Umsetzung

Die Umsetzung eines Lösungsansatzes ist etwas anderes als den Lösungsansatz zu finden. Die Umsetzung braucht kein divergentes Denken, kein Querdenken, keine Vielfalt – sondern System. Bei der Umsetzung ist konvergentes Denken gefragt. Das greift auf einen Fundus an Erfahrungen und Techniken zurück. Es übersetzt den Lösungsansatz als Modell in die konkrete Welt der Implementationstechnologien.

Konvergentes Denken ist nun allerdings in der Gruppe schwierig. Tut mir leid, das berichten zu müssen. Aber so ist es. So sagt es die Psychologie. Wo beim divergenten Denken eine heterogene Gruppe hilft, da hilft beim konvergenten Denken eine homogene Gruppe, also eine Expertenrunde.

Wenn ein Coding Dojo nun aber eine heterogene Gruppe darstellt und vor allem eben keine Experten zum Thema TDD zusammenkommen (sondern Entwickler, die es lernen wollen), dann kann ein Coding Dojo per definitionem für die Umsetzung keine guten Voraussetzungen bieten.

In diesem Licht erscheint es doppelt kontraproduktiv, die Kreativphase wie im letzten Coding Dojo anlässlich des dotnetpro.powerday zu überspringen. Nicht nur wurde kein Lösungsansatz erarbeitet, nein, es wurde die Gruppe sogar sofort in die Phase gestoßen, für die sie am schlechtesten aufgestellt ist. Weder existierte also eine gemeinsame Vorstellung von der Lösung, noch eine gemeinsame Vorstellung von der Umsetzung.

Vielleicht ist Ilker da zurecht stolz auf 2 grüne Tests und ca. 10 Zeilen Domänenlogik für die Kata BankOCR gewesen. Denn bei so schlechten Voraussetzungen ist beides vielleicht eine Leistung.

Frustrierend empfinde ich das Ergebnis dennoch. Denn die Gruppe ist um größere Erfolge betrogen worden, weil man nicht “artgerecht” mit ihr umgegangen ist.

Wie hätte es denn aber besser aussehen können? Meine Vorstellung von einer “artgerechten” kollektiven Umsetzungsphase sieht so:

  • Das Coding Dojo definiert explizit, worauf bei der Umsetzung geachtet werden soll. Das kann einmalig geschehen (“Bei allen unseren Dojo achten wir bei der Umsetzung auf ABC und XYZ.”) oder für jedes Dojo immer weder neu (“Heute wollen wir uns auf XYZ bei der Umsetzung konzentrieren.”).
    Wichtig ist in jedem Fall die ausdrückliche Formulierung eines Umsetzungsrahmens. Denn nur so kann das Dojo bei der Umsetzung effizient gehalten werden. Kommentare, die sich auf Verhaltensweisen beziehen, die nicht im Fokus der Umsetzung liegen, müssen nicht verfolgt werden. Das entspricht wieder dem Konsentprinzip.
  • Während der Umsetzung übernehmen einer oder mehrere Experten in Bezug auf die Umsetzungsgrundsätze die Moderation. Sie setzen selbstverständlich nicht allein um; die Gruppe soll so gut es geht auch die Umsetzung vorantreiben. Aber die Experten leiten die Gruppe an. Sie halten die Gruppe im Rahmen der Umsetzungsgrundsätze, geben Hilfestellungen, regen an, erklären.
    Experte kann jeder sein, der sich in Bezug auf Umsetzungsgrundsätze berufen fühlt. Dazu muss niemand eingeflogen werden. Auch der sprichwörtliche Einäugige kann die Blinden anleiten. D.h. wenn sich auch nur einer aus der Gruppe etwas mehr mit einem Umsetzungsgrundsatz auseinandergesetzt und eine Meinung dazu entwickelt hat, kann er die Moderation über nehmen – und sollte es auch.
  • Nach der Umsetzung folgt selbstverständlich eine Reflexion. Wer mag, kann sie als Phase 3 ansehen. Darauf möchte ich hier aber nicht näher eingehen.

Warum braucht das Kollektiv bei der Umsetzung eine Moderation in Bezug auf die Umsetzungsgrundsätze? Weil die Gruppe zusammengekommen ist, um eben diese Grundsätze zu lernen. Wo aber keine/nur wenig Kompetenz ist, entwickelt die sich nicht spontan aus ungeleiteten, tappenden Versuchen einer heterogenen Gruppe.

Wenn man 10jährige in einem Raum sperrt mit einem Haufen elektrischer Bauteile und dem Auftrag, eine Lampenwechselschaltung zu bauen, ist kaum zu erwarten, dass da etwas herauskommt. Die Gruppe wird sich nicht das Wissen aneignen können. Zusammen mit einem Lehrer jedoch ist das möglich. Der baut die Schaltung nicht selbst, lenkt aber immer wieder die Aufmerksamkeit. Didaktik und Methodik müssen stimmen. Dann findet effizientes und effektives Lernen statt.

Bei einem Coding Dojo ist das nicht anders. Ohne Anleitung findet kein verlässliches Lernen in Bezug auf die ausgelobten Inhalte statt. Das sind meist die Umsetzungsgrundsätze (z.B. TDD, Architektur, OOP). Experten führen die Gruppe hin zur Kompetenz in Bezug auf die Umsetzungsgrundsätze. Sie greifen dabei so wenig wie möglich in den Gruppenprozess ein, aber soviel wie nötig, um den Fokus zu halten.

Irgendwas kann natürlich jeder auch ohne Anleitung lernen. Ich z.B. habe beim letzten Dojo gelernt, wie man rechteckige Blöcke in VS2010 markiert. So nett das aber auch ist, dafür gehe ich nicht ins Coding Dojo. Das kann ich auch bei einer Plauderei einer .NET User Group erfahren.

Fazit: Damit die Umsetzung eines Lösungsansatzes zügig und erfolgreich ist, braucht es Können. Wo das Können fehlt, muss es über Experten in die Gruppe eingebracht werden. Aber auch wo das Können schon in der Gruppe ist, braucht es Moderation für eine kohärente Arbeit der Gruppe.

Kollektive Intelligenz mit System

Ich schätze Ilker für seine hochmotivierte Art, Dojos durchzuführen. Und ich schließe mich seinen Latifa-Werten an.

Aber ich möchte bei ihnen nicht stehenbleiben. Sie sind für mich nur ein Rahmen, in dem für mich das eigentliche Lernen stattfindet. Und dafür ist meine Vision, dass es verlässlich stattfindet in Bezug auf klar kommunizierte Ansätze in der Umsetzungsphase oder auch der Kreativphase.

Darüber hinaus bin ich auch der Überzeugung, dass solches Lernen nur funktioniert, wenn es nicht eine gewisse Führung gibt. Im besten Fall versteht die mehr vom Lerninhalt als der Rest der Gruppe. Sollte das jedoch einmal nicht der Fall sein, ist noch nicht alles verloren. Allerdings muss die Moderation dann besonders sensibel sein.

Bei allem Willen zu Spaß beim Dojo und selbstverständlich grundsätzlicher Gleichberechtigung aller Teilnehmer glaube ich allerdings nicht, dass demokratische Anwandlungen oder “code first” Denke zielführend sind.

Mir scheint, dass die bisherigen Dojos die Kompliziertheit von Problemen unterschätzen und die Leichtigkeit, mit der sich Ansätze wie TDD lernen lassen, überschätzen. Sie glauben, ohne Kreativitsphase (oder gar Anforderungserfassungsphase) auszukommen. Sie glauben, ohne Expertenmoderation in der Umsetzungsphase auskommen zu können. Ihr Credo: “Durch den Code zur Wahrheit und zur Erkenntnis”

Dass es nicht so einfach ist, zeigen dann aus meiner Sicht die magerer Erfolge der Dojos. Wie gesagt: Irgendwas wird schon gelernt. Aber wird das gelernt, was sich die Dojo-Macher wünschen? Ich bezweifle es. (Wenn Sie sich überhaupt etwas wünschen jenseits des Barnum-Mottos “Hier ist für jeden was dabei.”)  Wird gelernt, was sich die Teilnehmer wünschen? Ich bezweifle es. (Wenn die überhaupt einen konkreten Lernwunsch haben und nicht bloß aus Neugierde kommen.)

Damit will ich nicht das Engagement bisheriger Dojo-Macher kritisieren. Im Gegenteil! Ich finde es sehr cool, dass wir hier in der .NET-Welt eine solche Szene entwickelt haben und eifrig diskutieren. Nochmal danke an Vorreiter Ilker!

Aber was am Anfang gut und ausreichend gewesen sein mag, ist es vielleicht jetzt nicht mehr. Der Geschmack kommt beim Essen. Und da es nun Katas und Dojos gibt, ist es – so scheint mir – an der Zeit, weiter zu gehen. Bisher war Dojo 1.0. Ich möchte jetzt Dojo 2.0. Ich möchte Coding Dojos nach oben skizziertem Schema, die noch mehr bieten als die bisherigen. (Oder vielleicht nicht mehr, sondern Anderes.)

image Und deshalb präge ich jetzt mal einen weiteren Dojo-Stil: den Schwarm-Stil. Ilkers Stil ist der Latifa-Stil, meiner der Schwarm-Stil. Warum Schwarm in der Stilbezeichnung? Das ist für mich eine Anspielung auf das Buch “Der Schwarm” von Frank Schätzing. Darin kommt eine Intelligenz vor, die sich aus “sichtbaren” Individuen zusammensetzt, eine kollektive Intelligenz, eine Schwarmintelligenz.

Mir ist klar, dass am Begriff Schwarmintelligenz eine Menge hängt, was nicht zum Coding Dojo passt. Aber egal ;-) Ich finde ihn knackig und es steckt auch das Kollektiv drin.

Jetzt stellt sich nur die Frage, wann und wo das erste Schwarm-Stil Coding Dojo stattfindet. Mal überlegen… Wenn es konkreter wird, berichte ich hier im Blog.

7 Kommentare:

Pete hat gesagt…

Hallo Ralf,
wie Du Dir selbst bereits in der Einleitung die Frage gestellt hast: Ja, Du siehst es ganz falsch und schief läuft nichts. Das Einzige was meiner Meinung nach aktuell in die falsche Bahn läuft sind Diskussionen und Blogartikel mit deren Mittel versucht wird das Bild eines "Coding Dojos" zu verzerren. Ich möchte das ganze noch mal auf eine andere Ebene heben und nicht zu sehr ins Detail gehen. Ilker hat glaube ich vergangenes Wochenende darüber schon genug philosophiert. Das Münchener Coding Dojo ist als eine Art Lerngruppe entstanden was auf Grund des Formats stetig wachsende Begeisterung verzeichnete. Der Grund dafür ist auf der einen Seite das Engagement von Ilker und mir, auf der anderen Seite natürlich die Teilnehmer, die bereit waren Ihre Freizeit zu opfern um mit uns ZUSAMMEN an einer Lösung zu arbeiten. Als Lerngruppe bezeichne ich persönlich ein kollektives erarbeiten einer Lösung und gegenseitige Vermittlung von Wissen. Das was Du bei uns in München beim Dojo präsentiert hast sage ich hier gerne nochmal: "Es war ne nette One-Man-Show; hat aber mit einem Dojo rein gar nichts zu tun." Ich weiß nicht wie Du das während deiner Schul- oder Studienzeit gemacht hast aber in Lerngruppen ist meist kein Lehrer dabei. Oder warst Du immer schon ein Eigenbrötler? ;-)
Auch verstehe ich nicht wie jemand, der sich als "Architekt" und Mentor bezeichnet ein derart destruktives Verhalten an den Tag legen kann wie beim Dojo auf den dotnetpro.powerdays. Dieses Verhalten hat mich an meine Schulzeit erinnert als ich noch derjenige war, der in der letzten Reihe saß und mit allein Mitteln den Unterricht sabotiert hat. Und genau das zeigt mir wiederum, dass Du das Format einfach nicht verstanden hast.
Wenn Du weiterhin der Meinung bist "Dojos" halten zu müssen tu mir persönlich wenigstens den Gefallen und benenne es anders. Was hälst du von "Ralfs Diskussionsstammtisch" ? ^^

Ralf Westphal - One Man Think Tank hat gesagt…

Part 1:

@Peter: Du kritisierst, dass das Bild vom Coding Dojo verzerrt würde. Aber welches Bild? Verzerrung kann nur eintreten, wenn es ein klares Bild gibt.

So ein Bild gibt es aber nicht. Ich kenne keine offizielle Definition von Coding Dojo. Ich kenne nur Interpretationen. Und da ist Ilkers Interpretation erstmal genauso legitim wie meine.

Dass die Lerngruppe in Muc sich engagiert, bezweifle ich nicht.
Dass ihr euch da rein hängt, sehe ich auch. Davor ziehe ich auch den Hut.
Ich seid die Dojomotivationsbären. Keine Frage. Das meine ich ganz positiv.
Toll dass ihr die Leute interessiert und sie wiederkommen.

Ich bezweifle auch nicht, dass ihr dort alle ZUSAMMEN an einer Lösung arbeitet.
Und ich bezweifle auch nicht, dass jeder dabei irgendwas lernt.

Doch dann beginnen wir auseinander zu driften.

"Irgendwas lernen" ist mir einfach zu wenig.
Es ist auch vielen anderen, die 1-2 Mal dabei waren zuwenig.
Deshalb sage ich: ein Dojo kann auch anders gehen.

Ilker hat die Dojodefinitionshoheit nicht gepachtet.
Es kann andere Formen von Dojos geben.
Falls ich den Eindruck erweckt haben sollte zu meinen, wie ein Dojo ausschließlich aussehen sollte, dann bitte ich um Entschuldigung.
Solchen Eindruck wollte ich nicht erwecken. Ich will nicht behaupten, dass ein Schwarm-Dojo nun das (!) richtige Dojo sein.
Es ist nur ein anderes Dojo, dass aus meiner Sicht Schwächen des Latifa-Stils ausbügelt.
Nicht mehr. Aber auch nicht weniger.

Deinen Vorwurf, mein Auftritt hätte "rein gar nichts" mit einem Dojo zu tun gehabt, perlt daher an mir ab.
Sorry. Aber mit deinem Urteil stellst du dich in die Position des Definierenden, des Wissenden, des Richtigen, des Wahren.

Und wenn du es als One-Man-Show bezeichnest, dass am Ende 4 Gruppen zusammen eine Software erfolgreich herstellen (auch wenns geholpert hat), dann versteh ich nicht, was Ilker da veranstaltet.
Er dirigiert die Teilnehmer mit seinen Fragen und Abstimmungen, er springt durch die Reihen mit Motivationsrufen.
Das ist keine Show? Da treibt nicht One-Man die Show an?
Get real, Peter.

In Lerngruppen ist kein Lehrer dabei. Hab ich in einem anderen Posting ja geschrieben.
Aber am Ende müssen Lerngruppen das, was sie meinen, gelernt zu haben, vor einem Lehrer demonstrieren.
Am Ende kommt einer und sagt hopp oder top.
Es gibt in der Schule für Lerngruppen immer ein Korrektiv.
Diese Korrektiv jedoch verweigert Ilker konsequent.
Was rauskommt ist nicht nur, was rauskommt - sondern auch noch immer gut.

...

Ralf Westphal - One Man Think Tank hat gesagt…

Part 2:

Inwiefern war ich pers. in der letzten Reihe destruktiv?
Bitte nenne mir konkrete Handlungen, die den Fortgang des Dojo gestört haben?

Lag es daran, dass ich mit eine Diskussion über die Signatur gewünscht habe?
War destruktiv, dass ich gebeten habe, man möge "den Versuchsaufbau" erklären oder gar rechtfertigen?
(Warum NUnit aus dem GAC, warum Tests im Implementationsprozess?)
War destruktiv, dass aus der letzten Reihe der Wunsch nach Löschen eines Tests kam?
War destruktiv darauf hinzuweisen, dass Ilker seine Abzählungen der Abstimmungen tendenziös vorgenommen hat?

Come on, Peter. Das kannst du nicht ehrlich meinen.
Ich habe sachliche Beiträge gemacht.

Und wenn wir ein bissen in der letzten Reihen rumgetuschelt haben, dann kann das die anderen nicht wirklich gestört haben.
Keine sonstige Diskussion schien mir dadurch behindert.
Ansonsten wäre es auch Ilkers Aufgabe gewesen, hinten mal für Ruhe zu sorgen.
Das hat er aber nicht getan - weil wir nämlich nicht destruktiv waren.

Mit "allen Mitteln sabotiert" hat niemand etwas.

Wir waren allerdings kritisch.
Ganz bewusst.

Zum Abschluss: Peter, mit Verlaub, du hast die Dojo-Wahrheit nicht gepachtet.
Du hast kein Dojo-Zertifikat von niemandem.
Du hast nicht mehr, als dass du ein paar Mal etwas veranstaltet hast, dessen Format du abgekupfert hast.
That´s it.

Deshalb lass es sein mir oder anderen den Gebrauch der Bezeichnung Dojo verbieten zu wollen.
Du machst dich lächerlich. Du tust der Sache nicht gut.

Und frage besser deinen Initiator Ilker erstmal, ob er das genauso sieht wie du.
Denn Ilker scheint mir entspannter. Der hat verstanden, dass es Stilrichtungen geben kann.
Und so machen wir schlicht Dojos mit unterschiedlichem Stil.

-Ralf

PS: Wenn du sagst, ich solle "meine" Dojos "Ralfs Diskussionsstammtisch" nennen übersiehst du übrigens, dass ich nicht als einziger der Meinung bin, dass Dojos auch anders ablaufen können.
Die Kritik ist breiter. Keine Sorge.
Aber, hey, warum ist das schlimm?
So gibt es halt unterschiedliche Stile in friedlicher Koexistenz.
Du bist herzlich eingeladen, bei Schwarm-Dojos mal mitzumachen.
Taste the difference ;-)

Stefan Lieser hat gesagt…

@Peter Puh, du haust ja ganz schön auf den Klotz! Auch mich würde interessieren, inwiefern "die letzte Reihe" destruktiv war. Wie Ralf schon geschrieben hat, haben wir durch Fragen versucht, eine andere Blickrichtung einzubringen. Und wir haben aktiv mitgearbeitet. Meine Skizze dazu findest du in meinem Blog.
Leider hat Ilker unsere Versuche uns einzubringen jedoch abgebügelt, in dem er ohne Diskussion gleich zur Abstimmung überging und sich dann regelmäßig "verzählt" hat.
Ich habe mich bereits dafür entschuldigt, dass ich nicht noch hartnäckiger versucht habe mich einzubringen. Und die Entscheidung, in der letzten Reihe zu bleiben, würde ich heute vermutlich auch anders treffen.
Ihr solltet akzeptieren, dass es unterschiedliche Sichtweisen zu Dojos gibt. Ilker tut das meiner Ansicht nach. Dein Kommentar wirkt so, als wollte dir jemand das Spielzeug wegnehmen ;-)

Fazit: die Welt ist bunt. Unterschiedliche Standpunkte und Herangehensweisen sind eine Bereicherung. Alldings nur, wenn es dabei zu offener Diskussion kommt. Sich beleidigt zurücklehnen und andere Ansichten als destruktiv abstempeln hilft nicht weiter.

Viele Grüße
Stefan, ein Schwärmer ;-)

Pete hat gesagt…

@Ralf
Ich hab in den letzten 10 Monaten einiges an Erfahrung in verschiedensten Dojos gesammelt. Teils als Moderator, Codeaffe oder als Gast auf internationaler Ebene. Ich will mich hier nicht profilieren wie manch andere sonder lediglich mein subjektives Empfinden zum Ausdruck bringen.

Was Ilker an Zeit und Energie in diese Sache investiert rechne ich ihm sehr hoch an. Wir saßen lange und oft zusammen um herauszufinden aus dieser Timebox das Optimum herausholen können. Das ich mich prinzipiell in dieser Sache nicht in den Vordergrund dränge hat persönliche Gründe. Von daher finde ich es auch vollkommen O.K., dass Du mich in Ilkers Schatten stellst :-)

Verbieten tu ich dir nichts. Dojos gibt es auf der ganzen Welt. Ich sage dir nur, dass Du meiner Meinung nach auf dem falschen Weg bist.

Und was die Destruktivität angeht:

Ich finde es hat einfach etwas mit Respekt zu tun.
Da wäre zum Beispiel die Bitte des Moderators zusammen zu rutschen um besser diskutieren zu können, der ihr nicht nachgekommen seit. Oder ein Twitter-posts in denen Fragen von Teilnehmern in lächerliche gezogen werden.

https://twitter.com/StefanLieser/status/16787224065

Es gibt noch ein paar andere Punkte auf die ich jetzt nicht näher eingehen werde. Allein diese zwei Vorfälle finde ich einfach nur respektlos und überheblich.

@Stefan:
Freut mich, dass Du dazu gelernt hast und die Sache heute anders siehst.

Ralf Westphal - One Man Think Tank hat gesagt…

@Peter: Was Ilker an Engagement in die Dojo-Sache steckt, rechne ich ihm auch hoch an. Wo ich kann, motiviere ich auch, zum Dojo zu gehen - unabhängig vom Stil.

Bei aller Hochachtung vor dem Engagement erlaube ich mir nur, auch Kritik zu üben. Oder zumindest für die Durchführung einen anderen Stil zu bevorzugen. Das schmälert Ilkers Leistung nicht.

Und zumindest ist hab kein Problem mit dir oder Ilker ein Bier zu trinken. Da können wir lustig plaudern. Dennoch ziehe ich ein Schwarm-Dojo dem Latifa-Dojo vor. Kannst du nicht so differenzieren?

Und selbstverständlich respektiere ich die Mühe, die ihr euch gebt, aus der Timebox das Optimum herauszuholen. Ich habe nur eine andere Meinung dazu, ob ihr euer Ziel erreicht. Gut gewollt ist noch nicht Ziel erreicht.

Aber wie gesagt: Ihr habt auch andere Ziele als der Schwarm (oder Lieser, Westphal & Co). Das ist ok. Kannst du auch ok dazu sagen?

Und wenn du felsenfest behauptest, der Schwarm sei auf dem falschen Weg... dann kannst du weiter machen, wie du magst. Das ist ok. Du musst nicht konvertieren. Ich aber auch nicht. Es lebe die Pluralität. Das sollte im Sinne der Gleichberechtigung von Latifa sein. Das solltet ihr als Latifa-Gentlemen akzeptieren können.

Allerdings würde ich mir wünschen, dass du deine Behauptung mit Fakten und Argumenten untermauerst. Ich habe mich bemüht, in mehreren Postings meine Position zu substanzieren. Dafür nehme ich Bezug auf Prinzipien, Praktiken, Konzepte aus Softwareentwicklung und Psychologie und Organisationsentwicklung. Ähnliche Versuche der Begründung der Effektivität habe ich bei euch noch nicht gesehen. Schade. Latifa stellt lediglich einige Regeln auf. Das wars. So isses, sagt Latifa. Aber nicht warum diese Regeln und keine anderen, keine mehr.

Am Ergebnis - sorry to say - kann man nicht ablesen, dass dieses Regeldogma besonders hilfreich wäre. Und damit meine ich den Code, um dessen Produktion es immer noch geht. Dass Teilnehmer irgendwas lernen auch bei Latifa, nun, das habe ich ja nie bestritten. Wenn ihr ausschließlich das wollt... Ok, dann habt ihr eine ausreichende Regelbasis.

Dass wir nicht nach vorn gerückt sind... hm... ja, das war ein bisschen Lümmelhaft.

weiter im nächsten Teil...

Ralf Westphal - One Man Think Tank hat gesagt…

Teil 2:

Auf der anderen Seite habe ich nicht bemerkt, dass andere Teilnehmer der Aufforderung gern gefolgt sind. Ich halte eine solche Maßnahme bei einem so kleinen Raum auch für Überflüssig. Sie gehörte zum Wunsch, eine Latifa-Kuschelatmo herzustellen. Dem Prozess hat sie nicht gedient. Höchstens dem Wohlbefinden des Moderators.

Zur Twitternachricht: Die ist erst geflossen, als Ilker völlig ohne jede Begründung meine inhaltliche Frage so gar rein gar nicht weiter verfolgt hat. Er hat sie schlicht ungentlemanlike übergangen. Weder hat er das mir als Einwerfendem begründet. Noch den Teilnehmern gegenüber. Bei sonstigem Willen zur Demokratie hat er sich von einem Einwurf eines Teilnehmers, der sich nicht lang mit einer Signatur aufhalten wollte, davon abbringen lassen - weil es ihm in den Latifa-Kram gepasst hat. Zuviel Nachdenken, zuviel Struktur, zuviel letzte Reihe. Und das obwohl es eine scheinbar ernst gemeinte Frage gab, was denn mit Signatur gemeint sei. Ilker als Moderator hat den ahnungslosen Teilnehmer im Regen stehen lassen.

Dass es jmd gibt, der nicht weiß, was eine Signatur ist... nun, das hätte ich wirklich nicht angenommen. Ich selbst wollte dazu auch nichts weiter sagen, um mich ganz bewusst aus Ilkers Dojo rauszuhalten. Ich wollte ihm einen Impuls mit der Frage geben, weil er sie in der Vergangenheit durchaus positiv aufgenommen hatte. Sozusagen eine Erinnerung an schonmal im Dojo Gelerntes. Leider wurde die Chance vertan.

Dass wir in der letzten Reihe saßen hatte übrigens noch einen Grund: in einem anderen Dojo hat Ilker Stefan und mich herausheben wollen. Das war uns unangenehm, weil es ja sein Dojo ist. Wir sind schon genug in der Community zu sehen. Also haben wir Ilker diesbzgl. vorher angesprochen. Und wir haben uns in die letzte Reihe gesetzt. Und ich hab deshalb auch keine Diskussionen vom Zaun gebrochen. Ein paar Einwürfe konnte ich mir dann jedoch nicht verkneifen.

Mit "respektlos" und "überheblich" solltest du dennoch vorsichtig sein. Erstens sind wir beim Dojo nicht im Kindergarten (sondern einer Profiveranstaltung mit Lernanspruch), zweitens hat Ilker Teilnehmerpositionen so mit Engagement und Demokratie übergebügelt, dass es auch nicht mehr ganz gentlemanlike war.

Dennoch: Euer Engagement ist cool. Davor ziehe ich den Hut.

-Ralf