Hindernisse dauerhaft lösen durch Impediment Management mit A3-Denken

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 lösen - Am besten schnellProbleme 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.

Beispiel eines ausgefüllten A3-BogensIm 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?

  • Gemeinsame strukturierte ProblemlösungWä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ändnis noch 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?

Eine deutsche A3 – Vorlage finden Sie hier als Download (PDF, 1.2 MB). Um den Denkprozess dahinter zu lernen, empfehle ich das Buch Managing To Learn und die sehr schön illustrierten A3-Thinker Karten. Ein Beispiel zu einem ausgefüllten A3 – Bogen finden Sie auch bei Henrik Kniberg (auf Englisch).

Was kann man damit noch tun?

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?

Neue Räume öffnen – Mit Open Space in agilen Transitionen

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.

Ein Open Space ThemenplakatDas 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.

Open space in progress - afternoon at the Social Media Learning Lab (c) CC-BY Tatiana12Und 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.

Open Space groups, engagement (C) CC-BY Tatiana12Wir 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.

Dan Mezick, der diese Idee beim Scrum Gathering Paris darstellte, zeugt auch von positiven Erfahrungen beim Einsatz von Open Space in agilen Transitionen und bemerkenswerten Ergebnissen.

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.

Scrum skalieren – Communities of Practice (CoP) verständlich erklärt

Communities of Practice in ScrumStellen 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.

Definition einer CoPEine 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?

Scrum und IT-Kanban – Zwei Wege zur Agilität im Vergleich

(c) 2012, Muenchberger Service Jam, CC-BY-NDWährend Scrum schon seit etlichen Jahren die Veränderung in den IT-Abteilungen der Welt anführt, hat sich in den letzten Jahren noch ein Weg zu mehr Agilität entwickelt: IT-Kanban. Es lohnt sich daher, die Frage zu stellen, wo beide Wege Ähnlichkeiten besitzen und auch zu erkennen, wo Unterschiede sind, um entscheiden zu können, welche Vorgehensweise besser passen kann.

Scrum ist ein Framework für die Entwicklung und Wartung komplexer Produkte in Teamarbeit. IT-Kanban ist eine Change Management Methode, die eine schrittweise Transformation einer IT-Abteilung ermöglicht. Die Richtung dieser Veränderung kann hin zu mehr Agilität sein, muss es aber nicht. Das hängt von Ihren konkreten Zielen ab.

Scrum ist eine Revolution. Eine drastische Veränderung im Unternehmen, die auf diese Weise viele Probleme auf einmal beseitigen kann und alle anderen deutlich sichtbar macht.

IT-Kanban hingegen setzt auf Evolution in kleinen Schritten. Für manche Firmen ist dieser Weg angenehmer, dafür verpasst man möglicherweise das Potenzial, das in einer radikalen Veränderung steckt.

Ein wichtiges Konzept teilen beide Vorgehen: Sie etablieren Pull-Systeme also Umgebungen, in denen die Teams selbst entscheiden, wieviel Arbeit sie annehmen wollen. Und da es bei dieser Arbeit darum geht, mit möglichst wenig Aufwand den Kunden so früh wie möglich zufrieden zu stellen, folgende beide dem Denken der Lean Production (schlanke Produktion).

Das Sichtbarmachen von Wissensarbeit ist eine weitere Stärke, die beide Vorgehen nutzen: Durch Taskboards werden die in Arbeit befindlichen Aufgaben sichtbar und transparent für alle: Fortschritt wird greifbar.

(c) 2012, Muenchberg Service Jam, CC-BY-NDEin wichtiges Ziel ist eine optimierte Wertschöpfungskette. Das Mittel dazu die Etablierung einer Kaizen – Kultur durch Inspektion und Adaption.

Während Scrum dazu feste Iterationen als eine Art „Projekt-Herzschlag“ einsetzt, folgt IT-Kanban dem Fluß der Arbeit durch das System: Besprechungen werden durch situative Notwendigkeit einberufen.

Bei allen Unterschieden und Gemeinsamkeiten stellt sich damit die Frage, welcher Weg für Sie besser passt? Neben diesem Überblick ist die tiefere Beschäftigung mit beiden Vorgehensweisen wichtig, um die richtige Wahl für Ihre Situation zu treffen, denn der Transfer auf Ihren Kontext ist das Entscheidende.

Das klappt zum Beispiel mit einem Tagesworkshop, einer professionellen Kanban-Simulation oder auch im Selbststudium –  für den weiteren Einstieg finden Sie hier entsprechende Buchtipps.

Pair Programming – die kleinste Feedbackschleife in agilen Teams

Jeder Entwickler hat es schon einmal erlebt: Man kommt morgens zur Arbeit und ein Kollege hat sich krank gemeldet und wird vielleicht sogar längere Zeit nicht mehr ins Büro kommen.

Wer kümmert sich nun um die liegenbleibenden Aufgaben? Hat jemand das notwendige Wissen und kennt den Quelltext des Programms und die darin getroffenen Designentscheidungen gut genug, um schnell übernehmen zu können?

Um so schlechter das Wissen im Team verteilt ist, um so höher ist der etwas sarkastisch benannte „Truck-Faktor“ – die Wahrscheinlichkeit, dass das Projekt scheitert, wenn ein Entwickler ausfällt.

Eine Lösung ist der regelmäßige Austausch über geschriebenen Quellcode. Während eine Version davon die bekannten Quellcodereviews darstellen, ist die aktivere Variante das so genannte Pair Programming („Programmieren in Paaren“).

In einem permanenten Wechselspiel von zwei Entwicklern vor einem Computer entsteht so Quelltext, der während der Entstehung von vier Augen gesehen wird. Der gerade entwickelnde Kollege kommentiert während er Quelltext schreibt, was er tut, denkt also quasi laut.

Wenn der Programmierer, welcher gerade nicht die Tastatur hat, Fragen, Anmerkungen oder Ideen hat, teilt er sie dem Partner mit oder bittet kurzerhand um die Tastatur und „läßt Code sprechen“. So entsteht eine Feedbackschleife direkt dort, wo die Kunst bzw. das Handwerk stattfindet.

Dies spart nicht nur anderweitigen Kommunikationsaufwand, macht häufig mehr Spaß und hilft, Teams zusammenzubringen sondern steigert auch die Qualität, denn es rutschen weniger Bugs in den Produktivcode, wie die Grafik erläutert: Nur noch die Fehler, die beide Entwickler machen würden, kommen ungesehen davon.

Der zeitliche Aufwand steigt dabei, jedoch arbeiten Paare oft etwas schneller, sodass mit leicht höheren Produktionskosten gerechnet werden muss – dies ist jedoch häufig eine sinnvolle Investition in vielen Vorhaben, die eine längere Lebensspanne überdauern sollen, berücksichtigt man die oben genannten Vorteile. Vielleicht kennen Sie ja die Kosten von Fehlern, die an Ihre Kunden ausgeliefert worden sind? Entscheiden Sie selbst, ob diese Investition interessant sein kann!

Übrigens wird dann auch die Planung einer Iteration leichter, denn mehr Entwickler können nun immer mehr Aufgaben bearbeiten, da sie das benötigte Wissen gemeinsam haben.

Meine Empfehlung: Probieren Sie es aus und sprechen Sie über die Erfahrungen in einer Retrospektive.

…und wie wäre es eigentlich mit Pair Administration, Pair Designing und Pair Management?

Management 3.0 – Die Welt ist komplexer als wir glauben wollen

Update: Nächster Management 3.0 – Kurs am 25. / 26.10.2012 in Mannheim  – jetzt noch anmelden

Wir Ingenieure finden die Betrachtung, dass die Welt kausal funktioniert, irgendwie einleuchtend. Ich werfe Geld in den Fahrkartenautomaten und er druckt ein Ticket aus. Tut er das nicht, ist der Drucker vielleicht defekt oder das System muss neu gestartet werden. Aber nicht nur Ingenieure, die meisten Menschen sind der Meinung, dass es in der Regel einen Grund für ein Verhalten oder eine Situation gibt. Manchmal findet man ihn vielleicht einfach nicht so leicht. Oder?

Dieses Kausalität genannte Phänomen hat unsere Managementkultur stark geprägt. Führungskräfte versuchen in chaotischen Zuständen oder bei drohenden Fehlschlägen regelmäßig, die Kontrolle über die Situation zurückzugewinnen und die vermeintlich verantwortlichen Faktoren in die gewünschte Richtung zu beeinflußen. Im schlimmsten Fall gibt es die Suche nach einen Schuldigen.

Kausalität leistet der Wissenschaft einen unschätzbaren Dienst: Siedepunktberechnungen und Konstruktionspläne, vorhersagbare Flugbahnen von Raketen werden möglich. Und doch gibt es genügend Fragen, die wir nicht beantworten können: Wird unser Softwareprojekt wie geplant mit den definierten Funktionen fertig werden? Wie wird das Wetter in drei Wochen sein? Komme ich pünktlich zu meinem Termin am Freitag Abend durch die Münchener Innenstadt?

Wieso können wir diese Fragen nicht exakt beantworten? Was ist anders an ihnen?

Die Antwort ist die Komplexität. Damit ist nicht gemeint, wie man schnell denken könnte, dass es unüberschaubar viele Faktoren in einer Fragestellung gibt, sondern das unvorhersagbares Verhalten eines Systems. Dies zeigt uns zum Beispiel das Eulersche Dreikörperproblem von nur drei simplen Wassermolekülen: Die Zutaten sind simpel, das Systemverhalten komplex.

Solche Gegebenheiten blieben auch unseren Forschern nicht verborgen: Mittlerweile gibt es eine ganze Wissenschaft, die sich mit solchen Zusammenhängen beschäftigt, genannt die Disziplin der Komplexitätstheorie.

Wenn wir aufhören, kausales und lineares Denken auf komplexe Systeme wie Softwareprojekte und Teams anzuwenden und stattdessen auf die Komplexitätstheorie setzen, bedienen wir uns eines Modells, dass deutlich nützlicher ist und uns Antworten auf Fragen ermöglicht, die wir sonst nicht erhalten. Die Anwendung dieses Ansatzes auf die Führung von Scrum- und Kanban-Teams heißt „Agiles Management„.

Management 3.0 – Agile Leadership Practices in Deutschland lernen

Agiles Management ist ein häufig übersehener Teil agilen Vorgehens. Es gibt viele verfügbaren Informationen über agile Softwareentwicklung, agiles Testen und agiles Projektmanagement, aber wenig konkrete Praktiken für Entwicklungs- und Teamleiter. Unabhängig davon müssen auf dem Weg zum agilen Unternehmen aber nicht nur  Entwickler, Tester und Projektmanager neue Praktiken lernen. Auch Entwicklungs- und Teamleiter müssen eine solche neue Herangehensweise zur Führung und Steuerung agiler Organisationen lernen.

Mehrere Studien identifizieren, dass das traditionelle Management das grösste Hindernis bei der Einführung agiler Softwareentwicklung ist. Entwicklungsleiter und Teamleader dürfen also neu erfahren, was ihre Rolle in der agilen Organisation ist.

Jürgen Appelo hat sich seit einigen Jahren mit genau diesem Thema in seinem bekannten Blog auseinandergesetzt, im Buch „Management 3.0“ sowie den gleichlautenden Kursen seine Erkenntnisse aus seiner eigenen Zeit als Manager einer großen agilen Firma in den Niederlanden veröffentlicht.

Zweimal hatte ich im vergangenen Jahr die Gelegenheit, Jurgen in seinen Kursen zu besuchen und bin zu der Überzeugung gekommen, dass die Denkweisen und Werkzeuge, die er entwickelt hat, vielen Führungskräften im 21. Jahrhundert helfen können, professionell und erfolgreich in komplexen Umgebungen zu arbeiten. Daher biete ich in Kooperation mit Jurgen als offizieller Trainer in diesem und den kommenden Jahren offene Management 3.0 Kurse in Deutschland an.

Wenn auch Sie sich diesem Thema intensiver widmen möchten, finden Sie vieles dazu in Jurgen Appelos Buch und in meinen Kursen.

Die Kaizen-Kultur in Scrum und Kanban

Scrum ist ein sehr gutes Framework, wenn man in Teams von 7+/-2 Personen Software produzieren möchte. Mittlerweile hat sich Wissen um die Skalierung von Scrum über ganze Abteilungen und Organisation gesammelt und viele der in der Praxis auftretenden Themen sind diskutiert und mit einigen Lösungsvorschlägen umrissen worden.

Scrum bedingt per se einen kulturellen Wandel in Organisationen. Die agile Denkweise und die klare Sichtbarkeit von Problemen schafft den Grundstein für eine Kultur der stetigen Verbesserung (eine so genannte Kaizen-Kultur).

Nun hat sich während der letzten Jahre noch eine andere Art und Weise entwickelt, wie man eine solche Kultur etablieren kann. Die Methoden Kanban ist in die Softwareindustrie eingezogen und auch wenn manche den Begriff aus der Automobilindustrie kennen, so ist hier nur das transferiert worden, was im Softwarebereich funktioniert hat – unter dem gleichen Namen. Damit ist ein Werkzeug entstanden, was in seinem Grundprinzip ersteinmal bestechend simpel wirkt:

Wir visualisieren, was wir eh schon tun und begrenzen unsere Arbeit in einem Prozessschritt, um einen ausbalancierten Wertfluss zu erzeugen. Das hat viele schöne Nebeneffekte, wie bessere Teamarbeit und eben auch die Möglichkeit, zu erkennen, wie die eigenen Produktionsprozesse optimiert werden können.

Stattet man dann die Mitarbeiter auch noch mit der Befähigung aus, eigene Optimierungen durchführen zu dürfen und auch bei dabei eingeführten Fehlern das Vertrauen der Vorgesetzten zu genießen, beginnt ein Unternehmenswandel zur reifenden agilen Organisation.

Viele Wartungsteams haben sich dank der freien bzw. nicht notwendigen Einteilung in Iterationen dieses Modells bereits bedient und es lohnt sich in passenden Situationen, Kanban als Weg in die agile Welt zu nutzen. Evolution statt Revolution?

Die Frage ob Scrum oder Kanban besser ist, mag man beantworten mit der Frage, ob man besser eine Schraube oder einen Nagel verwendet, um ein Gemälde zu befestigen: Anbringen kann man es wohl mit beidem – mal ist jedoch das eine sinnvoller und mal das andere. Und manche meinen auch, es sei sowieso ein Vergleich von Äpfeln mit Birnen. Ich denke mir: Hauptsache es schmeckt.

Study Group: Gemeinsam lernen

Mein Kunde Softwarekontor hat mich beauftragt, eine Study Group zu initiieren. Bei diesem Format geht es um gemeinsame Weiterbildung und Austausch zu definierten Themen.

Das ganze funktioniert so:

  • Auswahl eines Lernbereichs
  • Auswahl von passenden Quellen (Webseiten, Bücher, Demos, Quellcode, Webcasts)
  • Definition, wie das Wissen erschlossen werden soll (Lesen in Vorbereitung oder vor Ort, Buchtausch alle 15 Minuten, Durchstöbern…)
  • Ermittlung des passenden Intervalls und der Länge eines Treffens
  • Erstellen einer Roadmap für alle Treffen zu dem Thema (optional)
  • Einigung auf eine Agenda für das nächste Treffen

Einen weiteren Tipp gab mir Deborah hierzu: Hat man mehrere Bücher zu einem Thema bietet sich an, diese erstmal gemeinsam zu sichten:

  • Jeder nimmt sich ein Buch für 15 Minuten, liest darin, was er möchte. Das kann ein Kapitelanfang sein, das Inhaltsverzeichnis, Skimmen einiger Seiten
  • Danach stellt jeder das gelesene den anderen aus seiner Sicht dar
  • Danach tauscht man die Bücher untereinander nochmal aus und wiederholt die obigen Schritte

Als Ergebnis hat jeder einen Überblick über das Lernmaterial, kann es grob beurteilen und per Konsenz kann entschieden werden, welches Material verwendet wird.

Entschließt sich das Unternehmen kostenfrei Getränke und ein paar Snacks oder direkt einige Pizzen zu ordern, wird aus einer Study Group schnell eine tolle Plattform des innerbetrieblichen Austauschs und der Teamentwicklung.

COVID-19 AktionMoment noch, spare 150,- €* bei Newsletter-Anmeldung

Wir unterstützen Dich + Deine Firma mit unseren Scrum-Zertifizierungskursen, um erfolgreich auf Veränderungen zu reagieren.

Melde Dich jetzt für den Agile Growth® Newsletter an + erhalte sofort Deinen Rabattcode über 150,- Euro für Deine nächste Online- oder Präsenz-Seminarbuchung. 

* gültig bei Seminar-Teilnahme im Jahr 2021, kombinierbar mit Frühbucher-Rabatt für Präsenz- und Online-Seminare.