Big Scrum – Team to Program Giora Morein |  [email_address] <ul><li>Co-Founder of BigVisible Solutions </li></ul><ul><li>C...
<ul><li>Project Initiation Roadmap </li></ul><ul><li>Stakeholders </li></ul><ul><li>Program Organizational Model </li></ul...
Initiation Roadmap <ul><li>Activities are  concurrent </li></ul><ul><li>All artifacts are  starting-points </li></ul><ul><...
Stakeholders
Stakeholder Model <ul><li>Goals </li></ul><ul><li>Identify stakeholders and  types </li></ul><ul><li>Define stakeholder  r...
Stakeholder Interaction Level of interaction depends on type of stakeholder Stakeholders High : Daily Med : Weekly Low :  ...
Stakeholder Collaboration Level of collaboration depends on type of stakeholder Stakeholders High : On the Team/Program Me...
Stakeholders Types Create communication/collaboration strategy Stakeholders Interaction Level Collaboration Level low medi...
Educating Stakeholders
Alignment & Education <ul><li>Truth : Agile Programs are Different </li></ul><ul><li>New  principles ,  practices  and  ar...
Example: Stories <ul><li>What are stories? </li></ul><ul><li>Basic planning and building unit of Agile teams </li></ul><ul...
Example: Stories <ul><li>They are different </li></ul><ul><li>Stories are not requirements </li></ul><ul><li>Stories are n...
Example: Reports <ul><li>New Reports and Diagnostics </li></ul><ul><li>Agile reports must support decision-making </li></u...
The Program Model
Program Organization <ul><li>Goals </li></ul><ul><li>Independent  team units </li></ul><ul><li>Distributed backlog  manage...
The Team Each team has a  ScrumMaster SM aka: Team Lead Project Manager The Program Model
The Team Each team has a  product owner SM aka: Customer Business The Voice The Truth PO The Program Model
The Team Each team has it’s own  story backlog BL SM aka: team backlog backlog stories PO The Program Model
The Team Each team plans, sizes, manages and executes its own backlog Team meets daily in “stand-ups” or Scrums BL SM PO T...
Program Coordination BL SM PO BL SM PO BL SM PO BL SM PO Program comprises of multiple teams Team leads meet regularly aka...
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...
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 P...
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...
Product Coordination BL SM PO BL SM PO BL SM PO BL SM PO Product Team prioritizes consolidated Program Backlog Program Bac...
Product Coordination BL SM PO BL SM PO BL SM PO BL SM PO 3 Product Management Models 1.  Top-Down <ul><li>Stories defined ...
Product Coordination BL SM PO BL SM PO BL SM PO BL SM PO 3 Product Management Models 2.  Bottom-up <ul><li>Features and St...
Product Coordination BL SM PO BL SM PO BL SM PO BL SM PO 3 Product Management Models 3.  Hybrid <ul><li>Features  defined ...
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 M...
Scaling Large Programs weekly weekly The Program Model UPO UPO UPO
Technical Coordination BL SM PO BL SM PO BL SM PO BL SM PO Architecture team organized as program support Members of archi...
Distributed Teams
Distributed vs. Virtual We prefer  Distributed  teams not Virtual  Teams Distributed Teams Virtual Team Distributed Team I...
Distributed Scrum Teams <ul><li>Each Team: </li></ul><ul><li>has its own  ScrumMaster </li></ul><ul><li>has its own  Produ...
Anti-Pattern:  Functionally Silod Teams  <ul><li>Each Team: </li></ul><ul><li>Multi-location, multi-team project </li></ul...
Scaling Strategies
2 Fundamental Approaches 1. BIG BANG! How to Scale? 2. Phased Scaling Strategies
Big Bang <ul><li>Extremely Difficult and Inefficient </li></ul><ul><li>Rushed  team selection </li></ul><ul><li>Bigger aud...
Phased <ul><li>Can be rapid or slow phased approach </li></ul><ul><li>1-2 teams  ramped up at a time </li></ul><ul><li>Wid...
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 I...
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 I...
Challenges and  Success Factors
Challenges with Scaling Agile <ul><li>Expect to deal with the following: </li></ul><ul><li>Cross-program  communication  c...
Common Pitfalls <ul><li>Avoid doing this: </li></ul><ul><li>Ramping up  too fast </li></ul><ul><li>Focusing on  standardiz...
Keys to Success <ul><li>Do This: </li></ul><ul><li>Get  strong ScrumMasters  and  Product Owners </li></ul><ul><li>Ensure ...
Upcoming SlideShare
Loading in...5
×

BigScrum - Scaling Teams to Programs

902

Published on

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.

Published in: Technology, Business
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
902
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide
  • 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
  • Transcript of "BigScrum - Scaling Teams to Programs"

    1. 1. Big Scrum – Team to Program Giora Morein | [email_address] <ul><li>Co-Founder of BigVisible Solutions </li></ul><ul><li>Certified Scrum Trainer (CST) </li></ul><ul><li>Agile Coach </li></ul><ul><li>Specialize in ramping up and scaling Agile and Scrum teams. </li></ul>
    2. 2. <ul><li>Project Initiation Roadmap </li></ul><ul><li>Stakeholders </li></ul><ul><li>Program Organizational Model </li></ul><ul><li>Distributed Teams </li></ul><ul><li>Scaling Strategies </li></ul><ul><li>Challenges and Success Factors </li></ul>Agenda
    3. 3. Initiation Roadmap <ul><li>Activities are concurrent </li></ul><ul><li>All artifacts are starting-points </li></ul><ul><li>Anything can be changed </li></ul>Project Initiation Team Formation & Training Initiate Program Iteration 0 Assessment Business Discovery Stakeholder Meetings and Alignment Activity Focus
    4. 4. Stakeholders
    5. 5. Stakeholder Model <ul><li>Goals </li></ul><ul><li>Identify stakeholders and types </li></ul><ul><li>Define stakeholder roles </li></ul><ul><li>Align and educate stakeholders </li></ul><ul><li>Define communication and interaction model </li></ul><ul><li>Define cross-program goals </li></ul><ul><li>Identify success measures </li></ul>Stakeholders
    6. 6. Stakeholder Interaction Level of interaction depends on type of stakeholder Stakeholders High : Daily Med : Weekly Low : Monthly
    7. 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
    8. 8. Stakeholders Types Create communication/collaboration strategy Stakeholders Interaction Level Collaboration Level low medium high low medium high <ul><li>Project Consumers </li></ul>1 3. Visitors & Guests 3 2. Project Implementers 2 4. Project Dependency 4 5. Org. Stakeholders 5
    9. 9. Educating Stakeholders
    10. 10. Alignment & Education <ul><li>Truth : Agile Programs are Different </li></ul><ul><li>New principles , practices and artifacts </li></ul><ul><li>New vocabulary </li></ul><ul><li>Many traditional artifacts disappear </li></ul><ul><li>Education is required </li></ul><ul><li>It takes time to learn </li></ul><ul><li>It takes time to adjust </li></ul><ul><li>Stakeholders will need guidance </li></ul>Educating Stakeholders
    11. 11. Example: Stories <ul><li>What are stories? </li></ul><ul><li>Basic planning and building unit of Agile teams </li></ul><ul><li>Small capability that will provide value </li></ul><ul><li>Avoids implementation details </li></ul><ul><li>Represents invitation to a future conversation </li></ul>Educating Stakeholders As a vacation planner I want to see photos of hotel rooms As a repeat vacation planner I want to rebook a past trip As a user, I want to cancel a reservation
    12. 12. Example: Stories <ul><li>They are different </li></ul><ul><li>Stories are not requirements </li></ul><ul><li>Stories are not tickets </li></ul><ul><li>Stories are not use-cases </li></ul><ul><li>Stories are not a promise </li></ul>Educating Stakeholders As a vacation planner I want to see photos of hotel rooms As a repeat vacation planner I want to rebook a past trip As a user, I want to cancel a reservation
    13. 13. Example: Reports <ul><li>New Reports and Diagnostics </li></ul><ul><li>Agile reports must support decision-making </li></ul><ul><li>Focus on business objectives </li></ul><ul><li>Focus on productivity and completion rates </li></ul><ul><li>Little emphasis on change-reporting </li></ul>Educating Stakeholders
    14. 14. The Program Model
    15. 15. Program Organization <ul><li>Goals </li></ul><ul><li>Independent team units </li></ul><ul><li>Distributed backlog management </li></ul><ul><li>High cross-team communication </li></ul><ul><li>Program-level feature prioritization </li></ul><ul><li>Team-level story prioritization </li></ul>The Program Model
    16. 16. The Team Each team has a ScrumMaster SM aka: Team Lead Project Manager The Program Model
    17. 17. The Team Each team has a product owner SM aka: Customer Business The Voice The Truth PO The Program Model
    18. 18. The Team Each team has it’s own story backlog BL SM aka: team backlog backlog stories PO The Program Model
    19. 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. 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. 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. 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. 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. 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
    25. 25. Product Coordination BL SM PO BL SM PO BL SM PO BL SM PO 3 Product Management Models 1. Top-Down <ul><li>Stories defined in Program Backlog </li></ul><ul><li>Program Backlog split and distributed to teams </li></ul><ul><li>Requires extensive investment in Program Backlog </li></ul><ul><li>Only feasible in homogenous program </li></ul>PBL The Program Model
    26. 26. Product Coordination BL SM PO BL SM PO BL SM PO BL SM PO 3 Product Management Models 2. Bottom-up <ul><li>Features and Stories defined in Team Backlog </li></ul><ul><li>Team feeds Program Backlog </li></ul><ul><li>Typical in more heterogeneous environments </li></ul><ul><li>Difficult to manage program-level priorities </li></ul>PBL The Program Model
    27. 27. Product Coordination BL SM PO BL SM PO BL SM PO BL SM PO 3 Product Management Models 3. Hybrid <ul><li>Features defined and prioritized at program-level </li></ul><ul><li>Stories defined and prioritized at team-level </li></ul><ul><li>Features assigned based on capacity and subject </li></ul><ul><li>Supports complex prioritization </li></ul>PBL The Program Model
    28. 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. 29. Scaling Large Programs weekly weekly The Program Model UPO UPO UPO
    30. 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
    31. 31. Distributed Teams
    32. 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
    33. 33. Distributed Scrum Teams <ul><li>Each Team: </li></ul><ul><li>has its own ScrumMaster </li></ul><ul><li>has its own Product Backlog </li></ul><ul><li>has a dedicated Product Owner </li></ul><ul><li>can plan sprints independently </li></ul><ul><li>can optimize itself </li></ul><ul><li>is co-located </li></ul>STRIVE FOR THIS Distributed Teams
    34. 34. Anti-Pattern: Functionally Silod Teams <ul><li>Each Team: </li></ul><ul><li>Multi-location, multi-team project </li></ul><ul><li>Each location is functionally organized </li></ul><ul><li>Cross-functional teams are virtual </li></ul><ul><li>High dependency across locations </li></ul>AVOID THIS Function 1 (PM) Function 2 (Dev) Function 3 (QA) Function 4 (Vis. Des) location 2 location 4 location 3 location 1 Distributed Teams
    35. 35. Scaling Strategies
    36. 36. 2 Fundamental Approaches 1. BIG BANG! How to Scale? 2. Phased Scaling Strategies
    37. 37. Big Bang <ul><li>Extremely Difficult and Inefficient </li></ul><ul><li>Rushed team selection </li></ul><ul><li>Bigger audience results in poorer training </li></ul><ul><li>No time to establish rhythm </li></ul><ul><li>Little time for coaching and maturation </li></ul><ul><li>Poorer adoption </li></ul><ul><li>Unhappy people </li></ul>AVOID THIS Scaling Strategies
    38. 38. Phased <ul><li>Can be rapid or slow phased approach </li></ul><ul><li>1-2 teams ramped up at a time </li></ul><ul><li>Wider window to find the right people </li></ul><ul><li>Easier to schedule </li></ul><ul><li>Smaller audience being trained </li></ul><ul><li>Easier for program to focus efforts </li></ul><ul><li>Works best with coaching or mentoring </li></ul><ul><li>Better adoption </li></ul><ul><li>Happier people </li></ul>Scaling Strategies
    39. 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. 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. 41. Challenges and Success Factors
    42. 42. Challenges with Scaling Agile <ul><li>Expect to deal with the following: </li></ul><ul><li>Cross-program communication challenges </li></ul><ul><li>Cross-program coordination challenges </li></ul><ul><li>Managing program backlog </li></ul><ul><li>Shared services and resources </li></ul><ul><li>Continuous education </li></ul><ul><li>External forces </li></ul>Challenges and Success Factors
    43. 43. Common Pitfalls <ul><li>Avoid doing this: </li></ul><ul><li>Ramping up too fast </li></ul><ul><li>Focusing on standardization </li></ul><ul><li>Creating conflicts of interest </li></ul><ul><li>Focusing on efficiencies early </li></ul><ul><li>Focusing on effort rather than results </li></ul>Challenges and Success Factors
    44. 44. Keys to Success <ul><li>Do This: </li></ul><ul><li>Get strong ScrumMasters and Product Owners </li></ul><ul><li>Ensure executive support and dedication </li></ul><ul><li>Manage to your bottlenecks </li></ul><ul><li>Continuously examine existing policies and practices </li></ul><ul><li>Think small – even when you’re Big! </li></ul><ul><li>Get guidance </li></ul>Challenges and Success Factors

    ×