17spm_L17
Dynamic System Development Method
SPM 2017 © Ron Poet Lecture 17 1
Dynamic System Development Method
� Launched in 1995.
� A framework designed for software systems but also applied to other
business change methods.
� Typically used for projects with a time frame of 3 to 6 months.
� Principles
SPM 2017 © Ron Poet Lecture 17 2
� Principles
o The main cause of failure is people issues.
o 80% of the solution can be produced in 20% of the time.
o Things can always be completed later.
o Meet the current needs of the business.
o Choose simple solutions that are fit for purpose.
The Eight Principles (1, 2)
� Focus on the business needs.
o Understand the true business priorities.
o Establish a sound business case.
o Seek continuous business sponsorship and commitment.o
o Guarantee to produce the top priority deliverables.
� Deliver on time
o Timebox the work.
o Focus on the priorities of the business.
o Always hit deadlines.
3SPM 2017 © Ron Poet Lecture 17
Principles (3, 4)
� Collaborate
o Involve the right stakeholders at the right time throughout the
project.
o Empower the members of the team to take necessary decisions.
o Actively involve the business representative.
o Build a team culture.
� Never Compromise on quality
o Determine the required level of quality at the start.
o Don’t drop quality for any reasons.
o Design, document and test continually.
o Ensure quality by constant review.
4SPM 2017 © Ron Poet Lecture 17
Principles (5, 6)
� Build incrementally.
o Deliver business benefit early whenever possible.
o Continually confirm that the right system is being built.
o Formally reassess the project at the end of each iteration.o
� Develop iteratively.
o Do enough design up front to create a strong foundation.
o Build everything iteratively.
o Customer feedback after each iteration.
o Most details emerge later rather than sooner.
o Experiment, learn and evolve.
5SPM 2017 © Ron Poet Lecture 17
Principles (7)
� Communicate Continuously
o Daily team standup sessions.
o Facilitated workshops.
o Modelling and prototyping.o
o Present the current full solution early and often.
o Keep documentation lean and timely.
o Manage stakeholder expectations.
o Encourage informal face-to-face communications.
6SPM 2017 © Ron Poet Lecture 17
Principles (8)
� Demonstrate control.
o Formal approach to track and report progress.
o Plans and progress visible to everyone.
o Measure progress by delivery of products rather than completed o
activities.
o Manage proactively.
o Continually evaluate the project viability.
7SPM 2017 © Ron Poet Lecture 17
Lifecycle
� There is more initial planning than in other agile methods and it is an
agile approach to iterative development.
� Initial work
o Pre-project.
o Feasibility
o Foundations
� Main cycle, usually repeated.
o Exploration
o Engineering
o Deployment
� Post-project
8SPM 2017 © Ron Poet Lecture 17
Three Iterations
� Investigation
o The first iteration produces a rough working system.
o The team learns what needs to be done for the proper version.
o Takes 10 – 20% of the total time.o
� Refinement
o Build as much of the system as possible based on knowledge
gained in the investigation.
o 60 – 80% of the total time.
� Consolidation
o Finish up.
o 10 – 20% of the total time.
9SPM 2017 © Ron Poet Lecture 17
Initial Work
� Pre-project
o Outlines the business case for the project and the project sponsor.
o Resources for a feasibility study are obtained.
� Feasibility study
o Outlines possible approaches to the problem and estimates the cost
and timescale.
o Outlines business benefits and risks.
o If favourable, resources for the project are obtained.
� Foundation.
o High-level requirements, business case and schedule.
o Outline management and team structure and development plan
10SPM 2017 © Ron Poet Lecture 17
Vertical or Horizontal
� Requirements can be developed in two ways.
� Vertical
o Requirements are developed in full but sequentially.
o A basic system is available early on, with more functionality added o
later.
� Horizontal
o Simplistic versions of all requirements are developed together at
the start.
o Each requirement evolves as the system is developed.
11SPM 2017 © Ron Poet Lecture 17
Main Cycle
� Exploration
o Produce models and prototypes to learn more about possible
solutions.
o The code will not be used.
� Engineering
o Builds the actual code.
� Deployment
o The solution is used by the business.
o Training and support for users is provided.
o The product is reviewed.
o A decision is made about further iterations.
12SPM 2017 © Ron Poet Lecture 17
Post-Project
� 6 months after the deployment phase of the final iteration.
� A review on how well the project met the business objectives.
13SPM 2017 © Ron Poet Lecture 17
Roles
� There are a large number of different roles that people occupy.
� Of course, one person can occupy several roles.
� There are 3 families of roles:
o Businesso
o Technical
o Management
14SPM 2017 © Ron Poet Lecture 17
Business Roles
� Business Sponsor
o Make the business case and obtain the resources needed to keep
the project going.
o A largely political role.
� Business Visionary
o Looks after the detailed business needs.
� Business Analyst
o Makes sure requirements are correct and communicated to
developers.
� Business Advisor: Subject matter specialist.
� Business Ambassador: Represents users.
15SPM 2017 © Ron Poet Lecture 17
Technical Roles
� Technical coordinator
o Chief designer and technical expert.
� Team leader
o Leads the development team.o
� Solution developer
o Programmer
� Solutions tester
o Tests the code.
16SPM 2017 © Ron Poet Lecture 17
Management Roles
� Project manager.
o Looks after the big picture
� Workshop facilitator
o Plans the workshops, which are a main way of keeping o
communications open.
o An independent chair.
� DSDM Coach
o An expert on the DSDM framework.
17SPM 2017 © Ron Poet Lecture 17
Workshops
� Much of the requirement for good communication between people is
achieved with workshops.
� The facilitator does not contribute to the technical content of the
workshop.
o They plan the format: brain-storming, story boards, mind maps, o They plan the format: brain-storming, story boards, mind maps,
SWOT charts etc with flip charts, white boards and sticky notes.
� Strength, Weaknesses, Opportunities, Threats.
o They make sure everyone contributes and no one dominates.
o Make sure the goals are achieved.
18SPM 2017 © Ron Poet Lecture 17
Workshops (2)
� The workshop owner will benefit from the information the workshop
delivers.
o They define the objectives and provide the funding.
� The participants.
o Provide the solutions.
� The scribe records the outcomes and follow up actions.
19SPM 2017 © Ron Poet Lecture 17
Workshop Facilitator Tasks
� Define the objectives and plans with the workshop owner.
� Prepare by distributing the agenda and objectives to the participants.
� Run the workshop.
� Review the workshop at the end.
� Distribute the scribes report. These are not minutes but summaries of
decisions.
� Follow up the workshop with the workshop owner.
20SPM 2017 © Ron Poet Lecture 17
Assigning Priorities
� Use MoSCoW system.
� Start with everything as “Would Like To Have”.
o The business must argue to increase the level.
� Challenge all “Must Haves” to make sure they really are vital.
� Regularly re-evaluate priorities.
� Can’t make everything a Must Have!
21SPM 2017 © Ron Poet Lecture 17
Timeboxing
� A timebox is an iteration!
� It starts with a Kick Off meeting in the usual way.
� It ends with a Close Out meeting.
o This often runs back to back with the next Kick Off meeting.o
� Each day starts with a 15 minute standup meeting in the usual way.
� Keeping to the timeboxes means that everything will always be
delivered on time!
o In practice this means that all the Must Haves will be delivered.
o If the project goes well then some of the other requirements will
also be delivered.
22SPM 2017 © Ron Poet Lecture 17
Estimating
� The schedule is produced first.
� The effort required for all the requirements is estimated.
� The overall effort that can be spent on the project is then calculated.
� The scope (which requirements will be done) is then decided.
� Some contigency time must be allocated to cope with unexpected
difficulties.
o Should Have and Could Have requirements provide the flexibility
to cope with problems and still deliver the contracted system (the
must haves).
o Therefore, Must Haves should not account for more than 50% of
the initial requirements.
23SPM 2017 © Ron Poet Lecture 17
Estimating (2)
� People doing the work should make the estimates.
� An estimating workshop is the ideal place.
� Estimates of the effort required for the whole project should be made.
� They should be low precision, with typically 3 values.
o Low: just do the Must Haves.
o Medium: add Should and Could items.
o High: add the difference between medium and low on to the
medium estimate.
� Once into timeboxing (iterations), the time and effort is fixed.
� The only thing that can be changed is how many features are delivered.
24SPM 2017 © Ron Poet Lecture 17
Quality
� Quality is defined as:
o A minimum set of useable functions (the Must Haves)
o Usability and performance metrics.
o Maintainability.o
� There are three levels of maintainability, the customer decides which
one he wants.
o Maintainability is essential.
o A working solution is delivered as soon as possible. A
maintainable version will then be delivered later.
o All that is wanted is a workable solution that will not be
maintained.
25SPM 2017 © Ron Poet Lecture 17
Measuring Quality
� Don’t let quality management interfere with the process.
� Have periodic quality reviews.
� Show that correct processes are being used.
26SPM 2017 © Ron Poet Lecture 17
Risk Management
� Identify risks in a risk workshop.
o Impact: how much damage it could cause.
o Probability: how likely.
� Produce a risk log
o The risk and who owns it.
� Work out countermeasures for each risk.
o Prevention: may be quite costly
o Reduction: reduce the probability
o Acceptance: nothing can be done.
o Transfer: insurance or to a supplier
� Contingency plan: in case it happens.
27SPM 2017 © Ron Poet Lecture 17