Introduction to AGILE

METHODOLOGIES DSDM
AND SCRUM
 Overview

• What is DSDM?
• History and Background
• Principles
• Project Life Cycle
• Techniques and Roles
• When to use
• Summary
 What is DSDM?

• Dynamic Software Development Method

• A RAD approach to software development
• Iterative and Incremental
• Eliminate problems of:
– Going over-budget
– Missing deadlines
– Users not involved
– Management not commited
 History

• 1990s - Rapid Application Development

• "Meet the needs of a fast business"
• January 1994 - 16 founding members of
DSDM Consortium
• January 1995 - Version 1 completed.
• May 2003 - Current version is 4.2
 Organization

• United Kingdom based

• Non-profit, vendor-independent
• Board of 11 directors, 10 elected
• Academic membership costs about $860
US
• http://dev.dsdm.org/membership/list.asp
 9 Principles
• 1. Active user involvement
• 2. Teams must be empowered to make their own
decisions.
• 3. Frequent releases more important than maximizing
quality.
• 4. Primary criteria for deliverables is meeting business
needs.
• 5. Iterative development is essential to reach correct
solution.
• 6. Any change during development can be reversed.
• 7. The most high level requirements should be
unchangeable.
• 8. Testing shall occur throughout the lifecycle of the
project.
• 9. All stakeholders must cooperate and communicate.
 Attaining Success

• Management 
– Must accept the philosophy
– Empower project team to make decisions
– OR participate regularly with development
• End users
– Must be willing to test and judge functional
prototypes
 Process Overview

• Feasibility Study
• Business Study
• Functional Model Iteration
• Design and Build Iteration
• Implementation
Process Lifecycle
 Feasibility Study

• Investigate scope of an approved project

• Kick-off workshop to ensure stakeholders
buy in to the project. [1]
• Questions:
– Can this project meet the required business
needs?
– Is this project suited for the use of DSDM?
– What are the most important risks?
 Feasibility Study

• Produces:
– Feasibility Report
– Feasibility Prototype (optional proof-of-
concept)
– Outline Plan, a schedule of major milestones
– Risk Log
 Business Study

• Refine the plans of the feasibility study

• Produces:
– Business Area Definition
– Prioritized requirements list
– Development plan
– Updated risk log
• Leave non-functional requirements for
later
 Functional Model Iteration

• Utilize requirements to begin designs

• Four sub-stages
– Identify functional prototype
– Schedule development
– Create functional prototype
– Review prototype
• Begin user involvement; show prototypes
• Begin testing models
 Functional Model Iteration

• Produces:
– Functional model
– Functional prototype

• May combine this phase with Build phase if

– Working on a small project
– Technology exists to generate code from
models
 Design and Build

• Integrate components of previous phase

• Four sub-stages
– Identify design prototype
– Schedule development
– Create design prototype
– Review design prototype
 Design and Build

• Produces:
– Fully designed prototype
– User Documentation
• Testing continues
 Implementation

• System is delivered to end user

• Four sub-stages
– User approval
– Train users
– Implement system on-site
– Review system
 Implementation

• Review is critical
• May return to modeling phase
• Eventually delivers final system
 Techniques of DSDM

• Prototyping
• Testing
• Modeling
• Configuration Management
• Workshops
• MoSCoW
• Timeboxing
 MoSCoW

• Must have
• Should have
• Could have
• Would have
 Timeboxing

• Split the project up

• Fixed budgets and delivery dates
• Allows omission of least important
requirements
• Pareto principle
 Roles
• Executive Sponsor
• Visionary
• Ambassador User
• Project Manager
• Technical Co-ordinater
• Team Leader
• Developer
• Tester
• Scribe (documentation)
• Facilitator (workshop communication)
 Role Details

• Executive Sponsor
– Commits funding
– Final say in decision making
• Visionary
– Greatest knowledge and view
– Supervising project direction
• Ambassador User
– User experience and knowledge
 When to Use
• Inappropriate projects
– real time
– safety critical
– have well defined requirements
– have no fixed end date
– re-usable components
• Appropriate projects
– prioritisable requirements
– fixed end date
– cleared defined users
– can be broken down
 Why SCRUM?
• Frequent deliveries of completed functionality
• Small iterations = easier to adapt to change
• Customer involvement => customer satisfaction
• Deliver business value - Most important
requirements are done first, prioritized frequently
• Visible progress = predictable progress
• Continuous improvement
• Helps focus and motivate team
 What is SCRUM?
• term from rugby
• a process with a set of roles and practices
for agile development
• iterative = timeboxed (sprints)
• incremental = features added
incrementally
• continuous process improvements =
retrospectives
 SCRUM Lifecycle

24 hours
Daily Scrum
Meeting

Backlog tasks 30 days

expanded
Sprint Backlog by team

Potentially Shippable
Product Backlog Product Increment
As prioritized by Product Owner
 Product Backlog
• Prioritized list of work to be
performed on a product
• Anyone can contribute
backlog items
• Product Owner responsible
for prioritisation
 Sprint
• A fixed period of 30 days to
develop a deliverable product
• The Sprint includes design,
coding, testing, and
documentation
• Once a Sprint has started only the
Scrum Team can add or remove
items in Sprint backlog
• Abnormal termination of Sprint is
called for when the Sprint Goal no
longer makes sense
 Sprint Planning
Meeting to set the next Sprint goal
Product Backlog
Team
Capabilities
Business
Conditions Review Next Sprint
Technology
Consider Goal
Stability Organize
Sprint Backlog
Executable
Product
Increment
 Sprint Burndown Chart

Progress

900
Rem aining Effort in Hours

800
752 762
700
664
600 619
500
400
300 304
264
200 180
100 104
0 20

Da te
 Daily Scrum
Daily 15 minute status meeting
Team stands in a circle facing each other
Each team member answers 3 questions:
• What have you done since the last Scrum?
• What will you do between now and the next
Scrum?
• What got in your way of doing work?

For synchronization not problem solving!

 Sprint Review
• During this meeting the team presents to
management, customers, users and the
Product Owner the product increment that
has been built during the Sprint
• The team tells the story of its journey
during the Sprint.
• Powerpoint presentations are forbidden!
Scrum Team

• Self-organizing
• Cross-functional with no roles
• Seven plus or minus two
• Responsible for committing to work
• Authority to do whatever is needed to
meet commitment
 Chickens & Pigs
• Members of Scrum Team are known
as Pigs because they are committed
to delivering Sprint Goal
• People who are involved but not
dedicated to the project are known as
Chickens - they attend Scrum
meetings as observers
 Product Owner

Sets development schedule by prioritizing backlog

One person in this role ensures that only one set of
requirements drives development

Can be influenced by committees, management, customers,
sales people, but is the only person that prioritizes

Works with others to estimate items on Product Backlog

Eliminates confusion of multiple bosses, different opinions,
and interference
 Scrum Master
 The Scrum Master is responsible for
 the success of SCRUM

 establishing SCRUM practices

and rules, shielding the team

and removing obstacles
 representing management to the

project
 Exercise - Sprint Planning
Sprint Planning Meeting 10 mins
• Review the Product Backlog
• Select an achievable Sprint Goal with Product
Owner
• Determine what the number of features might be
that your team can complete
• Think about initial assignments
• Produce a Sprint Backlog on team worksheet
 A Few Rules
• Each team MUST work together
• Everyone MUST have work in the Sprint
• Each team MUST demo something at the end of the
Sprint (free of choice about how)
• Each team MUST complete their Sprint Planning
with a Sprint Backlog on the worksheet
• Each team MUST conduct their Daily Scrum meeting
• No Scrum Master is used in this exercise
• No predefined roles on Team; self-organization rules!