Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in Hamburg

3,203 views

Published on

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.

Published in: Business

Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in Hamburg

  1. 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. 2. Das agile Unternehmen Pecha Kucha Stefan Roock, JAX 2014 stefan.roock@it-agile.de, Twitter: @StefanRoock
  3. 3. In diesem Vortrag 1. Product Owner- Typen 4. Scrum Master- Typen 5. Drei Horizonte 3. Cross- Funktionalität 2. DoR / DoD
  4. 4. Product Owner Typen Jeff Marty Walter Eric
  5. 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. 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. 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. 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. 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. 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. 11. Weiterentwicklung des Teams Definition of Done t Teamleistetmehr
  12. 12. Weiterentwicklung des Teams Definition of Ready Definition of Done t Teamleistetmehr Teambraucht wenigerVorgaben
  13. 13. Weiterentwicklung des Teams Definition of Ready Definition of Done t Teamleistetmehr Teambraucht wenigerVorgaben Selbstorganisation Walter Marty Jeff, Eric
  14. 14. Minimal Cross- Funktional Scrum in den 1970ern Scrum-Team
  15. 15. Was ist besser?
  16. 16. Lernen/Innovation vs. Auslastung Kosten durch 
 mangelnde Auslastung Gesamtkosten Kosten durch 
 verzögertes Feedback Cross-Funktionalität
  17. 17. Weiterentwicklung des Teams Definition of Ready Definition of Done t Teamleistetmehr Teambraucht wenigerVorgaben Cross-Funktionalität
  18. 18. Scrum Master Tamara Sascha Peter Doreen
  19. 19. Scrum Master Tamara Sascha Peter Doreen • Entscheidet für das Team. • Beseitigt Hindernisse pro-aktiv.
  20. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×