Vintage Agile Delivery Framework for Legacy Products Version 0.7 Dec 30, 2014

Revision History Revision

Date

Revision Comments

Revision Author

0.1

4/17/2014 Initial draft

Neal Hooper

0.2

4/24/2014 Incorporating feedback from Galapagos stakeholders

Neal Hooper

0.3

4/27/2014 with ADF

0.4

5/2/2014 Added Automation and continual system test wording Julie Urban

0.5

5/19/2014 Updated lifecycle diagram

0.6

7/11/2014 Checklist in ADF.

0.7

12/30/2014 team” and “Beta1” as optional terminology.

Suggested new name for process and replaced APF

Sue McKinney

Neal Hooper

Added Release QA role and highlighted Agile Readiness Julie Urban

Added Release Architect Role. Added “hardening

Neal Hooper

Overview The Vintage Agile Delivery Framework (VADF) for Legacy Products is a set of product release processes that utilizes agile best practices. The framework is intended to be an evolution of the Product Delivery Framework (PDF) and should be used to drive product development. The framework guides software development through the use of a defined infrastructure of roles and responsibilities, processes, milestones, and artifacts. The VADF replaces previous versions of the Product Delivery Framework. The objectives of the VADF are to: - Provide a standard minimal framework for project execution, while empowering product delivery teams to own their specific implementation(s) and incorporate standard terminology and best practices into our software development methodology to ensure clarity of work, consistency in execution, and schedule agility.

Applicability The VADF should be adopted by large-scale projects that have: - operated with a waterfall-based methodology. - determined a pure agile adoption is not practical. - determined the feasibility of a methodology transition would be beneficial to project performance and not impact project risks.

Projects appropriate for the VADF should meet the following criteria: - Involve a project duration that is appropriate to complete all agile milestones - Establish and maintain representation of all primary roles defined throughout the project - Include content that can be managed in an iterative fashion with meaningful market deliverables for each release requirement - Minimize any extended period of hardening at the end of a release cycle (e.g., beta programs, regression testing, performance and persistence testing) - Automate unit, component, and functional tests for new code - Maintain continuous integration with all teams operating in a single code trunk that is continuously regression tested - Involve legacy product maintenance or enhancement. VADF is not intended for new product development – ADF should be used instead - More…

Vintage Agile Delivery Framework Elements The VADF includes 4 key infrastructure elements: 1. Roles and Responsibilities, 2. Processes, 3. Milestones, and 4. Artifacts 1. Roles and Responsibilities Roles and responsibilities are defined in the agile framework to include primary roles that participate in the execution of processes. These roles are mandatory for project execution to ensure cross-functional participation and effective turnaround. Roles defined are considered to be leaderless where all participants have an equal voice and responsibility in the project outcomes. All roles are to be performed with clear boundaries as documented below.

Primary Team Roles Stakeholder Provides input into the product business and customer objectives, representing their specific subject matter. Suggested stakeholders include… Tech Support Lead Provides Tech Support input during release and sprint planning sessions. Organizes Tech Support participation during demos and TOIs. InfoDev Lead Defines and drives the documentation strategy. Coordinates the work of Technical Writers in the Delivery Team. Localization Lead Defines and drives localization activities including translating strings and testing translated versions of the product. Beta Program and Plans and executes the Beta program IT Pilot Lead (aka Plans and manages the rollout of Alpha, Beta and RTM Customer One Lead) product builds to Symantec-internal production systems. Executive Sponsor

Establishes advocacy and prioritization for the project amongst leadership teams and across teams and/or businesses. Facilitates the resolution of team roadblocks and drives continuous improvements to overall processes.

Provides air-cover for team. Provides final direction on topics that are unresolved. Participates in demos. Product Manager Defines the business need, strategy, and prioritization of requirements through documented artifacts informed by customer intelligence. Ensures the Delivery Team fully understands the ‘what’ and the ‘why’. Owns the Product Roadmap. Identifies consulting customers for each epic user story. Product Owner Assesses product opportunities. Defines the problem from the customer and user point of view. Owns/Facilitates the creation and prioritization of Product and Release Backlog. Holds Release Reflections. Checks the team delivers the solution completely. Connects team with customers for feedback. Can be one to many scrum team relationship. Discovery Team Responsible for continuous innovation during a release. Conducts research and troubleshooting to enable problem solving and improved product quality. Consists of Product Owner, UX Developer, and Architect. Works ahead of the Delivery Team sprints. UX Developer Collaborates to define UX high-level designs for Delivery Team. Member of the Discovery Team working one or two sprints ahead of the Delivery Team. Product Owner (see above) Architect

Insures the solution architecture is sound, sustainable, and well-communicated. Also a member of the Discovery Team. Delivery Team Owns the business and customer problem solution. Consists of developers, testers, technical writers, etc. Developer Develops code solutions… Tester Tests code solutions in an iterative fashion… Technical Writer Gathers information to write key product delivers, such as: read me, guides, release notes, etc… Scrum Master Help Product Owner and Delivery Team work together efficiently and effectively. Owns and facilitates Sprint Backlog. Unblocks Team issues. Holds Daily Standups. Facilitates Team optimization of the VADF for the release. Coordinates the demos. One Scrum Master per scrum team. Holds sprint reflections. Development Mgr. Ensures Delivery Team is connected to customers. Facilitates team resource management, dependency management, team interlocks, and syncing of sprints. Collaborates with Scrum Master on VADF process optimization. Provides development Test Tools and Systems. Focuses on sprint risks.

Release PGM Launch PGM Release Architect

Release QA Lead

Focuses on release risks. Works with Development Manager on VADF process optimization. Facilitates “scrum of scrum” meetings. Facilitates Stakeholder meetings. Tying all the business processes together to get to market. Ensures all business processes and supporting systems are engaged for the release. Manages the Launch PGM checklist. Coordinates with all architects and relevant stakeholders to ensure the preservation of product architectural integrity; ensures the extension and/or refactoring of architecture is consistent with product reference architecture. Provides guidance for test strategies and test case definition; communicates SymQE standards for tracking test cases so scrum team’s tests can be used for regression; coordinates understanding of areas of code change and testing performed by scrum teams to define mainline hardening requirements; coordinate QA hardening phase including Regression, System Test & Performance Test.

System Team (aka Hardening Team) Owns the execution of system testing including performance testing, persistence testing, and product regression testing. Consists of system test engineers organized into scrum teams System Team Lead Plans the work assignments for the System Team. Owns the creation and implementation of the Regression Test Plan. System Test Engineers Conduct test activities for System Test scrum teams.

Note, CFT/CRT is not represented as a stakeholder. Expectation is that CFT/CRT contribute by supplying whole delivery teams. 2. Processes Processes are defined in the VADF to include a set of Scrum and Product Delivery processes to comprise the full spectrum of development from concept to launch. The scrum processes draw on concepts from the ADF based on various Agile software development methodologies and from the Product Delivery Framework (PDF). The scrum processes include: 1. Product Planning 2. Release Planning 3. Sprint Planning 4. Sprints 5. Demonstration 6. Reflection

The Product Delivery processes include: 1. System Test Planning 2. System Test Sprint Planning 3. System Test Sprints

Scrum Product Planning Input

Actions

MDR/PDR / Product Road Map

Develop Release Themes and Epic User Stories; identify risks and develop risk mitigation stories. Facilitator: Product Manager

Release Planning Prioritized Complete Release Backlog User Backlog; Stories; prioritize user stories based MVP User on BV (high, medium, low). Stories Facilitator: Product Owner Release Breakdown user stories if needed; Backlog estimate user stories using story points. Facilitator: Scrum Master Sprint Planning Prioritized Commit to what can be completed in Release the sprint; define ‘done, done, done’; Backlog identify architectural spike need. Facilitator: Scrum Master

Sprints Sprint Backlog; Def. of DONE3; IR

Write test and then code; hold daily stand ups; update information radiator; continuously integrate code, refactor as required; remove tech debt

Who Invol’d Whole Team

Output Prioritized Product Backlog; MVP User Stories; Decision Filters; Wireframes; Risks; Dependencies

Durat ion 1.5 d.

Whole Prioritized Release Team Backlog

0.5 d.

Deliv. Team

Estimated Release Backlog

0.5 d.

Deliv. Team

Sprint Backlog; architectural sprint backlog (optional); Definition of DONE3; Information Radiator (IR)

2-4 hrs.

Deliv. Team

User stories that meet DONE3 criteria and are ready to be deployed

2 wks.

Demonstration DONE3 Demonstrate DONE3 user User stories; get feedback from Stories stakeholders Facilitator: Scrum Master

Whole Team; Customers; Exec Spon.

Retrospective Discuss process changes for next Deliv Team sprint. Facilitator: Scrum Master

Working software; not DONE3 user stories added to Release Backlog

2 hrs.

Changes team makes to next sprint process

2 hrs.

Branch Operating Model

Product Delivery Process Some level of system testing should occur at all times on the Mainline, even at Sprint 1 in the form of automated regression testing, with other value-add system testing occurring as Sprints progress.

Once the final iteration for a release is completed and release scope is accepted by the Product Owner, the Alpha milestone build is generated. This signifies the start of the “Product Delivery Process”. During the Product Delivery Process, the System Test team follows the Scrum Process to execute regression, performance and persistence testing leading up to the RTM milestone. During the entire Product Delivery Process period the scrum teams need to budget Sprint time to address defects as they are found and not defer to a future Sprint. System Test variations on the Scrum Process defined above are: System Test Planning Input

Actions

Alpha build; DONE3 User Stories; Regression test strategy; Beta plan;

Select and prioritize regression test cases. Estimate regression test case execution timeframes. Estimate number of iterations needed to achieve Beta and RTM milestones. Set performance and persistence test strategies and milestone acceptance criteria. Facilitator: System Test Lead

System Test Sprint Planning Prioritized Commit to what can be completed Set of in the sprint; estimate regression Regression re-run requirements based on Test Cases; code velocity; define ‘done, done, Performance done’; and Facilitator: Scrum Master Persistence Test acceptance criteria; previously failed test cases

Who Invol’d Whole Team

Output Prioritized set of regression test cases. Expected number of iterations needed to declare Beta and RTM milestones. Beta and RTM milestone acceptance criteria

System Sprint Backlog; Test Information Radiator Scrum (IR) Team

Durat ion 1d.

2-4 hrs.

System Test Sprints Sprint Execute regression, performance Backlog; and persistence testing; hold daily IR stand ups; update information radiator; report defects and escalate to delivery teams for resolution

System Test Scrum Team

Test Case burn-down metrics; not DONE3 testing is added to the Release Backlog

7. Milestones Project milestones are defined throughout the VADF for a project as an indicator of project performance. Milestones ensure standards are met and targeted timelines are achieved. Milestones are managed by the Release Program Manager. The following are major milestones for the Product Delivery Process: - Alpha - Beta - Release to Manufacturing (RTM) - General Availability (GA)

Milestone Criteria The following section is intended to describe the intent of the milestones. The definition is intended to be used to define specific milestone acceptance criteria. Milestones are declared at the end of an iteration, once all defined acceptance criteria have been met.

Alpha (aka Beta1) Definition: A specific product build that can be used by customers to test in a lab environment. Typically the first full product build that can be made available to customers.

Beta (aka Beta2) Definition: A specific product build that can be made available to customers for testing purposes in production environments.

Release to Manufacturing (RTM) Definition: The final product build of a release. A build provided to cross-functional teams with the intent to distribute via sales channels.

2 wks.

General Availability (GA) The point in time where the RTM build is made available to all customers worldwide.

Note on Release Candidates The concept of a release candidate milestone is not applicable in this operating model. In theory, every build is a release candidate. At minimum a release candidate build is produced at the end of each iteration.

8. Artifacts Artifacts are the outcome of work and processes throughout the VADF. They are documents and deliverables achieved as teams work through the scrum and product release processes. Key artifacts are required as a minimum outcome of the VADF. Others are suggested below. As a general rule, documentation that does not add value to the customer or the engineering team is wasted effort and should not be produced. The following list is a set of recommended documents for teams to produce. It is expected that additional documentation will be produced by teams as needed, to define specific execution guidelines. For example, a team may document a set of rules governing their Continuous Integration implementation.

Required artifacts include: - Product Roadmap - Milestone plan and checklists - Project Charter - Sprint burn-down charts - Release burn-up charts - Testing scorecards - Planning checkpoint content - Release readiness checkpoint content

Suggested Artifacts include:

Artifact Reference architecture Product Roadmap Product Backlog

Owner Architect Product Manager Product Owner

Release Backlog Sprint Backlog Acceptance Criteria Recorded Demos Regression Test Strategy Beta Plan Launch Checklist Milestone Criteria and Checklists

Product Owner Product Owner Delivery Team Scrum Master System Test Team Lead Release Train Engineer Launch Program Manager Release PGM

Agile Readiness Checklist The Agile Readiness Checklist can be found in the Agile Delivery Framework. This is the checklist worked by a team in Sprint 0 to ensure they are ready to start Sprint 1 including being capable of reaching Done, Done, Done.

Agile Processing Flow

Adding a New User Story to Product Backlog

Release Lifecycle