Extreme Programming: From Theory to Practice

1. Extreme Programming:From Theory to Practice Brett Peterson Chief Architect & VP of Development VisionShare Inc.

2. XP Theory • Kent Beck – “Extreme Programming Explained, Embrace Change” • Succinct, practical book • I read it in 2001. • Resonated with me based on software development process issues I’d noticed since 1992 • This discussion based on the 1st edition

3. XP Theory: Overview • Take proven practices and turn them up to 10 • Practice them all the time, down to the minute-by-minute level • Hence the name "Extreme" • Arguably more disciplined than traditional approaches • Exact opposite of the "cowboy approach"

4. XP Theory: Cost of Change Curve

5. XP Theory: Cost of Change Curve • Want to be able to make large changes late in product life cycle • Only implement what is needed • Increase chances of getting it right • Flatten the cost of change curve through technology and practices • Simple design without unnecessary extras • Automated tests • Practice of constant refactoring

6. XP Theory: Four Values • Value 1: Communication • Bad communication is the primary cause of incorrect software • Customer to Dev Team and Dev Team to Customer • Metrics help customer determine progress • Within Dev Team

7. XP Theory: Four Values • Value 2: Simplicity • Always create the simplest solution that could possibly work • Be confident that one can successfully implement tomorrow's needs

8. XP Theory: Four Values • Value 3: Feedback • Customer to Dev Team • Current state of the system (tests) • Value 4: Courage • Fixing systemic flaws • Adding invasive features with confidence • Plus the Foundation: Respect • Team dynamics are critical

9. XP Theory: Twelve Practices • Turn them all up to 10 and do them constantly • Done together they: • Flatten the cost of change curve • Increase quality • Increase concrete output (working software) • Increase speed of results by only doing the simplest piece necessary • Increase resource efficiency by only doing what is necessary and getting immediate feedback on what is correct and incorrect

10. XP Theory: Twelve Practices • The Planning Game • On-site customer • Small Releases • Testing • Pair Programming • Simple Design

11. XP Theory: Twelve Practices • Refactoring • Continuous Integration • Metaphor • Collective Ownership • 40 hour week • Coding standards

12. XP Practice: The Beginning • 2002: Core group of 5 developers committed to trying XP in full • Found a room amenable as an XP lab • Kept cubicles • Effectively unused – phone only • Educated upper management on XP • Obtained XP lab funding for tables, monitors, keyboards, mice, docking stations

13. XP Practice: The Beginning • Moved to a new company (VisionShare) in late 2004. • Instituted XP there as well • Will intermingle both experiences throughout this discussion • Very different experiences and resulting decisions

14. XP Practice: Initial Decisions • Debate: PCs or laptops? • Had been using laptops • XP Theory seemed to imply PCs configured with identical development environments • Stuck with laptops • Couldn’t justify hardware purchase • Was later considered a good decision

15. XP Practice: Initial Decisions • Debate: Lab hours • We had developers in from 6:00am to 3:00pm, and others in from 9:00am to 6:00pm • Decided on core lab hours of 9:00am to 3:00pm • Did not want to sacrifice respect for the individual at the alter of XP theory • Enough overlap existed to make it work

16. XP Practice: Initial Decisions • Debate: Work Tracking Mechanics • Notecards or whiteboard? • I saw almost no value in notecards, but others on the team disagreed • I could not fathom planning via paper • Tool? • No good XP tools on the market at that time. • Found a few open-source, extensible issue tracking systems

17. XP Practice: Initial Decisions • Debate: Work Tracking Mechanics • Decided to significantly extend an open source PHP-based web issue tracking system called mantis • Designed out the minimal attributes and views to get started • Implemented as a side project with continuous improvements over time • Still in active use today, 6 years later

18. XP Practice: Mantis Extensions • Categorization of mantis issues into one of three hierarchically organized types • Requirement (Defined the “what”) • Story (Refined the “what” and added some “how”) • Task (unit of work for a developer) • Requirements contained stories which contained tasks • Removed tasks in early 2006

19. XP Practice: Mantis Extensions • Fields for time tracking on tasks • Rolled up through report views into stories • Developers tracked “Ideal Engineering Hours (IEH)” • Actual design and coding (not email or meetings) • Developers daily updated all tasks with updated IEH numbers • Each developer required to produce six IEH per day on average

20. XP Practice: Mantis Extensions • Iteration Views • An “iteration” is a time period between planning meetings • We settled on 4 week iterations • An iteration view showed all work planned for (or completed in) an iteration

21. XP Practice: Mantis Extensions • Daily progress percentages • All views showed the % complete of specific stories, tasks, or groupings of them (e.g., % complete of an iteration) • Allowed team leader to track and react to unexpected IEH expenditure on a daily basis if needed • Critical that developers accurately represent IEHs used and remaining IEH usage expected

22. XP Practice: Mantis Extensions • Easy movement of stories and tasks from one iteration to another • Critical for a smooth planning meeting (discussed later) • Screenshots on following pages

23. Main XP Page

24. Stories by Require-ment for an iteration

25. A Require-ment broken into stories

26. Iteration Progress Metrics at Bottom

27. Example Mantis Require-ment Utilizing Attach-ments

28. Example Mantis Require-ment’s Relation-ships and Bug Notes

29. XP Practice: Planning Process • Spreadsheet calculates target IEH for a team for an iteration • Considers vacations, sick, and 6 IEH quota • Estimation Meeting • Held on Thursday of the last week of an iteration • Dev team creates group estimates for all stories and continues stories that may need more time into the next iteration

30. XP Practice: Planning Process • Planning Meeting • Run by product manager • All stakeholders have a seat • Plan the work for the upcoming iteration (based on estimates and a target IEH goal) • Mantis “move item” functionality is useful • Review Meeting (eliminated) • Demonstrate results of previous iteration to all stakeholders

31. XP Practice: Issues • Customer Representative role • Not well filled • Universally a “bad thing” to leave unfilled • Leads to high levels of inefficiency in development and frustration with customers/sales • Filled now at VisionShare with very competent product management

32. XP Practice: Issues • Design Documentation • How much to produce? • Keep it up to date? • Is the code the ultimate expression of the design? • Best way to educate new developers? • We decided in both companies to mostly use design documentation in a transient capacity

33. XP Practice: Introducing XP • Buy-in was very high at first company where the initiative started. • Everyone willing to live through rough spots • Buy-in from second company where process was transplanted was mixed. • Additional developers from first company joined the second company

34. XP Practice: Introducing XP • Issues at new company • Pair programming • Common tables/workstations • Daily standup meetings • Test-first coding • “Big brother” – time tracking • Planning process and mantis brought immediate results

35. XP Practice: Introducing XP • Compromises made at new company • Never enforced pair programming • Did enforce common tables/workstations • Introduced continuous integration and unit testing • Partially successful at test-first coding • Used time reporting for roll up and planning reasons only

36. XP Practice: Lessons Learned • Every developer needs to be committed to every XP principle that is practiced • Compromise can potentially be used if the situation requires it, but it significantly reduces the benefit of full XP • One uncooperative person can cause significant disruption • Respect for the individual must be balanced against team needs

37. XP Practice: Lessons Learned • The XP on-site customer role is critically important • Immediate feedback on questions • Accurate requirements • Planning process works more smoothly • Open lab environment is distracting to some and liberating to others • Did significantly increase communication

38. XP Practice: Lessons Learned • Pair programming lessons • Is exhausting when done correctly • 6 to 8 hours maximum per day • Normal mental breaks don’t occur • Can poison a team if personalities clash • Difficult to hire confidently when pair programming is a requirement

39. XP Practice: Lessons Learned • Discipline and conformance • XP demands conformance • Core hours, lab environment, etc… • Viewed by some personalities as heavy handed, especially time tracking • Lack of discipline in time tracking causes significant difficulties in planning • Don’t go overboard • You don’t want robots

40. XP Practice: Lessons Learned • My top observations after 6 years and two XP environments • The “on-site customer” is the most important practice • Building an XP process requires complete commitment from all developers & mgmt • Individual resistance is magnified due to the interactive nature of the process • Start organically with a committed group

41. Thank you! Questions?