Im Sommer haben wir Urlaub in Schweden gemacht. Was in den ersten Tagen beim Fahren sofort klar wurde war, dass in Schweden Dinge gehen, die in Deutschland angeblich nicht möglich sind.
Wie kann das sein? Wollen die Schweden ihre Teslas nicht ausfahren? Sind sie keine geborenen Rennfahrer?
Die maximal erlaubte Höchstgeschwindigkeit kann innerorts je Beschaffenheit der Straße zwischen 30 km/h und 70 km/h liegen. Beachten Sie die Beschilderung.
Die maximal erlaubte Höchstgeschwindigkeit kann außerorts je Beschaffenheit der Straße zwischen 60 km/h und 100 km/h liegen. Beachten Sie die Beschilderung.
Die maximal erlaubte Höchstgeschwindigkeit kann auf Autobahnen je Beschaffenheit der Straße zwischen 90 km/h und 120 km/h liegen. Beachten Sie die Beschilderung.
Quelle: ADAC
Meine Beobachtung ist, dass in Schweden ein Verkehrsdesign angewendet wird, das klar macht, was das gewünschte Verhalten ist und gleichzeitig klar macht, dass zuwiderlaufendes Verhalten sanktioniert wird und das so transparent ist, dass keiner sich wirklich beschweren kann.
Beispiel 1
Innerorts weisen Schilder auf die gewünschte Geschwindigkeit hin. In die Straße sind „Wellen“ eingebaut, die nur in der gewollten Geschwindigkeit harmlos sind. Die Wellen sind von weitem erkennbar, da rechts und links von ihnen gelb-blaue Barken stehen und ca. 50 m vorher ein Warnschild.
Beispiel 2
Auf einem Länsväg (Landstraße) steht ein Geschwindigkeitsschild mit Tempo 70. Dann kommt das Schild erneut und darunter ein Kamerasymbol, das Navi warnt zusätzlich und darauf folgt dann ein gut sichtbarer Blitzer.
Das ist ein (wahrscheinlich aber nicht der einzige) Grund, warum die überwiegende Mehrheit aller schwedischen Kraftfahrer:innen, die ich in 3 Wochen beobachtet habe, sich an die Regeln hält, die in Deutschland angeblich nicht mal denkbar sind.
Andersherum macht das auch Sinn: Wir haben solche Designs nicht, oder nur halbherzig umgesetzt. Beispiel: die Smiley-Geschwindigkeitsmesser am Ortseingang. Das nicht vorhanden sein, bzw. die halbherzige Umsetzung ist mit ein Grund dafür, warum in Deutschland gerast wird, ob auf der Autobahn oder in der 30er-Zone meines Wohnorts.
Oder anders gesagt:
„Every system is perfectly designed to get the results it gets.“
Paul Batalden influenced by the thinking of W. Edwards Deming
Was hat das jetzt mit Agilität in Unternehmen zu tun? Wenn das nächste Mal etwas in eurem Betrieb nicht so läuft, wie eigentlich gedacht, lohnt sich der Blick auf das Arbeitssystem, bevor geurteilt wird und nach den alten (oft zu einfachen) Erklärungen gesucht wird.
So fängt es meistens an. Aus irgendeiner Ecke des Unternehmens kommt diese Forderung. Aber wie geht man an die Sache ran? Kollegen von tng waren so nett und führten einen eintägigen Workshop mit dem Titel „Designing Agentic Systems“ für mein Team durch.
Dieser Workshop basierte hauptsächlich auf dem Buch von Antonio Gulli: Agentic Design Patterns. A Hands-On Guide to Building Intelligent Systems.
A comic-style graphic illustrating the steps of agent-based system design from sensing to learning. Oder gutes Beispiel das KI manchmal allein nicht ausreicht, um Qualität des Outputs zu sichern. 😉
Im ersten Teil des Workshops sprachen wir kurz über LLMs und was eigentlich Agents sind und beschäftigten uns dann ausführlicher mit den Patterns von denen es eine ganze Reihe gibt. Das wohl prägnanteste Learning war, dass jedes dieser Patterns eine Entscheidung für etwas und gleichzeitig gegen etwas anderes ist. Diese Trade Offs führen dazu, dass es gar nicht die eine korrekte Architekturentscheidung geben kann. Alle Patterns sind abhängig davon um welche Use Cases es sich handelt, welches Risiko eingegangen werden kann und in welcher Umgebung das Ganze stattfindet.
Insgesamt gib es vier Cluster zu denen man diese Patterns zuordnen kann:
Foundations
Coordination
Reasoning
Quality, Safety & Oversight
Nachdem wir die Pattens durchgearbeitet hatten und ein gemeinsames Verständnis für diese gebildet hatten, ging es in die Gruppenarbeit. In kleinen Teams zu 2 bis 3 Menschen bekamen wir die Aufgabe eine agentische Architektur für einen in der realen Welt vorkommenden Use Case zu designen. Das war in unserem Fall ein Beispiel mit dem wir uns alle leicht verbinden konnten. Ein Reiseplannungs-Agent. Das Ziel war dabei natürlich nicht die eine „korrekte“ Architektur zu finden, sondern eine gut begründete Variante zu erstellen. Wir arbeiteten rein mit Visualisierungen in Excalidraw, aber es hätte auch jede andere Whiteboadlösung sein können.
In der Timebox von 2,5 Stunden, die anfänglich großzügig bemessen erschien, wurde schnell klar, dass gerade über die Fülle der Kombinationsmöglichkeiten – z.B. nicht alles kann und sollte zum Beispiel einem LLM überlassen werden – ergaben sich viele spannende Diskussionen. Sehr hilfreich war dabei, dass die Kollegen von tng immer wieder in unsere Breakout Sessions sprangen, um uns wichtige Impulse zu geben.
Am Schluss stellten wir uns gegenseitig unsere Ergebnisse vor. Wir hatten ins unseren Gruppen alles unterschiedliche Lösungen gewählt. In einem Teamworkshop mit dem Ziel eine Architektur zu finden, hätte jetzt noch die Phase der Festlegung auf das erste Experiment kommen müssen.
So blieben für uns folgende Erkenntnisse:
Der Tag war sehr gut investierte Zeit
In the real world, müsste jetzt noch ein Tag für die Erstellung und Implementierung eines POC folgen. Dazu dann die iterative Verbesserung durch Testabeckung und z.B. Guardrails, etc.
Es gibt nicht die eine „richtige“ Architektur
Patterns sind Trade Offs
Es ist sehr gut Unterstützung von Menschen mit mehr Expertise und Erfahrung in dieser Diskussion zu haben (ha, ha, nicht ganz neu!)
Insgesamt werden wir unsere Architekturentscheidungen mit Hilfe dieser Learnings noch einmal reviewen und gegebenenfalls anpassen.
Die 12 Prinzipien des Agilen Manifests werden gerne stiefmütterlich behandelt. Doch dienen sie als Leitlinien für agiles Arbeiten und ergänzen erklärend die vier übergeordneten Werte des Manifests. Sie helfen Teams, Organisationen und Einzelpersonen dabei, agile Methoden wie zum Beispiel Scrum, Kanban oder Extreme Programming (XP) sinnvoll und effektiv umzusetzen.
Cover art for the German western comic ‚Die Glorreichen 12‘ featuring twelve heroes in a dramatic showdown.
Zunächst eine Übersicht, der 12 Prinzipien und wozu sie konkret dienen. Danach ein Anwendungstipp, wie man im Team über sie ins Gespräch kommen kann.
Übersicht: ✅ 1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. • Ziel: Den Kunden regelmäßig mit funktionierender Software zu versorgen • Nutzen: Schnelles Feedback, höhere Zufriedenheit, Aufbau von Vertrauen
✅ 2. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden. • Ziel: Flexibilität gegenüber sich ständig ändernden Bedingungen • Nutzen: Bessere Anpassung an Markt und Kundenbedürfnisse
✅ 3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne. • Ziel: Kurze Entwicklungszyklen (z. B. alle 2–4 Wochen) • Nutzen: Frühzeitige Wertschöpfung und schnelles Lernen
✅ 4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten. • Ziel: Enge Kommunikation zwischen Business, Fachlichkeit und Technik • Nutzen: Gegenseitiges Verstehen, bessere Lösungen
✅ 5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen. • Ziel: Vertrauen und Eigenverantwortung fördern • Nutzen: Höhere Qualität und Engagement
✅ 6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. • Ziel: Direkte Kommunikation bevorzugen • Nutzen: Schnellere Entscheidungen, weniger Missverständnisse
✅ 7. Funktionierende Software ist das wichtigste Fortschrittsmaß. • Ziel: Fokus auf Kundennutzen steigernde Ergebnisse • Nutzen: Klarer Fokus auf Wertschöpfung
✅ 8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können. • Ziel: Kein Burnout, konstantes Arbeitstempo, Verlässlichkeit • Nutzen: Langfristige Produktivität
✅ 9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. • Ziel: Sauberer Code, gute Architektur • Nutzen: Leichtere Anpassung und Wartung
✅ 10. Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell. • Ziel: Komplexität vermeiden • Nutzen: Effizienz und Klarheit
✅ 11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. • Ziel: Teams entscheiden selbst über das „Was“ (PO) und das „Wie“ (DEV) • Nutzen: Kreativität, Verantwortung, bessere Lösungen
✅ 12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an. • Ziel: Kontinuierliche Verbesserung (z.B. durch Retrospektiven) • Nutzen: Lernkultur und stetige Optimierung
Anwendungstipp: Ein Weg, um im Team über die Prinzipien ins Gespräch zu kommen, ist die Agile Uhr. Auf z.B. einem Flip zeichnet man, eine Uhr mit 12 Markierungen. Jede Markierung steht für ein Prinzip. Dann teilt man das Team in 4 Gruppen auf. Jede Gruppe bekommt 3 Prinzipien, zu denen sie je eine Visualisierung und ein Hashtag finden sollen. Die Ergebnisse werden auf dem Flip mit der Uhr gesammelt. Nach dem Verständnisfragen zu den Prinzipien geklärt sind, kann eine weitere Aufgabe sein, die zwei Prinzipien zu finden, zu denen das Team Verbesserungspotential sieht, z.B. mit Hilfe von Dotvoting. Danach können mögliche Maßnahmen zur Verbesserung diskutiert und beschlossen werden. Die Agile Uhr kann später in den Teamraum gehängt werden. Remote wir alles auf z.B. Miro gemacht und die Uhr kann zum Videocall-Hintergrund des Agile Coaches werden.
Wie geht ihr mit den Prinzipien um? Welche der Prinzipien laufen bei euch schon gut? An welchen müsst ihr noch arbeiten?
Meine Beobachtung in den letzten Jahren ist, dass Teams, welche eine genaue Vorstellung ihres Kunden haben, einen viel größeren Nutzen schaffen, da sich ihre Gedanken um die von Ihnen zu erzeugende Wirkung für den Kunden und das Unternehmen drehen.
Was ich im Gegensatz aber viel öfter beobachtet habe ist, das viele Teams davon nur eine diffuse oder zumindest nicht transparent und geteilte Idee haben. In User Stories liest man dann z.B. „als Entwickler …“, im Planning gibt es Diskussionen, welche nur von Meinung gestützt sind und nicht von Daten. Wenn die Frage „Wer ist eigentlich unser Kunde?“ kommt, hört man ausweichendes wie: „das sind viele“. Auf konkretes Nachfragen wird weiter gemauert mit: „wir können es ja nicht allen recht machen.”
Melissa Perry über das Verständnis Ihres Produkts und Ihres Kunden.
„Als jemand, der schon seit geraumer Zeit in der Beratung tätig ist, muss ich mich ständig und sehr schnell in verschiedene Branchen einarbeiten. Und das finde ich sehr spannend, weil ich gerne mehr über all die verschiedenen Lösungen und den Mehrwert lerne, den wir bieten. Mein wichtigster Ratschlag lautet daher:
„Konzentrieren Sie sich immer zuerst auf den Kunden und den Mehrwert, den das Produkt bietet.“
Sie sollten also wissen, wer dieser Kunde ist, und genau verstehen, was die Lösung, die er anbietet oder bereits hat, für ihn leistet. Wie bietet sie einen Mehrwert und warum ist sie ihm wichtig? Wenn Sie sich darauf konzentrieren, können Sie darüber nachdenken, wie der Kunde sie nutzt. Welchen Platz nimmt sie in seinem Leben ein? Und dann können Sie Ihren Fokus erweitern. Selbst wenn ich mich im Gesundheitswesen vertieft habe, musste ich so viele verschiedene Dinge darüber lernen, obwohl ich keinen medizinischen Hintergrund habe. Dabei habe ich mich immer gefragt: Für wen lösen wir dieses Problem?“
Das Wichtigste ist zunächst nicht wie das Kaninchen vor der Schlange Angst zu haben, diese Herausforderung anzugehen. Was kann gemacht werden?
“Get out of the building!”
Andere Abteilungen haben vielleicht schon Kontakt mit Kunden und haben dazu Daten. Die Support-Hotline ist immer ein guter Startpunkt. Entweder man kann Kundengespräche live miterleben, oder von Statistiken profitieren. Der Vertrieb ist auch oft eine gute Anlaufstelle. Vielleicht können hier auch Kunden identifiziert werden, bei denen hospitiert werden kann. Das Ziel sollte immer sein, in einen möglichst direkten und regelmäßigen Kontakt mit relevanten Kunden zu kommen.
Momentan werden in meinem Umfeld dafür Hackathons organisiert, zu denen Kunden eingeladen werden. Diese steigern das gegenseitige Verständnis enorm.
Woher soll man sich als PO die Zeit dafür nehmen? Da hilft es sich Gedanken mit Hilfe des Product Owner Evolution Model zu machen. (Nähere Beschreibung in einem kommenden Post.)
Als Remote First Team ist es uns wichtig, dass wir uns regelmäßig in Präsenz treffen. Diesmal standen zwei Dinge auf dem Programm. Ein kleiner Hackathon und natürlich der obligatorische Jahresrückblick mit Jahresausblick. Zwei Dinge standen dabei zentral: a) das konsequente Aufräumen im Backlog und b) die perspektivische Weiterentwicklung des Teams.
Der erste Tag …
stand ganz im Zeichen der Backlog-Pflege. Unser PO hatte – gemäß dem Motto „Tickets im Backlog vergraben, ist wegwerfen für Feiglinge“ – schon einige alte bis uralte Backlog-Einträge im Vorfeld der Teamtage final gelöscht. Die noch vorhandenen wurden am Teamtag 1 vom Team im Pair oder Ensemble gleich umgesetzt. Obwohl das Team schon sehr oft virtuelle Büros eröffnet, war in Präsenz noch eine andere Dynamik spürbar, ähnlich der beck.tech Townhall.
In der Vorplanung benötigt ein PO zwei bis drei Sprints mit „Ready 4 Sprint“ Einträgen, damit das Team z.B. bei temporärem Ausfall des POs weiterlaufen kann. Danach dürfen die Einträge im Backlog an Granularität zunehmen. Bis hin zu dem Punkt, an dem sie „nur“ Ideen sind. Bildlich ähnelt das Backlog damit einem Eisberg. Ab 150 Einträgen ist dann aber irgendwann Schluss, denn das kann sich niemand aktiv merken. Außerdem hatte die agile Vorgehensweise ja einmal den Grund flexibel auf sich verändernde Bedingungen einzugehen und wenn das Backlog sich übermäßig füllt, steigt das Risiko in einem solchen Umfeld, Arbeit für die Tonne zu machen, wenn diese nicht rechtzeitig angegangen werden kann.
Am Abend genossen alle Beteiligten die gemeinsame Zeit in Präsenz bei etwas Sport und einem gemeinsamen Essen.
Tag 2 …
stand im Zeichen von Jahresrück und -ausblick. Wir begannen den Tag damit persönliche „Influence Maps“ zu zeichnen. In diesen sollten individuell prägende Ereignisse und Personen auf dem eigenen Lebensweg visualisiert werden, welche die Person zu der gemacht haben, die sie heute ist. Dabei lernten wir mehr über unsere Teamgefährten und waren erstaunt, wie viele verschiedene Einflüsse in uns selbst und auch als Team zusammenkommen. Es zeigte mir als Coach aber auch, das wir erst beginnen uns gegenseitig zu öffnen und verletzlich zu machen, denn die Beiträge waren zu großen Teilen noch sehr an der Oberfläche. #psychologischesicherheit
Quelle: Agilitrix: Create Authentic Connections with Influence Maps, 2013
In einem Jahresrückblick arbeiteten wir heraus, was die Methoden und Eigenschaften sind, die uns 2025 geholfen haben und welche wir mit hinüber nach 2026 nehmen wollen. Konfrontiert mit dem Ergebnis der Berater, die einige Zeit in der Firma unterwegs waren, reflektierte das Team, welche Kritik davon auf das Team zutrifft und wo mögliche Entwicklungspotentiale liegen. Dann schauten wir auf die Herausforderungen für 2026, die jetzt schon absehbar sind und fragten uns, ob wir uns dafür gut aufgestellt sehen und wo wir als Team noch nachlegen sollten. Das Team war grundsätzlich mit sich zufrieden und sah sich gut gerüstet. Da ich das antizipiert hatte und dem Team aber zumindest eine Entwicklungsmöglichkeit mit über die Weihnachtzeit geben wollte, hielt ich einen Impulsvortrag mit dem Titel „High Performance Teams versus High Impact Teams“, um eine mögliche Weiterentwicklung des Teams für 2026 ins Spiel zu bringen.
Im Gegensatz zu High Performance Teams, welche einen hohen Output generieren, erkennt man High Impact Teams an 5 wichtigen Merkmalen: Hohes Maß an Psychologischer Sicherheit, Kundenorientierung und Wirkung, Flexibilität und Reflektivität, Verlässlichkeit und Bedeutung und letztlich an klaren Zielen und Strukturen.
Das Team hat das Potential von einem jetzt schon sehr guten Team zu einem großartigen Team zu werden. In 2026 werden wir diesem Ziel wieder ein Stück näher kommen.
Als Gruppe von Scrum Mastern und Agile Coaches bewegte uns die Frage, welche Fähigkeiten wir als Individuen haben und was wir als Gruppe beherrschen. Der Impuls dazu kam von Außen. Andere Abteilungen im Unternehmen sehen die Notwendigkeit ihre Arbeitsweisen zu hinterfragen und schauen interessiert zu uns.
Was sollte ein Agile Coach können? Da unser Beruf keine einheitliche Ausbildung kennt, empfiehlt es sich aus meiner Sicht, einem hohen und vertrauenswürdigen Framework zu folgen. Wir entschieden uns für das ACCF (Agile Coaching Competency Framework) von Lyssa Adkins.
ACCF
Die Daumenregel ist mindestens 1 Fähigkeit in jedem Quadranten zu haben. Doch welche Fähigkeiten passen in welchen Quadranten und wie wollen wir bestimmen, wie die Fähigkeit ausgeprägt ist?
Zunächst haben wir asynchrone in einer Liste erstellt. Jede/r von uns schrieb alles was in die Quadranten passen könnte hinein. Da zeigten sich schon die ersten Unterschiede im Verständnis. In eine weitere Spalte schrieben alle ihre persönliche Selbsteinschätzung. zusammen mit einer kurz Info wie “zertifiziert nach”, “praktische Erfahrung von”, und so weiter. Die Selbsteinschätzung machten wir so simple wie möglich. Orientiert haben wir uns am Konzept von Shu (lernt die Regeln), Ha (wendet die Regeln an), Ri (beugt die Regeln) – im besten Sinne von Bruce Lee.
Als nächstes folgte unser Teamtag, an dem wir miteinander ein gemeinsames Verständnis erarbeiten wollten, was in welchen Quadranten gehört und ob noch eine Fremdeinschätzung der Fähigkeiten nützlich sein könnte. Außerdem wollten wir eine einfache Visualisierung erstellen, damit wir erkennen könnten, wo wir noch Bedarf an Weiterbildung haben und eventuell uns in späteren Terminen damit in der Unternehmung vorstellen könnten.
Als Team haben wir gelernt, dass es mehr Zeit benötigt, als wir uns vorgenommen hatten. Ebenfalls haben wir gelernt, dass es immer eine Unschärfe in solch einer Einschätzung geben wird.
Daher beschlossen wir eine schnelle Option zu wählen, um mit unseren Kunden ins Gespräch zu gehen. Diese basiert auf der einfachen Selbsteinschätzung der Teammitglieder. Das erschien uns „good enough for now“. Da wir den Austausch über unsere Kompetenzen als wertstiftend empfunden haben, entschlossen wir uns zum Jahresausklang uns noch einmal einen Tag Zeit zu nehmen und in lockerer Runde mit Kakao, Kaffee oder Tee uns unsere Erfahrungen gegenseitig zu erzählen. Wenn es uns ein besseres Verständnis zur Selbsteinschätzung unserer Kompetenzen liefern sollte fein, auf jeden Fall wird es uns näher zusammenbringen, da wir besser verstehen welchen Erfahrungsweg die Anderen genommen haben. Ich freu mich drauf.
Wenn wir diesen Tag miteinander verbracht haben, werde ich diesen Beitrag ergänzen.
Mit Teams arbeite ich momentan auf Produktebene mit dem Product Vision Board und der Go-OKR-Roadmap von Roman Pichler. Übergeordnet gibt es seit kurzem Abteilungs-Objectives. Bei der Arbeit an unseren Team-Objectives kam immer wieder die Frage auf: Wohin will eigentlich die Firma? Da die OKR-Initiative in der Abteilung entstanden ist, gibt es noch kein MOAL (Midterm Goal) oder gar Company-Objectives. Eine Strategie für die Firma in der Form, dass jede/r auf jeder Ebene des Unternehmens benennen könnte, wird erst erarbeitet.
Play in American Football
So begann ich mich wieder intensiver mit dem Thema Strategie zu beschäftigen. Eine interessante Beschreibung fand ich im Buch „Playing to Win“ von Lafley & Martin. Sie definieren Strategie so:
„(…) Strategie ist ein integrierter Satz von Entscheidungen, die das Unternehmen in seiner Branche einzigartig positionieren, um einen nachhaltigen Vorteil und einen überlegenen Wert im Vergleich zur Konkurrenz zu schaffen.“ (Playing to win, Lafley & Martin, 2024, S.11)
Die Autoren nennen fünf Entscheidungsfragen die Wahlkaskade. Sie lauten: Was ist das Ziel? Wo spielen wir? Wie gewinnen wir? Welche Kernfähigkeiten brauchen wir? Welches Managementsystem ist nötig? Teilweise werden diese Fragen auch im Product Vision Board beantwortet. Ich werde, wenn wir beim nächsten Mal in den Teams wieder auf unsere Produktstrategie schauen, diese Fragen einbringen. Dies scheint auch im Sinne der Autoren zu sein, denn sie sprechen in größeren Organisationen davon, dass auf alle Ebenen solche Wahlkaskaden beantwortet werden sollten. Jedes Produkt, jede Abteilung, jede Ebene in der Hierachie für sich, mit dem Wissen um die Anderen angrenzenden Wahlkaskaden.
Sie beschreiben, dass Strategiearbeit ein iterativer Prozess ist, bei dem sich die einzelnen Komponenten gegenseitig bedingen. Das gilt für die Erstellung aber natürlich gerade dann, wenn die initiale Strategie steht. Außerdem sagen sie, dass dieser Prozess nicht die Aufgabe einer kleinen Gruppe von Experten sein muss. Aus meiner Perspektive auch nicht sein sollte, um möglichst viele relevante Stimmen zu hören und das spätere Commitment in das Ergebnis – die Strategie – zu erhöhen.
Das Buch heißt „Playing to Win“. In Deutschland – so mein Eindruck – fremdelt man ja manchmal mit dem Willen zu Gewinnen. „Ich spiele doch aus Spaß“, hört man oft. In meiner persönlichen Erfahrung haben Dinge aber eine größere Chance erfolgreich zu sein, wenn ich mir eine Intention setze. Zum Beispiel: Wie ich mich in einem Termin verhalten will, bis hin zu, was ich in diesem Quartal erreichen will. In diesem Sinne verstehe ich das „Gewinnen“, wie die Autoren es beschreiben. Wenn ich zum Beispiel im Sport mir nicht die Absicht setzte das Spiel zu gewinnen und alles (Faire und Sportliche) tun werde, um das zu erreichen, werde ich gegen einen gleichwertigen Gegner sehr wahrscheinlich als Verlierer vom Platz gehen.
Mein Fazit: Playin to Win ist ein sehr interessantes, kurzweilig geschriebenes Buch, mit vielen Beispielen aus P&G (Procter & Gamble). Die Essenz wird nach jedem Kapitel zusammengefasst und ist allgemeingültig formuliert. Ich persönlich freue mich darauf es mit meinen Teams auszuprobieren und sehe mich auch dadurch gerüstet im Company weiten Strategieprozess die richtigen Fragen zu stellen.
Im Juni 2025 kamen 12 Teams, interne Mitarbeiter aus unterschiedlichen Fachabteilungen und Kunden für zwei Tage zu einem Hackathon zusammen. Die Zielsetzungen kamen aus den Teams, hatten je einen Sponsor und einen Coach. Die gemeinschaftliche Idee war es den ersten Vormittag mit einer für alle mehr oder weniger neuen Methode zu starten: Dem Design Studio
Das Design Studio ist ein kollaborativer Workshop-Ansatz, der darauf abzielt, in kurzer Zeit eine große Anzahl unterschiedlicher Ideen und Lösungsansätze zu generieren. Es ist eine iterative Methode, die häufig im Design Thinking und in der agilen Produktentwicklung eingesetzt wird, um schnell innovative Ideen zu entwickeln und zu verfeinern. Wenn man sich das Buch „Sprint“ von Jake Knapp vornimmt, liest man allerdings das dort 5 Tage, also eine Sprintwoche, dafür verwendet wird. Konnte eine extreme Verkürzung auf einen Vormittag funktionieren?
Bei der Townhall (Pfeil, da steh ich)
Auf dem Hackathon konnte ich es ausprobieren. Ich war skeptisch. In einem interdisziplinären Team wollten wir uns darum kümmern, welche Schmerzen, Wünsche und Bedürfnisse unsere Kunden in Bezug auf eines unserer digitalen Produkte haben. Am Ende des Hackathons sollte ein von Kunden getesteter Click-Dummy stehen.
Kernpunkte der Design Studio Methode
Kollaborativ: Das Design Studio bringt ein multidisziplinäres Team zusammen, um gemeinsam an einem Problem zu arbeiten.
Iterativ: In mehreren Runden werden Ideen generiert, präsentiert, diskutiert und weiterentwickelt.
Visuell: Skizzen und Prototypen spielen eine wichtige Rolle, um Ideen zu visualisieren und zu veranschaulichen.
Strukturierter Prozess: Die Methode folgt einem klaren Ablauf, der sowohl die Ideengenerierung als auch die Bewertung und Verfeinerung umfasst.
Fokus auf Nutzer: Die Design Studio Methode kann genutzt werden, um nutzerzentrierte Lösungen zu entwickeln.
Ablauf einer Design Studio Session:
1. Problemstellung: Ein klar definiertes Problem oder eine Herausforderung wird vorgestellt.
Diese Problem hatte sich auf dem Hackthon konkretisiert, da wir mit einigen Kundenitnterviews geführt hatten und mit anderen eine Customer Value Canvas ausgefüllt hatten. (Mehr dazu erfährst du hier.)
2. Ideenfindung: Die Teilnehmer entwickeln in kurzer Zeit (z.B. 5 Minuten) individuelle oder paarweise Skizzen. Wir haben es individuell, je 1 Minute, auf DIN A4 Papier gemacht. Ergebnis 6 Skizzen auf einem Blatt x 9 Personen = 54 Skizzen in 6 Minuten.)
3. Präsentation und Feedback: Die Skizzen werden dem Team vorgestellt und mit zwei Klebepunkten (oder Ähnlichem) markiert. Die Timebox von 2 Minuten wurde von allen eingehalten. Allerdings ist es eine geballte Ladung Info. Beim nächsten Mal würde ich etwas mehr Zeit nach dem erstellen der Skizzen geben, damit die Ersteller ein Schlagwort oder kurze Headline für jede ihrer Skizzen erstellen, damit es allen beim Bepunkten leichter fällt, sich zu orientieren.)
4. Weiterentwicklung: Die Teilnehmer überarbeiten ihre Skizzen basierend auf dem Feedback und neuen Inspirationen. Wir haben uns entschieden, die sich wiederholenden Ideen in den Skizzen, welche hoch bewertet waren zu nehmen, einen Paperprototype zu bauen und dann weiter mit den Kunden zu itterieren.
5. Wiederholung: Die Schritte 2-4 können mehrmals wiederholt werden, um die Ideen zu verfeinern.
6. Ausarbeitung: Abschließend werden die besten Ideen in einer gemeinsamen Skizze oder einem Prototyp zusammengefasst. (Wir haben uns hier für Paperprototyping entschieden, welche den Kunden zur Interaktion vorgelegt werden.)
Vorteile der Design Studio Methode
Schnelle Ideengenerierung Es können viele Ideen in kurzer Zeit generiert werden.
Interdisziplinärer Austausch Unterschiedliche Perspektiven fördern die Kreativität und die Qualität der Lösungen.
Fokus auf das Wesentliche Die Methode hilft, schnell zu prototypen und zu testen.
Stärkung des Teamgeists Die gemeinsame Arbeit an Ideen fördert die Zusammenarbeit und das Verständnis im Team.
Methodenbeschreibung stammt von: Google KI-Zusammenfassung Die Anmerkungen sind meine eigenen Erfahrungen im Juni 2025
Das ist eine Frage, die von meinen Kindern nicht immer eindeutig beantwortet werden kann, wenn sie zusammen mit Lego etwas gebaut haben. Was bei Kindern noch lustig ist, möchte ich als Agile Coach bei meinen Teams vermeiden. Deshalb ist es wichtig, dass es Klarheit darüber gibt, für wen wir was machen und warum. Und dies nicht nur in den Köpfen der Product Owner, welche die Produktverantwortung tragen.
In einem der Teams die ich gerade begleite, nahmen wir uns zum Beispiel 2 x 2 Stunden Zeit und arbeiteten mit Hilfe des von Roman Pichlers entwickelten Product Vision Boards (PVB). Das PVB ist ein visuelles Werkzeug und dient dazu, wichtige Aspekte wie die Produktvision, Zielgruppe, Bedürfnisse der Nutzer, Kernfunktionen und Geschäftsziele gemeinsam, in Hinblick auf die Ziele des Unternehmens zu definieren.
Im Workshop haben wir unser Wissen zu den Aspekten Zielgruppe, Bedürfnisse, Business Ziele u.a. zusammengetragen. Teilweise haben wir in Kleingruppen diese Aspekte vertieft, um dann unser gemeinsames Verständnis auf dem Product Vision Board festzuhalten.
Meine Aufgabe dabei war es, das Team durch diesen Prozess zu führen und meine Expertise an Stellen einzubringen, wenn sie benötigt wurde. Zum Beispiel bei der Formulierung der Produktvision. Es ist im übertragenen Sinne etwas anderes, ob die Vision klingt wie: „Ich mache im Krankenhaus sauber.“ oder „Ich trage mit meiner Arbeit dazu bei Krankenhauskeime zu beseitigen, damit die Sterblichkeit der Patienten aufgrund solcher Keime um 90% reduziert wird.“
Wir stießen bei unserer Arbeit auch auf „blinde Flecken“, bei denen wir explizit machen konnten, was wir schon länger wussten. „Wir müssen mehr über unsere Nutzer in Erfahrung bringen“. Deshalb waren wir auch sehr glücklich über die Townhall, bei der wir bereits die Gelegenheit ergriffen hatten, Nutzerinterviews zu führen, was wir in der Folgezeit weitergeführt haben.
Wichtig dabei ist allgemein, dass dies ein empirischer Ansatz ist. Man sollte zu Beginn nicht zu viel Arbeit in das Product Vision Board stecken. Wir wollen also in Zukunft regelmäßig überprüfen, ob unsere Daten weiterhin bestimmte Annahmen validieren, oder ob sich Dinge geändert haben und wir daraufhin unsere Ausrichtung anpassen müssen.
Mit Hilfe des Product Vision Boards haben wir begonnen eine Roadmap zu erstellen. Da wir in der Abteilung mit OKRs arbeiten natürlich als OKR Roadmap, aber das wird sicherlich ein nächster Post.
Wie stellt ihr sicher, dass es in euren Abteilungen und Teams ein gemeinsames und geteiltes Verständnis zu Produkt Vision, Strategie und Kundenbedürfnissen gibt?
Zunächst beschreibe ich ein schwieriges Meeting. Danach gehe ich auf mögliche Ursachen ein und dann beschreibe ich Handlungsoptionen, die helfen.
“Ich bin mir ganz sicher, wenn wir uns überlegen würden, was ist denn der Faktor, der in Firmen ganz drastisch die Produktivität verbessern würde? Ist das die Einführung von SAP oder was ist es? (…) Ich bin mir ganz sicher, dass der Faktor, der das am schnellsten hinkriegen würde und der eigentlich gar nicht so teuer sein müsste, das ist die firmeninterne Schulung von Moderatorinnen und Moderatoren.” Peter Modler
Podcast „Neu geordnet“ 10.07.2023
Das Meeting Du wirst gebeten ein Meeting zu moderieren. Du kennst die Menschen vom Sehen. Als du gerade angefangen hast, kommt noch ein Teilnehmer zu Tür rein, er entschuldigt sich nicht, kommentiert laut seinen eigenen Vorgang der Platzsuche und findet sogar noch Zeit einen anderen Teilnehmer zu begrüßen. Als er sich endlich gesetzt hat, breitet er seine Unterlagen großflächig aus. Du, als wohlerzogener Mensch, stellst dich kurz vor: “Hallo, ich bin Edgar.” Du versuchst dann wieder den Fokus auf das Meeting zu setzen. Schon beim Vorstellen der Agenda fällt der Mensch von eben dir ins Wort, da er meint das Agendapunkt 5 ja der eigentlich wichtige sei und an Nummer eins gehöre. Du versuchst zu erklären, dass dies ja die Agenda der Fachabteilung sei, für die du kurzfristig die Moderation des Meetings übernommen hättest. Er nörgelt noch eine Weile an der Agenda herum. Als die Fachabteilung dann endlich ihren Vorschlag mit einer Menge Daten vorgestellt hat, sagt der Mensch von eben schlicht: “So ein Quatsch!”. Trotz der Versuche mit Fakten zu überzeugen, bleibt er dabei. Das Meeting endet ohne Ergebnis.
Was lief schief Das Verhalten einer Person im Meeting war nicht kooperativ und die Moderation war nicht in der Lage, das Meeting erfolgreich zu machen.
Warum war das so? Die kurze Antwort: Hier trafen Menschen mit unterschiedlichen Kommunikationssystemen aufeinander.
Die ausführlichere Antwort: Moderator:in und einige Teilnehmer:innen war in einem sogenannten „horizontalen Kommunikationssystem“ unterwegs. Sie sendeten dabei Inhalte, Argumente und Zeichen der Gleichheit. Ihnen ging es um Dialog auf Augenhöhe. Ihr „Gegenspieler“ war im „vertikalen Kommunikationssystem“ unterwegs. Ihm ging es zunächst um Rang und Revier. Das musste geklärt werden, bevor er überhaupt inhaltlich hätte einsteigen können.
Die Begriffe „horizontales und vertikales Kommunikationssystem“ stammen von Dr. Peter Modler, der sich auf Arbeiten von Deborah Tannen, einer Soziolinguistin an der Georgetown University, beruft. Sie hat sich geschlechterspezifische Unterschiede in der Kommunikation angesehen. Dabei macht sie ein Koordinatensystem auf zwischen Hierarchie und Gleichheit auf der y-Achse und Nähe und Distanz auf der x-Achse. Die Erkenntnisse von Deborah Tannen liefern dabei aber keine eindeutige Zuordnung von Kommunikationssystem zu Geschlecht. Das heißt, Männer wie auch Frauen, bedienen sich dieses Systems. Es gibt ebenfalls keine Bewertung der unterschiedlichen Systeme. Beide Systeme können gut für die jeweilige Person in bestimmen Kontexten funktionieren. Es wird nur problematisch, wenn sich die Beteiligten nicht darüber bewußt sind und deshalb nicht adäquat reagieren können. Zum Handwerkszeug eines guten Moderators gehört das Wissen über diese Zusammenhänge.
“Horizontale“ gehen in der Regel super vorbereitet in ein Meeting und ab der ersten Sekunde schon auf das Thema konzentriert. Das heißt, sie gehen davon aus, dass die einzige Ebene dieses Meetings die inhaltliche Ebene ist. Kennzeichen sind fachlicher Austausch, gut begründete Argumente, intellektuell akademisch – sogenannter High Talk.
„Vertikale“ gehen in ein Meeting und wissen, für mich gibt es hier zwei Ebenen. Die eine ist die inhaltliche, die andere ist die politische. Dabei muss die politisch/hierarchische geklärt werden, bevor sie sich auf die andere einlassen können. Kennzeichen sind einfache kurze Sätze – sogenannter Basic Talk. Um noch deutlicher zu werden, benutzen sie den sogenannten Move Talk. Stehen also möglicherweise auf, machen abfällige Handbewegungen, etc.
“Die Moderatorinnen und Moderatoren in Meetings von Firmen, das sind eigentlich Leute, die Wissensorganisationen machen. Und insofern sind sie ein ganz zentraler Punkt für betriebswirtschaftliche Produktivität.” Peter Modler
Podcast „Neu geordnet“ 10.07.2023
Wie hätte es besser laufen können?
Vor dem Meeting
Als Moderator:in muss ich für mich klar haben, was meine Rolle in dem Meeting ist:
Rahmen setzen und Spielregeln überwachen
konstruktive Auseinandersetzung ermöglichen
anregende Atmosphäre schaffen
Ergebnisse sichern
Zeit im Augen behalten und ermöglichen diese einzuhalten
Neutralität waren
Unterstützt wird das von:
die Einladung sollte immer vom Moderator ausgehen.
die Meeting-Regeln müssen allen vorher klar sein. Im Meeting kurze Erinnerung daran.
die Länge des Meetings sollte nach Erfahrungswerten festgesetzt werden. Dabei sollte sich nicht von der Kalendersituation oder dem Besprechungstool gegängelt werden lassen.
Es muss vorab klar sein, das es keine Hierarchie über dem Moderator im Meeting gibt. Helfen kann dabei zum Beispiel die Inthronisierung durch den Ranghöchsten. Zum Beispiel: „Frau B. wird heute für uns dieses Meeting moderieren. Ich übergebe die Leitung nun an Frau B.“
Funktion des Moderator Rolle im Meeting
Es gibt eine defensive, wie auch eine offensive Funktion.
Die defensive Funktion besteht darin, die Meeting-Kultur gegenüber Störern zu verteidigen. Damit sind die gemeint, die andere nicht ausreden lassen, Vielredner oder Selbstdarsteller ohne substantielle Beiträge. Noch dringlicher wird es wenn rassistische oder sexistische Bemerkungen gemacht werden! Das muss sofort unterbunden werden. Wertfrei, ohne Emotion – das ist wichtig! Also nur aus der Rolle sprechen, nicht als private Person.
Die offensive Funktion, bezieht sich auf Menschen, die fachlich kompetent sind, aber nicht so gerne in einem Meeting öffentlich reden. Diesen Personen muss der Moderator so viel Schutz und so viel Mut geben, dass sie im Meeting ihre Kompetenz einbringen können. Wenn sie das von sich aus nicht machen, dann muss der Moderator Mittel haben, ihnen das zu ermöglichen.
Klarheit über den Lead im Meeting herstellen
Wer gehört in welches System? Das sollte der Moderator:in klar sein. Es sind oft kleine Dinge, die das Anzeigen. Vertikale werden immer mit zu den letzen gehören, die zum Meeting erscheinen. Sie beeilen sich nicht, sondern wählen eine Geschwindigkeit, welche ihrer Machtposition unterstreicht. Die Zeit vor dem Meeting, von der Türschwelle an, ist Vertikalen wichtig. Horizontalen ist das nicht wichtig, sie können ja im Meeting verbal brillieren.
“Also wenn so ein Typ zu spät kommt und ich bin damit beauftragt, dieses Meeting zu leiten, dann muss ich genau dem so früh wie möglich klarmachen, dass ich dieses Meeting leite und nicht er. Nur weil er vielleicht ein Silberrücken ist oder zufällig ein Geschäftsführer ist. Sonst zerschießt er mir das Meeting.” Peter Modler
Podcast „Neu geordnet“ 10.07.2023
Eine Moderator:in muss für „Vertikale“ klar machen, dass sie/er diese Rolle hat und das Meeting leitet. Für Vertikale fängt die Aushandlung der Hierarchie im Meeting schon vor Beginn an. Daher muss die Moderator:in gleich wenn jemand den Raum betritt, sich mit Vor- und Zuname + Rolle vorstellen: „Guten Morgen, mein Name ist … Ich leite heute dieses Meeting.“ Eventuell kann man noch hinter schieben: „es gibt noch freie Plätze, bis auf den am Kopfende, das ist meiner.“
In Remote Meetings sollte die Rolle zu Vor und Nachnamen geschrieben werden.
Das ist schon ein erstes Zeichen für Vertikale. Vertikale müssen nicht die erste Geige im Meeting spielen. Für sie ist es nur wichtig, dass die Rangfolge geklärt ist.
Natürlich kann es passieren, dass die Aushandlung der Hierarchie im Meeting nicht deutlich genug für Vertikale war. Also jemand versucht, die Zügel der Moderation an sich zu reißen, oder wie im Beispiel versucht die Agenda im Alleingang umzustellen. Hier hilft es freundlich aber bestimmt, ganz platt an die bestehende Rangfolge zu erinnern. Dabei schaut der Moderator die Person direkt an und sagt: „Ich bin der Moderator dieses Meetings. Sie sind Teilnehmer des Meetings. Wenn sie etwas sagen möchten, melden sie sich gerne zu Wort und ich nehme sie dran.“ Wenn darüber gemosert wird, einfach stur freundlich aber bestimmt den Basic Talk wiederholen. Auf keinen Fall einknicken, denn sonst war es das mit der Autorität der Moderationsrolle. Zumindest für dieses Meeting.
Schlussbemerkung Mir ist wichtig darauf hinzuweisen, dass die hier vorgestellten Verhaltensmöglichkeiten für Moderator:innen nicht benötigt werden, wenn es sich um eine Gruppe von Menschen mit horizontalem Kommunikationssystem handelt. Hier gibt es möglicherweise auch Vielredner oder andere Störungen, doch kann mit Ihnen auf eine andere Art und Weise umgegangen werden.
Wer mehr über das Thema „mit Ignoranten reden“ wissen möchte, findet in den folgenden Quellen einen guten Startpunkt.
