CSSE Annual Research Review
CORADMO: A Model to
Estimate Schedule
Acceleration in Agile Projects
Dan Ingold!
!
April 2014
Introduction
❖
Speedy development is increasingly important [1]!
❖
❖
❖
Research develops CORADMO!
❖
❖
❖
❖
❖
Reduced time-to-market!
Response to competitive or adversarial threats!
Constructive Rapid Application Development Model!
“Rebooting” of CORADMO (2000) presented in [2]!
Updated concept of “rapid” [3], factors not phase-specific!
Uses rapid-response concepts discovered in [10]!
Agile adoption/perception has increased dramatically!
❖
❖
Developers have embraced agile approach [4]!
Early and continuous delivery of software [5]
2
continue to use either an iterative or waterfall development process as their primary method of
software delivery.
Agile Has Overtaken Traditional
Figure 1 Agile Adoption Has Reached Mainstream Proportions
(select only one)
10.9%
Scrum
6.0%
Agile Modeling
3.8%
Feature-driven development (FDD)
3.4%
Test-driven development (TDD)
2.9%
eXtreme Programming (XP)
2.1%
Lean development
Agile, 35%
1.8%
Microsoft Solutions Framework (MSF) for Agile
Agile Data Method 1.6%
Adaptive Software Development (ASD) 1.3%
Six Sigma 0.9%
Crystal 0.3%
Behavior-driven development (BDD) 0.2%
Dynamic Systems Development Method (DSDM) 0.2%
30.6%
Do not use a formal process methodology
16.3%
Iterative development
Iterative, 21%
2.7%
Rational Unified Process (RUP)
Spiral 1.6%
8.4%
Waterfall
Waterfall, 13%
2.5%
Capability Maturity Model Integration (CMMI)
2.5%
ISO 9000
Base: 1,298 IT professionals
Source: Forrester/Dr. Dobb’s Global Developer Technographics® Survey, Q3 2009
Source: Forrester Research, Inc.
56100
3
Motivation
❖
Agile chosen when time-certain delivery required [1, 6]!
❖
Schedule planning done at team level [6, 7]!
❖
Detailed planning by iteration!
❖
High-level planning by release, at low-resolution!
❖
Cost/features may vary from plan for given schedule!
❖
Very little literature on agile planning, in terms of achievable
effort for given schedule!
❖
Agile schedules reported to be much lower than traditional!
❖
Traditional schedule proportional to ~3 x cube-root(effort) [8, 9]!
❖
Agile schedule appears proportional to square-root(effort)
4
Research Questions
❖
RQ1: Do the durations of larger-scale agile projects
remain proportional to the square-root of development
effort?!
❖
RQ2: What factors are predictive of schedule reduction
or extension in agile development projects?!
❖
RQ3: What is the quantitative effect of the application of
these factors on project schedule?
5
Intended Research Contribution
❖
Clarify the relationship between development effort and
schedule duration in agile projects!
❖
Identify key factors affecting agile software project
development schedule duration!
❖
Quantify effect of each factor on schedule acceleration/
deceleration!
❖
Create a model to allow predictive modeling of
schedule acceleration factors
6
Background
7
Cost/schedule Tradeoff
[13]
8
Cost/schedule Tradeoff
❖
COCOMO and other models postulate “optimal”
schedule [13]!
❖
❖
Deviation from optimal schedule increases costs!
❖
❖
❖
❖
Many models assume convex relationship of schedule and cost!
Given effort in shorter schedule needs more staff or hours!
More staff or hours decreases productivity [14]!
Extended schedule may increase “social loafing” [15][16]!
Schedule-sensitive projects may accept increased costs
9
Agile Claims Improved Schedule
❖
Agile claims to offer better productivity, possibly lower
cost [6][52]!
❖
Specific agile practices shown to increase productivity!
❖
❖
❖
Agile tends to use more level staffing profile than phased projects!
Higher degree of collaboration, reduced communication costs!
Pair programming [1][17], refactoring [18]!
❖
No research on schedule effect of larger-scale influences!
❖
This research identifies product, process, project, people,
and risk-tolerance influences on project schedule
10
Traditional Schedule Estimation
❖
Schedule derived as Duration = C * (Effort)F [2][19][20]!
❖
❖
❖
❖
CORADMO/COPSEMO postulates square-root relation [2]!
❖
❖
❖
❖
C is a constant in the range 2.0–4.0!
F is approximately 0.33!
Relationship is extremely well documented, 1000’s of projects [20]!
Nobody would use 2 persons for 7.5 months on 16 PM effort!
More reasonable to expect 4 persons for 4 months!
Claims square-root relation breaks down between 16-64 PM!
Sample ISBSG data supports cube-root relationship [21]!
❖
❖
Curve fitting using Eureqa GA data analysis package!
Solves to approximately 4 * (Effort)0.35
11
ISBSG Sample Effort vs Duration
PromiseData(ISBSG(2010(
35"
Dura%on((in(months)(
30"
25"
20"
""
SQRT"
15"
CUBRT"
10"
COPSEMO"
5"
0"
0"
10"
20"
30"
40"
50"
60"
70"
Effort((in(person4months)(
12
80"
90"
100"
Agile Schedule Estimation
❖
Literature has not reported agile duration vs effort!
❖
❖
❖
Agile proponents seem not to consider project-level schedule!
Almost everyone suggests using cube-root relationship!
Only (Jalote 2002) suggests square-root as “sanity check”!
❖
This research hypothesizes square-root relation for agile!
❖
Supported by 12-project sample data from AgileTek!
❖
❖
❖
AgileTek was small Midwest company using Architected Agile!
Data supplied to CSSE around 2004!
Company president died shortly thereafter, company disbanded
13
AgileTek Sample Effort vs Duration
AgileTek(Data(2004(
20"
Dura%on((in(months)(
18"
16"
14"
12"
Dura-on"
10"
8"
SQRT"
6"
CUBRT"
4"
2"
0"
0"
50"
100"
150"
Effort((in(person4months)(
14
200"
250"
Reduced Schedule in Agile
❖
Agile claims schedule reduction as key benefit [6]!
❖
Simple comparison of cube- and square-root curves!
❖
❖
Shows 50% (low-end, 25 PM) to 10% (high-end, 360 PM)!
Interestingly, agrees with agile claims and reports of 10-60% [12]
15
Cube Root vs Square Root Schedule
Square4root(vs.(Cube4root(
Dura%on((in(months)(
25.0#
20.0#
10%
Reduction
15.0#
20%
Reduction
10.0#
SQR(Eff)#
CUB(Eff)#
5.0#
50%
Reduction
0.0#
0#
50#
100#
150#
200#
250#
Effort((in(person4months)(
16
300#
350#
400#
Schedule Acceleration
❖
Common concept of many models is “impossible zone”
of schedule acceleration [19]!
❖
Below 75% of nominal schedule effectively
unachievable [13][19]!
❖
Limited by ability to execute tasks in parallel,
communications overhead [14]
17
The “Impossible Zone”
The
“Impossible
Zone”
[19]
18
CORADMO Schedule Acceleration
❖
Research stems from RT-34 identification of key schedule
acceleration factors in rapid-response contractors, agencies
[10][25][26]!
❖
Factors include:!
❖
❖
❖
❖
❖
❖
Product!
Process!
Project [27]!
People!
Risk!
Well supported by NPD literature
19
Product Factors
❖
Describe the nature of the system to be developed:!
❖
❖
❖
❖
❖
Simplicity [26], !
Ability to reuse existing elements [14], [26], [28], !
Ability to defer lower-priority requirements [6], !
Degree that models can be substituted for written documentation [6]!
maturity of the component technologies [29]
20
Process Factors
❖
Characterize the development methodology!
❖
❖
❖
❖
Concurrent processes observed to accelerate schedule!
❖
❖
❖
❖
Spiral model [31], !
Rational Unified Process [32], !
Agile methods [6]!
Process-streamlining!
❖
❖
❖
❖
❖
Concurrency of artifact development [6] [26] [31] [32] [33] [34] [35]!
Degree of process streamlining [2] [36] [37] [38] [39]!
Coverage, integration, and maturity (CIM) of tools used to support the development process [30]. !
Development Process Reengineering and Streamlining factor in the original CORADMO [2],!
Removal of bureaucratic and procedural delays; presence of enabling vs. coercive bureaucracy [36]. !
Kaizen performer-identified streamlining [37], [38], !
Lean approaches such as Kanban [39]. !
COCOMO database analysis found CIM effect 50% for coverage and 25% each for
toolset integration and maturity [40]
21
Project Factors
❖
Describe execution of the development effort: !
❖
❖
❖
❖
Project staff size [41]!
Degree and nature of team collaboration[41][42]!
CIM of the single-domain models, methods, processes, and tools
(MMPTs) employed [30]!
CIM of the multi-domain MMPTs used, where required [30]
22
People Factors
❖
Describe the project staff !
❖
❖
❖
❖
General knowledge, skills, and agility (or, ability to thrive with the
more concurrent nature of the agile/lean process) [1], [41], [43]!
KSAs specific to the primary problem domain!
KSAs spanning multiple problem domains, where needed; !
Team compatibility [26], [42], [44].
23
Risk Acceptance Factor
❖
Characterizes the project stakeholders' willingness to
accept rapid solutions that may require them to
compromise on some expectations [1], [25]!
❖
Stakeholders may range from highly risk-averse, to
strongly risk-accepting
24
CORADMO Model Factors
Accelerators/Ratings
Very Low
Low
Nominal
High
Very High
Extra High
PRODUCT
FACTORS
1.09
1.05
1.00
0.96
0.92
0.87
Simplicity
Extremely complex
Highly complex
Moderately
complex
Moderately simple
Highly simple
Extremely simple
Element Reuse
None (0%)
Minimal (15%)
Some (30%)
Moderate (50%)
Considerable (70%)
Extensive (90%)
Low-Priority Deferrals
Never
Rarely
Sometimes
Often
Usually
Anytime
Models vs. Documents
None (0%)
Minimal (15%)
Some (30%)
Moderate (50%)
Considerable (70%)
Extensive (90%)
Key Technology
Maturity
>0 TRL 1,2 or >1
TRL 3
1–2 TRL 5 or >2
TRL 6
1–2 TRL 6
All > TRL 7
PROCESS
FACTORS
1.09
1.05
1.00
0.96
0.92
0.87
Concurrent
Operational Concept,
Requirements,
Architecture, V&V
Highly sequential
Mostly sequential
2 artifacts mostly
concurrent
3 artifacts mostly
concurrent
All artifacts mostly
concurrent
Fully concurrent
Process Streamlining
Heavily
bureaucratic
Largely
bureaucratic
Conservative
bureaucratic
Moderate
streamline
Minimal CIM
Some CIM
Moderate CIM
General SE tool
support CIM
Simple tools, weak
(Coverage, Integration,
integration
Maturity)
1 TRL 3 or > 1 TRL 1 TRL 4 or > 2 TRL
4
5
25
Mostly streamlined Fully streamlined
Considerable CIM
Extensive CIM
CORADMO Model Factors
Accelerators/Ratings
Very Low
Low
Nominal
High
Very High
Extra High
PROJECT FACTORS
1.08
1.04
1.00
0.96
0.93
0.90
Project size (peak # of
personnel)
Over 300
Over 100
Over 30
Over 10
Over 3
≤3
Collaboration support
Globally
distributed; weak
comm., data
sharing
Nationally
distributed; some
sharing
Regionally
distributed;
moderate sharing
Metro-area
distributed; good
sharing
Simple campus;
strong sharing
Largely collocated;
Very strong sharing
Single-domain MMPTs
(Models, Methods,
Processes, Tools)
Simple MMPTs,
weak integration
Minimal CIM
Some CIM
Moderate CIM
Considerable CIM
Extensive CIM
Multi-domain MMPTs
Simple; weak
integration
Minimal CIM
Some CIM or not
needed
Moderate CIM
Considerable CIM
Extensive CIM
PEOPLE FACTORS
1.13
1.06
1.00
0.94
0.89
0.84
General SE KSAs
(Knowledge, Skills,
Agility)
Weak KSAs
Some KSAs
Moderate KSAs
Good KSAs
Strong KSAs
Very strong KSAs
Single-Domain KSAs
Weak
Some
Moderate
Good
Strong
Very strong
Multi-Domain KSAs
Weak
Some
Moderate or not
needed
Good
Strong
Very strong
Team Compatibility
Very difficult
interactions
Some difficult
interactions
Basically
cooperative
interactions
Largely
cooperative
Highly cooperative
Seamless
interactions
26
CORADMO Model Factors
Accelerators/Ratings
Very Low
Low
Nominal
High
Very High
Extra High
RISK
ACCEPTANCE
FACTOR
1.13
1.06
1.00
0.94
0.89
0.84
Partly risk-averse
Balanced risk
aversion,
acceptance
Moderately riskaccepting
Considerably riskaccepting
Strongly riskaccepting
-
Highly risk-averse
27
Not Traditional “Agile” Factors
❖
CORADMO factors not principles of Agile Manifesto
[51]!
❖
Not practices of agile SDMs [6][7][52]!
❖
Factors derived from behavioral analysis of projects
exhibiting schedule acceleration [10], and from theory
28
ISD Agility Criteria
❖
Analysis of agility from “first-principles” identifies set of high-level
principles distinct from specific agile SDMs [53]!
❖
Method must contribute to at least one of the following:!
❖
❖
❖
Creation of change!
❖
Proaction in advance of change!
❖
Reaction to change!
❖
Learning from change!
Method component must contribute to at least one, and not detract from any:!
❖
Perceived economy!
❖
Perceived quality!
❖
Perceived simplicity!
Method must be continually ready—minimal time/cost to prepare for use
29
ISD Agility
Perceived Customer Value
Model Factor
Creation
Proaction
Reaction
Learning
Economy
Quality
Simplicity
Continual
Readiness
Simplicity
X
X
X
X
X
X
X
X
Element Reuse
X
X
X
X
X
X
X
X
Low-Priority Deferrals
X
X
X
X
X
X
X
X
X
Models vs Documents
X
Technology Maturity
X
Concurrent Operations
X
X
X
X
Process Streamlining
X
X
X
X
Tool Support CIM
X
X
X
Project Staff Size
X
Collaboration Support
X
Single-domain MMPTs
X
X
Multi-domain MMPTs
X
X
Team Compatibility
X
Risk Acceptance
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
30
X
X
Methodology
31
Initial Evaluation Process
❖
Decomposed five factors into sub-factors, using a six-value
Likert rating scale from very low to extra high!
!
❖
Based on earlier research into !
❖
❖
❖
❖
D = ∏ Fi PM
Project macro-risk factors [55]!
Performance- and personnel competency-risk factors [44]!
Agile factors as summarized by [56]!
Performed Wide-band Delphi to assign initial multiplier
values [13][57]
32
Commercial Project Factor Analysis
Application Type
Technology
Person
Months
Duration
(Months)
Duration
/ √PM
Product
Process
Project
People
Risk
Multiplier
Error %
Insurance agency
system
HTML/VB
34.94
3.82
0.65
VH
VH
XH
VH
N
0.68
5%
Scientific/engineering
C++
18.66
3.72
0.86
L
VH
VH
VH
N
0.80
–7%
Compliance - expert
HTML/VB
17.89
3.36
0.79
VH
VH
XH
VH
N
0.68
–15%
Barter exchange
SQL/VB/
HTML
112.58
9.54
0.90
VH
H
H
VH
N
0.75
–16%
Options exchange site
HTML/SQL
13.94
2.67
0.72
VH
VH
XH
VH
N
0.68
–5%
Commercial HMI
C++
205.27
13.81
0.96
L
N
N
VH
N
0.93
–3%
Options exchange site
HTML
42.41
4.48
0.69
VH
VH
XH
VH
N
0.68
–1%
Time and billing
C++/VB
26.87
4.80
0.93
L
VH
VH
VH
N
0.80
–14%
Hybrid Web/clientserver
VB/HTML
70.93
8.62
1.02
L
N
VH
VH
N
0.87
–15%
ASP
HTML/VB/SQL
9.79
1.39
0.44
VH
VH
XH
VH
N
0.68
53%
On-line billing/tracking
VB/HTML
17.20
2.70
0.65
VH
VH
XH
VH
N
0.68
4%
Palm email client
C/HTML
4.53
1.45
0.68
N
VH
VH
VH
N
0.76
12%
33
Survey Instrument
❖
Online survey instruments of about 22 questions!
❖
Gone through 10+ refinement iterations!
❖
Divided into six sections!
❖
❖
❖
❖
❖
❖
❖
Introductory and general project data!
Product factors!
Process factors!
Project factors!
People factors!
Risk acceptance factor!
Piloted by several individuals, ready to roll out
34
Survey Data Sources
Here’s where you
can help…
35
Questions
???
36
Bibliography
[1]!
B. Boehm and R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed. Boston: Addison-Wesley, 2004.!
[2]!
B. Boehm, B. Clark, E. Horowitz, A. W. Brown, R. Reifer, S. Chulani, R. Madachy, and B. Steece, Software Cost Estimation with
Cocomo II with Cdrom, 1st ed. Upper Saddle River, NJ, USA: Prentice Hall PTR, 2000.!
[3]!
J. Martin, Rapid application development. New York; Toronto; New York: Macmillan Pub. Co. ; Collier Macmillan Canada ; Maxwell
Macmillan International, 1991.!
[4]!
D. West, T. Grant, M. Gerush, and D. D’Silva, “Agile development: Mainstream adoption has changed agility,” Forrester Res., 2010.!
[5]!
S. de Cesare, M. Lycett, R. D. Macredie, C. Patel, and R. Paul, “Examining perceptions of agility in software development practice,”
Commun ACM, vol. 53, no. 6, pp. 126–130, Jun. 2010.!
[6]!
K. Beck, Extreme Programming Explained, 2nd ed. Boston: Addison-Wesley, 2005.!
[7]!
K. Schwaber, “SCRUM Development Process,” in Business Object Design and Implementation, D. J. Sutherland, C. Casanave, J.
Miller, D. P. Patel, and G. Hollowell, Eds. Springer London, 1997, pp. 117–134.!
[8]!
B. Boehm, “Software Engineering Economics,” IEEE Trans. Softw. Eng., vol. SE-10, no. 1, pp. 4–21, 1984.!
[9]!
S. Oligny, P. Bourque, A. Abran, and B. Fournier, “Exploring the relation between effort and duration in software engineering
projects,” in Proceedings of the World Computer Congress, 2000, pp. 175–178.!
[10]!
D. Lapore and J. Colombi, “Expedited Systems Engineering for Rapid Capability and Urgent Needs,” Stevens Institute of
Technology, SERC-2012-TR-034, Dec. 2012.
37
Bibliography
[11]!
V. R. Basili, R. W. Selby, and D. H. Hutchens, “Experimentation in software engineering,” Softw. Eng. IEEE Trans., no. 7, pp. 733–743,
1986.!
[12]!
D. Reifer, “Ten ‘Take Aways’ from the Reifer ‘Quantitative Analysis of Agile Methods’ Study,” Jul. 2013.!
[13]!
B. Boehm, Software Engineering Economics. Englewood Cliffs, N.J.: Prentice-Hall, 1981.[14]!
Month: Essays on Sotware Engineering. Reading, Mass [etc.]: Addison-Wesley, 1995.!
[15]!
O. A. Alnuaimi, L. P. Robert, and L. M. Maruping, “Team size, dispersion, and social loafing in technology-supported teams: A
perspective on the theory of moral disengagement,” J. Manag. Inf. Syst., vol. 27, no. 1, pp. 203–230, 2010.!
[16]!
N. Nan and D. E. Harter, “Impact of Budget and Schedule Pressure on Software Development Cycle Time and Effort,” IEEE Trans.
Softw. Eng., vol. 35, no. 5, pp. 624 –637, Oct. 2009.!
[17]!
L. Williams, R. R. Kessler, W. Cunningham, and R. Jeffries, “Strengthening the case for pair programming,” Softw. IEEE, vol. 17, no.
4, pp. 19–25, 2000.!
[18]!
L. Cao, B. Ramesh, and T. Abdel-Hamid, “Modeling dynamics in agile software development,” ACM Trans Manage Inf Syst, vol. 1,
no. 1, pp. 5:1–5:26, Dec. 2010.!
[19]!
S. McConnell, Software Estimation: Demystifying the Black Art: Demystifying the Black Art. O’Reilly Media, Inc., 2006.!
[20]!
C. E. Walston and C. P. Felix, “A method of programming measurement and estimation,” IBM Syst. J., vol. 16, no. 1, pp. 54–73, 1977.
38
F. Brooks, The Mythical Man-
Bibliography
[21]!
T. Menzies, B. Caglayan, E. Kocaguneli, J. Krall, F. Peters, and B. Turhan, “The PROMISE Repository of empirical software
engineering data.” West Virginia University, Department of Computer Science, 2012.!
[22]!
S. Nerur, R. Mahapatra, and G. Mangalaraj, “Challenges of migrating to agile methodologies,” Commun ACM, vol. 48, no. 5, pp. 72–
78, May 2005.!
[23]!
T. Dyba and T. Dingsoyr, “Empirical studies of agile software development: A systematic review,” Inf. Softw. Technol., vol. 50, no. 9–
10, pp. 833–859, Aug. 2008.!
[24]!
T. Dingsøyr, S. Nerur, V. Balijepally, and N. B. Moe, “A decade of agile methodologies: Towards explaining agile software
development,” J. Syst. Softw., vol. 85, no. 6, pp. 1213–1221, Jun. 2012.!
[25]!
J. Ford, R. Colburn, and Y. Morris, “Principles of Rapid Acquisition and Systems Engineering,” Air Force Institute of Technology,
Wright-Patterson Air Force Base, Ohio, 2012.!
[26]!
B. J. Zirger and J. L. Hartley, “The effect of acceleration techniques on product development time,” Eng. Manag. IEEE Trans., vol. 43,
no. 2, pp. 143–152, 1996.!
[27]!
J. A. Lane, B. Boehm, M. Bolas, A. Madni, and R. Turner, “Critical success factors for rapid, innovative solutions,” in New Modeling
Concepts for Today’s Software Processes, Springer, 2010, pp. 52–61.!
[28]!
R. L. Daft and R. H. Lengel, “Organizational Information Requirements, Media Richness and Structural Design,” Manag. Sci., vol.
32, no. 5, p. 554, 1986. [29]!
B. Boehm, B. Clark, E. Horowitz, C. Westland, R. Madachy, and R. Selby, “Cost models for future
software life cycle processes: COCOMO 2.0,” Ann. Softw. Eng., vol. 1, no. 1, pp. 57–94, 1995.
39
Bibliography
[30]!
J. Baik and B. Boehm, “Empirical analysis of CASE tool effects on software development effort,” ACIS Int. J. Comput. Inf. Sci., vol. 1,
no. 1, pp. 1–10, 2000.!
[31]!
B. Boehm, “A spiral model of software development and enhancement,” Computer, vol. 21, no. 5, pp. 61–72, 1988.!
[32]!
P. Kruchten, The rational unified process: an introduction. Addison-Wesley Professional, 2004.!
[33]!
M. A. Cusumano and R. Selby, Microsoft secrets: how the world’s most powerful software company creates technology, shapes
markets, and manages people. New York: Simon & Schuster, 1995.!
[34]!
D. E. Strode, S. L. Huff, B. Hope, and S. Link, “Coordination in co-located agile software development projects,” J. Syst. Softw., vol.
85, no. 6, pp. 1222–1238, Jun. 2012.!
[35]!
J. A. Lane and B. Boehm, “Modern Tools to Support DoD Software Intensive System of Systems Cost Estimation,” USC Center for
Systems and Software Engineering, DAN 347336, Aug. 2007.!
[36]!
P. S. Adler and B. Borys, “Two Types of Bureaucracy: Enabling and Coercive,” Adm. Sci. Q., vol. 41, no. 1, pp. 61–89, Mar. 1996.!
[37]!
W. E. Deming, Out of the crisis. Cambridge, Mass.: MIT Press, 2000.!
[38]!
T. Ono, Toyota production system: beyond large-scale production. Portland, Or.: Productivity Press, 1988.!
[39]!
D. J. Anderson and D. G. Reinertsen, Kanban: Successful Evolutionary Change for Your Technology Business. Sequim, Washington:
Blue Hole Press, 2010.
40
Bibliography
[40]!
J. Baik, B. Boehm, and B. Steece, “Disaggregating and calibrating the CASE tool variable in COCOMO II,” IEEE Trans. Softw. Eng.,
vol. 28, no. 11, pp. 1009–1022, 2002.!
[41]!
D. R. Jeffery, “Time-sensitive cost models in the commercial MIS environment,” Softw. Eng. IEEE Trans., no. 7, pp. 852–859, 1987.!
[42]!
J. E. Hannay and H. C. Benestad, “Perceived productivity threats in large agile development projects,” in Proceedings of the 2010
ACM-IEEE International Symposium on Empirical Software Engineering and Measurement, New York, NY, USA, 2010, pp. 15:1–
15:10.!
[43]!
V. U. Druskat and A. T. Pescosolido, “The Content of Effective Teamwork Mental Models in Self-Managing Teams: Ownership,
Learning and Heedful Interrelating,” Hum. Relations, vol. 55, no. 3, pp. 283–314, Mar. 2002.!
[44]!
B. Boehm, D. Ingold, K. Dangle, R. Turner, and P. Componation, “Early Identification of SE-Related Program Risks,” Mar. 2010.!
[45]!
L. J. Arthur, Rapid evolutionary development: requirements, prototyping & software creation. New York [u.a.: Wiley, 1992.!
[46]!
J. A. Highsmith, Adaptive software development: a collaborative approach to managing complex systems. New York: Dorset House
Pub., 2000.!
[47]!
S. McConnell, Rapid development: taming wild software schedules. Redmond, Wash.: Microsoft Press, 1996.!
[48]!
E. M. Murman, Lean enterprise value insights from MIT’s Lean Aerospace Initiative. New York: Palgrave, 2002.!
[49]!
United States Air Force, “Air Force Instruction 63-114.” 04-Jan-2011.
41
Bibliography
[50]!
J. P. Womack and D. T. Jones, Lean thinking: banish waste and create wealth in your corporation. New York: Free Press, 2003.!
[51]!
K. Beck, M. Beedle, A. van Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, J.
Kern, B. Marick, R. C. Martin, S. Mellor, K. Schwaber, J. Sutherland, and D. Thomas, Manifesto for Agile Software Development,
http://www.agilemanifesto.org, vol. 2006. 2001.!
[52]!
A. Cockburn, Agile software development. Boston: Addison-Wesley, 2002.!
[53]!
K. Conboy, “Agility from First Principles: Reconstructing the Concept of Agility in Information Systems Development,” Inf. Syst.
Res., vol. 20, no. 3, pp. 329–354, Sep. 2009.!
[54]!
S. Chulani, B. Boehm, and B. Steece, “Bayesian analysis of empirical software engineering cost models,” IEEE Trans. Softw. Eng., vol.
25, no. 4, pp. 573 –583, Aug. 1999.!
[55]!
B. Boehm, D. Ingold, and R. Madachy, “The Macro Risk Model: An Early Warning Tool for Software-Intensive Systems Projects,” in
Proceedings of the 18th Annual International Symposium of INCOSE, The Netherlands, 2008.!
[56]!
D. Parsons, H. Ryu, and R. Lal, “The impact of methods and techniques on outcomes from agile software development projects,” in
Organizational Dynamics of Technology-Based Innovation: Diversifying the Research Agenda, Springer, 2007, pp. 235–249.!
[57]!
H. A. Linstone and M. Turoff, The Delphi Method: Techniques and Applications, vol. 2006. 2002.
42