Agile in the government

+

Agile Software Development for Government Software Intensive System of Systems (SISoS)Boulder Agile Meetup, 27 July 20166:00 PM CA Rally

Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2016

If we’re looking to increase the probability of success for Software Intensive System of Systems (SISoS), look to where that effort can produce the highest return for the investment.

The 2016 IT budget for Federal Agencies is ‒

$81,600,000,000.00

+Learning Objectives for Tonight

n What do we mean when we say Agile on Government programs? n It may not mean what you think it does.

n The many myths of Government IT Acquisition n Waterfall has been dead for 20 years.

n Using Earned Value on Agile programs n FAR 34.2/DFARS 234.2 ‒ is standard acquisition policy for programs

greater than $20M.

n Connecting the Dots between Agile and Government Acquisition of IT products and services is now appearing in contracting language.

n Risk Management is How Adults Manage Projects ‒ Tim Listern Agile alone is NOT Risk Management


2

3

Individuals and Interactions

OVERProcesses and

Tools

Working Software

OVERComprehensiveDocumentation

Customer Collaboration

OVERContract

Negotiation

Responding to Change

OVERFollowing the

Plan

The BIG Question for Government ‒ can we have?

+ Department of Defense Systems are Characterized by …n MILLIONS TO 10’S OF MILLIONS OF LINES OF CODE

n My current client has a code base of 2,000,000 lines of National Asset

n INTEGRATION WITH LEGACY SYSTEMS IN LEGACY SOFTWARE LANGUAGES

n Fortran 77 since basis of Missile Defense Systems

n REAL-TIME DATA AND CONTROL

n High integrity systems are the norm, not the exception

n STANDARDS-BASED

n Architecture, data protocols, hardware interfaces, data structures

n FORMAL REVIEW PROCESSES

n Independent Verification & Validation n Cyber security

n COMPLEX “REQUIREMENTS” FROM MULTIPLE STAKEHOLDERS

n Systems Modeling Languages, formal requirements management tools


4

+ What Do We Mean By Agile Software Development in the Government?

† Dr. Ashton Carter, Under Secretary of Defense for Acquisition, Technology and Logistics, Sep/Oct, 2010 Defense AT&L

Pembroke Welsh Corgi in a goat herding competition, Boulder County Fair, Longmont Colorado.Chubby body, short legs, not “lean,” but able to turn “inside the loop” of the sheep = “agile”

Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 ― 2016

5

+Agile in the Federal Government

6


In 2016, more and more government agencies will need to address the demand for speed, innovation, and cost containment. The pressure put on organizations to do this effectively yields the need for scalability of lean Agile development efforts broadly programs and portfolios.

Taking components of successful Agile development processes completed by smaller teams, such as continuous feedback loops, prioritization for value, more frequent development cycles, and increased collaboration, and replicating that on a larger scale will be vital for government agencies in 2016.

Emerging models, such as Scaled Agile Framework, which has been shown to return 30 to 50 percent improvements in productivity and quality, as well as a 200 to 300 percent improvement in time to market versus traditional delivery methods, will gain even more traction in Washington as agencies look to expand efficiencies, both vertically and horizontally.‒ http://www.businesswire.com/news/home/20151214005838/en/Booz-Allen-Experts-Predict-Trends-Impact-Government

Do these sound

familiar?

Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 ― 2016 7A Closer Look at 804: A Summary of Considerations for DoD Program Managers, Stephany Bellomo, CMU/SEI-2011-SR-015

+ Large Government Projects Have Unique Needs†

n Owning the Technical Baselinen Controlling software and hardware that evolve over time requires Program

Management and technologist to maintain a deep understanding of the system and its implementation – defined capabilities are established on contract

n This can be done with Open Systems Architecture (MOSA), technical reference frameworks, standards based development and other architecture frameworks ‒ emergent architectures are not allowed

n Incremental, Iterative, or Agile?n Iterative and Incremental have been in place since the early days of software

development. n 1980 TRW had iterative and incremental development for programs

n Challenges and Successesn Fast Feedback ‒ many processes require longer periods of work.n Slicing ACAT-I programs into several releases ‒ based on operational

architecturen To deliver frequent releases ‒ Development Test (DT) and Operational Test

(OT) organization must adapt to agile processes.


8

† Helping Large Government programs Adopt and Adapt to Agile Methods, Harry Levison, SEI, 13 June 2016

+ Agile at Scale, means having a Roadmap toward the destination†

† “Parallel Worlds: Agile and Waterfall Differences and Similarities,” Carnegie Mellon University, http://goo.gl/c9O2Id

4. Framing Assumptions


9

+ How Agile Benefits Government Programs†

n First ask How Long Are We Willing To Wait Before You Find Out We Are Late?

n The answer needs to be Short Enough To Take Corrective Actions To Stay On Plan.

n Agile forces the answer to that question to be produced every four weeks.

n With Agile’s working software Physical Percent Complete can be used to calculate EV every four weeks.

† “Adapting Agile to the Defense Acquisition Framework,” Mary Ann Lapham, Software Engineering Institute, Carnegie Mellon University


10

+ What Type of Program Are We Working?†

n Without establishing the baseline of what kind of Agile program we’re working, we can’t determine what processes will be appropriate for integrating Agile with Government procurement.

† “Context–Adaptive Agility: Managing Complexity and Uncertainty,” Todd Little, IEEE Software, May/June, 2005


11

+ Capabilities Based Planning is a Common Language Between Agile and Government Development Processes

12


Material converted end–to–end

Pilot

Data

Enrollment

Integrators

Quality Monitor

Internal

Router

Data Store Lookup

Data Warehouse

Data Marts

Data Marts

Portals and others

Billing

Demo conversion process, member reconciliation

Shared group matrix reports and interfaces

Shared member crosswalk and members to ERP

Integrators in ERP converted to inventory

Status and trigger conversions

Data in Marts for ERP

Material Master Converted from legacy

External InterfacesExternal Vendors converted to ERP

Finance Loss TBD

Resale's Vendors from legacy

Emulations

+

n Efficacy of the Budget (PV) ‒ is a dollar spent is a dollar earned?

n Release date based on EVM’s risk adjusted Estimate to Complete and Estimates At Completion ‒ not just Story Point Burndown charts.

n Baseline cost per Story point to convert agile estimating into EVM estimating.

n Project progress visibility in units of cost and schedule compared to the planned measures of progress.

n Mandatory production of working product every 4 weeks.

n Measures of Physical Percent Complete supported by Definition of Done, mandatory rather than optional.

n Measures of productivity, quality, and responsive to end user Features and Capabilities, not just cost and schedule.

Value of EVM for Agile Value of Agile for EVM

Value Proposition for Integrating Earned Value Management with Agile†

† “AgileEVM – Earned Value Management in Agile Projects,” Tamara Sulaiman, Brent Barton, and Thomas Blackburn,


13

+ Integration Across a Bright Line Between Agile and Government Processes Provides Actionable Information to all Decision Makers

Performance Reporting from Work Package PerformancePerformance• Budget – from WBS

Basis of Estimate• Cost – from time

cards• Value – from

completed Story Points

n Starting with Releases, Capabilities are flowed to the PMBn Capabilities produce the value from each Releasen Control Accounts and Work Packages are on baseline in the PMBn Work Packages contain Features produced in each Release by Sprintsn Release Planning baseline for period of performance and PV

Cadence Release 1 Cadence Release n

Feature 1,2,3Feature 4, .. ,8

Feature 9, …,12

Release 2 PP’s

WPPP

SLPPin IMS

CA

Sprints

Time Now

Performance Measurement Baseline

Agile Software Development Lifecycle

Feature n’s

The Bright Line

Milestones

Data Items

Releases

Capabilities in a Release

Agile Development Control Account

Task

Task

Task

Task

Task

Task

Task

Task

Task

…

n Feature ACP % = Completed / Plannedn Feature hours = Bottom Up from Task Estimaten Feature remaining hours = TO DO hours in

agile tool for Tasks, to Stories, to Features


14

+Process Flow on Government Agile Projects

15


❶ StartingwiththeRoughOrderofMagnitudefromthecustomersneededFeatureselicitedfromtheCapabilities,layoutouttheFeaturesinthelogicalsequenceintheProductRoadmap.ThisestimateincludesthehoursneededtoimplementtheFeatureandthesequenceoftheFeaturestoproducetheCapabilitiesforthecustomer’sbusinessneeds.

❷ WiththesequenceofFeature,thecontentsoftheProductRoadmapupdateandtheReleasePlanforthoseFeaturesbuilt.ThisshowswhatFeatureswillbeproducedineachReleasetomatchtheProductRoadmap.

❸ WiththeProductRoadmapandRelease,placetheFeaturesontheProductBacklogwithestimatesfromtheROMandStoryPoints‒iftheyareusedtoprioritizetheFeatures.Thisisanoption,butprovidesaneasywaytoassessprioritizesofbusinessvalueindependentofthecostordurationoftheefforttoproducetheFeatures.

❹ FromtheFeaturesinRally,updatetheIMSwithwhichFeaturesbelongsineachSprint.ThishasbeendefinedintheROM,foratimephasedPlannedValue.

❺ DuringtheSprint,updatetheTODOfieldinRally.ThisresultsinthecalculationofPhysicalPercentCompletefortheStoryintheSprint,andtheFeaturefromtheStories.

+ Connecting the Dots between all the moving parts

16


+ Setting Up for Earned Value in an Agile Development Tool

17


+ Measuring Physical Percent Complete at Feature and Story

18


+ A Critical Understanding about Planning in Agile and Government

In Government Planning In Agile Planning

Work Duration is estimated for the deliverables in the Work Breakdown Structure.

Work placed in fixed time boxes insideSprints on fixed boundaries – Time Boxed Scheduling.

Sequence of work defined during planning process. The result is delivery dates defined by the network of activities in the Integrated Master Schedule (IMS).

Sequence driven by priority of work defined by the customer, selected from the Product Backlog.

Work efforts continue in sequenced Work Packages until planned outcomes are delivered.

Work effort fixed inside the Sprint with a fixed team. At end of Sprint work stops. Unfinished work returned to Product Backlog

“Programs may have a relatively clear mission, but the specific requirements can be volatile and evolving as customers and development teams alike explore the unknown.” – Jim Highsmith, “What is Agile Software Development?” Cross Talk, The Journal of Defense Software Engineering, October 2002, pp. 4–9


19

+ The Agile Manifesto and Government Contracts

20


Agile Manifesto Government Contracting

Individuals and

InteractionsOver

Process and Tools

Processes are the basis of ProgramPlanning and Controls. The funding comes from a sovereign and mandates governance processes be in place.

Working Software

OverComprehensive Documentation

The ability of the government to accept working software on 2 week boundaries must be carefully assessed

Customer Collaboration

OverContract Negotiation

The Federal Acquisition Regulation trumps all naïve approaches to spending the government’s money

Respondingto Change

OverFollowing a Plan

Change control is applied at the Contract End Item Deliverables

+ 12 Principles of Agile and Government Procurement

21


❶ Early and Continuous Delivery of

Valuable Software

❼ A Working System is the

Primary Measure of Progress

❷ Welcome Changing

Requirements

❸ Frequent Delivery of the

Working Software from few weeks to

a few months

❹ Business People and

Developers Work Together Daily

❺ Individuals are Motivated and

Empowered

❽ Conversations are Face-to-Face

❻ Sustainable Development is

Promoted by Leadership

❾ Continuous Attention to Technical

Excellence

❿ Simplicity in All Things

⓫ Architecture, Requirements, and Designs

Emerge from Self-Organizing Teams

⓬ Teams Regularly Reflect

on How to Be More Effective

The Big QuestionHow Does Agile Development Fit Into An Overall Process Needed to Improve the Probability of Program Success?

Systems Engineering

RiskManagement

Lifecycle LogisticsTest &

Evaluation

Affordability and Lifecycle Resources

Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 ― 2016 22

+ Government Program’s Start with Systems Engineering Measuresn Measures of Effectiveness (MOE) ‒ Operational measures of

success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions.

n Measures of Performance (MOP) ‒ characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions.

n Technical Performance Measures (TPM) ‒ represent the capabilities and characteristics so significant that failure to meet them can be cause for reevaluation, reassessing, or termination of the program.

n Key Performance Parameters (KPP) ‒ determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal.


23

+ SISoS Development Is About Systems Engineering

24


Assembly, Test, and Delivery

System Architecture &

Capabilities§ Iterative Agile Development § Emergent Design within the

Architecture§ Requirements Derivation from the

Capabilities

KPPOperational

MOPFunctional

TPM

MOEOperational

Delivery&Acceptance

IntegrationVerificationValidation

AgileDevelopmentwithinFramework

+

n Forecasting Estimate to Complete (ETC) and Estimate At Completion (EAC) in units of measure meaningful to the decision makersn Risk adjusted Dollars and Time for the delivery of project Value

n Using Physical Percent Complete from the Agile Task level that implements each Story ‒ to roll this measure to the Feature in the Product Backlogn Agile measures Story Points completed, but those Story Points are not

connected to Physical Percent Complete of the delivered Valuen Using Planned Value (BCWS) and Earned Value (EV) shows actual progress

to plan not possible by just measuring burn down of Story Points

n Story Points have no meaning to Program Management on government programs ‒ nor commercial program either.

Increasing the Probability of Program Success (PoPS) must be the goal of any program management process

What are the Unassailable Beneficial Outcomes of Applying EVM to Agile?

5. Foundations of EVM


25

+Connecting the Dots

26


Agile Government

Incremental and Iterative Development

Short duration deliverables, 44 Day rule.Rolling wave planning for future workFeatures derived from Capabilities

Working Software

Physical Percent Complete using Measures of Effectiveness, Measures of Performance, Technical Performance Measures, and Key Performance Parameters

Emergent Requirements

Stable Capabilities in support of Mission and Vision, Emergent Requirements to fulfill those CapabilitiesCapabilities Based Planning

+ Risk Management is How Adults Manage Projects ‒ Tim Lister

27


Uncertainty

Irreducible(Aleatory)

Reducible(Epistemic)

NaturalVariability

Ambiguity

OntologicalUncertainty

ProbabilisticEvents

ProbabilisticImpacts

PeriodsofExposure

+ Project Success Depends on Many Things …

n When driving the project in the absence of desired outcomes – the project goal – without units of measure meaningful to the decisions makers …

… Some technical, some managerial, some political, some economic. But they’re all connected in a closed loop system.

n It’s like driving in the rear view mirror. ‒ It can be done, but you don’t know you ran over anything until you it’s too late.

n Close Loop Control provides the headlights to see where you’re going and what’s in the way of your progress

n Open Loop Control has no desired outcome in terms of delivery date, cost, and needed capabilities, defined before you start and during you trip, so you’ll only know where you’re going when you arrive.


28


Backup Slides

+GREEN Connections

30


❶ Early and Continuous Delivery of

Valuable Software

❼ A Working System is the

Primary Measure of Progress

❸ Frequent Delivery of the

Working Software from few weeks to

a few months

Frequent delivery provides several advantages. Customers get to see what they’ve asked for to confirm it’s still what they need. Closed loop control must sample for the error single fast enough to take correction action. The value of Value evolves, frequent confirmation needed.

Any good project management system bases its performance assessment on working product, never on the passage of time and consumption of money.Agile forces this paradigm.

The best measure of progress to plan is the assessment of a working product against the planned Effectiveness and Performance.Working system means every single component of the outcomes of the project.

+GREEN Connections

31


A sustainable pace starts with the plan for the needed capacity for work, the needed capabilities of that team, and the leadership to assure those resources have all they need to sustain that capacity and possess those capabilities.

All project success depends on the right people, following the right processes, using the right procedures, to produce the right outcomes, at the right time, for the right cost.

❺ Individuals are Motivated and

Empowered

❻ Sustainable Development is

Promoted by Leadership

It’s illogical to not focus on technical excellence.Do this by defining what technical excellence is up front is mandatory. This means Measures of Effectiveness (MOE), Measures of Performance (MOP), Technical Performance (TPM), and Key Performance Parameter (KPP).

❾ Continuous Attention to Technical

Excellence

+Almost GREEN Connections

32


Feedback is core to the closed loop control system needed to keep the project on plan.Continuous delivery of planned value for planned cost, at planned time requires this closed loop control. The communication is nosier on Government Programs.

⓬ Teams Regularly Reflect

on How to Be More Effective

Systems engineering seeks a technical and programmatic architecture that maximize the probability of success.This success starts with a simple and effective solutions that scale and respond to emerging requirements as complexity grows.

❿ Simplicity in All Things

In most instances, government buyers of software products or services are not co-located with development teams. This puts a burden on the Product Owner to have much greater visibility to customer needs.

❹ Business People and

Developers Work Together Daily

+Moving from GREEN Connections

33


The procurement of software and services by the Government restricts the interaction between the two parties.Agile contracting must be improved to address this gap

❽ Conversations are Face-to-Face

Requirements change, but Capabilities are stable.Changing requirements must to be tested against capabilities for confirm the need for change.While welcome is an agile term, on government contracts, changing requirements requires change control.

❷ Changing Requirements are

Welcome

In government system, architecture is many times defined externally ‒ DoDAF, MOSA, JFMIP, ToGAF, Financial Management Systems Architecture are examples.Emergent architectures are possible in domains where Enterprise interoperability is mandatory.

⓫ Architecture, Requirements, and Designs

Emerge from Self-Organizing Teams

+ResourcesThis briefing is not from Whole Cloth. Many have come before and many will come afterward. The resources listed here are the starting point for anyone interested in applying the principles developed in this briefing for integrating Agile with Earned Value Management projects

Knowledge is of two kinds. We know a subject ourselves, or we know where we can find information upon it – Samuel Johnson


+Resources (A Very Small Sample)

n http://www.afei.org/WorkingGroups/ADAPT/Documents/Forms/AllItems.aspx ‒program management with Agile in the Federal Government

n http://www.sei.cmu.edu/reports/10tn002.pdf ‒ Considerations for Using Agile in DoD Acquisition

n https://www.mitre.org/sites/default/files/publications/MITRE-Defense-Agile-Acquisition-Guide.pdf ‒ Defense Agile Acquisition Guide

n https://www.mitre.org/sites/default/files/pdf/11_0401.pdf ‒ Handbook for Implementing Agile in Department of Defense Information Technology Acquisition

n http://www.dau.mil/pubscats/ATL%20Docs/Jan_Feb_2013/Broadus.pdf ‒ The Challenges of Being Agile in DoD

n http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20120013429.pdf ‒ Agile Development Methods in Space Operations

n http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.473.6590&rep=rep1&type=pdf ‒ Should NASA Embrace Agile Processes?

n http://www4.ncsu.edu/~scarpen/Research_files/Agile_Suitability_to_Space_Based_SE_FINAL.pdf ‒ Is Agile too Fragile for Space-Based Systems Engineering?


35

+Resources (A Very Small Sample)

n http://www.acq.osd.mil/evm/resources/Agile_EVM_Home.shtml ‒ March 2016 meeting at PARCA (Performance Assessment and Root Cause Analysis) for Agile and EVM: A Program Managers Desk Guide

n http://www.acq.osd.mil/evm/resources/DoDAgileSep2015.html ‒ DoD Agile Meeting” Enhancing Adoption Agile Software Development in DOD ‒ September 2015.

n http://www.acq.osd.mil/evm/resources/EVM-Agile%20Meeting.html ‒ EVM and Agile Software Development Open Meeting – February 2015.


36


37

Agile in the government

Technology

Transcript of Agile in the government