April 08

276 views
226 views

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
276
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
1
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • April 08

    1. 1. Exigen Services Business Software Trends David Webb April 2008
    2. 2. State of Application Development <ul><li>Pace of business change is extremely high </li></ul><ul><ul><li>IT often unable to support the rapidly changing business with proper systems in time </li></ul></ul><ul><li>Application projects plagued by high failure rates </li></ul><ul><ul><li>Unreliable estimates and/or changes to requirements produce schedule slips and cost overruns </li></ul></ul><ul><ul><li>“ 72% of application projects are failed or challenged” – Standish Group </li></ul></ul><ul><ul><li>“ Most development organizations experience severe overruns, and many (nearly half) have cancelled or abandoned some of their projects” – Cutter Consortium </li></ul></ul><ul><li>Even when projects do not fail outright, systems often do not meet business needs (user satisfaction is low) </li></ul><ul><ul><li>64% of features in systems/products are rarely or never used – Standish Group </li></ul></ul><ul><ul><li>Business problem can evolved while the project is in-flight </li></ul></ul>
    3. 3. There is ample room for improvement “ Please indicate how much you agree or disagree with these statements about application software you use that is custom-developed by your IT organization.” “ New apps or changes to existing apps are delivered at expected quality levels” 2% 7% 20% 29% 35% 7% Base: 418 technology influencers at US companies with more than 500 employees who personally used custom applications developed by their IT organizations (percentages may not total 100 due to rounding) “ New apps or changes to existing apps are delivered in the time frame needed” 3% 9% 20% 31% 30% 7% Base: 417 technology influencers at US companies with more than 500 employees who personally used custom applications developed by their IT organizations (percentages may not total 100 due to rounding) Source: Forrester’s Business Technographics ® March 2005 United States Technology User Benchmark Study Agree Strongly agree Somewhat agree Somewhat disagree Strongly disagree Disagree
    4. 4. Conventional development methodology <ul><li>“ Waterfall”: Single-pass, sequential process with separate phases for requirements specification, design, coding, integration, testing, and deployment </li></ul>
    5. 5. Methodology part of the problem? <ul><li>Waterfall contributes to high project failure rate </li></ul><ul><ul><li>Attempts comprehensive, predictive planning </li></ul></ul><ul><ul><li>Fails to account for high-change nature of projects </li></ul></ul><ul><ul><li>Results in unreliable estimates, schedules and budgets </li></ul></ul><ul><ul><li>No visibility into real status of projects until too late </li></ul></ul><ul><ul><li>“ Four out of the five key factors contributing to project failure are associated with and aggravated by the waterfall model, including inability to deal with changing requirements, and problems with late integration”  </li></ul></ul><ul><li>Waterfall contributes to the outsourcing difficulties </li></ul><ul><ul><li>Makes change control process slow, stressful and expensive </li></ul></ul><ul><ul><li>Causes customers to broaden the scope excessively at requirements definition phase (“Change too expensive”) </li></ul></ul><ul><ul><li>Causes providers to underestimate to come in with lowest bid (“We will make it up on change requests”) </li></ul></ul><ul><ul><li>As a result, customers may end up locked into features that don’t reflect their true needs, not getting the functionality they do need, and being hit with huge change request bills </li></ul></ul>* Craig Larman, “Agile & Iterative Development: A Manager’s Guide”, 2004
    6. 6. The project variables
    7. 7. Enter Agile development <ul><li>Iterative, incremental development methodology </li></ul><ul><li>Highly disciplined approach focusing on delivering value (fit-for-purpose, functioning systems and products, on time) over strict process adherence </li></ul><ul><li>Predicated upon the inherent complexity and high-change, inventive nature of application development projects </li></ul><ul><li>Adaptive, multi-level planning vs. predictive planning (recognizing the Cone of Uncertainty) </li></ul><ul><li>Fosters strong collaboration and alignment between multiple groups of stakeholders (business and IT) </li></ul>
    8. 8. Agile vs. Waterfall Opportunity for requirements change Opportunity for requirements change Opportunity for requirements change Opportunity for requirements change Project A: Waterfall development process Project B: Agile (iterative) development process J F M A M J J A S O N D J F M A M J J A S O N D Requirements definition Formal approval process for requirements change Release Release 1 Iteration 0 Release 2 Release 3 Release 5 Release 4
    9. 9. Enterprise IT continues to adopt Agile
    10. 10. Standard Contract Types <ul><li>Fixed Price Waterfall </li></ul><ul><ul><li>Tries to offload risk </li></ul></ul><ul><li>Time and materials </li></ul><ul><ul><li>Client takes risk </li></ul></ul><ul><li>Time and materials not to exceed </li></ul><ul><li>Fixed Price Agile </li></ul>
    11. 11. Manifesto for Agile Software Development <ul><li>We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: </li></ul><ul><li>Individuals and interactions over processes and tools </li></ul><ul><li>Working software over comprehensive documentation </li></ul><ul><li>Customer collaboration over contract negotiation </li></ul><ul><li>Responding to change over following a plan </li></ul><ul><li>That is, while there is value in the items on the right, we value the items on the left more. </li></ul>
    12. 12. “ Traditional” Roles (Scrum / XP) <ul><li>Product Owner / Customer </li></ul><ul><ul><li>Defines and prioritises the requirements </li></ul></ul><ul><ul><li>Gives feedback on what is delivered </li></ul></ul><ul><ul><li>Signs off completed work </li></ul></ul><ul><li>Scrum Master / Technical Project Manager </li></ul><ul><ul><li>Manages the “self managing development team” </li></ul></ul><ul><ul><li>Facilitates processes / Drives meetings </li></ul></ul><ul><ul><li>Protects the release </li></ul></ul><ul><ul><li>Removes impediments </li></ul></ul><ul><li>Development Team </li></ul><ul><ul><li>Includes QA </li></ul></ul>
    13. 13. Roles and Locations - Traditional Customer Exigen Scrum Master Developers / QA <ul><li>Customer wants moon on a stick and no one keeps him in check </li></ul><ul><li>Integration hell – how do we get live code into production? </li></ul><ul><li>How do we get access to corp systems and standards? </li></ul><ul><li>How does the scrum master remove impediments in the client? </li></ul>Product Owner
    14. 14. Roles and Locations – Ideal world Customer Exigen Scrum Master Developers / QA Product Owner PM / Oversight Enabler <ul><li>Customer wants moon on a stick and no one keeps him in check (PM) </li></ul><ul><li>Integration hell – how do we get live code into production? (Enabler) </li></ul><ul><li>How do we get access to corp systems and standards? (Enabler) </li></ul><ul><li>How does the scrum master remove impediments in the client? (PM) </li></ul>
    15. 15. Lifecycle
    16. 16. Agile Contracts <ul><li>Now </li></ul><ul><ul><li>T & M not to exceed (Fixed Budget) </li></ul></ul><ul><li>Future – Fixed Price </li></ul><ul><ul><li>Shared Risk </li></ul></ul><ul><ul><li>Guaranteed Velocity </li></ul></ul><ul><ul><li>Guaranteed estimates </li></ul></ul><ul><ul><li>Certainty of well planned fix price but with flexibility and business value prioritisation </li></ul></ul>
    17. 17. Questions

    ×