Presentation on theme: "Enterprise Agile IT Requirements Management"— Presentation transcript:
1 Enterprise Agile IT Requirements Management Defense Acquisition University Alumni Association (DAUAA) Symposium04/08/2014Matthew R. Kennedy, PhD, CSPLesson 03
2 What is Agility?“The speed of operations within an organization and speed in responding to customers (reduced cycle times)” (Mass. Inst. Tech.)
3 Agile ManifestoThe foundational document for Agile software developmentSigned by 17 software developers in Feb 2001Core ValuesIndividuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan
4 12 Principles of the Agile Manifesto Continuous delivery of valuable softwareWelcome changing requirementsDeliver working software in weeks/monthsWork together dailyBuild projects around motivated individualsFace-to-face conversationWorking software is the measure of progressPromote sustainable developmentGood design enhances agilitySimplicity is essentialSelf-organizing teamsReflect on how to become more effective
5 Test Driven Development What do they Mean?ScrumeXtreme Programming (XP)Disciplined Agile Delivery (DAD)Dynamic Systems Development Method (DSDM)CrystalLeanTest Driven DevelopmentKANBAN
6 Three+ Requirement Truths 1. You can’t gather all the requirements up front 2. The requirements you do gather will change 3. There is always more to do than time and money will allow 4. Your estimates will be off** Added to the Agile Samurai Truths
7 Your Estimates Will Be Off Knowledge WorkSoftware “Research” and Development∞TECHNOLOGYSPEED LIMITIncreased Complexity
8 Example Operational Requirement Create an exact hand written copy of 300 pages from a historical book!
9 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.
10 It’s Math – It has to be Accurate, Right? FORMULA: (# lines per page) x (# words per line) = words per page25 x 10 = 250 words per page!300 (Pages) x 250 (Words) = 75,000 words to copy!
11 “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 pages3,409 (total minutes) / 480 (minutes in an 8-hour day) = 7.1 Days (assuming 1 person)How many words couldyou copy in 1-minute?*Brown, C. M. (1988). Human-computer interface design guidelines. Norwood, NJ: Ablex Publishing.
12 ExperimentGiven a typed paragraph I asked 28 IT Professionals to estimate how many words per minute they could copy
13 The Numbers 28 Subject Matter Experts Total 1,127 Years of Experience Average years of Experience
14 Results High 70 Words per Minute Low 15 Average Paragraph 1 Estimate Actual
15 Results High 70 High 47 Words per Minute Low 15 Low 13 Average Average Paragraph 1EstimateActual
16 Results High 70 High 47 High 45 Words per Minute Low 15 Low 15 Low 13 AverageAverageAverageParagraph 1Paragraph 2EstimateActualEstimateActual
17 Results High 70 High 47 High 45 Words per Minute Low 15 Low 15 Low 13 AverageAverageAverageAverageParagraph 1Paragraph 2EstimateActualEstimateActual
18 What If…You estimate using the high (70) estimate but the team performs at the average (36) rateHigh: 75,000 Words / 70 WPM = 1,071 MinutesAverage: 75,000 Words / 36 WPM = 2,083 MinutesHoursJanFebMarchAprilMayJuneJulyAugSepOctNovDecHigh Estimate (1,071 hours)~ 6 Months estimated deliveryAverage (2,083 hours)~ 1 Year to actually deliverWPM = Words-per-minute
19 Or What If…You estimate using the Low (15) estimate but the team performs at the average (36) rateLow: 75,000 Words / 15 WPM = 5,000 MinutesAverage: 75,000 Words / 36 WPM = 2,083 MinutesHoursJanFebMarchAprilMayJuneJulyAugSepOctNovDecHigh Estimate (5,000 hours)2+ Years estimated deliveryHigh Estimate Cont…Average (2,083 hours)~ 1 Year to actually deliverWPM = Words-per-minute
21 Cost Typically tied to schedule (see Schedule) but not always: Material cost (I.e., Titanium vs stainless steel)Increased / decreased performance (hardware)Etc…
22 Schedule (Time)Long project schedules or schedule delays may cause additional schedule delays or an obsolete product since:User needs changeCausing additional requirements late in the process to address these changes -> adding to the scheduleTechnology changesMay require hardware changes -> adding to the schedule
23 Quality Pay me now… Or pay me later… Increased cost to repair later in developmentIncrease in support costs (Help Desk)Decrease user trust
28 Aspects of Product Development Business AspectResponsible for the overall acquisition: contracting, funding, operational requirements, and system delivery structureProject / System AspectOverall technical management. Further decompose the requirements and allocate them to software or hardwareDevelopment AspectDevelopmental items
29 Different Focus – Same Goal BusinessAspectOp. RequirementsStrategic GoalsContractsFundingTech. RequirementsProject Planning Systems PlanningTechnical StandardsIntegrationDevelopment TestProject / System Aspect=DevelopmentAspect
30 Traditional Requirements Management Business AspectLocked RequirementsProject / System AspectHow long (time) will it take to complete these requirements?How much will it cost to complete these requirements?
31 Traditional Requirements Management Business AspectLocked RequirementsTraditional DeliveryAt what point can we ACCURATELY readjust our cost estimate?When can we adapt to changing requirements?Project / System AspectRequirement 1 DesignRequirement 2 DesignRequirement 3 DesignRequirement 4 DesignRequirement n DesignRequirement 1 BuildRequirement 2 BuildRequirement 3 BuildRequirement 4 BuildRequirement n BuildRequirement 1 TestRequirement 2 TestRequirement 3 TestRequirement 4 TestRequirement n TestIntegrationAcceptance TestingFirst time capability is achievedEstimated Time – Likely to be extended
32 Using What We Know We can’t get everything done [Prioritization] Time is a critical factor [Time Boxing / Short Time-lines]Agile PracticesIncremental DevelopmentSmall TeamsIterative DevelopmentTime BoxingShort Time-linesLean InitiativesRetrospectives (Lessons learned)PrototypingEmpowered / Self-organizing / Managing teamsContinuous User InvolvementPrioritized Product Backlog (Requirements)Co-located TeamsKennedy / Ward
33 How do we Prioritize Enterprise Requirements? Numerically?Relative to each other?Groups?
34 MoSCoW* (Groups) Must Should Could Won’t Must Have (or Minimum Usable Subset)Should HaveCould HaveWon’t Have (but Would Like in Future)Won’tCouldShouldMustIncreased Priority* Used in Dynamic Systems Development Method
35 Agile Requirements Management Business AspectIncrement 1Won’tCouldShouldMustIncreased PriorityProject / System AspectGiven this priority, budget and time what capability can be completed?
36 Agile Requirements Management Business AspectAgile Delivery At what point can we ACCURATELY readjust our cost estimate? At what point can we adapt to changing requirements?Increment 1Reprioritize / Add / Remove RequirementsWon’tCouldShouldMustIncreased PriorityIncrement 2Reprioritize / Add / Remove RequirementsWon’tCouldShouldMustIncreased PriorityIncrement nWon’tCouldShouldMustIncreased PriorityProject / System Aspect“Must” Requirement 2“Must” Requirement 1“Must” Requirement n“Should” Requirement 2“Should” Requirement 3“Should” Requirement 4“Should” Requirement 6“Should” Requirement 5“Should” Requirement 7“Could” Requirement n“Could” Requirement 1Minimum Capability Achieved –Other Requirements may be pushed to a future increment“Should” Requirement 1Time-Box= Time-Boxed Sub-capability
37 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)
38 To the Maximum Extent Possible Requirements… Must be developed in priority orderMust meet the minimum level of predefined acceptable quality and no moreMust be estimated by the developers performing the work
39 Cultural Barriers Pushed capability vs. added time / $$ Multidisciplinary teams vs. domain focused teamsStove-piped / domain focused contracts
40 More Tools to Manage Risk Specify SHORT delivery timesGenerally, the longer the deliver time the greater the riskPrioritize the requirementsEnsure high priority requirements get completed firstWorking capabilities are the only measure of success
41 Fragile vs. Agile FRAGILE AGILE Adding Time / Adding Money to a troubled projectPushed capability to the next incrementDomain focused teamsMultidisciplinary teamsLong / single deliveriesShort / incremental deliveriesNon-standard / monolithic designStandard / Modular designRequirements change throughout developmentRequirements change between incrementsLong static contractsStreamlined contracting process
42 Agile Requirements with Traditional Project Management XBusiness AspectIncrement 1Won’tCouldShouldMustIncreased PriorityProject / System AspectRequirement 1 DesignRequirement 2 DesignRequirement 3 DesignRequirement 4 DesignRequirement n DesignRequirement 1 BuildRequirement 2 BuildRequirement 3 BuildRequirement 4 BuildRequirement n BuildRequirement 1 TestRequirement 2 TestRequirement 3 TestRequirement 4 TestRequirement n TestIntegrationAcceptance Testing
44 Interim 5000.02 From 1 to 6 Acquisition Models Model 1: Hardware Intensive ProgramModel 2: Defense Unique Software Intensive ProgramModel 3: Incrementally Fielded Software Intensive ProgramModel 4: Accelerated Acquisition ProgramHybrid Program A (Hardware Dominant)Hybrid Program B (Software Dominant)
45 Interim 5000.02 Process 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 DirectiveMDAs 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 requirementsStatutory requirements will be complied with, unless waived in accordance with relevant provisions
49 Better Buying Power 2.0Reflects the Department of Defense’s commitment to continuous improvement in acquisition performanceEncompasses a set of fundamental acquisition principles to achieve:Greater efficiencies through affordabilityCost controlElimination of unproductive processes and bureaucracyPromotion of competition
50 Better Buying Power 2.0 and Agile Practices Achieve Affordable ProgramsMandate affordability as a requirementInstitute a system of investment planning to derive affordability capsEnforce affordability capsControl Costs throughout the Product Life CycleImplement "should cost" based managementEliminate redundancy within warfighter portfoliosInstitute a system to measure the cost performance of programs and institutions and to assess the effectiveness of acquisition policiesBuild stronger partnerships with the requirements community to control costsIncrease the incorporation of defense exportability features in initial designslncentivize Productivity & Innovation in Industry and GovernmentAlign profitability more tightly with Department goalsEmploy appropriate contract typesIncrease use of Fixed Price Incentive contracts in Low Rate Initial ProductionBetter define value in "best value" competitionsWhen LPTA is used, define Technically Acceptable to ensure needed qualityInstitute a superior supplier incentive programIncrease effective use of Performance-Based LogisticsReduce backlog of DCAA Audits without compromising effectivenessExpand programs to leverage industry's IR&DEliminate Unproductive Processes and BureaucracyReduce frequency of OSD level reviewsRe-emphasize AE, PEO and PM responsibility and accountabilityEliminate requirements imposed on industry where costs outweigh benefitsReduce cycle times while ensuring sound investment decisionsPromote Effective CompetitionEmphasize competition strategies and creating and maintaining competitive environmentsEnforce open system architectures and effectively manage technical data rightsIncrease small business roles and opportunitiesUse the Technology Development phase for true risk reductionImprove Tradecraft in Acquisition of ServicesAssign senior managers for acquisition of servicesAdopt uniform services market segmentationImprove requirements definition/prevent requirements creepIncrease use of market researchIncrease small business participationStrengthen contract management outside the normal acquisition chain—installations, etc.Expand use of requirements review boards and tripwiresImprove the Professionalism of the Total Acquisition WorkforceEstablish higher standards for key leadership positionsEstablish stronger professional qualification requirements for all acquisition specialtiesIncrease the recognition of excellence in acquisition managementContinue to increase the cost consciousness of the acquisition workforce—change the culture
51 Final ThoughtThere are NO extra-ordinary programs…. Just programs that do ORDINARY things better!