From traditional software development process to scrum

Knowledge sharing: Scrum and other methodologies

Son Nguyen, son.nguyen.thanh.81@gmail.comYM & Skype: ng_thanhson

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