BigScrum - Scaling Teams to Programs
•
10 j'aime•927 vues
This presentation provides a pattern for scaling scrum teams to programs as well as provides some guidance for kicking off larger programs, dealing with program stakeholders as well explores scaling alternatives.
![Big Scrum – Team to Program Giora Morein | [email_address] ,[object Object],[object Object],[object Object],[object Object]](https://image.slidesharecdn.com/bigvisible-bigscrum-091105192647-phpapp01/85/bigscrum-scaling-teams-to-programs-1-320.jpg)
![[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Agenda](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à BigScrum - Scaling Teams to Programs
Similaire à BigScrum - Scaling Teams to Programs (20)
Plus de ThinkLouder
Plus de ThinkLouder (12)
Dernier
Dernier (20)
BigScrum - Scaling Teams to Programs
- 4. Stakeholders
- 6. Stakeholder Interaction Level of interaction depends on type of stakeholder Stakeholders High : Daily Med : Weekly Low : Monthly
- 7. Stakeholder Collaboration Level of collaboration depends on type of stakeholder Stakeholders High : On the Team/Program Med : Extended Team/Program Low : External to the Team
- 16. The Team Each team has a ScrumMaster SM aka: Team Lead Project Manager The Program Model
- 17. The Team Each team has a product owner SM aka: Customer Business The Voice The Truth PO The Program Model
- 18. The Team Each team has it’s own story backlog BL SM aka: team backlog backlog stories PO The Program Model
- 19. The Team Each team plans, sizes, manages and executes its own backlog Team meets daily in “stand-ups” or Scrums BL SM PO The Program Model
- 20. Program Coordination BL SM PO BL SM PO BL SM PO BL SM PO Program comprises of multiple teams Team leads meet regularly aka : Scrum-of-Scrums daily SM SM SM SM The Program Model
- 21. Program Coordination BL SM PO BL SM PO BL SM PO BL SM PO Program is led by Program Manager or : Uber ScrumMaster daily SM SM SM SM The Program Model
- 22. Product Coordination BL SM PO BL SM PO BL SM PO BL SM PO Product team leads meet regularly aka : Meta-Scrum daily PO PO PO PO The Program Model
- 23. Product Coordination BL SM PO BL SM PO BL SM PO BL SM PO Product Team is led by Product Director or : Chief Product Owner daily PO PO PO PO UPO The Program Model
- 24. Product Coordination BL SM PO BL SM PO BL SM PO BL SM PO Product Team prioritizes consolidated Program Backlog Program Backlog divided into team Backlogs PBL PO PO PO PO UPO The Program Model
- 28. Support Teams BL SM PO BL SM PO BL SM PO BL SM PO PBL PO PO PO PO UPO SM SM SM SM A A A Architects DBA’s D D The Program Model Infrastructure I I I
- 29. Scaling Large Programs weekly weekly The Program Model UPO UPO UPO
- 30. Technical Coordination BL SM PO BL SM PO BL SM PO BL SM PO Architecture team organized as program support Members of architecture team participate in functional teams Responsible for defining standards, technical debt strategy, code ownership, high-level design etc. Provide technical guidance and advice The Program Model A A A A A A A A
- 32. Distributed vs. Virtual We prefer Distributed teams not Virtual Teams Distributed Teams Virtual Team Distributed Team Individuals in multiple remote locations Individuals co-located in different locations Never collaborate in person, regardless of location Individuals collaborate in-person with others in same location. Teams communicate virtually across locations Extremely high levels of geographic dependencies Lower levels of geographic dependencies
- 36. 2 Fundamental Approaches 1. BIG BANG! How to Scale? 2. Phased Scaling Strategies
- 39. Example of Rapid Phase Model Scaling Strategies Mgt 1 2 3 4 5 6 7 8 Training, Stories and Setup Team 1 9 10 11 12 Team 1 Iteration 1 Team 1 Iteration 2 Team 1 Iteration 3 Training, Stories and Setup Team 2 Team 2 Iteration 1 Team 2 Iteration 2 Team 2 Iteration 3 Training, Stories and Setup Team 3 Team 3 Iteration 1 Team 3 Iteration 2 Team 3 Iteration 3 Training, Stories and Setup Team 4 Team 4 Iteration 1 Team 4 Iteration 2 Team 4 Iteration 3 Training, Stories and Setup Team 5 Team 5 Iteration 1 Team 5 Iteration 2 Training, Stories and Setup Team 6 Team 6 Iteration 1 Team 6 Iteration 2
- 40. Example of Rapid Phase Model Scaling Strategies Mgt 1 2 3 4 5 6 7 8 Training, Stories and Setup Team 1 9 10 11 12 Team 1 Iteration 1 Team 1 Iteration 2 Team 1 Iteration 3 Training, Stories and Setup Team 2 Team 2 Iteration 1 Team 2 Iteration 2 Team 2 Iteration 3 Training, Stories and Setup Team 3 Team 3 Iteration 1 Team 3 Iteration 2 Team 3 Iteration 3 Training, Stories and Setup Team 4 Team 4 Iteration 1 Team 4 Iteration 2 Team 4 Iteration 3 Training, Stories and Setup Team 5 Team 5 Iteration 1 Team 5 Iteration 2 Training, Stories and Setup Team 6 Team 6 Iteration 1 Team 6 Iteration 2
- 41. Challenges and Success Factors
Notes de l'éditeur
- Example of a 4-week Project initiation roadmap. Day 1 to Iteration 1. Things that happen during the project setup phase. (we will not spend too much time on all these areas, but rather focus on the program setup, organization and stakeholder involvement). Length of your project ramp-up may be different Activities are not serial – there are very few dependencies. We strive to relegate dependencies to be finish-to-finish dependencies.
- Identify the various stakeholders and determine the type of stakeholder (stakeholder types impact the level of interaction and collaboration with the project team. more about stakeholder types later.) Define the stakeholder role on the project how they will interact with the project team Alignment, support and buy-in is extremely important. Educating stakeholders about Agile is important. Particularly if stakeholders are new to Agile and Scrum. Align stakeholders around program goals. It is important that program goals are derived from the overall program and project vision, and that these goals are always within the line of sight. The should be concrete and avoid abstraction. Define success measures. You probably will want to include some success measures at the process adoption level.
- Examples: sales people, support teams, operations teams, release management, legal, compliance etc.
- Basic planning and building unit of Agile teams Small feature that when implemented will provide value Avoids implementation details Represents invitation to a future conversation
- Basic planning and building unit of Agile teams Small feature that when implemented will provide value Avoids implementation details Represents invitation to a future conversation
- New set of Reports and Diagnostics Focus on business-objectives Reports must support decision-making Focus on productivity and work completion rates Little emphasis on change-reporting
- ScrumMaster or Team Lead or Agile Project Manager Primarily a leadership role Partners with Product Owner to define product backlog Responsible for removing impediments Responsible for progress reporting
- Product Owner Determines what the team builds Responsible for prioritization Trade-off decision-maker Defines product functionality Domain expert
- Size work Identify iteration tasks Estimate task effort Develop quality product Communicate progress and issues
- 3 models (coming up on next slides): Top Down – Program Backlog is split into multiple-team backlogs. Stories are defined at the Program Backlog level and then distributed to each team. This is only feasible for homogenous teams building similar capability using the same technology. Bottom-Up – Features and stories are defined at the team level by product owners which then feed the overall program backlog. Typical in more heterogeneous environments where each team and product owner specialize either in different technology or different domain area. Difficult to manage program-level priorities and goals Hybrid – Most common. Features or epics are defined at the program level, typically with participation of all product owners. Features are prioritized in the program backlog and then distributed to each team backlog. The team product owner and the team define, size and prioritize individual stories.
- Bottom-Up – Features and stories are defined at the team level by product owners which then feed the overall program backlog. Typical in more heterogeneous environments where each team and product owner specialize
- Bottom-Up – Features and stories are defined at the team level by product owners which then feed the overall program backlog. Typical in more heterogeneous environments where each team and product owner specialize either in different technology or different domain area. Difficult to manage program-level priorities and goals
- Hybrid – Most common. Features or epics are defined at the program level, typically with participation of all product owners. Features are prioritized in the program backlog and then distributed to each team backlog. The team product owner and the team define, size and prioritize individual stories either in different technology or different domain area. Difficult to manage program-level priorities and goals
- Becomes a program of programs The bigger it gets, the more complex it gets
- GS
- GS 1) Program members who are responsible for delivering product. Generally these people are largely dedicated to the program
- GS Too much, Too fast Avoid unless unavoidable (business and timing constraints)
- GS Many more benefits: Team empowerment Team maturation Team adoption of principles Better adoption of practices Better team formulation Faster time to delivering value More efficient
- Many more benefits: Team empowerment Team maturation Team adoption of principles Better adoption of practices Better team formulation Faster time to delivering value More efficient
- Many more benefits: Team empowerment Team maturation Team adoption of principles Better adoption of practices Better team formulation Faster time to delivering value More efficient
- GS
- GS Communication – avoiding teams putting up walls, working together, collaborating. No “My job” vs. “Your Job” – replace with “Our Job” 2) Coordination – sometimes Team A is working on something that is dependent on Team B except this is not the highest priority for Team B. Scheduling, etc. Simple scheduling practices and coordinate release planning workshops help overcome this challenge. 3) Ensuring the “Product Vision” is validated, shared, broadly communicated, and changes are communicated. Ensure that release planning has resulted in a meaningful increment in support of that Vision 4) Shared services can be approached using the engagement pattern (program-level (providing stories/guidance) and team/iteration-level (providing team guidance) involvement ) 5) New people come on board that need training. Ongoing training and education will be needed with different foci (e.g. intro vs specialized practices) 6) Production support, Compliance, Functional managers etc
- GS 1) Ramping up too fast can result in missing the important fundamental principles 2) There really are no true benefits of standardization, other than ensuring that at a high level the guidance and support teams receive is fairly consistent. “ Crawl, walk, run” is a common learning approach in organizations like the military and others…it has developed over time, and works. An incremental, staggered approach allows multiple teams to go through this learning process effectively. Team 1: Crawl Walk Run Team 2: Crawl Walk Run Team 3: Crawl Walk Run As teams reach the “run” maturity level then coaching effort tends to decrease. 4) Focus on productivity. Examine efficiency once you have reached maturity 3) Conflicts of interest when between those who report organizationally and those who report form project perspective and their bosses
- Bigness often gets in the way – think of ways to minitiarize