Sehr geehrter Herr Kubitz vielen Dank für Ihre Frage! Wir möchte Sie in diesem Zuge auch um Entschuldigung für die späte Antwort bitten! -- Das Team hin zu einer aktiv gelebten Ergebnisverantwortung zu entwickeln ist immer ein Prozess, der zum einen Zeit und zum anderen eine intensive Begleitung im Sinne eines Coachings braucht. Grundlage ist wie im Artikel beschrieben eine strikte Rollen- und Eventdefinition mit klaren Regeln (= agiles Framework) angepasst auf die konkrete Projektorganisation. Alles was hier nicht klar definiert wird, holt einen im späteren Projektverlauf ein. Das agile Framework sollte auch (im Sinne einer permanenten Qualifizierung) stets sichtbar und transparent gehalten werden, z.B. in einer Scrum-Fibel für alle Projektteilnehmer oder auch über „Marketing“-Folien im Scrum Room. Darauf aufbauend ist wie ebenfalls im Artikel beschrieben im Rahmen der Projektsteuerung eine konsequente Einhaltung des agilen Frameworks notwendig, da das der zentrale Enabler für eine Verantwortungsdelegation vom Product Owner an das Planungsteam ist. Das fängt bei kleinen Dingen an wie einer täglichen Teilnahme am Daily Scrum zur Synchronisation des Teams und geht bis zur Aufbereitung klarer Umsetzungsempfehlungen (Verantwortung über das WIE) bzgl. zentraler Projektergebnisse in den drei Dimensionen Ergebnis-Termin-Kosten. Dabei nehmen der PO und der Scrum Master wie beschrieben die Coaching-Rolle ein. Gerade der PO muss als Vorbildfunktion seiner Rolle gerecht werden und die Rolle des Teams einfordern. Über ein Coaching hinaus müssen der PO und der Scrum Master dem Team auch Ängste nehmen (Verantwortungsdelegation ist ein kontinuierlicher Change Prozess!). Hierbei hat die Retrospective mit einer offenen Feedback- und Fehler-Kultur eine entscheidende Bedeutung. Werden Ziele nicht erreicht, darf dies nicht sofort zu einem Ausbrechen aus dem Prozess führen. Gerade vor ein paar Tagen habe ich die Diskussion mit einem PO geführt, um ihn von einem sofortigen Einschreiten abzuhalten. Ein bisschen Zeit und Vertrauen muss man dem Team schon geben. Ein Feedback ist allerdings auch wichtig. -- Anhand folgender Beispiele möchten wir das Coaching durch den Scrum Master konkretisieren. - Im Rahmen eines Fabrikplanungsprojekts haben wir es nach einiger Zeit geschafft, dass das Team nun entscheidungsfreudiger ist. Zu Beginn wurden vor allem Entscheidungsvorlagen gebastelt. Wobei die Fragen, die nur interdisziplinär zu beantworten sind (Schnittstellen der Funktionen im Dev. Team), ausgeklammert bzw. maximal stiefmütterlich behandelt wurden. Ein Fertigungsplaner im Bereich Vorfertigung hat beispielsweise mehrere Optionen zu einer vom Kunden gewünschten Volumensteigerung (wie z.B. zusätzliche Anlage, Erweiterung einer bereits beschafften Anlage, Mitnutzung einer bereits beschafften Anlage eines anderen Projekts) detailliertest ausgeplant, sekundengenaue MTM-Analysen inklusive. Auswirkungen auf den Prozess und somit auf Kosten und Investitionen in anderen Fertigungsbereichen, auf das Layout, auf Logistikprozesse usw. waren somit gar nicht Teil der Entscheidungsvorlage. Das Denken im Gesamtzusammenhang und das Wissen, auf was individuelle Planungsänderungen alles Einfluss haben können fehlte zu Beginn komplett. Wir fordern von den Planungsteammitgliedern ein, dass sie alle Entscheidungsvorlagen als Team soweit aufbereiten (inhaltlich, nicht graphisch), dass sie selbst in der Lage wären, eine Entscheidung zu treffen. Damit einher geht klare, begründete Empfehlung aus dem Team für jede Entscheidung, die sich das Team (noch) nicht selbst zutraut. Während der Präsentation der Entscheidungsvorlage dringen wir darauf, dass die Entscheidung sofort fällt und nicht vertagt wird. Falls dies doch passiert, versuchen wir zu klären, warum die Erkenntnis (dass die Entscheidung nicht getroffen werden kann) erst jetzt fällt (Was hätte man tun müssen/müsste man beim nächsten Mal tun…). Wenn man soweit ist, dass der Entscheidungsträger den Empfehlungen in der Regel folgt, kommt die Einsicht für den letzten Schritt von alleine. „Warum könnt ihr (das Planungsteam) das nicht direkt entscheiden?“. Inzwischen hat sich die „Eskalationsfreude“ deutlich zurückentwickelt. -- Im Rahmen eines hybriden Projekts (Fahrzeugprojekt Zulieferer Automotive) mit einem Scrum Team aus Entwicklung, Konstruktion, Einkauf, Fertigungs-, Logistik- und Qualitätsplanung haben wir mehrfach erlebt, dass das Team dazu neigt, auftretende Schwierigkeiten zu Hindernissen zu erklären (und sie damit aus dem Verantwortungsbereich zu schieben). Ein Beispiel ist die folgende Situation: In der Zusammenarbeit mit einem weiteren Planungsteam auf einem anderen Kontinent kommt es zu Unstimmigkeiten. Die von dort stammende Kritik an bestimmten Dokumenten kann nicht nachvollzogen werden. Anstatt in einem kurzen Telefonat dieses gegenseitige Verständnis zu schaffen, wird es als Hindernis in das Daily Scrum gespielt. Dies ist natürlich eine Einladung zur Intervention durch den Scrum Master. -- Im Rahmen einer Retrospektive wurde erkannt, dass die interkontinentale Kommunikation nicht zufriedenstellend funktioniert, was sich zunehmen zu einem Hindernis für das Planungsteam entwickelte. Um die Zusammenarbeit nachhaltig zu verbessern haben wir daraufhin die agilen Methoden auch im internationalen Partner-Team eingeführt, ergänzt um eine Schnittstelle zwischen den Teams („scaling scrum“). Im Rahmen der dortigen „Anlaufphase“ konnten wir wieder einmal in der vollen Bandbreite erleben, wie schwierig es für ein neues Team zu Beginn ist, die Ergebnisverantwortung anzunehmen. Ein Team, dass gewohnt ist, Aufgabendelegiert zu bekommen und dann einen Status zu reporten, tut sich naturgemäß schwer mit der neuen Rolle. Das gleiche gilt auch für die Product Owner (wir haben in diesem Projekt ein PO-Team). Doch wie äußern sich diese Schwierigkeiten? Die Product Owner tauchen im Daily Scrum auf und reden mit. Das gemeinsame Ziel wird unterschiedlich interpretiert. Die Planungsteammitglieder schicken uninformierte Vertreter. Das Planungsteam „berichtet“ an den Scrum Master, statt gegenseitig an sich selbst. Der Link zwischen Aufgaben und dem Sprint Backlog geht z.T. verloren, weil das Team Aufgaben aus dem Tagesgeschäft mitbringt und zugleich dazu tendiert, interdisziplinäre Aufgaben aus dem Sprint Backlog zu vergessen. Neben der permanenten intensiven Intervention im Rahmen der Events ist hier vor allem die konsequente Sprint Retrospective extrem wichtig, um gemeinsam im Scrum Team am Rollenverständnis, an den Regeln und an der „Definition of Done“ zu arbeiten. Die gemeinsam festgelegten Regeln platzieren wir immer auch sichtbar am Scrum Board. -- Um bei Zielkonflikten Ergebnisse-Termine-Kosten ein entscheidungsfähiges Planungsteam zu haben, sehen wir nur einen vielleicht radikal erscheinenden Ansatz Das Entscheidungsparadigma umzudrehen heißt, dieses vollständig umzudrehen! Also letztlich das komplette magische Dreieck Ergebnisse-Termine-Kosten in die Verantwortung des Teams zu legen. Ansonsten kann ein Team nie vollständig eigenverantwortlich über das WIE entscheiden. Natürlich lässt sich das Ausmaß der Verantwortung (gerade in der Dimension Kosten) wieder durch den Product Owner steuern. Dazu kann zum einen der Project Backlog mit übergeordneten Akzeptanzkriterien (z.B. hinsichtlich Kosten) dienen, zum anderen stellen die genannten Events des agilen Framework starke Quality-Gates dar. Vorausgesetzt wie eingangs beschrieben ist wiederum die strikte Definition und Umsetzung des agilen Frameworks im Projekt. -- Wir hoffen, damit Ihrer Frage einigermaßen gerecht zu werden. Falls weitergehendes Interesse besteht, stehen wir gerne für einen persönlichen Austausch zur Verfügung!