Wenn du als Scrum Master merkst, dass du dein Team nicht vorwärtsbringst

Was machst du?
Diese Frage stellt sich mir seit ein paar Wochen. Ich spüre, dass ich das Team nicht so enablen kann, wie ich mir das vorstelle. Ziele, welche sich das Team vor ca. 3 Monaten selbst gesteckt hat, erreicht es nicht – und ist zufrieden mit der Situation.


Habe ich zu hohe Ansprüche an mich und an die Team-Mitglieder um sich dauernd zu verbessern?
Als Scrum Master habe ich hohe Ansprüche bezüglich der eigenen Leistung in der Rolle wie auch an die Teammitglieder und somit an das Team. Beim Team ist es primär der Anspruch sich immer wieder verbessern zu wollen, unabhängig davon wie gut das Team ist, denn «A rolling stone gathers no moss». Als Scrum Master möchte ich jede einzelne Person weiterbringen – was sich, im optimalen Fall, auf das grosse Ganze entsprechend auswirkt. Wenn es sogar messbare, konkrete Themen gibt, in welchen sich das Team verbessern kann, umso besser, da es greifbar ist für alle (z.B. Geschwindigkeit, Schnelligkeit). Mich triggert es, wenn das Team zufrieden ist, obwohl es offensichtliches Verbesserungspotenzial aufweist und trotz Interventionen nicht wirklich vorankommt. (Jetzt stellt sich die Frage nach den Interventionen, das gibt vermutlich einen separaten Blogbeitrag 😉). Hat ein Team seine selbstgesteckten Ziele und Verbesserungswünsche erreicht, dann gilt es diese zu feiern. Noch mehr jedoch gilt es die einzelnen Schritte auf dem Weg dahin zu zelebrieren. Die sind es, welche das Team wirklich voranbringt und im Endeffekt erfolgreich macht – und mich als Scrum Master enorm freuen.


Passen das Team und der Scrum Master mit seinen Skills zusammen?
Mit dieser Frage stellte ich fest, dass jeweils eine kontroverse Diskussion startet. Zum einen, dass sich so der Scrum Master zu sehr ins Zentrum stellt. Zum anderen, dass das Team dann erfolgreich wäre, im sich Wehren gegen Veränderungen bez. «gegen» den Scrum Master. Eine weitere Facette ist, dass der Scrum Master dann «versagt» hat, wenn er das Team nicht weiterbringt und den Hut nehmen würde.
Meines Erachtens ist es nicht ganz so trivial, da alles mal mehr mal weniger hineinspielt. Jeder Scrum Master hat seine eigene Art wie die Rolle gelebt wird und welche Skills die jeweilige Person einbringt aufgrund der Erfahrung, Charaktereigenschaften, Vorstellungen und Visionen sowie in welchem Kontext sich das Scrum Team befindet und deren Teamzusammenstellung. Hast du ein Team welches «open minded» ist und gerne Neues probiert, ist es sicher einfacher mögliche Lösungswege zu probieren, um sich für den passenden zu entscheiden. Hast du ein Team welches «Hierarchie gläubig» ist und Bekanntes stark wertschätzt ist es sicher schwieriger Lösungen zu probieren, um adäquate Entscheidungen zu treffen.

In diesem Fall wird Neues skeptisch betrachtet und anschliessend zugestimmt, um es auszuprobieren. Jetzt fragst du dich, wo ist nun das Problem. Beim Commitment. Es commiten sich alle dazu aus dem Team, jedoch wirklich leben und voranziehen tut es keine Person länger als zwei Tage. Oder es wird dem Scrum Master zuliebe gemacht, damit dieser glücklich ist. Beispiel: Das Planning ist stark optimierungsbedürftig. Die PBIs werden für den Sprint geplant inkl. den Tasks auf Stundenbasis. Die Kapazität ist geringer als die geplanten PBIs und Tasks. Darauf angesprochen in Retros, Workshop und gemäss Team Commitment im Planning «für den Fall, dass es wieder vorkommt», ist der Bedarf für eine valide Planung klein. Alle im Team sind glücklich; PO da all seine PBIs im Sprint sind, Developer hat den ganzen Sprint Arbeit und Testing hat genügend zu tun. Man kann dann immer noch PBIs in den nächsten Sprint schieben, wenn diese nicht abgeschlossen werden – oder die verfügbaren Stunden tunen, damit die Planung valide wird und der Scrum Master nicht mehr reklamiert.

Wenn der Scrum Master darauf aufmerksam macht, kommen entweder «hab’s vergessen», «passt doch so, wie wir es gemacht haben» oder gar keine Reaktion. Hiermit habe ich echt Mühe, da es sich aus meiner Sicht um erwachsene mündige Menschen handelt, welche «in charge» sind und der Scrum Master kein Diktator ist, der befielt, wo es durchgeht. Hier fordert mich das Team stark um meine Fähigkeiten bezüglich Umgangs mit «Widerständen im Commitment» zu trainieren. Zurzeit versuche ich es direktiv und eher «Drill Sargent« mässig, was weniger meiner Haltung entspricht jedoch für mich wichtig ist, es auszuprobieren, ob so mehr erreicht wird mit dem Team. Das bringt mich auch zur Frage nach dem zusammenpassen des Teams und Scrum Master, weil das, was ich an Repertoire habe, und in den vergangenen Monaten dazu lernte, auch durch Coaching, das Team anscheinend nicht weiterbringt. Der Teamentwicklungs-Workshop vom Herbst 2022, welche durch Externe geleitet wurde, scheint leider ebenfalls verpufft zu sein. Die Teammitglieder mögen sich, was echt klasse ist. Produktiv ist es bis jetzt nicht wirklich was besser geworden.

Was ist eure Erfahrung in dieser Situation? Ist es Team blaming wenn der Scrum Master mit einem Team nicht weiterkommt? Was macht ihr hier konkret?


Ist es ein Aufgeben oder eine sachlogische Entscheidung?
Das ist das Dilemma, in welchem ich zurzeit stecke. Wie obenstehend gelesen, es sind alle happy so wie es ist – ausser der Scrum Master. Wenn das Team glücklich ist mit seinem Weg, ist der Scrum Master zu kritisch? Wenn das Management mehr Planbarkeit und Aussagekraft vom Team erwartet, hat der Scrum Master versagt? Gibt der Scrum Master auf, wenn er sich entscheidet weiterzuziehen, da Energie und Aufwand für ihn nicht zufrieden stellend ist (ROI subjektiv gefühlt ca 40%).

Ich liebe die Rolle als Scrum Master, da es absolut geil ist Menschen und Teams zu begleiten, herauszufordern und weiterzubringen. Die Reflexion der Rolle und des eigenen Handelns ebenfalls, weil nur so kann ich besser werden und noch mehr dazu lernen für zukünftige Herausforderungen.

Learnings
Was ich bis jetzt gelernt habe in diesem Team und für die Zukunft mitnehme möchte ich nachstehend mit euch teilen.

Noch klarer Kommunizieren.
Ich tendiere stark dazu dem Gegenüber Fragen zu stellen, damit die Lösung für ein Problem selbst gefunden werden kann. Hier werde ich künftig viel mehr konkrete Lösungen direkt anbieten statt das Gegenüber studieren zu lassen, wenn diese Art zu Coachen nicht funktioniert nach zwei Mal.

Schneller aktiv Handeln.
Weniger Zeit nehmen mir das Ganze anzuschauen und mit feinen Interventionen zu verändern. Sondern rascher proaktiv angehen, auch wenn das Gegenüber sagt es werde jenes oder dies angehen.

Auf das Bauchgefühl hören.
Ich wollte es bei diesem Team «richtig» und «gut» machen um «erfolgreich» zu sein und alle Parteien «glücklich» machen und habe mein Bauchgefühl vernachlässigt. Dieses zeigte sich in der Vergangenheit jedoch immer als gut und zuverlässig.

Scrum Master Rolle ist der Hammer.
Die Rolle mag ich nach wie vor und trotz – oder gerade wegen – diesen Schwierigkeiten. Wo bekommt man sonst so viel Abwechslung innerhalb eines Jobs?! Und ich liebe Abwechslung, so wird es nicht langweilig 😊

Wie geht es weiter? Welche Möglichkeiten gibt es?
Nach Gesprächen mit dem direkten Management stehen diverse Fragen im Raum.
Sei es bezüglich des Scrum Masters, ob ich mit der Arbeitsweise des Teams leben kann.
Zusätzlich wurden diverse Wirkungsfelder aufgezeigt welche dringend bearbeitet werden sollten im näheren Umfeld des Team.

«Arbeitsweise des Teams akzeptieren und machen lassen – Schauen was dabei rumkommt.»
Die Fragen welche sich hier stellen sind; Kann und will der Scrum Master damit Leben, dass das Team keine saubere Planung will. Kann und will der Scrum Master damit Leben, das Team einfach rennen lassen, um zu sehen, was dabei rauskommt.

Einbindung grundsätzlich verbessern
Die allgemeine Einbindung der Involvierten Parteien (User, Business) ist aus Sicht des Managements stark verbesserungsfähig. Aktuell werden vor allem die internen Vertreter des Business angehört und anhand von dem das Backlog durch den PO nach eigenem Gutdünken erstellt.

Fokus mehr auf Stakeholdermanagement
Aktuell würden die Stakeholder gar nicht oder zu wenig in die Aktivitäten mit einbezogen und deren Bedürfnisse zu wenig in Betracht gezogen. Wie oben geschrieben gilt es hier einen allgemeinen Austausch direkt miteinander herzustellen und zu etablieren, damit die Prioritäten vom Business gesetzt werden. Wie kann das Business in Verantwortung genommen werden? Wie gelingt eine nachhaltige Entwicklung?

Daten sichten (z.B. Feldtests, User Erfahrung)
Anscheinend gibt es diverse Daten aus (Feld-)Tests, welche zur Verfügung stehen würden, jedoch von niemandem genutzt werden – weder von der internen Business Vertretung noch vom Team. Hier würde es v.a. darum gehen diese Daten mal grundsätzlich zu analysieren. Welche Erkenntnisse können in neue Taten umgesetzt werden?

«Den Haufen Individualisten» zu einem Team formen
Da das Team in Realität eher ein «Haufen von Individuen» ist, wäre eine weitere Möglichkeit das Gärtchen-Denken aufzubrechen und den Weg zu einem «gemeinsamen Ganzen» zu gehen. Ein Team zu bilden aus einer Gruppe mit charakterstarken Individualisten ist sicherlich eine weitere, grosse, Herausforderung. Ob dies in dieser Konstellation gelingt?

Das Team wechseln
Eine weitere Möglichkeit ist, dass ich das Team verlasse und zu einem anderen wechsle. In diesem Unternehmen hat es noch zwei weitere Teams welche einen Scrum Master brauchen könnten. Beide Teams «funktionieren» zur Zeit und sind in unterschiedlichen Kontexten unterwegs. Das eine Team ist schon länger in Scrum unterwegs und das andere etwas weniger lang da es später entstand. Beide Teams haben interessante Themen.

Quo vadis?
Als Scrum Master gilt es immer wieder Neues zu lernen und Herausgefordert zu werden, gleichzeitig auch Erfahrung auszutauschen oder weiterzugeben.
Im ersten Team gibt es «nicht allzu viel» zu tun, da es läuft innerhalb und ausserhalb. Beim zweiten Team gibt es mehr zu tun, da dort aktuell auch Strukturell Anpassungen stattfinden welche vermutlich Auswirkungen auf das Team haben werden. Im dritten Team gibt es im Umfeld einiges zu tun, nebst der Arbeit innerhalb.

Mein Entscheid fällt auf das dritte Team, auch wenn dies bedeutet das ich als Scrum Master die eigenen Ansichten zur Arbeitsweise wegschliessen muss – was eine gute Übung ist. Die Herausforderungen hier reizen mich vor allem bezüglich Stakeholder Fokus und Team bilden. Eine Frage bleibt; Kommt der Scrum Master hier nicht zu stark in den Bereich des PO? Es bleibt spannend.
In diesem Sinne; Rock ‘n roll mit dem aktuellen Team und Scrum Master Skills trainieren!

Warum Story Points sinnlos sind.

Heute könnt ihr einen Blogbeitrag lesen der von einer künstlichen Intelligenz geschrieben wurde und auch von einer KI übersetzt wurde. Ich habe ChatGPT gefragt ob es mir einen Blog zu dem besagten Thema schreiben kann. Hier seine Antwort:

Agile Methoden haben in den letzten Jahren enorm an Popularität gewonnen, wobei Scrum eines der am häufigsten verwendeten Frameworks für die agile Softwareentwicklung ist. Scrum basiert auf dem Prinzip der iterativen Entwicklung, bei der ein Team kleine, inkrementelle Änderungen an der Software in kurzen Zyklen, den sogenannten Sprints, vornimmt. Während eines Sprints verpflichtet sich das Team, eine bestimmte Anzahl von User Stories zu liefern, die mit einer Technik namens Story Points geschätzt werden. Einige Kritiker argumentieren jedoch, dass die Schätzung von Story Points in Scrum sinnlos ist. In diesem Blog werden wir die Gründe für diesen Standpunkt untersuchen.

Zunächst einmal sollten wir verstehen, was Story Points sind. Story Points sind ein Maß für den relativen Aufwand, der für die Fertigstellung einer User Story erforderlich ist. Sie werden auf der Grundlage von Faktoren wie Komplexität, Aufwand und Risiko bestimmt. Das Team schätzt die Story Points während des Sprint Planning Meetings, das zu Beginn eines jeden Sprints stattfindet.

Eines der Hauptargumente gegen die Schätzung von Story Points ist, dass sie subjektiv und fehleranfällig ist. Jedes Teammitglied kann eine andere Interpretation dessen haben, was eine bestimmte Story beinhaltet, was zu inkonsistenten Schätzungen führt. Darüber hinaus wird der Schätzungsprozess häufig durch Vorurteile und persönliche Meinungen beeinflusst, was zu Ungenauigkeiten führt.

Ein weiteres Problem mit Story Points ist, dass sie nicht den wahren Wert der Software für den Endbenutzer widerspiegeln. Der Wert der Software wird durch ihre Fähigkeit bestimmt, die Bedürfnisse der Benutzer zu erfüllen und ihre Probleme zu lösen. Story Points hingegen konzentrieren sich auf den Aufwand, der für die Implementierung einer Funktion erforderlich ist, und nicht auf ihren Wert für den Endbenutzer. Dies kann dazu führen, dass das Team viel Zeit und Mühe auf die Implementierung von Funktionen verwendet, die für den Benutzer nicht entscheidend sind.

Die Schätzung von Story Points kann auch dazu führen, dass das Team unnötig unter Druck gesetzt wird, unrealistische Verpflichtungen einzuhalten. Sobald sich das Team zu einer bestimmten Anzahl von Story Points verpflichtet hat, fühlt es sich möglicherweise gezwungen, diese zu liefern, auch wenn es dafür Kompromisse bei der Qualität eingehen oder Abkürzungen nehmen muss. Dies kann zu technischen Schulden führen, d. h. zu einer Anhäufung von suboptimalem Code und Designentscheidungen, die die Wartung und Verbesserung der Software in der Zukunft erschweren.

Schließlich können Story Points einen unnötigen Overhead im Entwicklungsprozess verursachen. Teams verbringen viel Zeit mit dem Schätzen, Verfolgen und Aktualisieren von Story Points, was Zeit und Energie kostet, die eigentlich für die Entwicklung und Bereitstellung hochwertiger Software verwendet werden sollte.

Zusammenfassend lässt sich sagen, dass Story Points zwar ihren Nutzen haben, aber nicht immer eine genaue oder effektive Methode sind, um den für die Fertigstellung einer User Story erforderlichen Aufwand abzuschätzen. Sie können subjektiv sein, zu unnötigem Druck auf das Team führen und einen Overhead im Entwicklungsprozess erzeugen. Anstatt sich auf Story-Points zu konzentrieren, sollten Scrum-Teams der Bereitstellung qualitativ hochwertiger Software, die den Anforderungen der Endbenutzer entspricht, Priorität einräumen. Indem sie sich auf den Wert der Software konzentrieren und nicht auf den für die Implementierung erforderlichen Aufwand, können Teams bessere Ergebnisse erzielen und ein besseres Produkt liefern.

Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

Die Übersetzung hat Deepl gemacht.

Als Coach bin ich mit der Antwort, wie mit der Übersetzung sehr zufrieden. Was denkt ihr?

Warum es keine Definition of Ready (DoR) braucht!

Kürzlich war ich bei einem Team und das Thema: „Wir brauchen eine Definition of Ready (DoR)!“ stand auf der Agenda. Was war das Problem? Das Team bekommt seine Backlog Items (PBI) von einem Product Owner (PO), welcher die Arbeit aus verschiedenen Quellen der Organisation sammelt und zu einem Backlog zusammenschustert.

Natürlich kann nicht jede Person aus dem Team mit den Stakeholdern die Stories ausdiskutieren. Natürlich weiss der PO auch nicht jedes Detail zu der Anforderung. Natürlich muss nun jedes Teammember den Rohdaten zur Anforderung nachschleichen und sich die Informationen zusammensuchen. Natürlich macht das so gar keinen Spass. Natürlich ist das wieder Mal sehr ineffizient. Natürlich warten wir als Team wieder einmal ewig auf die Antworten unserer Fragen. Natürlich schaffen wir die Stories auch in diesem Sprint wieder nicht. Natürlich ist der PO enttäuscht und unsere Kunden auch. Natürlich sind die Schätzungen wieder mal voll für den A****.

Es muss was passieren! Wir wollen doch ein gutes Team sein, richtig agil arbeiten und für unsere Kunden coole Produkte entwickeln!

Der Lösungsansatz ist schnell gefunden. Es gibt sogar einen Namen dafür. Wir führen die Definition of Ready ein! Für jeden Auftrag der in unserem Backlog landet muss ein Minimum an Qualität erreicht sein und ein Set von Anforderungen müssen erfüllt werden. Sonst ziehen wir die Storie einfach nicht in unseren Sprint. Alle Kunden halten sich an unsere Regeln und voilà, es läuft perfekt für uns. Ein Hoch auf die DoR!

Komisch nur, das auch danach die Situation nicht wesentlich besser wurde. Der Scrum Master (SM) hat gewissermassen eine Lebensaufgabe gefunden, allen unseren Kunden die DoR zu erklären. Alle unsere Business Analysten schreiben sich die Finger blutig auf der Suche nach den fehlenden Infos, damit die DoR erfüllt wird. Es ist klar, das auch unser Lieblingskunde wieder mal nicht checkt, das auch er sich an unsere Regeln halten muss. Nach etlichen Sprints zeigt der SM dem Team die Metriken seit der Einführung der DoR. Wir sind nicht schneller geworden. Wir schätzen nicht besser. Wir kriegen nicht mehr Arbeit im Sprint auf Done. War also alles für die Katz?

Lasst uns mal das Problem mit der Brille der Wertschöpfungskette betrachten. Von der Idee bis zur Lieferung an den Kunden sind in den meisten Organisationen mehrere Abteilungen, Teams oder Bereiche notwendig um das coole Produkt oder Service zu liefern. Jedes Element der Wertschöpfungskette wird versuchen das Beste aus dem System raus zu holen und so schnell wie möglich an das nächste Element weiter zu geben.

Immer die Besten Absichten vorausgesetzt, aber dieses Verhalten wird als Lokale Optimierung bezeichnet. Jedes Team/Abteilung optimiert aus seiner lokalen Perspektive heraus. Damit entstehen Silos oder Systemgrenzen. Mal abgesehen, das dies in vielen Fällen ein Push System ist; darüber mehr in einem anderen Blogbeitrag.

An jeder dieses Systemgrenzen brauchen wir einen formalen Übergang von einem System zum Nächsten. Jedes Team produziert für eine Definition of Done (DoD) welche für sie passt. Die DoD beinhaltet jedoch nicht die Anforderungen für das nächste Team. Das nächste Team in der Wertschöpfung wird versuchen ihre Interessen beim vorhergehenden Team durchzusetzen. Wir wünschen uns von euch, das ihr unsere DoR respektiert! Jedes Team wird versuchen die Schnittstelle zum nächsten Team zu Optimieren. Und hier liegt der Grundstein warum auch nach der Einführung der DoR der Spass und der Erfolg ausbleibt.

Würden sich die Teams auf eine wertschöpfungs-übergreifende DoD einigen. Eine DoD welche die Anforderungen von der Idee bis zur Lieferung abdeckt. Dann würde die Wertschöpfungskette nicht künstlich durch die Teamgrenzen unterbrochen. Die Arbeit würde als etwas ganzheitliches durch verschiedene Teams/Abteilungen durchfliessen. Die DoD des Team 1 berücksichtigt die Anforderungen des Team 2 bereits. So auch die DoD von Team 2 zu Team 3 und so weiter. Dies wird natürlich nicht erreicht, indem jedes Team lange über „seine“ DoD nachgrübelt und sich dann stark macht das nur „unsere DoD“ was taugt. Diese, wertschöpfungsübergreifende DoD wird in moderierten Meetings unter den Teams ausgehandelt und entwickelt. Wir sind nun an der globalen Optimierung des Wertstroms angelangt.

Also; wenn es der Organisation gelingt, gute Interaktionen zwischen den Teams zu gestalten, eine DoD entwickelt, welche das Produkt den ganzen Wertstrom entlang begleitet, dann reicht eine DoD völlig aus. Es braucht keine DoR.

Ein Hinweis an die Coaches da draussen… wenn ich ein neues Mandat annehme suche ich die Teams welche eine DoR haben oder einführen wollen. Dann weiss ich schon sehr zuverlässig wie es mit der Wertschöpfungskette und der Kooperation zwischen den Teams steht. 😉

Kooperation vs. Kollaboration – Koordination Schulanlässe leicht gemacht

Oft habe ich es in der Vergangenheit erlebt, dass Organisationen, Führungspersonen und Arbeitnehmende den Blick auf die Resultate richten und vergessen dem Weg dahin Beachtung zu schenken. Es wurde vergessen in die Gruppe zu horchen und sich mit den Geschehnissen auseinander zu setzen. Gründe dafür gibt es viele. Die ach so oft gehörten und von viel zu vielen Menschen genutzten Ausreden warten nur darauf ein weiteres Mal genutzt zu werden. „Zu wenig Zeit“ oder „zu viel zu tun“ waren nur zwei der Ausreden, welche mir begegnet sind.

Den Weg betrachten würde beispielsweise heissen sich mit Working Agreements und den gegenseitigen Erwartungen auseinander zu setzen. Der Begriff der Kooperation drängt sich da in den Vordergrund.

Beim Erforschen von Kooperation bin ich über viele identische Ansätze gestossen. Besonders interessant war für mich die Differenzierung von Kooperation und Kollaboration, welche mir besonders im Zusammenhang mit Working Agreements und den gegenseitigen Erwartungen wichtig erscheint.

Nehmen wir uns doch in der ganz normalen Alltagshektik kurz Zeit einen Blick auf Kooperation und Kollaboration zu werfen.

Kooperation vs. Kollaboration

Kooperation und Kollaboration sind zwei grundverschiedene Arten und Weisen miteinander zu kooperieren. Betrachtet man die Kollaboration, dann steht der Mensch im Vordergrund. Besondere Beachtung finden hier zwei Aspekte. Der Mensch besitzt die Fähigkeit Vertrauen zu schenken und er ist auf andere Menschen angewiesen. Somit ist der Mensch Selbstzweck.

Beleuchtet man die Kooperation, dann steht die Sache im Vordergrund. In diesem Zusammenhang wird die Notwendigkeit Arbeit aufzuteilen bearbeitet.

Wenn die Theorie der Praxis begegnet

Meine Arbeit mit EduKanban beinhaltet weit mehr als ausschliesslich Kanban beispielsweise in Schulen, Verwaltungen und sozialen Institutionen einzuführen. Es geht nicht ausschliesslich um eine agile Methode, die auch noch in diesem Bereich umgesetzt werden muss. Es geht um den Mehrwert, um all die Türen, welche durch die Methode geöffnet werden können… und die damit verbundene Auseinandersetzung. An der Primarschule „Kleinbach“ haben wir mit EduKanban auf die Schulentwicklung geschaut und uns zu Kooperation und Kollaboration Gedanken gemacht.

EduKanban in der Schulentwicklung

Die Primarschule «Kleinbach» hat das Jahresmotto «ich + du = wir». Die Schulleitung hat zusammen mit der Steuergruppe «Schulentwicklung» die Wertschöpfungskette für Schulanlässe definiert. Auf dem Board haben wir der aktuelle Stand der Anlässe visualisiert. Die Verantwortlichkeiten der einzelnen Spalten wurden im Kollegium festgelegt, wie auch die Inhalte. Die WIP-Limite eins hat die Steuergruppe definiert, um das System nicht zu überlasten. Das heisst, die Steuergruppe der Schule hat sich dafür entschieden, dass pro Aktivität maximal eine Arbeitseinheit zugelassen wird.

Kanban-Board „Schulanlässe“ vorderer Teil

Kanban-Board „Schulanlässe“ hinterer Teil

Gedanken zur „Schulentwicklung“

Die Differenzierung von Kooperation und Kollaboration half bei der Erstellung der Working Agreements. Es wurde ein Bewusstsein geschaffen, welche Ebene der Zusammenarbeit angesprochen wird. Gerne teile ich meine Gedanken an dieser Stelle.

Kooperation findet da statt, wo die einzelnen Teams einer Spalte der Wertschöpfungskette mit einem Team einer vorangestellten oder nachfolgenden Spalte der gleichen Wertschöpfungskette zusammenarbeiten. Im Beispiel «Schulanlässe» würde das bedeuten, dass die Steuergruppe Schulentwicklung mit der Arbeitsgruppe Schulanlässe zusammenarbeitet und die Arbeit über den Commitment Point an Projekten weiterführt. Kooperation kann ebenfalls mit einem externen Anbieter stattfinden, welcher für ein Team einer Spalte Aufträge als Sub-Unternehmer übernimmt. Beim Schulfest könnte das die Stadtmusik sein, welche beispielsweise für den musikalischen Rahmen besorgt ist.

Kollaboration findet innerhalb der einzelnen Teams einer Spalte statt, das heisst beispielsweise in der Arbeitsgruppe Schulentwicklung. Kollaboration kann auch zwischen den Teams unterschiedlicher Spalten stattfinden, wenn die Teammitglieder sich auf Grund des vorhandenen Wissens, der Fähigkeiten und Fertigkeiten aushelfen und unterstützen können. Das könnte hier eine Person aus der Steuergruppe Schulentwicklung sein, welche die Arbeitsgruppe Schulanlässe temporär unterstützt.

Engpässen gemeinsam meistern

Temporäres Unterstützen kann dem einen oder anderen Menschen in der Organisation den Tag retten. Es geht nicht darum den Kopf ein zu ziehen, wenn irgendwo ein Engpass in Sicht ist. Teammitglieder dürfen für die Behebung eines Engpasses beigezogen werden. Nehmen wir das Beispiel Klassenlager, hier befinden wir uns im Bereich der Kollaboration, wenn man gemeinsam Engpässe meistert. Bei einem Klassenlager bearbeiten einzelne Teammitglieder alle Spalten eines Auftrages einer Wertschöpfungskette.

Im Daily Standup Meeting und dem anschliessenden After Meeting wird der Engpass thematisiert. Dies könnte im Falle des Klassenlagers die Unterstützung bei der Suche nach einem Lagerhaus durch ein Teammitglied bedeuten. Ebenfalls könnten in der Retrospektive Erkenntnisse für die Zukunft gewonnen werden.

Personen oder Gruppen arbeiten an unterschiedlichen Inkrementen des Produktes in der Wertschöpfungskette. Sie sind entsprechend nicht an der Entstehung aller Teile des Produktes beteiligt. Unter Berücksichtigung aller Gestaltungsebenen von Kanban kann ein Inkrement somit als Teil einer Wertschöpfungskette oder als individuelle Wertschöpfungskette produziert werden.

Der Mehrwert für die Schule „Kleinbach“

Ich musste etwas schmunzeln, als in der Schule „Kleinbach“ der Vorschlag eines Daily Standup Meetings auf Widerstand stiess. Der Grund für mein Schmunzeln war, dass dieses Daily Standup Meeting bereits stattfand. Am Morgen haben sich nämlich die an der Schule tätigen Personen im Lehrerzimmer pünktlich um 7:45Uhr zu einem Kaffee getroffen und sich ausgetauscht. Leider wurde das Schwarmwissen noch zu wenig genutzt. Lehrpersonen empfanden es sogar als unangenehm, wenn sie rumfragen mussten um für eine Herausforderung eine Person zu finden, welche ihnen helfen konnte. Nachdem der Einführung von Daily Standup Meetings trafen sich sogar noch mehr Menschen im Lehrerzimmer.

Fettnäpfchen bitte nicht selber kreieren!

Wer nun denkt, dass immer jede an der Schule tätige Person an allem teilnehmen musste, der irrt sich gewaltig. Das wäre ein selber produziertes Fettnäpfchen. Die Umsetzung sollte durchdacht sein, damit es nicht zur Belastungsprobe wird. Ansonsten könnte es gut sein, dass eine ganze Schule in den kollektiven Widerstand geht.

Koordination Schulanlasse leicht gemacht

Ein wichtiges Instrument für die Koordination in Schulen ist EduKanban. Es hilft schnell einen Überblick zu haben, Engpässe zu erkennen und ist vielseitig einsetzbar. Die Zusammenarbeit wird beleuchtet und das System erfährt Entlastung. Stop starting, start finishing!

Walk – Talk – Write

Oder auf deutsch: Gehen – Reden – Schreiben eine schöne Retrospektiven Methode bei sommerlichem Wetter.

Anleitung:

Bilde ein Team mit einem Teammitglied, das du noch nicht so gut kennst.

Stellen einen Wecker auf 10 bis 15 Minuten.

Geht wohin ihr wollen, während ihr über euer Team diskutiert (ja, ihr können auch im Freien unterwegs sein, oder zum Glace Stand, oder…. ).

Wenn der Wecker klingelt, schreibt auf Post-it oder Notitzpapier oder Flipchartpapier welche Veränderung im Team für euch am wichtigsten ist, und geht zurück zur Basis.

Präsentiert und diskutiert die Plakate oder Post-It’s.

Die Gesprächspartner sitzen bei der Präsentation zusammen, damit jeder sehen kann wer mit wem die Themen eingebracht hat.

Beobachtungen:
Dadurch, dass man Paaren rausschickt, hatte jeder viel mehr Zeit zum Sprechen, als wenn die ganze Gruppe zusammen wäre.

Die Bildung von Paaren, die aus Personen bestanden, die normalerweise nicht viel miteinander reden, erhöhte die psychologische Sicherheit, da die Teammitglieder, die in Konflikte verwickelt waren, nicht gepaart wurden.

Falls Regeln gewünscht werden:

  • Bewegung übertrumpft Sitzen
  • Sprechen übertrumpft Zuhören
  • Schreiben übertrumpft Lesen
  • kürzer übertrumpft länger

Wie immer… ich würde mich über Feedback freuen wenn jemand diese Retro ausprobiert hat und erfahren ob und was die Methode gebracht hat.

Agile Methoden sind Blödsinn!

Viele Leute, mit denen ich zu tun habe, sind frustriert, enttäuscht oder abgeneigt gegenüber Agilität. Ihre Firmen führen Agilität ein über Scrum oder Kanban oder LeSS oder SaFe – und wie sie alle heissen. Den Mitarbeitern werden diese Ansätze als agile Methode vorgestellt, welche bestimmte Strukturen (Meetings, Rollen, Abläufe) mit sich bringt. An diesen Strukturen halten sich Mitarbeiter nur zu gern fest. Das ist menschlich. Denn etwas Neues bedeutet Veränderung – logisch. Und wir Menschen suchen immer wieder Orientierung, um uns sicher zu fühlen, uns zu stabilisieren. Nur orientieren sich die meisten, welche agil werden wollen, am Falschen: an (scheinbar) starren Strukturen vermeintlicher Methoden zur Agilität. Ich höre dann Aussagen wie: „Agilität ist Blödsinn!“ oder „Agilität funktioniert bei uns nicht“. Und ja, agile Methoden sind Blödsinn!

Doch die oben genannten agilen Ansätze sind keine Methoden. Sie sind kein planmässiges und folgerichtiges Verfahren. Es sind Rahmenwerke. Die Strukturen, welche diese anbieten, dürfen nicht als die absolute Wahrheit oder eben „one-size-fits-all“-Lösung verstanden werden. Ich sehe in ihnen mehr eine gute Praxis, eine erste Anregung. In der Theorie machen die dargebotenen Strukturen total Sinn…doch sie sind in einem kontextlosen Raum. In der Realität treffen sie immer auf einen bestimmten Kontext…und machen mehr oder weniger Sinn – meist weniger. Dann sind sie Blödsinn.

Agilität ist eben nicht Strukturen, sondern Prinzipien. Alle agilen Rahmenwerke bauen auf bestimmten Prinzipen* auf. Und diese übersehen die meisten leider bzw. sie übergehen sie schnell.

Für mich sind neue Strukturen, also organisationelle Veränderung, nicht Agilität, sondern eine inherente Folge davon. Nicht die Agilität gestalten die Organisation neu, sondern die Mitarbeiter aufbauend auf agilen Prinzipien. Und ja, richtig gelesen. Mitarbeiter (!!!) sollen zusammen gestalten, wie sie sich organisieren. Und zwar alle Mitarbeiter einer Organisation (Führung miteingeschlossen) im Dialog. Das verstehe ich unter den im Zusammenhang mit Agilität oft benutzten Schlagwörtern „Selbstorganisation“ und „Ko-Kreation“.

Agilität ist keine fertig gebackene Lösung, geschweige denn ein Rezept. Agilität ist ein Kompass. Der Kompass zeigt auf Prinzipien, an denen sich die Mitarbeiter orientieren sollen, um so die beste Lösung in ihrem Kontext gemeinsam und kontinuierlich zu gestalten.

* Das agile Manifest, Scrum Säulen & Werte (S.4), Kanban Prinzipien, LeSS Prinzipien

Die Reise in neue Gruppen

Fast alle Formen institutionalisieren Lernens in meinem Leben finden in Gruppen statt. Dies begann schon früh mit dem Eintritt in den Kindergarten, später dann in der Schule und heute im Berufsalltag. Die Prägung unseres Verhaltens in Gruppen findet allerdings bereits im Familiensystem, der Familiengruppe, statt. Ich habe in Gruppen beispielsweise gelernt, wie ich argumentiere, mich durchsetze und wann ich mich zurücknehme.

Ich – das Individuum in der Gruppe

Oft war das Zusammenkommen in Gruppen mit dem Erlernen von Lerninhalten verbunden. Die Gruppe hatte ein konkretes Ziel, welches bearbeitet werden musste. Ich als Individuum habe mich zur Unterstützung der Ziele in meinem Verhalten an den Normen der Gruppe orientiert und mich entsprechend versucht zu verhalten. Selbstverständlich kam es in Gruppen auch immer wieder zu Reibungen, diesen wurde von der Gruppe allerdings teilweise nicht nachgegangen, da das Ziel im Fokus stand. Ich möchte nicht behaupten, dass ich in diesen Gruppen immer angepasst war oder den Bedürfnissen der einzelnen Individuen Raum gelassen habe. Ich denke, das kennt jeder, dass man manchmal auch etwas ungehobelt unterwegs ist. Natürlich alles zu Gunsten des Ziels. Doch ist es tatsächlich zu Gunsten des Ziels?

Die Reise in eine neue Gruppe

Letzte Woche durfte ich in nach Deutschland reisen um eine persönliche Lernerfahrung mit Gruppen zu machen. Bereits letztes Jahr habe ich mich für ein Sensivity Training, ein gruppendynamisches Training, angemeldet. In meinem Beitrag „Was hat Gruppendynamik mit Kanban zutun?“ schildere ich meine Eindrücke des ersten Trainings, welches nun schon einige Jahre zurück liegt. Aus diesem ersten Training habe ich viele Erkenntnisse mitgenommen und war nun bereit diese erneut zu reflektieren und meinen persönlichen Lernpfad zu beleuchten.

Theorie und Praxis

In der Theorie kann man nachlesen, wie ein Sensivity Training abläuft und wie die Erweiterung sozialer Kompetenz durch verhaltensorientierte Trainings funktionieren. Doch selbst mit dem Wissen um die Struktur ist jede Gruppe anders und unterschiedliche persönliche Verhaltensmuster kommen an den Tag. Grund dafür ist, dass die eigene Person, das eigene Verhalten und die Wirkung auf die anderen Teilnehmenden im Vordergrund stehen und ganz in den Fokus der Aufmerksamkeit gerückt werden. Das kognitive Wissen über mein soziales Verhalten alleine führt nicht unbedingt Veränderungen herbei und so ist das soziale Erleben, Erfahren und Erproben wichtig.

Die Gruppe und ich

Ich bin unendlich dankbar für diese erneute Erfahrung in meiner Trainingsgruppe, im Plenum und der Unterstützergruppe. Hier ein grosses Dankeschön an alle, welche mit mir die Woche erlebt haben. Die Gruppe gab mir die Möglichkeit neue Wege zu gehen und neues Verhalten auszuprobieren und mich meinen herkömmlichen Mustern zu stellen. Eine Gruppe Menschen, welche sich teilweise noch nie zuvor gesehen haben, bildet den Resonanzraum. Diese Menschen haben mir mein eigenes Verhalten gespiegelt.

Geschenk meiner Gruppe an mich

Die Gruppe gab mir die Möglichkeit meine Selbst- und Fremdwahrnehmung zu verbessern, emotionale Stabilität und Belastbarkeit weiter zu entwickeln, spontan zu sein, eine adäquate Ausdrucksweise zu schulen und mich in verschiedenen Rollen zu bewegen. Ich habe die Möglichkeit erhalten mich auszuprobieren und in einem ungefährlichen Rahmen, Verhaltensänderungen und ihre Wirkung zu erfahren.

und jetzt?

Nach einer Woche führt mich mein Weg zurück in die Schweiz. Ich bin sehr dankbar dafür diese Menschen kennengelernt zu haben, auch wenn mich der Eine oder Andere ganz schön herausgefordert hat. Diese intensive Woche hat mir den Mut gegeben mich in Gruppen auszuprobieren und mich bewusster einzubringen.

Wie beim ersten Training hat sich mein gruppendynamischer Blick wieder geschärft. Zur Entlastung meines Umfeldes waren die Auswirkungen nicht mehr so umfassend und anstrengend, wie nach meinem ersten Training. So hat mein privates und berufliches Umfeld keine schonungslose Überdosis an gruppendynamischer Analyse erfahren. Ich bin jetzt viel mehr bei mir, im Hier und Jetzt. Das hat Auswirkungen auf das Umfeld und die Gruppen, in welchen ich mich bewege.

Ist Agilität eine Religion oder ein Geschäft?

Ein Blogbeitrag von Howard Sublett
CEO I Leader | Keynote Speaker | Connector | Agilist I Board Member

Vielen Dank Howard das ich deinen Linkedin-Beitrag hier in deutscher Sprache publizieren darf!


Petit Jean Mountain - Photo by me.

Ist Agilität eine Religion oder ein Geschäft?

Kürzlich war ich als Berater bei einem Kundengespräch dabei und wir diskutierten über Produktangebote für die Welt, als mir einer der Führungskräfte die Frage stellte: „Ist Agilität eher eine Religion oder ist es ein Geschäft?“ Daraus entwickelte sich eine interessante Diskussion, und ich dachte, ich würde ein wenig von dem, was diskutiert wurde, mit Ihnen teilen, vor allem, wenn Sie jemanden einstellen wollen, der Ihnen bei Ihrer agilen Transformation hilft – oder wenn Sie in ein agiles Unternehmen einsteigen wollen. Die große Kündigung hat zur Folge, dass allein im November 2021 4,5 Millionen Menschen in den USA ihren Job kündigen.

Dies ist wirklich eine Zeit des Wandels.

Ich bin kein Religionswissenschaftler, also habe ich ein wenig gegraben, um eine Definition zu finden, und bei allem, was ich gefunden habe, scheint es, dass die Gelehrten selbst sich nicht einig sind. (siehe Referenz) Es gibt einige Elemente in den unzähligen Definitionen von Religion, die sehr danach klingen, wie viele sich der Agilität nähern. Formulierungen wie „System von Überzeugungen und Praktiken“ oder „umfassende Weltanschauung“ scheinen gut zusammenzupassen, während andere das nicht tun (die „Anbetung einer übermenschlichen, kontrollierenden Macht“ wäre ein Beispiel).

Aber ich betrachte mich als Student der agilen Bewegung, und für mich ist sie genau das – eine Bewegung.

Dictionary.com hat diese Definition für Movement:

No alt text provided for this image
Dictionary.com hat diese Definition für Movement:

Nun kann man darüber streiten, ob alle Agilisten eine „gemeinsame Ideologie“ haben, aber ich denke, man kann sehen, wie dies zutreffen könnte. Und die Leidenschaft, die viele Menschen in der Bewegung haben, lässt uns für manche wie eine Religion erscheinen. Das gilt vor allem für diejenigen, die das „Glück der Mitarbeiter“ als wichtigstes Ziel ansehen. Ich glaube zwar, dass agile Teams mehr Freude an ihrer Arbeit haben, aber das ist ein Nebenprodukt des Interesses daran, wie die Arbeit erledigt wird, und der Verbindung zum Kunden. Glück ist ein Ergebnis der teambasierten Arbeit, sollte aber ohne den Lieferaspekt, den wir mit der agilen Arbeitsweise erreichen, nicht im Mittelpunkt stehen.

Nun zum Geschäftlichen. Wow, das ist ein Geschäft geworden. Man sieht das jeden Tag auf Websites und in Marketingunterlagen von Unternehmen, Beratungsfirmen und anderen. Die Leute verkaufen „Agile“ und formelhafte Ansätze – vor allem solche, die für die Verkäufer finanziell vorteilhaft sind. Und die Organisationen dieser Welt kaufen. Viele derjenigen, die am aktivsten im Verkauf von „Agile“ sind, können die versiertesten, geschäftsorientiertesten Menschen sein, aber auch die am wenigsten auf die agile Bewegung ausgerichteten. Große Vertriebsorganisationen sind in der Lage, die Bedürfnisse von Unternehmen mit ihrem Angebot zu verbinden. Sie entwickeln Verkaufslösungen für die sich bietenden Gelegenheiten, und diese Abkehr von der traditionellen Arbeitsweise hat eine Fülle von Möglichkeiten geschaffen. Wenn sie einen Hammer haben, helfen sie Ihnen zu erkennen, dass Sie der Nagel sind.

Wie lautet also die Antwort?

Ich stelle fest, dass viele der Unternehmen, die „Agile*“ am besten verkaufen können, vielleicht die am wenigsten agilen Unternehmen sind. Und viele der agilsten Menschen sind wahrscheinlich mit am wenigsten gerüstet, um das, was sie wissen, kraftvoll zu verkaufen.

Howard Sublett

Ja, die agile Bewegung hat Züge einer religiösen Bewegung, aber sie ist keine Religion. Und ja, es ist ein Geschäft, denn die Menschen kaufen Angebote, die Einzelpersonen und Organisationen helfen sollen, agiler zu werden, aber diejenigen, die sich darauf als Geschäft konzentrieren, sind wahrscheinlich selbst nicht sehr agil. Ich bin sicher, dass es hier Ausreißer gibt, und dies sind nur grobe Umrisse, aber es ist ein Muster, das ich immer wieder sehe.

Was ist also zu tun?

Bevor Sie sich entscheiden, wen Sie einstellen oder für wen Sie arbeiten wollen, machen Sie Ihre Hausaufgaben.

Achten Sie auf Champagner.
Ein Unternehmen sollte die Werte vorleben, die es Ihnen vermitteln will, es sollte seinen eigenen Champagner trinken. Dazu gehören die Führungsebene, die Personalpolitik, das Marketing und vieles mehr. Stellen Sie Fragen und verlangen Sie Einsicht in die Mission/Vision/Werte und in die Führungsdokumente. Sprechen Sie mit den Mitarbeitern und sehen Sie sich an, wie die Arbeit iterativ und inkrementell erledigt wird. Fragen Sie auch die Mitarbeiter, wie sie als aktive Mitwirkende bei der Entwicklung von Lösungen für ihre Kunden geschätzt werden.

Lesen Sie, was sie schreiben.
Lesen Sie, was sie zur agilen Bewegung beigetragen haben und nicht nur Werbung für ihre spezielle Lösung machen. Tragen sie zum kollektiven Wohl der Bewegung bei oder sind sie spalterisch. Dies gilt auch für die Führungskräfte des Unternehmens und die Art und Weise, wie sie auf agilen Veranstaltungen auftreten, in den sozialen Medien und auf Blogseiten schreiben. Einige verbringen einen Großteil ihrer Energie damit, anderen zu sagen, dass sie im Unrecht sind, um sich selbst besser dastehen zu lassen – ich würde sie meiden.

Gemeinsam entdecken.
Seien Sie vorsichtig, was die Bereitschaft und die Fähigkeit der Menschen angeht, zu helfen, wenn sie bereits eine Lösung anbieten können. Agilität ist keine Einheitsgröße, und jedes Unternehmen befindet sich in einem anderen Zustand. Führen Sie ehrliche und offene Gespräche darüber, wo Sie als Unternehmen stehen und welche Ziele Sie zu erreichen hoffen. Ein Unternehmen, das agile Beratung anbietet, sollte auf jeden Fall einen iterativen und schrittweisen Ansatz verfolgen und darauf bestehen, diese Reise mit jedem Kunden gemeinsam zu gestalten. Wenn Sie für ein Unternehmen arbeiten, das agile Beratung anbietet, sollten Sie nicht in die Falle tappen, dass Sie eine dreistufige Lösung für jedes Kundenproblem oder ein perfektes Rahmenwerk unterschreiben – das wird wahrscheinlich nie funktionieren,

Organisatorische Veränderungen sind schwierig, kostspielig und haben keine Erfolgsgarantie. Sie sollten Ihre Sorgfaltspflicht erfüllen.

Howard Sublett

Das Geschäft mit der Agilität boomt. Menschen und Organisationen erkennen die Notwendigkeit, besser auf Kundenbedürfnisse reagieren zu können und zu reagieren, wenn sich die Dinge ändern. Sie müssen sich nicht zwischen Religion und Geschäft entscheiden. Stellen Sie nur sicher, dass diejenigen, mit denen Sie Geschäfte machen, nicht nur „Agile*“ verkaufen, sondern die agilen Prinzipien und Werte auch leben.

  • – Ich verwende hier absichtlich den Begriff „Agile“ – Agile mit großem „A“. Das Wort „agil“ ist kein Substantiv. Man kann „Agile“ nicht kaufen. Und doch verkaufen es so viele Unternehmen und Berater auf diese Weise. Agil ist ein Adjektiv oder ein Adverb, und es kann verwendet werden, um etwas anderes zu beschreiben. Einen agilen Prozess oder eine agile Denkweise.

Das Original ist auf Linkedin zu finden.

Utiliser les connaissances du système familial pour l’organisation

Chaque jour, nous réussissons la vie quotidienne en famille. Le rire, le plaisir et de passer du temps ensemble constituent notre fondement. Nous nous soutenons et nous nous aidons dans les situations difficiles. Bien sûr, nous avons aussi nos problèmes, mais qui n’en a pas… Nous n’avons pas toujours eu ce genre d’interaction.

Il faut plus qu’un marteau!

En tant que pédagogue diplômée avec de nombreuses années d’expérience, je possède de nombreux outils d’un point de vue professionnel. Ils sont et ont toujours été à ma disposition dans mon quotidien avec mes enfants. En étant pédagogue, la gestion de la famille n’est pas un problème, disent beaucoup de gens. Je ne suis pas d’accord. Ce n’est pas parce qu’on possède un marteau qu’on peut l’utiliser. Il faut plus que les outils pour pouvoir obtenir un effet optimal.

Ces dernières années, j’ai de plus en plus changé de métier tout en restant la même. Aujourd’hui, je travaille comme formateur, coach, superviseur et développeuse organisationnelle. Tout au long de mon chemin, j’ai toujours soutenu un individu, une équipe, un groupe et/ou une organisation dans le changement.  La confrontation avec les réalités actuelles a été un élément important.

La curiosité aide à introdruire

Dans mon système familial, j’ai essayé plusieurs choses. C’est intéressant de voir comment un groupe ou des enfants réagissent au changement. Et pourtant, ce sont mes enfants qui ont initié le plus grand changement. Comme j’étais de plus en plus plongée dans le monde agile, j’ai commencé à travaille avec un Kanbanboard. Mes deux filles ont observé avec curiosité et ont décidé d’utiliser elles aussi un tableau.

Je renonce à parler ici de la méthode Kanban de manière différenciée. J’aimerais plutôt parler de mes conclusions pour l’organisation.

„Daily“, „l’île“ et „La bourse d’échange“

Commencer le „daily“ par une interaction centrée sur le thème. Ce regard aide à établir la compréhension de chacun. Les domaines suivants sont abordés.

– MOI: Comment je me sens aujourd’hui? / Qu’est-ce qui me préoccupe?

– ENVIRONNEMENT : Que fais-je actuellement?

– NOUS: Comment je me sens dans le groupe / l’équipe?

– SUJET: Comment est-ce que je me sens par rapport au thème?

„L’île“ est une option qui peut être partiellement intégrée. Avec „l’île“, nous réalisons toujours une interaction centrée sur un thème. Nous posons la question „Que se passe-t-il en ce moment ?“ et envisageons „l’échange“.

Dans la „bourse d’échange“, nous thématisons si et sous quelle forme „l’échange social“ a eu lieu et s’il y a encore des „factures impayées“.

Regard supplémentaire souhaité

Ce regard supplémentaire sur le groupe n’apporte pas seulement des changements structurels. Un sentiment d’appartenance à l’autre se développe de plus en plus. Les différences peuvent être de plus en plus utilisées pour le processus de travail. L’individualité est de plus en plus vue comme une ressource. Les souhaits personnels, les intérêts, les espoirs, les possibilités, les forces et les faiblesses peuvent être apportés et sont pris en compte.

Les enfants sont très ouverts à un tableau Kanban. Ils aiment les règles, les „dailys“ et la possibilité de participer. Planifier consciemment des choses formidables et organiser sa vie de manière beaucoup plus consciente leur procure une grande joie. C’est précisément cette légèreté et ce sentiment d’appartenance qui peuvent être encouragés par ces petites adaptations.

Je trouve cette forme d’échange énormément enrichissante dans les organisations et dans mon système familial.

Kennst du den Unterschied zwischen einem Superbowl und einem Pro Bowl Team?

Ich finde American Football schon viele Jahre sehr spannend. Zuerst schaute ich nur auf den Sport. Später, als Coach, habe ich gesehen wie diese Teams Coaching Techniken und Methoden anwenden um High Perfomance Teams aufzubauen. Darum habe ich mich plötzlich für die Coaches aus der National Football Leage (NFL) angefangen zu interessieren.

Im American Football gibt es ein Grossereigniss welches vermtlich global bekannt ist. Der Superbowl. Das Finale der Saison. Die zwei besten Teams treffen aufeinander und spielen um den Meistertitel.

Es gibt aber auch ein anderes Finale. Der Pro Bowl. Diesen Event kennt hingegen kaum jemand. Dieses Spiel findet meistens in der Woche vor dem Super Bowl statt. Dabei werden aus allen Teams, welche nicht am Finale teilnehmen können, die besten Spieler ausgesucht und eingeladen. Die Besten der Besten treffen sich zum Saisonfinale und spielen gegeneinander. Mir ist aufgefallen, das die zwei Spiele sehr unterschiedliche Dynamiken aufweisen.

Beim Superbowl ist es klar. Da geht es um etwas Grosses. Wer gewinnt ist Meister und es winkt Ruhm, Reichtum und Ehre. Beim Pro Bowl ist es eher eine Ehre ausgewählt geworden zu sein, aber so richtig Risiko und vollen Einsatz gibt man sich da nach einer langen Saison auch nicht mehr.

Wenn man sich aber die zwei Spiele unter dem Aspekt eines Coaches anschaut kann man sehr spannende Team-Muster erkennen.

Die Zusammenfassung des Superbowls 2021
Die Zusammenfassung des Pro Bowls 2021
Vergleich Pro- vs Super Bowl

Ein Top Team ist nicht das Gleiche wie ein Team von Top Leuten!

Im Superbowl sieht man sehr gut wie ein eingespieltes Team funktioniert. Die einzelnen Spieler kennen sich untereinander. Sie vertrauen sich. Sie agieren in komplizierten Spielzügen sehr harmonisch untereinander. Je nach Spielsituation und Spielzug ist sichtbar, das ein Spieler eine Handlung ausführt die für den Gegner überraschend kommt, aber für die Team Members vorhersehbar war und ausgenutzt wird um einen Punkt zu machen.

Beim Pro Bowl sieht das Team-Zusammenspiel etwas anders aus. Viele Spielzüge funktionieren nicht. Der Spieler denkt, das machen wir jetzt so und da wo der andere Teamkollege sein sollte ist dann niemand. Was wiederum zu vermehrten Einzelaktionen und „Heldentum“ führt. Die Spieler respektieren einander. Sie sind Profis. Sie kennen jeden, noch so kleinen Trick des anderen Spielers. Trotzdem kommen sie leistgungsmässig nicht Ansatzweise an die Performance eines Super Bowl Teams heran. (Und die LA Rams und die Cincinnati Bangles gehören nicht zu den vermeindlichen Top Team der Ligen. Und, ein Fun Fact: es waren die jüngsten Head Coaches der Liga welche gegeneinander im Finale standen.)

Ich finde es sehr spannend diese zwei Ereignisse mal aus der Perspektive eines Coaches zu schauen. Selbst wenn du die Spielregeln nicht kennst. Schaue die mal die Teammuster und die Kooperations- und Kommunikations-Muster an. Dsa sin sehr grosse Untershiede zu sehen.

Es gibt auch eine Andere Perspektive beim Football. Die Perspektive der Skalierung. Es sind in jedem Team mehrere Coaches aktive und es sind mehrere Teams welche zusammen die ganzen Mannschaft bilden, aber das wird dann der nächste Blogbeitrag. 😉