1. Adopting Extreme Programming - the Benefits and Obstacles December 5, 2002 By Patricia Cleary

2. 12/03/2002Copyright Patricia Cleary Version 1.2 2 Agenda b Hypothesis b Background b Analysis b Results b Conclusion

3. 12/03/2002Copyright Patricia Cleary Version 1.2 3 Hypothesis –The practices of Extreme Programming help to develop better software systems than the other traditional methodologies such as Waterfall. –Extreme Programming is easy to implement

4. 12/03/2002Copyright Patricia Cleary Version 1.2 4 Committee b Thesis Advisor: Dr. Larry Dribin b Thesis Committee: Dr. Larry Dribin, Dr. Xiaoping Jia, Mr. Hank Streeter

5. 12/03/2002Copyright Patricia Cleary Version 1.2 5 Background

6. 12/03/2002Copyright Patricia Cleary Version 1.2 6 Why the need for software development processes? b Build quality software b On time b On budget b Meets the customer’s requirements

7. 12/03/2002Copyright Patricia Cleary Version 1.2 7 Waterfall Process [Dribin]

8. 12/03/2002Copyright Patricia Cleary Version 1.2 8 Issues with Waterfall Model b Documentation intensive b Requirements must be defined up front b Customer waits a long time for first deliverable b Lots of overhead b Difficult to handle changing requirements b Specifications are hard to validate and use b Complete problem must be defined at start [Dribin]

9. 12/03/2002Copyright Patricia Cleary Version 1.2 9 Why Agile was Developed b Developed to resolve issues with Waterfall

10. 12/03/2002Copyright Patricia Cleary Version 1.2 10 History of Agile b Several agile processes were developed during the 1990’s b Group of Agile Developers gathered at lodge in February 2000 b Developed Agile Manifesto b Formed Agile Software Development Alliance

11. 12/03/2002Copyright Patricia Cleary Version 1.2 11 Agile Manifesto Values “Individuals and interactions over processes and tools “Working software over comprehensive documentation “Customer collaboration over contract negotiation. “Responding to change over following a plan.” [Agile Manifesto]

12. 12/03/2002Copyright Patricia Cleary Version 1.2 12 Why Agile? b Light weight b People focus b Adaptive b Less Documentation Intensive b Handles changing requirements better

13. 12/03/2002Copyright Patricia Cleary Version 1.2 13 Why Extreme Programming? b Adaptable set of guidelines b Inexpensive to implement -- no extra software costs or licensing fees b Handles changing requirements b Increases productivity b Reduces defect count

14. 12/03/2002Copyright Patricia Cleary Version 1.2 14 Extreme Programming Practices b Planning Game b Small Releases b Metaphor b Simple Design b Testing b Collective Ownership b Pair Programming b Refactoring b Continuous Integration b 40-hour workweek b On-site customer b Coding Standards

15. 12/03/2002Copyright Patricia Cleary Version 1.2 15 Research Study b Created survey to determine validity of hypothesis b Analyzed the projects based on background, implementation approach, and benefits and costs. b Any metrics performed were included b Sent out 20 surveys b 7 surveys returned b 6 successful implementations

16. 12/03/2002Copyright Patricia Cleary Version 1.2 16 Survey Response Demographics b Below results taken from the survey responses [Survey Respondents]

17. 12/03/2002Copyright Patricia Cleary Version 1.2 17 Survey Response Demographics b Project Backgrounds: 3 projects previously used Waterfall process; 4 projects used code and fix approach; 5 companies were large to mid size; 2 companies were start ups b Project Description: 1 maintenance project; mix of desktop and web applications b Various industries -- automotive, financial, security

18. 12/03/2002Copyright Patricia Cleary Version 1.2 18 Survey Response Demographics b Duration: few months to one year; 1 project lasted 3.5 years; first deliverable ready at 6 months b Systems were mid to large size b Implementation: 6 projects implemented XP all at once b 1 project read Kent Beck’s book and then discussed; 1 project demonstrated practices via a prototype

19. 12/03/2002Copyright Patricia Cleary Version 1.2 19 Results

20. 12/03/2002Copyright Patricia Cleary Version 1.2 20 XP Practices Matrix

21. 12/03/2002Copyright Patricia Cleary Version 1.2 21 Analysis

22. 12/03/2002Copyright Patricia Cleary Version 1.2 22 Assessing Difficulty of Implementation

23. 12/03/2002Copyright Patricia Cleary Version 1.2 23 Ease of Implementation b 3 thought it was easy b 3 thought it was difficult b 1 felt it was easy and difficult at times

24. 12/03/2002Copyright Patricia Cleary Version 1.2 24 Ideas that Helped Implementation b 5 respondents believed in a supportive management b 3 respondents believed in excellent communication b 2 respondents wanted a focus on shorter releases b 4 respondents wanted more emphasis on testing

25. 12/03/2002Copyright Patricia Cleary Version 1.2 25 Other Ideas that Helped Implementation b Everyone wanted to do XP b Lessons learned meetings - able to enhance process b Iterative development on small tasks allows for system to be visible sooner b Test first and pair programming practices allow for transfer of knowledge b Practice test first practice as team so team develops habit of practice

26. 12/03/2002Copyright Patricia Cleary Version 1.2 26 Ideas that Hampered Implementation b Lack of accountability on business side b Individuals fought against adopting XP practices b Hard for customer to keep up with acceptance test writing or customer did not write acceptance tests b Getting the customer involved

27. 12/03/2002Copyright Patricia Cleary Version 1.2 27 Ideas that Hampered Implementation b Test practice is hard to sustain throughout project -- hard to change mindset b Pair programming is difficult because people need to get along b Complex architecture and multiple platforms b Lack of communication and automated tests b Disagreements that arose between the pair programmers

28. 12/03/2002Copyright Patricia Cleary Version 1.2 28 Other Obstacles  Took time to teach the customer how to write effective stories.  For a maintenance environment, almost every solution required significant refactoring to allow for test first to occur.  The company culture was entrenched in the idea of review and approval. They wanted to have design reviews.

29. 12/03/2002Copyright Patricia Cleary Version 1.2 29 Is Extreme Programming Better?

30. 12/03/2002Copyright Patricia Cleary Version 1.2 30 Measurements Performed b 1 project quantitatively measured productivity and quality - Productivity doubled and defect count was reduced to one tenth original levels b Other projects had subjective comments that supported Extreme Programming

31. 12/03/2002Copyright Patricia Cleary Version 1.2 31 Benefits b Customer decides what is developed when b Cross training produced an accelerated learning curve. Team is learning from each other b There was a great amount of personal growth and team morale was higher. b Everyone could at any time see where the system was because of continual integration and short release cycles.

32. 12/03/2002Copyright Patricia Cleary Version 1.2 32 Benefits b XP forces people to communicate frequently through planning game and code. b Individuals could work on any part of the system because the code was easy to understand and supported by a large number of tests. b Shortened feedback loop. Iterations were short and the customer was able to respond to requirements correctness.

33. 12/03/2002Copyright Patricia Cleary Version 1.2 33 Other Benefits

34. 12/03/2002Copyright Patricia Cleary Version 1.2 34 Increased Productivity & Quality b Maintenance project showed quantitative measures. b Productivity was doubled b Defects were reduced to one tenth the original levels b Fewer defects = happier customers b If metrics hold true, then XP would have quantitative support to convince others

35. 12/03/2002Copyright Patricia Cleary Version 1.2 35 Knowledge Transfer b 4 respondents agreed that there is a tremendous amount of knowledge transfer b New developers sharpen skills b Team learns product quickly b Confidence levels are higher b Team members develop greater respect for each other

36. 12/03/2002Copyright Patricia Cleary Version 1.2 36 Customer Input b 3 respondents agreed that customer input was a benefit b Ability to prioritize allows for flexibility as requirements change b Customer knows what is being developed and is able to correct misunderstandings early on

37. 12/03/2002Copyright Patricia Cleary Version 1.2 37 Improved Communication b 5 respondents commented on the importance of communication b Forces team to communicate often b Done via planning meetings, pair programming, and the code b Everyone knows what is going on and system is visible to everyone

38. 12/03/2002Copyright Patricia Cleary Version 1.2 38 Possible Reasons for Benefits

39. 12/03/2002Copyright Patricia Cleary Version 1.2 39 People Factor b Half of respondents commented on the people factor in XP b Focuses on people; people not treated as resources b Everyone is different -- hard for everyone to always get along b There was maturity, personal growth, and higher degree of self confidence b Encourages respect of people

40. 12/03/2002Copyright Patricia Cleary Version 1.2 40 Testing b Unit testing (programmer) and functional (customer) b Tests are written first. Code is written to fulfill tests -- hard to adapt to this philosophy b Allows for only what is needed to be coded b Need to determine correct number of tests b 4 respondents would improve this area on another implementation

41. 12/03/2002Copyright Patricia Cleary Version 1.2 41 On Site Customer b All projects believed that the customer is an important part of project b Need to write effective stories and test cases b Customers decide what needs to be done b When customer is present, it is easier and quicker to get issues resolved

42. 12/03/2002Copyright Patricia Cleary Version 1.2 42 Pair Programming b Half of respondents agree that practice is useful b The other half found that the practice is hard for some developers to adapt to b Allows for transfer of knowledge b People’s personalities determine successfulness of practice implementation

43. 12/03/2002Copyright Patricia Cleary Version 1.2 43 Conclusion b Many views were qualitative and subjective to the respondents. b Many views echoed XP doctrine because the ideas behind XP are what appeal to management b Does not prove beyond a doubt that Extreme Programming is better than the Waterfall methodology. Ease of implementing Extreme Programming is completely subjective. It is team dependent.

44. 12/03/2002Copyright Patricia Cleary Version 1.2 44 Conclusion (cont’d) b There needs to be more quantitative studies done. b XP 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. [Howard]

45. 12/03/2002Copyright Patricia Cleary Version 1.2 45 Future Research b More quantitative analysis needs to be done to prove that XP is better b The claim that it is easy to implement is subjective and depends on several external variables, such as company culture and people.

46. 12/03/2002Copyright Patricia Cleary Version 1.2 46 Sources b Beck, Kent ExtremeProgramming Explained Embrace Change Addison-Wesley, 2000. b Dribin, Larry Dr., De Paul Univerisity, D01 -SE466 Introduction SE 466_D01_Intro_v1, March 2001 b Fowler, Martin and Highsmith, Jim The Agile Manifesto Software Development Magazine, August 2001. b Howard, Alan, Viewpoint The Communications of the ACM, Volume 45, #10 (October 2002), p.28-29 b Survey Respondents, Private Communication, 2002.