Learn. Perform. Succeed.

Enterprise Agile IT Requirements Management

Matthew R. Kennedy, PhD, CSPMatthew.Kennedy@dau.mil

Defense Acquisition University Alumni Association (DAUAA) Symposium 04/08/2014

What is Agility?

• “The speed of operations within an organization and speed in responding to customers (reduced cycle times)” (Mass. Inst. Tech.)

• The foundational document for Agile software development

• Signed by 17 software developers in Feb 2001

• Core Values– Individuals and interactions over processes and tools– Working software over comprehensive documentation– Customer collaboration over contract negotiation– Responding to change over following a plan

Agile Manifesto

http://agilemanifesto.org/

1. Continuous delivery of valuable software

2. Welcome changing requirements

3. Deliver working software in weeks/months

4. Work together daily

5. Build projects around motivated individuals

6. Face-to-face conversation

7. Working software is the measure of progress

8. Promote sustainable development

9. Good design enhances agility

10. Simplicity is essential

11. Self-organizing teams

12. Reflect on how to become more effective

12 Principles of the Agile Manifesto

http://agilemanifesto.org/

What do they Mean?

Lean

Test Driven Development

Scrum

KANBAN

eXtreme Programming (XP)Dynamic Systems Development Method (DSDM)

Crystal

Disciplined Agile Delivery (DAD)

Three+ Requirement Truths

1. You can’t gather all the requirements up front2. The requirements you do gather will change3. There is always more to do than time and money will allow4. Your estimates will be off*

* Added to the Agile Samurai Truths

Your Estimates Will Be Off

Software “Research” and D

evelopment

Knowledge Work

Increased Complexity∞TECHNOLOGY SPEED LIMIT

Example Operational Requirement

TCreate an exact hand written copy of 300 pages from a historical book!

How much will this cost?

• Assumptions– Section text is double-spaced, left-aligned, and set

in a 12-point Courier font. – The first line of a paragraph is indented one half

inch, or 5 characters, from the margin. – The margins are set so that there are 25 lines per

page, with each line having a maximum of 60 characters.

– Sixty characters per line at an average of six characters per word works out to an average of ten words per line.

It’s Math – It has to be Accurate, Right?

• FORMULA: (# lines per page) x (# words per line) = words per page

• 25 x 10 = 250 words per page!• 300 (Pages) x 250 (Words) = 75,000 words to

copy!

“Parametric” Words Per Minute Estimate

• The average human being hand-writes 22 words per minute while copying.*

– 75,000 (total words) / 22 (words per minute) = 3,409 minutes to copy 300 pages

• 3,409 (total minutes) / 480 (minutes in an 8-hour day) = 7.1 Days (assuming 1 person)

*Brown, C. M. (1988). Human-computer interface design guidelines. Norwood, NJ: Ablex Publishing.

How many w

ords could

you copy in 1-m

inute?

Experiment

– Given a typed paragraph I asked 28 IT Professionals to estimate how many words per minute they could copy

The Numbers

• 28 Subject Matter Experts– Total 1,127 Years of Experience– Average 40.25 years of Experience

Wor

ds

per

Min

ute

High 70

Low 15

Average

Results

Estimate Actual

Paragraph 1

0

10

20

30

40

50

60

70

80

36

Wor

ds

per

Min

ute

High 70

Low 15

Average

High 47

Low 13

Results

Estimate Actual

Paragraph 1

Average 0

10

20

30

40

50

60

70

80

36

27

Wor

ds

per

Min

ute

High 70

Low 15

Average Average

High 47

Low 13

Paragraph 2

Estimate Actual

High 45

Low 15

Results

Estimate Actual

Paragraph 1

Average 0

10

20

30

40

50

60

70

80

36

27 27

Wor

ds

per

Min

ute

High 70

Low 15

Average Average

High 47

Low 13

Low 15

Results

Paragraph 2

Estimate ActualEstimate Actual

Paragraph 1

0

10

20

30

40

50

60

70

80

36

27 27 26

Average Average

High 45

What If…

• You estimate using the high (70) estimate but the team performs at the average (36) rate– High: 75,000 Words / 70 WPM = 1,071 Minutes– Average: 75,000 Words / 36 WPM = 2,083 Minutes

WPM = Words-per-minute

High Estimate (1,071 hours)~ 6 Months estimated delivery

Average (2,083 hours)~ 1 Year to actually deliver

DecOctSepAugJulyJuneAprilMarchFebJan May Nov

Hours

Hours

Or What If…

• You estimate using the Low (15) estimate but the team performs at the average (36) rate– Low: 75,000 Words / 15 WPM = 5,000 Minutes– Average: 75,000 Words / 36 WPM = 2,083 Minutes

WPM = Words-per-minute

Average (2,083 hours)~ 1 Year to actually deliver

DecOctSepAugJulyJuneAprilMarchFebJan May Nov

Hours

Hours

High Estimate (5,000 hours)2+ Years estimated delivery

High Estimate Cont…

Project Variables

• Cost• Schedule (Time)• Quality• Capability

Cost

• Typically tied to schedule (see Schedule) but not always:– Material cost (I.e., Titanium vs stainless steel)– Increased / decreased performance (hardware)– Etc…

Schedule (Time)

• Long project schedules or schedule delays may cause additional schedule delays or an obsolete product since:– User needs change

• Causing additional requirements late in the process to address these changes -> adding to the schedule

– Technology changes• May require hardware changes -> adding to the schedule

Quality

• Pay me now… Or pay me later…– Increased cost to repair later in development– Increase in support costs (Help Desk)– Decrease user trust

Capability

• Decreased user trust

Project Variables

• Cost• Schedule (Time)• Quality• Capability

WHIC

H VARIABLES D

O WE A

LLOW T

O CHANGE?

= Floating= Fixed

Cost Schedule

Capability

Quality

Traditional

Cost Schedule

Capability

Quality

Agilevs.

Project Variables

Learn. Perform. Succeed.

Organizational Structure

Aspects of Product Development

• Business Aspect– Responsible for the overall acquisition:

contracting, funding, operational requirements, and system delivery structure

• Project / System Aspect– Overall technical management. Further decompose

the requirements and allocate them to software or hardware

• Development Aspect– Developmental items

Different Focus – Same Goal

BusinessAspect

Project / System Aspect

DevelopmentAspect

=

Op. RequirementsStrategic Goals

ContractsFunding

Tech. RequirementsProject Planning Systems Planning

Technical StandardsIntegration

DevelopmentTest

Busin

ess A

spec

tPr

ojec

t / S

yste

m

Aspe

ct

Lock

ed R

equi

rem

ents

Traditional Requirements Management

How long (time) will it take to complete these requirements?

How much will it cost to complete these requirements?

Busin

ess A

spec

tPr

ojec

t / S

yste

m

Aspe

ct

Lock

ed R

equi

rem

ents

Estimated Time – Likely to be extended

Requirement 1

Design

Requirement 2

Design

Requirement 3

Design

Requirement 4

Design

Requirement n

Design

Requirement 1

Build

Requirement 2

Build

Requirement 3

Build

Requirement 4

Build

Requirement n

Build

Requirement 1

Test

Requirement 2

Test

Requirement 3

Test

Requirement 4

Test

Requirement n

Test

Integration

Firs

t tim

e ca

pabi

lity

is a

chie

ved

Traditional Requirements Management

Acceptance Testing

Traditional DeliveryAt what point can we ACCURATELY readjust our cost estimate?

When can we adapt to changing requirements?

Using What We Know

• We can’t get everything done [Prioritization]• Time is a critical factor [Time Boxing / Short Time-lines]

Incremental Development Small Teams

Iterative Development Time Boxing

Short Time-lines Lean Initiatives

Retrospectives (Lessons learned) Prototyping

Empowered / Self-organizing / Managing teams

Continuous User Involvement

Prioritized Product Backlog (Requirements)

Co-located Teams

Kennedy / Ward

Agile Practices

How do we Prioritize Enterprise Requirements?

• Numerically?• Relative to each other?• Groups?

MoSCoW* (Groups)

• Must Have (or Minimum Usable Subset)• Should Have• Could Have• Won’t Have (but Would Like in Future)

Won’t

Could

Should

Must

Incr

ease

d Pr

iorit

y* Used in Dynamic Systems Development Method

Agile Requirements ManagementBu

sines

s As

pect

Proj

ect /

Sys

tem

As

pect

Won’t

Could

Should

MustIn

crea

sed

Prio

rity

Increment 1

Given this priority, budget and time what capability can be completed?

Agile Requirements ManagementPr

ojec

t / S

yste

m

Aspe

ctBu

sines

s As

pect

Won’t

Could

Should

MustIn

crea

sed

Prio

rity

Time-Box

= Time-Boxed Sub-capability

“Should” Requirement 1

“Should” Requirement 2

“Should” Requirement 3

“Should” Requirement 4

“Should” Requirement 6

“Should” Requirement 5

“Should” Requirement

7

“Could” Requirement

n

“Could” Requirement 1

Min

imum

Cap

abili

ty A

chie

ved

–Oth

er R

equi

rem

ents

may

be

push

ed to

a fu

ture

incr

emen

t

Increment 1

Rep

riorit

ize

/ Add

/

Rem

ove

Req

uire

men

ts

Won’t

Could

Should

Must

Incr

ease

d Pr

iorit

y

Increment 2

Rep

riorit

ize

/ Add

/

Rem

ove

Req

uire

men

ts

Won’t

Could

Should

Must

Incr

ease

d Pr

iorit

y

Increment n

“Must” Requirement 2

“Must” Requirement 1

“Must” Requirement n

Agile DeliveryAt what point can we ACCURATELY readjust our cost

estimate?At what point can we adapt to changing requirements?

Requirements Must Have A…

• Specified level of Testable Quality (Acceptance criteria)

• Priority (Must, Should, Could, Won’t)– Everything CAN’T be a MUST!

• Estimated Level of Effort (time-boxed period to complete each requirement)

To the Maximum Extent Possible Requirements…

• Must be developed in priority order• Must meet the minimum level of predefined

acceptable quality and no more• Must be estimated by the developers

performing the work

Cultural Barriers

• Pushed capability vs. added time / $$• Multidisciplinary teams vs. domain focused

teams• Stove-piped / domain focused contracts

More Tools to Manage Risk

• Specify SHORT delivery times– Generally, the longer the deliver time the greater the

risk• Prioritize the requirements

– Ensure high priority requirements get completed first

• Working capabilities are the only measure of success

Fragile vs. Agile

FRAGILE AGILE

Adding Time / Adding Money to a troubled project

Pushed capability to the next increment

Domain focused teams Multidisciplinary teams

Long / single deliveries Short / incremental deliveries

Non-standard / monolithic design Standard / Modular design

Requirements change throughout development Requirements change between increments

Long static contracts Streamlined contracting process

Busin

ess

Aspe

ct

Won’t

Could

Should

Must

Incr

ease

d Pr

iorit

y

Increment 1

Agile Requirements with Traditional Project Management

Proj

ect /

Sys

tem

As

pect

Requirement 1

Design

Requirement 2

Design

Requirement 3

Design

Requirement 4

Design

Requirement n

Design

Requirement 1

Build

Requirement 2

Build

Requirement 3

Build

Requirement 4

Build

Requirement n

Build

Requirement 1

Test

Requirement 2

Test

Requirement 3

Test

Requirement 4

Test

Requirement n

Test

Integration

Acceptance TestingX

Learn. Perform. Succeed.

The DoD’s Support for Agile

Interim 5000.02 From 1 to 6 Acquisition Models

• Model 1: Hardware Intensive Program• Model 2: Defense Unique Software Intensive

Program• Model 3: Incrementally Fielded Software

Intensive Program• Model 4: Accelerated Acquisition Program• Hybrid Program A (Hardware Dominant)• Hybrid Program B (Software Dominant)

BA C

= Milestone Decision = Decision PointLegend:

Materiel Development

Decision

Capability Development

Document (CDD) Validation

Full-Rate Production

(FRP)Decision

Development Request for

Proposals (RFP) Release Decision

Initial Operational Capability (IOC)

Full Operational Capability (FOC)

Materiel Solution Analysis

Technology Maturation &

RiskReduction

Production & Deployment

Engineering & Manufacturing Development

Disposal

Low-Rate InitialProduction(LRIP)

OT&E

Operations & Support

Model 1: Hardware

Sustainment

Rt: .6”Bottom: 1.7

BA C

Full Deployment

Decision (FDD) Full

Deployment (FD)

MaterielSolutionAnalysis

Technology Maturation &

Risk Reduction

Engineering & Manufacturing Development

Materiel Development

Decision

Deployment Operations & Support

Disposal

IOC

Build 1.1

Build 1.2

Build 1.3Build 0.1

RiskReduction

= Milestone Decision = Decision PointLegend:

CDD Validation

Build 1.5Build 2.1*

Integration

OT&E

LimitedDeployment

Model 2: Software Intensive

Sustainment

Left: .1Rt: .2

Top: .2Bottom: 1.3

* The actual number and type of builds during the program will depend on system type.

Development RFP

Release Decision

Build 1.4

BA

Full Deployment

Decision (FDD)

MaterielSolutionAnalysis

Risk Reduction

Development &Fielding

Materiel Development

Decision

Build 1

Build 0

RiskReduction

Build

CDD Validation

OT&EBuild n

Build 2

Limited Fielding Decisions

. . .

Sustainment

Full Deployment

(FD)

IOC

Operations & Support

Build 2.1

OT&EBuild 2.n

Build 2.2. . .

Sustainment

FDD

Limited Fielding Decisions

FDIOC

B

Risk Reduction

Development &Fielding

Operations & Support

Increment 2

Disposal

Build n.1

OT&EBuild n.n

Build n.2. . .

Sustainment

FDD

Limited Fielding Decisions

FDIOC

B

Risk Reduction

Development &Fielding

Operations & Support

Increment n

= Milestone Decision

= Decision Point

Legend

Left: .5Right: 1.75

Top: .2Bottom: .7

Development RFP

Release Decision

Development RFPRelease Decision

Development RFPRelease Decision

Interim 5000.02Process Flexibility

• The structure of a DoD acquisition program and the procedures used should be tailored as much as possible to the characteristics of the product being acquired, and to the totality of circumstances associated with the program including operational urgency and risk factors.

• Authorizes Milestone Decision Authorities (MDAs) to tailor the regulatory requirements and acquisition procedures in this instruction to more efficiently achieve program objectives, consistent with statutory requirements and DoD Directive 5000.01

• MDAs will tailor program strategies and oversight, including program information, acquisition phase content, the timing and scope of decision reviews and decision levels, based on the specifics of the product being acquired, including complexity, risk factors, and required timelines to satisfy validated capability requirements

• Statutory requirements will be complied with, unless waived in accordance with relevant provisions

DoD CIO IT Modernization

4. Enabling Agile IT

10. Modernize IT Guidance and Training

Better Buying Power 2.0

• Reflects the Department of Defense’s commitment to continuous improvement in acquisition performance

• Encompasses a set of fundamental acquisition principles to achieve:– Greater efficiencies through

affordability– Cost control – Elimination of unproductive

processes and bureaucracy– Promotion of competition

Better Buying Power 2.0 and Agile Practices

Achieve Affordable Programs Mandate affordability as a requirement• Institute a system of investment planning to derive affordability caps• Enforce affordability capsControl Costs throughout the Product Life Cycle• Implement "should cost" based management• Eliminate redundancy within warfighter portfolios• Institute a system to measure the cost performance of programs and

institutions and to assess the effectiveness of acquisition policies Build stronger partnerships with the requirements community to

control costs• Increase the incorporation of defense exportability features in initial

designslncentivize Productivity & Innovation in Industry and Government• Align profitability more tightly with Department goals Employ appropriate contract types• Increase use of Fixed Price Incentive contracts in Low Rate Initial

Production• Better define value in "best value" competitions• When LPTA is used, define Technically Acceptable to ensure needed

quality• Institute a superior supplier incentive program• Increase effective use of Performance-Based Logistics• Reduce backlog of DCAA Audits without compromising effectiveness• Expand programs to leverage industry's IR&DEliminate Unproductive Processes and Bureaucracy Reduce frequency of OSD level reviews• Re-emphasize AE, PEO and PM responsibility and accountability Eliminate requirements imposed on industry where costs outweigh

benefits Reduce cycle times while ensuring sound investment decisions

Promote Effective Competition Emphasize competition strategies and creating and

maintaining competitive environments Enforce open system architectures and effectively manage

technical data rights• Increase small business roles and opportunities• Use the Technology Development phase for true risk

reductionImprove Tradecraft in Acquisition of Services• Assign senior managers for acquisition of services• Adopt uniform services market segmentation• Improve requirements definition/prevent requirements

creep• Increase use of market research• Increase small business participation• Strengthen contract management outside the normal

acquisition chain—installations, etc. Expand use of requirements review boards and tripwiresImprove the Professionalism of the Total Acquisition Workforce• Establish higher standards for key leadership positions• Establish stronger professional qualification requirements

for all acquisition specialties• Increase the recognition of excellence in acquisition

management• Continue to increase the cost consciousness of the

acquisition workforce—change the culture

Final Thought

• There are NO extra-ordinary programs…. Just programs that do ORDINARY things better!

Matthew.Kennedy@dau.mil