The Common Pitfalls of eXtreme Programming

Adoption and Ways to Avoid Them

Teemu Vainio

Helsinki University of Technology

ttvainio@cc.hut.fi

48353V

Executive Summary

This paper presents some of the common issues software development teams have had

when adopting to eXtreme Programming (XP). The sources for the studies were

different articles and seminar reports that contained handled with the new XP

projects.

Firstly, the XP practices are quite explained in quite straight forward manner.

Then the different case studies are generally compared with the adoption state of the

XP practices. This leads to a conclusion that there seems to be clear distinction

between the difficulties of adoption between different practices.

After this initial presentation of the practices and figures, the troubles are handled in

more detail. What went wrong and why?

Finally, some methods and tools to help the adoption of XP are collected from the

case studies. They are then investigated to some extent and listed with their

applicability to a certain practice of XP.

2

Executive Summary .......................................................................................................2 Abstract ..........................................................................................................................4 1 Introduction............................................................................................................4 2 Extreme programming explained...........................................................................6 3 Adoption of different practices ..............................................................................9

Table 1. Adopted practices by professionals ...................................................12 Table 2. Practice adoption comparison............................................................13

4 Troubles with the practices ..................................................................................14 Table 3. Problems with the practices ...............................................................17

5 Methods to help adoption.....................................................................................18 Table 4. Methods to help adoption ..................................................................20

6 Tools to help adoption .........................................................................................21 Table 5. Available tools for use in XP.............................................................24

7 Summary and conclusions ...................................................................................24 8 REFERENCES ....................................................................................................26

3

Abstract

This paper contains some of the most common pitfalls and ways to try to avoid them

when introducing XP for a software development team. The data was collected from

various articles explaining experiences when using XP in a software engineering

project.

1 Introduction

XP is a agile methodology developed by Kent Beck directed for small development

teams with its’ main goal being the management of change while maintaining the

quality of the product in development (Beck, 1999).

XP looks quite simple on the paper, but implementing the practices (Beck, 1999) has

proved to be quite a big task for many development teams. The different practices are

usually either applied only to some extent or not used altogether. Therefore, it is

important to find out what practices of XP are not so easy to execute in daily work

and why and what could be done to help the adaptation. To define the terminology, by

adaptation I mean that a practice is accepted as a part of daily workflow even after the

initial introduction. By introduction I mean the first few tries of something, when the

excitement is possibly blurring objectivity. This is quite critical for new

methodologies such as XP, since it involves practices that are quite radical and hard to

adapt since they are totally against the mindset of a typical developer (Pelrine, Uhtes

4

& Noack, 2000). Or as Beck (1999, p. 153) himself put it “The XP practices are so

sideways to what we have heard and said and maybe even been successful with in the

past”. That’s why Beck (1999) suggests three steps of adoption:

1. Pick your worst problem

2. Solve it the XP way

3. When it’s no longer your worst problem, repeat.

This paper presents some of the experiences the developers have had

with XP. It includes XP practices that have been found difficult to adopt to and some

of the the ways and tools they have used to counter the problems with the practices.

Since XP is an agile methodology directed for small developer teams, typically about

10 people, I have not studied any cases where that constraint is clearly exceeded. One

should notice that this means teams, not organization.

The research methods used were studying a set of case studies where a development

team was adapting to XP and presented some problems, obstacles, experiences or

improvements. Since XP is new way of software development there are not too many

sources of case studies available. The case studies used were the ones found from the

library of Institute of Electrical and Electronics Engineers (IEEE)

(http://ieeexplore.ieee.org), from XP2001 conference

(http://www.xp2001.org/xp2001/conference/), from XP Agile Universe

(http://www.xpuniverse.com/home), from Association for Computing Machinery

(ACM) Proceedings (http://www.acm.org), from Software Development Magazine

5

(http://www.sdmagazine.com) and from Psychology of Programming Interest Group

(PPIG) (http://www.ppig.org) homepage.

The body of this paper is divided into five major chapters; in the chapter two, I briefly

explain the practices of XP. In the third chapter, I have collected the adoptions of

practices in the cases. In the fourth chapter I have collected the various problems that

have been encountered in the adoption. The last two chapters are, consecutively,

methods and tools that can be used to make transition to XP practices easier.

2 Extreme programming explained

XP is a high discipline based, agile methodology to answer to the common event of

requirements changing even on the final run of the software development. XP is

targeted for small groups of developers (10 or less) and offers a set of practices to

apply to everyday software development. Namely, these are as follows:

1. Planning game

Since the requirements are going to change anyway, the system is planned

together with the customer. Customer will write down (preferably on

cardboard cards) his user stories that will describe a single user story.

Developers will then estimate the time needed to implement each card and

finally the customer can select which of the cards are implemented in the

given timeframe.

6

2. Small releases

This practice is the manifestation of the incremental nature of the XP. The

development team should increase the features conservatively for each release.

3. Metaphors

The development team should invent and deploy metaphors of the system to

promote a common way of the naming and conventions of the system. People

of the project (customer and developers) should use the same language to

understand each other.

4. Simple design

Do only the simplest thing that will provide the given feature and nothing

more. This means that functionality should be isolated in their own

modules/functions/classes so that each piece of code performs as little as

possible.

5. Tests

Testing is divided into two categories; unit testing and acceptance testing.

Unit tests are meant to be implemented before the actual feature. This way the

developer has to think the interfaces and functionalities his class/module is

going to provide. The unit tests should run 100% all the time.

Acceptance tests are specified by the customer to test a specific feature or

sometimes a set of features. When all the acceptance tests have passed for a

given user story that user story is considered done.

7

6. Refactoring

Refactoring is part of the iterative process of making the system simpler. If

some piece of code can be made simpler it should be done. Also any duplicate

code should be taken out.

7. Pair programming

The code is written in pairs. This means that two people sit on the same table

using the same computer writing the same code. The other one can review

while the other pair writes code, and in a tight spot he can help the other one

out.

8. Continuous integration

The code is integrated to a common base at least once a day. All unit tests

should run 100% both before and after the integration.

9. Collective ownership

Everybody owns the code. This means that each developer should be able to

implement anything in the whole system.

10. On-site customer

The representative of customer should be always accessible by the

development team. This means the feedback from the people who will use

system should be immediate.

8

11. 40 hr weeks

No overtime is allowed except as a last resort when one week of overtime can

be allowed.

12. Coding standards

The code must be easily readable by every developer. These makes also sure

that no pair programming conflicts will arise so easily.

13. Open workspace

People should work in the same open environment, not fill up isolated offices.

The main point is, though, that communication should be fluent.

One should note that these practices are evolving all the time and are subject to

change. This means that even new practices can arise and old ones disappear or at

least change their form.

3 Adoption of different practices

The nine different cases are organized in the following activity matrix (Table 1.) to

show the adoption of different practices and the possible note if the practice was not

included in the paper. The different cases are as follows:

• Company A (Grenning, 2001), a software company building new system to

replace existing legacy product. A separate development team wanted to test

something new.

9

• Company B (Huisman, Poole, 2001), and independent software vendor named

Iona Technologies. Problems with code entropy, no clear process for software

development.

• Company C (Gittins, Hope, 2001), a small software development company

with guru-styled solutions leading to unmanageable code. Nine developers,

progressive adaption of XP.

• Company D (Yongqing, Wolff, 2001), a young and dynamic web bank named

EuropeLoan Bank with rapid changing requirements. Technology changing

very fast too.

• Company E (Johansen et al. 2001), a small software company with few

developers, a complete product but problems with schedules and management

of requirements for new versions.

• Company F (Kini, Collins, 2001), a software outsourcing company. Explicitly

mentioned team size, four developers and one tester.

• Company G (Martin, Newkirk, 2000), a small and experienced development

team building a registration system. A need for aggressive process.

• Company H (Pelrine J. 2000 ), a fixed-price software development project.

Need to implement a simulator for pharmaceutical company.

10

• Company I (Morales, 2002), an independent software vendor, Symantec.

Predictability and quality improvement was necessary. Few XP teams located

separately.

Four different adoptions are Not adopted(Red), Partially adopted (Light green),

Adopted (Dark green) and Not included(White) and these are marked with colors

given in parenthesis. Some of the papers left adoption of some practices quite

unclear, so every time there seemed to be some controversy about the matter I left the

box white(Not included). This approach leaves something to hope for and therefore

the value of the Table 1. is not as good as it could be.

11

Table 1. Adopted practices by professionals

A B C D E F G H I Planning game

Partially adopted

Partially adopted

Adopted Adopted Partially adopted

Adopted Adopted Partially adopted

Partially adopted

Small releases

Adopted Adopted Not included

Adopted Adopted Adopted Adopted Not included

Adopted

Metaphors

Not adopted

Adopted Not adopted

Not included

Not included

Not included

Not included

Not included

Not included

Simple design

Adopted Partially adopted

Not adopted

Not included

Adopted Adopted Not included

Not included

Adopted

Tests

Adopted Adopted Not adopted

Not included

Partially adopted

Partially adopted

Adopted Not included

Adopted

Refactoring

Adopted Adopted Partially adopted

Adopted Partially adopted

Adopted Not included

Not included

Partially adopted

Pair programming

Adopted Partially adopted

Partially adopted

Adopted Partially adopted

Partially adopted

Adopted Partially adopted

Adopted

Continuous integration

Adopted Adopted Not included

Not included

Not included

Not included

Not included

Not included

Adopted

Collective ownership

Adopted Adopted Partially adopted

Not included

Not included

Not included

Not included

Not included

Not included

On-site customer

Partially adopted

Adopted Not adopted

Not included

Adopted Not included

Not included

Partially adopted

Partially adopted

40hr week

Adopted Not adopted

Not included

Not included

Adopted Not adopted

Not included

Not included

Not included

Coding standards

Adopted Adopted Not included

Not included

Not included

Not included

Not included

Not included

Not included

Open workspace

Not adopted

Adopted Adopted Adopted Not included

Adopted Not included

Not included

Not included

Table 2. shows all the results gathered from the Table 1. where they are collected,

averaged and sorted in descending order by the adoption. Every adoption is 2 points,

partial adoption is 1 point, not adopted is 0 points and not included means that it is not

included in the calculation. These points are then summed and divided by number of

adopters (N). This means, that the bigger the average, (with maximum of 2 (all

adopted), and minimum of 0(no adoption)) the better the adoption.

12

Table 2. Practice adoption comparison (2=all adopted, 1=half adopted, 0=no

adoption)

Practice Adoption N

Small releases 2,00 7

Continuous integration 2,00 3

Coding standards 2,00 2

Collective ownership 1,67 3

Open workspace 1,60 5

Refactoring 1,57 7

Simple design 1,50 6

Planning game 1,44 9

Pair programming 1,44 9

Tests 1,43 7

On-site customer 1,40 5

40hr week 1,00 4

Metaphors 0,67 3

Interesting point to notice is the quite big divergence of the results. One reason is

likely the fact that Gittins & Hope (2001), for instance, studied the adoption of XP on

a project already started. Other factors can probably be explained by different

company cultures, people from different backgrounds, internal/external projects etc.

Also the fact, that some of the practices were not included, decreasing the N, can

cause misconceptions. Finally, the total amount of case studies used is so small, that

13

no real and mathematically reliable statistics can be applied. Since all these different

factors aren’t handled differently one should use common criticism for the tables

above. Boldly, however, I have used them as a basis for contemplation in the rest of

this paper.

From the data gathered, one could make such assumptions that small releases,

refactoring, open workspace, collective ownership, planning game, simple design,

continuous integration, pair programming, and coding standards were the most

adopted practices. I find the fact that planning game was so well adopted perhaps the

most surprising. That cannot even be explained by the different motivators of internal

customers (Johansen et al. 2001) since the best adoptions came from the companies

with external customers. Perhaps the conservative approach to software engineering is

truly approaching its demise even from the customer’s point of view.

The hardest practices to adopt were metaphors, 40hr week, on-site customer and

testing. Still testing got surprisingly big adoption considered its nature of flipping the

software development upside down. Possibly people have noticed the increased

reliability of the system when the tests were implemented.

4 Troubles with the practices

One of the most common troubles with XP seems to be the introduction of writing the

test code first and the actual function code afterwards. It seems that in people’s minds

there are psychological barriers and uncertainty of one’s ability to work in this

seemingly backwards manner (Johansen et al. 2001).

14

Metaphors were hard to adopt perhaps since people didn’t quite understand its

meaning and motivation (Gittins, Hope, 2001). Also it seems that a formulation of a

common language for all to understand is not easy and needs time to evolve

(Grenning, 2001). What I found interesting was the fact that overtime was so

common. It seems that the adoption of different practices leads to overtime, since time

is spent learning XP. On the other hand at least one company culture almost

demanded overtime, since otherwise the team could be said as not being committed

(Johansen et al. 2001).

Planning game was quite well adopted through out the professional teams, but the

management seemed to be one of the biggest obstacles (Grenning, 2001). Honestly,

developers and customers writing requirements on cards and switching them around

looks rather silly and perhaps even unprofessional.

Deadline pressure seem to give its own effect on the refactoring, (Yongqing, Wolff

2001) since when the deadline approaches, refactoring is easily forgotten. This can

easily lead to messy and badly manageable code.

There seems to be trouble to have the customer on-site also. This probably is a

financial issue, since one customer spending time with the development team can be

considered as a lost resource and therefore it needs quite brave executives from the

customer’s side to allow this.

15

Coding has always been more or less a personal thing for developers. You use your

own tools, your own wits and produce modules. True, you are a part of a collective,

but still the actual development is your own art. Therefore some people are naturally

not receptive of pair programming. The studies show that those who are not repetitive

will not “buy” the pair programming no matter what.

Open workspace is usually adopted well but not co-located offices can cause

problems especially if people do not have a common way of communication between

the offices.

16

Table 3. Problems with the practices

Practice Problem(s)

Planning game • Lack of belief from management

• Hard to evaluate the velocity at

the beginning

Unit tests • Intrinsic opposition to working

“backwards” manner

Metaphors • Motivation and meaning not clear

• Not so easy to develop a common

language for all participants

Refactoring • Deadline causes slips from

clearing and refactoring one’s

code

Customer on-site • Cost

40hr weeks • Management can see this as a lack

of commitment

Pair programming • Some people will just not do it, no

matter what

Open workspace • Offices can be separate;

communication is not fluent

17

5 Methods to help adoption

Generally, it seems that a bit by bit adaptation cannot be underlined enough. It is a

major factor to make sure that the XP practices will make their way into development

teams. This is what Beck (1999) has said in his book and it is clear from the cases too.

Interesting paper from Collins and Miller (2001) describes a meta-process to guide the

adaption of XP. It uses the three maturity levels of XP introduced by Beck, namely

XP (out of the box), adaptation, transcendence, and then states that reaching the final

level as fast as possible is not the most important thing. The most important thing is to

move only when needed. This is quite well put in the paper (Collins, Miller, 2001) as

follows: “... the team should adapt the process from within to produce the best

possible results. Nothing drains a team more than having change dictated to it.”

One issue that arised was the need for someone to tutor the unit testing practice

(Johansen, Stauffer & Turner 2001). This means that the tutor should definitely be

more than a coach. He should know good tools and methods to implement the unit

testing and acceptance tests. Also training for all affected staff, even including the

executives is suggested (Griffin 2001) for better XP adoption in an organization.

The tutoring specified in the previous paragraph can be extended to include even the

customer. The customer can be quite lost and confused when the developer team starts

laying out cards. It seems quite clear, that in the beginning the customer should also

be taught about the unorthodox-like ways of XP.

18

If pair programming just doesn’t seem to sit on the development team, consider

extensive code reviews with emphasis also on strict coding conventions and design

the bug fixes beforehand. Also one thing to keep in mind in pair programming is to

teach more than just coding. If the pair is not familiar with the versioning control

system, that should be taught as well.

The customer not on-site can be solved by several ways. Since the motivator for

customer on-site is the immediate feedback of the user of the system, development

teams can use a proxy for customer. This proxy can be from the sales department with

deep knowledge of the client needs. This alongside with demo workshops and

meetings with the actual customer seem to provide enough customer interaction to

provide good results.

To help the adoption of coding standards, use templates for source code. These

templates can include an example frame of class or function with example

commenting and convention of the source code.

For helping the planning game, short iterations, 40hr weeks the customer should be

convinced of the “big bugs as one story”-approach as suggested by Beck and

Fowler(2000). This can be, though, more easily said than done, since it can be hard

for customer to get the hang of using his “credits” on mistakes other people have

made and shouldn’t be present in the first place.

19

Refactoring can be made easier by specifying explicit refactoring weeks rather than

trusting that people will recfactor the code implicitly while developing and

implementing tasks from the planning game.

Also for planning game and dealing of tasks, some ground rules can be set. For

instance if a developer fails to deliver a story, he may not sign for it in the next

iteration. Being strict and following the deliveries of the developers will keep the

velocity of each person aligned with his tasks.

Table 4. Methods to help adoption

Practice Method(s)

Refactoring • Explicit refactoring days/weeks

Planning game • Big bug as a story

• Rules for choosing tasks, monitor

velocity

Coding standards • Code templates

Customer on-site • Customer proxy

• Demo sessions often

All • Extensive tutoring to all levels of

organization interacting with XP

with an experienced tutor.

Pair programming • Code reviews

• Design the fixes

• Strict code conventions

20

6 Tools to help adoption

Adoption of new processes and methodologies are easier to conduct if there are

enough supportive and automating tools available. Even though XP is such a young

agile process model; there are already some tools for the XP developer.

For the unit testing practice there exists lots of frameworks to speed up the

development and automation of testing. JUnit (http://www.junit.org) was used in

many places (Kini & Collins 2001)(Morales 2002) JUnit provides a Java unit testing

framework which can be used to automate the unit testing. A C++ port of this tool is

also available called CPPUnit (http://sourceforge.net/projects/cppunit/). Other testing

tools mentioned in the cases were HTTPUnit (http://www.httpunit.org) and scripting

languages such as Perl and Python. It seems that these testing frameworks played a

large part in adaption of unit testing, since they were used almost universally, and

make the writing of the test cases and executing them easier. Of course, depending on

the context and technology people should pick their test tools carefully. For instance

on projects already started, the testing practice can be hard to apply retrospectively

even with proper tools (Gittins, Hope 2001).

Automating the UI testing can be a problem, but there seems to exist a some tools for

that purpose too. In one case (Dunsmore et al., 2001) Rational’s

(http://www.rational.com) ClearQuest

(http://www.rational.com/products/clearquest/index.jsp) was used for defect tracking

21

and Segue’s (http://www.segue.com) SILK

(http://www.segue.com/html/s_solutions/silk_s_family.htm) was used to create scripts

to perform end-to-end testing of the system. Then a tool from NuMega

(http://www.numega.com) called TrueCoverage

(http://www.numega.com/products/cover/tc_java.shtm) is used to see how much the

test code coverages the application programming interfaces. Rational Robot

(http://www.rational.com/products/robot/index.jsp) is also a tool, which can be used

to automate the end-to-end testing of a system. Using all these different tools a high

coverage, totally automated testing process can be built. This will clearly make the

testing process more easier, faster and funnier to deploy.

For refactoring there was at least one tool available. This tool is called Codemorpher

for Java (http://www.xptools.com/?doc=products) and it claims to automate the

restructuring, cleaning up and making the code more readable. In no case studies were

any refactoring-specific tool mentioned, but it is easy to see the added value of at least

partly automated refactoring. Interesting way of refactoring analysis was though

mentioned in one case (Kini & Collins 2001) where a source code analysing software

was used. This software was JavaNCSS

(http://www.kclee.com/clemens/java/javancss) and it generates metrics from the

source code automatically. These metrics, including non commented source

statements, cyclomatic complexity number, count of packages, classes, functions and

inner classes (all for global, class and function-level scope) can then be used in

analysis to find out code that needs refactoring or more tests.

22

Continuous integration and small releases need a robust and effective versioning

control system. Version control is not a new thing, and there are plenty of these tools

in the market. In the studies, open source CVS (http://www.cvshome.org/) was

mentioned and Source Integrity from Mortice Kern Systems (http://www.mks.com).

An interesting tool that was mentioned in a paper from Lippert et al. (2001) was

called JWAM IntegrationServer. It is a tool especially developed for XP use. It

combines the unit testing practice and short integration cycles. There are of course

many others not mentioned in the studies, such as Visual Sourcesafe from Microsoft

(http://www.microsoft.com).

Coding standards are hard to set in place without an automated watchdog. This kind

of a system will point out slips from the standards and the developer can gradually

learn the standard thoroughly. There are some such tools available such as Jtest and

CodeWizard from Parasoft (http://www.parasoft.com) which were mentioned in the

cases.

For planning game there are no specific tools, but one can be innovative and use all

kinds of different reporting and documentation systems to move the game from

analog to digital. This can be an issue in workplaces, where the customer and/or the

superiors find it hard to start playing around with cardboard stories. The semantics

will be the same, though.

Since the development team can work different locations an easy and fast way of

collective communication should be available. In the cases no specific tool was

explicitly mentioned. For these purposes there are quite a few options available. From

23

Microsoft (http://www.microsoft.com) a specific tool for the purpose is MSN

Messenger. This tool can take advantage of live video feed and audio. Sometimes

there is too little bandwidth and a simpler tool is needed. For this purpose Internet

Relay Chat (IRC) can be used. This allows people to create channels where to

communicate. ICQ (http://www.icq.com) works on the same basis, but is more

advanced.

Table 5. Available tools for use in XP

XP Practice Tool

Unit testing / Acceptance testing JUnit, HTTPUnit, CPPUnit, script

languages such as Perl and Python,

Rational Robot, NuMega’s

TrueCoverage, Segue’s SILK

Refactoring Codemorpher for Java, JavaNCSS

Continuous integration CVS, Visual Sourcesafe, Source

Integrity, JWAM IntegrationServer

Coding standards Jtest, CodeWizard

Open workspace / Communication MSN Messenger, IRC, ICQ

7 Summary and conclusions

XP is an agile methodology adaptive to the change of requirements and is meant for

small development teams. The cases seem to express that the practices are not so easy

to adopt with just a snap of fingers and an experienced coach with initial coaching

24

tutor is necessary. Most of the studies show that some modifications for the practices

are made to support the adoption.

Overall, I think, companies adopting XP did quite well. The adoption of practices was

much higher than one would expect when getting familiar with the XP for the first

time. Of course, if those practices that were not mentioned in the studies are

considered not adopted the situation can be said to be quite different.

Tools are also very important to provide support and frames for XP. For example, the

unit testing practice is very laborious task to perform without any framework.

Therefore, it seems, most of the studies gave examples of different tools set in place

to help the adoption.

A positive finding and perhaps a signal of the emerging maturity of XP can be said to

be the presence of the various tools to provide support for the different XP practices.

Especially since most of the tools are developed just for the XP.

I found some interesting things while writing this paper; First of all, there is still a big

lack of case studies available of XP adoptions. The few available aren’t too good to

use for comparisons since the industry of the companies, motivator for XP and

different maturities vary so much. Therefore some common way of making these

cases to “stand on the same line” would be more than welcome to help assessment of

adoption of XP.

25

This paper presents the common problems that different teams and companies have

encountered and the various cures they have used to tackle these i.e. killing the

symptoms, but not perhaps the disease. For the future it would be interesting to find

out what actually leads to the problems and try to find out common denominators and

preventives to make the adoption of practices proceed without woe. This means

studying of job culture, different nationalities of people, education of people etc.

Finally, the causality between the adoption level of XP and the project successes

would also be an interesting issue to study. Are some of the practices clearly “the life

veins” of XP-projects, and will failing in them probably lead to failure in the project

too?

8 REFERENCES

2nd International Conference on eXtreme Programming and Flexible Processes in

Software Engineering [Online], Available at:

http://www.xp2001.org/xp2001/conference/ [2002, March 12].

Association for Computer Machinery homepage [Online], Available at:

http://www.acm.org

Beck, K. 1999, eXtreme Programming Explained: Embrace Change, Addison-

Wesley

26

Beck, K., Fowler, M. 2000, Planning Extreme Programming, Addison-Wesley

Collins, C. T., Miller, R. W. 2001, ‘Adaptation: XP Style’, XP2001

Conference, Italy, Sardinia, [Online], Available at:

www.xp2001.org/xp2001/conference/papers/Chapter13-Collins+alii.pdf

[2002, March 10].

Dunsmore K., Wiemann C., Wolosin G. 2001, ‘A Practical Application of XP’,

XP2001 Conference, Italy, Sardinia, [Online], Available at:

www.xp2001.org/xp2001/conference/papers/Chapter27-Dunsmore+alii.pdf

[2002, March 11].

Grenning, J. 2001, ‘Launching Extreme Programming at a Process-Intensive

Company’, IEEE Software, November/December, pp. 27-33

Griffin, L. A. 2001, ‘A Customer Experience: Implementing XP’

XP Universe Conference, Raleigh, NC, [Online],

Available at: http://www.xpuniverse.com/2001/pdfs/XPU01.pdf [2002, March

11].

Gittins, R., Hope, S. 2001, ‘A study of Human Solutions in eXtreme Programming’,

[Online], Available at: http://www.ppig.org/papers/13th-gittins.pdf [2002,

March 10].

27

HTTPUnit, a testing framework, emulating browser behavior, homepage, [Online],

Available at: http://www.httpunit.org [2002, March 10].

Huisman, J.W., Poole, C. 2001 ‘Using Extreme Programming in a Maintenance

Environment’, IEEE Software, November/December, pp. 42-50

Institute of Electrical and Electronics Engineers homepage [Online], Available at:

http://ieeexplore.ieee.org [2002, March 16].

Johansen, K., Stauffer R., Turner D. 2001, ‘Learning by Doing: Why XP Doesn’t

Sell’, XP Universe Conference, Raleigh, NC, [Online],

Available at: http://www.xpuniverse.com/2001/pdfs/XPU01.pdf [2002, March

11].

JUnit, a Java testing framework homepage, [Online], Available at:

http://www.junit.org [2002, March 15].

Kini, N., Collins, S. 2001, ‘Steering the Car: Lessons Learned from an Outsourced

XP Project’, XP Universe Conference, Raleigh, NC, [Online],

Available at: http://www.xpuniverse.com/2001/pdfs/XPU03.pdf [2002, March

11].

Lippert M., Roock S., Tunkel R., Wolf H. 2001, ‘Stabilizing the XP Process Using

Specialized Tools’ , XP2001 Conference, Italy, Sardinia, [Online], Available

28

at: http://www.xp2001.org/xp2001/conference/papers/Chapter9-

Lippert+alii.pdf [2002, March 15].

Martin, R. C., Newkirk J. 2000 ‘Extreme Programming in Practice’, OOPSLA

Companion, Minneapolis, Minnesota, United States, pp. 25-26 [Online],

Available at: http://delivery.acm.org/10.1145/ 370000/367909/p25-

newkirk.pdf?key1=367909&key2=6445435101&coll=portal&

dl=ACM&CFID=1769491&CFTOKEN=67865367 [2002, March 15].

Morales, W. A. 2002 ’Going to Extremes’, Software Development Magazine, January

[Online] Available at: http://www.sdmagazine.com/documents/s=2279/

sdm0201a/ [2002, March 15].

NuMega, a subsidiary of Compuware Corp [Online], Available at

http://www.numega.com [2002, March 10].

Pelrine, J. 2000 ‘Modelling infection scenarios – a fixed-price eXtreme Programming

success story’, OOPSLA Companion, Minneapolis, Minnesota, United States,

pp. 23-24 [Online], Available at: http://delivery.acm.org/10.1145/370000/

367907/p23-pelrine.pdf?key1=367907&key2=1006435101&

coll=portal&dl=ACM&CFID =1769491&CFTOKEN=67865367 [2002,

March 15].

Pelrine, N., Uhtes, R., Noack, C. 2000, ‘Why it is hard to learn eXtreme

Programming?’, Daedalos International, [Online],

29

Available at: http://www.daedalos.com/DE/DOWNLOAD/

eXtreme-Programming/whyIsItHardToLearnXP_NOD2000.pdf [2002, March

15].

Psychology of Programming Interest Group homepage [Online], Available at:

http://www.ppig.org [2002, March 10].

Rational Software Corporation web site [Online], Available at:

http://www.rational.com [2002 March 10].

Segue Software Inc web site [Online], Available at:

http://www.segue.com [2002, March 10].

Software Development Magazine homepage [Online], Available at:

http://www.sdmagazine.com [2002, March 29].

XP Agile Universe homepage [Online], Available at:

http://www.xpuniverse.com/home [2002, March 17].

Yongqing, Y., Wolff, W. 2001 ‘A great challenge: XP in a typical dot-com’, XP2001

Conference, Italy, Sardinia, [Online], Available at:

http://www.xp2001.org/xp2001/conference/papers/

Chapter31-Yongqing+alii.pdf [2002, March 15].

30