190 likes | 267 Views
eXtreme Programming. How XP addresses the 10 reasons for Software Project Failure! Ian Mitchell Ian@Mitchell.co.nz http://www.xp.co.nz. SW Delivery - What do we want?. Implement the business processes Deliver to “expectations” User-friendly, “Intuitive”, Just how I would do it!
E N D
eXtreme Programming How XP addresses the 10 reasons for Software Project Failure! Ian Mitchell Ian@Mitchell.co.nz http://www.xp.co.nz
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
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
“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
“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
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
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
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
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. Confidential to Ian Mitchell, FNZCS
2. Users are too busy • Daily availability • On the development team • Contracted fixed availability • Approvals required every day. Confidential 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! Confidential 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 10-15 days duration. Confidential 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! Confidential 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! Confidential 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. Confidential 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! Confidential 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. Confidential 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. Confidential to Ian Mitchell, FNZCS
XP is the way to go! • Thank you! • Ian Mitchell • Ian@Mitchell.co.nz • Ph: +64 9 528-3350 • Mobile: +64 25 965-608 Confidential to Ian Mitchell, FNZCS