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

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

2. Agile
at
WSRI
• Standard
Agile
processes
focus
on
soFware
development,
with
emerging
requirements
in
a
product
development
context.
• The
WSRI
domain
conducts
research
trade
studies
and
produces
outcomes
from
Modeling
and
Simula8ons
to
determine
best
solu1on
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
soFware
development
and
keep
up
with
this
test
schedule.
• Performers
should
use
best
commercial
prac8ces
for
rapid
soFware
development,
such
as
Agile
methodology,
and
leverage
the
simula8on
environment
developed
in
Phase
1
for
frequent
and
progressive
valida8on
of
the
soFware.
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
ac8vi8es
on
the
program,
where
budget
and
resources
assigned
to
produce
deliverables.
Program
Event
–
An
assessment
point
that
occurs
at
the
culmina8on
of
significant
Program
Event
in
the
Integrated
Master
Plan.
Release
–
on
CODE:
CoDR,
SRR,
DS-­‐Interim,
PDR
maturity
assessments.
Rolling
Wave
(RW)–
Conver8ng
planning
packages
into
detailed
work
packages
so
that
near-­‐term
effort
is
always
detailed.
IteraBon
–
a
1me
box
in
which
development
of
deliverables
tasks
place
Rolling
Wave
Planning
–
with
current
defini8zed
RW,
planning
for
upcoming
RW’s
no
further
than
the
planning
horizon.
IteraBon
Planning
–
the
teams
plan
for
work
by
selec8ng
items
from
the
Backlog
and
commiYng
them
to
an
itera8on.
Program
Event
Planning
in
IMP/IMS
Release
Planning
–
planning
assignment
of
deliverables
to
specific
itera8ons
and
staff.

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

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

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
IteraBon
Management
Increasing
Maturity
Increasing
Maturity
Increasing
Maturity
§ WBS
defines
deliverables
in
the
Backlog.
§ Allocate
Backlog
items
to
Releases
and
start
Release
Management
Release
Management
Itera8on
Management
Release
Itera8on

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
Itera8on
Every
Thursday
Status
§ Physical
Percent
Complete
§ Hours
remaining
to
100%

9. Agile
for
WSRI
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
solu8ons
on-­‐8me
and
on
budget.
9

10. Agile
Principles
for
WSRI
• Individuals
and
interac/ons
over
processes
and
tools.
– Teams
of
individuals
will
perform
work
in
the
SOW
for
each
deliverable.
– This
work
will
be
assessed
at
each
itera8on,
release,
and
Program
Event
•
Working
so6ware
over
comprehensive
documenta/on.
– Since
documents
are
the
product
of
the
effort,
both
soFware
and
documenta8on
will
be
needed
•
Customer
collabora/on
over
contract
nego/a/on.
– The
rela8onship
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
WSRI
adap1on
of
the
Four
Agile
Manifesto
Statements
10

11. HANDS
ON
EXAMPLE
Let’s
puts
some
Hands
On
for
the
1st
Release
and
the
3
Itera8ons
of
the
1st
release.
Define
the
Deliverables
for
CoDR
from
the
WBS
Define
the
contents
of
the
Itera8ons
Breakdown
the
Tasks
inside
the
Deliverables
Es8mate
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
defini8on
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. Itera8on
Planning
• For
the
Itera/ons
in
the
1st
Release,
using
the
WBS
– Assign
Deliverables
to
each
Itera/on
– Determine
staff
needed
for
each
Deliverable
– Determine
the
Tasks
performed
to
produce
the
Deliverable
– Es8mate
the
hours
to
produce
the
Deliverable
within
that
Itera/on
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
es8mated
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
Deliverable
2
Deliverable
3
Deliverable
4
Deliverable
5
IteraBon
1
Backlog
Items
From
WBS

17. Tasks
Items
Developed
from
each
Deliverable
for
the
WBS
17
Task
1
Task
2
Task
3
Task
4
Task
5
Deliverable
1
Delivery
Manager

18. CONDITIONS
FOR
SUCCESS
WITH
AGILE
PROCESSES
Research
shows
there
are
several
condi8ons
for
success
in
deploying
Agile
on
DOD
(DARPA)
programs.
We’ll
need
to
assure
these
condi8ons
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
capabili8es
first
Agile
techniques
§ Well
defined
standards
of
produc8on
Team
Capability
§ Competence
and
exper8se
§ Managers
knowledgeable
of
agile
§ Adap8ve
management
style
Project
Management
§ Agile
requirements
analysis
and
project
management
§ Process
tracking
§ Face-­‐to-­‐face
communica8on
§ Regular
working
schedule
Team
Environment
§ Coloca8on
of
team
members
§ Coherent,
self-­‐organized
teams
§ Small
teams
working
on
weekly
cycle
of
deliverables
§ No
mul8ple
independent
teams,
close
coordina8on
of
work
Customer
Involvement
§ Good
customer
rela8onships
§ Progress
visible
to
customer
on
fine
grained
boundaries

20. Defining
What
Done
Looks
Like
in
an
Agile
Process
• Done
for
Itera8on
is
different
than
Done
for
the
Release
• Acceptance
criteria
for
the
itera1on
defined
in
the
itera8on
planning
session
– Agreed
to
by
the
team
– Defined
in
the
WBS
Dic8onary
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
• Itera8on
retrospec8ve
assesses
progress
to
plan
– Debt
is
accumulated
when
planned
work
is
not
completed
as
planned.
20

21. Condi8ons
for
Success
• Program
Lifecycle
• Team
Environment
• End
User
Access
• Training
And
Coaching
• Oversight
• Incen8ves
• Team
Composi8on
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
expecta8ons
and
criteria
to
reflect
the
level
and
type
of
documenta8on
acceptable
at
these
milestones
– Tradi8onal
levels
of
documenta8on
are
not
produced
by
Agile
– CODE
defines
contents
22

23. Team
Environment
• Self
organiza8on
is
an
Agile
paradigm
• Centralized
func8ons
s8ll
needed
– Systems
engineering
– Configura8on
control
– Integra8on
and
Test
– Interface
management
• These
centralized
func8ons
are
consider
constraints
in
the
DOD
Agile
paradigm
– Boundaries
for
defining
limits
on
choice
and
interac8ons
– These
are
system
boundaries
that
define
edges
of
the
agile
teams.
23

24. End
User
Access
• End
use
access
is
pragma8c
in
many
DOD
environments.
• Single
voice
of
the
user
is
needed
– Recurring
TIMs
and
monthly
mee8ng
can
provide
this
voice
• DOD
acquisi8on
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
• Subtle8es
and
nuances
will
cause
confusion
and
divert
energy
from
the
agile
process
• A
training
Program
Management
Office
delivers
agile
training
and
coaching
• Ini8al
and
ongoing
training
is
a
cri8cal
success
factor
25

26. Oversight
• Agile
has
less
defined
over
sight
func8ons
• Management
is
a
team
func8ons
rather
than
an
overseer
• Day
to
day
func8ons
need
to
be
defined
in
a
business
rhythm
for
all
team
members
• Process
documenta8on
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. Incen8ves
• Early
delivery
of
useful
material
is
a
primary
incen8ve
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
Composi8on
• And
Agile
advocate
is
the
anchor
for
success
• While
end-­‐user
representa8ves
are
not
likely
for
CODE,
a
proxy
for
those
will
be
needed
• Keeping
the
team
together
long
enough
to
achieve
high
performance
is
needed
– Mul8-­‐tasking
needs
to
be
minimized
– Key
technical
leads
under
a
collec8ve
organiza8on
28

29. EFFECTIVE
PRACTICES
OF
AGILE
Effec8ve
Agile
prac8ces
are
nearly
iden8cal
to
effec8ve
engineering
and
tradi8onal
project
management
prac8ces.
The
only
difference
is
in
the
business
rhythm
cycles.
Short,
compact,
completely
formed
outcomes
produced
on
a
regular
basis.

30. Effec8ve
Prac8ces
of
Agile
• Planning
• Organiza8onal
Commitment
• Prepara8on
• Execu8on
• Evalua8on
30

31. Planning
• Think
agile,
not
just
follow
agile
prac8ces
• Allow
gradual
migra8on
to
agile
• Observe
and
communicate
with
other
program
members
• Follow
organiza8on
change
discipline
• Be
prepared
for
difficul8es
• Start
with
Agile
guidance
and
an
Agile
adop8on
strategy
31

32. Organiza8onal
Commitment
• Ensure
all
components
involved
in
Agile
projects
are
commimed
to
the
organiza8on’s
Agile
approach.
• Iden8fy
an
Agile
champion
within
senior
management.
• Ensure
all
teams
include
coaches
or
staff
with
Agile
experience.
• Empower
small,
cross-­‐func8onal
teams.
32

33. Prepara8on
• Train
en8re
organiza8on
in
Agile
approach
and
mindset,
and
train
Agile
prac88oners
in
Agile
methods.
• Ensure
subject
mamer
experts
and
business
team
members
have
required
knowledge.
• Enhance
migra8on
to
Agile
concepts
using
Agile
terms
and
examples.
• Create
physical
environment
conducive
to
collabora8on.
• Iden8fy
measurable
outcomes,
not
outputs,
of
what
you
want
to
achieve
using
Agile.
• Ensure
that
the
defini8on
of
how
a
story
will
be
determined
to
be
done
is
comprehensive
and
objec8ve.
33

34. Execu8on
• Use
same
dura8on
for
each
itera8on.
• Capture
itera8on
defects
in
a
backlog
tool.
• Test
compliance
with
planned
maturity
of
deliverables
early
and
oFen
throughout
the
life
cycle.
34

35. Evalua8on
• Obtain
stakeholder
/
customer
feedback
frequently
and
closely
monitor
correc8ve
ac8ons.
• Con8nuously
improve
Agile
adop8on
at
both
the
project
level
and
organiza8on
level.
• Iden8fy
and
address
impediments
at
the
organiza8on
and
project
levels.
• Gain
trust
by
demonstra8ng
value
at
the
end
of
each
itera8on.
• Track
progress
using
tools
and
metrics.
• Track
progress
daily
and
visibly.
35

36. Agile
Management
Process
Flow
36
WBS
IteraBon
1
IteraBon
2
IteraBon
3
…
IteraBon
n
Close
Out
§ 208hrs
/
Itera8on
§ 12
Deliverables
/
Itera8on
§ Deliverables
§ Deliverables
§ Deliverables
§ Tasks
§ Tasks
CA
CoDR
…
PDR
WBS
basis
of
deliverables
Backlog,
per
MIL-­‐SRTD-­‐881C,
decomposed
into
Release
Backlog,
then
into
Itera8on
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
absorp8on
§ 2,500
hours
capacity
per
itera8on
(20
work
days)

37. Rules
of
Engagement
• Planning
takes
place
on
Itera8on
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
8me
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
conduc8ng
the
programma8c
ac8vi8es
of
the
program.
39

40. Steps
to
Loading
the
Baseline
Into
the
Program
Management
Tools
1. Establish
Releases
2. Establish
Itera8ons
within
each
release
3. Establish
Stories
from
the
WBS
and
allocate
them
to
each
release
4. Assign
resources
to
each
Story
5. Es8mate
work
effort
–
in
hours
–
to
each
story
6. Assess
if
capacity
for
work
≥
demand
for
work
7. Repeat
Steps
4,
5,
and
6
un8l
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
itera8ons
to
produce
the
outcomes
of
those
“Events”
41
Releases
are
“mini-­‐projects”
and
treated
as
“deliverables”
of
fully
formed
outcomes

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

43. Establish
Stories
Inside
Itera8ons
• 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
revisi8ng
the
Story
43
Requirements
Churn
is
just
as
much
a
problem
in
Agile
as
it
is
in
Tradi1onal
projects

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

45. Es8mate
Work
Effort
for
Those
Resources
• Use
proposal
BOE’s
as
a
start
of
effort
es8ma8on
• Revisit
those
to
confirm
understanding,
es8mates,
and
outcomes
• Load
the
work
effort
es8mates
into
the
project
management
tool
45
All
es1mates
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
cri8cal
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
por8ons
of
the
program
are
covered.
– This
all-­‐in
requirement
assures
all
deliverables
are
iden8fied
in
the
WBS.
– The
WBS
facilitates
collabora8on
between
the
team
members
by
tying
performance,
cost,
schedule,
and
risk
informa8on.
– The
WBS
facilitates
the
required
technical
rigor
and
integrated
test
and
evalua8on
throughout
the
acquisi8on
process.
– The
WBS
is
the
first
loca8on
to
define
the
risks
to
achieving
the
above
items
in
this
list
48

49. Vocabulary
(Con8nued)
Deliverables
• Agile
focuses
on
outcomes
rather
than
ac8vi8es
• Our
outcomes
are
listed
in
the
BAA
(and
SOW
from
the
contract)
– Trade
studies
– Open
Architecture
– Transi8on
Plan
– MOP
defini8ons
– 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
(Con8nued)
Release
Planning
• Release
planning
is
not
scheduling
• The
backlog
of
Deliverables
from
the
WBS
are
assigned
to
Itera8ons
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
ac8ons
needed
to
formalize
the
plan
– Baselines
this
confidence
with
all
the
stakeholders
– Results
in
collec8ve
ownership
of
the
plan,
any
need
to
replanning,
and
communica8on
within
the
team
50