Upload
julianne-kipling
View
220
Download
1
Tags:
Embed Size (px)
Citation preview
Learn. Perform. Succeed.
Enterprise Agile IT Requirements Management
Matthew R. Kennedy, PhD, [email protected]
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!