The document outlines an agile program management process tailored for DARPA's code program, emphasizing adaptive methodologies to enhance software development and ensure timely deliverables. It discusses the importance of defining work breakdown structures, release plans, and iteration management to maintain project control and align with program goals. Additionally, it highlights key success factors for agile implementation, including team environment, customer involvement, and organizational commitment to agile practices.

1. Agile Program Management Process
Applying Agile principles, practices, and processes to the CODE program.
Building the Release Plan for each program event and the deliverables for that review.

2. Agile at DARPA
• Standard Agile processes focus on software
development, with emerging requirements in a
product development context.
• The DARPA domain conducts research trade
studies and produces outcomes from Modeling
and Simulations to determine best solution
architectures and algorithms for the CODE
domain:
– Along with a small amount of coding
• Our needs are not the same as web site
developers for the local pizza shop.
2

3. The BAA Says …
• DARPA strongly encourages the use of the Agile
methodology to expedite software development
and keep up with this test schedule.
• Performers should use best commercial practices
for rapid software development, such as Agile
methodology, and leverage the simulation
environment developed in Phase 1 for frequent
and progressive validation of the software.
3

4. Our Glossary
4
DODI 5000.02 Agile
WBS – displays and defines the product, or
products, to be developed and/or produced.
Backlog – a list of deliverables which the team
maintains.
Deliverable – a tangible outcome delivered to the Government from the program
Task – lowest level work activities on the program, where budget and resources assigned to
produce deliverables.
Program Event – An assessment point that
occurs at the culmination of significant
Program Event in the Integrated Master Plan.
Release – on CODE: CoDR, SRR, DS-Interim,
PDR maturity assessments.
Rolling Wave (RW)– Converting planning
packages into detailed work packages so that
near-term effort is always detailed.
Iteration – a time box in which development of
deliverables tasks place
Rolling Wave Planning – with current
definitized RW, planning for upcoming RW’s no
further than the planning horizon.
Iteration Planning – the teams plan for work
by selecting items from the Backlog and
committing them to an iteration.
Program Event Planning in IMP/IMS
Release Planning – planning assignment of
deliverables to specific iterations and staff.

5. Agile Management Process Flow
5
WBS
Iteration 1 Iteration 2 Iteration 3 … Iteration n Close Out
 Deliverables
 Tasks
 Tasks
 Deliverables
 Deliverables
 Deliverables
 Tasks
 Tasks
CA CoDR
…
PDR
WBS basis of deliverables Backlog, per MIL-STD-881C,
decomposed into Release Backlog, then into Iteration Backlog
for delivery by Stories and Tasks.

6. CODE Program Life Cycle
Each Program Event is a Release, with Iterations (Sprints) producing
deliverables for that Release to increase maturity of outcomes
6
Release 2Release 1 Release 3 Release 4
Final Capabilities

7. Agile Program Rhythm
7
Completed
Deliverable
Requirement,
Develop, Deliver
Requirement,
Develop, Deliver
Requirement,
Develop, Deliver
Requirement,
Develop, Deliver
Completed
Deliverable
Completed
Deliverable
Completed
Deliverable
Increasing
Maturity
Program Maturity
Assessment Event
Program Maturity
Assessment Event
Program Maturity
Assessment Event
Program Maturity
Assessment Event
Iteration Management
Increasing
Maturity
Increasing
Maturity
Increasing
Maturity
 WBS defines deliverables in the Backlog.
 Allocate Backlog items to Releases and start Release Management
Release Management
Iteration Management
Release
Iteration

8. Performance Assessment
On a Weekly Basis
8
Deliverable
Task
Task
Task
Task
Planned
240 Hrs
% Complete
100%
100%
0%
0%
Remaining
80 Hours
Actual
200 Hrs
DelTek
GCS
Week 1 Week 2 Week 3 Week 4
20 Day Iteration
Every Thursday Status
 Physical Percent Complete
 Hours remaining to 100%

9. Agile for DARPA and the CODE
Program
• Enable program planning and controls with
agile process to support emerging paths of
research within the Statement of Work for the
program.
• Maintain the integrity of the cost and
schedule baseline for a DARPA procurement
contract.
• Assure delivery of winning solutions on-time
and on budget.
9

10. Agile Principles for DARPA
• Individuals and interactions over processes and tools.
– Teams of individuals will perform work in the SOW for each
deliverable.
– This work will be assessed at each iteration, release, and Program
Event
• Working software over comprehensive documentation.
– Since documents are the product of the effort, both software and
documentation will be needed
• Customer collaboration over contract negotiation.
– The relationship with the customer is done through TIMs as defined in
the SOW
• Responding to change over following a plan.
– Incremental development of the OS, DS, and Open Architecture
deliverables
DARPA adaption of the Four Agile Manifesto Statements
10

11. HANDS ON EXAMPLE
Let’s puts some Hands On for the 1st Release and the 3 Iterations of the
1st release.
Define the Deliverables for CoDR from the WBS
Define the contents of the Iterations
Breakdown the Tasks inside the Deliverables
Estimate to hours of work for the Tasks
11

12. Release Planning
• For 1st Release, using the WBS
– Define what Deliverables are assigned to the
Release from the WBS
– The definition of Done for each Deliverable is
stated in the SOW
• For example CoDR has an agenda to review the work to
date
– Determine the Resources needed for each
Deliverable from the Resource Pool
12

13. Iteration Planning
• For the Iterations in the 1st Release, using the
WBS
– Assign Deliverables to each Iteration
– Determine staff needed for each Deliverable
– Determine the Tasks performed to produce the
Deliverable
– Estimate the hours to produce the Deliverable
within that Iteration for each Task
13

14. Weekly Planning
• Every Thursday status the work progress to
date
– What is the Physical Percent Complete for each
Task – 0% or 100%
– Capture actual costs from Time Sheets completed
daily, from GCS
– Report the estimated Remaining Work for each
Task
• Program Controls will produce an analysis
14

15. NOW FOR HANDS ON
15

16. WBS Items Are the Backlog of all
Planned Work
16
Deliverable 1

17. Tasks Items Developed from each
Deliverable for the WBS
17
Task 1
Delivery
Manager

18. CONDITIONS FOR SUCCESS WITH
AGILE PROCESSES
Research shows there are several conditions for success in deploying
Agile on DOD (DARPA) programs.
We’ll need to assure these conditions are in place for CODE.

19. Agile Success Factors
19
Success Factor Evidence Success Factor Being Applied
Delivery Strategy  Regular delivery business rhythm
 Plan the delivery of important capabilities first
Agile techniques  Well defined standards of production
Team Capability  Competence and expertise
 Managers knowledgeable of agile
 Adaptive management style
Project
Management
 Agile requirements analysis and project management
 Process tracking
 Face-to-face communication
 Regular working schedule
Team Environment  Colocation of team members
 Coherent, self-organized teams
 Small teams working on weekly cycle of deliverables
 No multiple independent teams, close coordination of work
Customer
Involvement
 Good customer relationships
 Progress visible to customer on fine grained boundaries

20. Defining What Done Looks Like
in an Agile Process
• Done for Iteration is different than Done for the
Release
• Acceptance criteria for the iteration defined in the
iteration planning session
– Agreed to by the team
– Defined in the WBS Dictionary from the SOW
• Acceptance criteria for the release defined in the
release planning session
– Agreed to by the team
– Defined in the SOW for each Program Event
• Iteration retrospective assesses progress to plan
– Debt is accumulated when planned work is not completed
as planned.
20

21. Conditions for Success
• Program Lifecycle
• Team Environment
• End User Access
• Training And Coaching
• Oversight
• Incentives
• Team Composition
21

22. Program Lifecycle
• The Agile mindset starts early in the program lifecycle
• Determining how to meet program milestones is the
first step:
– OS CoDR – Release 1 (3 Mo)
– DS SRR/CoDR – Release 2 (6 Mo)
– DS-Interim – Release 3 (9 Mo)
– DS PDR – Release 4 (14 Mo)
• Create expectations and criteria to reflect the level and
type of documentation acceptable at these milestones
– Traditional levels of documentation are not produced by
Agile
– CODE defines contents
22

23. Team Environment
• Self organization is an Agile paradigm
• Centralized functions still needed
– Systems engineering
– Configuration control
– Integration and Test
– Interface management
• These centralized functions are consider constraints in
the DOD Agile paradigm
– Boundaries for defining limits on choice and interactions
– These are system boundaries that define edges of the agile
teams.
23

24. End User Access
• End use access is pragmatic in many DOD
environments.
• Single voice of the user is needed
– Recurring TIMs and monthly meeting can provide this
voice
• DOD acquisition community is usually a proxy for
the customer
– This is not likely the case for CODE
– But rapid and recurring feedback on deliverables is
needed to stay agile in absence of specific
requirements management
24

25. Training and Coaching
• Subtleties and nuances will cause confusion
and divert energy from the agile process
• A training Program Management Office
delivers agile training and coaching
• Initial and ongoing training is a critical success
factor
25

26. Oversight
• Agile has less defined over sight functions
• Management is a team functions rather than an
overseer
• Day to day functions need to be defined in a
business rhythm for all team members
• Process documentation is minimal on agile teams
and replaced with
– Big Visible Charts – showing process flows on weekly,
monthly, and quarterly boundaries
– Guidance Cards – to remember the words
– Check lists – for each status process
26

27. Incentives
• Early delivery of useful material is a primary
incentive in the Agile paradigm
• In the end, the deliverables must provide
compliant content, but focusing on cost and
schedule is secondary to value produced
27

28. Team Composition
• And Agile advocate is the anchor for success
• While end-user representatives are not likely
for CODE, a proxy for those will be needed
• Keeping the team together long enough to
achieve high performance is needed
– Multi-tasking needs to be minimized
– Key technical leads under a collective organization
28

29. EFFECTIVE PRACTICES OF AGILE
Effective Agile practices are nearly identical to effective engineering and
traditional project management practices.
The only difference is in the business rhythm cycles.
Short, compact, completely formed outcomes produced on a regular basis.

30. Effective Practices of Agile
• Planning
• Organizational Commitment
• Preparation
• Execution
• Evaluation
30

31. Planning
• Think agile, not just follow agile practices
• Allow gradual migration to agile
• Observe and communicate with other
program members
• Follow organization change discipline
• Be prepared for difficulties
• Start with Agile guidance and an Agile
adoption strategy
31

32. Organizational Commitment
• Ensure all components involved in Agile
projects are committed to the organization’s
Agile approach.
• Identify an Agile champion within senior
management.
• Ensure all teams include coaches or staff with
Agile experience.
• Empower small, cross-functional teams.
32

33. Preparation
• Train entire organization in Agile approach and mindset,
and train Agile practitioners in Agile methods.
• Ensure subject matter experts and business team members
have required knowledge.
• Enhance migration to Agile concepts using Agile terms and
examples.
• Create physical environment conducive to collaboration.
• Identify measurable outcomes, not outputs, of what you
want to achieve using Agile.
• Ensure that the definition of how a story will be
determined to be done is comprehensive and objective.
33

34. Execution
• Use same duration for each iteration.
• Capture iteration defects in a backlog tool.
• Test compliance with planned maturity of
deliverables early and often throughout the
life cycle.
34

35. Evaluation
• Obtain stakeholder / customer feedback
frequently and closely monitor corrective actions.
• Continuously improve Agile adoption at both the
project level and organization level.
• Identify and address impediments at the
organization and project levels.
• Gain trust by demonstrating value at the end of
each iteration.
• Track progress using tools and metrics.
• Track progress daily and visibly.
35

36. Agile Management Process Flow
36
WBS
Iteration 1 Iteration 2 Iteration 3 … Iteration n Close Out
 208hrs /
Iteration
 12
Deliverables
/ Iteration
 Deliverables
 Deliverables
 Deliverables
 Tasks
 Tasks
CA CoDR
…
PDR
WBS basis of deliverables Backlog, per MIL-SRTD-881C,
decomposed into Release Backlog, then into Iteration Backlog
for delivery by Stories and Tasks.
 Resources ~ 25 engineers, with 100 hours / month capacity for work
 ~31,000 hours budget over 18 months at 1,700 hours / year absorption
 2,500 hours capacity per iteration (20 work days)

37. Rules of Engagement
• Planning takes place on Iteration and Release
boundaries
– No work crosses a 20 work day increment
– No work crosses a 90 calendar day assessment of
progress to plan
• Status progress to plan done every Thursday
– DCAA daily time sheet
– Physical percent complete of tasks in Deliverable
37

38. Rules of Engagement (Concluded)
• All work to produce a deliverable is measured
as 0% / 100% complete
• This means the planning of that work has to
follow the 0/100 rules
38

39. 7 STEPS TO OUR RESOURCE
LOADED BASELINE
The key to success for CODE and beyond is Tools Follow Process
We’ll develop the process than adapt the tools to fit that process.
As a start the processes shown here are the top-level framework for
conducting the programmatic activities of the program.
39

40. Steps to Loading the Baseline Into the
Program Management Tools
1. Establish Releases
2. Establish Iterations within each release
3. Establish Stories from the WBS and allocate
them to each release
4. Assign resources to each Story
5. Estimate work effort – in hours – to each story
6. Assess if capacity for work ≥ demand for work
7. Repeat Steps 4, 5, and 6 until demand equals
capacity
40

41. Establish Releases
• The current release plan is
– CoDR
– DS-SRR/CoDR
– DS-Interim DR
– DS-PDR
– Phase 1 Final Report
• Each release will have iterations to produce the
outcomes of those “Events”
41
Releases are “mini-projects” and treated as
“deliverables” of fully formed outcomes

42. Establish Iterations Inside Releases
• Iterations are planned for 20 work days each
and fit inside the Release Cycle
– CoDR = 3 Iterations
– DS-SRR/CoDR = 3 iterations
– DS-Interim DR = 3 Iterations
– DS-PDR = 3 Iterations
42
Daily standups confirm not only work for the day,
week, and Iteration, but impediments to progress
that must be removed “today”

43. Establish Stories Inside Iterations
• Stories deliver terminal node WBS elements
• Walking the WBS, the program team layouts
out the Stories against the WBS elements
• Each story
– Produces a single outcome of a WBS element
– Takes up to 20 working days to complete
– Is 100% complete, no revisiting the Story
43
Requirements Churn is just as much a problem in
Agile as it is in Traditional projects

44. Assign Resources to Stories
• With Stories laid into Iteration assign staff to
perform the work
– Named resources assigned to each story
– Can have multiple staff assigned to a Story for its
completion
• Assure staff availability in the resource calendar
– Commitment to perform is a Critical Success Factor
44
Resource commitments for the period-of-
performance assure sustainable “throughput”

45. Estimate Work Effort for Those
Resources
• Use proposal BOE’s as a start of effort
estimation
• Revisit those to confirm understanding,
estimates, and outcomes
• Load the work effort estimates into the
project management tool
45
All estimates need to be adjusted for naturally
occurring variance and event-based risk

46. Assess Capacity for Work Against
Demand for Work
• Compare demand for work against capacity for
work
• Assure sufficient capacity for the demand before
proceeding
• If demand higher than capacity, re-plan work to
level demand
• The Grooming of the Backlog is critical to
controlling the progress to plan
46
Closed loop control of demand versus capacity has
a weekly sampling interval

47. BACKUP
47

48. Vocabulary
Work Breakdown Structure
• MIL-STD-881-C tells us …
– All portions of the program are covered.
– This all-in requirement assures all deliverables are
identified in the WBS.
– The WBS facilitates collaboration between the team
members by tying performance, cost, schedule, and
risk information.
– The WBS facilitates the required technical rigor and
integrated test and evaluation throughout the
acquisition process.
– The WBS is the first location to define the risks to
achieving the above items in this list
48

49. Vocabulary (Continued)
Deliverables
• Agile focuses on outcomes rather than activities
• Our outcomes are listed in the BAA (and SOW from the
contract)
– Trade studies
– Open Architecture
– Transition Plan
– MOP definitions
– Various reports
• The agile planning process, won’t detail how to
produce these, just that they are produced.
• The agile planning process is not a schedule
49

50. Vocabulary (Continued)
Release Planning
• Release planning is not scheduling
• The backlog of Deliverables from the WBS are
assigned to Iterations within a Release
• The Team …
– Comprehends the work of the Release
– Shares the understanding of what it takes to produce
the release
– Agrees on the actions needed to formalize the plan
– Baselines this confidence with all the stakeholders
– Results in collective ownership of the plan, any need
to replanning, and communication within the team
50