Exec Level Briefing on Distributed Agile Practice
•Transferir como PPTX, PDF•
2 gostaram•330 visualizações
Ravi Tadwalkar's PoV on SAFe in geographically distributed organizations
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Exec Level Briefing on Distributed Agile Practice
Semelhante a Exec Level Briefing on Distributed Agile Practice (20)
Mais de Ravi Tadwalkar
Mais de Ravi Tadwalkar (18)
Último
Último (18)
Exec Level Briefing on Distributed Agile Practice
- 1. Distributed Agile Practice- Exec Level Briefing Ravi Tadwalkar’s Point of View
- 2. Distributed Teams – Key Principles Among SAFe and Scrum principles, there are three key principles that Distributed Teams focus on: 1. Close, daily cooperation between business people and developers 2. Principle: Apply cadence and synchronize teams 3. Build incrementally with fast, integrated learning cycles Adapt and apply SAFe practices to distributed teams
- 3. Principle: Close, daily cooperation between business people and developers Co-located Distributed Team Partially- dispersed Distributed Team Fully-dispersed Distributed Team Recommended Distributed Team Structure • Co-located Product Owner, Technical Lead, Scrum Master, and team • Optionally, use Lead Developer as interface between Distributed Team and on-site ART Alternate Partially-dispersed Distributed Team Structure • Co-located Product Owner, Technical Lead, Scrum Master, and partial team • Some members may reside onshore Not recommended
- 4. Principle: Apply cadence, synchronize teams Distributed Team operated in the same cadence as ART Synchronize onshore/offshore Team and ART ceremonies Common Program and Team Backlogs 1. Pre-PI Planning 2. PI Planning 1. Distributed Scrum Team Ceremonies 2. Scrum of Scrums (SoS) & Program Increment level Ceremonies 1. Common Program Backlog of features 2. Team Backlog of user stories 3. Team PI Objectives that align and rollup to Program PI Objectives
- 5. Pre-PI Planning process encompasses the below key steps: T-6 Week T-5 Week T-4 Week T-3 Week T-2 Week T-1 Week Goals/Objectives for PI, Capabilities to Achieve PI Goal and Feature refinement • Acceptance criteria • Product Management review T = PI Planning Product Management input • Product requirements • Product Management review • Multiple grooming sessions • User story maturity rating User Story Build-out & Refinement by Scrum Teams Milestone: product plan reviews with key Leads Draft a PI Plan • PI Capacity • Story Allocation to sprints Offshore Team only
- 6. Time Meeting Participant s Expectation Tel Aviv El Segundo (PDT) Tuesday 9am- 5pm Monday PI Planning Day 1 Tel Aviv Scrum Teams 1. Review Features (Business and Enablers) 2. Review user stories, functional and non-functional acceptance criteria 3. Conduct User Story Maturity Rating 4. Create Dependencies objects in Agile Craft 5. Record assumptions 6. Record risks and mitigation plan 7. Asks Tuesday 5pm- 6pm Tuesday 7am-8am PI Planning Day 1 Sync Dev Leads, RTE, Scrum Masters and Pos Communicate: 1. Features (Business and Enablers) 2. User stories, functional and non-functional acceptance criteria 3. Dependencies 4. Assumptions 5. Risks and mitigation plan 6. Asks Wednesday 9am-5pm Wednesday 8am – 2pm PI Planning Day 2 Tel Aviv Scrum Teams 1. Document velocity for sprints 1-5 2. Plan features and stories for sprints 1-5 3. Record Team PI Objectives 4. Record assumptions 5. Record risks and mitigation plan 6. Asks Wednesday 5pm-6pm Wednesday 7am-8am PI Planning Day 2 Sync Dev Leads, RTE, Scrum Masters and Pos Communicate: 1. Present velocity for sprints 1-5 2. Present features and stories for sprints 1-5 3. Present Team PI Objectives 4. Present assumptions 5. Present risks and mitigation plan 6. Asks Thursday Midnight – 1AM Wednesday 2pm – 3pm PI Planning Day 2 Readout Dev Leads, RTE, Scrum Masters and POs Communicates: 1. Present changes to team PI Objectives 2. Present changes to PI Scope (features and stories) 3. Confirm Assumptions 4. Confirm Risks and mitigation plan 5. Asks El Segundo PI Planning Days: Tuesday and Wednesday every 10 weeks PI Planning for Distributed Team • In lieu of face-to-face PI Planning, Distributed Team prepares PI Plan two-days prior to onsite PI Planning event. • Set clear expectation, meeting time and list of participants for these “Distributed Team PI Planning” days. • Setup “PI Planning Day X Sync” meetings to align outcomes from previous ART PI Planning day. Sample PI Planning for Tel Aviv Team
- 7. Scrum Ceremonies: Plan and publish your Distributed/Onsite Scrum Ceremonies and SoS Monday Tuesday Wednesday Thursday Friday (T-5d) Planning Part I: Grooming session with the team and PO on user stories maturity ranked (T-1d) Final prioritized list of user stories identified and ready in JIRA with maturity ranked and estimated Day 1 (T) Start of Sprint • S: Planning Part II – Capacity Planning • S: Set up Jira stories and estimation Day 2 (T+1d) • S: (by 10:30AM PDT) Documented Daily Scrums (onshore and offshore) • P: Dev/QA Post Scrum Day 3 (T+2d) • S: (by 10:30AM PDT) Documented Daily Scrums (onshore and offshore) • S: Final Test Cases Id • S: Scrum of Scrums (RTE, Proxy RTE, Scrum Masters) (7:30AM) Day 4 (T+3d) • S: (by 10:30AM PDT) Documented Daily Scrums (onshore and offshore) • S: Mid Sprint Review Day 5 (T+4d) • S: (by 10:30AM PDT) Documented Daily Scrums (onshore and offshore) • S: Scrum of Scrums (RTE, Proxy RTE, Scrum Masters) (7:30AM) Day 6 (T+5d) • S: (by 10:30AM PDT) Documented Daily Scrums (onshore and offshore) • Backlog Refinement (Recorded story review, pre- estimation, slotting) Day 7 (T+6d) • S: (by 10:30AM PDT) Documented Daily Scrums (onshore and offshore) • 60% of user stories delivered to test team • Recorded Tech Review for upcoming stories. Day 8 (T+7d) • S: Scrum of Scrums (RTE, Proxy RTE, Scrum Masters) (7:30AM) • S: (by 10:30AM PDT) Documented Daily Scrums (onshore and offshore) Day 9 (T+8d) S: (by 10:30AM PDT) Documented Daily Scrums (onshore and offshore) • User Stories Complete • Final sprint review with PO and architects Day 10 (T+9d) • S: Scrum of Scrums (RTE, Proxy RTE, Scrum Masters) (7:30AM) • S: Retrospective • S: Sprint Review/Demo • S: Recorded Sprint Review/Demo S = Full onshore and offshore Together P = Partial onshore and offshore team together > Offset teams by one day
- 8. Time Titans (Vietnam) Mirosoft-2 (Tel Aviv) Microsoft-3 (New Jersey) Android 3 (Tel Aviv) Aviato (El Segundo + Tel Aviv) Miracle Workers (Tel Aviv) Roku 1 (Tampa) Roku 2 (Tampa)El Segund o (PDT) Tampa/ NJ (EDT) Tel Aviv Vietnam 7:30 -- 18:30 -- -- -- -- -- SU -- -- -- 7:00 10:00 18:00 20:00 SOS SOS SOS SOS SOS SOS SOS SOS 7:30 10:30 18:30 20:30 Retro (T) Retro (T) Retro (T) Retro (T) Retro (T) Retro (T) Retro (T) Retro (T) 8:00 11:00 19:00 21:00 Demo (T10) Demo (T10) Demo (T10) Demo (T10) Demo (T10) Demo (T10) Demo (T10) Demo (T10) SU: Daily Standup SOS: Scrum of Scrums Retro: Retrospective Demo: (Recorded) Note: This slide covers meetings attended by teams in different locations. Scrum Ceremonies: Plan and publish time of meetings that accommodate everyone
- 9. Principle: Build incrementally with fast, integrated learning cycles Distributed Team(s) operate in the same eco-system as any other team. They use common set of tools across all teams They Build and Test incrementally ALM: Jira, AgileCraft Collaboration: HipChat, Confluence Code Quality/ Unit Test: Junit, SonarQube Test Automation: LISA, Jmeter, Selenium Build Tools and Repo : Maven, Nexus Test management: Qmetry CI/CD Orchestration: Jenkins Monitoring and Log: AppDynamics, Splunk Security: Fortify NOTE : Tools are very specific to this case study
- 10. • Distributed Agile Teams’ success is all about giving & getting feedback across stakeholders in the ART value stream – in timely manner! • Distributed Agile doesn't come in one box.. It’s a journey with goals! • Distributed Agile is more than tooling .. It involves improvising our ways of working, process, and culture! 10 Summary
- 11. Thank you
Notas do Editor
- Animation/ Interactivity Notes: Voice Over Script: Principle #1 – Take an Economic View - SAFe is about delivering value to the customer on a frequent basis. Thus Taking An Economic View means all activities should be driven by business value. This is carried out in many areas of the enterprise, including: Portfolio Level, where value streams are funded and agile release trains (ARTs) are assigned according to the enterprise’s strategic themes Value Stream/Program Levels, where capabilities/features are sized and prioritized according to business value (opportunity, time-to-market, effort) Program Increment or PI provides a mechanism for the entire ART to deliver features, resulting in a solution that can be delivered to the customer Architectural Runway, where technical enablers are designed/implemented just-in-time -- as required by the upcoming PI -- thereby avoiding non-essential research/development efforts Team Level, where user stories are taken into a sprint according to the features in the current PI. Hence development work is aligned with feature benefits. A good example of this is when Product Management identifies its minimum-viable product (MVP) for each program increment (PI). Thus the teams are continually delivering working code for essential features, resulting in a solution that could be released to the customer if the business chooses to do so. In contrast, focusing on features that aren’t part of the MVP (minimum-viable product) may not be taking an economic view since it could involve non-essential work (e.g., nice-to-haves or even gold plating). A – Potentially Shippable Product – a functional solution, built from the code produced by the teams in each of their sprints. It may be missing some key business features (e.g. trick play) or technical enablers (e.g. DRM), however the solution could be shipped via the release team for customer feedback should the business choose to do so. B – Shippable Product – a functional solution that meets the MVP requirements and can be shipped via the release team. C – Final Product – a functional solution that meets all the requirements specified by product management for the PI’s.
- Animation/ Interactivity Notes: Voice Over Script: Principle #1 – Take an Economic View - SAFe is about delivering value to the customer on a frequent basis. Thus Taking An Economic View means all activities should be driven by business value. This is carried out in many areas of the enterprise, including: Portfolio Level, where value streams are funded and agile release trains (ARTs) are assigned according to the enterprise’s strategic themes Value Stream/Program Levels, where capabilities/features are sized and prioritized according to business value (opportunity, time-to-market, effort) Program Increment or PI provides a mechanism for the entire ART to deliver features, resulting in a solution that can be delivered to the customer Architectural Runway, where technical enablers are designed/implemented just-in-time -- as required by the upcoming PI -- thereby avoiding non-essential research/development efforts Team Level, where user stories are taken into a sprint according to the features in the current PI. Hence development work is aligned with feature benefits. A good example of this is when Product Management identifies its minimum-viable product (MVP) for each program increment (PI). Thus the teams are continually delivering working code for essential features, resulting in a solution that could be released to the customer if the business chooses to do so. In contrast, focusing on features that aren’t part of the MVP (minimum-viable product) may not be taking an economic view since it could involve non-essential work (e.g., nice-to-haves or even gold plating). A – Potentially Shippable Product – a functional solution, built from the code produced by the teams in each of their sprints. It may be missing some key business features (e.g. trick play) or technical enablers (e.g. DRM), however the solution could be shipped via the release team for customer feedback should the business choose to do so. B – Shippable Product – a functional solution that meets the MVP requirements and can be shipped via the release team. C – Final Product – a functional solution that meets all the requirements specified by product management for the PI’s.
- Animation/ Interactivity Notes: Voice Over Script: Principle #1 – Take an Economic View - SAFe is about delivering value to the customer on a frequent basis. Thus Taking An Economic View means all activities should be driven by business value. This is carried out in many areas of the enterprise, including: Portfolio Level, where value streams are funded and agile release trains (ARTs) are assigned according to the enterprise’s strategic themes Value Stream/Program Levels, where capabilities/features are sized and prioritized according to business value (opportunity, time-to-market, effort) Program Increment or PI provides a mechanism for the entire ART to deliver features, resulting in a solution that can be delivered to the customer Architectural Runway, where technical enablers are designed/implemented just-in-time -- as required by the upcoming PI -- thereby avoiding non-essential research/development efforts Team Level, where user stories are taken into a sprint according to the features in the current PI. Hence development work is aligned with feature benefits. A good example of this is when Product Management identifies its minimum-viable product (MVP) for each program increment (PI). Thus the teams are continually delivering working code for essential features, resulting in a solution that could be released to the customer if the business chooses to do so. In contrast, focusing on features that aren’t part of the MVP (minimum-viable product) may not be taking an economic view since it could involve non-essential work (e.g., nice-to-haves or even gold plating). A – Potentially Shippable Product – a functional solution, built from the code produced by the teams in each of their sprints. It may be missing some key business features (e.g. trick play) or technical enablers (e.g. DRM), however the solution could be shipped via the release team for customer feedback should the business choose to do so. B – Shippable Product – a functional solution that meets the MVP requirements and can be shipped via the release team. C – Final Product – a functional solution that meets all the requirements specified by product management for the PI’s.
- In order to ensure the PI planning event is productive for all teams, DFW has implemented a Pre-PI planning process that starts 6 weeks before the Planned PI event. The process of Pre-PI planning at DFW starts with establishing Goals/Objectives for the PI with supporting features and relevant acceptance criteria. This is typically aligned upon by product management and architectural leadership as based on product objectives there is typically engineering groundwork that needs to happen first to enable those goals. This is what is called “Architecture” and “Enabler” features in the timeline which are specified concurrently to the above business goals. Since there are a lot of suppliers involved with the DFW architecture, supplier input is needed ahead of time with specifying what is needed from them from a PI perspective. This typically happens 5 weeks before the PI event. Once the capabilities have been refined and agreed upon by management, these are shared with all the Scrum teams and RTEs for allocation of work on respective trains. Based upon these requirements Scrum teams do an initial SWAG of the features sizes ensuring that they can be accomplished within a PI and then stack rank them from a priority and logical sequence perspective. While the previous activity is happening the PO/TPO/Architect for the scrum teams starts to build out all the user stories with detailed acceptance criteria to support required Features for the PI. This activity lasts for 3 weeks and runs through to the PI planning event. After the first week, the suppliers (both internal and external) need to start to review their plans with affected Scrum teams so that both sides know what to expect for the upcoming 10 week increment. This activity culminates with a supplier plan review and readout to key leads on the trains before the PI planning event. Note for the above user story build out and refinement activity by Scrum teams, this activity may involve multiple grooming sessions with all members of the Scrum teams and giving feedback to the PO/TPO/Architect on immature stories via a rating process and helping with gaps in acceptance criteria and/or proper sequence of activities. Once the above activities are complete the trains are now ready for the PI planning event.
- Animation/ Interactivity Notes: Voice Over Script: Principle #1 – Take an Economic View - SAFe is about delivering value to the customer on a frequent basis. Thus Taking An Economic View means all activities should be driven by business value. This is carried out in many areas of the enterprise, including: Portfolio Level, where value streams are funded and agile release trains (ARTs) are assigned according to the enterprise’s strategic themes Value Stream/Program Levels, where capabilities/features are sized and prioritized according to business value (opportunity, time-to-market, effort) Program Increment or PI provides a mechanism for the entire ART to deliver features, resulting in a solution that can be delivered to the customer Architectural Runway, where technical enablers are designed/implemented just-in-time -- as required by the upcoming PI -- thereby avoiding non-essential research/development efforts Team Level, where user stories are taken into a sprint according to the features in the current PI. Hence development work is aligned with feature benefits. A good example of this is when Product Management identifies its minimum-viable product (MVP) for each program increment (PI). Thus the teams are continually delivering working code for essential features, resulting in a solution that could be released to the customer if the business chooses to do so. In contrast, focusing on features that aren’t part of the MVP (minimum-viable product) may not be taking an economic view since it could involve non-essential work (e.g., nice-to-haves or even gold plating). A – Potentially Shippable Product – a functional solution, built from the code produced by the teams in each of their sprints. It may be missing some key business features (e.g. trick play) or technical enablers (e.g. DRM), however the solution could be shipped via the release team for customer feedback should the business choose to do so. B – Shippable Product – a functional solution that meets the MVP requirements and can be shipped via the release team. C – Final Product – a functional solution that meets all the requirements specified by product management for the PI’s.