EssayBark -Excellent Writing Services

Appendix E: Estimating Process for Agile Based on GAO

Best Practices for Estimation

In the report, GAO Cost Estimating and Assessment Guide, the GAO has provided a useful guide

for helping a program office understand the mechanics of cost estimation. Figure 16 shows the

generalized estimation process recommended by the GAO. This section will overview the steps in

the GAO’s process, and highlight areas where particular approaches or issues come up when

discussing estimation of projects that use Agile methods [GAO 2009].

Figure 16: GAO-09-3SP Estimation Process Diagram

The process of estimation laid out by the GAO is applicable to a project using Agile methods as

well as to any other kind of project. An Agile project’s estimation is likely to look different from a

traditional project’s in terms of the estimating structure, ground rules and assumptions, and the

data that is gathered to support the estimate.

The sections that follow will address these issues from the viewpoint of the team that is making

the estimate (in DoD acquisitions, often a contractor). It is our belief that an understanding of the

estimating team’s process will make it easier for the team evaluating the estimate (typically the

government program office) to judge the appropriateness of the estimate.

Estimating Structure

Steps in the GAO guide for determining the estimating structure include:

• Define a work breakdown structure (WBS) and describe each element in a WBS dictionary (a

major automated information system may have only a cost element structure).

• Choose the best estimating method for each WBS element.
• Identify potential cross-checks for likely cost and schedule drivers.
• Develop a cost-estimating checklist.

Agile projects we interviewed had used multiple estimating structures, including product-oriented

ones similar to traditional programs, as well as WBS that were based on releases and sprints

(short, usually two- to four-week iterations), a typical construct of Agile projects. Where projects

CMU/SEI-2011-TN-002 | 94

were able to build the estimating structure to mimic the project approach (i.e., the releases/sprints

approach), estimates were easier to construct and communicate.

Ground Rules and Assumptions

The steps in the GAO guide for identifying ground rules and assumptions include:

• Clearly define what the estimate includes and excludes.
• Identify global and program-specific assumptions, such as the estimate’s base year, including

time phasing and life cycle.

• Identify program schedule information by phase and program acquisition strategy.
• Identify any schedule or budget constraints, inflation assumptions, and travel costs.
• Specify equipment the government is to furnish as well as the use of existing facilities or new

modification or development.

• Identify prime contractor and major subcontractors.
• Determine technology refresh cycles, technology assumptions, and new technology to be

developed.

• Define commonality with legacy systems and assumed heritage savings.
• Describe effects of new ways of doing business.

This is the step where communicating about an Agile program’s intended use of Agile methods is

important, because the typical assumptions that underlie traditional estimates are likely to be

different.

Some of the above items (like specifying equipment) are not specifically tied to use of Agile

methods. This is a case where the ground rules come from the acquisition program, and the

assumptions are provided by the estimator.

There are three specific areas where discussions about Agile methods can easily be called out—

identify program schedule information by phase and acquisition strategy; identify schedule or

budget constraints; and describe the effects of new ways of doing business.

When discussing program schedule in terms of acquisition strategy, discussing the Agile practices

related to evolving functionality over multiple releases, and not completely specifying

requirements at the beginning of the project, are relevant discussion points. For example, some

programs can tolerate having an approved list of capabilities, versus a highly specific list of

parameterized requirements. The level of abstraction of capabilities and requirements should be

specified in the SOW so that there is no misunderstanding as the effort proceeds.

In terms of describing effects of new ways of doing business, this is where a program office can

lay out its expectations in terms of releases, sprints, types of stories to be supported, continuous

integration/test environments expected to be provided, and other practice and technology elements

that may be involved with the particular Agile methods they wish to support. Estimators need to

reveal their own methods and assumptions and how those are expected to affect how business will

be conducted.

CMU/SEI-2011-TN-002 | 95

Contractors using Agile methods that we interviewed emphasized the importance of creating a

shared mental model of ground rules and assumptions between the developer and the program

office. Where a program office wanted to both use Agile methods on the project and apply

traditional cost estimation (having their cake and eating it too), contractors tended to pick up the

effort of translating their estimates based on Agile ground rules into estimates that reflect more

traditional size or size surrogate-based approaches. Some of this is helped by methods like

AgileEVM, which is discussed in Section 5.

Data

The steps in the GAO report for obtaining data include:

• Create a data-collection plan with emphasis on collecting current and relevant technical,

programmatic, cost, and risk data.

• Investigate possible data sources.
• Collect data and normalize them for cost accounting, inflation, learning, and quantity

adjustments.

• Analyze the data for cost drivers, trends, and outliers and compare results against rules of

thumb and standard factors derived from historical data.

• Interview data sources and document all pertinent information, including an assessment of

data reliability and accuracy.

• Store data for future estimates.

Agile projects are actually quite data-centric. However, the data that is gathered is a bit different

from traditional projects, and its use in estimation is typically different as well.

A Nominal Agile Estimation Process in a DoD Context

Based on Mike Cohn’s Agile Estimating and Planning, three basic concepts are key to creating

and using estimates in Agile projects [Cohn 2006]:

• Estimation of overall size can only give a high-level estimate for the work item, typically

measured using a neutral unit such as story points.

• Velocity is a measure of how many points this project team can deliver within an iteration.
• Estimation of effort for a work item translates the size (measured in points) to a detailed

estimate using hours for each subtask. This estimation is usually undertaken at the beginning

of a sprint or iteration, and is based on the velocity and whatever heuristics have been used to

characterize the user stories that are the basis for the work item.

Agile estimation processes, like Agile methods in general, focus on near-term requirements and

activities in more detail than longer-term requirements do. Therefore, the first step in Agile

estimation is to elicit the requirements that are known at the time of the project start. Many Agile

projects are not fresh starts, they build on existing legacy software baselines. Requirements may

come in the guise of defects that need to be corrected or enhancements that are sometimes phrased

as defects (“I want the software to do X, but it does Y” when it was never expected to have to do

Y). The difference between the two conditions is whether there is an existing architecture for the

product.

CMU/SEI-2011-TN-002 | 96

In summary, as with most other aspects of Agile development, existing practices, such as the

GAO estimation practices, can be readily adapted for use in programs using Agile, with

appropriate knowledge of both the Agile side and the traditional side of the topic.

CMU/SEI-2011-TN-002 | 97

Appendix F: Details on Satir Organizational Change

Management Model

Satir Change Cycle Details

Remembering the cycle charted in Figure 14 (reproduced below), it is useful to think about how

an individual or group actually makes their way through the cycle (or does not, in the case of an

unsuccessful change).

The flowchart version of the Satir cycle emphasizes that there are multiple points at which an

individual or group can backtrack into a prior stage if they are unsupported in making each shift

[Weinberg 1997].

Figure 17: Flowchart Version of Satir Change Model

CMU/SEI-2011-TN-002 | 98

This model can be very explanatory when observing the behavior of an organization trying to

adopt Agile methods. For example, when a program manager tries to use the same technical

review agenda for an Agile project that they use for other types of projects, they are trying to

accommodate the foreign element (new customer behaviors required by Agile methods) in their

old model. Organizations that all of a sudden go back to traditional methods after using Agile

methods for a period of time are often ones who were not given sufficient opportunity to integrate

and practice the new behaviors to the point where they could be (at least) as successful as before.

CMU/SEI-2011-TN-002 | 99

Appendix G: Adler Factors Related to Complexity and Timing

of Change Effort

In the main body of this technical note, we introduced a set of factors that help to determine the

scale and scope of an organizational change. The factors are explained in a bit more detail here

[Adler 1990].

Skills: The least impacting change involves something where the only thing that needs to change

is the skills of the people adopting the new practices. The caveat here is an assumption that the

new skill has some grounding in other skills the adopters are likely to have.

Procedures: Next higher on Adler’s scale is procedures. When procedures need to change, there

is usually a chain of command that must be brought in to the decision. Sometimes the

management of an organization is unaware of the procedural changes that adopting a new

technology (e.g., an electronic health record system) will have. Changing procedures sometimes

also involves changing where power resides within an organization, leading to conflict.

Structure: Beyond procedures, structure is the next higher item on Adler’s scale. Structural

changes almost always involve changes in power structures, which gets the attention of people

who are not necessarily actual adopters of the new practices, but are affected by the adopters, or

are affected by the outcomes of new procedures. Any time power and its exercise are involved,

passions will run high and resistance to changing the status quo is likely.

Strategy: Strategy goes beyond structure to touching the senior decision-makers in an

organization. When business strategy changes, it often means that shifts in the markets are paid

attention to, and there are implications for all the factors below it on Adler’s scale.

Culture: Culture is at the top of the change difficulty scale from Adler. When the culture is

expected to change, it impacts people’s values and their assumptions about what behavior is

acceptable and not acceptable within the organization. Often these assumptions and values are not

explicit; they are discovered primarily by violating one or more of the organization’s norms.

CMU/SEI-2011-TN-002 | 100

CMU/SEI-2011-TN-002 | 101

Appendix H: Notes from the Field

In the course of conducting interviews and reviews for this document, several of our interviewees

and reviewers had their own ideas about what to change or how to change some particular aspect

of DoD culture to successfully adopt Agile methods. The following are quotes from either an

interviewee or a reviewer, framed in terms of the topic they were discussing. Their roles within

DoD acquisition, though not their names, are included.

With regard to delivering more value with limited or shrinking resources, a senior program

manager stated:

If you have a schedule and you are three months behind … but need ATEC testing … and a

test unit for your IOT&E … there is NO way you can postpone to improve quality. If you try,

you lose your test unit (because they will likely have to deploy/train to deploy), you lose your

funding (because it expires or gets taken away for not spending it when you were supposed

to, and you have to go explain to a myriad of oversight bodies what your problems are …

and the multiple differing bodies do not agree … and want updated documentation (CBA,

EA, ROI, net present value).

Bottom line is that you can’t stop to take the time to improve quality … you go live with what

you have, you skip testing, you field the poor-quality system … and you try to fix it after go

live in sustainment.

Additionally, you are incentivized to get into sustainment (post MS C) on ACAT 1D

programs to remove the constraint of OSD oversight … to try and get MDA delegated to the

component.

On the topic of system relationship to software:

This discussion (and virtually all Agile methodology discussions) fails to address the system

design/architecture analysis phases, which identify and specify SW components that need to

be built (or acquired) from the actual SW development methodology used to actually develop

the one to many software components (or products). For large systems, there may be several

layers of architectural analysis performed (system to segment, segment to element, element

to component) before the SW components are identified and specified. The specification of a

software component would be identifying the stories and epics for that component. As soon

as there is an initial set of stories that are “good enough” (this is the product backlog), then

the iterative/Agile SW component development can begin. All of the continued learning and

updates to the “system,” “segment,” “element” engineering may result in updates being

made to the component (or product) backlog over time. The rhythm of

system/segment/element engineering does not have to be the same as the rhythm of the SW

component Agile development.

For large systems (such as those often acquired by the DoD) this is a very important

discussion and distinction.

On the topic of Agile methods and each Service:

There should be an organization in each Service that has competency in these things … and

repeatable processes. That is NOT subject to the existing 5000. Where the software PMs have

authority sufficient for responsibility.

CMU/SEI-2011-TN-002 | 102

 Things the organization will need:

• dedicated architects that are RESPONSIBLE to the PM for what gets built (not above the

1. PM) drawing cartoon compliance architectures

• dedicated lawyers
• dedicated KOs for each program
• an infrastructure team that is RESPONSIBLE for actual implementation of ALL

programs (not one). This means they are responsible for its stand-up, not just its

oversight

• dedicated functional experts; including FINANCE people that understand the proprietary

government rules (requirements) that have to be built into all software

• dedicated cost estimators that do it for ALL programs the same way, with the same tools

and cost elements

On the topic of DoD culture of guidance that inhibits common sense:

With regard to enterprise software buys:

Seven programs with licenses bought from Company “X” with strings attached. Users of all

seven systems require seven different licenses for the same product (e.g., a user of these seven

systems has seven licenses for the SAME PRODUCT being used in seven different system

stacks).

Proposed Solution: Enterprise license that allows access to all seven systems with one license

… based on a package of Company “X” products that gives every program what they need …

and then some … for 50% less.

The programs cannot mix funding (different colors, appropriated vs. non-appropriated) and it

is against the law to “augment the funding of one program with that of another”… it gets

stupidly hard … PMs give up … and the government spends lots more money.

On the topic of trying to use rolling wave planning as an Agile support:

How does this fit with the requirements for 25-year lifecycle costs, independently validated by

the Service and DoD … and EVM attached to an approved baseline and APB that must not

change by more than 10%?

Don’t forget that you must know the different colors of money … so, you have to “guess” what

color you need before you know what you really need (can DISA provide that unique Teradata

hardware/software as a managed service … or do you have to buy it as a capital investment

and just have DISA run it?) … color of money matters.…

 … and there is a $250k limit on using OPS money for “development” … or “fixes”

… and anything more than $1M for a “business system” must go to the DOD Investment

Review Board (IRB) … after it goes through the component and DCMO … and functional

proponent.

CMU/SEI-2011-TN-002 | 103

… and trading partners of that business domain system are in the “warfighting domain” …

with different governance.

 A labyrinth of bureaucracy.

On the topic of cultural themes supporting Agile methods:

If I were to pick a third theme, it would be teamwork. Agile is all about working as a team,

including the customer as a valued team member. That change from us versus them to all of us

working together to solve the customer’s problem is a much bigger deal. And it may be one of

the biggest hurdles that DoD has to overcome to transition to Agile. We have to put trust and

goodwill back into the contractual relationship.

On the topic of embracing change and its importance in an Agile culture:

Embracing change is also the reason that Agile teams build quality SW. They know that if

future changes are to be cost effective, the SW has to be clean. This is a fundamental difference

between Agile and traditional. With traditional approaches, you often try to enable future

change with infrastructures, hooks, etc. Agile takes a fundamentally different approach. Rather

than anticipate what will change, they try to build SW that is amenable to change—few

dependencies, clear code, safety net for future changes, etc.

On the topic of the importance of adopting Agile values, not just Agile practices:

Agile methods are not an option, they are what we do, how we behave. Having to justify Agile

principles on every program basically keeps us from every actually becoming Agile; we simply

act Agile from time to time. This is not where we want to be.

On the topic of the challenges in changing DoD culture to accommodate appropriate use of

Agile methods:

Changing a culture is a large-scale change effort that will take time to implement. It is not

critical that the culture be changed in order to start adopting Agile methods, but it is for them

to be successful over the long term.

On the topic of embracing change:

The current DoD processes are change resistant—plan driven—and I think it is going to be a

major mental/cultural shift to embrace change.

Trust and willingness to make mistakes are two more biggies with Agile. These are two things

that (in my experience) are not encouraged or tolerated in many DoD projects.

Mastery comes with experience and feedback that a process works. Trust is built over time, so

it is critical to start taking baby Agile steps and not wait until you have the culture fixed first.

On the topic of “doing Agile” versus “being Agile”:

One of the first things that I tell people when I am coaching them about Agile is that Agile is

not just something that you do by following a process, but it’s something that requires you to

think differently. This is where a lot of teams fail using Agile.

CMU/SEI-2011-TN-002 | 104

CMU/SEI-2011-TN-002 | 105

Appendix I: Selected Agile Resources

The Program Management Institute has started an Agile certification program. The following is

the institute’s current (as of publication of this TN) list of references:

Agile Retrospectives: Making Good Teams Great

Esther Derby, Diana Larsen, Ken Schwaber

ISBN #0977616649

Agile Software Development: The Cooperative Game – Second Edition

Alistair Cockburn

ISBN #03214827

The Software Project Manager’s Bridge to Agility

Michele Sliger, Stacia Broderick

ISBN #0321502752

Coaching Agile Teams

Lyssa Adkins

ISBN #0321637704

Agile Project Management: Creating Innovative Products – Second Edition

Jim Highsmith

ISBN #0321658396

Becoming Agile: …In an Imperfect World

Greg Smith, Ahmed Sidky

ISBN #1933988258

Agile Estimating and Planning

Mike Cohn

ISBN #0131479415

The Art of Agile Development

James Shore

ISBN #0596527675

User Stories Applied: For Agile Software Development

Mike Cohn

ISBN #0321205685

Agile Project Management with Scrum

Ken Schwaber

ISBN #073561993X

Lean-Agile Software Development: Achieving Enterprise Agility

Alan Shalloway, Guy Beaver, James R. Trott

ISBN #0321532899

See www.pmi.org/Certifcation/New-PMI-Agile-Certifcation.aspx for updated information.

CMU/SEI-2011-TN-002 | 106

CMU/SEI-2011-TN-002 | 107

References

[Adler 1990]

Adler, P. S. & Shenhar, A. “Adapting Your Technological Base: The Organizational Challenge.”

Sloan Management Review 32, 1 (1990): 25-37.

[Agile Alliance 2001]

Agile Alliance. History: The Agile Manifesto. http://agilemanifesto.org/history.html (2001).

[Ambler 2004]

Ambler, Scott W. Disciplined Agile Software Development: Definition.

http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm (2004).

[Bhalareo 2009]

Bhalareo, S. “Incorporating Vital Factors in Agile Estimation through Algorithmic Method,”

International Journal of Computer Science and Applications 6, 1 (2009) 85-97.

[Boehm 1981]

Boehm, B. Software Engineering Economics, Prentice Hall, 1981.

[Boxer 2009]

Boxer, P. & Garcia, S. Limits to the Use of the Zachman Framework in Developing and Evolving

Architectures for Complex Systems of Systems. SATURN Conference, May 2009. Software

Engineering Institute, 2009.

http://www.sei.cmu.edu/saturn/2009/images/Limit_use_Zachman_Framework.pdf

[CASISP 2010]

Committee for Advancing Software-Intensive Systems Producibility, National Research Council.

Critical Code: Software Producibility for Defense. The National Academies Press, 2010.

[CIPP 2010]

Committee on Improving Processes and Policies for the Acquisition and Test of Information

Technologies in the Department of Defense, National Research Council. Achieving Effective

Acquisition of Information Technology in the Department of Defense. The National Academies

Press, 2010.

[Cockburn 2007]

Cockburn, A. Agile Software Development: The Cooperative Game, 2nd ed. Addison-Wesley,

2007.

[Cohn 2006]

Cohn, M. Agile Estimating and Planning. Addison-Wesley, 2006.

CMU/SEI-2011-TN-002 | 108

[Cohn 2008]

Cohn, M. “When Should We Estimate the Product Backlog.” Mike Cohn’s Blog – Succeeding

with Agile (March 16, 2008). http://blog.mountaingoatsoftware.com/when-should-we-estimatethe-product-backlog

 

[Conner 1983]

Conner, D. & Patterson, R. “Building Commitment to Organizational Change.” Training and

Development Journal (April 1983):18-30.

[CSSE 2011]

Center for Systems and Software Engineering, University of Southern California. Agile

COCOMO II. http://csse.usc.edu/csse/research/AgileCOCOMO/ (2011).

[Defense Acquisition University 2011a]

Defense Acquisition University. Defense Acquisition Guidebook, July 2011. Defense Acquisition

University, 2011.

[Defense Acquisition University 2011b]

Defense Acquisition University. “Foreword.” Defense Acquisition Guidebook. Defense

Acquisition University, 2011. https://acc.dau.mil/CommunityBrowser.aspx?id=314709. Accessed

July 13, 2011.

[Defense Acquisition University 2011c]

Defense Acquisition University. Ch. 4.3.6, “Evolutionary Acquisition Programs,” 280-281.

Defense Acquisition Guidebook. http://at.dod.mil/docs/DefenseAcquisitionGuidebook.pdf.

Accessed Sep 12, 2011.

[Defense Acquisition University 2011d]

Defense Acquisition University. Ch. 3.1.2, “Life-Cycle Cost Categories and Program Phases,”

Defense Acquisition Guidebook. https://acc.dau.mil/CommunityBrowser.aspx?id=314767#3.1.2.

Accessed July 13, 2011.

[Defense Acquisition University 2011e]

Defense Acquisition University. Welcome to the Defense Acquisition Guidebook Home Page.

https://acc.dau.mil/CommunityBrowser.aspx?id=289207&lang=en-US. Accessed July 13, 2011.

[Defense Science Board 2009]

Defense Science Board. Report of the Defense Science Board Task Force on Department of

Defense Policies and Procedures for the Acquisition of Information Technology. Office of the

Under Secretary of Defense for Acquisition, Technology, and Logistics, 2009.

[Department of Defense 2011]

Department of Defense. Section 2.5.2.4.1, “Guidance,” 57. Earned Value Management

Implementation Guide. Department of Defense, 2006.

https://acc.dau.mil/CommunityBrowser.aspx?id=386074&lang=en-US. Accessed July 13, 2011.

CMU/SEI-2011-TN-002 | 109

[Elssamadisy 2009]

Elssamadisy, A. Agile Adoption Patterns: A Roadmap to Organizational Success. Pearson

Education, Inc., 2009.

[GAO 2009]

Government Accountability Office. GAO Cost Estimating and Assessment Guide: Best Practices

for Developing and Managing Capital Program Costs (GAO-09-3SP). United States Government

Accountability Office, 2009.

[Garcia 2006]

Garcia, S. & Turner, R. CMMI Survival Guide: Just Enough Process Improvement. AddisonWesley,

2006.

[Gates 2008]

Gates, R. M. Speech to National Defense University (Washington, D.C.) Monday, September 29,

2008. http://www.defense.gov/Speeches/Speech.aspx?SpeechID=1279 (2008). Accessed July 13,

2011.

[Highsmith 2009]

Highsmith, J. Agile Project Management: Creating Innovative Products, 2nd ed. AddisonWesley,

2009.

[House Armed Services Committee 2010]

House Armed Services Committee. House Armed Services Committee Panel on Defense

Acquisition Reform Findings and Recommendations (DAR Final Report [3-23-2010]). United

States House of Representatives, 2010.

[Jones 1995]

Jones, C. Patterns of Software System Failure and Success. International Thompson Computer

Press, 1995.

[Kovatch 2009]

Kovatch, D. Roles & Responsibility of the Product Owner. Scrum Gathering, Orlando, FL, 2009.

Scrum Alliance, 2009. http://www.scrumalliance.org/resources/617

[Lapham 2010]

Lapham, M.A.; Williams, R.; Hammons, C.; Burton, D.; & Schenker, A. Considerations for

Using Agile in DoD Acquisition (CMU/SEI-2010-TN-002). Software Engineering Institute,

Carnegie Mellon University, 2010. http://www.sei.cmu.edu/library/abstracts/reports/10tn002.cfm

[Larman 2004]

Larman, C. Agile and Iterative Development: A Manager’s Guide. Addison-Wesley, 2004.

[Leffingwell 2008]

Leffingwell, D. Scaling Software Agility. Addison-Wesley, 2008.

CMU/SEI-2011-TN-002 | 110

[Moore 2002]

Moore, G. Crossing the Chasm: Marketing and Selling Disruptive Products to Mainstream

Customers. Harper Business Essentials, 2002.

[OSD 2010]

Office of the Secretary of Defense. A New Approach for Delivering Information Technology

Capabilities in the Department of Defense, Report to Congress, November 2010, Pursuant to

Section 804 of the National Defense Authorization Act for Fiscal Year 2010. United States

Department of Defense, 2010. http://dcmo.defense.gov/documents/OSD%2013744-10%20-

%20804%20Report%20to%20Congress%20.pdf

[Ozkaya 2011]

Ozkaya, I.; Brown, N.; & Nord, R. Ch. 3, “Communicating the Value of Architecting within Agile

Development,” 11-22. Results of SEI Independent Research and Development Projects (FY 2010)

(CMU/SEI-2011-TR-002). Software Engineering Institute, Carnegie Mellon University, 2011.

http://www.sei.cmu.edu/library/abstracts/reports/11tr002.cfm

[Poppendieck 2003]

Poppendieck, M. & Poppendieck, T. Lean Software Development. Addison-Wesley, 2003.

[Project Management Institute 2008]

Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK

Guide), 4th ed. Project Management Institute, 2008.

[Rally Software 2010]

Rally Software. Agile Adoption Trends and Their Implications for Your Company. Rally

Software, Inc., 2010. http://www.slideshare.net/rallysoftware/agile-adoption-trends. Accessed

July 13, 2011.

[Rawsthorne 2010]

Rawsthorne, D. Agile Release Planning and Monitoring. CollabNet, 2010.

http://www.open.collab.net/media/pdfs/SBU_ReleasePlanning.pdf. Accessed July 13, 2011.

[Rogers 2003]

Rogers, E. Diffusion of Innovation, 5th ed. Simon & Schuster, 2003.

[Ruhe 2009]

Ruhe, Guenther. Product Release Planning: Methods, Tools and Applications. Auerbach

Publishing, 2009.

[Schein 2009]

Schein, Edgar H. Organizational Culture and Leadership, 3rd ed. Jossey-Bass Publishers, 2004.

[Schenker 2007]

Schenker, F. & Jacobs, R. Project Management by Functional Capability. Presented at the 7th

Annual CMMI Technology Conference and User Group, Denver, CO, November 2007.

www.dtic.mil/ndia/2007cmmi/Thursday/3amSchenker.pdf

CMU/SEI-2011-TN-002 | 111

[SEER-SEM 2011]

“SEER-SEM.” http://en.wikipedia.org/wiki/SEER-SEM. Accessed July 13, 2011.

[Shalloway 2009]

Shalloway, A.; Beaver, G.; & Trott, J. R. Lean-Agile Software Development: Achieving

Enterprise Agility. Addison-Wesley, 2009.

[Sidky 2009]

Sidky, A. & Smith, G. Becoming Agile in an Imperfect World. Manning Publications Co., 2009.

[Stutzke 2005]

Stutzke, R. Estimating Software-Intensive Systems: Projects, Products, and Processes. AddisonWesley,

2005.

[Sulaiman 2006]

Sulaiman, T; Barton, B.; & Blackburn, T. “AgileEVM – Earned Value Management in Scrum

Projects,” 10-16. AGILE ’06 Proceedings of the Conference on AGILE 2006. Minneapolis, MN,

July 2006. IEEE Computer Society, 2006.

[Treacy 1995]

Treacy, M. & Wiersema, F. The Discipline of Market Leaders: Choose Your Customers, Narrow

Your Focus, Dominate Your Market. Perseus Books, 1995.

[Weinberg 1997]

Weinberg, G. Quality Software Management: Anticipating Change. Dorset House, 1997.

CMU/SEI-2011-TN-002 | 112

REPORT DOCUMENTATION PAGE Form Approved

OMB No. 0704-0188

Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions,

searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments

regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington

Headquarters Services, Directorate for information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to

the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503.

1. AGENCY USE ONLY

(Leave Blank)

2. REPORT DATE

October 2011

3. REPORT TYPE AND DATES

COVERED

Final

4. TITLE AND SUBTITLE

Agile Methods: Selected DoD Management and Acquisition Concerns

5. FUNDING NUMBERS

FA8721-05-C-0003

6. AUTHOR(S)

Mary Ann Lapham, Suzanne Miller, Lorraine Adams, Nanette Brown, Bart Hackemack, Charles (Bud) Hammons, PhD, Linda Levine,

PhD, Alfred Schenker

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

Software Engineering Institute

Carnegie Mellon University

Pittsburgh, PA 15213

8. PERFORMING ORGANIZATION

REPORT NUMBER

CMU/SEI-2011-TN-002

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)

HQ ESC/XPK

5 Eglin Street

Hanscom AFB, MA 01731-2116

10. SPONSORING/MONITORING

AGENCY REPORT NUMBER

CMU/SEI-2011-TN-002

11. SUPPLEMENTARY NOTES

12A DISTRIBUTION/AVAILABILITY STATEMENT

Unclassified/Unlimited, DTIC, NTIS

12B DISTRIBUTION CODE

13. ABSTRACT (MAXIMUM 200 WORDS)

This technical note (TN), the second in an SEI series on Agile in the DoD, addresses some of the key issues that either must be

understood to ease the adoption of Agile or are seen as potential barriers to adoption of Agile in the DoD acquisition context. These

topics were introduced in the first TN of the series, CMU/SEI-2010-TN-002. For this TN, the SEI gathered more data from users of Agile

methods in the DoD and delved deeper into the existing body of knowledge about Agile before addressing them. Topics considered here

include: why DoD is interested in Agile methods; what it means to be Agile in the DoD; managing and contracting for Agile programs;

technical milestone reviews in a DoD Agile acquisition context; estimating in a DoD Agile acquisition context; and moving toward

adopting Agile practices. The authors hope that this report continues to stimulate discussion about and appropriate adoption of Agile in

the DoD and federal agencies.

14. SUBJECT TERMS

agile methods, agile acquisition

15. NUMBER OF PAGES

119

16. PRICE CODE
17. SECURITY CLASSIFICATION OF

REPORT

Unclassified

18. SECURITY CLASSIFICATION

OF THIS PAGE

Unclassified

19. SECURITY CLASSIFICATION

OF ABSTRACT

Unclassified

20. LIMITATION OF

ABSTRACT

UL

NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89) Prescribed by ANSI Std. Z39-18

298-102