University of Southern California Center for Systems and Software Engineering A Model for Estimating Agile Project Schedule Acceleration Dan Ingold, USC-CSSE

University of Southern California

Center for Systems and Software Engineering

A Model for Estimating Agile Project Schedule Acceleration

Dan Ingold, USC-CSSE

SSCM/COCOMO Forum

17 October 2012



Project Goals

Research Question: Can we quantify the schedule acceleration to be expected

from employing agile techniques, given a range of development project characteristics?

• Goal is not to estimate what a team using poor SE/architectural practices & processes can achieve

• Can always cut corners to reduce schedule… for a while, at least

• Goal is to examine what effects the various characteristics of a project using good practices have on achieving schedule compression

October 17, 2012 Copyright © USC-CSSE 2



COCOMO for Agile Projects?

• COCOMO II calibrated against larger projects– Larger projects typically optimized to minimize cost– Agile projects typically optimized to minimize schedule

• Over-estimates schedule for smaller projects– Estimates schedule varies with cube-root of effort– Smaller projects vary with square-root of effort

• Optimizes 27-PM project as 2.45 persons / 11 mos.– Minimizes communication overhead, optimizes effort– But… 11 months is too long under competitive pressure




(Re)introducing CORADMO

• Constructive Rapid Application Development Model

• Observations of early-agile projects completing 27-PM projects in 5 months with 5.4 persons, and even 9 persons to complete in 3 months

• Derivative of COCOMO II, introduced ~2000– Implemented as COCOMO II / COPSEMO post-processor– Derived six drivers through initial two-round Delphi

• Lacked critical mass of data to calibrate model




New CORADMO Drivers

• SERC RT-34 tasked to study “expediting SE”– Identified candidate firms and agencies that were

successfully compressing project development time– Conducted series of onsite visits and in-depth interviews

• Derived expanded set of factors common across these entities, good candidates for new drivers– Product: describes nature of system to be developed– Process: characterizes the development methodology– Project: describes execution of the development effort– People: characterizes capabilities of development staff– Risk: describes stakeholder willingness to accept risk




General CORADMO Structure

• CORADMO depends on the existence of a good baseline effort estimate; it does not estimate effort

• Estimated duration D is proportional to square-root of estimated effort PM

• Like COCOMO, CORADMO uses product of multiplier factors, rated according to project characteristics




Product Factors

• Simplicity: simple products are easier to develop• Reuse: reuse saves work (or does it?)• Deferrals: postpone features to fit schedule• Modeling: working models vs complete documents• Maturity: fewer technologies needing development




Process Factors

• Concurrency: serial waterfall / concurrent iteration• Streamlining: bureaucracy requires “just so”?• Tool support: integrated development, continuous

integration, automated testing, model-to-code, etc.




Project Factors

• Staff size: more people ≈ higher communication overhead (are factors large enough for big staff?)

• Collaboration: how well does team share data?• MMPTs: tool support within and across domains




People Factors

• KSAs: how senior is team? How agile is team?• Single vs Multi-domain: how well do team skills

cross domain boundaries (analogous to MMPTs)• Compatibility: can’t we all just get along?




Risk Acceptance Factors

• How willing are stakeholders to accept risk?– Tolerance of chaotic, evolving processes– “We’ve always done it this way.” “The manual says these

are the required processes and artifacts.”– Adaptive, oriented toward product completion

• Many of the accelerated-development teams reviewed had compliant, risk-tolerant customers




Commercial Calibration

• Midwest software development firm using agile• Supplemented agile with additional SE processes

– Detailed business process analysis– Delphi estimates of software testing effort– Risk-based situation audits– Componentized architectures– …

• Makes this firm reasonably comparable to complex aerospace/defense projects from which CORADMO factors derived




Commercial Calibration (cont’d)

Copyright © USC-CSSE 13October 17, 2012



Commercial Calibration (cont’d)

• Projects varying from 10 KSLOC to 400 KSLOC• Varying levels of complexity and technology• Selected rating factors based on reported project

characteristics, and of firm as a whole– Product: C++ projects received Low ratings; HTML/VB

projects received Very High ratings– Process: Most projects reported as “highly concurrent,”

received Very High ratings– Project: Variation in staff sizes results in different ratings– People: Very senior staff rated as Very High– Risk: Consistent, rigorous and balanced approach

yielded Nominal risk ratings




Calibration Discussion

• Acceptable results for first-cut– One outlier discarded, described as having high

requirements churn– Tends to over-estimate schedule compression

• Outlier suggests Product may require sub-factor for requirements churn: perhaps “stability?”

• Process within narrow range• Project within narrow range• People factor has single rating

– May not extend to wider range or less capable staff– But… rapid projects often employ most-senior staff




Decision Support Case Study

• Hypothetical company, composite of real affiliates of USC CSSE

• Illustrates use of CORADMO tool to support decision to move to more agile approach

• Evaluate as-is and to-be conditions, as rated by model sub-factors

• Determine potential schedule compression through adoption of new strategy




Case Study—As-is

• Evaluate current state against factors

• Use to inform decision on change to more rapid development

• Overall acceleration factor of current state = 1.01




Case Study—Initial To-Be

• Produce artifacts more concurrently

• Causes reductions in– Technology maturity– SE tool support– General SE KSAs– Team compatibility

• Expected 5% schedule improvement

• Saw 4% schedule increase




Case Study—Final To-Be

• Restore reduced factors to baseline, by being aware of the potential problems

• Choose to– Perform more activities

concurrently– Improve bureaucratic

internal and external processes

• Schedule improves by 8%




Case Study Shortcomings

• Case study illustrates some problems with using the factors in the model

• We really would have expected some more noticeable change in schedule

• The expected improvements and discovered shortfalls are so small as to be lost in the noise– Suggests either that the factors are too small– Or that the method of combining sub-factors (in this

example, by averaging them) is incorrect

• So, more work to be done…




Further Issues

• How to handle contribution of sub-factors– Average, additive, multiplicative, preponderance?– Offsetting: does a very-low complement a very-high?

• Factors complete and correct?• Too many factors (too complex)?• Accuracy, consistency of how factors would be

coded by potential users• Overall range of factor multipliers, 1.63-0.48, (3.4:1)

seems consistent with reported range of schedule compression in agile projects, but…




Next Steps

• Need additional data on wider range of projects that would be characterized as “rapid” or “agile”

• So, looking for volunteers who would be willing to share project performance data

• Conducting workshop here to discuss factors– Delphi to uncover omitted (or superfluous) factors– Effect of contravening factors– Sufficient range of multiplier factors




Questions?


Documents

University of Southern California Center for Systems and Software Engineering A Model for Estimating Agile Project Schedule Acceleration Dan Ingold, USC-CSSE