From traditional software development process to scrum


Published on

Short overview from traditional software development to Scrum. What is the difference? Starting point for discussion at agile forum Vietnam.

Published in: Education, Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Requirement is never fixed in the software development
  • People may think that this is the way Scrum manages requirement changes
  • Just my stories in the development point of view, don’t say about theory or business point of view
  • Agile principles?
  • Easy to understand but extremely to implement.
  • But move peopleout if they cannot adapt
  • Different thinking between management and engineering levels -> engineering is forced to live a lie
  • From traditional software development process to scrum

    1. 1.  Son Nguyen, YM & Skype: ng_thanhson
    2. 2.  Introduction Traditional methodologies My Scrum stories
    3. 3.  About me Just a brainstorming and discussion session Please be active
    4. 4.  
    5. 5. 2003 2004 2005 2006 2007 2008 CMMi TL9000Waterfall XP TDD UML Unified Process Scrum Continuous Integration
    6. 6. Requirements Requirements Analysis Architecture Design Detail Design Implementation Testing Maintenance
    7. 7.  Waterfall (plan driven) is a well known methodology / process It has dependencies on phases (gated stages) In theory it works great but in practice it may not work It is fundamentally based on an assembly-line mentality for developing software -> no point to go back No mechanism to deal with delays -> buffer -> over estimation
    8. 8. The software factory
    9. 9. Requirements Requirements Analysis Architecture Design Detail Design Implementation Testing Maintenance
    10. 10.  Can start working with incomplete requirements, architecture, design, … Can go back to the previous step and update It is still messy for long time project Sometimes it is unpredictable for the project delivery
    11. 11. Requirements Quick DesignRefine & ImplementationRework Evaluation & Update Final Testing Release
    12. 12.  Good for an environment of changing requirements No methodology for each step Hard in the planning point of view Hard to maintain May cause a lot of reworks and increase cost
    13. 13.  
    14. 14. Let’s Turn Our ThinkingUpside Down
    15. 15.  Self-organization, disciplined, motivation, ownership, and pride You may have to accept: o Some first failed sprints o Give some not qualified members time and training to adjust
    16. 16.  Adaptive process Higher commitment and discipline Flexibility and adaptiveness with work requirements change Collaboration, freely to contribute … But be careful! There is nothing good at the first time, you need to build it with right people
    17. 17.  No need to spend too much time in planning No code written in early phases for requirement validation Communication issue Tester-developer schedule alignment No risk deferral Adaptive with requirement change … But be careful, don’t just do “Iterative”
    18. 18. Plan Driven Value Driven Fixed Variable Scope ScopeVariable Variable Fixed Fixed Time Resources Time Resources
    19. 19.  Increasing Innovation Increase the quality of the deliverables Deliver the highest business value features first Onsite customer … It is not easy to do “Variable Scope”
    20. 20.  Remove organizational overhead Remove management pressure from teams Remove process / planning overhead … It is really hard and need support from your management level