Schau dir Aufzeichnungen und Präsentationen an!

Vergangene Events

Oftmals starten große Organisationen ihre Reise zur Agilität mit einem Piloten in dem ein bis zwei isolierte Teams Scrum ausprobieren. Dieser Pilot ist meistens erfolgreich und daher wird Scrum auf viele Teams skaliert. Dieser multi Scrum-Team Ansatz resultiert in vielen „Team Backlogs“, „Team Product Ownern„, und führt im Endeffekt zur einer lokalen Optimierung die die Organisation als Ganzes nicht verbessert. Das Ergebnis ist die Produktivität sinkt, die Fertigstellung von kunden-orientierten Anforderungen dauert länger, die Fähigkeit die Richtung schnell und einfach zu ändern ist nicht vorhanden. In diesem Event werden wir die Ursachen erkunden, und die wichtigsten Elemente aufzeigen was eine Organisation benötigt, um diese Situation zu ändern und damit von einer multi Scrum-Team zu einer multi-Team Scrum, einer adaptiven Organisation zu werden

Psychologische Sicherheit und die Wichtigkeit von guten Beziehungen sind in aller Munde, doch wie erreicht man genau das im eigenen Team und über die Teamgrenzen hinaus?

In diesem Vortrag teile ich konkrete Ansätze und Praktiken, die ich in meiner Arbeit als Agile Coach sowohl innerhalb meines Teams als auch über Teamgrenzen hinweg eingesetzt habe und immer noch einsetze, um eine psychologisch sichere und vertrauensvolle Umgebung zu schaffen. 

Ich möchte mit meinem Vortrag Inspiration und Hilfe für eure Arbeit in euren Teams bieten. Ich teile meine Vorgehensweise, um euch Anregungen zu geben und euch zu unterstützen, euren eigenen Weg zu finden und das zu implementieren, was für euch und eure Teamumgebung am besten passt. 

Sobald das Unternehmen kein Startup mit nur einer Handvoll Mitarbeitern mehr ist, stellt sich die Frage nach der inneren Struktur. Historisch wurden einfach Menschen mit ähnlicher Ausbildung in Gruppen sortiert und diese Gruppen dann weiter geordnet.

In dem Vortrag zeige ich wie Skalierung vernünftig, orientiert an der echten Wertschöpfung, funktionieren kann. Dazu greife ich auf das wenig bekannte ScALeD Modell zurück. Damit öffnet sich ein natürlicher Weg der Skalierung von Agilität ohne erhobenem Zeigefinger und pedantischer Diskussion um die Details des einen oder anderen Skalierungsframeworks.

Ein wenig beachteter Aspekt von Skalierung ist die Unternehmenskultur. In vielen Fällen wird davon ausgegangen, dass das passende Skalierungsframework Handlungen erzeugt die zu neuen Erfahrungen führen, und diese Formen eine neue Unternehmenskultur.

Das ist überraschend, denn es gibt schon viele Jahre Ideen wie Unternehmenskultur – auch im Sinne einer Unternehmensagilität –aktiv geformt werden kann. Allerdings braucht man dazu einen längeren Atem und ein kontinuierliches Zusammenwirken aller Verantwortlichen.

Neue Personen, unbekannte Organisationsstrukturen, unklare oder unbekannte Ziele und gegensätzliche Laufrichtungen, unausgesprochene Spannungsfelder, technisches Kauderwelsch und du plötzlich mittendrin. Wer kennt es nicht: als Scrum Master startest du in einem neuen Team und stehst ganz neuen Herausforderungen gegenüber. 

Dein Ziel ist klar: Als „True Leader“ dein Team weiterentwickeln und dazu befähigen, ein wertvolles Produkt liefern zu können. Aber was kannst du bewirken, wenn du dein neues Umfeld noch gar nicht verstehst? Erstmal nichts. 

In diesem Vortrag lernst du die sechs Dungeons kennen, die du bewältigen musst, um möglichst schnell in deinem Team wirksam zu werden und welche Methoden dir dabei helfen können. Ob du nun zum ersten Mal in der Rolle des Scrum Masters agierst oder als erfahrener Scrum Master bereits mittendrin in deinem hundertsten Projekt steckst: hier findest du Inspirationen für deine Selbstorganisation. 

Als Scrum Teams führen wir im agilen Alltag zahlreiche Rituale durch. Wir nennen sie nur anders: Scrum Events.
Ebenso wie andere helfen sie uns, Komplexität zu reduzieren und Struktur und Ordnung in einer nicht-geordneten Umwelt zu etablieren.

Mit unseren Scrum Ritualen stehen wir als Scrum Teams dabei vor ähnlichen Herausforderungen wie andere Ritualgemeinschaften.
Eine besonders prominente Ritualgemeinschaft ist die katholische Kirche. Auf den ersten Blick hat „Scrum“ vielleicht nichts mit „Kirche“ zu tun.
Wenn wir beide hinsichtlich ihrer Rituale betrachten, ergeben sich zwischen beiden Welten aber ganz spannende, zuweilen amüsante, und im besten Falle auch hilfreiche Parallelen:

An diesem Abend möchte Michael dieser vielleicht ungewöhnlichen Parallelisierung von Scrum-Ritualen und kirchlichen Ritualen nachgehen und darüber sprechen:
Was ist eigentlich ein Ritual? Wo gibt es Parallelen zwischen Scrum Ritualen und religiösen Ritualen? Können wir für unseren Alltag etwas von den Herausforderungen lernen, vor denen andere Ritualgemeinschaften wie die kath. Kirche stehen?

Die Entscheidungsverantwortung muss zwischen allen Akteuren im konkreten organisatorischen Kontext explizit gemacht werden. Eine solche Transparenz bietet die Sicherheit, auch mutige Entscheidungen zu treffen.

Aus diesem Grund haben Tim Klein und Oliver Winter vor fünf Jahren das „Product Ownership Evolution Model“ – kurz POEM – entwickelt. In dieser Session wird uns Tim noch mal die Hintergründe, Aufbau und Wirkung von POEM erklären sowie Facilitation-Tipps geben. Zudem werden wir die Chance bekommen, das Model selber auszuprobieren und Fragen rund um Product Ownership gemeinsam zu diskutieren.

Mit dem „Product Owner Evolution Model (POEM)“ wird ein Werkzeug vorgestellt, in dem die Vertreter:innen der (Scrum-)Rollen die Ist-Situation ihrer Entscheidungsfreiräume selbst eintragen können (Positionierung i.S. einer Aufstellung). Dies umfasst u.a. auch den „Business Owner“ (als Synonym für CPO, Director Product, CEO, o.ä.). Während ein solches Self-Assessment bereits an sich einen gewissen Wert darstellt und wunderbare Möglichkeiten zur gemeinsamen Diskussion eröffnet, liegt der größte Wert des Modells in der Entwicklung eines gemeinsamen Zielbilds. So können alle Rollen – und insbesondere Product Owner – im folgenden Schritt ihre gewünschte Soll-Position eintragen und gemeinsame Entwicklungsziele festlegen. Ein weiterer Aspekt ist das Coaching durch Scrum Master oder Agile Coach: Mit dem Modell kann gut veranschaulicht werden, bei welchen Tätigkeiten, Scrum Master oder Agile Coach für Product Owner:in und Entwicklungsteam aktuell entsprechendes Coaching anbieten kann. Ebenso entsteht damit Klarheit, wo im Kontext des Zielbildes ggf. ein anderer oder erweiterter Coaching-Bedarf entsteht, um Product Owner:in und Entwicklungsteam auf ihrem Weg in ihre neuen Verantwortungsbereiche zu unterstützen und zu begleiten.

Wenn Teams oder Organisationen sich dazu entscheiden, „agiler“ zu werden, orientieren sie sich in ihrem Setup häufig am Rahmenwerk Scrum. Sie benennen also Scrum Master und Product Owner, planen Sprints mit Planning, Dailies, Review und Retros und priorisieren die Anforderungen der Stakeholder als „User Stories“ in einem Product Backlog, das sie abarbeiten – macht man so, richtig?

Ganz klar: Jein. Denn die Verantwortlichkeiten, Events und Artefakte von Scrum einzuführen („Doing Agile“), ohne dass die Beteiligten deren Sinn, Zweck und Kontext verstehen und zu beherzigen wissen („Being Agile“), führt fast unweigerlich zu einer Reihe von Missverständnissen, die schon von Beginn an in die Irre führen können und später schwer wieder einzufangen sind. Also: Was braucht‘s, damit Euer Scrum kein murcS wird?

Design Thinking „ist ein kreativer Prozess zur Lösung komplexer Probleme“ sagen die einen. „Ist eine Haltung“, sagen die anderen. Ich sage “ja” zu beidem. Ich motiviere, warum es wichtig ist, nicht sofort in den Lösungsraum zu gehen und zeige, wie Design Thinking eine Brücke zwischen dem, was ist, und dem, was sein könnte, schlägt. Ein an den Menschen ausgerichtetes Vorgehen ermutigt dazu, sich auf deren Bedürfnisse zu konzentrieren und so bessere Produkte, Dienstleistungen, Prozesse und Organisationen zu entwickeln. Der Perspektivwechsel von „making people want things“ hin zu „making things people want“ zeigt, wie Design Thinking und Agile sich ergänzen und sinnvolle Innovationen ermöglichen. 

Wie im Design Thinking üblich, gibt es in dem Vortrag auch eine „hands-on experience“ – daher haltet bitte einen Stift und 2 Blatt Papier bereit!