eXtreme Programming

1. eXtreme Programming Fad, Fall-back or Fail-safe Focus? Fast Defect-Free Software Delivery! Ian Mitchell Ian@Mitchell.co.nz http://www.xp.co.nz

2. SW Delivery - What do we want? • Implement the business processes • Deliver to “expectations” • User-friendly, “Intuitive”, Just how I would do it! • Reliable software - Defect-free • On Time delivery • Within budget • Future proofed. Confidential to Ian Mitchell, FNZCS

3. Software Development Failures • 70% of projects result in failure (legal letters) • 70% of these are not technology problems • But are change management or communication problems! • Can we continue with methodologies with a chance of success of less than 1/3rd? Confidential to Ian Mitchell, FNZCS

4. “Old Economy” • We know what we are doing – ‘cause we have done it a 1000 times before • Give our really bright programmers detailed specifications and they will do exactly what they are told (they won’t need to think!) • We managers cannot learn much useful from geeks (Programmers don’t know anything about business!). Confidential to Ian Mitchell, FNZCS

5. “New Economy” • I have not been here before • There are no roads on my map • Hey, I’m off the map! • Where are: • the deserts (there is nothing there) • the uncrossable ravines (we cannot go forward) • the wild gorillas (what will get us out there?) • the swamps? (Will we catch a disease?) Confidential to Ian Mitchell, FNZCS

6. How to cross new territory! • Set strategic goals • Take short day marches • Record every thing you do • Make sure at least 2 people are familiar with the route • Look around – what can you see? • Make a decision about where to go tomorrow • Check against our strategic goals. Confidential to Ian Mitchell, FNZCS

7. Some people say . . . • Develop software iteratively • Manage requirements • Use component-based architecture • Visually model software • Verify software quality • Control changes. Confidential to Ian Mitchell, FNZCS

8. But we say . . . • Develop software incrementally • Review requirements after every small step • Deliver small incremental components into production every three weeks • Don’t visualise - See the real thing • Build in and prove it is defect free • Review all requests every three weeks. Confidential to Ian Mitchell, FNZCS

9. To effect change . . . • Hit the block . . . • Admit the way we do it is not working • Seek another way • Try another way • If it works . . . • Embed it as OUR way. Confidential to Ian Mitchell, FNZCS

10. Common Senseto the Extreme! • Everybody will design every day • System will always be the simplest possible • Review code all the time • Test all the time • Define and refine architecture all the time • Integrate and test several times a day • Iterate every hour; deliver every day. Confidential to Ian Mitchell, FNZCS

11. What is XP? • Early, concrete and continuing feedback to the user in short cycles • Incremental planning all the time • Flexible implementation schedule responding to business needs • Automatic tests to allow customers to monitor progress • Communication: Oral, tests, source code • Evolutionary design! Confidential to Ian Mitchell, FNZCS

12. User Stories The Planning Game Small Releases Metaphor Simple Design Test every case Refactoring On-site customer Pair programming Coding Standards Collective Ownership Continuous Integration 40-hour week. XP in Short Confidential to Ian Mitchell, FNZCS

13. Basic Attitudes • Rapid Feedback • Assume simplicity • Incremental change • Embracing change • Quality work • Plus . . . Confidential to Ian Mitchell, FNZCS

14. Four Values • Communication – user management to coders • Simplicity • Feedback • Courage. Confidential to Ian Mitchell, FNZCS

15. Secondary Principles • Teach learning • Small initial investment • Play to win • Concrete experiments • Open, honest communication • Work with people’s instincts, not against them • Accepted responsibility • Local adaptation • Travel light • Honest measurement. Confidential to Ian Mitchell, FNZCS

16. Managers must: • Make IT happen • Co-ordinate • Report • Reward. Confidential to Ian Mitchell, FNZCS

17. My Experience (Large package) • Hit the Block (1m lines of code) • Integration tests repeatedly fail • 3 tier – DB Mtce, SQL procs, COM objects, actual code • Multiple environments – Unix, Novell, MS 3.1,98,Me • Brilliant code does not “fit” anymore • Cannot locate impact of a change • Bottleneck in the general admin program • Bottleneck: stored procedures, WISE, Documentation • Surfacing n-tier deep error messages. Confidential to Ian Mitchell, FNZCS

18. My Solution • Break code into separate applications & “core” • Redesign Build scripts – 3 weekly releases • Coding • Inspection – Pre/Post-assertion • Standards and style guides • Best practice Friday sessions • Test harnesses • Coverage and performance tests • Paired programmers • Feature “razor”. Confidential to Ian Mitchell, FNZCS

19. One pair in One day • Whiteboard with user; get the Story right, Design code unit, split into tasks, volunteer to deliver • Write Face – Pre/post-assertions • Write 50 lines of code • Write 50 lines of test harness • Inspect • Test including Coverage and Performance • Iterate for each test case – each path thru code • Show user the tests that day. Confidential to Ian Mitchell, FNZCS

20. Other Coding Practices • As soon as Face is executable • Move to repository • Integrate • Build • Document • Pass to QA • Release to team • Part of next customer release. Confidential to Ian Mitchell, FNZCS

21. Six is Too Many! • Project versus team size – 6 pairs plusdocumentation editor plus QA (2) plus Build Script controller plus Install Script controller • Time in communication • If team requires 15 minutes per each two way pair then the 7th unit costs twice as much. • So need to segment project into separately manageable and deliverable projects • Dev Environment, Build, database, menu, access rights, etc. Confidential to Ian Mitchell, FNZCS

22. A Year is Too Long! • Keep focus, staff turnover • Cost of changing staff mid-project • But Netscape – 4 week bursts, 2 week re-set • Now continuous releases – by a team • May be 3 weeks for large packages • Focus is on every day delivering completed proven defect-free code and test harness and documentation • Web-based systems have much smaller deliverables. Confidential to Ian Mitchell, FNZCS

23. Economics • Pay only for what works • Minimise risk • Get benefits early • Maintainable code • Measure cost, time, quality, scope • Risks are all made short-term • Complex and irresolvable debates. Confidential to Ian Mitchell, FNZCS

24. NZ Programmers • Have good IS qualifications • Learn quickly from good conceptual base • Often have commerce qualifications • Show initiative • Are not into CYA • Work well together: no internal competition • Respect common sense. Confidential to Ian Mitchell, FNZCS

25. When to use XP • Not on very large projects • My advice – avoid these because your chance of winning is quite low! • Not for embedded software if the hardware is frozen • Not with data-driven apps – RAD for these • Not with “Old Economy” management • My advice – avoid these because your chance of winning is quite low! Confidential to Ian Mitchell, FNZCS

26. Thank You! • Ian@Mitchell.co.nz • http://www.xp.co.nz • Phone: +64 9 528-3350 • Mobile: +64 25 965-608 Confidential to Ian Mitchell, FNZCS