EXtreme Programming How XP addresses the 10 reasons for Software Project Failure! Ian Mitchell [email protected]

eXtremeeXtreme Programming Programming

How XP addresses the 10 reasons for Software Project Failure!

Ian [email protected]

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.



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?



““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!).



““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?)



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.



Some people say . . .Some people say . . .

Develop software iterativelyManage requirementsUse component-based architectureVisually model softwareVerify software qualityControl changes.



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.



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.



2. Users are too busy2. Users are too busy

Daily availabilityOn the development teamContracted fixed availabilityApprovals required every day.



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!



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.



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!



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!



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.



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!



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.



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.



XP is the way to go!XP is the way to go!

Thank you!Ian Mitchell

• [email protected]

• Ph: +64 9 528-3350

• Mobile: +64 25 965-608

Documents

EXtreme Programming How XP addresses the 10 reasons for Software Project Failure! Ian Mitchell [email protected]