Gutes Video! Da kommt das vielgesagte Sprichtwort: "SCRUM rückwärts gelesen ergibt MURCS" zur Geltung. Letztlich ist SCRUM nur eine Form der Ausarbeitung eines Projektes. Wie aber ein Projekt definiert wird, steht auf einer anderen Karte. Diese wird oftmals vergessen. Da heißt es in der krassesten Form: "Wir nehmen die Anforderungen in Schriftform auf, da haben wir Spielraum in der Interpretation. Gemeinsames Verstehen mit dem Kunden, gemeinsame Entwicklung von Lösungen via Rapid Prototyping ... das ist uns zu aufwendig."
@@SebastianBurkart Finde ich in deiner Playlist Videos zum Aufsetzen von Projekten? Als zentrales Element nutze ich "Project Canvas" in Kombination mit Design Thinking bzw. Sprint Design mit dem Ziel, einen testbaren Prototypen zu entwickeln. Was sind deine ne Ansätze?
Hi. Leider habe ich dazu noch keine Videos. Meine Ansätze sind da ähnlich zu deinen. Design Sprints, Project Canvas, was ich auch oft verwende sind Product Canvases und vor allem Story Maps, damit man eine gute Visualisierung hat, wie der Schnitt ist, wie der Flow usw.
@@SebastianBurkart Ich finde diesen Ansatz auch Klasse. Vor allem daher, dass der Entscheider (sprich der Kunde) in den Entwicklungsprozess von Anfang an ins Boot geholt werden kann. Der Kunde wird zum Partner. Der Vorteil: Man entwickelt keine Lösungen mit tausenden Funktionen, sondern in sich kompatible Module. Der Kunde kann dann die Module in Ihrer Wichtigkeit priorisieren. Letztlich hilft das genau das auch dann in der agilen Umsetzung.
Eine Frage, eigentlich steht im Scrum Guide, dass nur die Developers beim Daily Meeting mitmachen. Warum haben Sie gesagt (wie bei Frage 1 geantwortet), dass der Product Owner dabei sein muss?
Der Scrum Guide sagt zwar, dass nur die Developer daran teilnimmt und der Produkt Owner und der Scrum Master nur, wenn sie an Einträgen des Sprint Backlogs arbeiten, aber meine Erfahrung und die vieler Anderen hat gezeigt, dass es extrem viel Sinn macht, dass der Product Owner daran teilnimmt, da er offene Fragen zu Tickets, Fragen bzgl. der Priorität beantworten kann. Auch sagt der Guide, dass im Daily Scrum auch bei Bedarf das Sprint Backlog angepasst werden kann. Hierfür macht es meiner Meinung nach viel Sinn, den Product Owner direkt mit in der Diskussion zu haben und nicht erst danach zu informieren und dann vielleicht aufgrund weiterer Informationen doch wieder was ändern zu können. Zudem heißt es im Guide auch "Daily Scrums verbessern die Kommunikation". Diese sollte aber nicht nur zwischen den Developern, sondern auch mit dem Scrum Master und dem Product Owner immer verbessert werden.
Vielen Dank für deine informativen Videos!
Sehr gerne!
Herausragende Erklärung. Danke Sebastian.
Danke dir Sirko :-)
Gutes Video! Da kommt das vielgesagte Sprichtwort: "SCRUM rückwärts gelesen ergibt MURCS" zur Geltung. Letztlich ist SCRUM nur eine Form der Ausarbeitung eines Projektes. Wie aber ein Projekt definiert wird, steht auf einer anderen Karte. Diese wird oftmals vergessen. Da heißt es in der krassesten Form: "Wir nehmen die Anforderungen in Schriftform auf, da haben wir Spielraum in der Interpretation. Gemeinsames Verstehen mit dem Kunden, gemeinsame Entwicklung von Lösungen via Rapid Prototyping ... das ist uns zu aufwendig."
Hi. Danke. Finde ich eine spanndende Betrachtung. Danke dir 👍
@@SebastianBurkart Finde ich in deiner Playlist Videos zum Aufsetzen von Projekten? Als zentrales Element nutze ich "Project Canvas" in Kombination mit Design Thinking bzw. Sprint Design mit dem Ziel, einen testbaren Prototypen zu entwickeln. Was sind deine ne Ansätze?
Hi. Leider habe ich dazu noch keine Videos. Meine Ansätze sind da ähnlich zu deinen. Design Sprints, Project Canvas, was ich auch oft verwende sind Product Canvases und vor allem Story Maps, damit man eine gute Visualisierung hat, wie der Schnitt ist, wie der Flow usw.
@@SebastianBurkart Ich finde diesen Ansatz auch Klasse. Vor allem daher, dass der Entscheider (sprich der Kunde) in den Entwicklungsprozess von Anfang an ins Boot geholt werden kann. Der Kunde wird zum Partner. Der Vorteil: Man entwickelt keine Lösungen mit tausenden Funktionen, sondern in sich kompatible Module. Der Kunde kann dann die Module in Ihrer Wichtigkeit priorisieren. Letztlich hilft das genau das auch dann in der agilen Umsetzung.
Eine Frage, eigentlich steht im Scrum Guide, dass nur die Developers beim Daily Meeting mitmachen. Warum haben Sie gesagt (wie bei Frage 1 geantwortet), dass der Product Owner dabei sein muss?
Der Scrum Guide sagt zwar, dass nur die Developer daran teilnimmt und der Produkt Owner und der Scrum Master nur, wenn sie an Einträgen des Sprint Backlogs arbeiten, aber meine Erfahrung und die vieler Anderen hat gezeigt, dass es extrem viel Sinn macht, dass der Product Owner daran teilnimmt, da er offene Fragen zu Tickets, Fragen bzgl. der Priorität beantworten kann. Auch sagt der Guide, dass im Daily Scrum auch bei Bedarf das Sprint Backlog angepasst werden kann. Hierfür macht es meiner Meinung nach viel Sinn, den Product Owner direkt mit in der Diskussion zu haben und nicht erst danach zu informieren und dann vielleicht aufgrund weiterer Informationen doch wieder was ändern zu können. Zudem heißt es im Guide auch "Daily Scrums verbessern die Kommunikation". Diese sollte aber nicht nur zwischen den Developern, sondern auch mit dem Scrum Master und dem Product Owner immer verbessert werden.