Distributed agile- exec level briefing

Editor's Notes

• #3: 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.
• #4: 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.
• #5: 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.
• #6: 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.
• #10: 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.