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?

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.

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?