eXtreme Programming How XP addresses the 10 reasons for Software Project Failure! Ian Mitchell

Tuesday, 24 April 2001Confidential to Ian Mitchell, FNZCS 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.

Tuesday, 24 April 2001Confidential to Ian Mitchell, FNZCS 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/3 rd ?

Tuesday, 24 April 2001Confidential to Ian Mitchell, FNZCS “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!).

Tuesday, 24 April 2001Confidential to Ian Mitchell, FNZCS “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?)

Tuesday, 24 April 2001Confidential to Ian Mitchell, FNZCS 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.

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

Tuesday, 24 April 2001Confidential to Ian Mitchell, FNZCS 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.

Tuesday, 24 April 2001Confidential to Ian Mitchell, FNZCS Top 10 Software Development Traps – Wiegers Vision and scope not clearly defined Vision is NOT reality – Does the whole team understand it? – Do IT staff understand the vision? Scope cannot be determined for a fixed price if there are unknowns – Missing technologies – New techniques – Never done before – Goal posts always shift.

Tuesday, 24 April 2001Confidential to Ian Mitchell, FNZCS 2. Users are too busy Daily availability On the development team Contracted fixed availability Approvals required every day.

Tuesday, 24 April 2001Confidential to Ian Mitchell, FNZCS 3. Customer surrogates don’t speak for users Ensure the gap is addressed Make sure the end-users are all enrolled Get code into production incrementally Ensure user on development team can get direct access to management top team Interview them and educate them before the project begins!

Tuesday, 24 April 2001Confidential to Ian Mitchell, FNZCS 4. All Requirements are Critical Force the rapid implementation – Pilot – Narrow business area – Selected branch – But real Wield the “razor”! Pick the next delivery less than days duration.

Tuesday, 24 April 2001Confidential to Ian Mitchell, FNZCS 5. Ambiguities Correct, Complete, Consistent – But at what level of detail – Irregularities handled by intelligent clerks Whiteboard the use cases – User Stories Case: Store incorrect instances or cancel Have the user present Implement the simple case first!

Tuesday, 24 April 2001Confidential to Ian Mitchell, FNZCS 6. Requirements change! Yeh! Right! So! Do we plan 2 years development and not learn anything on the way? Can we freeze the business for a year? Change is real!

Tuesday, 24 April 2001Confidential to Ian Mitchell, FNZCS 7. Schedule slips Resources are not added Users can see the daily progress – they know the impact on the schedule – their problem! Buy-in to the “razor” Journeys of a 1000 miles begin with... Give the user the next thing they said they wanted – within 3 weeks.

Tuesday, 24 April 2001Confidential to Ian Mitchell, FNZCS 8. Changes get lost! So, did we deliver what was next most important? Did our users make the right decision? If it was so important did you argue every three weeks that this change was the most critical thing to do? Of course you keep the request on a card!

Tuesday, 24 April 2001Confidential to Ian Mitchell, FNZCS 9. Functionality is never used So why was it written? If implemented in 3 weeks then it would have been used Only three weeks development lost.

Tuesday, 24 April 2001Confidential to Ian Mitchell, FNZCS 10. The customer is not satisfied All that code and... We stayed with the business as operations changed and moved on So we reached the end? Or we are still implementing more code to address new business challenges.

Tuesday, 24 April 2001Confidential to Ian Mitchell, FNZCS XP is the way to go! Thank you! Ian Mitchell Ph: Mobile: