Prozesse: "Mechanik" vs. "Einstellung"

Bei Diskussionen rund um agile Vorgehensmodelle oder Entwicklungsprozesse innerhalb von Organisationen erlebe ich immer wieder, dass die Menschen darauf fokussieren wie die Prozesse implementiert wurden. Es wird selten diskutiert warum gewisse Prozesse so ausgeführt werden bzw. welches Ziel damit verfolgt wird.
Dies führt oftmals dazu, dass die Meetings eines Frameworks (z.B. Scrum) täglich ausgeführt werden, aber das zugrunde liegende Ziel nicht erreicht wird. Es ist sogar so, dass diese "Abweichung" aufgrund von fehlendem Wissen nicht einmal erkannt wird.
Deswegen möchte ich in diesem Thread auf die wichtigsten Meetings sowie deren Ziel innerhalb des Entwicklungsprozesses bei logi.cals eingehen.

Sprint Planung
Die Sprint Planung wird bei uns in 2 Teile unterteilt und wird zu Beginn eines Sprints (alle 2 Wochen) durchgeführt.
Teil 1
Ziel ist es, gemeinsam ein Sprint-Ziel zu definieren. WAS soll am Ende des Sprints verfügbar sein?
Als Basis dient der Produkt-Backlog, es wird definiert welche neuen Funktionalitäten innerhalb dieses Sprints entwickelt werden. Das Entwicklungs-Team committed sich gegenüber dem Product-Owner dazu, die definierten Funktionen bis zum Ende des Sprints zu entwickeln und in das Produkt gemäß der Definition of Done zu integrieren.
Teil 2
Ziel ist es, einen Umsetzungsplan für den Sprint zu entwickeln. WIE wird das definierte Sprint-Ergebnis erreicht?
Das Entwicklungs-Team definiert gemeinsam alle Tasks, welche notwendig sind um das Ziel zu erreichen und publiziert diese auf dem Scrum-Board.

Daily Scrum
Ziel des Meetings ist die tägliche Abstimmung des Entwicklungsteams in Bezug auf die definierten Sprint-Ziele. WIE ist der Status in Bezug auf die zugesagten Ergebnisse?
Das Entwicklungsteam adaptiert ggf. den Umsetzungsplan sodass die zugesagten Ergebnisse geliefert werden können. Können Hindernisse durch das Entwicklungsteam nicht beseitigt werden, werden diese über den Scrum-Master eskaliert.

Sprint Review
Ziel des Sprint-Reviews ist es, Feedback zu dem gelieferten Produkt durch einen Anwender zu erhalten. Entspricht das WAS geliefert wurde der Erwartungshaltung?
Daraus werden Änderungswünsche am bestehenden Produkt generiert, welche in weiterer Folge in den Produkt-Backlog eingepflegt werden.

Sprint Retrospektive
Ziel der Sprint-Retrospektive ist es, den Prozess und die Zusammenarbeit innerhalb des Sprints zu bewerten und Verbesserungen abzuleiten. Entspricht die Vorgehensweise WIE das Team während dem Sprint gearbeitet hat unseren Vorstellungen und Ansprüchen?
Daraus werden Änderungen am Prozess generiert, welche im folgenden Sprint umgesetzt werden.