Adopting Extreme Programming - the Benefits and Obstacles
Submitted to the Software Engineering Department of De Paul University
Review Committee Chairman: Dr. Lawrence Dribin
Committee Members: Dr. Xiaoping Jia
Mr. Hank Streeter
Submitted By
Patricia Cleary
School of Computer Science, Telecommunications, and Information Systems
De Paul University
243 S. Wabash
Chicago, IL 60604
December 5, 2002
81900277
De Paul University
Thanks to Committee Members
Especially Dr. Lawrence Dribin
His assistance, patience and time was greatly appreciated
Revision History
Date
Version
Modifications
11/25/2002
1.0
Initial Version
12/02/2002
1.1
Renamed Analysis Section to
Research Study; Revised
Abstract
12/09/2002
1.2
Minor grammar corrections;
reformat with double spacing
Version 1.2
2
12/09/2002
81900277
De Paul University
Abstract
The Waterfall methodology of software development is widely used by many software
development groups. However, this methodology is often burdensome and document
intensive. It focuses on the process and not the people who develop the software. It is
also believed that it is difficult to handle changing customer requirements. The customer
is often unsure of what he or she wants or else the needs change once the software has
been developed. These may be some of the reasons why software is often late and over
budget.
In the 1990’s, the agile software development processes began to emerge to improve
some of the deficiencies in the Waterfall method. Extreme Programming is one of the
agile processes at the forefront of the agile processes. It is a set of twelve practices.
Extreme Programming should be viewed as a set of guidelines for a company to interpret
and adapt to fit the company’s culture so that the process can assist the developers in the
software development process.
It is believed by many individuals who have implemented Extreme Programming that it is
a better approach than the Waterfall approach and feel that it may resolve many of the
Waterfall methodology issues.
But, what makes Extreme Programming better? It is lightweight, people focused,
adaptive, supports less documentation, and has the ability to handle changing
requirements better. One of the goals of Extreme Programming is to increase
Version 1.2
3
12/09/2002
81900277
De Paul University
productivity and quality. Proponents of Extreme Programming believe that it achieves
its goals by helping the customer get involved in controlling project direction.
Proponents also feel that Extreme Programming improves team morale and customer
satisfaction. They feel that it also improves knowledge transfer among the team
members. The above positives resolve many of the drawbacks of the Waterfall model.
Extreme Programming does have its obstacles also. Some obstacles that need to be
addressed include the need for management support and communication, especially
between the customer and the development team, and within the development team itself.
The hypothesis for this thesis is that Extreme Programming improves the ability of a
project team to develop software. A secondary hypothesis is that Extreme Programming
is easy to implement on a project team. This thesis surveys a number of project teams to
analyze whether Extreme Programming practices helped project teams develop better
software systems than the other traditional methodologies such as Waterfall. It also
evaluated the difficulty in implementing Extreme Programming within a project team
A survey of project teams that had tried to implement Extreme Programming was
conducted. Seven projects were surveyed on background, implementation approach,
benefits and costs. Project metrics were also analyzed where available. These surveys
were then analyzed to determine if there was any validity to the primary and secondary
hypothesis.
Version 1.2
4
12/09/2002
81900277
De Paul University
Based on the survey results, there was a fair amount of subjective positive result.
However, there was little quantitative proof that Extreme programming is easy to
implement and or that it offers considerable benefits to a project team. Due to the
relative newness of Extreme Programming, more quantitative analysis needs to be done
by companies to verify the validity of the claims.
Version 1.2
5
12/09/2002
81900277
De Paul University
INTRODUCTION .......................................................................................................................................10
BACKGROUND ..........................................................................................................................................12
THE WATERFALL MODEL...........................................................................................................................13
HISTORY OF THE AGILE PROCESSES ...........................................................................................................17
EXTREME PROGRAMMING ..........................................................................................................................20
Activities of Extreme Programming ......................................................................................................22
Values of Extreme Programming ..........................................................................................................24
Principles of Extreme Programming .....................................................................................................27
Practices of Extreme Programming ......................................................................................................30
Practices, Principles, and Values – Tying Them Together ....................................................................31
Extreme Programming – Is It the Answer? ...........................................................................................34
RESEARCH STUDY ..................................................................................................................................35
RESULTS .....................................................................................................................................................40
OVERALL RESULTS ....................................................................................................................................40
Number Of Surveys ................................................................................................................................40
Types of Companies...............................................................................................................................40
Matrix of Practices Implemented / Not Implemented ............................................................................41
PROJECT A .................................................................................................................................................42
Background / Demographics .................................................................................................................42
Implementation of Extreme Programming ............................................................................................43
Measurements Performed ......................................................................................................................47
Benefits ..................................................................................................................................................47
Obstacles ...............................................................................................................................................47
Improvements On Next Implementation ................................................................................................48
Environments to Not Implement In ........................................................................................................48
Version 1.2
6
12/09/2002
81900277
De Paul University
PROJECT B..................................................................................................................................................48
Background / Demographics .................................................................................................................48
Implementation of Extreme Programming ............................................................................................50
Measurements Performed ......................................................................................................................52
Benefits ..................................................................................................................................................52
Obstacles ...............................................................................................................................................52
Improvements On Next Implementation ................................................................................................53
Environments to Not Implement In ........................................................................................................54
PROJECT C..................................................................................................................................................54
Background / Demographics .................................................................................................................54
Implementation of Extreme Programming ............................................................................................55
Measurements Performed ......................................................................................................................56
Benefits ..................................................................................................................................................56
Obstacles ...............................................................................................................................................57
Improvements On Next Implementation ................................................................................................57
Environments to Not Implement In ........................................................................................................57
PROJECT D .................................................................................................................................................58
Background / Demographics .................................................................................................................58
Implementation of Extreme Programming ............................................................................................59
Measurements Performed ......................................................................................................................61
Benefits ..................................................................................................................................................62
Obstacles ...............................................................................................................................................62
Improvements On Next Implementation ................................................................................................63
Environments to Not Implement In ........................................................................................................63
PROJECT E ..................................................................................................................................................64
Background / Demographics .................................................................................................................64
Implementation of Extreme Programming ............................................................................................65
Measurements Performed ......................................................................................................................66
Version 1.2
7
12/09/2002
81900277
De Paul University
Benefits ..................................................................................................................................................66
Obstacles ...............................................................................................................................................66
Improvements On Next Implementation ................................................................................................67
Environments to Not Implement In ........................................................................................................67
PROJECT F ..................................................................................................................................................67
Background / Demographics .................................................................................................................67
Implementation of Extreme Programming ............................................................................................68
Measurements Performed ......................................................................................................................70
Benefits ..................................................................................................................................................71
Obstacles ...............................................................................................................................................72
Improvements On Next Implementation ................................................................................................72
Environments to Not Implement In ........................................................................................................73
PROJECT G .................................................................................................................................................73
Background / Demographics .................................................................................................................73
Implementation of Extreme Programming ............................................................................................75
Measurements Performed ......................................................................................................................78
Benefits ..................................................................................................................................................78
Obstacles ...............................................................................................................................................79
Improvements On Next Implementation ................................................................................................80
Environments to Not Implement In ........................................................................................................80
CONCLUSION ............................................................................................................................................81
SUMMARY OF FINDINGS .............................................................................................................................81
Projects Background / Demographics ...................................................................................................81
Implementation of Extreme Programming ............................................................................................83
Measurements Performed ......................................................................................................................86
Benefits ..................................................................................................................................................87
Obstacles ...............................................................................................................................................88
Improvements On Next Implementation ................................................................................................89
Version 1.2
8
12/09/2002
81900277
De Paul University
Environments to Not Implement In ........................................................................................................90
IS EXTREME PROGRAMMING BETTER? .......................................................................................................91
Knowledge Transfer ..............................................................................................................................91
Customer Input ......................................................................................................................................92
Increased Productivity...........................................................................................................................94
Increased Quality ..................................................................................................................................94
Improved Communication .....................................................................................................................95
Improved Team Morale .........................................................................................................................96
Summing It Up .......................................................................................................................................96
IS EXTREME PROGRAMMING EASY TO IMPLEMENT? ..................................................................................97
People Factor ........................................................................................................................................98
Testing ...................................................................................................................................................99
Refactoring ..........................................................................................................................................100
On Site Customer.................................................................................................................................101
Simple Design ......................................................................................................................................101
Pair Programming ..............................................................................................................................102
Summing It Up .....................................................................................................................................103
FUTURE RESEARCH .............................................................................................................................105
REFERENCES ..........................................................................................................................................106
WEB REFERENCES ................................................................................................................................107
Version 1.2
9
12/09/2002
81900277
De Paul University
Introduction
Software engineers have long been plagued with the problem of how to deliver
quality software on time, on budget, and fulfilling the customer’s requirements. One
issue that prevents this goal from being attained is that the requirements change. The
customer is unsure of exactly what they want or the business need changes. They
describe what they believe the system should do. Once the system is developed, they
decide that it is not what they need and change the requirements.
The new answer for software development may come in Extreme Programming. It is
lightweight and better able to handle changing requirements. However, is it really
better than the traditional methodologies?
Does Extreme Programming make
companies more productive? What obstacles does a company face when they try to
implement Extreme Programming? What benefits does a company reap when they
use it? Are there companies that due to certain characteristics or cultural issues,
should not implement Extreme Programming, but instead stay with the other
traditional methodologies?
The hypothesis for this thesis is that the practices of Extreme Programming help to
develop better software systems than the other traditional methodologies such as
Waterfall. Also, this thesis will have implementers try to assess how difficult it is to
implement Extreme Programming.
Version 1.2
10
12/09/2002
81900277
De Paul University
The thesis will use a survey to examine companies that have tried to implement the
Extreme Programming agile methodology. It will analyze the surveys to determine
the benefits, issues, and problems companies face when implementing Extreme
Programming.
The surveys will also be used to determine whether or not the
companies were successful in their implementation of Extreme Programming.
Version 1.2
11
12/09/2002
81900277
De Paul University
Background
Software engineers have been on a search for a silver bullet. The silver bullet would
be the answer to all software development woes. They need a way to create better
software that is of high quality and that fits the customer’s needs, is on time, and
within budget. The software development community decided to try to find some
answers to their dilemma. The first approach used for developing software was one
of “code and fix”.
This approach was not very successful and in many cases
produced software that was of poor quality. Hence, the entrance of formal processes
or methodologies such as waterfall, spiral, and iterative development methodologies.
These processes have been around for several years and have been used by many
software engineers on projects. They often produced the desired results.
As years have passed, the software development environment has changed. Business
and economic conditions are putting pressure on software engineers to deliver
software to help companies stay competitive and survive in the recent economic
conditions.
These companies need the software immediately. They cannot afford to
wait years for software development. The company’s survival is at stake. Software
engineers needed a quicker way to develop software. However, they did not want to
abandon the methodologies that had been in place for years. They also needed
processes that could better handle the changing requirements that seem to creep up in
so many projects.
Version 1.2
12
12/09/2002
81900277
De Paul University
The new agile methodologies may hold the key that developers are looking for.
However, the Waterfall model has been around for years and has been successful for
many companies. One company that the author was familiar with saw increased
customer satisfaction and a reduced number of defects once they implemented the
Waterfall model. Why the need for change? A close examination will show that the
Waterfall Model is a thorough process, but it also has its flaws.
The Waterfall Model
Many companies use a waterfall-based model to develop software.
One main
problem with this process model is that defects are often found late in the process.
When defects are found late, it is often costly to fix them. Also, changes to software
requirements are not brought to light until the software is almost complete. It is then
often costly to go back to implement the changes. The following is a brief description
of the Waterfall Model.
The waterfall model generally consists of 5 phases. They include:
1. Requirements definition
2. System and software design
3. Implementation and unit testing
4. Integration and system testing
5. Operation and maintenance
Version 1.2
13
12/09/2002
81900277
De Paul University
The first phase is where the customer would define what the system is needed to do.
The requirements may improve system functionality, increase the business’ bottom
line, or make individuals more productive. A business requirement may be written.
The business requirement would contain the user’s requirements.
The second step is where the solution is designed. The business requirements may be
converted into functional and / or design specifications. The functional specification
is a high level design of the software requirements. The design specification is a
more detailed, low level, technical specification. There should be a one to one
correspondence between the business requirements and the specifications.
The third phase is when the code is written. Once complete, the developer will then
unit test his or her work. When satisfied, the task is turned over to the quality
analysis team for more testing. Some companies also do code walk throughs to try to
ensure that the code is correct.
The fourth phase is where the new code is integrated into a test system. The quality
assurance team will exercise the test cases they have written.
Once the testers are
satisfied, the new code is integrated into the customer’s live system.
Version 1.2
14
12/09/2002
81900277
De Paul University
The last phase is operation and maintenance. It is in this phase that the customer
starts using the new code. In some cases, training and documentation is provided for
the users. Any defects are submitted to the developers to be corrected.
Requirements
definition
System and
software design
Implementation
and unit testing
Integr ation and
system testing
Operation and
maintenance
Figure 1. Diagram of the Waterfall Model [4]
The above process is long and time consuming.
“Quick fixes” do not happen.
Changes need to go through the whole cycle, even if it is just an additional field to a
screen. If done incorrectly, the impact that one small change can have on a large
complex system can be costly.
The above process was believed to have worked. Many managers implemented it.
They believed that the process helped to produce quality results. It also helped
increase customer confidence. Even with this in mind, management decided that the
Version 1.2
15
12/09/2002
81900277
De Paul University
process needed to be changed because it was too slow. The Waterfall model is often
heavy on documentation. It also has several areas where bottlenecks could occur
when a project needs to develop quickly. However, there are also other issues with
using the Waterfall model. They include:

“Requirements must be defined up front which causes problems because users
often do not know what they want and most analysis and design techniques do not
provide representation of the solution for the user.

“The customer must wait a long time for the first deliverable

“The ‘Large Specifications’ produced are hard to use and hard to validate

“It is difficult to handle changes in requirements

“It has a lot of overhead. One example is that documentation is often redundant
and, in some cases, contradictory. Contradictions cause developers to have to
research the issues to find the correct requirement.

“The complete problem must be defined at the start

“It is rigid/brittle for large projects. “ [4]
Managers needed to slim down the process. They did not want to go back to the
“code and fix” approach. Managers started to look at the new agile process models.
They believed that the agile processes would be the answer for creating a software
package that needed to be done in phases quickly and had to handle the myriad of
changing requirements.
Version 1.2
16
12/09/2002
81900277
De Paul University
History of the Agile Processes
The agile processes began emerging in the 1990’s.
There are several software
development processes that have been proposed in the last several years that can be
characterized as being lightweight or agile. These include Extreme Programming (XP),
Coad’s Feature Driven Development, Highsmith’s Adaptive Software Development,
Cockburn’s Crystal Family, and Scrum, to name a few. They are focused on being
adaptive and people focused.
“The most immediate difference is that they are less document-oriented….In
many ways they are rather code-oriented: following a route that says that the key
part of documentation is source code.”[8]
“Agile methods are adaptive rather than predictive.” [8]
Also, “agile methods are people-oriented rather than process-oriented.” [8]
In February 2000, a group of Agile Developers gathered at a lodge to discuss the agile
processes. Among these people were Kent Beck, Mike Beedle, Arie van Bennekum,
Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith,
Andrew Hunt, Ron Jeffries, John Kern, Robert C. Martin, and several others. They
formed the Agile Software Development Alliance. This group developed the “Manifesto
for Agile Software Development”.
Version 1.2
17
12/09/2002
81900277
De Paul University
The principles contained in the manifesto include:

“Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.

“Welcome changing requirements, even late in development. Agile processes
harness change for the customer’s competitive advantage.

“Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.

“Business people and developers work together daily throughout the project.

“Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.

“The most efficient and effective method of conveying information to and within
a development team is face-to-face conversation.

“Working software is the primary measure of progress.

“Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.

“Continuous attention to technical excellence and good design enhances agility.

“Simplicity – the art of maximizing the amount of work not done – is essential.

“The best architectures, requirements, and designs emerge from self-organizing
teams.

“At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly. “ [5]
Version 1.2
18
12/09/2002
81900277
De Paul University
The group of seventeen also developed four values that are important to remember when
developing software.

“Individuals and interactions over processes and tools

“Working software over comprehensive documentation

“Customer collaboration over contract negotiation.

“Responding to change over following a plan.” [5]
It is important to remember that “the agile methodology is not anti-methodology.” [5]
The group of agile method developers “embrace modeling, but not merely to file some
diagram in a dusty corporate repository; embrace documentation, but not to waste reams
of paper in never maintained and rarely-used tomes; we plan, but recognize the limits of
planning in a turbulent environment.” [5] The agile processes are guidelines that are
adaptable.
The light weight processes tend to be more adaptable. Software development is not a
predictable activity. Changes are always occurring. Processes need to be able to respond
to these changes. Also, a major element of developing software is people. When
different groups of people come together, there is always a unique chemistry that sets the
group apart. Teams are dynamic and changing. They need to work together and have a
process that works with them and not against them.
Also, with the new agile
methodologies, “developers need broader skills.” [1]. Implementing an agile process in
Version 1.2
19
12/09/2002
81900277
De Paul University
any environment “require changes in personnel, process and culture.” [1] However, in the
long run, it may be beneficial since the agile processes are more flexible and can handle
the changing requirements that are always present in every project.
The strong point of the new agile processes is that they adapt. One process does not fit
all projects. There are always special circumstances where it needs to be modified. A
maintenance environment would need a different process than a research and
development environment. “When it comes to methodologies, each project is different
and each project team is different – there’s no one-size-fits-all solution.”[5]
The goal needs to be to develop a process that is adaptable and flexible enough to assist
in creating software that fits the customer’s needs, is on time, and within budget. The
future of this may very well be in the agile software processes.
Extreme Programming
Extreme Programming is at the forefront of the agile processes. It should be viewed as a
set of guidelines that can be interpreted and adapted. This allows the process to fit in
with a company’s culture. After all, objectives and cultures differ from company to
company. It also should help developers in the software development process. Extreme
Programming is not a part of any software package. This makes it very attractive for
companies that are on tight budgets and cannot afford the cash outlay for software and
licenses. Also, “XP is a lightweight, efficient, low-risk, flexible, predictable, scientific,
and fun way to develop software.” [3] It has its own features that set it apart from other
Version 1.2
20
12/09/2002
81900277
De Paul University
methodologies. “It is distinguished from other methodologies by: It’s early, concrete,
and continuing feedback from short cycles.” [3] Also, it is important to note that “XP is a
light-weight methodology for … developing software in the face of vague or rapidly
changing requirements.” [3]
As will be seen, Extreme Programming is based on activities, values, principles, and
practices. These four premises are the cornerstone to the Extreme Programming
philosophy.
Version 1.2
21
12/09/2002
81900277
De Paul University
Activities of Extreme Programming
Activities
Values
Principles
Practices

Listening

Communication

Rapid Feedback

Planning Game

Designing

Simplicity

Assume Simplicity

Small Releases

Coding

Feedback
Incremental

Metaphor

Testing

Courage
Change

Simple Design

Embracing Change

Testing

Quality Work

Refactoring

Teach Learning

Pair Programming

Small Initial

Collective Ownership
Investment

Continuous Integration

Play To Win

40-Hour Workweek or

Concrete

Sustainable Equivalent
Experiments

On-Site Customer
Open, Honest

Coding Standards
Communication

Work With People’s
Instincts

Local Adaptation

Travel Light

Honest
Measurement
There are four values for Extreme Programming. These four activities are relavant to any
software development project. They include:

Listening

Designing

Coding
Version 1.2
22
12/09/2002
81900277

De Paul University
Testing
The above list is basic and easy to understand. The activities help a software developer
to produce a quality product. In order to reach this goal, the developer needs to listen.
He or she needs to then design, code, and test the system. These activities should always
be a part of any development process.
Version 1.2
23
12/09/2002
81900277
De Paul University
Values of Extreme Programming
Activities
Values
Principles
Practices

Listening

Communication

Rapid Feedback

Planning Game

Designing

Simplicity

Assume Simplicity

Small Releases

Coding

Feedback
Incremental

Metaphor

Testing

Courage
Change

Simple Design

Embracing Change

Testing

Quality Work

Refactoring

Teach Learning

Pair Programming

Small Initial

Collective Ownership
Investment

Continuous Integration

Play To Win

40-Hour Workweek or

Concrete

Sustainable Equivalent
Experiments

On-Site Customer
Open, Honest

Coding Standards
Communication

Work With People’s
Instincts

Local Adaptation

Travel Light

Honest
Measurement
There are four values for Extreme Programming. They include:

Communication

Simplicity

Feedback
Version 1.2
24
12/09/2002
81900277

De Paul University
Courage
Communication is important to any project’s survival. Without communication among
team members, management, and customers, the project will not succeed. People fail to
communicate for several reasons. One is that if a mistake is made, there is a fear of
punishment. Some individuals have information overload and ignore valuable
information that should be shared with others. Another situation is when the severity of a
change is miscalculated. If it is believed to have little impact, the individual may push
the information to the side and forget to tell others until it is too late. [3]
Extreme programming encourages communication throughout the project. The main
premise behind the success of the project is communication. Developers develop
together. In this way, they communicate. The customer is part of the project. They help
to make decisions and create story cards that describe what the system should do. Also,
the actual code and tests are a form of communication.
Simplicity is another value. It is better to have a simpler system. This makes it easier to
express what the system can do. There is more room for error when the system is
complicated and complex. Beck notes that “it is better to do a simple thing today and pay
a little more tomorrow to change if it needs it, than do a more complicated thing today
that may never be used anyway.” [3]
Version 1.2
25
12/09/2002
81900277
De Paul University
Feedback helps the development team and customer know how the project is doing.
Extreme programming employs several forms of feedback. These include:

Results from unit testing the software and regression testing previous passed
test cases on newly implemented code.

When new requirements are requested, estimates for development time are
created.

The team also tracks project process by evaluating how many tasks are
completed versus uncompleted tasks. This helps determine if the project is on
time for completion.

Since Extreme Programming tries to put a system into production as soon as
possible, programmers are able to receive feedback from the users to see how
valuable the system is and how well the requirements fit the customers’ needs.
At the same time, they are able to continue development on other tasks. [3]
Courage is the last value for Extreme Programming. If there is a fundamental flaw, the
team needs the courage to stop and fix the flaw. Even if this means that it sets the project
back. Coding around a flaw only breeds trouble. Also, the team needs to not be afraid to
start over. Some of the most promising designs can end up being extremely complicated
or complete failures. Remember, that just because it looks good on paper does not mean
that it will work once it is put together. It is good to recognize this and to be able to step
back and try another route.
Version 1.2
26
12/09/2002
81900277
De Paul University
Principles of Extreme Programming
Activities
Values
Principles
Practices

Listening

Communication

Rapid Feedback

Planning Game

Designing

Simplicity

Assume Simplicity

Small Releases

Coding

Feedback
Incremental

Metaphor

Testing

Courage
Change

Simple Design

Embracing Change

Testing

Quality Work

Refactoring

Teach Learning

Pair Programming

Small Initial

Collective Ownership
Investment

Continuous Integration

Play To Win

40-Hour Workweek or

Concrete

Sustainable Equivalent
Experiments

On-Site Customer
Open, Honest

Coding Standards
Communication

Work With People’s
Instincts

Local Adaptation

Travel Light

Honest
Measurement
The principles of Extreme Programming are a bridge to the values. There are five main
principles. They include:

Rapid feedback – “get feedback, interpret it, and put what is learned back into the
system as quickly as possible.” [3]
Version 1.2
27
12/09/2002
81900277
De Paul University

Assume simplicity – code only what is needed.

Incremental change – make small changes in a series over time.

Embracing change – technology and business are constantly changing; it is best to
accept change and adapt.

Quality work
There are some other more minor principles that Extreme Programming also believes in.
These include:

Teach learning – strategies need to be developed. Individuals are then able to
take these strategies and create their own styles and procedures to fulfill their
work requirements.

Small initial investment – start small and add later. Resources can be expensive
and when a project is just starting, too many resources can be troublesome to a
project’s bottom line.

Play to win – do what is required. “Software development played to win does
everything that helps the team to win and doesn’t do anything that doesn’t help to
win.” [3]

Concrete experiments – decisions need to tested.

Open, honest communication – team members need to talk to each other.

Work with people’s instincts, not against them – teams need to work together and
respect other members.
Version 1.2
28
12/09/2002
81900277

De Paul University
Accepted responsibility – let people be individuals as long as it is not to the
detriment of the team. Let individuals choose tasks that need to be developed and
openly resolve issues.

Local adaptation – adapt the process to fit the company’s needs and culture.

Travel light – developers need to be able to change.

Honest measurement – “choose metrics that have correlation to the way we want
to work.” [3]
Version 1.2
29
12/09/2002
81900277
De Paul University
Practices of Extreme Programming
Activities
Values
Principles
Practices

Listening

Communication

Rapid Feedback

Planning Game

Designing

Simplicity

Assume Simplicity

Small Releases

Coding

Feedback
Incremental

Metaphor

Testing

Courage
Change

Simple Design

Embracing Change

Testing

Quality Work

Refactoring

Teach Learning

Pair Programming

Small Initial

Collective Ownership
Investment

Continuous Integration

Play To Win

40-Hour Workweek or

Concrete

Sustainable Equivalent
Experiments

On-Site Customer
Open, Honest

Coding Standards
Communication

Work With People’s
Instincts

Local Adaptation

Travel Light

Honest
Measurement
There are twelve (12) practices which extreme programming advocates. These include:

Planning Game

Small Releases

Metaphor

Simple design
Version 1.2
30
12/09/2002
81900277
De Paul University

Testing

Refactoring

Pair programming

Collective ownership

Continuous integration

40-Hour workweek or sustainable equivalent

On-site customer

Coding standards
Practices, Principles, and Values – Tying Them Together
The above guidelines can now be put into action. The below process flow encapsulates
many of the practices of Extreme Programming. The general process flow can be
modified and adapted to fit a company’s specialized needs.
The first idea is that the customer needs to write stories. These stories need to be short,
but have enough detail to explain what the system is expected to do. The development
team takes the stories and provides estimates. They also determine how many iterations
will comprise one release and how long each iteration will be. The team also needs to
estimate how many hours of coding they can perform in an iteration.
Once the stories are estimated, the development team meets with the customer. The
customer determines what he or she would like to see in the first release. Then, they
break it down by iteration. The estimates are summed to ensure that the development
Version 1.2
31
12/09/2002
81900277
De Paul University
team can code that amount of work in one iteration. If not, the customer needs to
reevaluate the stories and pull those that are not wanted for the first iteration.
The next step would be for the development team to take the stories and break them into
tasks. The developers can choose which tasks they want to code and then place estimates
on these. The team reassesses the estimates and if these new estimates exceed what can
be completed in an iteration, they need to call the customer back so that he or she can
decide on what other tasks can be removed.
Once the preliminaries are done, the team can start writing the unit test cases. The code
is then developed to fit the test case. This ensures that only the needed requirements are
developed. Once a task is complete, the developers should integrate the code and rerun
the tests to ensure that the whole system is still functioning. It is best to do this as
frequently as possible. This ensures that if the newly installed code breaks the system,
the cause can be easily (hopefully) found since the new code is fresh in the developers’
minds. Also, the developers are responsible for refactoring the code. The goal is to
remove any duplication and complexities.
The developer also needs to be able to notify the customer of any questions he or she may
have. If they cannot, there should be a process in place to resolve the issues in a timely
manner. Management needs to be tracking progress so that any schedule slippage can be
corrected as soon as possible. This may mean reevaluating what items can be fulfilled in
Version 1.2
32
12/09/2002
81900277
De Paul University
the iteration. At the same time, the customer can be writing the acceptance tests that they
will use for reviewing the system’s functionality.
When the iteration is complete, the code is built and the customer can begin acceptance
testing. Any defects or issues should be addressed as new stories that can be added to
later iterations or releases. Also, the customer is made aware of any tasks that are not
finished. This allows for the customer to reschedule the tests. Once the iteration is
complete, the team can reevaluate their work capacity for the next iteration.
The
customer then takes these new estimates to assess what is needed for the next iteration.
The process begins again.
The other practices such as 40 hour workweek, metaphor, and collective ownership also
help to make Extreme Programming a success.
The developers try to not work
consecutive weeks of overtime. Tired workers lead to more mistakes and more work.
When workers are not able to concentrate and produce quality work, the result is often
schedule slippages. The metaphor allows for everyone to have a basic understanding of
the system. Collective ownership allows for anyone on the team to change the code.
They know that they can change the code and not break anything else since they can run
the tests against the new code. Even though these practices are not specifically mentioned
in the process flow above, they are occurring as development proceeds.
Version 1.2
33
12/09/2002
81900277
De Paul University
Extreme Programming – Is It the Answer?
Now that there is a better understanding of what the Waterfall and Extreme Programming
Methodologies are, we can proceed to determine if the practices of Extreme
Programming help to develop better software systems than the other traditional
methodologies such as Waterfall. Also, we will have implementers assess how difficult it
is to implement Extreme Programming.
Version 1.2
34
12/09/2002
81900277
De Paul University
Research Study
A survey was used to determine the validity of the hypothesis. There was a privacy
statement issued to the survey respondents. It stated that all information would be kept
confidential and in strict confidence. All data would be aggregated. Company names
would not be named.
The questions were broken out into three areas. These areas were demographics,
implementation approach, and benefits and costs. The following questions were used for
the survey:
I. Demographics
1. Please provide a brief description of the process that was in place before Extreme
Programming (i.e. Waterfall, Code and Fix, etc.):
2. Please provide a brief description of the Project that Implemented Extreme
Programming:
3. Please briefly describe the company’s culture, size, and any other relevant
background.
Version 1.2
35
12/09/2002
81900277
De Paul University
4. What was the team size?
5. What were the team members’ areas of expertise? How did this effect the overall
implementation?
6. What was the duration of the project?
7. How many lines of code and/or objects did the project contain?
II.
Implementation Approach
8. Was Extreme Programming implemented all at once or introduced step by step?
9. Please provide a brief description of how Extreme Programming was
implemented for the project.
10. How many iterations were in a release? How long was an iteration?
11. Below are listed the practices of Extreme Programming. Please mark an “S” next
to the practices successfully implemented, “N” for the practices not implemented,
“U” for unsuccessful implementation, “P” for partial implementation.
A. Planning game:
Version 1.2
_____
36
12/09/2002
81900277
De Paul University
B. Small Releases:
_____
C. Metaphor:
_____
D. Simple Design:
_____
E. Testing:
_____
F. Refactoring:
_____
G. Pair Programming:
_____
H. Collective Ownership:
_____
I. Continuous Integration: _____
J. 40-hour work week:
_____
K. On-site customer:
_____
L. Coding Standards:
_____
12. Please list some of the ideas / practices that made the implementation of the
practices most successful.
13. Please list some of the practices or issues that made the implementation of the
practices most difficult.
14. How was communication within the team and with the customer?
15. Was the customer readily available to address concerns, questions, release
compositions, and prioritizations? Please explain.
Version 1.2
37
12/09/2002
81900277
De Paul University
16. Was any project tracking performed? If yes, please explain the measurements
performed and how they were done.
17. Was management supportive during the implementation of the new process? Do
you feel that this had an impact on how well the new process was accepted by
others and did this effect their attitudes?
III. Benefits and Costs
18.
Did you feel that Extreme Programming was:
a. Extremely easy to implement
b. Easy to implement
c. Difficult to implement
d. Extremely difficult to implement
19. Did you feel that the project successfully implemented Extreme Programming?
Please explain.
20. Please list some of the problems / issues and resolutions (if any) that made
implementation of the practices hard.
Version 1.2
38
12/09/2002
81900277
De Paul University
21. Please list some of the benefits that were derived from the implementation of
Extreme Programming
22. Would you use Extreme Programming on another project? Please explain.
23. Do you feel that Extreme Programming is a worthwhile process for other
companies to implement? Please explain.
24. Are there any environments/projects that you feel Extreme Programming is not
suited for?
25. If you were to implement Extreme Programming again, what would you change?
The survey was emailed out to approximately 20 individuals who have had experience
with Extreme Programming. These individuals were selected from Extreme
Programming websites, books, personal meetings, and panel discussions. The survey
could be filled out and returned via email. Respondents also had the choice of
conducting a phone interview. The results were then compiled to determine the validity
of the hypothesis.
Version 1.2
39
12/09/2002
81900277
De Paul University
Results
The information contained in the Results and Conclusion sections below was taken from
the surveys returned. This information is the ideas, thoughts, and data from the
respondents themselves. In many cases, they are the exact words of the respondents and
should be viewed as the respondents. [7] The responses to the questions are more
qualitative than quantitative. Future surveys would benefit from more quantitative
analysis.
Overall Results
Number Of Surveys
There were 20 surveys sent out and 7 responses were received. Three were email
responses and the other 4 were phone interviews. Of the 7 responses, 6 believed that
Extreme Programming was successfully implemented.
Types of Companies
One company was a small part of a larger conglomerate and was in the science field.
Another company was an auto manufacturer. A third company was a start up security
company and the fourth company was part of the secondary mortgage industry. The
other two companies were an insurance company and a software distributor.
To preserve anonymity, an arbitrary set of letters has been chosen to represent the
different projects that were analyzed. Projects will be referred to as Project A, Project B,
etc.
Version 1.2
40
12/09/2002
81900277
De Paul University
Matrix of Practices Implemented / Not Implemented
Below is a list of the Extreme Programming Practices and how the respondents ranked
implementation of the practice for the project.
XP Practice
Successful
Partial
Unsuccessful
Not Implemented
Planning Game
C, D, E, F, G
B
A
Small Releases
E, F, G
A, B, D
C
Metaphor
C, G
B, D
A, E, F
Simple Design
A, B, C, D, E, F, G
Testing
B, C, D, E, F
A, G
Refactoring
B, C, D, E, F
A, G
Pair
B, C, D, E, F, G
A
B, C, D, E, F, G
A
B, C, D, E, F, G
A
B, C, E, G
A, D
On-Site Customer
C, D, E, F
A, B, G
Coding Standards
B, C, D, E, F, G
A
Programming
Collective
Ownership
Continuous
Integration
40-hour work
F
week
Version 1.2
41
12/09/2002
81900277
De Paul University
Project A
Background / Demographics
Project Description
Project A was to take the existing legacy system and create a .NET front end that would
transmit data via XML strings to it for updating. Plus, the legacy code needed to be
cleaned up and be restructured to better mirror an object oriented database. It currently
was a relational database.
Project A’s company had originally been using a Waterfall Model. Management was
unhappy with the time it took to complete a task using the Waterfall model and began to
examine Extreme Programming as an alternative.
Company Objectives
Management wanted a process that was light on documentation and less time consuming.
They needed to create a new product quickly. They had a short time frame to get a
product to market.
The company was very used to having all aspects of development backed up by several
pages of documentation. This documentation had to go through a lengthy review and
approval process.
Version 1.2
42
12/09/2002
81900277
De Paul University
Team Size
The team size consisted of 15 individuals. A majority of the team had no object-oriented
development experience. Five members of the team were strong on the object-oriented
development. This had a detrimental effect on the project since the mindset of many
employees going into the project was relational databases. The switch to object oriented
was a hard concept for many to grasp. Seven individuals were sent to one-week classes to
learn the .Net technology. They were then supposed to come back and train the other
team members.
Project Size
The project consisted of about 10 projects. The projects contained over 20 classes each.
The legacy code was large and due to the many modifications over the years could not be
estimated.
The first release of the project took about 6 months. There was much duplication in the
code in regards to multiple objects and classes. The first release had several iterations.
The first iteration lasted 4 months and the following iterations were about 1 week in time.
Implementation of Extreme Programming
The management team liked the concepts that Extreme Programming advocated. It was
decided that the new process would be a set of guidelines that would be presented to the
developers at a meeting.
Version 1.2
43
12/09/2002
81900277
De Paul University
In designing the new process, they first came up with a basic process methodology. This
methodology was a list of goals for the process to achieve. One was to set release goals
and milestones. Another provision in the process was to develop and check-in smaller,
incremental steps. The Quality Analysis function would be automated. Finally, the
product would be built weekly and would be measured to see how well it met the goals
for the week.
Agile teams would form and reform as task developed. This would allow individuals the
opportunity to work in a variety of roles. The developers had a voice in the system being
created and the specifications were to be minimal.
Management created a list of values and ideas. Many of these were based off of the same
principles that are contained in the Extreme programming philosophy.
The next step was to create a sample process workflow. The below is an example that
was proposed.
1. Product marketing identifies and prioritizes a business requirement
2. Feature team discussions detail out the design and negotiate the requirement
3. Product marketing records and posts the requirements
4. The development teams accept the requirements and estimates
5. Management plans, projects, and measures
6. Daily 9:00 a.m. all-hands meeting to review issues and/or obstacles
7. Development teams develop code and unit test. Then, integrate code daily.
Version 1.2
44
12/09/2002
81900277
De Paul University
8. Weekly production build
9. QA performs automated regression and acceptance testing
10. Measurement of completed requirements = status of product
Management decided to not implement the Paired Programming concept. They did not
feel comfortable with the idea and were not sure how the concept could allow for a
greater productivity. However, they were using the idea that code would be inspected and
unit tested via other team members.
The developers were given their tasks and went off to begin developing. The above
workflow was on paper and it never was seen in action by the developers.
Ideas that Helped Implementation
Not many of the practices were successfully implemented. However, there were 4
members of the team, who as they were developing, had adopted many of the Extreme
Programming practices. One example was the Pair Programming practice. Pair
programming was really not being done in this project. But, when a complicated task
came around, there were two teams of people who would get together and develop the
task at one terminal. This helped to get the task done and, at the same time, the team
members were able to learn from each other.
Ideas that Hampered Implementation
One issue for this project is that there was no one really monitoring the development
process daily. Because of this, several developers decided to adopt their own process.
Version 1.2
45
12/09/2002
81900277
De Paul University
Communication with the customer was not a high point. The customer was the
marketing team and management. When a question came up, an email would have to be
sent and it could take days for an answer. Also, the stories that were developed did not
have much meaning. Many were so brief that the developer would need to see how the
legacy system responded in order to determine what the requirements really were. Also,
there was really no prioritizations regarding tasks. The developer was handed a story and
that story was his or her responsibility to develop. On the other hand, communication
within the team was better. Daily emails were sent to the whole team to let everyone
know what he or she would be working on for the day. An issue with this was that some
people chose to ignore the emails because at times there was too much information.
Management support was lacking on this project. Management had concerns with
growing the shrinking customer base and getting the new product to market. The process
that was being used to develop the product was not a focus. Also, there was no dedicated
resource to ensure that the process was followed. Therefore, some developers tended to
create their own process as they went. Other developers tended to revert back to the
Waterfall Model
Respondent Ranking on Ease of Implementation
Extreme Programming was extremely difficult to implement. There were too many
variables that caused the implementation to fail. The company needed to get a new
product to market and to grow the customer base to make sales. The development team
Version 1.2
46
12/09/2002
81900277
De Paul University
was focused on developing the product and learning new technologies at the same time.
There was not much time to focus on the development process.
Measurements Performed
Due to time constraints, no measurements were performed.
Benefits
For those members that used the pair programming concept to handle the more complex
tasks, there was a resounding “I like this” response. It helped developers learn new
concepts. They were able to exchange ideas on what they knew. Since the technology
was new to all the developers on this project, this was a definite bonus.
Obstacles
Management support was needed. Since there was no real advocacy from management,
the team did not feel that the new process was that important. The general consensus was
to get the product done.
Communication was also an issue. Everyone seemed to be moving ahead on tasks not
realizing how one decision could affect other developers. Questions were not always
answered in a timely manner. At some points, developers were waiting for answers and
could not move forward until the issues were answered.
Finally, testing was another obstacle. If the tests were automated, it would have been
more efficient. Many times, the QA team would bring an issue to a developer. The
Version 1.2
47
12/09/2002
81900277
De Paul University
developer would try to duplicate it and could not. The developer was trying to run the test
based on an incomplete, written description.
Improvements On Next Implementation
If Extreme Programming was to be implemented again, it would be best to try it when
there can be a focus on the process. A dedicated resource is needed to monitor the
process. Management needs to be supportive. Also, it would be better if the team was
familiar with the technology that was being used for development. Having to learn a new
technology and development process at the same time can be too overwhelming.
Environments to Not Implement In
Extreme Programming is definitely not recommended for an environment where there are
too many focuses at once. In the end, something falls by the way side.
Project B
Background / Demographics
Project Description
The company had patented tools for the analysis of blood samples. They needed
software to manage the analysis. The system was required to produce the results in a
timely manner. The application was to be a desktop application that had connections to
other equipment via serial ports. It would be developed in Java and use an object
oriented database.
Version 1.2
48
12/09/2002
81900277
De Paul University
The basic development approach used before Extreme Programming was code and fix.
Company Objectives
This company was a small part of a larger conglomerate. They were very hesitant about
introducing the software into the field too soon. They felt that as long as they had
something that already worked, why rush? Since the company did not feel that it had
sufficient in-house resources, they hired a consulting team. The consulting team had used
Extreme Programming for other projects and was extremely pleased with the results.
Also, the company needed some type of process. The code and fix approach was not
producing the needed results.
Team Size
The development teams consisted of 6 - 12 individuals. There was one full time business
person and 12 other part time business individuals. The team had some object oriented
expertise. Those who were not experts had at least been exposed to object oriented
technology. Extreme Programming helped the team get up to speed very quickly. The
pair programming concept allowed for a huge transfer of knowledge.
Project Size
There were over 1000 classes and approximately 3000 – 4000 unit test cases.
The project took about 3.5 years. During this time, there were several releases as the
system went through ongoing development. The first shippable product took 3 years to
produce, which was because of some company strategy issues. In reality, there was a
Version 1.2
49
12/09/2002
81900277
De Paul University
working version within the first 6 months. There were 30 iterations in a release and the
iterations lasted 4 weeks.
Implementation of Extreme Programming
The basic approach to implementing Extreme Programming was to do it all at once. This
took a couple of weeks. The first step was to explain the process to the team. Then, the
team needed to be taught the practices by using a prototype. This was a short iteration.
This time was classified as the Exploratory Phase and it lasted about 6 – 8 weeks. During
this time, the team was shown the practices, a proof of concept was demonstrated, and a
prototype was built.
One of the main focuses of Extreme Programming is communication, which in this
project was great. “The customer was readily available even though he or she was not in
the room and, the team members worked well together. There were few surprises since
everyone knew what was going on.” [7]
Ideas that Helped Implementation
One idea that made the implementation of the practices successful was the Lessons
Learned meetings that were done. “This meeting was used to determine what needed
fixing and what went well. This gave the team the opportunity to display courage and
say “Stop” when something was not right. This concept fostered an attitude of constant
reflection and helped to improve the process with each iteration.” [7]
Version 1.2
50
12/09/2002
81900277
De Paul University
Another point that helped to make the implementation easier was that management was
supportive. “They liked the general idea of Extreme Programming and did not promote or
shoot down any of the practices.” [7] The company was more concerned with their
current business than the software that was being developed. The consulting team was
given a task and the management was not going to interfere.
Ideas that Hampered Implementation
At times, it was difficult to implement the practices. The main issue was the corporate
culture. “On the business side, no one really owned the product and the attitude was that
they had something that worked, no need to rush. There was a lack of accountability and
no commitment to set a deadline. When issues were raised to management, they did not
handle the issues. If something changed, there were no consequences.” [7] For example,
if a task was not completed in an iteration, management would just add the task to
another iteration. They did not look at the importance of the other tasks and how moving
this one task effected the rest of the schedule. Also, management would not give the
development team a deadline date.
Respondent Ranking on Ease of Implementation
In looking back at the project, Extreme Programming was easy to implement for this
project.
Version 1.2
51
12/09/2002
81900277
De Paul University
Measurements Performed
A roll up was done on task estimates versus the actuals. The analysis was done on the
task, story, and iteration level. The number of acceptance tests written versus passing
was recorded on a whiteboard.
Benefits
The benefits of Extreme Programming on this project were numerous. “The cross
training was phenomenal. This had the effect of producing an accelerated learning curve.
What the team learned in one year was the equivalent of 3- 5 years of solid experience.”
[7] The important premise was that the team was able to keep things moving forward
after the consulting team left the project. The less skilled developers were able to change
the code and not break it in the process. Also, there was a great amount of personal
growth. The individuals on the team were able to socialize and relate better. Their self
confidence grew, along with the maturity level. The team was not afraid of a challenge.
The respondent also believes that Extreme Programming can be worthwhile for any
company. “Everyone wants to reap the benefits that Extreme Programming gives.
However, many do not want to take the steps required to achieve these benefits.
Adjustments need to be made in the company culture and environment. The individuals
need to change their attitudes and mentality.” [7]
Obstacles
One obstacle to implementation came from a team member’s attitude and actions. “ The
person would reject the practices of Extreme Programming. He would not pair with other
Version 1.2
52
12/09/2002
81900277
De Paul University
programmers and insisted on writing large documents. The team learned to work around
his habits to make Extreme Programming work.” [7]
Another issue was customer accountability. When a task slipped or was pushed into a
new iteration, no one paid attention to the impact that this would have on future
iterations.
Improvements On Next Implementation
For the next implementation, there needs to be more focus on short releases.
Management needs to leverage what they have. “The releases could have been done
every few months, but there was a fear of how the impact would affect the customers if
the releases were too frequent. If there were more deliveries, the company could have
received better returns. The management did not have a desire to change and wanted to
do things as they had always been done.” [7]
There were issues also with developers who did not recognize their weaknesses. This
caused much rework to be done. The developers needed to recognize their weaknesses
and be able to go to the right resources for help. Another issue that needs to be addressed
on the next iteration would be to have better management support. Senior management
should hold employees more accountable. The proper upper management support can
make a difference in whether or not a project succeeds.
Version 1.2
53
12/09/2002
81900277
De Paul University
Environments to Not Implement In
There is one situation where the respondent feels that implementing Extreme
Programming may not be appropriate. “This is when a team is dealing with large
working legacy code.” [7]
Project C
Background / Demographics
Project Description
Project C was a corporate payroll system. The implementation appeared to be designheavy and the approach seemed to be to build for the future.
Company Objectives
The company’s IT department used generally chaotic software development practices that
were wrapped in a loosely-phased planning process.
Team Size
The team consisted of 21 individuals. There were two coaches – one full time and one
part time. The team also had 14 programmers and 2 testers. There were 3 on-site
customers. The programmers and testers had decent skills. The lead customer was
excellent. He knew the domain well.
Version 1.2
54
12/09/2002
81900277
De Paul University
Project Size
There were 250,000 lines of code. The system consisted of 3,000 classes and 30,000
methods. The project lasted one year once it was restarted using Extreme Programming.
The iterations lasted about 3 weeks and the first release contained about 20 iterations.
Implementation of Extreme Programming
Extreme programming was implemented all at once. The team was very receptive.
Whatever the coach said, the team did. The team fine-tuned the process as they went
along. The pair programming concept took off slowly and the refactoring practice was
slow in the beginning. This was due to lack of knowledge about refactoring. The other
practice that was really not implemented was small releases. It was hard to determine
how to do the small releases. “However, there was a fully integrated system that the
customer could test and view at any time. And, new features were continually being
added.” [7]
Ideas that Helped Implementation
First, “there was no one on the team who did not want to do Extreme Programming.” [7]
Also, the team started small. There were times when a couple individuals broke some of
the pairing or testing rules. The consequences were made obvious very quickly.
Secondly, the customer and management were great. “The support came from the top.”
[7] The communication with the customer and within the team was excellent. The
customer was always available to answer questions and prioritize issues and sat with the
team for the entire project. Management was supportive of the new process. “The real
Version 1.2
55
12/09/2002
81900277
De Paul University
push came from the coach’s leadership and the team’s willingness to accept it.” [7] The
team wanted to see the project succeed.
Ideas that Hampered Implementation
There were some issues that made the implementation of the practices difficult. There
was a small part of the original code kept in the system. “It was never brought up to the
coding standards and this code was difficult to maintain.” [7] “Also, there were a few
individuals who were fighting the adoption of Extreme Programming. These individuals
were asked to leave the project.” [7]
Respondent Ranking on Ease of Implementation
Extreme programming was very easy to implement and difficult, at times, for this project.
“It was very easy to implement when the participants are willing. It is difficult to
implement acceptance testing. Also, it is hard to sustain refactoring throughout the
project.” [7]
Measurements Performed
The team performed some analysis. The number of stories and tasks done over time was
tracked. Also, the team tracked the number of acceptance test running versus those not
running.
Benefits
One important milestone is that the product shipped approximately on time. There was a
very low defect count. The team was flexible. “Individuals could work on any part of
Version 1.2
56
12/09/2002
81900277
De Paul University
the system because the code was easy to understand and supported by a large number of
tests. Also, everyone on the team and in management could at any time see where the
system was.” [7]
Obstacles
There were some obstacles that the team encountered. One issue that was easily resolved
was when “individuals wanted to work odd hours or did not want to perform testing.
They were asked to leave.” [7] Also, when there was pressure from management,
individuals tended to buckle and forgo some of the practices. When this happened,
rework was often needed later. This can cause the project to go slower. Also, “planning
should be done on project releases. Lastly, management needs to be told what the team
knows – good and bad. Otherwise, political problems can evolve.” [7]
Improvements On Next Implementation
In retrospect, there are some things that could be changed on the next round of
implementation. “There should be more pair programming and acceptance tests can be
more generalized. Also, the practice of small releases needs to be implemented better.
Finally, the release plan should be public and kept current.” [7]
Environments to Not Implement In
It is important to remember that “any project that can do the XP practices will benefit
from them. The more practices that are done, the more benefits a company will see.” [7]
Version 1.2
57
12/09/2002
81900277
De Paul University
Project D
Background / Demographics
Project Description
Project D is an application that is being developed for a start up security company. The
development approach before the project was started was one of code and fix. The
company specializes in products that allow for the encrypting and decrypting of data that
is entering a network. Project D was to be a software application that would be used to
configure the devices for multiple systems.
Company Objectives
The company consisted of 30 employees. It was an extremely casual environment. Most
of the company were in the hardware, marketing, and selling areas, with the exception of
two Java Developers.
Team Size
The team consisted of 3 individuals. Two of the individuals were more senior. They had
collectively approximately 6 years of Java experience and desktop application
development. They also had experience with the J-Unit testing software. The junior
developer was a strong graphic artist. This combination brought much to the table.
There were a few deficits present that would impact the project. The project was going to
use new technologies that were foreign territory to this development team.
Version 1.2
58
12/09/2002
81900277
De Paul University
Project Size
The project has been in development for 3 months. It is expected to last through the end
of the year. Each release consists of 12 iterations. An iteration is 2 weeks long. There
are some other statistics that can be noted. There are about 10 Java server packages and
about 100 – 150 classes.
Implementation of Extreme Programming
Extreme Programming was implemented all at once for this project. Since the team was
so small and located very close together, stand up meetings were held occasionally. The
pair programming concept was a challenge since there were only 3 individuals. This
meant that the team could not pair all the time.
For the most part, the practices were implemented successfully. The small releases were
done on a quarterly basis. There were only pockets of metaphor for the system. The
testing practice was successful. There was J-unit tests. Also, the team is automating the
customer tests.
Ideas that Helped Implementation
It takes much teamwork to implement the practices of Extreme Programming. One key is
to “be honest with yourself and the customer.” [7] There needs to be discussion with the
customer. When planning the iterations, the team needs to be honest and up front with
what can be done and what cannot be done. This allows for the customer to decide what
really needs to be completed in an iteration.
Version 1.2
59
12/09/2002
81900277
De Paul University
Communication on this project was excellent. However, there were only 3 people. This
made it very easy. The customer fills the XP role to a tee. “He is able to write the
stories, prioritize the work, and do the tradeoffs. The customer is readily available to
answer all questions. He understands that a story is worth so many points and that the
team can only complete a certain number of points each iteration. The customer is able
to plan the iterations based on the points for the story.” [7]
Another area that helps make Extreme Programming successful for this project is that
management was extremely supportive. “They understood what was meant by XP. The
expectations were set early on and they bought it.” [7] Therefore, they wanted to
participate.
Ideas that Hampered Implementation
Pair programming is a difficult practice to implement. It is difficult because it requires
people to work together and not all people can get along. Also, pairs need to come up
with some type of system to help resolve disagreements in a quick, but productive way.
One example is to have each person rank how important his or her resolution is for the
disagreement. Another point is that pair programming needs people to be able to work
together. This can be difficult when a person is having a bad day or outside issues that
are affecting the emotions.
Another area that is hard to sustain throughout a project is the testing practice. “It is
difficult to determine the appropriate ways to test. A team needs to figure out when they
have enough tests.” [7] It is hard to find the right balance.
Version 1.2
60
12/09/2002
81900277
De Paul University
Another difficulty was the multiple platforms that could be used for this application. The
application could work on one platform, but would need modifications to work on
another. “The project was technically complicated.” [7] New technologies had to be
learned by the team.
Respondent Ranking on Ease of Implementation
The respondent believed that Project D was an easy implementation for Extreme
Programming.
Measurements Performed
There was some simple project tracking done. “The team used a modified wiki to
perform the tracking.” [7] Wiki is a term used to describe a composition system. “It’s
main function for this project was to act as a repository and hold the statistics.” [7] It was
a good way for the team to communicate. “Wiki is Hawaiian for 'quick'. The basic
premise is that a Wiki is a set of pages of information that are stored in a database. They
are managed using some type of scripts.” [7]
The time for stories and tasks were measured. The estimates versus the actuals were
being compared. Then, rollups could be performed on the task, story, and iteration level.
The team could also look back at previous iterations to assist in determining future
estimates.
Version 1.2
61
12/09/2002
81900277
De Paul University
Benefits
There were several benefits. “The customer believes that he or she is in control of the
process.” [7] The customer is not used to having this feeling. Therefore, “coaching needs
to be done in the beginning of the project so that the customer can adapt. The focus is on
what the customers want and need. The developers are also aware of why the customers
want the features that they request.” [7]
“Extreme Programming does the best job at balancing all the forces of software
development.” [7] The other methodologies do not take into account the people factor.
“With Extreme Programming, the customer has one voice.” [7] It does not allow for
projects to suffer because there is input from too many sources that are in conflict with
each other.
One last benefit is communication. “Extreme Programming forces people to
communicate frequently.” [7] This is one area where projects often fail. Extreme
Programming tries to resolve this point through its many practices, such as the planning
game and pair programming. These practices encourage communication within the team
and with the customer.
Obstacles
“One obstacle is that it is really hard to feel the true XP flow on this project. The team
was too small. The ideal project size should be around 6 – 8 people.”[7] This allows for
3 – 4 pairs to be working together and actually touching the code often. Another obstacle
Version 1.2
62
12/09/2002
81900277
De Paul University
was the disagreements that arose between the developers. Also, “technical issues were a
challenge throughout the project.” [7]
Improvements On Next Implementation
“It is very hard to be prescriptive. He believes that software projects should be quantified
to the customer. In other words, if the software in question is to be implemented, how
does it affect the customer’s bottom line?” [7] The development team needs to
understand why the software is important to the customer. In too many cases, the
customer believes that the software is going to create a large return on investment, but in
the end, it really has no effect on the bottom line at all.
Environments to Not Implement In
There needs to be a "distinction between new software development and software
maintenance. If these two areas exist within a company, there needs to be a split or else it
will be harder to have Extreme Programming. One group needs to focus on the existing
customer base. The other group needs to focus on the new customers.”[7] Otherwise, the
needs of the existing customers and the new customers can clash. Another obstacle is
there needs to be “organizational buy in to implement the cultural changes that Extreme
Programming advocates, such as pair programming, on-site customer, and 40 hour
workweek. Extreme Programming is a different way of thinking and people need to be
psychologically prepared to think this way and accept it.” [7]
Version 1.2
63
12/09/2002
81900277
De Paul University
Project E
Background / Demographics
Project Description
Project E was using a “Waterfall methodology that had many review steps. It can also be
characterized as a BDUF or Big Design Up Front.” [7] The project was an embedded
application. The system being developed was a subsystem of a much larger system. The
subsystems were decomposed from the BDUF. The group that was implementing the
subsystem was small.
Company Objectives
The culture is one where review and approval are the norm. Only one team was using the
XP methodology.
Team Size
The team size started out small. It had only two people. It eventually grew to six
individuals. The team members had a good knowledge of the application domain. Also,
there was some knowledge of C and C++. There was also some object oriented
knowledge.
Project Size
Project E lasted 6 months. There were about 100 classes. The iterations were 4 weeks
and a release consisted of 10 – 12 iterations.
Version 1.2
64
12/09/2002
81900277
De Paul University
Implementation of Extreme Programming
Extreme Programming was implemented all at once with one exception. “Instead of
using user stories, the team used use cases. The use cases were created incrementally.”
[7] For Project E, a systems engineer was designated as the on-site customer and the
programmers wrote the acceptance tests. The customer reviewed the tests. The iteration
planning actually took less than a day.
“The team communication was very good until the systems engineer joined the team.
The systems engineer was not a good team player. This negativity had an adverse effect
on the rest of the team, bringing them down.” [7] The customer was available when
needed. However, the “customer did not like when defects were found because this
meant he had to create more stories to correct the defects.”[7] He was not happy with the
additional work.
Ideas that Helped Implementation
The ideas that made this implementation of Extreme Programming successful were
iterative development and development was done on small tasks. Also, the idea of testing
first made the implementation of the practices successful.
Ideas that Hampered Implementation
The most difficult issue in implementing the practices was the fact that “the customer did
not write the automated acceptance tests. The developers performed this.” [7]
Version 1.2
65
12/09/2002
81900277
De Paul University
The management was supportive in implementing Extreme Programming. However,
“other engineers in other groups were suspicious of this support.” [7] Due to this
cautious and sometimes negative attitude, “management had trouble convincing the
engineers to try the techniques and practices.”[7]
Respondent Ranking on Ease of Implementation
This project could be classified as having Extreme Programming difficult to implement.
Measurements Performed
There was not much tracking done on this project.
Benefits
Some of the benefits that could be seen easily were that “the team had fun and learned
much at the same time. There was no need for tons of documentation.” [7] Project E
“had predictable schedule progress. The architecture was grown incrementally. Finally,
the tests were written before the code.” [7]
Obstacles
There were some issues with implementing Extreme Programming. Since the company
culture was entrenched in the idea of review and approval, it was difficult to implement
Extreme Programming. “The company wanted to have the design reviews. To resolve
this and satisfy the management team, “design-as-built” reviews were implemented. The
“design-as-built” reviews did not prevent the team from continuing on while waiting for
the review to occur.” [7]
Version 1.2
66
12/09/2002
81900277
De Paul University
Improvements On Next Implementation
If Extreme programming were to be implemented again, “the acceptance tests would be
automated.” [7] In regards to other aspects, “it is team dependent.” [7] The personalities
of the team determine what tweaking needs to be done in the implementation. No project
is the same and therefore no implementation of Extreme Programming will be the same.
Environments to Not Implement In
“All companies, teams, and projects are different.” [7] This is because they are made up
of people and people are different. “Some people just do not work well with Extreme
Programming, while others thrive. Also, a customer is needed to make Extreme
Programming work. Finally, management support is a necessity and is needed to
determine the iteration composition and realistic schedules for the project and team.” [7]
Project F
Background / Demographics
Project Description
Project F had many issues before the implementation of Extreme Programming. The
methodology that was in place was a Waterfall model. When the consulting team started,
Project F was already failing. The requirements were not complete. The delivery date
was frozen. Also, the requirements were created by people who were not part of the
development team.
Version 1.2
67
12/09/2002
81900277
De Paul University
Company Culture
The company was about 2 years old and really had no understanding of process or
methods. Their business direction was in a constant state of change. They needed a
process that would move with their business.
Team Size
The team was average in size. It had a total of 6 individuals. The whole team was
engineers. One member was the team lead. This person was the XP mentor, coach, and
had hands on development experience. The team members had in depth knowledge of
the financial industry.
Project Size
The project contained approximately 20 new objects. Also, 5 new components were
created.
“The project started with 3 week iterations. These were reduced to 2 week iterations so
that data could be gathered regarding how many tasks could be completed in an iteration.
The 2 week iteration was later reduced to 1 week iterations. This was to increase the
business value that the customer was receiving.” [7]
Implementation of Extreme Programming
Extreme Programming was implemented by applying some of the practices first. The
customer for this project was not the person who would be using the software. Due to an
already strained relationship with the client, the project manager was playing the role of
Version 1.2
68
12/09/2002
81900277
De Paul University
customer and this did not work well. The date was set and the features were wanted. The
XP mentor pushed for the real customer to be part of the team.
As the project moved along, the team needed someone to test the software. Finally, the
real customer was brought in. One feature that was thought to be complete was
demonstrated. The customer immediately spoke up. This was not what was requested.
The team was way off. Everyone can interpret the written word differently. The team
wanted to remedy the situation immediately. They sat down with the customer and had
her write down exactly what was needed. They then estimated the amount of work.
There were more requests. The client was asked to write all requests down and prioritize
them. This was the beginning of letting the client take control. This was also where the
team started to mend the relationship with the client. The customer saw the results early
on and was able to correct issues as they occurred. The system was being developed
according to the customer’s needs.
Ideas that Helped Implementation
The two practices not implemented were the 40 hour work week and metaphor. The
other practices that were implemented made the project successful. It is equivalent to
saying, “the sum of the parts is greater than the whole.”
Ideas that Hampered Implementation
Communication at the beginning of this project was nonexistent. The team made the
CEO aware of the issues early on. But, the CEO was adamant that the date was set and
Version 1.2
69
12/09/2002
81900277
De Paul University
the feature set would be developed as is. The team knew that since the company was new
that the requirements were going to change. The CEO liked the ideas presented
regarding Extreme Programming. He was not adopting them and was more concerned
with the signed contract. The team was finally able to have the customer come onsite.
Once the customer was on board and supportive, communication became great. “The
customer was taught what they needed to do; they were very capable of fulfilling the XP
customer role. They were available, addressed release compositions, and prioritized the
tasks.” [7]
Another major obstacle was getting the customer involved. At first, they did not have the
time to do the testing. However, once they were brought into the team and explained the
process, they made an effort. “They found it challenging to juggle commitments and to
be a part of the team.” [7] But, the rewards were worth it. The customer received a
system that was what they wanted. The customer also was able to learn from the team.
“The customer learned how to write clear stories and that testing was important
throughout the project. They also needed to be involved in the project.”[7] If not, the
risk is having something developed that is not what is wanted.
Respondent Ranking on Ease of Implementation
Extreme Programming can be classified as being easy to implement for this project.
Measurements Performed
At the beginning, the velocity was tracked to determine the project’s actual end date. The
team measured how well they were hitting their estimates on the stories. They needed to
Version 1.2
70
12/09/2002
81900277
De Paul University
shorten the iterations so that they could get some valid numbers. Due to the tight
schedule, project tracking was minimal on this project.
Benefits
As with the other projects, there were some benefits to implementing Extreme
Programming. “The biggest benefit was that it allowed the company to realize a product
that was better at meeting their expectations while reducing costs and raising the level of
quality. Once the customer was involved, the feedback loop was shortened. This
assisted in development because the team could keep moving at a reasonable pace.” [7]
The customer was won over by Extreme Programming and also found several areas of
great importance. These include:

“Being able to steer development based on my business needs

“Seeing working software sooner

“Knowing when things were going to be completed

“Being able to change my mind without costing extra

“Open communication

“Getting what I want the first time around

“Knowing immediately the risks.” [7]
There were more benefits too. “We proved that having the client on board, driving the
priorities and steering every decision was a tremendous benefit. We proved that
compiling all the requirements up front is a waste of time and that business requirements
Version 1.2
71
12/09/2002
81900277
De Paul University
do change. We proved that indeed the client ultimately understands their business better
than anyone else and we add value if we can respond to their requests now rather than
later. And we proved that short development cycles with working software and frequent
client feedback loop significantly reduces risk and helps keep the project on course.” [7]
The customer was enthusiastic about Extreme Programming. The experience was
enjoyable. “It was able to meet the business needs sooner, had the flexibility to modify
my requests and felt the quality of the final product was a significant improvement over
previous projects.” [7] The customer had seen projects before not meet the requirements.
Extreme Programming gives the customer control and they drive the project. The
customer needs to be part of the team and is the key to success. This is a main selling
point of Extreme Programming.
Obstacles
It took time to teach the customer how to write effective stories. Many times the stories
were too large. This is common with new customers who are implementing XP for the
first time. Another issue was that the “client had brought in a project manager who had
no knowledge of XP and had very poor project management skills.” [7]
Improvements On Next Implementation
If the respondent could implement Extreme Programming again, there are some changes
he would make. One issue that should be changed would be to “insist that the team pair
more often. This would allow the team to achieve a better transfer of knowledge across
the board.” [7] Another point is that the “client would be on board from the beginning.
Version 1.2
72
12/09/2002
81900277
De Paul University
Everyone needs to be present for the planning game. The practice of testing needs to be
improved. It needs to be a consistent part of the development cycle. There should be
more unit tests and the customer should be testing more often.” [7] Also, individuals
need to abandon the document everything mentality. This slows down the process. The
idea is to keep it simple. Another modification may be to “implement the practices one at
a time.” [7] The coach can focus on one practice and have the team get used to it. It may
not be as overwhelming. It is important to remember that the environment really plays a
role in how Extreme Programming is implemented. For this project, “the mindset and
attitudes of the management needed to be changed before Extreme Programming could
take hold.” [7]
Environments to Not Implement In
There are environments where Extreme Programming will not succeed. “If the company
does not want to do an agile process, then they should not.”[7] One cannot force XP into
an environment. “The team and client must accept XP.” [7]
Project G
Background / Demographics
Project Description
Project G is using Extreme Programming in a maintenance environment. It was a webbased application that needed much defect correction. The company had previously used
the Waterfall methodology for developing and maintaining software. The process was
riddled with many problems. The one problem was that “defects were being corrected,
but the code was not being deployed to production.” [7] Also, there were a high number
Version 1.2
73
12/09/2002
81900277
De Paul University
of defects being released into production. “The code merge process was complex and
risky.” [7] The company was looking for a way to get more productivity from its
resources. Finally, “the majority of defects were being found at the end of the
development cycle.” [7] It would have been more cost effective if they were found
earlier in the development cycle.
Company Objectives
The company was very hesitant when it came to making any changes. Management
needed proof before any changes would be approved. They wanted to see numbers that
showed there was an actual improvement and that the change would be cost effective.
The team started looking at other development processes. Extreme Programming seemed
to be the answer. Management gave the go ahead for a pilot.
Team Size
The team consisted of 18 people. Twelve were developers. There was also one coach,
one team leader / project manager, one analyst, one customer, and two testers. The team
brought a wide and varied skill set to the mix. The developers were of all levels. The
coach knew the Extreme Programming methodology, but had never led a team in
implementing it before. The project manager did not really participate in the day to day
happenings, but did oversee the project. The testers lacked automation expertise. The
customer knew what the product was supposed to do. This variety allowed for the team
to be able to learn from each other.
Version 1.2
74
12/09/2002
81900277
De Paul University
Project Size
The project lasted 12 weeks. There were 2 – 3 iterations per release. Each iteration
lasted one week. The application was about 275,000 lines.
Implementation of Extreme Programming
Extreme Programming was implemented all at once. The idea was first presented to
management. They believed that Extreme Programming could yield many benefits for
the company such as increase in productivity and quality. Management also wanted to
resolve the backlog of defects that were present for the application. They agreed to allow
the team to do a pilot on the web application project.
The team was assembled. Each member of the team was given a copy of Kent Beck’s
book that explains the concepts and principles of Extreme Programming. The team then
met and discussed the text. Once the team was sold on the Extreme Programming
methodology, the next step was to start implementing the process. “The whole team of
twelve performed the test first practice. Then, the team was broken down into three
groups of four. From there, the team was broken down into pairs.” [7] One problem that
was brought to light very quickly was that members of the team were weak in the area of
object oriented technology. For those members, special training was done to bring them
up to speed. This was a big plus for Extreme Programming. “Team members
weaknesses are found quickly and can be resolved early on. “ [7] Also, refactoring code
was done during the test first exercise. In some cases, “200 lines of code were pared
down to 50 lines.” [7] Duplication and complexity was removed from the system.
Version 1.2
75
12/09/2002
81900277
De Paul University
The planning game was modified. Since most of the defects were estimated at a day, the
team found that the estimation process was a waste of time. “The team decided that it
would be assumed that all defects would take one day to fix. If not, the defect would be
brought to the team’s attention and the customer would need to decide what to do. The
customer’s job was to prioritize the list of defects based on this assumption.” [7] The
practice of testing first was found to be very expensive for the team. This was because
the architecture was very complicated. Therefore, the team decided to perform the test
first practice whenever it could appropriately. Refactoring was also done when it was
feasible.
Ideas that Helped Implementation
There were some practices that made the implementation of the practices very successful.
One idea was to “practice as a team the test first idea.” [7] Also, “the test first and pair
programming practices helped bring the newer and younger developers up to speed
quickly since they were teamed with a senior developer.” [7] There was a transfer of
knowledge between the pairs. Finally, “having everyone in one central location was a
plus in making Extreme Programming successful. It facilitated communication since
everyone was in close proximity to one another.” [7]
Communication was very good for Project G. There was a hierarchy put in place. First,
face to face communication would happen. If the person was not available, leave a voice
mail. As a last resort, go with email. “For the team, 95% of communication was done
face to face. With the customer, 50% was done face to face.” [7] The customer was
Version 1.2
76
12/09/2002
81900277
De Paul University
located in another building. They would stop in once a day for about an hour or more.
However, they were very responsive and prompt when answering the emails.
Management was also very supportive of the process. The main premise was that this
was a pilot to see if it would resolve the many issues of the Waterfall model. They were
using this as an evaluation tool.
Ideas that Hampered Implementation
There were some areas that made the implementation difficult. One was that “since the
architecture was complex, it did not lend easily to the test first and refactoring practices.
It made these practices difficult, time-consuming, and expensive. Also, the team was too
large at the beginning of the project.” [7] It would have been better to start out with
fewer individuals and then ramp up. It was hard to keep that many individuals busy at
the beginning. Also, “since each defect took about one day to fix, it was hard for the
customer to keep up with the acceptance test writing. In many cases, the developers had
to write the tests and hope that they were correct in what the code should do.” [7]
Respondent Ranking on Ease of Implementation
For Project G, the respondent felt that Extreme Programming was difficult to implement.
“The team needs to have people who know what they are doing. It also takes practice
and time to implement the practices. Finally, the test first idea is difficult to master.” [7]
Version 1.2
77
12/09/2002
81900277
De Paul University
Measurements Performed
This project performed measurements on productivity and quality.
They measured
productivity by person day. They wanted to see how much work a single person could do
in one day. This measurement showed a significant increase in productivity. “It took
about one month before the team was at a level of productivity equal to prepilot
productivity. However, once this was reached, the productivity kept increasing. At some
points, there was a 300 – 400% higher productivity than prepilot. On average, though,
productivity was double the prepilot productivity.” [7]
Quality also had successful results. They measured the number of defects preproduction.
“Before Extreme Programming, there were 5 defects for every 10 items put into
production. At the end of the first iteration, this dropped to one third. By the end of the
pilot, the defects were down to one defect for every 10 items put into production.” [7]
The results were compared with numbers from the previous process. These numbers
offered the management team the proof they needed that Extreme Programming was a
better methodology than Waterfall.
Benefits
Project G showed many benefits that were derived from the implementation of Extreme
Programming. The team was able to get through more defects in a shorter amount of
time. The product quality improved. There was definitely higher quality and
productivity. This was seen in the numbers -- it was actually quantified. “The delivery
process was faster and therefore, code was being moved into production quicker.
Version 1.2
78
12/09/2002
81900277
De Paul University
Corrected defects were being released every 3 weeks. Before, it was taking 78 days to
close a defect.” [7]
Also, individuals who were previously less productive were more productive in this
environment. They were learning more and they were learning it quicker. The team was
able to maximize efficiency.
“Extreme Programming allows the resources to be focused on what is important.” [7]
The customer is telling the team what needs to be done now and that is what the team is
working on. The time sensitive issues are being completed first. Also, “Extreme
Programming allows for small wins quickly.” [7] This, in turn, builds the team’s and
customer’s confidences. Finally, “the company is leveraging its assets. Since employees
are learning very quickly, the company is able to get the most from them. They are more
productive in a shorter time span.” [7]
Obstacles
There were also problems that arose during the implementation. One is that “the team
learned early on that there needed to be more training to handle the weakness that was
present from lack of object oriented technology knowledge.” [7] It was also found that
every solution required significant refactoring to allow for test first to occur. Therefore,
the refactoring and test first were only done when it was feasible. Also, analysis of the
defects was taking too much time. It was decided that the team would work on one issue
until it was complete. Finally, “new issues were not getting attention when they were
reported. One new defect may have had enough business impact to knock another defect
Version 1.2
79
12/09/2002
81900277
De Paul University
down a priority. The customer decided that the best route would be for him to decide the
urgency of the new issues based on the few details that were present.” [7]
Extreme Programming advocates let the code be the documentation. For large
enterprises, this is not prudent. There needs to be some sort of documentation for the
users and others. The respondent feels that a simple flowchart could suffice.
Improvements On Next Implementation
If this respondent was to implement Extreme Programming again, there are some ideas
that he would implement differently. First, “he would definitely start with a smaller
team. Then, once the workload started to build up, the team would be ramped up. He
would also bring in a seasoned test first person. This person would be responsible for
teaching the team techniques for test first. Finally, he would like to see more buy in from
the customer.” [7] The customer is an integral part of Extreme Programming. They no
longer give the requirements and then sit on the sidelines until the system is developed.
They are a part of the process – from beginning to end.
Environments to Not Implement In
“Extreme Programming would be difficult to implement in a company where there are
multiple teams working together and only one team is using Extreme Programming.” [7]
It needs to be an all or nothing situation. Otherwise, something will fail. “Any team can
adopt the practices as long as they are receptive to the concepts and practices.” [7]
Version 1.2
80
12/09/2002
81900277
De Paul University
Conclusion
At the beginning, we had set out to prove two points. One is that the practices of Extreme
Programming help to develop better software systems than the other traditional
methodologies such as Waterfall. The second hypothesis that we set out to prove was
that Extreme Programming was easy to implement. Below is an analysis of the results
and how they fit into proving the original hypothesis.
Summary of Findings
Projects Background / Demographics
Seven projects were analyzed.
All except one implemented Extreme Programming
successfully. Three of the projects had a Waterfall methodology in place before
implementing Extreme Programming. The others were using a code and fix approach.
For the most part, the companies were all large to midsize. They ranged in size from a
few hundred employees to over ten thousand. There were also two smaller startup
companies of thirty to sixty employees each.
Project Description
All the projects were new development projects with the exception of Project G. Project
G implemented Extreme Programming in a maintenance environment.
Version 1.2
81
The projects
12/09/2002
81900277
De Paul University
were a mix of desktop and Web applications. The applications were being used by a
variety of industries. These include the automotive, financial, and security sectors.
Company Objectives
The company cultures ran the gamut. Project D’s company culture was at one extreme –
it was completely casual and laid back. While Project A and E were mired in the
philosophy that everything needed to be reviewed and approved. They believed that
before anything could be developed, it needed to be reviewed and approved by
management. Project B’s company was more concerned with their business than with the
software being developed. Project G wanted to see quantitative proof before they would
accept or reject the new process. Project F’s company was more concerned with the
signed contract than actually creating software that satisfied the customer’s needs. As
can be seen, the culture for each project was different.
Team Size
The teams were average in size. They were around 6 to 12 people. The smallest team
consisted of three developers. It was pointed out that this team is too small to see the
benefits of Extreme Programming. Teams should really be about 6 individuals or more.
The other projects followed this guideline.
Project Size
The project durations ranged from a few months to 1 year. There was the exception of
one project that was going on for 3.5 years. The first working version was available
within 6 months.
Version 1.2
82
12/09/2002
81900277
De Paul University
The number of objects and lines of codes had a wide range, but all the systems were mid
to large size. Lines of code were between 100,000 and 275,000 and the number of
objects were between 100 and 3000.
Implementation of Extreme Programming
Six of the respondents replied that Extreme Programming was implemented all at once.
Project F applied a few practices at a time. Project G had the team read Kent Beck’s
book and then they discussed it. Project B showed the team how to use the practices by
implementing a prototype first.
Some projects modified the practices to fit the environment. Project E used use cases
instead of user stories. Project G modified the planning game.
Ideas that Helped Implementation
Five respondents believed that a supportive management was important. Management
support can make or break a project. Employees look to management for guidance. If
management is in strong support of a project, the team will try to make it a success.
Also, there needs to be accountability. Management needs to take ownership and needs
to embrace the process. They need to set deadlines and goals. Management also needs to
realize that changes need to be made. The team needs to adopt a new way of thinking
when they implement Extreme Programming.
Version 1.2
83
12/09/2002
81900277
De Paul University
Three respondents commented on the excellent communication with the customer and
within the team. The customer was available to answer questions, prioritize, and
determine the compositions of an iteration.
Project B ran lessons learned meetings. These brought the team together so that they
could focus on the process. It was a time where they could see what worked and did not
work. They could then adjust the process to correct or resolve any issues and obstacles.
This helped to make Extreme Programming successful.
Other ideas that the respondents felt assisted with the implementation include:

Everyone on the team wanted to do Extreme Programming. (Project C)

The team started small. (Project C)

The real push came from the coach’s leadership and the team’s willingness to
accept it. The team wanted to see the project succeed. The team spirit was high.
(Project C)

One key is to be honest with yourself and the customer. When planning the
iterations, the team needs to be honest and upfront with what can be done and
what cannot be done. (Project D)

Iterative development (Project E)

Development was done on small tasks (Project E)

Practice as a team the test first idea. (Project G)
Version 1.2
84
12/09/2002
81900277

De Paul University
The test first and pair programming practices helped bring the newer and younger
developers up to speed quickly. There was a transfer of knowledge between the
pairs. (Project G)

Having everyone in one central location facilitated communication (Project G)
Ideas that Hampered Implementation
Two respondents commented on lack of communication being issues for the projects.
Another two respondents also found that lack of management support were issues for
implementing the practice.
Some other issues that respondents felt hindered the implementation of the practices
include:

On the business side, no one really owned the product and there was a lack of
accountability. (Project B)

There was a small part of the original code kept in the system. It was never
brought up to the coding standards. (Project C)

Individuals who were fighting the adoption of Extreme Programming. (Project C)

Pair programming is a difficult practice to implement because it requires people to
work together in harmony. (Project D)

The testing practice is hard to sustain throughout a project. It is also difficult to
determine the appropriate ways to test. (Project D)

Multiple platforms that an application uses can cause complexity. (Project D)
Version 1.2
85
12/09/2002
81900277
De Paul University

The customer did not write the automated acceptance tests. (Project E)

Getting the customer involved. (Project F)

The architecture was complex and it did not lend easily to the test first and
refactoring practices. It made these practices difficult, time-consuming, and
expensive. (Project G)

The team was too large at the beginning of the project. (Project G)

It was hard for the customer to keep up with the acceptance test writing. (Project
G)
Respondent Ranking on Ease of Implementation
Three respondents thought Extreme Programming was easy to implement and the other
three thought it was difficult. Project C’s respondent believed that it was easy and
difficult at different times in the project. This ranking was subjective to the respondents
based on many external factors, such as the team members’ personalities, customer
involvement, and management support.
Measurements Performed
Six of the respondents reported that some types of measurements were performed.
Project G tracked productivity and quality. These statistics were then compared to
previous numbers using the Waterfall methodology.
The other five projects tracked more of the actuals vs. estimates numbers. The statistics
could be rolled up based on task, story, iteration, or release level.
Version 1.2
86
12/09/2002
81900277
De Paul University
Benefits
Two projects commented on an increase in quality.
Project G backed this up
quantitatively. Also, two other respondents remarked on the customer believing that he
or she is in control of the process.
Some other benefits that the respondents commented on include:

The pair programming practice helped developers learn new concepts. (Project A)

The cross training was phenomenal. This had the effect of producing an
accelerated learning curve. (Project B)

There was a great amount of personal growth. (Project B)

The product shipped approximately on time. (Project C)

Individuals could work on any part of the system because the code was easy to
understand and supported by a large number of tests. (Project C)

Everyone on the team and in management could at any time see where the system
was. (Project C)

Extreme Programming does the best job at balancing all the forces of software
development. The other methodologies do not take into account the people factor.
(Project D)

The customer has one voice. (Project D)

Extreme Programming forces people to communicate frequently. (Project D)

The team had fun and learned a lot at the same time. (Project E)

There was no need for tons of documentation. (Project E)
Version 1.2
87
12/09/2002
81900277
De Paul University

Predictable schedule progress. (Project E)

The architecture was grown incrementally. (Project E)

Tests were written before the code. (Project E)

It allowed the company to have a product that was better at meeting their
expectations while reducing costs and raising the level of quality. (Project F)

Shortened feedback loop. (Project F)

The customer understands their business the best and knows what is needed.
(Project F)

Higher productivity (Project G)

The resources are focused on what is important. The time sensitive issues are
being completed first. (Project G)

Allows for small wins quickly. This builds the team’s and customer’s
confidences. (Project G)
Obstacles
Some obstacles that the respondents found on the various projects include:

Management support was needed.
Since there was no real advocacy from
management, the team did not feel that the new process was that important.
(Project A)

Lack of communication (Project A)

Lack of automated tests (Project A)
Version 1.2
88
12/09/2002
81900277

De Paul University
Members of the development team would reject the practices of Extreme
Programming. (Project B)

Customer accountability (Project B)

Individuals wanted to work odd hours (Project C)

Individuals did not want to perform testing. (Project C)

Disagreements that arose between the pair programmers. (Project D)

The company wanted to have design reviews. (Project E)

It took time to teach the customer how to write effective stories. (Project F)

Training to handle the weaknesses of team members (Project G)

For a maintenance environment, almost every solution required significant
refactoring to allow for test first to occur. Therefore, the refactoring and test first
were only done when it was feasible. (Project G)
Improvements On Next Implementation
Two respondents commented on managements need to be supportive and there needs to
be a focus on short releases. Two respondents also remarked that there should be more
emphasis on pair programming.
The area of testing was a big area for improvement with many respondents. Four
respondents believed that the following areas need to be focused on:

Acceptance tests can be more generalized.

Automated acceptance tests
Version 1.2
89
12/09/2002
81900277

De Paul University
The whole practice of testing needs to be a consistent part of the development
cycle. There should be more unit tests and the customer should be testing more
often.

Bring in a seasoned test first person to teach the team techniques for test first.
Some other modifications that respondents would make on subsequent implementations
include:

It would be best to try it when there can be a focus on the process. (Project A)

A dedicated resource is needed to monitor that the process is being followed.
(Project A)

Developers need to recognize their weaknesses. (Project B)

The release plan should be public and kept current. (Project C)

The client should be on board from the beginning. (Project F)

Everyone needs to be present for the planning game. (Project F)

Individuals need to abandon the document everything mentality. (Project F)

Implement the practices one at a time (Project F)

Start with a smaller team. (Project G)

More buy in from the customer. (Project G)
Environments to Not Implement In
Some environments that respondents feel probably should not try implementing Extreme
Programming include:
Version 1.2
90
12/09/2002
81900277

De Paul University
A company where there are multiple teams working together and only one team is
using Extreme Programming. It needs to be an all or nothing situation. (Project
G)

Extreme Programming is not recommended for an environment where there are
too many focuses at once. (Project A)

There needs to be a distinction between new software development and software
maintenance. If these two areas exist within a company, there needs to be a split
or else it will be harder to have Extreme Programming. (Project D)

Another obstacle is that there needs to be organizational buy in to implement the
cultural changes that Extreme Programming advocates. (Project D)

A customer is needed to make Extreme Programming work. (Project E)

Management support is a necessity. (Project E)

If the company does not want to do an agile process, then they should not.
(Project F)
Is Extreme Programming Better?
Knowledge Transfer
Four respondents strongly agreed that Extreme Programming allows for a tremendous
amount of knowledge transfer among team members. The learning curve is accelerated.
Much of this is done through the pair programming practice. This practice has the
Version 1.2
91
12/09/2002
81900277
De Paul University
element of cross training and allows newer developers to sharpen their skills. The senior
developers also learn from the junior developers. The knowledge transfer assists the
team in learning the product quickly. This aids in giving the team the confidence it needs
to be able to change the code and know that they are not breaking something else.
This
practice allows for more code to be done quicker. As Project B noted, an individual
perceived that they had received 3 – 5 years experience at the end of 1 year.
In summation, over half of the respondents agree that Extreme Programming does allow
for team members to learn from each other. Since developers are paired up, they work as
a team and the learning comes as a result of this pairing. Junior and senior developers are
able to sharpen their skills. The other respondents did not make any references to the
aspect of knowledge transfer. It can be concluded that this transfer of knowledge is
beneficial to all involved. Confidence levels are higher and individuals develop a greater
respect for their team members.
Customer Input
Three respondents agreed that customer input was a valuable benefit of Extreme
Programming. The customer is able to prioritize items on a consistent basis. This allows
for flexibility as requirements and needs change. The customer is able to get what they
want, when they want it and has the feeling that he or she is in control. Many customers
are not used to this. Before, they would sit down and describe the requirements up front,
and then wait several months to years for the finished product to be produced. By this
point, the requirements had changed and the product did not fulfill the needs of the
customer. Now, the customer is an integral part of Extreme Programming. The customer
Version 1.2
92
12/09/2002
81900277
De Paul University
knows what they want and why. They can communicate this to the development team.
The customer drives the project and is part of the team.
Also, Project F started out with creating the requirements by BDUF (big design up front).
The delivery date was arbitrarily set. When the team came in, they knew that the date
could not be met. They proved it with Extreme Programming. With other processes, it is
very likely to have schedule overruns.
With Extreme Programming, the development team is communicating with the customer.
As with any project, issues and obstacles come up. When they do, the team can discuss
these openly and honestly. The customer is then able to adjust the requirements and
reprioritize. The schedule is predictable because everyone is in the know. It is a win-win
situation.
In summation, half of the respondents found that customer input was vital to a project.
The other respondents did not comment on customer input. In the Waterfall model, the
customer gives the requirements at the start of the project. They usually do not have
anymore input until the development is complete. With Extreme Programming, the
customer is constantly involved. They are making decisions daily. The author believes
that this control is another important factor in the success of the project. The customer
knows what is being developed and is able to correct any misunderstandings early on.
Version 1.2
93
12/09/2002
81900277
De Paul University
Increased Productivity
Project G proved to be the best at quantitatively proving that Extreme Programming was
better than the Waterfall methodology. It showed that in comparison to the previous
Waterfall process that was in place, there was a definite improvement in productivity. It
showed that productivity doubled.
It can be concluded that if more projects would perform metrics, we would have a better
idea if productivity does increase for projects that use Extreme Programming. Project G
shows that productivity is doubled compared to the Waterfall model. This is a bonus for
many companies who are trying to make their resources more productive. As Extreme
Programming becomes more widely used, more companies will probably perform the
metrics to determine if productivity does increase. If these figures prove to be true,
Extreme Programming would have quantitative support that would convince others to
adopt the process.
Increased Quality
Project G also proved to be the best at quantitatively proving that Extreme Programming
increased product quality. It showed that in comparison to the previous Waterfall process
that was in place, there was a definite improvement in quality. It showed that the
number of defects was reduced to one tenth the original levels. Project C also found that
the defect count was lower. This was not backed up with any numbers or statistics.
In summation, the defect counts need to be measured for Extreme Programming projects
and compared to some previous process defect metric. Fewer defects translates to
Version 1.2
94
12/09/2002
81900277
De Paul University
happier customers. Again, as Extreme Programming becomes more widely used, more
companies will probably perform the metrics to determine if quality does improve for
projects using it. If these numbers prove to be true, Extreme Programming could have
more quantitative support to convince others to adopt the process.
Improved Communication
Five of the respondents commented on communication. Extreme Programming fosters
communication. In too many projects, the main reason for failure is lack of
communication. Extreme Programming forces the team to communicate often. This is
done with planning meetings and pair programming. Communication is also occurring
through the code. The code is simple. If everyone is communicating and fulfilling their
responsibilities, there is no need to play the blame game. This is why communication is a
constant thread throughout Extreme Programming. It is one of the keys as to why people
like it so much.
Project A believed that part of the failure could be linked back to the poor
communication that occurred on the project. Project F started out with poor
communication, but once the customer was on board, the project turned around. Project
D’s respondent believes that Extreme Programming forces communication frequently.
In summation, seventy percent of the correspondents feel that communication should be a
natural event in all software development. Unfortunately, it is not. In the author’s
experience, it has been seen on projects where no one really knows what is happening.
For example, the deployment date could be different for each person that is asked. When
Version 1.2
95
12/09/2002
81900277
De Paul University
there is a breakdown in communication, requirements are often coded incorrectly. This
leads to dissatisfied customers and unhappy developers.
Improved Team Morale
Three of the projects commented on the team morale or attitude. They found it to be
better at the end of the project. Team members had more self confidence in themselves.
They had gained a greater respect for their teammates. Individuals also experienced a
greater level of personal growth. Team morale is an important element. It affects how
people approach their work.
The attitude of each team member affects the other
members. The attitude can make or break a team and a project. Project B focused on the
personal growth that the individuals achieved. They had matured as individuals. Project
E also commented on the fact that the team had fun. Work is more enjoyable when it can
be fun.
In summation, half of the respondents feel that team morale is another important issue in
software development. The other respondents did not have any comments on this area.
When team morale is high, developers are productive. They care about their work. They
want to do a good job. Everyone wants to go the extra mile. When developers reflect a
negative attitude, they bring down the rest of the team and the project.
Summing It Up
Extreme Programming has many benefits. Many of the above were qualitative and
subjective to the respondents. However, the subjective views are very strong that
Extreme Programming is better than Waterfall. It allows for software to be developed
Version 1.2
96
12/09/2002
81900277
De Paul University
quickly. The quality and productivity of the team is higher. The team learns from one
another. The team morale is higher. The customer is a part of the decision making
process. Communication is forced to happen. Everyone who needs to know should
know. It is a win-win situation for all involved.
This does not prove beyond a doubt that Extreme Programming is better than the
Waterfall methodology. There needs to be more quantitative studies done. Since
Extreme Programming is just starting to take hold in the development community, many
projects have not done this type of analysis. Extreme Programming may in 10 years end
up like RAD. “After studying the RAD methodology, it has been determined that it has
not delivered on any of its promises of increased productivity, etc.” [6]
Is Extreme Programming Easy to Implement?
It cannot be said definitively whether or not Extreme Programming is easy to implement.
There are too many factors that can decide whether it is easy or difficult. The surveys
were split down the middle on this issue. Three respondents thought it was easy to
implement and the other three thought it was difficult. Project C’s respondent believed
that it was easy and difficult at different times in the project. Why the discrepancy? This
is easy. People are involved. People have thoughts, opinions, and attitudes that effect
how well Extreme Programming is accepted and embraced. However, there are other
variables that play into how easy it is to implement Extreme Programming.
Version 1.2
97
12/09/2002
81900277
De Paul University
People Factor
Extreme Programming focuses on people. People are treated like people. They are not
just resources. This is one area that makes Extreme Programming different, yet difficult.
Every person is different. Yet, when you are a part of an Extreme Programming team,
you need to learn to get along with others. You need to be able to work as a team.
People are allowed to be creative and individuals, while at the same time be a part of the
team. Several projects have commented on how people have matured since using
Extreme Programming. Project B believed that there was a great deal of personal growth
that occurred. Also, people gain a higher degree of self-confidence in themselves.
People become better people.
Project D also focused on the people factor. Each team consists of different personalities.
These personalities make up the chemistry of the team. It takes the right type of
chemistry for a team to succeed. Emotions can run high at times. People need to take
notice and adjust. There also needs to be some way of resolving disagreements. The
most important item is that people need to work together and communicate.
Communication needs to be honest – whether it is good or bad. The team needs to be
aware of any obstacles or issues so that they can be resolved. The team needs to respect
each other so that the communication can be open and honest.
In summation, over half of the respondents agree that people are the one of the keys to
success for a project. The other respondents did not focus on this aspect. People have
feelings, thoughts, and opinions. If the right chemistry exists, the team can be successful.
They need to work together. Extreme Programming encourages people to be treated as
Version 1.2
98
12/09/2002
81900277
De Paul University
people. The author has had the experience to work in both an Extreme Programming and
Waterfall environments. The author finds that Extreme Programming encourages the
respect of individuals. It allows them to be creative. It allows them to have a say in the
software development.
Testing
Another bonus with Extreme Programming is the testing practice. Extreme Programming
classifies testing as either unit or functional. The programmer performs the unit testing.
This is also referred to as test first. The customer performs the functional testing.
Four respondents agreed that on a subsequent implementation, they would improve the
area of testing. Testing and code writing go hand in hand for Extreme Programming.
With other traditional methodologies, testing is an area that is often left to the end of the
project when it is very costly to find defects. Extreme Programming advocates writing
tests first. Then, code to the tests. It is even better when the tests are automated. The
developers just need to press a button and the tests are ran. If they are successful, the
developer can move on. Otherwise, they are aware of the issues while the code is fresh in
their minds.
The test first philosophy causes a shift in mindset. Developers need to change their
attitudes. They need to make testing a part of the code development. Also, people need
to determine what are the appropriate ways to test the software and when are there
enough tests. This can be difficult for someone who is not used to writing tests.
Version 1.2
99
12/09/2002
81900277
De Paul University
In summation, over half of the respondents agree that testing is one of the more important
practices of Extreme Programming, even though it is difficult to implement. The other
respondents did not comment on this aspect. Testing the software early on helps to flush
out the defects when they are often easier to fix. However, it is difficult to change the
mindset to test first. The test first practice needs to be rehearsed and individuals need to
be reminded when they forgo this practice. This reminder can help them to try to make
test first a habit.
Refactoring
Refactoring assists in simplifying code. It makes it easier for others to understand.
However, refactoring is also a hard practice to implement. It took off slowly for Project
C. Project G implemented refactoring where feasible since they were dealing with a
maintenance environment.
In some cases, it proved to be too expensive and time
consuming to do for many defects.
In summation, only 25% of the respondents voiced an opinion regarding refactoring. The
other respondents had no strong thoughts on this practice. Refactoring can be expensive
especially in a maintenance environment. However, it should be done. It makes the code
easier to understand and simpler. It also allows others to be able to easily enhance the
code later. It was noted by two respondents that this practice is difficult to implement.
One reason could be that some people do not like changing code that works. Why
change something that is already working? The answer comes down to
Version 1.2
100
12/09/2002
81900277
De Paul University
understandability. People come and go on projects. They need to be able to understand
the system with little ramp up time.
On Site Customer
The customer needs to be part of the project. Project F showed that the customer is an
important part of the team. The customer is no longer sitting on the sidelines. They are
an active participant and this requires that they learn how to write stories that are easy to
understand and to the point. They also need to write test cases. It is their responsibility
to drive the project. They decide what needs to be done in each iteration. The project
requires that a customer give up time so that they can be a part of the team. If the
customer is not readily on board, this makes the implementation more difficult.
In summation, every project commented that an onsite customer should be involved for
projects. When the customer is present it is easier and quicker to get issues resolved.
When the customer is not present, there is usually some lag time in getting responses.
This can result in a schedule slippage since the developer may need to wait for the
response before development can continue. This can lead to frustration among the team,
management, and the customer.
Simple Design
Extreme Programming focuses on simplicity. The idea behind simplicity is that only
items that need to be developed be developed. The developer is not coding any bells or
whistles into the system. The design is kept simple so that anyone can look at the code
and understand it. This also introduces a great deal of flexibility into the system.
Version 1.2
101
12/09/2002
81900277
De Paul University
Developers know that the code can be changed and know that it still works. This is
because the system has a suite of tests to support the code and ensure that it works.
Developers are then free to move onto other projects. Others can come in and pick up
where they left off very easily. Developers are only coding to make the requirements
work. This helps developers to meet their deadlines, because they know what needs to be
done. Project G brought up many of the above points.
Project C also pointed out that individuals could work on any part of the system because
the code was easy to understand and supported by a large number of tests.
In summation, about 25% of respondents commented on making the design simple. The
other respondents did not comment on this aspect of Extreme Programming. Simple
design makes the code easy for all developers to understand. Since extraneous items are
not coded, the system is meeting the customer’s requirements. Extra features cause for a
more complex system. It can often result in wasted time since these features may never
be used. The author believes that code should be clear and concise. Variables should be
descriptive. Comments around looping structures can also aid in understandability. This
helps developers get up to speed quickly often with little help from others.
Pair Programming
Developers have been independent and coded by themselves. Pair programming has
developers creating code together. This is hard for some developers to adapt to. Project
C agreed that this practice was implemented slowly. Project B advocated that this was a
great practice. It allowed for a greater transfer of knowledge. It was used on Project A to
Version 1.2
102
12/09/2002
81900277
De Paul University
resolve complicated tasks. Project D stated that this practice is hard to implement because
of people’s different personalities. The chemistry between people needs to be right.
Pair programming is a practice that helps developers to create better code. Developers
are able to learn from each other. It forces programmers to give up some of their
independence. Some developers do not like this. This is another practice that requires a
shift in mindset. This is difficult. One solution may be to have developers try the pair
programming concept a few hours a day. This would allow them to get used to the idea.
As the practice becomes habit, the time would increase automatically.
In summation, half of the respondents found that this practice is extremely successful and
useful. The other half found it very difficult to implement. One project did not
implement paired programming since they did not see how the practice could increase
productivity. However, some developers chose to pair up for the more complex tasks.
The author believes that the benefits are strong and evident. Even if the practice is hard
to implement, developers need to take the time to adjust. The result is better code, more
knowledgeable developers, and increased productivity and quality.
Summing It Up
Because of the nature of the types of responses received, only subjective deductions can
be made regarding the ease of implementing Extreme Programming. It is team
dependent. One implementation may be viewed as a success, while the next may be
viewed as unsuccessful. It comes down to the many variables present. People are the
Version 1.2
103
12/09/2002
81900277
De Paul University
most unpredictable. Emotions can run high especially when the stress is high. Changing
the way people think is also difficult. People can become set in their ways. They
become complacent and resistant to change. It is not only people, but business culture
that faces this same problem. The support needs to flow down from the top. The
management and culture need to embrace Extreme Programming. From there, it should
be easy to implement.
This is one statement that is matter of opinion. For some people, math comes easy to
them. For others it is difficult. The same can be said for implementing Extreme
Program. What one person finds easy, another will find difficult.
Version 1.2
104
12/09/2002
81900277
De Paul University
Future Research
The next step is that more quantitative analysis needs to be done.
Project G had
quantitative measures that supported the claim that Extreme Programming was better. It
proved that productivity doubled. The defect count was reduced to one tenth. More
projects need to perform quantitative analysis to prove beyond a reasonable doubt that
Extreme Programming is better. The issue regarding Extreme Programming being easy
to implement is another story. This appears to be a very subjective statement that is
dependent on several external variables, such as company culture and people. The
validity of this statement warrants more investigation also.
One way to possibly
investigate this further is to statistically analyze what practices are fully implemented and
which are not and why.
Of course, as we all know, there is no one right answer. What works for one company or
project will not always work for the next company or project. As the future of software
development evolves, so will the development processes that assist in creating quality
software for the marketplace.
Version 1.2
105
12/09/2002
81900277
De Paul University
References
[1] Ambler, Scott The Threat of the New Software Development Magazine, December
2001.
[2] Bamberger,J. Essence of the Capability Maturity Model IEEE Computer, Volume 30,
#6 (June 1997), p.112-114
[3] Beck, Kent ExtremeProgramming Explained Embrace Change Addison-Wesley,
2000.
[4] Dribin, Larry Dr., De Paul University, D01 -SE 466 Introduction SE
466_D01_Intro_v1, March 2001
[5] Fowler, Martin and Highsmith, Jim The Agile Manifesto Software Development
Magazine, August 2001.
[6] Howard, Alan. Viewpoint The Communications of the ACM, Volume 45, #10
(October 2002), p.28-29.
[7] Survey Respondents, Private Communication, 2002.
Version 1.2
106
12/09/2002
81900277
De Paul University
Web References
[8] www.martinfowler.com/articles/newMethodology.html
Version 1.2
107
12/09/2002