Attachment VI - EPLC Agile.pdf

Food and Drug Administration

ENTERPRISE PERFORMANCE LIFECYCLE (EPLC)

AGILE METHODOLOGY OVERVIEW

Version Number: 2.0

Version Date: January 2017

VERSION HISTORY

Version Number

Implemented

By

Revision

Date

Approved

By

Approval

Date

Description of Change

1.0 Greg Hoover 8/22/2014 Initial version

1.1 Greg Hoover 8/19/2015 Minor changes to deliverable times

2.0 Greg Hoover 1/10/2017 CCB approved changes

Introduction

A key to successful IT management is a solid project management methodology that incorporates best government and commercial practices through a consistent and repeatable process, and provides a standard structure for planning, managing and overseeing IT projects over their entire life cycle. The HHS Enterprise Performance Life Cycle (EPLC) framework provides that methodology for HHS OPDIVs including FDA.

The EPLC framework consists of ten life cycle phases shown in EPLC Framework Figure 1. Within each phase, activities, responsibilities, reviews, and deliverables are defined. Exit criteria are established for each phase and Stage Gate Reviews are conducted through the IT Governance process to ensure that the project’s management quality, soundness, and technical feasibility remain adequate and the project is ready to move forward to the next phase. The EPLC framework provides a guide to Project Managers, supporting Contractors, Business Owners, IT Governance, Critical Partners, and other Stakeholders throughout the life of the project.

Figure 1: EPLC Frame Work

The EPLC framework applies to all projects, regardless of the development methodology used, and can be applied appropriately to meet the particular needs of the methodology applied. Specifically, the framework can accommodate the iterative nature of many development methodologies (including the “waterfall”, Spiral, Rapid Application Development, Incremental, and Rapid Prototyping) primarily through the use of iterative cycles within the overall life cycle phases as shown in EPLC Agile Framework Figure 2.

The most popular agile development methodology is Scrum and all future references in this and other FDA guides will reference standard Scrum terminology when explaining Agile EPLC processes.

Figure 2: EPLC Agile Frame Work:

Artifacts

Incremental development methodology and determining which project artifacts provide value often has a contentious relationship. In the world of government IT we are faced with the challenges of short delivery times, funding constraints and limited resources while at the same time must adhere to best practices and mandated processes. Determining what artifacts and when they should be provided would be difficult without guidelines that consider flexibility. The EPLC framework addresses both issues by identifying best practices deliverables and the flexibility needed to adequately manage risk while allowing for differences in project size, complexity, scope, and duration. Users of the EPLC framework are allowed flexibility to tailor the framework where particular phases or deliverables may not apply, are not identified, combine phases and deliverables when appropriate and provide for conditional approvals that allow progress to a subsequent phase in a manner that identifies and controls for risk. The EPLC framework is also clear in identifying the elements that cannot be removed from EPLC through tailoring:

Identifying the business need

Documenting correct, clear and adequate requirements

Following processes that ensure the system will be able to operate within the as-is and/or target enterprise architecture

Adequate Business Product testing

Appropriate operations and maintenance documentation

The Project Process Agreement (PPA) is used to authorize and document the selection of specific deliverables and Stage Gate Reviews applicable to the project. The PPA also documents the justifications for using, not using, or combining specific artifacts or Stage Gate Reviews. In most situations, standard artifacts such as the Business Case, Security documentation, Project Schedule, System Requirements, Test documentation and Design and O&M documentation are required but how these artifact requirements are satisfied can differ when following an iterative development methodology. Incremental processes may introduce either new or differently formatted artifacts that may be considered as equivalent artifact substitutes (User Stories, Product Backlogs, and Burndown Charts). In most cases project tools also generate agile artifacts like earlier mentioned. Both these and other project artifacts can be generated from tools and should be considered as equivalent artifact substitutes (Project Management Planning, Risk Registers, Dashboard Status, Traceability Matrices, Test Cases, and Test Reports). When there is a deviation from EPLC suggested best practices justification of what artifacts will be provided and when they will be available for review must be provided in the PPA for approval during the Planning phase.

The next item to consider is in determining when the Agile EPLC deliverables are updated, made available for interim review and/or finalized for final review. These factors are project dependent and are influenced by the Product/Sprint Backlog strategies, dependencies, and team resources. The project team assesses these factors and proposes when the deliverables will be provided for assessment(s). The final delivery and assessment times are negotiated among the project stakeholders and Critical Partners and baselined during the Planning Phase.

Stage Gate Reviews

Stage Gate Reviews occur at the end of each project phase to determine whether the objectives and exit criteria have been met, and whether the project can proceed to the next phase:

Establishment of project management processes

Assessment of deliverables

Another significant difference between Waterfall EPLC development methodology and Agile EPLC methodology is the execution of Requirements through Test Stage Gate Reviews. These Stage Gate Review activities are essentially combined as a single activity and completed during each Sprint Review. Like the project deliverables, any Critical Partner exit criterions for the Sprint Reviews are negotiated among the project stakeholders and Critical Partners and baselined during the Planning Phase (Figure 3). Sprint Reviews for an agile project are separate from, and not governed by, the EPLC Framework. However, it is advisable to include Critical Partners in Sprint Review ceremonies as appropriate.

Figure 3: EPLC Agile Workflow and Reviews

Like Waterfall Projects, Agile Projects can tailor the EPLC (number of Artifacts and Stage Gate Reviews) based on the project complexities and document this in the Agile Project Process Agreement (PPA) (Figure 4).

Figure 4: Project Process Agreement for Agile Projects

Each EPLC Phase is described in more detail in the sections below. The EPLC Artifacts that are developed in each phase are listed under EPLC Artifacts. Contractors may be responsible for input, validation or development of the artifacts. The artifacts that a contractor may be responsible for delivering, depending on the type of contract and contract owner, are listed under Potential Contractor Deliverables. Additionally, Contractor participation is expected during Project Readiness Reviews to prepare for Stage Gate Reviews.

Initiation Phase

Overview:

During the Initiation Phase, a Business Owner identifies a business need for which a technological solution is required and a preliminary enterprise architecture review is conducted to determine if there is sufficient justification to proceed into the Concept Phase. The Initiation Phase may be triggered as a result of business process improvement activities, changes in business functions, advances in information technology, or may arise from external sources, such as public law or the general public. When an opportunity to improve business/mission accomplishments or to address a deficiency is identified, the Business Owner and/or Business Project Manager document these opportunities in the Business Needs Document. Sufficient high-level functional requirements are required to understand what the project is intended to do and how it supports the business needs.

The Initiation Phase ends with a review to determine readiness for Critical Partner review during the Initiation Stage Gate Review.

Outcome:

The outcome of the Initiation Phase is the decision to invest in a full business case analysis and preliminary project management plan.

EPLC Artifacts:

Business Needs Document (RQST-IT Project Request)

Potential Contractor Deliverables:

Business Needs Document

Concept Phase

The Concept Phase begins after the Initiation Stage Gate Review occurs and the Business Needs Document is approved to enable a new business process or enhance an existing business process through the application of information technology. The purposes of the Concept Phase are to:

Identify and validate an opportunity to improve business accomplishments of the organization or to correct a deficiency related to a business need.

Identify significant assumptions and constraints on solutions relative to that need.

Explore alternative concepts and methods to satisfy the need.

Establish project sponsorship / ownership

Develop and establish the Business Requirements

Determine IPT staffing requirements for the project

Document all the considerations of Privacy Act

In the Concept Phase, sufficient requirements detail is developed to support the detailed cost and schedule estimates, alternatives analyses, and other elements of the Business Case and preliminary Project Management Plan.

The Concept Phase ends with a review to determine readiness for Critical Partner review during the Concept Stage Gate Review.

Outcome:

The outcome of the Concept Phase is the proposal and approval of a high level Rough Order of Magnitude;

approval of initial project cost, schedule and performance baselines; and issuance of a Project Charter; and the documentation and prioritization of Business Requirements.

EPLC Artifacts:

Business Case

Project Security Categorization

System of Records Notice (SORN)

E-Authentication

Project Charter

Business Requirements Document

Business Requirements Document

Planning Phase/ Sprint 0/Release Planning Activities

The Planning Phase begins after the Concept Stage Gate Review when the project has been formally approved and funded, and the Project Charter is approved. This Phase requires study and analysis culminating in the full Agile Project Management Plan. Specific plans for management and governance of the project are established and documented to guide ongoing project execution and control. The degree of project management rigor that is to be applied to the project is determined, the EPLC is tailored (via the Project Process Agreement), project work is broken down into specific tasks and sub-tasks, and milestones are established.

Sprint 0 Planning:

Agile project planning must also conduct Sprint 0 Planning Activities. The purpose of Sprint 0 is to provide business and IT with a collaborative process to identify key features of the release. During Sprint 0, the business should be responsible for generating user stories and the technical team should review those stories.

The purposes shouldn’t be to finalize user stories as much as it should be to understand what users may say verbally versus what they documented. Are users leaving out important functionality or acceptance criteria? Is what they say what they mean? Writing and discussing user stories should be an iterative process where business learns how to write better stories and the technical team learns how to go back to the business for clarification.

Stories should encompass immediate, short term and long term requirements of the system. The team should work together to build a reasonable backlog that will allow the technical team to go through several iterations

The Product Owner should define the exit criteria for passing from Sprint 0 into the Sprint iterations.

The team should decide upon an iteration schedule, Sprint planning, Sprint Review and daily meeting schedules.

Sprint 0 represents the final opportunity to validate what was originally requested and approved is what the team is capable of building in the timeframe and budget allowed.

Sprint 0 planning should be an iterative process where the team builds on product and project knowledge while identifying the initial set of EPICS or Users Stories that allow the project team to build a working solution.

At this time, the product backlog should not contain all of the requirements the team expects to accomplish during the release but it should contain enough features to allow the development team to be able to work on the initial sprints.

The product backlog should be managed and prioritized by the product owner, IT PM or business PM depending on the structuring of project roles and responsibilities. Developers should not be responsible for performing prioritization. Business should identify the features that provide the greatest business value and the IT PM should identify the stories that have the greatest risk/reward and the product backlog should represent Business and IT working collaboratively to prioritize and build an effective product backlog.

Refine estimates based on an assessment of the technology capabilities, project scope and schedule constraints. The product backlog is not static. Stories can and should be added, modified and deleted based on new information about the system and or features.

Planning the Release Continuously

The initial release plan is understood to be rough. It must be detailed enough only to get started, by predicting that the project will deliver enough to meet the business need. Agile projects are planned continuously, and corrected as time goes on. One of the primary mechanisms for course correction is allowing the release plan to evolve in response to all kinds of feedback. It can take several iterations for team velocity to settle.

Iterations will sometimes deliver less functionality than was planned for, and sometimes more. Features, architectural choices, design choices, or framework or technology choices might prove to be too risky or simply unworkable. The user interface might require revision. Staff might be lost or added. Feature priorities might change. All of these factors will assist in the grooming of the release plan.

The Planning Phase ends with a readiness review to determine if sufficient project plans have been defined and is ready for Critical Partner review during the Sprint 0 Review.

Outcome:

Outcomes of the Planning phase are complete and adequate project planning artifacts including refinement of project cost, schedule and performance baselines.

Sprint 0 exit checklist:

Establish baselines

Document the frequency of Sprints (X number of Sprints per Release)

Document the length of Sprints (1 - 4 week increments)

Estimate initial sprint velocity

Validate project scope and if adjustments are required (Nice to haves vs. must haves)

Determine date, time, location and attendees for Daily and Weekly status meetings

Finalize Release Schedule

Setup/configuration of Development, Test, Pre-Prod and Production environments

Key Understandings:

The Project Team, Product Owner and Business SMEs have agreed upon the goals of the Release

The Project Team, Product Owner and Business SMEs have agreed upon the activities that will occur during UAT and during the Sprint Review

Example: Business will conduct UAT and move User Stories to Done; a live demo during the Sprint Review will not be required.

Critical Partners have by identified and they have a clear understanding of the Project’s expectation of them and the services they will provide.

Prioritization – Determine which sets of stories should be completed first.

The amount of learning and knowledge that can be gained by developing a group of features

The amount of risk removed by developing those features to the overall project

The value both financial and business of having those features

The impact on the cost of future feature development

EPLC Artifacts:

Project Process Agreement

Agile Project Management Plan

Project Schedule

Potential Contractor Deliverables:

Agile Project Management Plan (contract specific)

Project Schedule (contractor activities)

Agreed Agile deliverables (example Product Backlog, User Stories, Burn charts)

EVM process and reporting (as needed)

Requirements Analysis Activities Conducted During Sprints

During the Requirements Analysis Activities, the Sprint Backlog is validated and decomposed into functional and non-functional requirements or user stories describing functionality that is needed to meet the requirements. These requirements define the Sprint Backlog in more detail with regard to inputs, processes, outputs, and interfaces, and permit further detailed release management planning.

The Requirements Analysis Activities ends with a transition to Design Activities.

Outcome:

The outcome of the Requirements Analysis Activities is to translate the Sprint Backlog into detailed functional and non-functional requirements or user stories.

EPLC Artifacts:

Logical Data Model and Logical Data Dictionary (ERWIN) System Requirement Specifications /User Stories Requirements Traceability Matrix (tracing Business Requirements to technical requirements)

Logical Data Model and Logical Data Dictionary (ERWIN) System Requirement Specifications Requirements Traceability Matrix (tracing Business Requirements to technical requirements)

Design Phase Activities Conducted During Sprints

The Design Activities seeks to develop detailed specifications that emphasize the physical solution to the end user's information technology needs for a particular release. The system requirements/user stories and logical description of the entities, relationships, and attributes of the data that were documented during the Requirements Analysis Activities are further refined and allocated into system and database design specifications that are organized in a way suitable for implementation within the constraints of a physical environment (e.g., computer, database, facilities).

The Design Activities may include a review prior to detailed design of the Sprint Backlog to achieve confidence that the design satisfies the system requirements, is in conformance with the enterprise architecture and prescribed design standards. The Design Activities ends with a transition to Development Activities.

The outcome of the Design Activities is to translate the Sprint Backlog into the proposed Business Product design and successful completion of the Sprint Reviews.

System Design Document Privacy Impact Analysis (PIA) Physical Data Model and Physical Data Dictionary (ERWIN) Interface Control Document (ICD) Requirements Traceability Matrix (tracing requirements to design) Systems Security Plan System Architecture Document

System Design Document Privacy Impact Analysis (PIA) Physical Data Model and Physical Data Dictionary (ERWIN) Interface Control Document (ICD) Requirements Traceability Matrix (tracing requirements to design) Systems Security Plan System Architecture Document

Development Activities Conducted During Sprints

During the Development Activities, the system developer takes the detailed design information documented during the previous activities and transforms it into machine-executable form, and ensures that all of the individual components of the proposed Business Product function correctly and interface properly with other components within the system/application. As necessary and appropriate, system hardware, networking and telecommunications equipment, and COTS/GOTS software is configured. New custom-software programs are developed, database(s) are built, and software components are integrated. Test data and test case specifications are finalized. Unit and integration testing is performed by the developer with test results appropriately documented.

The Development Phase ends with a transition to Test Activities

The outcome of the Development Phase is completion of all agreed coding and associated documentation;

user, operator and maintenance documentation, and test planning.

Requirements Traceability Matrix (RTM) (tracing design to code) Release Test Plan Test Cases Specifications Version Description Document (VDD) (release package)

Requirements Traceability Matrix (RTM) (tracing design to code) Release Test Plan Test Cases Specifications Version Description Document (VDD) (release package)

Test Activities Conducted During Sprints

The primary purpose of the Test Activities is to determine whether the Business Product developed or configured during the Development Activities is ready for Sprint Review. During the Test Activities, formally controlled and focused testing is performed to uncover errors and bugs in the prosed Business Product that need to be resolved. There are a number of specific validation tests that are performed during the Test Phase (e.g., requirements validation, system integration, interface, regression, information security, performance, stress, 508 compliance, and user acceptance).

The Test Phase ends with a Sprint Review to determine if the results of testing the system meet the Product Owner’s and Critical Partners’ exit criteria.

The outcome of the Test Phase is completed testing, including user acceptance testing, and readiness for implementation and training.

Requirements Traceability Matrix (RTM) (tracing requirements to test cases) Test Reports Project Implementation Plan Training Materials User Manual

Requirements Traceability Matrix (RTM) (tracing requirements to test cases) Test Reports Project Implementation Plan Training Materials User Manual

Implementation Phase

During the Implementation Phase, the Business Product is moved from the Test environment status to the production environment. The process of implementation is dependent on the characteristics of the project and the Business Product, and thus may be synonymous with installation, deployment, rollout, or go-live. If necessary, data conversion, phased implementation, and training for using, operating, and maintaining the system may be accomplished during the Implementation Phase. The completed system must be certified and accredited before use in the production environment.

If any “mid-release” Sprint is planned for production the project must first hold an Implementation Stage Gate Review to ensure that the agreed interim deliverables have been completed and the interim product is production ready. If this is the final Sprint the Implementation Phase ends with a readiness review to ensure that all artifacts are ready for review and an Implementation Stage Gate Review to ensure that the final product is production ready. The Implementation Stage Gate Review may result in:

Approval of going live with the current release and go back to the Planning Phase for the next release;

or

Approval of going live with the current release and approval to move the project to the Operations and Maintenance (O&M) Phase where O&M releases for bug fixes and maintenance occur

Deny going live and further assessment of next steps

The outcome of the Implementation Phase is successful implementation of the completed Product Backlog into production and a decision as to whether remaining Product Backlog will be delivered or movement to O&M status.

Operations & Maintenance (O&M) Manual Contingency and Disaster Recovery Plan Service Level Agreement(s) (SLAs) / Memorandum(s) of Understanding (MOUs)

Operations & Maintenance (O&M) Manual Contingency and Disaster Recovery Plan Service Level Agreement(s) (SLAs) / Memorandum(s) of Understanding (MOUs)

Operations & Maintenance Phase

During the Operations & Maintenance (O&M) Phase, the certified and accredited Business Product operates in full-scale production environment for sustained use with releases for bug fixes and maintenance. Major changes to the scope will require the project to return to Initiation Phase for modifications to the Business Case and Project Charter. Minor changes to the product that are within scope will require the project to return to the Planning Phase. Periodically the Business Product will also need to be re-certified and re-accredited for continued operation in the production environment. When the time comes that the Business Product will no longer be needed or will be replaced, then a plan for final disposition of the Business Product must be prepared and approved prior to moving into the Disposition Phase.

The outcome of the Operations and Maintenance Phase includes ensuring all processes, manual and automated, are documented in the operating procedures, as well as successful operation of the system against current cost, schedule and performance benchmarks.

Post Implementation Report Plan of Action and Milestones Operational Analysis Disposition Plan

Potential Contractor Deliverables:

Post Implementation Report Plan of Action and Milestones Operational Analysis Disposition Plan

Disposition Phase

During the Disposition Phase, the operation of a Business Product is formally ended in accordance with organization needs and pertinent laws and regulations. The Business Product is retired or disposed of based on the formal Disposition Plan approved during the Operations & Maintenance Phase. The disposition activities ensure the orderly termination of the Business Product and preserve vital information about the system so that some or all of the information may be reactivated in the future if necessary. Particular emphasis is given to proper preservation of the data processed by the Business Product, so that the data is effectively migrated to another Business Product or archived in accordance with applicable records management regulations and policies for potential future access.

The outcome of the Disposition Phase is the deliberate and systematic decommissioning of the Business Product with appropriate consideration of data archiving and security, migration of data or functionality to new assets, and incorporation of lessons learned over the project life cycle.

Project Archives

Project Archives