Agile transformation

From traditional life cycle to a lean and agile frameworkMarch 19, 2019

2

OverviewWith the launch of U.S. Digital Service, GSA 18F Digital Services Delivery, and similar federal initiatives, there is now an abundance of material available to help federal agencies implement agile practices, starting with the U.S. Digital Services Playbook and TechFar publications. This paper builds on that literature, providing a step-by-step guide for agencies to mature agile adoption by describing inflection points that require investment and deeper commitment to change, and advising on general approaches for realizing a value-driven, lean and agile enterprise.

IntroductionWhile a handful of federal acquisitions are many years into applying agile with tailored governance processes, many agencies are just now confronting the challenge of adapting agile development to their systems engineering and acquisition processes. Typically, organizations preparing to use agile are pre-acquisition or in the source selection phase, or perhaps they are under scrutiny and hoping to turn around a troubled program. Wherever agencies are in their agile journey, all of them encounter challenges managing agile development projects within their portfolios. Government agencies struggle with aligning agile programs to broader organizational structures and processes, and the transition to Agile roles, practices and ceremonies can be perplexing.

To address this, Perspecta offers a set of recommendations to help government organizations successfully adapt governance and engineering processes that more effectively enable agile development, with the end-goal being to rapidly deliver better products and services and establish a value-focused organization.

They are as follows:

1. Stabalize agile project teams

• Fix the development cadence

• Invest in product ownership

• Take time to inspect and adapt

2. Bring test and integration in-cycle

3. Update late-phase governance

4. Streamline upfront planning

• Reduce requirements management overhead

• Apply value-oriented, lightweight solution engineering

5. Align the organization with value flow

In support of these recommendations, Perspecta provides an overview of common government acquisition approaches, their relationship to the systems engineering (SE) life cycle (commonly represented by the SE “Vee” graphic), and the challenges inherent in integrating agile development in this context. We then discuss the recommendations above in detail, describing why they are important and how to implement them in a coordinated step-by-step approach, with the end result being a complete transformation of the government organization into a truly agile enterprise.

What is agile?Agile is an iterative and incremental approach to software development. Though different agile methodologies encompass common practices, agile is really a mindset change. The Agile Manifesto and its supporting Twelve Agile Principles emphasize a few key concepts:

• Small, cross-functional, motivated teams work closely with the business and within fixed-time intervals to prioritize and deliver valuable software early and frequently

• Technical excellence is paramount, and progress is judged by working software

• The best architectures, designs and requirements are simple and emergent, not complex and planned in elaborate detail

• Agile teams operate at a sustainable pace and continuously learn, improve, and adapt to changing circumstances to realize team and customer success

In sum, agile means flexibility and responsiveness to change, which contrasts with the traditional approach of developing a plan, setting baselines (e.g. technical, cost, schedule, performance, contractual, etc.), and carefully managing baselines to ensure adherence to the plan. Similarly, agile says that what counts is technically proficient teams building working software—not passing gate reviews—and regular (daily) face-to-face collaboration with customers. This ensures teams develop the right software and are not “managing to the plan” using static processes, cumbersome tools and comprehensive documentation.

Lean roots

Goal: Highest quality, lowest cost, shortest lead time

KaizenStandardizedwork

Stability

Heijunka

Just-In-TimeContinuous flow

Takt timePull system

JidokaStop and notifyof abnormalities

Separate man’swork and

machinework

Figure 1: Toyota production system “house of lean”

In many ways, agile principles and processes are simply an adaptation of lean (coming from the Toyota Production System, figure 1), but evolved for software development. In lean, the goal is the highest quality at the lowest cost, with the shortest sustainable lead time.

By comparison, in agile the goal is early and continuous delivery of value. In lean, the delivery mechanism is a continuous, pull-based manufacturing flow with an emphasis on automation, building quality in, and trusting workers to stop the line to immediately fix abnormalities. Similarly in agile, the team addresses requirements “just in time.”

3Perspecta I Agile transformation

For each iteration, the team uses automated tools and testing to ensure high quality and the team decides how best to fulfill requirements (i.e. emergent design). Whereas lean emphasizes Heijunka (production leveling) to enable flow, agile uses iteration time boxes to force capacity matching and limit work in progress (WIP). Lean emphasizes the need to standardize work as much as possible while agile does this by decomposing work items into smaller, more manageable pieces for execution against a predefined “definition of done”. Both lean and agile emphasize continuous improvement (Kaizen), and both require stability to function well.

Systems thinkingAlso central to lean is the concept of optimizing the whole, rather than components and subsystems, to achieve continuous flow of value. Lean says to structure and visualize work systems and processes so that queues, delays, and wastes are easily identified and addressed. Likewise in agile, the orientation around value delivery demands a cross-functional, multi-skilled team to collectively storm and complete the work. Incremental value delivery at the user story level requires iterative development of an end-to-end system or application; the team cannot achieve that by building one architectural component at a time. Since stovepiped functions inhibit agility, as such workers operate in an environment choked by cross-organizational dependencies that trigger external processes or decision-makers to resolve, agile success is based on a stable, balanced team of generalized specialists focused on end-to-end system value delivery.

Systems development and value flow at the scale of agileAs an example of how value flow and systems thinking are baked into agile, consider how agile teams rely on user stories to convey requirements instead of traditional functional requirements (i.e. “shall” statements). User stories are not static and carry the basis for conversation with stakeholders to explain additional details:

• What is the business context?

• What does success look like?

• Are there related themes that might describe a larger set of features?

As the team progressively elaborates the user story to uncover the acceptance criteria, they define specific technical details necessary to achieve the desired functionality and business value. The team then estimates and prioritizes user stories for future development based on size, complexity and business value. When a team commits to user stories in iteration planning, they are committing to fully implement those user stories in that timebox – that is, the resulting working software is accepted by the product owner (PO) and is potentially shippable. Thus, each user story encompasses an entire SE V life cycle, fully implemented in the span of days to weeks.

The acquisition and engineering life cycle Government acquisition, engineering and readiness processes tend to follow a common phase-gate governance approach. For the purposes of this white paper, we rely on the Department of Homeland Security (DHS) Acquisition Management Directive 102-01 (MD102-01), along with MD 102-01 Appendix B, Systems Engineering Life Cycle (SELC), to guide the discussion, as they represent a well-elaborated expression of this governance philosophy. That said, equivalent governance frameworks exist elsewhere (e.g. Department of Defense Instruction 5000.02), some of which already incorporate tailoring to better allow for agile development. Indeed, DHS recently published Instruction 102-01-004, “Agile Development and Delivery for Information Technology” to guide the use of agile at DHS, demonstrating that some government organizations are already incorporating the concepts proposed in this white paper.

DHS Acquisition Life Cycle Framework The DHS Acquisition Life Cycle Framework (ALF) in figure 2 describes four distinct stages and includes five Acquisition Decision Events (ADEs). Specific guidance for each phase or ADE depends on whether the program is considered major or non-major, and many programs are subject to further process tailoring via oversight from an acquisition review board (ARB) and/or executive steering committee (ESC). Note that the DHS ALF is not specific to software development programs or information technology (IT); the framework assumes some adaptation based on the type of program.

The need phase consists of defining the needs driving the acquisition, reflected in ADE 1, the purpose of which is to validate the collected needs and authorize additional analysis. After ADE 1 is the analyze/select phase, which culminates in ADE 2A. This event ensures sufficient solution engineering to justify ARB approval of an official program and marks the beginning of the obtain phase of program planning. The ARB reviews program plans and authorizes supporting acquisitions at ADE 2B and approves the transition into Low Rate Production or Incremental Delivery (as applicable) at ADE 2C, while ADE 3 provides official approval for the production and deployment of the developed capabilities – i.e. the produce, deploy, support and dispose phase.

Figure 2: DHS Acquisition Life Cycle Framework per MD 102-01 Rev3

Need Analyze/select Obtain Produce/deploy/support/dispose

Collection point forgaps and needs

1: Validate needs

= Acquisition Decision Event (ADE)

2a: Approve program 3: Produce and deploy program products

2b: Approve supporting projects/contracts2c: Approve low rate production or incremental delivery

1

2a

2c

32b1

4

Figure 3: The waterfall model1

Waterfall observationsWaterfall timelines for major programs typically span years, with distinct phases often lasting several months. The result is a process that, if followed without deviation, demands significant upfront planning. Meanwhile there is often a multi-year period between initial solution envisioning and tangible, operational testing that validates the appropriateness of the solution (i.e. “fit for purpose”). Due to the heavy, sequential nature of this process, almost all of the progress reviews consist of reviewing documents rather than working product. As a result, assessing risk involves a degree of speculation. Meanwhile, program managers are tempted to forgo engineering rigor in order to save on upfront development costs and keep delivery timelines. Though waterfall inherently backloads risk, a decision to skimp on early SE heightens program risk further. This is a major reason why waterfall programs tend to falter as integration testing often triggers significant design re-engineering and associated rework to address critical defects.

Agile inside the VBy and large, federal agencies already using agile tailor their governance processes by shoehorning agile development (e.g. Scrum) into the development phase—(figure 4).

Figure 4: Agile inside SELC development phase, with scrum loops

signifying sprints or iteration

Acquisition Lifecycle Framework (ALF)

Systems Engineering Life Cycle (SELC)

Need Analyze/select Obtain Deploy and

support0 1 2a 2b 32c

SPR SPR PPR SDR PDR CDR IRR OTRRPRR

LRIP

PIRORR

SELC

ALF

Solutionengineering

Planning Requirementsdefinition

Design Development Operationsand

maintenance

ImplementationIntegration

DHS Systems Engineering Life CycleThe DHS Systems Engineering Life Cycle (SELC) supports the ALF with a set of control gates at which various project artifacts are reviewed to assess engineering rigor and program risk. The general progression of milestones is as follows:

• The SELC commences after ADE 1, which is followed by the Study Plan Review (SPR) to review ground rules and assumptions, analysis plans, scope and methods that will be used to evaluate, assess and choose between new capability alternatives

• The Solution Engineering Review (SER) reviews Analysis of Alternatives (AoA) outcomes and determines readiness for ADE 2A and program scope planning

• The Project Planning Review (PPR) ensures adequacy of the plan (cost, scope and schedule) to satisfy stated requirements in a technically feasible approach and aligns with ADE 2B (if needed)

• The System Definition Review (SDR) ensures adequate detail in the requirements and plans for the project to begin design and development

• Design progress is assessed via a Preliminary Design Review (PDR), and finalized at the Critical Design Review (CDR), marking readiness for coding and/or fabrication

• An Implementation Readiness Review (IRR) ensures system readiness for integration and test based on subsystem and/or configuration item tests and a review of the test infrastructure and planning

• The Production Readiness Review (PRR) reviews system level testing to validate that the developed solution meets the defined requirements and to assess readiness for implementation, deployment or production

• Post- PRR, ADE 2C (when applicable) authorizes initial low-rate production, and Operational Test Readiness Review (OTRR) signals readiness for operational testing

• The Operational Readiness Review (ORR) evaluates whether the system as implemented meets mission needs and operational requirements and is ready to move into the Operations and Maintenance (O&M) phase, while the Post Implementation Review (PIR) documents deployment, implementation, and lessons learned for future releases

In summary, the SELC reflects a sequentially phased, review-based approach based on the classic Systems Engineering (SE) “V”. In essence, this is the traditional waterfall model originally and famously described by Winston Royce in 1970, the defining characteristic of which is a plan-based sequential development process broken up into distinct functional phases governed with control gates (figure 3).1 In the SELC adaptation, the solution engineering and planning happens first (e.g. architecture, CONOPS, high-level requirements, use cases, etc.), then efforts transition into defining detailed functional requirements. The process proceeds into preliminary and final design, development, integration and test, and finally implementation and O&M. Along the way, progress and risk are assessed by reviewing appropriate artifacts at reviews and events.

System requirements

Softwarerequirements

Analysis

Program design

Coding

Testing

Operations

5Perspecta I Agile transformation

Transitioning from V to AgileWith this background, the misalignment of agile development within a traditional waterfall approach is apparent, and the implications go beyond just eliminating PDR and CDR. Simply put, the more plan-based management remains, the less effective agile can be. So if an agency has committed to agile development, what is the best way to maximize agile success? Meanwhile, whatever incongruities exist between agile and waterfall, governance instructions still apply. There must be a solution to this dilemma.

Transitioning to a more fully agile approach requires us to define and pragmatically bound the problem in terms of end-to-end value delivery. In that vein, the following recommendations unlock the potential of agile to accelerate value delivery and evolve the organization and its processes. We suggest a general sequence of steps, but many of these changes can be implemented concurrently.

1. Stabilize agile project teams

The most important consideration for unlocking agile’s potential is to stabilize and protect the agile team as much as possible from the effects of traditional project planning and management methods. Stable, cross-functional teams of five to nine people are fundamental to agile development, yet programs routinely disrupt team maturation by moving or allocating resources across multiple projects. Besides experiencing productivity drag from task switching, this behavior inhibits team members from jelling together over time. Program management should make every effort to foster stable agile teams, and instead of assigning personnel to work projects, leave the team intact and bring the work to them. This means that management must appropriately staff the agile team with the necessary cross-functional resources to do the work. Also, agile approaches the concept of the project manager role differently than defined by PMBOK3. For instance, in scrum, the scrum master (SM) is the team process leader and facilitator, while the PO is responsible for business value definition and prioritization. The rest of the scrum team consists of multi-skilled developers and testers, while specialized roles (e.g. business analyst, systems engineer, software architect, system administrator, database administrator, etc.) may supplement the team. Agile teams should have requisite domain experience, and the team environment should nurture continuous learning.

CadenceThe underlying temporal construct of agile development is the iteration timebox. This cycle should be a short period (e.g. one to four weeks) – otherwise agility is a mirage. An agile team may need a few iterations to stabilize its iteration length and standardize a cadence. Once that occurs, managers and stakeholders should adjust meetings and business rhythms to better interact with agile teams. In the ideal scenario, the entire program follows the same cadence as the agile team, providing frequent and predictable opportunities to coordinate and synchronize.

Business value prioritizationIdeally, a business stakeholder should be a full-time member of the agile team to drive business value prioritization. In scrum, the PO fills this role and is the team’s scope authority; to accept completion of work items, they must triage inputs from other stakeholders and

Another way to visualize this is with agile at the bottom of the Systems Engineering “V” (figure 5).

Figure 5: Agile at the bottom of the SE V

In other cases, the tailored process might even include agile across some or all of design and integration phases (figure 6) in addition to the development phase. For example, most programs using agile quickly abandon PDRs and CDRs as being impractical.

The benefits of implementing agile this way are real. For instance, even when requirements are fixed early, the agile approach of iteratively developing the most valuable requirements first and demonstrating the results at iteration demos gives the government early insight into the viability of the intended solution and allows for earlier course correction. Similarly, when agile developers implement continuous integration (CI) and other test-driven development (TDD) practices, the integration phase is radically shortened, completed incrementally, or even eliminated altogether, allowing for earlier delivery of value to users.

Figure 6: Agile inside SELC design, development and integration

phases

Unfortunately, there are drawbacks with this approach. For one, while agile development helps to meet or improve on the original acquisition timeline, pre-award activities still tend to take far too long. Second, waterfall-style requirements do not lend well to agile software development and often slows agile teams who must continually maintain, map to, and decompose requirements documents into more useful artifacts. Third, unaltered OTRR and ORR processes can hinder agile teams from delivering frequently. Finally, agile development operates under a different organizational pattern and philosophy than traditional INCOSE2 - and PMBOK3 - based approaches. Agile is fundamentally team-driven, not plan-driven, so the integration of agile into waterfall-based models naturally exposes friction and holes associated with these divergent principles. Agile development teams and government management can struggle to work together given the differing (and inconsistent) use of lexicon, roles, processes, business rhythms and metrics.

Implementation

Concept of

operationsOperations andmaintenance

Projectdefinition

Project testand integration

Requirements

and architectureSystem verificationand validation

Verification and

validation

Detailed design Integration, testand verification

Time

Acquisition Lifecycle Framework (ALF)

Systems Engineering Life Cycle (SELC)

Need Analyze/select Obtain Deploy and

support0 1 2a 2b 32c

SPR SPR PPR SDR PDR CDR IRR OTRRPRR

LRIP

PIRORR

SELC

ALF

Solutionengineering

Planning Requirementsdefinition

Design Development Operationsand

maintenance

ImplementationIntegration

6

Figure 7: Cost of defect vs. length of feedback cycle4

Figure 8: Defect cost over time5

3. Update late-phase governance

With quality technical practices and CI/CD in place, it is time to streamline or eliminate control gates between iteration completion and release to production. While flattening the front end of the V is also important (figure 8), if we do not first improve code quality and accelerate the release of valuable product increments, we queue up requirements and functionality without enhancing value delivery. From an ALF and SELC standpoint, this means governance tailoring should first address the right side of the SE V. For example, if an agile team is using CI and automated regression testing and is successfully demonstrating working software each iteration, consider skipping or combining IRR and PRR, as the intent of these events are met via the iteration demo. Similarly, if each iteration produces quality increments of potentially shippable code, make ORR a recurring, lightweight review tied to frequent releases.

If the project practices DevOps, OTRRs may be altogether obsolete, as code quality and deployment frequency undermine the logic for

Perc

enta

ge o

f def

ects

Coding

% Defects introduced this phase

Unit test Functionaltesting

Field test Post release

85%

Repaircost

5x10x

40x

500x

% Defects found in this phase

$ Cost to repair defect in this phase

help the team define, decompose, estimate and prioritize the work. A scrum team with an absent PO is a sailboat without a rudder: as winds change, the boat twists and turns uncontrollably, loses velocity and risks tipping over; similarly, competing priorities and discordant voices cause an agile team to misperceive business needs and struggle to deliver value.

Inspect and adaptAnother agile team practice to nurture is the sprint review, held at the very end of the iteration. The goal of the sprint review is to demo the results of the sprint and evaluate what went well and what did not, then turn that into concrete actions for improvement in the next cycle. Good agile teams track team-level performance metrics and evaluate quantitative and qualitative data to self-assess. Great agile teams have the discipline to implement prioritized improvements in the following iteration. There is no limit to an agile team’s potential when its members take the retrospective as seriously as the work of building the system itself.

2. Bring test and integraiton in-cycle

Once a stable team is successfully executing the basic agile rhythms, focus should turn to maximizing use of high quality technical practices. Principally this involves adopting a test-first mentality and incorporating eXtreme Programming (XP) and DevOps practices:

• Define done for the different classes of work items

• Define upfront the acceptance criteria and test approach with each user story or task

• Write and automate unit tests concurrent with software coding

• Invest in the use of tools that support automated software configuration management, build, integration and test

• As much as possible, automate and perform all testing inside the iteration

• Regularly check in and continuously integrate new/changed code into the main branch

• Use pair coding, regularly re-factor code and incorporate other XP best practices

• Demo at the end of each sprint

• Configure development, test and staging environments to match production environment as closely as possible, and use continuous integration (CI) and continuous delivery (CD) practices to streamline the pipeline from development to production (DevOps)

These technical practices merit their own white paper discussion, but their value to successful agile execution cannot be overstated. Defects, convoluted code and technical debt generate rework and kill agility; fix quality and agile becomes a lot easier. In fact, the cost of not implementing test-driven quality practices in-cycle is enormous, as demonstrated in figures 74 and 85. Similarly, since business value is not truly realized until software is in the hands of users, an agile-based project should invest in infrastructure and tooling to implement CI/CD, with the goal of deploying functionality as near as possible to code completion.

Defect found via pair programming

Defect found via continuous integration

Defect found via Test Driven Development (TDD)

Defect found via active stakeholder participation

Defect found via traditional review or inspection

Defect found via traditionalacceptance testing

Defect found via traditionalsystem testing

Length of feedback cycle

Cos

t

Copyright 2006-2009 Scott W. Ambler

7Perspecta I Agile transformation

4. Streamline upfront planning

A stable, productive agile team churning out high quality, potentially shippable software every iteration—that is the definition of value delivery! However, a successful agile team operating within the traditional ALF/SELC paradigm is still fundamentally plan driven. The ability of agile to harness change for the customer’s advantage is diminished if the team is executing against architecture, requirements, and design is defined before the agile team even existed. Worse is forcing an agile team to decompose functional requirements into system requirements even as they write user stories to aid coding and development. As a result, we expend effort to write, decompose, trace and close official requirements even though this is divorced from how the agile team creates and delivers business value.

Reduce requirements management overheadIf the government composes functional requirements before an agile team is in place, the fate of managing a traditional requirements hierarchy alongside user stories may be unavoidable. That said, the agency should consider relieving agile teams of having to maintain a system requirements specification. Instead, rely on user story verification criteria and associated acceptance tests to close functional requirements. Ideally, requirements closure (i.e. verification) criteria has been developed alongside the functional requirements, otherwise, the agile team and PO may need to elaborate requirements verification and user story acceptance criteria concurrently to ensure traceability.

Value-oriented, lightweight solution engineeringEven with requirements traceability resolved, the question remains as to how to tailor early-phase governance processes to more effectively feed into agile development processes. Agile teams still need a vision and a roadmap:

• What is the organization trying to achieve?

• What are the short-, medium- and long-range milestones for the project?

• What are the operational scenarios and business processes being impacted, and what are the high-level capabilities and constraints that guide the solution design?

These questions help the PO and agile team maintain focus on business value delivery.

Because each user story is its own Agile mini-V, the answer is to tailor governance to better harness early solution engineering efforts in a way that captures contextual information from which a backlog of user stories can be constructed. In an ALF/SELC context, there is little need to tailor ADE 1 and activities up through SPR. That being said, engineering work done in support of agile acquisitions must be value-centric rather than function-centric: the centrality of value delivery to agile execution demands that the work of drafting a CONOPS, outlining high-level architecture, and capturing operational requirements should serve to effectively scope the business value involved—not elaborate technical design.

conducting user acceptance testing (UAT) distinct from operational test and evaluation (OT&E). Instead, consider a lightweight Release Readiness Review (RRR) for each release to replace IRR, PRR, OTRR, and ORR, and rely on post-release user feedback to guide O&M enhancements. Post-development control gates become less valuable once an agile team consistently builds quality code and

demonstrates deployment readiness each sprint.

Figure 9: Agile delivery reshapes the SE V

Information assurance readinessA frequent challenge to implementing CI/CD is the RMF process (figure 9). Like other forms of governance, RMF often is implemented in alignment with sequential waterfall milestones. Building good security practices and testing into the development cycle is the best way to remove RMF as an obstacle to agile delivery goals – in other words, include information assurance (IA) as part of the definition of done. Gaining authority to operate (ATO) may require agile teams to support parallel, sequential processes spanning multiple iterations, but once ATO is achieved and the system enters continuous monitoring, the payoff of addressing IA in cycle becomes clear. This combination of robust security engineering and DevOps is known as DevSecOps. DevSecOps delivers business value more frequently while still safeguarding the underlying quality and security of the solution.

Concept ofoperations

Operations andmaintenance

Requirementsand architecture

Detailed design

Agile

dev

elop

men

tUn

it te

stIn

tegr

atio

n te

stRe

gres

sion

test

Auto

dep

loym

ent

Informs

Project envisonedat “Sprint 0”

Securitylife cycle

Categorize

Assess

Post-MVPincrementdelivery

Project Envisonedat “Sprint 0”

Deploy MVP Create Minimum Viable Product [MVP]

Test MVP

Authorize

Monitor

Implement

Select

Figure 10: The NIST RMF security life cycle6

8

5. Align the organization with value flow

In transitioning from traditional, plan-driven governance towards a healthy agile approach, the overall acquisition process timeline drastically improves. But agile transformation should not end here. In fact, an agency implementing agile will discover that its organization and business processes constrain the flow of value in the enterprise. Operationalizing a fundamentally agile-based governance model demands major shifts in roles and responsibilities. Specific remediation steps vary from agency to agency; variables include how the agency is organized around its work prior to agile transformation, statutory and regulatory compliance challenges, budget cycles and appropriations constraints, rules and practices to protect national security information and similar hurdles.

Still, adopting agile raises the visibility of value flow across divisions, offices, and even agency or department levels, and this motivates leadership to realign accordingly. Committed agile adopters should consider the inevitability of organizational change to facilitate value flow and aim to plan agile acquisitions and program structures that specifically align to value streams. Agile execution and organizational value flow are mutually reinforcing: agencies that streamline governance to facilitate agile development better understand the need to improve the flow of value through their organization. A clear understanding of organizational value streams simplifies the process of end-to-end agile transformation, including planning for new agile efforts. Holistic agile transformation thus harmonizes mission, purpose, values and resources in support of enduring value delivery.

ConclusionThe vision of an agile enterprise organized around rapid delivery of value is attainable in the federal sector, today. To do this, government agencies should use these five recommendations to evolve beyond the painful shoehorning of agile software development inside traditional plan-based governance models. Government leaders who commit to fully adapting their acquisition and engineering processes to reflect lean and agile principles throughout will reap the resulting benefits.

References1.“Managing the Development of Large Software Systems,” Winston W. Royce, 1970 2. International Council on Systems Engineering 3. Project Management Body of Knowledge, as curated by the Project Management Institute (PMI) ---unsure of which figure this is 4. Source: Scott Ambler, http://www.ambysoft.com/essays/ whyAgileWorksFeedback.html 5. Source: Applied Software Measurement, Capers Jones, 1996 6. Source: http://csrc.nist.gov/groups/SMA/fisma/ Risk-Management-Framework/

Where early-phase governance tailoring begins in earnest is towards the end of the traditional solutions engineering phase. Since managing to plan-driven baselines does not generate optimal agile outcomes, project planning and authorization activities should change. Instead of gauging the readiness of solution engineering to guide formal program planning, the intent should be to capture sufficient information about the business needs to populate a program backlog of user stories for future implementation. Just as importantly, we must articulate what success looks like for these user stories. In cases where the backlog can be funneled to an existing agile team, PPR and ADE 2B are superfluous, though a lightweight SDR-like event may be useful to ensure the agile team understands and has the adequate resources to execute the backlog. This does not necessitate writing functional requirements; instead, enter this review with high-level user stories synthesized from CONOPS, AoAs, architectural analysis, test plans and user discussions.

Working upstream from the existing agile team, the process of flattening the front-end of the SE V looks like this:

• Stop decomposing system requirements

• Work with the agile team to close functional requirements via story acceptance tests

• Stop writing new functional requirements for the agile team to implement; instead, write user stories and provide business context

• Funnel new user stories into the backlog and work with the agile team to progressively elaborate, estimate, and prioritize for implementation

• Form additional agile teams to work off the backlog more quickly (if desired)

Alternatively, if a new acquisition is necessary, a lightweight PPR validates the readiness of the backlog and supporting documents to begin source selection. Meanwhile, ADE 2B ratifies the approach for putting a new agile team (or program of Agile teams) on contract. Post-source selection, the SDR becomes the program kickoff and synchronization meeting with the new agile team to ensure all parties understand the program backlog and the resources necessary to execute.

Learn more at perspecta.com

About PerspectaPerspecta brings a diverse set of capabilities to U.S. government customers in defense, intelligence, civilian, health care and state and local markets. Our 260+ issued, licensed and pending patents are more than just pieces of paper, they tell the story of our innovation. With offerings in mission services, digital transformation and enterprise operations, our team of 14,000 engineers, analysts, investigators and architects work tirelessly to not only execute the mission, but support the backbone that enables it. Perspecta was formed to take on big challenges. We are an engine for growth and success, and we enable our customers to build a better nation.