extreme programming how xp addresses the 10 reasons for software project failure! ian mitchell...
TRANSCRIPT
eXtremeeXtreme Programming Programming
How XP addresses the 10 reasons for Software Project Failure!
http://www.xp.co.nz
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
SW Delivery - SW Delivery - What do we want?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 2001
Confidential to Ian Mitchell, FNZCS
Software Development Software Development FailuresFailures
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?
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
““Old Economy”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 2001
Confidential to Ian Mitchell, FNZCS
““New Economy”New Economy”
I have not been here beforeThere are no roads on my mapHey, 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 2001
Confidential to Ian Mitchell, FNZCS
How to cross new territory!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 2001
Confidential to Ian Mitchell, FNZCS
Some people say . . .Some people say . . .
Develop software iterativelyManage requirementsUse component-based architectureVisually model softwareVerify software qualityControl changes.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
But we say . . .But we say . . .
Develop software incrementallyReview requirements after every small stepDeliver small incremental components into
production every three weeksDon’t visualise - See the real thingBuild in and prove it is defect freeReview all requests every three weeks.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
Top 10 Software Development Top 10 Software Development Traps – WiegersTraps – 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 2001
Confidential to Ian Mitchell, FNZCS
2. Users are too busy2. Users are too busy
Daily availabilityOn the development teamContracted fixed availabilityApprovals required every day.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
3. Customer surrogates don’t 3. Customer surrogates don’t speak for usersspeak for users
Ensure the gap is addressedMake sure the end-users are all enrolledGet code into production incrementallyEnsure user on development team can get
direct access to management top teamInterview them and educate them before the
project begins!
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
4. All Requirements are 4. All Requirements are CriticalCritical
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.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
5. Ambiguities5. Ambiguities
Correct, Complete, Consistent– But at what level of detail– Irregularities handled by intelligent clerks
Whiteboard the use cases – User StoriesCase: Store incorrect instances or cancelHave the user presentImplement the simple case first!
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
6. 6. Requirements change!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 2001
Confidential to Ian Mitchell, FNZCS
7. Schedule slips7. Schedule slips
Resources are not addedUsers 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 2001
Confidential to Ian Mitchell, FNZCS
8. Changes get lost!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 2001
Confidential to Ian Mitchell, FNZCS
9. Functionality is never used9. Functionality is never used
So why was it written?If implemented in 3 weeks then it would
have been usedOnly three weeks development lost.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
10. The customer is not 10. The customer is not satisfiedsatisfied
All that code and . . .We stayed with the business as operations
changed and moved onSo we reached the end?Or we are still implementing more code to
address new business challenges.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
XP is the way to go!XP is the way to go!
Thank you!Ian Mitchell
• Ph: +64 9 528-3350
• Mobile: +64 25 965-608