Search

BigScrum - Scaling Teams to Programs

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Notes on slide 1

    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

    Favorites, Groups & Events

    BigScrum - Scaling Teams to Programs - Presentation Transcript

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

    + gmoreingmorein, 3 weeks ago

    custom

    72 views, 0 favs, 0 embeds more stats

    This presentation provides a pattern for scaling sc more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 72
      • 72 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 0
    • Downloads 0
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories

    Tags

    -->
    Search
    RSS Feed
    What's new?

    © 2009 SlideShare Inc. All Rights Reserved