Agile in the government

+
Agile Software Development for Government
Software Intensive System of Systems (SISoS)
Boulder Agile Meetup, 27 July 2016
6: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 Lister
n Agile alone is NOT Risk Management
2

3
Individuals and
Interactions
OVER
Processes and
Tools
Working
Software
OVER
Comprehensive
Documentation
Customer
Collaboration
OVER
Contract
Negotiation
Responding to
Change
OVER
Following 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 IndependentVerification &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
PembrokeWelsh 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 inWashington 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 7
A 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 Baseline
n 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 Successes
n Fast Feedback ‒ many processes require longer periods of work.
n Slicing ACAT-I programs into several releases ‒ based on operational
architecture
n 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 AreWe
Willing ToWait BeforeYou Find
OutWe 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 Interfaces
External 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 Performance
Performance
• Budget – from WBS
Basis of Estimate
• Cost – from time
cards
• Value – from
completed Story
Points
n Starting with Releases, Capabilities are flowed to the PMB
n Capabilities produce the value from each Release
n Control Accounts and Work Packages are on baseline in the PMB
n Work Packages contain Features produced in each Release by Sprints
n Release Planning baseline for period of performance and PV
Cadence Release 1 Cadence Release n
Feature 1,2,3
Feature 4, .. ,8
Feature 9, …,12
Release 2 PP’s
WP
PP
SLPP
in 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 / Planned
n Feature hours = Bottom Up from Task Estimate
n Feature remaining hours = TO DO hours in
agile tool for Tasks, to Stories, to Features
14

+
Process Flow on Government Agile Projects
15
❶ Starting with the Rough Order of Magnitude from the customers needed Features
elicited from the Capabilities, layout out the Features in the logical sequence in the
Product Roadmap. This estimate includes the hours needed to implement the Feature
and the sequence of the Features to produce the Capabilities for the customer’s
business needs.
❷ With the sequence of Feature, the contents of the Product Roadmap update and the
Release Plan for those Features built. This shows what Features will be produced in each
Release to match the Product Roadmap.
❸ With the Product Roadmap and Release, place the Features on the Product Backlog with
estimates from the ROM and Story Points ‒ if they are used to prioritize the Features.
This is an option, but provides an easy way to assess prioritizes of business value
independent of the cost or duration of the effort to produce the Features.
❹ From the Features in Rally, update the IMS with which Features belongs in each Sprint.
This has been defined in the ROM, for a time phased Planned Value.
❺ During the Sprint, update the TO DO field in Rally. This results in the calculation of
Physical Percent Complete for the Story in the Sprint, and the Feature from the Stories.

+ 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 inside
Sprints 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
Interactions
Over
Process and
Tools
Processes are the basis of Program
Planning and Controls.The funding
comes from a sovereign and mandates
governance processes be in place.
Working
Software
Over
Comprehensive
Documentation
The ability of the government to
accept working software on 2 week
boundaries must be carefully
assessed
Customer
Collaboration
Over
Contract
Negotiation
The Federal Acquisition Regulation
trumps all naïve approaches to
spending the government’s money
Responding
to Change
Over
Following 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 Question
How Does Agile Development Fit Into An Overall Process
Needed to Improve the Probability of Program Success?
Systems
Engineering
Risk
Management
Lifecycle
LogisticsTest &
Evaluation
Affordability
and Lifecycle
Resources

+ Government Program’s Start with
Systems Engineering Measures
n 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
KPP
Operational
MOP
Functional
TPM
MOE
Operational
Delivery &
Acceptance
Integration
Verification
Validation
Agile Development within Framework

+
n Forecasting Estimate to Complete (ETC) and Estimate At Completion
(EAC) in units of measure meaningful to the decision makers
n 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 Backlog
n Agile measures Story Points completed, but those Story Points are not
connected to Physical Percent Complete of the delivered Value
n 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 work
Features 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 Capabilities
Capabilities Based Planning

+ Risk Management is How Adults
Manage Projects ‒ Tim Lister
27
Uncertainty
Irreducible
(Aleatory)
Reducible
(Epistemic)
Natural Variability
Ambiguity
Ontological
Uncertainty
Probabilistic Events
Probabilistic
Impacts
Periods of Exposure

+ 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

+
Resources
This 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&typ
e=pdf ‒ Should NASA Embrace Agile Processes?
n http://www4.ncsu.edu/~scarpen/Research_files/Agile_Suitability_to_Space_Based_S
E_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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (7)

Similaire à Agile in the government

Similaire à Agile in the government (20)

Plus de Glen Alleman

Plus de Glen Alleman (20)

Dernier

Dernier (20)

Agile in the government