Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in Hamburg
•
25 gefällt mir•4,817 views
Der Vortrag zeigt verschiedene Facetten von Scrum und verdeutlicht, dass es nicht die eine richtige Anwendung von Scrum gibt. Die Product Owner-Rolle muss ganz unterschiedlich ausgestaltet werden, abhängig vom Innovationsgrad der Entwicklung. Der Scrum Master muss seinen Führungsstil an die Reife des Teams anpassen. Und die Zusammensetzung des Teams hängt vom Unsicherheitsprofil des Projektes ab.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in Hamburg
Ähnlich wie Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in Hamburg (20)
Mehr von Stefan ROOCK
Mehr von Stefan ROOCK (20)
Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in Hamburg
- 1. Shades of Scrum Was Scrum im Unternehmen alles kann SEACON, Hamburg, 07.05.2015 Urs Reupke, urs.reupke@it-agile.de Stefan Roock, stefan.roock@it-agile.de
- 2. Das agile Unternehmen Pecha Kucha Stefan Roock, JAX 2014 stefan.roock@it-agile.de, Twitter: @StefanRoock
- 3. In diesem Vortrag 1. Product Owner- Typen 4. Scrum Master- Typen 5. Drei Horizonte 3. Cross- Funktionalität 2. DoR / DoD
- 5. Product Owner Typen Jeff Marty Walter Eric • Schreibt gewissenhaft sehr genaue User Stories • Start in den Sprint mit klaren User Stories gemäß Definition of Ready • Wenig Rückfragen der Entwickler während des Sprints (Details in der Regel in den User Stories definiert)
- 6. Product Owner Typen Jeff Marty Walter Eric • Schreibt gewissenhaft sehr genaue User Stories • Start in den Sprint mit klaren User Stories gemäß Definition of Ready • Wenig Rückfragen der Entwickler während des Sprints (Details in der Regel in den User Stories definiert) • Erstellt User Stories; nimmt das Team für die Sprint-Vorbereitung mit in Anspruch • ist im Sprint gut verfügbar • viele Details zu Anforderungen klären Marty und Team noch im Sprint
- 7. Product Owner Typen Jeff Marty Walter Eric • arbeitet als Entwickler im Team mit • Start in den Sprint mit Zielen, nicht mit User Stories • Stories entstehen mitunter im Sprint • Schreibt gewissenhaft sehr genaue User Stories • Start in den Sprint mit klaren User Stories gemäß Definition of Ready • Wenig Rückfragen der Entwickler während des Sprints (Details in der Regel in den User Stories definiert) • Erstellt User Stories; nimmt das Team für die Sprint-Vorbereitung mit in Anspruch • ist im Sprint gut verfügbar • viele Details zu Anforderungen klären Marty und Team noch im Sprint
- 8. Product Owner Typen Jeff Marty Walter Eric • arbeitet als Entwickler im Team mit • Start in den Sprint mit Zielen, nicht mit User Stories • Stories entstehen mitunter im Sprint • Interagiert mit dem Team bei Sprint-Planning und -Review und im Sprint nicht verlässlich schnell erreichbar • Start in den Sprint mit groben Features statt User Stories • Schreibt gewissenhaft sehr genaue User Stories • Start in den Sprint mit klaren User Stories gemäß Definition of Ready • Wenig Rückfragen der Entwickler während des Sprints (Details in der Regel in den User Stories definiert) • Erstellt User Stories; nimmt das Team für die Sprint-Vorbereitung mit in Anspruch • ist im Sprint gut verfügbar • viele Details zu Anforderungen klären Marty und Team noch im Sprint
- 9. Product Owner Typen Jeff Marty Walter Eric Selbstorganisation EntfernungvomTeam • arbeitet als Entwickler im Team mit • Start in den Sprint mit Zielen, nicht mit User Stories • Stories entstehen mitunter im Sprint • Interagiert mit dem Team bei Sprint-Planning und -Review und im Sprint nicht verlässlich schnell erreichbar • Start in den Sprint mit groben Features statt User Stories • Schreibt gewissenhaft sehr genaue User Stories • Start in den Sprint mit klaren User Stories gemäß Definition of Ready • Wenig Rückfragen der Entwickler während des Sprints (Details in der Regel in den User Stories definiert) • Erstellt User Stories; nimmt das Team für die Sprint-Vorbereitung mit in Anspruch • ist im Sprint gut verfügbar • viele Details zu Anforderungen klären Marty und Team noch im Sprint
- 10. Product Owner Typen Jeff Sutherland Marty Cagan Walter Falls Eric Ries Selbstorganisation EntfernungvomTeam Startup Missionskritisch, Fachabteilung als POevtl. Krücke während Transition Weiterentwicklung eines erfolgreichen Produkts
- 11. Weiterentwicklung des Teams Definition of Done t Teamleistetmehr
- 12. Weiterentwicklung des Teams Definition of Ready Definition of Done t Teamleistetmehr Teambraucht wenigerVorgaben
- 13. Weiterentwicklung des Teams Definition of Ready Definition of Done t Teamleistetmehr Teambraucht wenigerVorgaben Selbstorganisation Walter Marty Jeff, Eric
- 14. Minimal Cross- Funktional Scrum in den 1970ern Scrum-Team
- 15. Was ist besser?
- 16. Lernen/Innovation vs. Auslastung Kosten durch mangelnde Auslastung Gesamtkosten Kosten durch verzögertes Feedback Cross-Funktionalität
- 17. Weiterentwicklung des Teams Definition of Ready Definition of Done t Teamleistetmehr Teambraucht wenigerVorgaben Cross-Funktionalität
- 19. Scrum Master Tamara Sascha Peter Doreen • Entscheidet für das Team. • Beseitigt Hindernisse pro-aktiv.
- 20. Scrum Master Tamara Sascha Peter Doreen • Entscheidet für das Team. Erläutert seine Entscheidungen. • Lässt das Team kleinere Entscheidungen selbst treffen. • Bittet manchmal das Team um Unterstützung bei der Hindernis- Beseitigung. • Entscheidet für das Team. • Beseitigt Hindernisse pro-aktiv.
- 21. Scrum Master Tamara Sascha Peter Doreen • Entscheidet für das Team. Erläutert seine Entscheidungen. • Lässt das Team kleinere Entscheidungen selbst treffen. • Bittet manchmal das Team um Unterstützung bei der Hindernis- Beseitigung. • Entscheidet für das Team. • Beseitigt Hindernisse pro-aktiv. • Lässt das Team entscheiden. Behält sich aber Vetorecht vor. • Beseitigt Hindernisse auf Unternehmensebene. • Das Team muss Hindernisse auf Team- Ebene selbst beseitigen.
- 22. Scrum Master Tamara Sascha Peter Doreen • Entscheidet für das Team. Erläutert seine Entscheidungen. • Lässt das Team kleinere Entscheidungen selbst treffen. • Bittet manchmal das Team um Unterstützung bei der Hindernis- Beseitigung. • Entscheidet für das Team. • Beseitigt Hindernisse pro-aktiv. • Lässt das Team entscheiden. Behält sich aber Vetorecht vor. • Beseitigt Hindernisse auf Unternehmensebene. • Das Team muss Hindernisse auf Team- Ebene selbst beseitigen. • Hält dem Team den Spiegel vor. • Lässt das Team alles selbst entscheiden. • Beseitigt kaum Hindernisse.
- 23. Scrum Master und Situational Leadership Tamara Sascha Peter Doreen • Entscheidet für das Team. Erläutert seine Entscheidungen. • Lässt das Team kleinere Entscheidungen selbst treffen. • Bittet manchmal das Team um Unterstützung bei der Hindernis- Beseitigung. • Entscheidet für das Team. • Beseitigt Hindernisse pro-aktiv. • Lässt das Team entscheiden. Behält sich aber Vetorecht vor. • Beseitigt Hindernisse auf Unternehmensebene. • Das Team muss Hindernisse auf Team- Ebene selbst beseitigen. • Hält dem Team den Spiegel vor. • Lässt das Team alles selbst entscheiden. • Beseitigt kaum Hindernisse. unfähig unsicher fähig sicher
- 24. Scrum Master und Situational Leadership Tamara Sascha Peter Doreen • Entscheidet für das Team. Erläutert seine Entscheidungen. • Lässt das Team kleinere Entscheidungen selbst treffen. • Bittet manchmal das Team um Unterstützung bei der Hindernis- Beseitigung. • Entscheidet für das Team. • Beseitigt Hindernisse pro-aktiv. • Lässt das Team entscheiden. Behält sich aber Vetorecht vor. • Beseitigt Hindernisse auf Unternehmensebene. • Das Team muss Hindernisse auf Team- Ebene selbst beseitigen. • Hält dem Team den Spiegel vor. • Lässt das Team alles selbst entscheiden. • Beseitigt kaum Hindernisse. unfähig unsicher fähig sicher Delegating Participating Selling Telling
- 25. 3-Horizonte-Modell Horizont 1 (heute) t € Horizont 2 (12-24 Monate) Horizont 3 (18-36 Monate) Optionen sichern mit geringem Aufwand und wenig Geld Validierte Geschäftsmodelle in Horizont 1 überführen Das laufende Geschäft (finanziert Horizonte 2 und 3)
- 26. 3-Horizonte-Modell Horizont 1 (heute) t € Horizont 2 (12-24 Monate) Horizont 3 (18-36 Monate) Optionen sichern mit geringem Aufwand und wenig Geld Validierte Geschäftsmodelle in Horizont 1 überführen Das laufende Geschäft (finanziert Horizonte 2 und 3) Marty Jeff Eric
- 27. 3-Horizonte-Modell Horizont 1 (heute) t € Horizont 2 (12-24 Monate) Horizont 3 (18-36 Monate) Optionen sichern mit geringem Aufwand und wenig Geld Validierte Geschäftsmodelle in Horizont 1 überführen Das laufende Geschäft (finanziert Horizonte 2 und 3) C ross-Funktionalität
- 28. 3-Horizonte-Modell Horizont 1 (heute) t € Horizont 2 (12-24 Monate) Horizont 3 (18-36 Monate) Optionen sichern mit geringem Aufwand und wenig Geld Validierte Geschäftsmodelle in Horizont 1 überführen Das laufende Geschäft (finanziert Horizonte 2 und 3) Doreen (Delegating) Peter (Participating)
- 29. Im Überblick Horizont 1 Horizont 2 Horizont 3 Marty Jeff Eric Cross-Funktionalität Laufendes Geschäft Neues Produkt/ Geschäft Optionen schaffen/ sichern Doreen (Delegating) Peter (Participating) Scrum und Kanban Scrum Scrum und Lean Startup
- 30. Danke für die Aufmerksamkeit Stefan Roock stefan.roock@it-agile.de Twitter: @StefanRoock Urs Reupke urs.reupke@it-agile.de Agil auf allen Ebenen