Embed Size (px)
DESCRIPTION
Short overview from traditional software development to Scrum. What is the difference? Starting point for discussion at agile forum Vietnam.
Citation preview
Agenda Introduction Traditional methodologies My Scrum stories
Introduction About me Just a brainstorming and discussion session Please be active
Traditional methodologies
Methodologies I used before
Waterfall
2003
UML
CMMi
Unified Process
XP
Scrum
TL9000
Continuous Integration
TDD
2008
2007
2006
2004
2005
Lean history
WaterfallRequirements
RequirementsAnalysis
ArchitectureDesign
DetailDesign
Implementation
Testing
Maintenance
Waterfall 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
The software factory
Waterfall with feedback
Requirements
RequirementsAnalysis
ArchitectureDesign
DetailDesign
Implementation
Testing
Maintenance
Waterfall with feedback
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
Iterative & IncrementalRequirement
s
Quick Design
Implementation
Evaluation & Update
Refine & Rework
Final Testing Release
Iterative & Incremental 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
My Scrum stories
Agile - Scrum
Let’s Turn Our Thinking Upside Down
Quick overview about Scrum
People’s motivation Self-organization, disciplined, motivation,
ownership, and pride You may have to accept:
o Some first failed sprintso Give some not qualified members time and training to
adjust
People’s motivation 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
Risk reduction 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”
Risk reduction (lean)
Value driven
Fixed Scope
VariableTime
VariableResources
Plan Driven
VariableScope
FixedTime
FixedResource
s
Value Driven
Value driven 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”
Focus on implementation
Remove organizational overhead Remove management pressure from teams Remove process / planning overhead … It is really hard and need support from your
management level
Discussion
