adopting extreme programming - the benefits and obstacles december 5, 2002 by patricia cleary

Adopting Extreme Adopting Extreme Programming - the Programming - the Benefits and ObstaclesBenefits and Obstacles

December 5, 2002December 5, 2002

By Patricia ClearyBy Patricia Cleary

12/03/2002 Copyright Patricia Cleary Version 1.2

2

AgendaAgenda

HypothesisHypothesis BackgroundBackground AnalysisAnalysis ResultsResults ConclusionConclusion


3

HypothesisHypothesis

– The practices of Extreme The practices of Extreme Programming help to develop Programming help to develop better software systems than the better software systems than the other traditional methodologies other traditional methodologies such as Waterfall.such as Waterfall.

– Extreme Programming is easy to Extreme Programming is easy to implementimplement


4

CommitteeCommittee

Thesis Advisor: Dr. Larry DribinThesis Advisor: Dr. Larry Dribin Thesis Committee: Dr. Larry Thesis Committee: Dr. Larry

Dribin, Dr. Xiaoping Jia, Mr. Hank Dribin, Dr. Xiaoping Jia, Mr. Hank StreeterStreeter


5

BackgroundBackground


6

Why the need for software Why the need for software development processes?development processes?

Build quality softwareBuild quality software On timeOn time On budgetOn budget Meets the customer’s Meets the customer’s

requirementsrequirements


7

Waterfall Process Waterfall Process [Dribin][Dribin]

Requirementsdefinition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance


8

Issues with Waterfall Issues with Waterfall ModelModel

Documentation intensiveDocumentation intensive Requirements must be defined up frontRequirements must be defined up front Customer waits a long time for first Customer waits a long time for first

deliverabledeliverable Lots of overheadLots of overhead Difficult to handle changing requirementsDifficult to handle changing requirements Specifications are hard to validate and useSpecifications are hard to validate and use Complete problem must be defined at start Complete problem must be defined at start

[Dribin][Dribin]


9

Why Agile was DevelopedWhy Agile was Developed

Developed to resolve issues with Developed to resolve issues with WaterfallWaterfall


10

History of AgileHistory of Agile

Several agile processes were Several agile processes were developed during the 1990’sdeveloped during the 1990’s

Group of Agile Developers gathered Group of Agile Developers gathered at lodge in February 2000at lodge in February 2000

Developed Agile ManifestoDeveloped Agile Manifesto Formed Agile Software Formed Agile Software

Development AllianceDevelopment Alliance


11

Agile Manifesto ValuesAgile Manifesto Values

““Individuals and interactions over Individuals and interactions over processes and toolsprocesses and tools

““Working software over Working software over comprehensive documentationcomprehensive documentation

““Customer collaboration over Customer collaboration over contract negotiation.contract negotiation.

““Responding to change over Responding to change over following a plan.” [Agile Manifesto]following a plan.” [Agile Manifesto]


12

Why Agile?Why Agile?

Light weightLight weight People focusPeople focus AdaptiveAdaptive Less Documentation IntensiveLess Documentation Intensive Handles changing requirements Handles changing requirements

betterbetter


13

Why Extreme Why Extreme Programming?Programming?

Adaptable set of guidelinesAdaptable set of guidelines Inexpensive to implement -- no Inexpensive to implement -- no

extra software costs or licensing extra software costs or licensing feesfees

Handles changing requirementsHandles changing requirements Increases productivityIncreases productivity Reduces defect countReduces defect count


14

Extreme Programming Extreme Programming PracticesPractices

Planning GamePlanning Game Small ReleasesSmall Releases MetaphorMetaphor Simple DesignSimple Design TestingTesting Collective Collective

OwnershipOwnership

Pair ProgrammingPair Programming RefactoringRefactoring Continuous Continuous

IntegrationIntegration 40-hour workweek40-hour workweek On-site customerOn-site customer Coding StandardsCoding Standards


15

Research StudyResearch Study

Created survey to determine validity of Created survey to determine validity of hypothesishypothesis

Analyzed the projects based on Analyzed the projects based on background, implementation approach, background, implementation approach, and benefits and costs.and benefits and costs.

Any metrics performed were includedAny metrics performed were included Sent out 20 surveysSent out 20 surveys 7 surveys returned7 surveys returned 6 successful implementations6 successful implementations


16

Survey Response Survey Response DemographicsDemographics

Below results taken from the survey Below results taken from the survey responses [Survey Respondents]responses [Survey Respondents]


17


Project Backgrounds: 3 projects previously Project Backgrounds: 3 projects previously used Waterfall process; 4 projects used used Waterfall process; 4 projects used code and fix approach; 5 companies were code and fix approach; 5 companies were large to mid size; 2 companies were start large to mid size; 2 companies were start upsups

Project Description: 1 maintenance project; Project Description: 1 maintenance project; mix of desktop and web applicationsmix of desktop and web applications

Various industries -- automotive, financial, Various industries -- automotive, financial, securitysecurity


18


Duration: few months to one year; 1 Duration: few months to one year; 1 project lasted 3.5 years; first deliverable project lasted 3.5 years; first deliverable ready at 6 monthsready at 6 months

Systems were mid to large sizeSystems were mid to large size Implementation: 6 projects Implementation: 6 projects

implemented XP all at onceimplemented XP all at once 1 project read Kent Beck’s book and 1 project read Kent Beck’s book and

then discussed; 1 project demonstrated then discussed; 1 project demonstrated practices via a prototypepractices via a prototype


19

ResultsResults


20

XP Practices MatrixXP Practices Matrix

XP Practice Successful Partial Unsuccessful Not ImplementedPlanning Game C, D, E, F, G B ASmall Releases E, F, G A, B, D CMetaphor C, G B, D A, E, FSimple Design A, B, C, D, E, F, GTesting B, C, D, E, F A, GRefactoring B, C, D, E, F A, GPairProgramming

B, C, D, E, F, G A

CollectiveOwnership

B, C, D, E, F, G A

ContinuousIntegration

B, C, D, E, F, G A

40-hour workweek

B, C, E, G A, D F

On-Site Customer C, D, E, F A, B, GCoding Standards B, C, D, E, F, G A


21

AnalysisAnalysis


22

Assessing Difficulty of Assessing Difficulty of ImplementationImplementation


23

Ease of ImplementationEase of Implementation

3 thought it was easy3 thought it was easy 3 thought it was difficult3 thought it was difficult 1 felt it was easy and difficult at 1 felt it was easy and difficult at

timestimes


24

Ideas that Helped Ideas that Helped ImplementationImplementation

5 respondents believed in a supportive 5 respondents believed in a supportive managementmanagement

3 respondents believed in excellent 3 respondents believed in excellent communicationcommunication

2 respondents wanted a focus on 2 respondents wanted a focus on shorter releasesshorter releases

4 respondents wanted more emphasis 4 respondents wanted more emphasis on testingon testing


25

Other Ideas that Helped Other Ideas that Helped ImplementationImplementation

Everyone wanted to do XPEveryone wanted to do XP Lessons learned meetings - able to Lessons learned meetings - able to

enhance processenhance process Iterative development on small tasks Iterative development on small tasks

allows for system to be visible soonerallows for system to be visible sooner Test first and pair programming practices Test first and pair programming practices

allow for transfer of knowledgeallow for transfer of knowledge Practice test first practice as team so Practice test first practice as team so

team develops habit of practiceteam develops habit of practice


26

Ideas that Hampered Ideas that Hampered ImplementationImplementation

Lack of accountability on business Lack of accountability on business sideside

Individuals fought against adopting Individuals fought against adopting XP practicesXP practices

Hard for customer to keep up with Hard for customer to keep up with acceptance test writing or customer acceptance test writing or customer did not write acceptance testsdid not write acceptance tests

Getting the customer involvedGetting the customer involved


27

Ideas that Hampered Ideas that Hampered ImplementationImplementation

Test practice is hard to sustain throughout Test practice is hard to sustain throughout project -- hard to change mindsetproject -- hard to change mindset

Pair programming is difficult because people Pair programming is difficult because people need to get alongneed to get along

Complex architecture and multiple platformsComplex architecture and multiple platforms Lack of communication and automated testsLack of communication and automated tests Disagreements that arose between the pair Disagreements that arose between the pair

programmersprogrammers


28

Other ObstaclesOther Obstacles

Took time to teach the customer how Took time to teach the customer how to write effective stories. to write effective stories.

For a maintenance environment, For a maintenance environment, almost every solution required almost every solution required significant refactoring to allow for test significant refactoring to allow for test first to occur.first to occur.

The company culture was entrenched The company culture was entrenched in the idea of review and approval. in the idea of review and approval. They wanted to have design reviews.They wanted to have design reviews.


29

Is Extreme Programming Is Extreme Programming Better?Better?


30

Measurements PerformedMeasurements Performed

1 project quantitatively measured 1 project quantitatively measured productivity and quality - productivity and quality - Productivity doubled and defect Productivity doubled and defect count was reduced to one tenth count was reduced to one tenth original levelsoriginal levels

Other projects had subjective Other projects had subjective comments that supported Extreme comments that supported Extreme ProgrammingProgramming


31

BenefitsBenefits

Customer decides what is developed whenCustomer decides what is developed when Cross training produced an accelerated Cross training produced an accelerated

learning curve. Team is learning from each learning curve. Team is learning from each otherother

There was a great amount of personal There was a great amount of personal growth and team morale was higher. growth and team morale was higher.

Everyone could at any time see where the Everyone could at any time see where the system was because of continual system was because of continual integration and short release cycles. integration and short release cycles.


32

BenefitsBenefits

XP forces people to communicate XP forces people to communicate frequently through planning game and code.frequently through planning game and code.

Individuals could work on any part of the Individuals could work on any part of the system because the code was easy to system because the code was easy to understand and supported by a large understand and supported by a large number of tests.number of tests.

Shortened feedback loopShortened feedback loop. . Iterations were Iterations were short and the customer was able to respond short and the customer was able to respond to requirements correctnessto requirements correctness..


33

Other BenefitsOther Benefits


34

Increased Productivity & Increased Productivity & QualityQuality

Maintenance project showed Maintenance project showed quantitative measures.quantitative measures.

Productivity was doubledProductivity was doubled Defects were reduced to one tenth the Defects were reduced to one tenth the

original levelsoriginal levels Fewer defects = happier customersFewer defects = happier customers If metrics hold true, then XP would have If metrics hold true, then XP would have

quantitative support to convince othersquantitative support to convince others


35

Knowledge TransferKnowledge Transfer

4 respondents agreed that there is a 4 respondents agreed that there is a tremendous amount of knowledge tremendous amount of knowledge transfertransfer

New developers sharpen skillsNew developers sharpen skills Team learns product quicklyTeam learns product quickly Confidence levels are higherConfidence levels are higher Team members develop greater Team members develop greater

respect for each otherrespect for each other


36

Customer InputCustomer Input

3 respondents agreed that 3 respondents agreed that customer input was a benefitcustomer input was a benefit

Ability to prioritize allows for Ability to prioritize allows for flexibility as requirements changeflexibility as requirements change

Customer knows what is being Customer knows what is being developed and is able to correct developed and is able to correct misunderstandings early onmisunderstandings early on


37

Improved CommunicationImproved Communication

5 respondents commented on the 5 respondents commented on the importance of communicationimportance of communication

Forces team to communicate oftenForces team to communicate often Done via planning meetings, pair Done via planning meetings, pair

programming, and the codeprogramming, and the code Everyone knows what is going on Everyone knows what is going on

and system is visible to everyoneand system is visible to everyone


38

Possible Reasons for Possible Reasons for BenefitsBenefits


39

People FactorPeople Factor

Half of respondents commented on the Half of respondents commented on the people factor in XPpeople factor in XP

Focuses on people; people not treated as Focuses on people; people not treated as resourcesresources

Everyone is different -- hard for everyone Everyone is different -- hard for everyone to always get alongto always get along

There was maturity, personal growth, There was maturity, personal growth, and higher degree of self confidenceand higher degree of self confidence

Encourages respect of peopleEncourages respect of people


40

TestingTesting

Unit testing (programmer) and functional Unit testing (programmer) and functional (customer)(customer)

Tests are written first. Code is written to Tests are written first. Code is written to fulfill tests -- hard to adapt to this philosophyfulfill tests -- hard to adapt to this philosophy

Allows for only what is needed to be codedAllows for only what is needed to be coded Need to determine correct number of testsNeed to determine correct number of tests 4 respondents would improve this area on 4 respondents would improve this area on

another implementationanother implementation


41

On Site CustomerOn Site Customer

All projects believed that the customer All projects believed that the customer is an important part of projectis an important part of project

Need to write effective stories and test Need to write effective stories and test casescases

Customers decide what needs to be Customers decide what needs to be donedone

When customer is present, it is easier When customer is present, it is easier and quicker to get issues resolvedand quicker to get issues resolved


42

Pair ProgrammingPair Programming

Half of respondents agree that practice Half of respondents agree that practice is usefulis useful

The other half found that the practice is The other half found that the practice is hard for some developers to adapt tohard for some developers to adapt to

Allows for transfer of knowledgeAllows for transfer of knowledge People’s personalities determine People’s personalities determine

successfulness of practice successfulness of practice implementationimplementation


43

ConclusionConclusion

Many views were qualitative and subjective Many views were qualitative and subjective to the respondents. to the respondents.

Many views echoed XP doctrine because the Many views echoed XP doctrine because the ideas behind XP are what appeal to ideas behind XP are what appeal to managementmanagement

Does not prove beyond a doubt that Extreme Does not prove beyond a doubt that Extreme Programming is better than the Waterfall Programming is better than the Waterfall methodology. Ease of implementing Extreme methodology. Ease of implementing Extreme Programming is completely subjective. It is Programming is completely subjective. It is team dependentteam dependent. .


44

Conclusion (cont’d)Conclusion (cont’d)

There needs to be more There needs to be more quantitative studies done. quantitative studies done.

XP may in 10 years end up like XP may in 10 years end up like RAD. After studying the RAD RAD. After studying the RAD methodology, it has been methodology, it has been determined that it has not delivered determined that it has not delivered on any of its promises of increased on any of its promises of increased productivity, etc. [Howard]productivity, etc. [Howard]


45

Future ResearchFuture Research

More quantitative analysis needs More quantitative analysis needs to be done to prove that XP is to be done to prove that XP is betterbetter

The claim that it is easy to The claim that it is easy to implement is subjective and implement is subjective and depends on several external depends on several external variables, such as company culture variables, such as company culture and people.and people.


46

SourcesSources

Beck, Kent Beck, Kent ExtremeProgramming Explained ExtremeProgramming Explained Embrace ChangeEmbrace Change Addison-Wesley, 2000. Addison-Wesley, 2000.

Dribin, Larry Dr., De Paul Univerisity, Dribin, Larry Dr., De Paul Univerisity, D01 -SE466 D01 -SE466 Introduction SE 466_D01_Intro_v1Introduction SE 466_D01_Intro_v1, March 2001, March 2001

Fowler, Martin and Highsmith, Jim Fowler, Martin and Highsmith, Jim The Agile The Agile Manifesto Manifesto Software Development Magazine, August Software Development Magazine, August 2001.2001.

Howard, Alan, Howard, Alan, Viewpoint Viewpoint The Communications of The Communications of the ACM, Volume 45, #10 (October 2002), p.28-29the ACM, Volume 45, #10 (October 2002), p.28-29

Survey Respondents, Private Communication, 2002.Survey Respondents, Private Communication, 2002.

adopting extreme programming - the benefits and obstacles december 5, 2002 by patricia cleary

Documents

b adaptive b

b customer

time b

surveys b

budget b

b build quality software

b light weight b people

agile manifesto b