EssayBark -Excellent Writing Services

Figure 4: Classic Iron Triangle

However, software development projects often fail because the organization sets unrealistic goals

for the Iron Triangle. An example of this came from one of our reviewers. If the government got a

requirement to take a simple Hypertext PreProcessor (PHP)/mySQL-based forum type website

that already exists in the .com and simply move it to the .mil, it could take $3-5 million and a year

to complete. This would include, but not be limited to, documenting a new start, conducting a

capabilities assessment, assigning a program manager, finding a host, doing the justification and

approval, establishing contracts, getting the vendor and “approved” system for billing, briefing the

required oversight groups, and so forth. If this type of requirement occurred within a commercial

environment, it would take about two hours and less than $1,000.

“The fact that (particularly SIDRE [software-intensive innovative development and

reengineering/evolution]) software development effort and duration cannot be estimated precisely

means that it is unwise to try to lock a software project into simultaneously fixed budget,

schedule, and feature content (as has been found in many fixed-price, fixed-requirements software

development contracts)” [Critical Code 2010]. In the end, if the project team delivers at all, the

quality of the delivered product suffers and the project is almost always late and over budget.

 

6

 The triangle is the historical representation of this idea as well as for process. The two triangles do not

represent the same ideas but rather only use the same icon.

Schedule

Scope

Cost

Quality

CMU/SEI-2011-TN-002 | 7

With the emergence of Agile, another view of the Iron Triangle has evolved. Jim Highsmith

proposed the Agile Triangle as an alternative to measuring performance with the Iron Triangle

because Agile is all about being flexible [Highsmith 2009]. Since value is based on capabilities

that the users or stakeholders find valuable, scope is the cornerstone of the Agile Triangle. Scope

should be considered first and cost and schedule should adapt to achieving the scope. This may or

may not be possible, but it is the ideal. Because Agile processes and methods allow for flexibility,

customers also gain more innovation value in that it is easier for them to be inventive or consider

new ideas.

Highsmith has continued to evolve the initial Agile Triangle. The most important items to

measure should be value and quality, within the constraints of the program (scope, cost,

schedule). According to Highsmith, these are defined as

1. Value: Your project’s value should be measured by the stakeholders and what they expect.
2. Quality: The quality part of the triangle means you can deliver a reliable product by adapting

to the customer’s needs.

3. Constraints: Here is where the three elements of the Iron Triangle appear—project scope,

schedule, and cost.

The new Agile Triangle shown in Figure 5 illustrates these attributes.

Figure 5: New Agile Triangle7

 

The new Agile Triangle changes the foundational trade-off elements to include value and quality,

and keeps the old standards of cost, schedule, and scope in the constraints part of the triangle.

This is another way in which Agile addresses Gates’s need for a “75% solution in months.” By

putting the focus on value to end users through such approaches as continual end-user

involvement, Agile’s philosophy is poised to address explicit DoD needs.

 

7

 Adapted from Jim Highsmith (http://www.jimhighsmith.com/2010/11/14/beyond-scope-schedule-and-cost-theagile-triangle/).

 

Constraints

(Scope, Cost, Schedule)

Value

Quality

CMU/SEI-2011-TN-002 | 8

1.3 Background

1.3.1 Overall Approach

This report is based on both a literature review and interviews with many diverse programs and

practicing Agilists. We conducted a literature search to see what information was available that

could be adapted for a DoD environment. We also created a selective but not exhaustive list of

topics that we used when interviewing personnel who are Agile corporate advocates, practicing

Agile consultants, and personnel working on projects employing Agile methods. The projects

ranged from 7-10 people to programs with 100 developers. Some staffs were collocated and

others were distributed. Personnel interviewed were from both commercial and government

domains. We combined the results to provide some anonymity for our interviewees. Table 1

depicts the general characteristics of our interviewees where available. We also gained

information from several other sources that was not program specific but rather based on

extensive consulting or tool usage.

Table 1: Characterization of Interviewed Programs

Characteristic

Program #1

Program #2

Program #3

Program #4

Program #5

Program #6

Size of Program in

Dollars

$10-

15M/yr

$13M/yr $4.7M/yr Multiple

programs

Multiple

programs

Multiple

programs

Headcount of

Developers

Not

releasable

60 19 Varied Varied Varied

Headcount of

Program Office

Not

releasable

9 1-2 Varied Varied Varied

Type of Program

(IT, C2,

embedded

weapons, other)

C2, IT,

Modeling

and

Simulation

C2 C2 IT, C2 IT, C2 Commercial

Type of Contract CPFF,

T&M

T&M CPFF Varied,

preferred

T&M

Varied In house

# Months Using

Agile Methods

48-72

depending

on

program

96 42 Variable Variable Variable

CMU/SEI-2011-TN-002 | 9

Table 1: Characterization of Interviewed Programs (cont’d.)

Characteristic

Program #1

Program #2

Program #3

Program #4

Program #5

Program #6

# Iterations or

Deliveries Using

Agile methods

20-45 releases:

up to 330 builds

207 8 Variable Variable Variable

Agile Method in Use Scrum XP/Scrum Scrum Scrum Scrum Scrum

Approx # of Users of

Software/System

Produced Using Agile

Method

Not available Greater than

670 adopting

organizations

Not

available

Variable Variable Variable

For this report, we will use one of the common definitions of Agile, as cited in our first report on

Agile in the DoD:

Agile: An iterative and incremental (evolutionary) approach8

 to software development which

is performed in a highly collaborative manner by self-organizing teams within an effective

governance framework with “just enough” ceremony that produces high-quality software in

a cost-effective and timely manner which meets the changing needs of its stakeholders

[Ambler 2004].

From a programmatic perspective, Agile should live within the traditional foundational triangle of

scope, schedule, and cost. However, practitioners of Agile methods have taken a different

approach towards the traditional project triangle as shown in Figure 5.

In order to leverage these new models for program execution, the acquiring organization and the

developing organization must consider what changes need to be made to their current mental

models and their current practices. The rest of this TN addresses factors that are likely to need

change.

1.3.2 Audience for this Technical Note

The audiences for this report are

• senior DoD acquisition policy makers, to advise them on the practicality and policy pitfalls of

encouraging the application of Agile software development methods in their programs;

 

8

 Note that the life cycles illustrated in DoD 5000.02 are also incremental in nature. Agile methods are not the

exclusive expression of incremental methods. However, it is also true that a team claiming to use Agile methods

must be using, by necessity, an incremental and iterative life cycle.

CMU/SEI-2011-TN-002 | 10

• members of DoD program offices who may be challenged to undertake a software

development acquisition with a contractor who will be using Agile software development

methods; and

• software development contractors who are contemplating responding to a DoD Request for

Proposal (RFP) with a proposal based on using Agile software development methods.

1.3.3 Content of This Report

The reader may wonder how we selected the topics to address in this report. A subset of this

author team published a technical note in 2010 (CMU/SEI-2010-TN-002) in which we

acknowledged that the 2010 report only began to explore employing Agile within the DoD. We

mentioned several potential future topics. This TN addresses most of them including

• Management—discussion and exploration of governance changes, management style for the

Agile PM, and management structure for Agile projects (iteration, release, enterprise).

• Contracts and finance—discussion and exploration of costing and estimation for Agile

programs, types of contracts and which works best with Agile, and incentives.

• Benefits from Agile—discussion about how Agile is viewed within the Agile community

using risk and a variation of the cost, schedule, quality triangle.

• Organizational change management—discussion of what should be changed to work

effectively within an Agile environment, how to go about instituting those changes, etc.

• Culture—definition of the Agile culture, what it relies on, how it is different from existing

cultures, and how to bridge the gap.

There are a variety of other relevant topics that could and should be addressed. As we did our

research, we created a list of these topics. The potential list of other topics is addressed in Section

7, Summary and Conclusion.

1.3.4 Organization of This Report

The organization and potential audience for each topic in the report is provided below.

Executive Summary contains highlights of this report.

Section 1, Introduction describes what is Agile, why DoD is interested in Agile methods, and the

background for the report. All readers should review this section.

Section 2 discusses in more depth what it means to adopt Agile in a DoD context, especially as it

concerns the organization’s culture. The audience for this section includes policy makers,

program managers, and development organizations contemplating moving towards Agile

Section 3 discusses contracting for and managing Agile programs. Its primary audience is

acquisition program managers, with a secondary audience of policy makers and development

organizations, as well as contractor personnel in various roles.

Section 4 discusses the effects of Agile on technical milestone reviews, particularly System

Requirements Review (SRR), PDR, and CDR. Its primary audiences are acquisition program

managers and policy makers who are reviewing, approving, and executing acquisition strategies.

CMU/SEI-2011-TN-002 | 11

Section 5 addresses cost and effort estimation in Agile projects. Its primary audience is

acquisition program managers, with secondary audiences of development organizations and

independent cost evaluators.

Section 6 provides insight into the use of organizational change management approaches for Agile

methods adoption. Its audience includes policymakers, program managers, and development

organizations, anyone who influences the environment for Agile adoption or who is substantively

involved in the adoption.

Section 7 summarizes the TN and provides suggestions for future topics for detailed exploration.

Several appendices follow the main body of the report, providing more detail or pointers to

resources related to the topics of the individual sections.

Appendix A defines acronyms.

Appendix B is the glossary.

Appendix C provides culture details.

Appendix D is a COCOMO factors list.

Appendix E describes an estimating process for Agile based on GAO best practices for

estimation.

Appendix F provides details on the Satir Organizational Change Management Model.

Appendix G provides the Adler factors related to complexity and timing of change effort.

Appendix H provides notes from the field.

Appendix I provides selected Agile resources.

CMU/SEI-2011-TN-002 | 12

CMU/SEI-2011-TN-002 | 13

2 Implications of Agile Adoption for the DoD Acquisition

Context

In this section, we begin with a brief description of Agile themes. This is followed by a discussion

of various DoD processes and practices that are likely to need to change in order to successfully

adopt Agile. We discuss impacts to the following areas: acquisition life cycle, DoD culture, PMO

behavior, and planning practices. Sections that follow address particular subsets of these themes,

especially contracting, management, and technical milestones in the DoD acquisition life cycle.

2.1 Agile Themes

Learning and value-seeking are two themes that were visible in our interviews and continue to be

emphasized in the rhetoric on Agile methods. Together these themes support an Agile culture.

Though they are not the only themes that support an Agile culture, they are ones that differ in

their explicit use in DoD acquisition.

Through test-driven development cycles, nested iterations, continuing and frequent involvement

of the users of the system being produced, and retrospectives on how well practices have worked,

software developers involved in an Agile culture expend significant effort learning about the

problem space of the user, the solution space, and the processes that work best for them. One of

our interviewees, while reflecting on the importance of retrospectives, said, “I find this to be the

most beneficial part of the entire process. We do this in the fighter aircraft world. We call it

debriefing and we do it better than anyone. [It’s] a chance to learn and improve. So this in my

opinion is vital.”

Communication amplifies individual learning into team learning through information radiators.

Often, these take the form of big, visible charts that are posted in common areas of the workplace.

They should display progress, obstacles, and actions, and be easy to update. Thus, they “radiate”

information and support communication and rapid response to changing project conditions. In

geographically distributed teams, other mechanisms besides physical wall charts are used for the

same purpose, and some vendors of support tools for Agile methods incorporate tools specifically

meant for this purpose. One of our reviewers commented on their use of the wall-chart style of

information radiator: “[This was] one of the key practices used on [our program] increment 1,

which brought about significant change in a short period of time.”

Agile development is always value-seeking—concerned with delivering the best possible product

to the customer within the available timeframe. Developers emphasize high-quality working

software and take pride in providing value by having the flexibility to respond to changes in

business direction, requirements, and new needs. “Practices that help the customer to determine

what the better solution is and communicate that to the team correctly will deliver business value

as well” [Elssamadisy 2009].

The two themes of communication and value-seeking get expressed in different ways within

different Agile methodologies and for different product settings. The following discussion

addresses these and other themes relevant to DoD acquisition from different perspectives. We

address the acquisition context that Agile approaches would be expected to support, elements of

CMU/SEI-2011-TN-002 | 14

an Agile culture, differences between “doing” Agile versus “being” Agile, Agile success factors

and corresponding program management office (PMO) enablers, Agile methods and the DoD

culture, and the Agile philosophy related to planning.

2.2 Implications of Adopting Agile for the DoD Acquisition Life Cycle

The Defense Acquisition Guidebook states that “the Defense Acquisition System exists to manage

the Nation’s investments in technologies, programs, and product support necessary to achieve the

national Security Strategy and support the United States Armed Forces” [Defense Acquisition

Guidebook a 2011]. The DoD 5000 series (DoD Directive (DoDD) 5000.01 and DoD Instruction

(DoDI) 5000.02) provides the basic guidance to implement the acquisition process. The overall

life cycle framework is shown in Figure 6.

Figure 6: Acquisition Life-Cycle Framework [Defense Acquisition Guidebook 2011e]

In 2009 the Defense Science Board said, “The fundamental problem DoD faces is that the

deliberate process through which weapon systems and information technology are acquired does

not match the speed at which new IT capabilities are being introduced in today’s information age”

[Defense Science Board 2009].

The National Research Council has also studied DoD acquisition, stating, “DOD systems

acquisition policies, expertise, practice, and culture—including those applied to IT systems—

reflect the practices, policies, and cultural norms associated with large weapons systems

programs…. With respect to IT, however, there is a longstanding reluctance to deviate from

standard weapons system acquisition processes, and acquisition personnel are not trained or led to

differentiate the unique aspects of IT systems acquisition” [Committee 2010]. One of our

reviewers emphasized the burden this application of weapons system processes on IT has in their

IT-focused part of a jet aircraft program: “We are constantly being forced to use the exact same

processes as the jet itself and it continues to cost us non-value-added overhead.”

These studies and others prompted Congress to include Section 804 in the National Defense

Authorization Act for Fiscal Year 2010 (FY10 NDAA, PL 111-84). Pursuant to Section 804, OSD

published a report providing updates on DoD’s progress toward developing a new acquisition

process for information capabilities [OSD 2010]. This new process “will leverage ongoing

CMU/SEI-2011-TN-002 | 15

Department efforts to streamline Defense Business Systems (DBS) acquisition and incorporate

best practices garnered from engagement with industry and lessons learned from ongoing DoD

efforts. The new process is intended to take full advantage of the speed of IT innovation from

commercial industry to foster an environment for mission-focused and time-critical deliveries that

support the full spectrum of IT applications within the DoD” [OSD 2010]. A new business

capability life cycle is being created that will change the milestone and budgeting focus for IT

systems that are not embedded or driven by technology development. The guiding principles for

the new approach are

• delivery early and often
• incremental and iterative development and testing
• rationalized requirements
• flexible/tailored processes
• knowledgeable and experienced IT workforce

Agile methods seem to answer the need for many of the above principles. However, it should be

noted that to embark on this new acquisition life cycle, the DoD workforce will need to adapt its

culture to work within the new paradigm. It is also worth noting that some programs that are

outside the IT systems mandate also use Agile methods, often when using Agile software

development in the context of a larger traditional DoD weapons system.

2.3 Doing Agile vs. Being Agile

Agile is a mindset and a way of working that embodies the Agile Manifesto and Agile Principles.

The mindset is often the differentiator between successful and unsuccessful Agile projects [Sidky

2009]. However, many organizations start their journey by “doing Agile,” via adoption of the

methodologies and practices commonly called Agile.

There are a number of Agile processes—Scrum, XP (Extreme Programming), RUP (Rational

Unified Process), DSDM (Dynamic Systems Development Method), ASD (Adaptive Software

Development), and others. Each provides potential benefits through its own practices’ reflection

of Agile principles and values.

A development team can start “doing Agile” by picking an Agile process and following it step by

step without fully embodying the Agile culture described briefly in Table 2. This often provides

incremental benefits through smaller and more focused delivery of operational software.

However, adopting Agile for software development is more than learning a new process. “Being

Agile” is more about creating and sustaining a culture of agility. This culture is founded upon key

principles expressed in the Agile Manifesto. Rather than simply advocating a new software

delivery process, these Agile tenets seek to change what the team values, measures, and delivers,

(i.e., placing value on collaboration and personal interactions, working software, and adjustment

to change).

Table 2 presents the principles (in bold) that tie to the Agile Manifesto, as well as Agile behaviors

that support these principles, and possible government PMO actions and enablers that can support

the use of Agile methods, where appropriate. This translation is intended to assist acquisition

program managers to gain a better understanding of the Agile development teams they may be

working with. Items in italics are direct quotes from the Agile Manifesto. Other behaviors listed

CMU/SEI-2011-TN-002 | 16

are ones that we have observed in our interviews that are consistent with the manifesto. The main

cultural themes reflected in the table are leadership values, team values, values around incentives

and reward systems, and values around development practices. Although these values may also be

present in non-Agile development contexts (in fact, many of them are derived from pre-Agile

experience of the Manifesto authors), they are behaviors that are iconic of Agile environments.

Table 2: Agile Manifesto Principles and Possible Program Office Enablers for Them

Agile Manifesto and Principles Common Behavioral Expressions of

the Agile Manifesto and Principles

PMO Actions & Enablers

Build projects around motivated

individuals. Give them the environment

and support they need, and trust them to

get the job done.

Team performance is emphasized more

heavily than individual performance.

Candor and truth are rewarded, not

punished.

Distinction is clear between individuals’

status on the development team

(respect) and formal HR rewards.

The team visibly rewards its heroes.

Mentoring is rewarded.

At least some of the reward system is

team-based.

Provide rewards other than monetary

(choice assignments, mentoring,

training, etc)

Downplay or equalize merit increases

Associate career accomplishments

and milestones with promotions.

Let the development team naturally

recognize its heroes.

Include an appreciation step in

iteration retrospectives.

Our highest priority is to satisfy the

customer through early and continuous

delivery of valuable software.

– and –

Working software is the primary measure

of progress.

Early functioning software release is

rewarded (vs. documents are “finished”).

Focusing early on the parts of the system

that have the most direct business or

end-user value

Use of user stories to communicate

between developers and other

stakeholders

Provide developers with access to real

end users or to end-user surrogates

with depth in operational use of the

type of system being built.

Architect system in a way that permits

early delivery of working (although

often prototype) software.

Minimize time for delivery increments

and base requirements choices

around ability to get early feedback

from operational use.

Business people and developers must

work together daily throughout the project.

Vision is shared by sponsor and teams.

Local sponsors respect team autonomy.

Local sponsors (usually acquisition

customer) visibly value team input in

management decisions.

Management willingness to be creative

within the business constraints of the

environment

Support working well across boundaries

Managers’ first duty is to remove

impediments to developer productivity.

Co-locate customer and end user(s)

with developers

Stakeholders, including the customer,

participate actively in standup

meetings.

Establish award fee, CDRLs, and

other contractual criteria that

encourage small deliveries of working

software rather than a “big bang”

delivery.

Work with relevant certification

authorities to reduce lag time to enduser

delivery while maintaining

appropriate security.

 

CMU/SEI-2011-TN-002 | 17

Table 2: Agile Manifesto Principles and Possible Program Office Enablers for Them (cont’d.)

Agile Manifesto and Principles Common Behavioral Expressions of

the Agile Manifesto and Principles

PMO Actions & Enablers

Simplicity—the art of maximizing the

amount of work not done—is essential.

Keep everything—software,

documentation, overhead—as simple as

possible.

Bloated software and gold-plating are

discouraged

Minimizing waste is important.

Reduce distractions for developers

and testers; consider physical facility

adjustments like a team room, if

feasible.

Keep team on task; minimize team

members being shared among

multiple projects.

Model appropriate product owner

behavior in daily standup meetings.

Deliver working software frequently, from a

couple of weeks to a couple of months,

with a preference to the shorter timescale.

Fail fast, learn fast is encouraged

Time-boxed iterations (also called

“sprints” in some methods)

Scope management within release

cycle(s)

Reduce risk via early working software

that is releasable to users

Consider use of time and material

contracts where feasible—software

development as a service

The most efficient and effective method of

conveying information to and within a

development team is face-to-face

conversation.

Co-located teams whenever possible

Strong telepresence technology support

for geographically distributed teams

Developer isolation is frowned upon.

Strong team-based values

Information sharing vs. “knowledge is

power”

Candor, communications,

transparency

Minimize barriers to use of

collaboration technology when colocation

is infeasible.

Continuous attention to technical

excellence and good design enhances

agility.

Peer reviews are embraced by

development teams.

Learning is valued.

Shared team understanding of what

“done” means

Encourage pair or small-team

programming.

Develop Agile coaches for both

acquisition side and development side.

Define acceptance test early to close

in on definition of “done.”

At regular intervals, the team reflects on

how to become more effective, then tunes

and adjusts its behavior accordingly.

Self-reflection via things like

retrospectives is encouraged.

Metrics used for course correction, not

punishment of individuals

Formalize team reflection, via

retrospectives or other mechanisms,

as part of release cycles.

Keep metrics simple enough to be

gathered and still be useful.

Focus on improving development

team velocity.

Agile processes promote sustainable

development.

– and –

The sponsors, developers, and users

should be able to maintain a constant pace

indefinitely.

Sustainable pace is rewarded.

Personal heroics are not encouraged.

Little overtime is seen.

Uncompensated overtime is rare.

Focus on meeting shorter-duration

delivery dates by modulating scope.

CMU/SEI-2011-TN-002 | 18

Table 2: Agile Manifesto Principles and Possible Program Office Enablers for Them (cont’d.)

Agile Manifesto and Principles Common Behavioral Expressions of

the Agile Manifesto and Principles

PMO Actions & Enablers

Welcome changing requirements, even

late in development. Agile processes

harness change for the customer’s

competitive advantage.

Small amount of change occurring within

an iteration, but a fair amount of

reprioritization of requirements inbetween

iterations

Product owner minimizes churn with the

team inside an iteration, but brings up

changes in the environment and enduser

needs in-between iterations

Leave slack in each iteration for

important, urgent defect removal or

requirements change—how much

depends on team velocity and

character of software being

developed.

2.4 Implications of Adopting Agile on DoD Culture

What can be observed in any organization? Every organization has common things that are visible

and reflect its basic assumptions, shared values, espoused values, and artifacts as shown in Figure

7. Together these form a view of the organization’s culture [Schein 2009]. Artifacts are the most

visible elements of a culture. They include the products of the groups and everything an

organization experiences, from the facilities and properties of the physical environment to the

group’s language, reports and documents, posters and presentation materials, myths, stories, and

rituals.

“Information radiators” are a good example of an artifact of Agile culture. The big, visible

version of these charts can take many forms, for example: a storyboard of user stories that

highlights the iteration’s status, burndown charts that show the number of requirements and

stories that are completed, status of the continuous integration builds, roadblock charts that show

obstacles and who has responsibility for working these, and so on. Distributed teams also need

information radiators. One of our reviewers commented, “A large flat-panel screen in each

lab/team room is a wonderful information radiator for distributed teams.” In an Agile culture, it is

critical that the artifacts are dynamic, actionable expressions of the project at work, not static

documents (e.g., project mission statements that are not expected to change frequently). Cultural

artifacts are easy to see but can be hard to interpret, and they alone do not represent the essence of

a culture.

Figure 7: Key Elements of Cultu

The Agile Manifesto is a good ex

originators of the term “Agile me

aspire. Espoused values (things w

of a workplace. Espoused values

group accepts the solution’s value

success eventually become basic

substantiated research but are unq

may start as an espoused value in

there are sufficient tooling mecha

shared value, a common practice

continuous integration become au

discussable, it would become a ba

The relationship between values a

reasonably congruent with the un

can be helpful in bringing the gro

[Schein 2009]. In situations wher

identity will be very strong. In tho

explanation, rationalization, and a

weaker.

Common manifestations of Agile

in column two of Table 2. In som

strong shared values related to Ag

successfully used for more than a

Agile adoption was relatively rece

strong Agile identity, prospective

team members, not just the team l

 

9

 Adapted from Edgar Schein’s Orga

CMU/SEI-2011-T

ure9

xample of the espoused values of the Agile Alliance, the

thods,” and it generally reflects the values to which Agil

we say we do), norms, and rules make up the everyday op

become shared when they have been proven as solutions

1. Solutions (actions and values) that are repeatedly used

assumptions—general inferences that are not grounded i

questionable [Schein 2009]. For example, continuous inte

n an Agile organization (this is a rule we will follow), but

anisms to support continuous integration, it will not beco

that most of the organization would not readily abandon

utomatically accepted within the group without its use be

asic assumption for that particular culture.

and assumptions is important. “If the espoused values are

nderlying assumptions, then the articulation of those valu

oup together, serving as a source of identity and core miss

e there is tight coupling or congruency, the Agile cultura

ose situations where there is less congruence, evidenced

aspiration around the values, the Agile cultural identity w

e principles, through shared values and behaviors, are hig

me of the organizations we interviewed, we saw evidence

gile principles, particularly in programs where Agile had

a couple of years. We saw other cases, particularly where

ent, of a weaker Agile cultural identity. In one program,

e employees are likely to be interviewed by all their poten

lead. The team makes a judgment as to the fit of the emp

 

anizational Culture and Leadership, 1992.

TN-002 | 19

le teams

perations

s and the

d with

in

egration

t until

me a

1. Should

eing

e

es …

sion”

al

by more

will be

ghlighted

of

d been

e the

with a

ntial

ployee,

CMU/SEI-2011-TN-002 | 20

not only in terms of software development skills, but also in terms of their perceived ability and

willingness to adopt pair programming and test-driven development practices; both of these are

anchors of Agile practices in that organization. In a more traditional project, full team

involvement in interviewing and deciding on new members is not as common an occurrence. One

reviewer, who shares the practice of team interviewing with this program, commented, “In almost

all cases that I have seen, the team is better off without adding a team member versus adding one

who does not jell with the rest of the team or work well in a team environment.”

An expected, but still striking difference we saw in Agile programs versus more traditional

software programs was the attitude toward requirements. In the more traditional programs that

some of our interviewees had worked on, a tremendous amount of effort, energy, and attention

was paid to refining requirements statements to a low level of detail and obtaining multiple levels

of approval of them before doing any prototyping or visible design activities. The confidence of

the development team in how accurate the requirements were in terms of the user’s needs was

low. However, they could not substantively move forward with the design until the complete

systems requirements had been approved. A reviewer who had a similar experience said, “To

date, I have not seen where the rigor applied to our requirements has brought any value to our

product.” The attitude toward requirements in the programs we interviewed using Agile was much

more focused on a definition of only enough capability to bring acknowledged value to an end

user, with much less focus on ultimate completeness of the requirements set. In the program using

Agile, the team was confident that with the user involvement that they knew they could count on,

they would discover additional requirements as the project evolved and that all the requirements

they worked on would provide definable value to the customer.

The shared value of prioritizing end-user involvement to build confidence in requirements early

allows both the acquirer and developer to permit appropriate ambiguity early in the project. This

is contrary to what is more typical in a traditional acquirer/development team, which strives for

completeness of a requirements specification prior to significant design work. Although this is a

false completeness (almost everyone we spoke with acknowledged that the complexity of today’s

systems makes it impossible to completely know a system’s requirements prior to design), the

shared values of the acquirer/developer team are focused on the completion aspect of the

requirements rather than allowing evolutionary learning about them.

Here is what one colonel tells his subordinate PMs about requirements and release planning:

Planning Release 1 … [should contain the] smallest fieldable amount with tangible ROI

that the customer will agree to, and

• should demonstrate that the system will work end-to-end … or a logical chunk of it

that can be built upon.

• Pick the easiest requirements that have the best quality data.
• Fight for this. The customer wants it all in the first release … every time.
• Give success earlier, validate assumptions, buy time to further analyze the harder

things.

• If budget cuts take everything except the release 1 money, you are still a success.

Planning Release 2 thru ‘n’ … use a model.

CMU/SEI-2011-TN-002 | 21

• You must know: the interfaces required, the quality of the data required, the

hardware required, and the software required … with costs and estimates of

complexity for each.

• Create a model based on the variables above … use it for estimates going forward;

continuously refine.

• If you have to go around the world to field each increment at each unit, it means

many trips;[that must be] synced with [the] deployment schedule …[which will cost

lots of] $$$ … think this thru carefully.

Culture is ingrained in the organization, and is intertwined with everything that the organization is

and does, including these dimensions:

• organizational structure
• leadership style
• rewards system
• communication and decision-making styles
• staffing model

Table 3 compares the above cultural dimensions as reflected in typical Agile and traditional DoD

environments.10 This is not a comprehensive characterization, but is intended for purposes of

comparison. It also provides an informal way for a DoD organization to understand how closely

its current culture reflects Agile cultural elements. Although this table may seem like it advocates

Agile elements as superior to traditional DoD elements, for adopters of Agile, the point and the

challenge is that the Agile adoption is likely to occur within the traditional DoD culture and steps

will need to be taken to mitigate risks related to cultural conflict that is likely to arise.

An Agile culture runs counter to the traditional DoD acquisition culture in many ways, from

oversight and team structure to end-user interaction throughout development. In our interviews

with successful DoD Agile projects, we have consistently confirmed that adopting Agile methods

requires a mindset change for government program management offices and other acquisition

entities the projects interact with, such as the Office of the Secretary of Defense (OSD). The first

step in effecting a culture change of this type is to understand the differences in assumptions,

shared values, and artifacts that make up the cultures of Agile projects and those of more

traditional projects as executed in the DoD [Schein 2009].

 

10 These are generalizations and by nature will not be present as stated in every Agile or DoD traditional program

situation. Some DoD program offices, for example, have created excellent collaboration structures through the

judicious use of integrated product teams.