In der heutigen Folge geht es um die Kraft der Gemeinschaft. Es geht darum, wie du Gemeinschaften dazu nutzen kannst, Veränderungsvorhaben, die gerade anstehen oder da sind, zu unterstützen.
Und was dabei zu beachten ist, welche Parameter wir uns anschauen und welche Reflexionsfragen wir uns in unserem Leben stellen, wenn es um das Thema Gemeinschaften geht.
Viel zu viele Meetings! Wer Scrum einführt und auf agiles Arbeiten setzt, kennt das Problem: irgendwer nörgelt immer darüber, dass es jetzt so viele neue Meetings gibt. Wir schauen uns die Symptome dieser Problematik an: hat Scrum wirklich so viele Meetings und was müssen wir tun, um sie effektiver zu gestalten?
Gerade läuft in Rückersbach wieder die Play 4 Agile Konferenz. Leider schaffe ich es dieses Jahr nicht, dort zu sein, aber ich habe mich heute daran erinnert, was ich 2019 bei meinem letzten Besuch alles mitnehmen konnte. Von einer Methode würde ich euch gerne in diesem Artikel berichten.
Damals hatte ich das Spiel Team Work mit dabei und bot eine Open Space Session dazu an.
Ziel war herauszufinden, wie man das Spiel mit Teams einsetzen kann, um sie in ihrer Entwicklung weiter voranzubringen. Wie immer bei einem Open Space stieg dann kurz vor der Session die Spannung. Es ist der letzte Slot der Veranstaltung, haben die Leute noch genug Energie? Kommt überhaupt jemand? Zu meiner großen Freude wurden alle Fragen mit „Ja“ beantwortet (Secret Learning: Bei Open Spaces mutig sein, das klappt schon!!).
Die Regeln
Zuerst habe ich den Teilnehmern das Spiel vorgestellt. Jede Karte enthält 6 nummerierte Begriffe. Das Tolle an den Karten ist, dass sie auf Deutsch, Englisch, Französisch und Italienisch beschriftet sind. Eine Person, die nicht erklärt und im Team der „Ratenden“ ist, nennt einfach eine Zahl zwischen 1 und 6. Zwei Leute sind für eine Runde das Erklär-Team, ziehen eine Karte und müssen in einem Satz den Begriff mit der genannten Nummer erklären. Dabei darf der Begriff, um den es geht, natürlich nicht selbst verwendet werden. Und damit es nicht ganz so einfach ist, darf jeder immer nur ein Wort sagen während sein Teammitglied den Satz dann weiter ausformulieren muss.
Das Gesellschaftsspiel vergibt Punkte für Erfolg und Misserfolg. Wir haben uns allerdings dagegen entschieden, das Zählen von Punkten in den Mittelpunkt zu rücken. Sobald der Begriff erraten ist, wechselt eine der erklärenden Personen ins andere Team und umgekehrt. Danach geht es von vorne los.
Let’s Hack it!
Nach ein paar Runden waren die Spielprinzipien klar, und wir haben überlegt, wie wir das Spiel auf unseren Alltag übertragen können. Ausgestattet mit Karteikarten und Stiften haben wir, jeder für sich, ein kurzes Brainstorming gemacht. Es wurden Begriffe notiert, die mit unserer Arbeit als Agilisten zu tun haben.
Für die nächsten Spielrunden waren dies unsere neuen Begriffe. Wir haben wieder eine Weile gespielt, um herauszufinden, wie dies das Spiel verändert.
Der Spaß ist geblieben (ein Glück 😉 ), und wir haben einiges darüber gelernt, dass nicht jeder gleich tickt. Die letzten Minuten der Session haben wir dann genutzt, um unsere Erfahrungen zusammenzutragen und abzuleiten, in welchen Situationen diese Übung eingesetzt werden könnte.
Was haben wir gelernt?
Sowohl das Original als auch die angepasste Variante des Spiels können, je nach Kontext, mit Teams eingesetzt werden.
Lasst es passieren, man kann den Satz nicht planen.
Reagiert auf die Veränderung, die euer Mitspieler in den Satz einbringt.
Vorgefertigte Karten sind nicht nötig, erstellt sie gemeinsam mit eurem Team.
Unterstützt eure Mitspieler, wenn sie feststecken – unterbrecht kurz, macht ein „Daily“ und findet gemeinsam heraus, welches Wort er oder sie gerade braucht.
Sackgassen sind Anknüpfungspunkte für spätere Diskussionen im Team.
Nur das gesamte Team sollte Punkte erzielen können (wenn man unbedingt Punkte zählen will).
Wo kann die Methode eingesetzt werden?
In der Opening- oder Closing-Phase einer Retrospektive.
Als Energizer in Workshops (dann evtl. doch mit vorher geschriebenen Karten, es soll ja schnell gehen).
Bei kontextspezifischem Brainstorming.
Beim Klären von Problemen, Missverständnissen bzw. Unklarheiten.
Ich bin mir sicher, es gibt noch mehr Dinge, die wir in Zukunft durch diese Methode und über ihre Einsatzmöglichkeiten lernen werden. Für eine 45-Minuten-Session bin ich aber mit dem ersten Ergebnis sehr zufrieden und freue mich darauf, die Methode bald in einem Team auszuprobieren. Solltet ihr jetzt angefixt sein und die Methode einsetzen, lasst mich gerne wissen, wie es gelaufen ist und was es mit euch und euren Teams gemacht hat.
Warum kann es legitim sein ein Team Assessment durchzuführen?
Wie gehen wir da ran, mit welcher Haltung und wir stellen Dir ein ganz konkretes Werkzeug vor, welches wir lieben und oft benutzen und stellen Dir auch drei Arten vor, wie Du dieses für Dich in Deinem Alltag benutzen kannst.
Heute gehen wir mit einem Prinzip aus dem agilen Manifest den kollektiven Burnout an, das uns hilft „nein“ zu sagen. Wir erklären Dir, warum es schwer ist nein zu sagen und welche vier Bedingungen Du in Deinem Projekt oder Produkt brauchst, damit Du nein sagen kannst, damit wir am Ende „ja“ zu den wirklich wichtigen Dingen sagen können.
9 neue Erkenntnisse für agile Teams mit Magic Maze
Dieser Artikel ist Ursprünglich im Januar 2020 erschienen.
Magic Maze für agile Teams -Was bisher geschah…
In meinem letzten Artikel zu Magic Maze hatte ich die uns bis dato 9 bekannten Erkenntnisse zusammengefasst und mit euch geteilt. Seitdem ist natürlich nicht Schluss gewesen. Ich selbst hatte bei Kunden mehrfach die Gelegenheit Magic Maze einzusetzen und zusammen mit meinem
Kollegen Veit sowie Stefan Zumbrägelbeim Global Scrum Gathering in Wien eine Open Space Session zu Magic Maze zu hosten. Mein Highlight bezüglich Magic Maze dieses Jahr war allerdings ein Certified Scrum Master Training mit Björn Jensen . Ich war als Co- Trainer mit dabei und konnte mit den Teilnehmern recht früh am ersten Tag eine Runde Magic Maze
Neun neue Erkenntnisse für agile Teams mit Magic Maze spielen, um sie für agiles Arbeiten zu sensibilisieren. Das hat nicht nur sehr viel Spaß gemacht, sondern auch noch richtig gut funktioniert. An dieser Stelle nochmal „Danke an Björn“ für diese tolle Gelegenheit und das Vertrauen!
Aber warum erzähle ich euch das alles? Es gab natürlich neue Erkenntnisse, insgesamt 9 neue Erkenntnisse für agile Teams mit Magic Maze. Und genau das treibt mich an, Magic Maze weiter mit Teams und in Trainings einzusetzen. Ich werde die bisher bekannten Erkenntnisse nicht nochmal hier zusammenfassen, dafür bitte den oben verlinkten Artikel lesen.
Feedback aus der Community
Kurz nach dem letzten Beitrag kam schon der erste Kommentar von Abigail Leijten, in dem sie zwei Erkenntnisse geteilt hat.
„Mut: es gehört Mut dazu, am Anfang dich als erste am Tisch zu setzen, wo du gar nicht genau weißt, was passieren wird.“ Das kann ich bestätigen, ich habe mehrfach größere Gruppen gehabt, bei denen wir auch die Rolle des Beobachters hatten und sich der Tisch somit erst zögerlich gefüllt hat. Das kann man in Retrospektiven auch oft beobachten. Man bittet das Team Beobachtungen zu teilen und es dauert eine Weile, bis sich der Erste traut oder freiwillig spricht. Sowohl im Spiel, als auch in der Retro, passiert aber nichts Schlimmes, wenn man die Initiative ergreift. Schönes Thema über das man im Debrief sprechen kann.
„Als Teil des „Agiles Mindset“ ist auch ein Satz „Jeder hat seine eigene Geschwindigkeit“. Wir hatten den Fall, wo manche Leute 3 Runden gebraucht haben, bevor sie den Teleporter komplett verstanden haben. Auch das war für die Gruppe ein schönes Learning.“ Das ist eine weitere tolle Erkenntnis, wie ich finde. Mir fällt das auch oft auf. Ich interpretiere da auch rein, dass man Leute nicht mit Informationen überladen und erwarten kann, dass es alle sofort verstanden haben. Man kann das Spiel noch so oft und ausführlich erklären – erst wenn es los geht, merkt man, ob es wirklich verstanden wurde.
Vielen Dank Abigail, dass du diese tollen Impuls mit uns geteilt hast!
Was wir neues gelernt haben
Ich knüpfe gleich an. Ich würde noch einen Schritt weitergehen und die Erkenntnis ziehen „einfach mal Machen“. Bei der Produktentwicklung wissen wir nicht, ob wir das Richtige bauen, bis wir den Kunden um Feedback bitten. So geht es mir als Facilitator des Spiels auch oft. Ob die Spieler meine Anweisungen verstanden haben, sehe ich erst, wenn sie es spielen. Und bisher hatte es keine Gruppe zu 100% verstanden. Das konnte dann aber schnell angepasst werden im Spiel. Ich weiß nicht, wie viel Zeit es gekostet hätte, um die Missverständnisse beim Erklären auszuschließen bzw. ich glaube es ist nicht möglich. Also Erkenntnis bzw. Parallele zu agilem Arbeiten, einfach mal machen und Feedback einholen!
Es gilt die Prime directive (von Norman L. Kerth). „Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.“ Übersetzt: „Unabhängig davon, was wir entdecken werden, verstehen und glauben wir aufrichtig, dass jeder sein Bestes in der gegebenen Situation mit dem verfügbaren Wissen, den Ressourcen und unseren individuellen Fähigkeiten getan hat.“ Wie sehr diese Haltung hilft, erkennt man bei Magic Maze in den Phasen, in denen gesprochen werden kann. Ist das erste Fingerpointing vorbei, haben die Teams in der Regel verstanden, was ihnen weiterhilft ihr Ziel zu erreichen und was nicht. Fingerpointing hilft nie! So ist es auch in Retrospektiven. Nicht umsonst ist die Prime directive dort so wichtig. Dieser Punkt baut ebenfalls sehr schön auf den Punkten 11 und 12 auf, wie ich finde.
Läuft man bei Magic Maze ein Feld zu weit, kann man diesen Fehler selbst nicht korrigieren. Man braucht Hilfe aus dem Team. Diese Erkentiss hat dazu geführt, dass die Runde gemerkt hat, dass es auch im Alltag OK ist, um Hilfe zu bitten, wenn man sich in eine Sackgasse manövriert hat. Denn man bedenke Punkt 13, es gilt die Prime directive; man hat es ja nicht absichtlich gemacht.
Der letzte Punkt aus meinem vorherigen Artikel bezog sich darauf, dass man durch lange Planung am Anfang nicht besser vorhersagen kann, wie sich das Labyrinth aufbauen wird. Ein Team hat dies noch um die Aussage „eine Schätzung am Anfang wäre sehr sehr ungenau“ ergänzt. Das Team weiß, dass es alle Mittel hat, um die Aufgabe zu lösen, aber es hätte sich nicht gut gefühlt eine feingranulare Schätzung abzugeben. Sicher ein tolles Learning für Personen außerhalb eines Entwicklungsteams. Nehmt den Punkt gerne gezielt mit ins Debrief, wenn ihr im Alltag Probleme mit den Ansprüchen an Schätzungen habt.
In den Phasen auf der Sanduhr wird immer fleißig gesprochen und geplant. Doch dann kommt oft alles anders. Das führte zu der Erkenntnis, dass eine gemeinsame Sprache und gemeinsames Wording nicht selbstverständlich sind. Auch das ist bei Scrum oft zu beobachten. Daher führe ich sehr gerne Grundlagentrainings mit neuen Teams durch, um die verschiedenen Taxonomien ans Licht zu bringen und eine gemeinsame zu verankern.
Der „Tu was Stein“ kann von jedem Spieler genutzt werden, um einem andren Spieler zu signalisieren, dass er etwas tun kann, das dem Team weiterhilft. Im Spiel passiert das sehr natürlich und unverzüglich, sobald eine solche Situation erkannt wird. Die Analogie zu Scrum ist das Impediment. Ein Spieler hält unwissentlich den Betrieb auf. Es ist total OK und auch wichtig, dies sofort anzusprechen. Im Spiel passiert das von alleine. Warum sollte das also im Alltag nicht ebenso selbstverständlich werden?
Ich schließe mit einem für mich schönsten Sätze in einem Debrief, der auch keiner weiteren Erklärung bedarf „Das Spiel hat aus Fremden innerhalb kürzester Zeit ein Team gemacht“
Dieser Artikel ist 2019 bereits erschienen und jetzt neu veröffentlich worden.
Ich Habe Magic Maze im Dezember 2018 kennen gelernt, als mein damaliger Kollege Veit Richter es in einer Open Space Session angeboten hat. Damals hatte er das Spiel schon einige Male eingesetzt und konnte wertvolle Erkenntnisse mit uns teilen. Seitdem habe auch ich es mit verschiedenen Teams genutzt. Wir haben es auch auf User Groups und Open Spaces eingesetzt, um es anderen Coaches in der Community vorzustellen, damit auch diese von diesem Brettspiel profitieren können. Und wer hätte es gedacht… es sind neue Erkenntnisse entstanden! In diesem Blogbeitrag möchte ich alte und neue Erkenntnisse noch einmal zusammenfassen. Wer das Spiel noch nicht kennt, bitte erst den Beitrag vom letzten Jahr lesen, damit ihr die Spieldynamik versteht. Auf diese werde ich hier nicht mehr eingehen (mehr dazu im Originalartikel, welcher oben verlinkt ist,) sondern nur noch auf die Erkenntnisse.
Bereits in Teil 1 enthaltene Erkentisse:
Retrospektiven finden (bis auf eine Ausnahme die ich kürzlich erlebt habe) jedes Mal ohne Aufforderung, sofort nach der ersten Runde statt und werden als sehr wertvoll wahrgenommen. Wäre hätte das gedacht?
In Phasen auf der Sanduhr stimmt sich ein Team wie im Daily Scrum ab und lernt dabei meist schnell, dass Schuldzuweisungen nicht hilfreich sind und eine nach vorne gerichtete Haltung deutlich zielführender ist. Man steckt sich Zwischenziele bis zur nächsten Abstimmung und geht diese an.
Abstimmung und Kommunikation wird als elementar angesehen, um Erfolg zu haben.
Ach ja; die Zeit! Die verlieren die Teams auch oft aus den Augen und die Sanduhr beendet die erste Runde mit einer Niederlage. Man einigt sich dann oft drauf, dass in der zweiten Runde jemand die Sanduhr, aka Timebox, überwacht. Die Spieler lernen so, dass jemand der Zeit und die Prozesse im Auge hat, Mehrwert liefert.
Neue Erkenntnisse:
Im Spiel gibt es den großen roten „Tu-Was- Stein“; das einzige Mittel zur Kommunikation, während Figuren bewegt werden. Nur mit dem „Tu-Was-Stein“ kann ich meinem Teammitglied mitteilen, dass ich ihn für etwas benötige. Bestimmt eine Person in der Gruppe und nennt ihn ab sofort Projektleiter. Onkel Ben würde sagen „with great power comes great responsibility“. Und so ist es auch. Er ist ab jetzt der einzige der diesen Stein bewegen darf. Zwei Muster konnten wir bisher dabei beobachten. Erstens führte diese Regel dazu, dass sich die anderen spielenden Personen geistig abgemeldet haben. Es gibt ja jemanden der aufpasst, damit nichts ins Stocken gerät. Der Projektleiter muss also voll dabei sein, damit das Spiel nicht zum Erliegen kommt. Keiner will mehr selbst mitdenken. Eigentlich nicht das, was wir in unseren Teams sehen wollen. Erfreulicherweise gibt es noch eine schöne Beobachtung bei diesem Setup. Sie tritt bei größeren Gruppen eher auf. Das erste Mal habe ich sie erlebt, als ich den PO eines Teams zum „Tu-Was-Stein“ Beauftragten ernannt habe und 8 Spieler damit beschäftigt waren das Kaufhaus auszurauben. Auf die Frage „Wie hat sich das mit dem Tu-Was-Stein für dich angefühlt lieber PO?“ kam eine sehr tolle aber damals für mich noch überraschende Antwort: (Zitat nicht 100% exakt) „Es war furchtbar, und so anstrengend, jedesmal wenn ich den Stein bewegen wollte, war die Aktion, die ich anzeigen wollte, schon erledigt bis ich den Stein überhaupt in der Hand hatte. Das Team braucht mich gar nicht, sie haben alle Herausforderungen selbst gelöst, bevor ich ihnen überhaupt ein Signal geben konnte. Es war sehr anstrengend dann wieder aufzupassen und einen neuen Blocker zu finden. Und am Ende haben sie es toll gelöst ohne mein Zutun“ . Und mein ScrumMaster Herz hat einen großen Hüpfer gemacht. Man kann also lernen, einfach mal loszulassen und den Experten zu vertrauen.
Dieses Learning hat auch deshalb so gut funktioniert, weil es eine Gruppe mit 8 Spielern war. Ich habe mich gefragt, warum das so ist und dieser Effekt bei kleineren Gruppen nicht so häufig zu sehen war.
Ab dem 5. Spieler wird eine der vier Grundbewegungen (Nord, Ost, Süd, West) doppelt vergeben. Bei 8 Spielern ist jede Himmelsrichtung doppelt besetzt. Wir haben also ein Team mit einem gewissen Grad von T- Shaping. Und das merkt man auch. Ist ein Spieler gerade total auf einen Character fokussiert und er könnte einen weiteren Character ebenfalls voranbringen, damit seine Mitspieler wieder übernehmen können, gibt es immer noch einen zweiten Spieler der dies dann tun kann. Es lebe das T-Shaping!
Kennt ihr auch diese Daily Scrums, die einfach nicht enden wollen. Nach 45 Minuten wird noch fleißig diskutiert und nach Lösungen gesucht. Magic Maze macht sehr deutlich, was dies mit dem Sprint Ziel macht. Da man nur eine begrenzte Zeit hat (wie im Sprint auch) die von der Sanduhr angezeigt wird und die unerbittlich auf 0 zugeht, wird einem sehr schnell klar, das man das Magic Maze Daily nicht überziehen sollte, da man sonst nicht mehr genug Sprint Zeit übrig hat, um das Ziel zu erreichen. Ein tolles Learning wie ich finde.
Apropos Ziel: Es ist total wichtig eines zu haben. Das merkte auch ein Team in der ersten Runde von Magic Maze, als sie etwas planlos umhergeirrt sind. „Was ist eigentlich unser Ziel?“ fragte ein Spieler. Was lehrt uns das? Ich habe entweder schlecht erklärt oder sie haben nicht aufgepasst. Ist letztlich total egal, was der Fall war. Wichtig ist nur die Erkenntnis, dass wenn wir nicht verstanden haben was unser Ziel ist, wir sofort nachfragen müssen. Sonst rennen wir kopflos in der Gegend rum. Und das kostet viel Zeit und Zusatzaufwand. Kommt Euch bekannt vor oder?
Man kann mit Magic Maze auch sehr gut darstellen, warum man komplexe Probleme nicht durch Planung im Vorhinein lösen kann. „Legt doch mal nur die Startplatte aus und bittet die Spieler alle Züge bis zum Ziel aufzuschreiben“. Seid bereit Fotos der Gesichter zu machen.
Ich bin mir sicher es werden in den nächsten Runden weitere Erkenntnisse dazukommen. Ich bin jetzt schon total beeindruckt, wie ein Brettspiel ohne jegliche Anpassung so viele wertvolle Botschaften für agile Teams liefern kann. Und das verbunden mit Unmengen von Spaß. Denn ich habe noch keine Situation erlebt, in der die Spieler nach dem ersten Scheitern (und ja liebe Spieler, es ist normal das die erste Runde in die Hose geht 😉 ) aufhören wollten.
Last but not least, Ehre wem Ehre gebührt. Danke lieber Veit, dass du mir dieses Spiel gezeigt hast und auch vorher erkannt hast, dass es sich super für die Arbeit mit agilen Teams eignet.
Wer seine IT-Projekte mit einer agilen Methode wie Scrum oder IT-Kanban durchführt, findet immer wieder Hindernisse heraus, die das Unternehmen davon abhalten, effizient und mit Freude zu arbeiten. Mal ist es ein Product Owner, der zu selten greifbar ist für sein Team, mal ein abstürzender Build-Server und mal fehlende Fähigkeiten im Entwicklungsteam für eine neue Produkt-Herausforderung. Solche Hindernisse werden Impediments genannt.
Probleme rufen nach einer Lösung.
Und meistens wollen wir sie so schnell wie möglich weg haben. Aus dem Sinn, gelöst und erledigt. Nicht wahr? Natürlich – wir wollen handeln. Nicht zuletzt ist es ja auch ein Teil der Rolle eines ScrumMasters und des Managements, die Bahn frei zu machen für die Entwicklungsteams.
Mit dem schnellen Sprung vom Problem zur Lösungsidee verpassen wir häufig aber eine wichtige Chance: Dem Problem gewissenhaft auf den Grund zu gehen. Oft sind die wahrgenommenen Auswirkungen nämlich nur die Symptome eines darunterliegenden, tieferen Problems. Und wenn wir dies nicht herausfinden, ist unsere Maßnahme entweder erfolglos oder behebt die Grundursache nicht – und das Problem kommt wieder. Vielleicht in einer anderen Form, vielleicht zu einer anderen Zeit. Aber es ist nicht nachhaltig gelöst. Wir verbennen Zeit und Energie.
Im Umfeld des Toyota Produktionssystems hat sich aus dieser Erkenntnis das so genannte A3-Denken entwickelt. A3 Denken ist dabei eine strukturierte iterative Vorgehensweise zur gemeinsamen Lösung komplexer Impediments.
Dabei ist physisch gesehen ein A3 tatsächlich ein DIN A3 großen Papierbogen mit einer spezifischen Unterteilung in Prozessschritte. Das A3-Denken ist somit also ein Denkprozess zur Lösung von Impediments in einem Unternehmen. Und dieser Prozess wird dann auf solch einer Vorlage festgehalten.
Die Prozessschritte eines A3s decken dabei einmal den vollständigen PDCA – Zyklus ab. Wir umkreisen ein Problem, um seine Essenz zu verstehen, erstellen Handlungsalternativen, setzen diese um und nutzen die Ergebnisse, um zu lernen.
Welche Vorteile ergeben sich daraus?
Während man mit einem solchen strukturierten Problemlösungverfahren arbeitet, trainiert man sein logisches Denken und kommt immer wieder auf neue Aspekte, die einem vorher nicht klar waren.
Ein erfahrener Mentor kann dabei durch die richtigen Fragen das Problemlösungsverständnisnoch weiter vertiefen. Systemisches Denken und der Umgang mit komplexen Sachverhalten wird so erlernbar. Und spätestens seit Management 3.0 wissen wir, dass ohne systemische Sicht das Management unserer Organisationen nicht erfolgreich sein wird.
Nach erfolgter Problemlösung gibt ein A3-Bogen eine konsistente Geschichte wieder: „Ich sah Problem X, fand dabei Grundursache Y und Tat Z mit dem Result ABC.“ Diese Geschichte ist ein Teil des Unternehmenswissens, dass wir so an Kollegen weitergeben können.
Sie möchten gleich loslegen und einen A3 selbst ausprobieren?
Wie eine ScrumMasterin letztens in einem Einzel-Coaching zu mir sagte: Das kann man ja auch prima im privaten Bereich einsetzen, um neue Lösungen zu entwickeln. Vielleicht kennen Sie ja auch diese immer wiederkehrenden Themen, die irgendwie nie richtig gelöst werden? Was würde passieren, wenn Sie einmal die Forscher-Brille aufsetzen und auf die Suche nach den Grundursachen gehen?
Wir sind häufig in Besprechungen. Oft mehrmals täglich. Unsere Kollegen laden uns ein, an wichtigen Themen zu arbeiten. Oder wir sie. Der Einladende entwirft eine Agenda, definiert ein Thema, stellt ein Problem zur Diskussion, möchte ein Ziel erreichen in einer vorgegebenen Zeit. Manchmal sind diese Besprechungen wirklich wichtig, oft nur teilweise informativ, manchmal versucht man aus Höflichkeit nicht zu laut zu gähnen oder gleich ganz zu entschlafen.
Das muss doch anders gehen. Wie wäre es, wenn wir das grundlegende Prinzip unserer Besprechungen umdrehen würden? Was passiert, wenn wir nur einen minimalen strukturellen Rahmen vorgeben und freiwillige Teilnehmer einladen, über ihre Lieblingsthemen zu reden? Wie wäre es, wenn man dabei nicht nur gehen könnte, wenn einen die Langeweile ergreift sondern sogar selbstverständlich geht, wenn man woanders mehr Beitragen kann? Und es sich dabei noch wie die längste Kaffeepause der Welt anfühlt?
Genau das ist ein so genannter Open Space:
Unter einem Open Space versteht man ein erprobtes Konferenzformat des selbstorganisierten Austausches, um in wichtigen Themen neue Ideen und Lösungen zu finden.
Seit 1985 gab es weltweit über 60.000 dieser Zusammenkünfte von manchmal nur 6 bis weit über 2.000 Personen. In allen möglichen Branchen wurden so neue Räume geöffnet für Lösungen und Innovationen.
In Deutschland trifft sich die agile Szene ebenfalls gerne auf diese Art und Weise. Denn es gibt viele Ähnlichkeiten zwischen agilem Arbeiten und einem Open Space:
Ein Facilitator erleichtert Selbstorganisation: Wie ein Agile Coach ist ein Open Space Facilitator jemand, der den Prozess sehr gut kennt und bei den Inhalten den Teilnehmern vertraut. Er unterstützt durch laterale Führung die Selbstorganisation aller, um gemeinsam bemerkenswerte Ergebnisse zu erreichen.
Und jeder gestaltet dieses Ergebnis mit. Denn ein Open Space lebt von dem, was die Teilnehmer mitbringen sowie eine Scrum Einführung von den Zielen und Wünschen der Teammitglieder und Organisation abhängt. Ohne Leidenschaft und Verantwortungsübernahme wird agiles Arbeiten schnell fade und langweilig, jede Besprechung zur Einschlafhilfe.
Informationen sichtbar machen, um zu entscheiden: In einem Open Space visualisieren wir die Themen des Tages an einem Anschlagbrett, ganz ähnlich wie ein Taskboard eines agilen Teams. So sieht jeder alle Informationen und kann die richtigen Entscheidungen treffen.
Wir dürfen Freiwilligkeit voraussetzen. Wer bei einem Open Space teilnimmt, ist nur da, weil er es möchte. Auch zu einer neuen Arbeitsweise wie Scrum kann man niemanden zwingen, das wäre ein Anti-Pattern.
Die Intelligenz der Gruppe nutzen: Wenn viele kluge Köpfe zusammenkommen, sind Lösungen komplexer Probleme leichter. Verschiedene Perspektiven der Intelligenz der Gruppe nutzt Scrum in seinen Besprechungen und Schätzverfahren. Im Open Space nutzen wir dieses Potential voll aus.
Fazit: Agile Transformationen und Open Spaces passen von ihrer Grundhaltung hervorrgangend zusammen, was auch die oben aufgezeigten Parallelen unterstreichen. Nutzen Sie die Kraft des Open Space in Ihrem Weg zum agilen Unternehmen.
Wann hatten Sie das letzte Mal ausgiebig Zeit, mit allen Ihren Kollegen zusammenzukommen, um intensiv die Themen zu besprechen, die Ihnen am Herzen liegen? Wenn das schon eine Weile her ist, dann probieren Sie doch einmal einen Open Space bei Ihnen aus! Und wenn Sie in einer agilen Transition sind, dann erst recht.
Stellen Sie sich vor, Sie würden in Ihrem Unternehmen agile Methoden wie Scrum oder IT-Kanban einführen. Vielleicht arbeiten Sie sogar schon so?
Softwareentwickler arbeiten nun in kleinen Teams von 5 – 9 Personen. ScrumMaster und Agile Coaches investieren viel Energie, diese Teams zu stärken und zu schützen. Im Laufe der Zeit entwickelt dabei jedes Team seinen eigene Definition davon, wie gute Softwareentwicklung aussieht und funktioniert.
Doch was ist mit Querschnittsthemen?
Wie koordiniert man gemeinsame Auslierferungen, an denen mehrere Teams arbeiten? Wie lernen wir teamübergreifend neue Softwareentwicklungspraktiken? Wie entwickeln wir Entwicklungsrichtlinien, die für alle Teams passen? Wo kommen Tester zusammen, um herauszufinden, was gute Qualität für sie bedeutet?
Wenn wir agil mit mehreren Teams arbeiten möchten, brauchen wir teamübergreifend einen Weg, solch einen Austausch zu gestalten. Eine Art von loser Interessensgemeinschaft aus Praktikern. Menschen, die freiwillig und aus Leidenschaft zusammenkommen – vielleicht wie wir Deutschen das so gerne in Vereinen tun (nur weniger bürokratisch)?
Vor über 20 Jahren beschäftigten sich die Sozialforscher Jean Lave und Étienne Wenger mit der Bedeutung von sozialen Konstrukten in Lernprozessen. Und sie formten den Begriff der „Communities of Practice“ – kurz: CoP.
Eine Community of Practice ist eine Gruppe von Personen, die ein gemeinsames Anliegen oder eine Passion für etwas besitzen, das sie tun und lernen wollen, wie sie darin durch regelmäßigen Austausch besser werden.
Eine Teilnahme an solch einer Community ist immer freiwillig – und unabhängig vom bisherigen Wissensstand. Anfänger, Fortgeschrittene und Experten treffen sich regelmäßig, um gemeinsam zu lernen.
Wie beginnt man nun so eine Community of Practice?
Das ist leicht! Derjenige, der für ein Thema eine große Leidenschaft besitzt, sucht nach Gleichgesinnten im Unternehmen. Man legt gemeinsam erste Ziele fest und lädt alle interessierten Kollegen zu einem großen Willkommens-Termin ein. Dort informiert man dann über das Vorhaben und bittet die Teilnehmer, um Feedback, ob sie in Zukunft auch mit an Bord sind. Ein erfahrener ScrumMaster als Experte für Teamprozesse kann von Anfang an schon als Facilitator den Weg der CoP begleiten.
Wie sähe Ihre Firma mit solchen Lerngemeinschaften aus? Was wäre dann anders? Wer würde zu welchen Themen wohl im Austausch sein? Wenn Sie Lust bekommen haben, selbst eine Community of Practice zu Gründen oder Kollegen dabei zu helfen, mit ihrer Initiative erfolgreich zu sein, empfehle ich Ihnen dieses Buch. Und danach viel Spaß bei der Umsetzung! Denn gemeinsames Lernen macht uns doch oft am meisten Spaß, oder?
Probleme rufen nach einer Lösung.
Das muss doch anders gehen. Wie wäre es, wenn wir das grundlegende Prinzip unserer Besprechungen umdrehen würden? Was passiert, wenn wir nur einen minimalen strukturellen Rahmen vorgeben und freiwillige Teilnehmer einladen, über ihre Lieblingsthemen zu reden? Wie wäre es, wenn man dabei nicht nur gehen könnte, wenn einen die Langeweile ergreift sondern sogar selbstverständlich geht, wenn man woanders mehr Beitragen kann? Und es sich dabei noch wie die längste Kaffeepause der Welt anfühlt?
Stellen Sie sich vor, Sie würden in Ihrem Unternehmen agile Methoden wie Scrum oder IT-Kanban einführen. Vielleicht arbeiten Sie sogar schon so?
Eine Community of Practice ist eine Gruppe von Personen, die ein gemeinsames Anliegen oder eine Passion für etwas besitzen, das sie tun und lernen wollen, wie sie darin durch regelmäßigen Austausch besser werden.