Autor: Ruedi

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?

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. 😉

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.

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!

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:

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.

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

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. 😉

Letztes Jahr war ich an verschiedenen Workshops oder Trainings als Scrum Master Coach engagiert. Das Ziel war es Scrum Master bei ihrer Arbeit zu begleiten und ihre Potentiale zu entwickeln und Verhaltensmuster zu ändern welche in dieser Rolle nicht hilfreich sind. Dabei ist es ein einige Mal passiert, das der Scrum Master am Ende des Events keine Idee oder Ressourcen mehr hatte um eine gute Retrospektive mit dem Team zu gestalten. Dann musste ich als Coach etwas unerwartet und unvorbereitet einspringen und mit dem Team einen Tagesabschluss gestalten.

Am ersten dieser Events war die Lage so, das sich mehrere Teams zu einem Releaseplanning zusammengefunden hatten. Der Tag war sehr intensive, die Teilnehmenden schon ziemlich müde. Und jetzt noch eine Retro? Also, eine Retromethode muss her: leichtgewichtig, schnell erklärt und sie sollte die Menschen auch wieder etwas energetisieren, nicht noch mehr auslaugen. Anderterseits brauchten wir unbedingt Input was wir zu den nächsten Events verbessern sollen. Es war auch so das sich im Raum mehrere Wortführer herauskristalisiert hatten. Wenn die ein Thema gewählt haben, dann haben sich die anderen Teammitglieder selten mit ihren eigenen Ideen gemeldet.

Mir ist die Think-Pair-Share Methode aus den Innovations Workshops in den Sinn gekommen. Da kann man sehr gut die Ideen im Raum herausfinden, konzentrieren und an die Gruppe kommunizieren. Sie ist einfach, schnell und liefert gute Resultate. Warum also nicht einmal als Retrospektive ausprobieren?

Die Einstimmung habe ich so moderiert das ich ihnen versprochen habe das wir in maximal 30 Minuten eine gute Retro geliefert haben. Dann die Timeboxen gesetzt.

1. Schritt: Think
   Alle Teilnehmenden haben ein Notizzettel und einen Stift. Die Timebox wird auf 2 oder 3 Minuten gesetzt. Die Frage lautet:
   Was würdet ihr euch selber empfehlen damit das nächste Meeting mehr Spass macht und der Tag ein voller Erfolg ist?
   Jede Idee, Anregung auf einen Zettel.
   Jede Person für sich alleine
2. Schritt: Pair
   Alle suchen sich eine Person mit welcher sie nun für maximal 4 Minuten austauschen welche Ideen, Vorschläge oder Kritikpunkte für sie wichtig sind. Dieses Paar entscheidet sich für 2-3 Zettel, welche sie auch den anderen am Workshop erzählen möchten.
3. Schritt: Share
   Jedes Paar hat nun maximal 5 Minuten den anderen ihre Empfehlungen zur Verbesserung vorzustellen. Es sollten keine Diskussionen gestartet werden. Klärungsfragen sind OK. Der Scrum Master oder ich als Coach notieren die Themen und die Empfehlungen. Die ersten Paare erklären meistens etwas besser, gegen Ende der Sequenz ist dann meistens schon fast alles gesagt und es kommen nur noch Dinge die vorher nicht erwähnt wurden.

Auf diese Art haben wir in einigen Workshops auf eine sehr leichtgewichtige Art und Weise gutes Feedback erhalten konnten die darauffolgenden Events viel besser gestalten.

Ich habe auch angefangen das sich die Paare jeweils entscheiden dürfen ob sie jemanden für irgendwas an diesem Tag bedanken möchten. Die Erfahrung war dahingehend das sehr viele Kudos (Lobungen) an verschiedene Teammitglieder ausgesprochen wurden und dadurch auch erstaunliche Leistungen zum Vorschein gekommen sind, welche von Menschen erbracht wurden die eventuell etwas weniger prominent in der Gruppe kommunizieren.

Ich habe mit dieser sehr einfachen Retro im 2021 sehr gute Erfahrungen gemacht und werde die auch in den kommenden Jahren sicher noch mehr einsetzen.

Happy New Year 2022