Follow my new blog

Montag, 31. Mai 2010

Gezieltes Coding Dojo

Dass das Coding Dojo am 26.5.2010 kein Coding Dojo war, darüber sind Ilker und ich uns durchaus einig. Der Rahmen war zwar der des üblichen Münchner Dojos – der Inhalt wich dann jedoch stark davon ab. Ilker hat diese Abweichung jetzt nochmal begründet und ich habe auch schon innerhalb dieser bezweckten Abweichung reflektiert. Was bleibt da noch zu sagen?

Messlatte #1: Die offizielle Zieldefinition

image Mir geht der Kommentar von Steffen Forkmann nicht recht aus dem Kopf. Ist da wirklich etwas zu kurz gekommen beim Dojo? Wenn etwas zu kurz kommt, dann weicht etwas vom Ziel ab. Was aber ist das Ziel eines (oder des Münchner) Coding Dojos?

In einem früheren Posting von Ilker ist zu lesen, das Ziel eines Coding Dojos sei…

“[d]ie erfolgreiche Vermittlung von nutzbaren Lerneffekten – für jeden Teilnehmer. Er sagte dass ein Dojo keine feste, durchgeplante Veranstaltung mit fixem Programm oder Paradigma sei, sondern dass das Dojo primär die Teilnehmer und den Lerngedanken im Fokus hat.”

Wenn ich das in Anschlag bringe, dann bin ich ziemlich sicher, dass auch das letzte Coding Dojo sein Ziel erreicht hat. Niemand sollte zu kurz gekommen sein. Denn einen “nutzbaren Lerneffekt” hat es für jeden gegeben. (Wer keinen hatte, melde sich bitte bei mir. Dann bessere ich nach.)

Und da es keine “feste, durchgeplante Veranstaltung mit fixem Programm oder Paradigma” ist, sollte auch meine anders als übliche Nutzung der Dojo-Zeit dojokonform gewesen sein.

Allerdings: Wie steht es mit den “Teilnehmer[n] und de[m] Lerngedanken”? Mein Eindruck war, dass die Teilnehmer nicht nur Empfänger waren, sondern stets mitgestaltet haben. Anders als sonst, aber immer noch aktiv. Sehr aktiv sogar.

Fazit: Gem. der öffentlichen Definition des Münchner Coding Dojos ist alles im grünen Bereich gewesen. Anders, ungewohnt, aber zielführend. Ilker hat sich “nichts zu Schulden kommen lassen”. Als “Salonier” des Community Lernens hat er seine Aufgabe erfüllt. Merci, Ilker!

Messlatte #2: Selbstgebastelt

Soweit die offizielle Definition von Coding Dojo. Ich möchte jedoch die Gelegenheit nicht verstreichen lassen, mir auch selbst über die Ziele eines Coding Dojos Gedanken zu machen. Was gehört aus meiner Sicht dazu?

Zunächst einmal zum Begriff bzw. dem Bild des Dojo: Steffen Forkmann (und andere) scheinen enttäuscht gewesen zu sein, dass im letzten Dojo soviel “Lehrereinsatz” war. Das ist allerdings – zumindest im Hinblick auf das klassische Dojo – ein Missverständnis. Ein klassische Dojo ist ein Ort des Lernens des rechten Pfads, der auch von Religion geprägt ist. Im Dojo geht es also klassisch um einen Kanon vermittelt durch eine Lehrer/Meister-Schüler/Lehrling-Hierarchie. Der Gedanke einer gleichberechtigten Community in Bezug auf die Lerninhalte ist dem klassischen Dojo fremd.

Wenn nun die Softwaregemeinde den Begriff Dojo für sich entdeckt, dann halte ich es für vermessen (oder zumindest missverständlich) ihn ohne diese klassische Wurzel zu denken. Ein Dojo nur als Dojo zu akzeptieren, wenn es keinen Lehrer gibt, täte also besser, die Veranstaltung anders zu nennen.

Das soll nicht bedeuten, dass in einem Coding Dojo alles so laufen soll wie in einem Kendo Dojo im Japan des 17. Jahrhunderts. Modernisierung im Geiste westlicher Gleichberechtigung und Individualität ist natürlich völlig ok. Achtsamkeit im Umgang mit einem Traditionsbegriff scheint mir jedoch angebracht. Insofern bin ich der festen Überzeugung, dass in einem Dojo auch mal eine Hierarchie auftreten darf: einer weiß was, die anderen wollen es von ihm lernen.

Überwachung der Zielerreichung: Ob mit der ohne Lehrer – in Ilkers Definition ist das ja auch offen gelassen –, ein Ziel ist für ein Dojo wie für jede Veranstaltung nötig. Laut Ilker ist das “nutzbare Lerneffekte”; im Dojo soll also irgendetwas gelernt werden. Die Teilnehmer sollen nachher schlauer sein. Was das ist, sei einmal dahingestellt. Ich nehme irgendeinen fachlichen Aspekt an. Ilker lässt auch das frei in seiner Definition – konkretisiert jedoch in der normalen Praxis. Test-Driven Development scheint mir am ehesten die Praktik, die das Dojo als Lerninhalt zu vermitteln versucht.

Wichtiger als der Lerninhalt ist mir an dieser Stelle jedoch, wie der erreicht wird. Steffen und andere favorisieren ein “Peer-Learning”, d.h. ein Lernen irgendwie ohne Lehrer, sondern von Teilnehmern auf mehr oder weniger gleicher Kenntnisstufe. Dazu gleich mehr.

Das ist ein valider Ansatz – allerdings kann ich dahinter nur Ernsthaftigkeit erkennen, wenn im Rahmen des Dojo auch eine Überprüfung stattfindet, ob das Ziel erreicht wurde. Wie findet aber eine Lernerfolgskontrolle statt? Bei den Dojos, die ich erlebt habe – sorry to say –, habe ich davon wenig gesehen.

Am Ende Spaß gehabt zu haben, ist keine Lernerfolgskontrolle in Bezug auf ein fachliches Ziel. Auch Funktionalität hergestellt zu haben, ist keine Lernerfolgskontrolle. Wie also stellen sich Steffen und die anderen es sich vor, den Lernerfolg in Bezug auf TDD oder anderes festzustellen? Solange der Anspruch existiert, dass nur ein ganz bestimmter Stil ein rechtes Dojo ausmacht, solange sollte auch klar gemacht werden können, wie denn dieser Stil seinen Erfolg sicherstellt.

Lernen von einander: Das Lernen in der Gruppe ist eine gute Sache. Lernen ist eine durchaus soziale Angelegenheit. Und Lernen ohne Machthierarchie ist auch wunderbar. Da bin ich dabei und finde es toll, das Ilker sich für einen solchen Lernprozess als “Facilitator” immer wieder zur Verfügung stellt. (Und nicht nur das! Ilker ist auch nimmermüder Motivator der Dojo-Sache. Das ist nicht zu unterschätzen.)

Ein Facilitator überwacht jedoch nur einen Prozess. Läuft alles gem. Prozessregelwerk? Tanzt keiner aus der Reihe? Gibt es keine Hindernisse, die dem Prozess im Wege stehen? Das im Blick zu behalten, ist Ilkers Sache.

Das bedeutet im Umkehrschluss und zur Entlastung von Ilker: Die Wissensvermittlung bzw. –generierung ist Sache der Teilnehmer.

Wie funktioniert das aber nur? Die Prämisse ist, dass es ein zu erlangendes Wissen gibt. Irgendwo hängt im Raum eine Latte (immer höher), die das Dojo überspringen soll. Aber wo hängt die? Wer weiß es, wenn kein “Lehrer” anwesend ist/sein darf?

image Leider, leider muss ich sagen, dass der Anspruch eines “Community Lernens”, bei dem alle gleich sind in der Diskussion, zwar schön ist – mir jedoch wenig effektiv und effizient erscheint. Es drängt sich mir das Bild eines Debattierclubs auf, in dem alle eine Meinung haben, es aber keiner so genau weiß.

Allemal solange keine systematische Ergebniserarbeitung und –sicherung stattfindet, wird da schnell viel geredet, die Energie fließt – nur wohin?

Wie gesagt: dass am Ende irgendwie Code läuft, ist mir nicht genug.

Wenn alle gleich “ahnungslos” sind, wer stellt am Ende fest, ob eine Lösung wirklich gut ist (oder zumindest besser als eine andere)? Gefühle haben dazu natürlich alle; und ein Durchschnittsgefühl lässt sich auch ermitteln. Solange wir jedoch den Anspruch haben, in einer Branche zu arbeiten, in der es auch mal gesichertes, also überindividuelles und geschmacksunabhängiges Wissen gibt, ist mir auch das zuwenig.

Übungsgruppen in der Universität arbeiten auch zusammen. Doch sie arbeiten in den Grenzen eines Korrektivs. Am Ende müssen sie ihre Ergebnisse präsentieren. Und die werden mit dem kanonischen Wissen verglichen. (Ausdrückliche Forschung, d.h. die Generierung neuer Erkenntnisse nehme ich hier aus.)

Beim Coding Dojo ist das zumindest nach dem Ideal einiger per Definitionem nicht der Fall; das nimmt kein kanonisches Wissen an – so scheint es mir zumindest. Wie also – das möge man mir erklären – kann ein Teilnehmer dann sicher sein, etwas zu lernen, wenn letztlich die anderen nicht schlauer sind als er – oder zumindest keine Rolle einnehmen dürfen, in der sie ihre Erkenntnisse gezielt den anderen vermitteln?

Man möge mich nicht falsch verstehen! Ich rede keiner Lehrerattitüde das Wort. Und der Wissenskörper befindet sich für mich immer im Fluss. Auch kann aus meiner Sicht Lernen immer nur jeder selbst; ein Lehrer ist bestenfalls Facilitator. (Im Clean Code Developer Camps haben Stefan Lieser und ich deshalb spaßeshalber das Ideal, dass das Lernen am besten funktioniert, wenn wir nur noch Kaffee ausschenken müssen und der Rest von selbst läuft ;-)

image Doch auch wenn der Wissenskörper im Fluss ist, hat er eine vom Einzelnen unabhängige (vorübergehende) Form, die zu erkennen sich lohnt. Zu der mögen TDD, Lambda Ausdrücke oder Funktionale Programmierung gehören. All das kann man besser oder schlechter tun. Aber wer weiß, ob eine Coding Dojo Gruppe es eher besser oder eher schlechter tut? Der Spaß an der Sache ist kein wirklicher Gradmesser dafür.

Mir geht es nicht darum, eine bestimmte Person auszuloben, die “es” besser weiß. Auch ich weiß nicht alles besser – aber von manchem glaube ich schon, dass ich es besser als manche weiß. Und so geht es mit anderen Themen anderen Community-Mitgliedern. Jeder weiß etwas – und auch mal besser als andere. Ist halt so. Und ist gut so.

Warum soll dann nicht der, der ein Thema besser beherrscht als andere, diese anderen anleiten? Warum muss Coding Dojo bedeuten, dass ohne Lehrer gearbeitet wird? Das will mir nicht in den Kopf.

Woher der Lehrer kommt, ist ja egal. Und über die Didaktik und Methodik lässt sich auch noch trefflich diskutieren.

Wenn es aber einen Lehrer gibt, also einen mit Wissensvorsprung, warum soll der nicht die anderen anleiten? Das halte ich für die effizientes Form des Lernens. Wir müssen uns ja nicht dümmer stellen als wir sind. Wie die Kinder zu lernen, also alles selbst herausfinden, ist eine romantische Vorstellung. Kinder lernen allerdings so, weil sie oft nicht anders können. Besser lernen sie, wenn man sie geeignet anleitet. Dann kann man nämlich das Verhältnis von Erfolg und Misserfolg steuern. Die Lernerfahrung ist dann eher motivierend.

Meine Zieldefinition

Und was ist der langen Rede kurzer Sinn? Was ist meine Definition von Coding Dojo? Hier Stichpunkte:

  • Coding Dojo bedeutet lernen in Gemeinschaft
  • Coding Dojo bedeutet den Willen zu Clean Code (Development)
  • Coding Dojo bedeutet, zunächst den state-of-the-art zu erarbeiten
  • Coding Dojo bedeutet, Code zu produzieren
  • Coding Dojo bedeutet Ergebnissicherung
  • Coding Dojo bedeutet, über das Lernen zu reflektieren
  • Coding Dojo bedeutet, Spaß mit gleichgesinnten Entwicklern zu haben

Das sind eine Menge Eckpunkte für ein Coding Dojo. Damit die alle verlässlich angelaufen werden, ist eine Moderation nötig. Ilker, du hast also auch in meinem Bild einen Job ;-)

Diese Eckpunkte spannen einen Raum auf, das Dojo. Wie das dann konkret mit Leben gefüllt wird, ist eine andere Sache. Ob Katas gemacht werden (kleine Aufgaben) oder über mehrere Sitzungen mit Hausaufgaben Projekte realisiert, das ist egal. Ob einer den anderen etwas vermittelt oder nicht, auch das ist mir letztlich egal – allerdings habe ich da so meine Meinung, wie effektiv das Lernen ist, wenn alle aus ihrer eigenen Unsicherheit heraus versuchen, Sicherheit zu erlangen. Das kann funktionieren – ist dann aber Forschung. Wer als pragmatischer Entwickler will aber forschen mit all dem, was an dem Begriff hängt?

Und nun kommt die Community. Was macht ein Dojo aus? Was gibt es diesen Eckpunkten hinzuzufügen? Was muss weg? Oder braucht es gar keine Definition und jeder macht einfach so für sich etwas und nennt es nur, wie die anderen?

12 Kommentare:

Carsten hat gesagt…

Ein Bestandteil der von Dir "klassisch" genannten Dojos (in den Kampfkünsten) ist aber auch die Wiederholung von Übungen, bis die Bewegungen als Reflexe abgespult werden können. Man lernt natürlich vom Meister, denn Wissen ensteht selten aus dem leeren Raum heraus. Die Vermittlung von Wissen ist also auch Grundsatz des Dojos.

Wenn also Begriffe wie Coding Dojo und gerade Kata verwendet werden und Du die Verwendung mit klassischen Hintergedanken möchtest, dann sollte man auch die Technik der Wiederholung von einfachsten Bewegungen bis zur Perfektion nicht vergessen.

Natürlich ist es schön, wenn alle Spass haben. Aber schöner ist es, wenn alle etwas gelernt haben. Ob das jetzt unbedingt die Inhalte der Session oder in Deinem Beispiel die verteilte Nutzung von Mercurial war, wäre für mich erstmal nicht so wichtig.

Und wenn für das Dojo kein fester Rahmen vorgegeben war, liegt die Enttäuschung wohl daran, dass manch einer mit einer festen Erwartungshaltung in das Dojo gekommen ist - übrigens nichts, was man in einem klassischen Dojo machen sollte, wenn ich überhaupt irgendwas aus den klassischen Kampfkünsten verstanden habe. ;-)

Carsten hat gesagt…

Ach, ein kleiner Nachsatz: Für mich hört sich Dein Inhalt nach einer guten Übung an. Das Abspulen einer FizzBuzz Kata wäre für mich z.B. nicht besonders aufschlussreich gewesen und ich bevorzuge es, neue Eindrücke mitzunehmen und nach der Reflektion z.B. in einer zweiten Session zu wiederholen bzw aufzubauen.

Thomas Christian hat gesagt…

Hallo Ralph,

ich für meinen Teil kann sagen, dass für mich ein Dojo sowohl das Lernen mit, als auch ohne einem Lehrer ist.
Nur weil ein Lehrer an einem Dojo beteiligt ist, schließt es TDD und coding nicht aus. Letztendlich geht es für mich in einem Dojo darum, dass ich etwas durch aktive Mitarbeit lernen kann und Spaß daran habe. Ob das jetzt mit oder ohne einen Lehrer ist, spielt für mich keine Rolle.
Bei der Variante mit einem Lehrer erwarte ich eigentlich sogar, dass ich durch das Dojo geleitet werde, da ich ja etwas von dem Lehrer lernen möchte. Das heißt, ich möchte mir Vorgehensweisen, Best Practices, o. ä. von dem Lehrer erklären lassen. Diese Dinge lernt man meiner Meinung nach eben nicht in einem Dojo ohne einen Lehrer, da niemand weiß, ob man die beste Lösung gefunden hat.
Bei der Variante ohne einen Lehrer, versucht man selbst die beste Lösung herbeizuführen und lernt durch die Diskussion mit den anderen Entwicklern.
In beiden Varianten allerdings, muss aktiv an der Lösung mitgearbeitet werden, um wirklich etwas davon zu lernen. Anderenfalls wäre es nur ein Vortrag.

Mir hat das Dojo sehr gut gefallen und ich konnte meine Kenntnisse im Bereich der Architektur wieder ein bisschen auffrischen. Natürlich hat es mir auch aus dem Grund so gut gefallen, da ich einer derjenigen gewesen bin, der mit an der Entwicklung einer Komponente beteiligt war, auch wenn der Code für kurze Zeit auskommentiert wurde. ;-)

Allerdings könnte ich mir vorstellen, dass es für diejenigen, die von den Softwarezellen noch nie etwas gehört hatten, recht kompliziert war, da gleich EBCs verwendet wurden.

Gruß Tom

Ralf Westphal - One Man Think Tank hat gesagt…

@Carsten: Ja, Wiederholung ist wichtig. Aber nicht unbedingt inhaltliche (immer wieder dieselbe Kata), sondern formale (immer wieder dasselbe Vorgehen).

In der Literatur wird für meinen Geschmack ein wenig zu sehr eine inhaltliche Wiederholung nahegelegt. Die ist nicht falsch - doch viel wichtiger finde ich es, einen Prozess zu haben, dessen Handgriffe ich immer wieder in neuen Zusammenhängen übe. Deshalb haben Stefan Lieser und ich inzw. mehr als 60 große und kleine Übungsaufgaben (von der Kata bis zur verteilten Anwendung) zusammengetragen, die alle einfach von den Anforderungen her zu verstehen sind - aber eben immer wieder Herausforderungen an den Prozess stellen.

-Ralf

Mike Bild hat gesagt…

Mit fehlen noch diese Stichpunkte:

CodingDojo bedeutet, Raum für Fehler
CodingDojo bedeutet, Raum für Exploration, Neues, Unbekanntes
CodingDojo bedeutet, Raum für Fragen (an die anderen Teilnehmer, ob nun Anfänger oder Sensei auf diesem oder jenem Gebiet)

Dadurch, so meine ich, lernen Anfänger von Senseis und Senseis von Anfängern. Vielleicht jeder der Benannten etwas anderes, dennoch mal mehr, mal weniger voneinander. Ob nun mit oder ohne anerkannten oder ernannten Sensei (Ich finde beide Varianten im Wechsel sehr spannend), für alle Beteiligten sollte das insgesamt attraktive und offene Klima des Dojos Grund genug sein, sich aktiv an der Lösungsfindung zu beteiligen und etwas neues für den Alltag mitzunehmen.
Gruß, Mike

Ralf Westphal - One Man Think Tank hat gesagt…

@Mike: "Raum für Fehler und Fragen" war für mich implizit. Aber vielleicht gut, das nochmal hervorzugehen.

Im Kern scheint mir jedoch das absolut Wesentliche: "es tun". Coding Dojo ist tätige saubere Softwareentwicklung (CCD) in einer Gruppe.

Es geht also nicht um neueste Technologien und es geht nicht ums Reden. Technologien werden natürlich eingesetzt und geredet muss auch werden. Aber CCD und Tun sind wichtiger.

Gibt es eine Abgrenzung zu einem üblichen Workshop? Ja, ich denke, in einem Workshop sitzt eher jeder für sich drin und es herrscht eine Atmosphäre von "möglichst viel mitnehmen und keine Fehler machen".

Beim Dojo gehts aber nicht primär um fehlerloses persönliches Lernen, sondern die Gruppe.

-Ralf

Mike Bild hat gesagt…

@Ralf ... Lernen durch Übung(Tun) - in der Gruppe. So ergibt sich genügend Feedback des eigenen Tun's zur Verbesserung (der Gruppe, persönlich und fachlich).

Nun, für mich bedeuted Workshop immer Teilnehmeraktivität. Mal stärker geleitet durch Sensei, mal weniger durch Moderation. Dann gäbe es für mich noch andere Formate des Lernens - Vorlesung, Vortrag, Session, und, und, und.

Workshop passt für mich deshalb schon zum Dojo. Der Dojo sollte allerdings noch mehr sein. Ein bisschen Trainingsraum, zum Üben und wiederholen von Abläufen. Ein bisschen Diskussionsrunde, zur Klärung von Fragen "Warum so und nicht etwa so?" Ein bisschen Spielwiese, um Fehler außerhalb des Projektgeschäftes machen zu können und neues zu probieren. Ein bisschen Stammtisch, um Spaß an der Sache in der Gruppe zu haben. Ein bisschen Projektarbeit, weil wir am Ende des Abends etwas erreicht haben wollen und das gemeinsam mit Struktur und Methodik, TDD und Clean Code. Und natürlich ein bisschen Schulung, weil schlichtweg viele engagierte Entwickler und Architekten zu den Dojos kommen. Jeder von ihnen kann, soll, muss sogar spannende, lehrreiche Wege zeigen und erläutern. Das wie und warum wird im Rahmen der Kata und im Zeitfenster am "Tun" demonstriert. Lehren und lernen am "Tun mit Ziel" erleben.

Was ist der Gradmesser ob eine CodingDojo Gruppe das eine besser oder schlechter tut? Das könnte ein Sparring-Kumite vereinzelt am "Tun" sportlich, spielerisch innerhalb einer CodingDojo Veranstaltung zeigen. Warum nicht? Code-Reviews der Repo Checkins mit entsprechenden Kommentaren sind auch eine Variante.

Was muss weg? Den allgemeinen Sinn, die Magie des CodingDojos durch "Das ist ein richtiges und das ist falsches CodingDojo." in seiner Methode keinen Raum zu geben. Ilker sagte: "Entscheidend ist, was den Teilnehmern Spaß macht." Dem kann ich mich anschliessen. Sie bestimmen wo es lang geht. Für den einen mit Abgrenzungen und sehr konkreten Erwartungen und für den anderen mit lockerer Atmosphäre. Mal Sensei, mal Exploration, mal reine Wiederholung. Fazit: Ying und Yang. Ein bisschen sollte von beidem, im Wechselspiel, im Zeitfenster mit Zielen, dabei sein. So, denke ich, bleibt ein CodingDojo spannend für alle mit Raum für Flexibilität.

Wo gibt es den die 60 Trainingsaufgaben?

-Mike

Ralf Westphal - One Man Think Tank hat gesagt…

@Mike: Die 60 Aufgaben stehen in einer Liste unseres internen Wiki :-) Die ziehen wir zu Rate, wenn wir Dojos oder Workshops machen. Manche kennst du auch schon ;-)

Da sie bisher nicht über Stichworte hinaus beschrieben sind, haben wir sie nicht öffentlich gemacht.

Zum Thema Spaß: Ja, Spaß soll sein. Lockere Runde. Vertrauensvolles Verhältnis. Alles gut und wichtig.

Und dennoch... mir ist die Spaßbetonung manchmal zu stark. Für Spaß gibt es Disco, public viewing, Quatsch Comedy Club, Kindergeburtstag...

Ein Dojo hat aus meiner Sicht nur seine Berechtigung als weiterer "Zeitfresser", wenn eben nicht der Spaß die höchste Priorität hat, sondern der Ernst, d.h. das verlässliche Lernen.

Ein Dojo ist keine Kuschelstunde, kein Veteranenverein, kein Debattierclub.

Die Atmosphäre soll locker sein, der Inhalt ernst. Sonst reicht es, gemeinsam ein Bier trinken zu gehen.

-Ralf

Mike Bild hat gesagt…

@Ralf @Aufgaben - Schade, ich hätte hier und da durchaus Spaß ;-) an weiteren Übungen allein und in der Runde gehabt.

Warum nicht Spaß als einen weiteren Motivator betrachten und fördern? Sollten wir nicht alle ein bisschen mehr Spaß an der Sache haben, gewinnen, wiederentdecken, entzünden, ...

Damit sollte ein Dojo natürlich nicht zu einem weiteren Teil der Spaßgesellschaft, in der der Veteranenverein regelmäßig in der Disco tanzt ;-), werden. Es bleiben erkannte und ernannte Ziele und ein evtl. Wechselspiele der Methoden.

Solange ein CodingDojo/Workshop, außer dem Versprechen etwas zu erlernen, keine Pflichtveranstaltung der Organisation/Firma/Handwerks/Branche ist/wird, bleibt noch ein weiteres Versprechen "Spaß mit gleichgesinnten Entwicklern".

-Mike

Ralf Westphal - One Man Think Tank hat gesagt…

@Mike: Lass es mich mal so formulieren:

Solange ein Coding Dojo in reflektierender Praxis im Kreis Gleichgestellter mit dem Ziel der Herstellung nicht funktionaler Qualität in Software befasst ist, geht alles.

Spaß oder keiner, Lehrer oder keiner, Architektur oder TDD, konzeptionieren oder coden...

-Ralf

Michael hat gesagt…

Es hat ganz offensichtlich eine heftige Diskussion begonnen. Ich möchte an dieser Stelle eigene Ideen und Gedanken hinzufügen.

Zunächst einmal denke ich, dass eine (nicht eingespielte) Gruppe nicht so effektiv ein Ziel erreichen kann. Gerade wenn alles gleichberechtigt zugehen soll. Da ist der Aufwand für Kommunikation und Abstimmung.

Im klassischen Dojo (wie ich es kenne) wird gezeigt und erklärt, aber noch mehr Zeit wird mit üben verbracht. Auch müsste ein Dojo regelmäßig und oft durchgeführt werden. Und ja, Anleitung finde ich wichtig. Regeln gibt es auch im klassischen Dojo. Man akzeptiert sie weil man lernen möchte.

Und Spaß, natürlich, warum nicht. Der Zweck ist aber etwas zu lernen. Und wie lernt man am besten, man spielt. Spielen ist überhaupt die beste Möglichkeit zu lernen, allein und in der Gruppe. Und spielen macht Spaß. Auch beim Spiel werden Regeln aufgestellt, wer mitspielen will beachtet sie.

Ich werde demnächst mehrere interne Dojos und Workshops durchführen. Mir ist dabei wichtig, das alle viel lernen. Noch wichtiger ist, das die Teilnehmer es im Anschluss auch anwenden können, möglichst eigenständig. Für die Durchführung habe ich eine ungefähre Vorstellung, weitere Anregungen, vor allem durch den Artikel von Ralf, gibt es in dieser Diskussion genug.

Michael hat gesagt…

Mein letzer Kommentar bezog sich auf den Artikel "Kollektiv intelligent codieren". Einmal nicht genau hingesehen, passt aber auch gut hierher