You are on page 1of 289

DSDM Public Version 4.

2 Manual

Introduction When Lifecycle People Products Management Development Tailoring Other

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/default.asp [12-1-2008 11:58:39]


DSDM Public Version 4.2 - Introduction

Introduction When Lifecycle People Products Management Development Tailoring Other

DSDM: Enabling Business Agility

Introduction

What is DSDM?

There is increasing pressure on organisations to deliver working systems to business in ever shorter timescales. The
processes by which systems are developed need to be agile and deliver what the business needs when it needs it.
DSDM is a framework based on best practice and lessons learnt since the early 1990's by DSDM Consortium
members. It provides a flexible yet controlled process that can be used to deliver new systems, which combines the
most effective use of people's knowledge, tools and techniques such as prototyping to achieve tight project delivery
timescales. Typically, a DSDM project will deliver an operational system within six months. Time to market is of the
essence in most organisations together with robust systems that do not damage their reputation, whether they operate
in the public or private sector, in business, education, or any other sphere.

DSDM has primarily been used as an approach for IT projects; however, it is appropriate to business change projects
and programmes. Such projects may have a large amount of technology change or no technology element at all. The
DSDM framework provides an ideal basis for an even-handed development and implementation process, which
encompasses people (e.g. organisation, staff, skills and capabilities), the technology that supports them (e.g. IT, office
automation and communications) and the processes that bind them all together (in line with the business strategy).

DSDM is an essential tool to effectively:

● understand
● plan
● communicate
● control
● deliver
● all projects (IT or Business Change).

DSDM and eXtreme Programming (XP)

This version of DSDM contains guidance on how to use XP in conjunction with DSDM. Combining XP and DSDM
produces a robust and rigorous hybrid that is scalable and sustainable for projects and organisations whether small,
medium or large. This combination brings together the energy and invention of XP with the proven maturity and
commercial know-how of DSDM.

The inclusion of XP confirms the DSDM framework's position as a repository for system development best practice
specifically in relation to the Agile Alliance and the Agile Manifesto and, furthermore, demonstrates how the DSDM
Framework including the lifecycle is relevant for this type of development approach.

http://www.dsdm.org/version4/2/public/Introduction.asp (1 of 4) [11-1-2008 15:42:45]


DSDM Public Version 4.2 - Introduction

Why use DSDM?

DSDM is a vendor-independent framework that recognises that more projects fail because of people issues than
technology. The focus is on helping people to work effectively together to achieve the business goals. DSDM is also
tool and technique independent enabling it to be used in any business and technical environment without tying the
method users to any particular vendor.

Many system development projects fail to meet the expectations of the end users. Such project failures can be
classified into one of five basic types:

1. The system fails to meet the business requirements for which it was developed. The system is either
abandoned or expensive adaptive maintenance is undertaken.
2. There are performance shortcomings in the system, which make it inadequate for the users' needs. Again, it is
either abandoned or amended incurring extra costs.
3. Errors appear in the developed system causing unexpected problems. Patches have to be applied at extra
cost.
4. Users reject the imposition of the system, for political reasons, lack of involvement in its development or lack of
commitment to it.
5. Systems are initially accepted but over time become impossible to maintain and so pass into disuse.

DSDM aims to prevent all five types of project failure.

A fundamental assumption of the DSDM approach is that nothing is built perfectly first time, but that 80% of the
solution can be produced in 20% of the time that it would take to produce the total solution. A basic problem with less
agile approaches is the expectation that potential system users can predict what all their requirements will be at some
distant point in time. This problem is compounded by the fact that the mere existence of a new system affects the
users' requirements because the methods of working have changed.

In the classical, sequential (or "waterfall") approach, the next step cannot be started until the previous step is
completed and fully tested. In practice, a lot of time is spent in getting from the 80% solution to the total solution, with
the assumption that no step ever needs to be revisited. This means that considerable time is spent going back to
"completed" steps and unravelling the defects from work that has previously been accepted. The result is that projects
are delivered late and over budget or they fail to meet the business needs since time is not spent reworking the
requirements.

DSDM assumes that all previous steps can be revisited as part of its iterative approach. Therefore, the current step
need be completed only enough to move to the next step, since it can be finished in a later iteration. The premise
is that the business requirements are likely to change anyway as understanding increases, so any further work would
have been wasted!

Systems built using the DSDM approach address the current and imminent needs of the business rather than
the traditional approach of attacking all the perceived possibilities. The resulting system is, therefore, expected to better
fit to the true business needs, be easier to test and be more likely to be accepted into the users' working practices.
Since the development cost of most applications is only a small part of the total lifecycle costs, it makes sense to build
simpler systems that are fit for purpose and easier to maintain and modify after their initial development. The latter is
possible since maintenance can be treated as a further incremental delivery towards the total solution.

DSDM is not only about developing new systems. Enhancements to existing systems can be created using DSDM.

http://www.dsdm.org/version4/2/public/Introduction.asp (2 of 4) [11-1-2008 15:42:45]


DSDM Public Version 4.2 - Introduction

Why use DSDM and XP?

There are a number of resistors to change that are experienced by XP practitioners, i.e. reasons why organisations do
not immediately embrace the ideas of XP. For example:

● XP is perceived as simply JDI (Just Do It)


● It's just too extreme for us to use here
● It's not scalable
● It’s not maintainable.

Another reason to use DSDM and XP together is that they are synergistic, for example DSDM focuses on the whole
lifecycle whereas XP is stronger on the detailed disciplines of programming. Combining XP with the rigorous yet Agile
approach of the DSDM framework addresses the above issues through:

● Recognised project governance


● Fundamental pre-coding activities
● Project risk management
● Recognition of technical and business organisational standards
● Team dynamics
● Team collaboration
● Extended roles and responsibilities
● Quality management above and beyond code quality

DSDM and project success

DSDM aims not only to prevent failure but to bring success, by delivering systems that:

● satisfy the real requirements of business, in order of importance


● support the way the business needs to work
● are delivered on time and within budget
● are delivered quickly, and yet are robust and right (e.g. the right functionality, performance, security and
maintainability)

Systems built with DSDM are not developed quickly at the expense of quality. DSDM focuses on the priorities of the
business and delivers what can safely be delivered within the time and cost constraints of the project, in priority order
determined by the business needs and the objectives of the project.

Summary of the benefits of using DSDM

Using an iterative process based on prototyping, DSDM involves the end-users throughout the project lifecycle. This
has many benefits, for example:

● the users are more likely to claim ownership of the system


● the risk of building the wrong system is greatly reduced
● the final system is more likely to meet the users' real business requirements
● the users will be better trained, since their representatives will define and co-ordinate the training required
● implementation is more likely to go smoothly, because of the co-operation of all parties concerned throughout
development.

http://www.dsdm.org/version4/2/public/Introduction.asp (3 of 4) [11-1-2008 15:42:45]


DSDM Public Version 4.2 - Introduction

What is in the Framework?

This product provides a framework for development projects that encompasses all aspects for successful delivery:
people, process and technology - with the emphasis on people, since more projects fail because of some people-based
problem than for any other reason.

The framework is based on nine Underlying Principles that enable projects to deliver what the organisation needs when
it needs it.

The framework defines a set of phases that any new/changing system (IT or business) will pass through - from initial
identification of a problem or opportunity to be addressed through the development of the new/changed system to
keeping the system operating successfully. These are described in the Process Overview.

Various products are produced within each phase. These are defined to a level that enables them to be used in any
development environment.

As stated above, the people aspects are essential, so DSDM defines key roles and responsibilities for people working
inside and alongside the development.

Every project will have the need for management techniques to control the process, such as good project planning, risk
management, quality management. DSDM provides guidance on management techniques focusing on aspects of
control that are specific to fast-moving development work. The Management Techniques section covers all the
essentials needed for a controlled and yet flexible approach.

Management is not the complete answer, the people within a project will be carrying out various activities from
identifying how to create the solution to the business problem or opportunity through building and testing the solution to
putting it into operation. DSDM has several core Development Techniques that assist the project workers in these
activities.

DSDM recognises that every project is unique in some way. Hence, a list of factors to consider when starting a DSDM
project are provided in the When to Use DSDM section together with a Suitability Risk/List for ascertaining early in the
project what aspects may cause problems later. Moreover, projects come in all sizes and guises, so guidance on
Tailoring DSDM for specific projects is also provided.

Lastly for those organisations (or parts of organisations) that have never used DSDM before, guidance is provided
about Introducing DSDM into an organisation.

If you are intending to use DSDM external to your own organisation commercially you must be a Member of the DSDM
Consortium and become a Licensed Reseller. Click here to find out about joining the Consortium.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Introduction.asp (4 of 4) [11-1-2008 15:42:45]


DSDM Public Version 4.2 - What's New

Introduction When Lifecycle People Products Management Development Tailoring Other

How to use this site

Introduction

The DSDM on-line manual can be read sequentially from start to finish by following the "Next" links on each page (at
the top and bottom right). You can also browse each section from the menus at the top, or get to the full site map at
any time using the manual logo at the top left.

For those who need a different route, this section helps you to find the best path through the manual. The routes are
provided from four perspectives:

● Someone new to DSDM and needing a broad understanding of what is in DSDM, why it is the way it is and
how it works before going into the detail
● Someone who has just been assigned to a DSDM project, knows the DSDM role that they will hold and wants
to know what this means for them
● Someone familiar with DSDM in previous versions
● Someone who understands this version of DSDM.

New to DSDM?

For quick understanding of the basics of DSDM:

● How the Process Works explains some of the important techniques of DSDM projects.
● The Process Overview describes the phases that a DSDM project goes through.
● The Underlying Principles show the basic philosophy that guides all DSDM projects.
● The People Overview covers the DSDM roles and how they work together - in line with the principles.

After reading these, depending on your personal interest, look at the Management Techniques Overview, the
Development Techniques Overview and the Products Overview to gain an understanding of what DSDM contains.

The When to Use section will be essential reading when you are considering using DSDM on a particular project.

If DSDM has not been used in your organisation before, read the guidance on Introducing DSDM into an Organisation.

Just been assigned a DSDM role?

Go to the People Overview and select the role from the list. This will take you to a description of the the role and its
activities and responsibilities throughout the project. Links to other parts of the DSDM manual are supplied from the
role description.

Familiar with DSDM in previous versions?

Read What's New in Version 4.2

Use the Site Map to find what you are looking for.

http://www.dsdm.org/version4/2/public/how_to_use_site.asp (1 of 2) [12-1-2008 12:09:27]


DSDM Public Version 4.2 - What's New

Familiar with DSDM Version 4.2?

Use the Site Map to find what you are looking for.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/how_to_use_site.asp (2 of 2) [12-1-2008 12:09:27]


DSDM Public Versionl 4.2 - Overview

Introduction When Lifecycle People Products Management Development Tailoring Other

Process Overview

Introduction

In line with the fifth underlying principle, the project lifecycle that DSDM uses is iterative and incremental. So the computer system
may not be delivered to the business in one go, but in a series of increments, which increase what it does each time. In this way,
urgent business needs can be addressed early while less immediately important functionality is delivered later. The iterative nature
of DSDM enables users to see work under construction, comment on it and request changes during the development of an
increment.

The lifecycle description below is not the whole picture; How the Process Works provides an overview of key techniques used
within DSDM to ensure successful delivery on time.

DSDM is more a framework than a method. It does not say how things should be done in detail, but provides a skeleton process
and product descriptions that are to be tailored to suit a particular project or a particular organisation. The project process, as
shown in the figure above, has five phases: Feasibility Study, Business Study, Functional Model Iteration, Design and Build
Iteration and finally Implementation in the working environment. These are preceded by the Pre-Project phase and end with the
Post-Project phase.

The Feasibility and Business Studies are done sequentially. They set the ground rules for the rest of development that is iterative
and incremental and therefore they must be completed before any further work is carried out on a given project. How the three later
phases overlap and merge is left to a particular project to decide. This will depend on several things, primarily the nature of the
system under construction and the tools being used to develop it.

After the project has delivered the solution to the business problem or opportunity, the project team is disbanded and the Post-
Project phase comes into play: this covers activities such as keeping the solution operating effectively and checking that the
expected business benefits have been achieved.

Each phase of the process has a minimum set of products emanating from it. Each of the products has a defined purpose and a set
of quality criteria by which achievement of that purpose can be assessed. How the products will be produced and what they will
contain is left to the individual organisation or project to decide.

http://www.dsdm.org/version4/2/public/Overview_of_DSDM.asp (1 of 4) [11-1-2008 15:45:05]


DSDM Public Versionl 4.2 - Overview

Pre-Project

The Pre-Project phase ensures that only the right projects are started and that they are set up correctly. Once it has been
determined that a project is to go ahead, funding is available, etc., the initial project planning for the Feasibility Study is done. Then
the project proper begins with the Feasibility Study.

The Feasibility Study

An important aspect of the Feasibility Study is the assessment of whether DSDM is the right approach for the project. The normal
considerations in a Feasibility Study are also present, such as a definition of the problem to be addressed together with
assessments of the likely costs and of the technical feasibility of delivering a computer system to solve the business problem.

Given that DSDM is to be used for the development of systems that are needed urgently, the Feasibility Study is necessarily short,
and should last no more than a few weeks. This may have an impact on an organisation's standards for an acceptable Feasibility
Report. There is not sufficient time in DSDM projects to produce large documents unless they are absolutely necessary. Therefore
the Feasibility Report will cover all the usual topics but not in great detail. The DSDM philosophy is to do enough and no more.

As well as a Feasibility Report, there are two other products from the Feasibility Study. Both are produced to support the
conclusions of the Feasibility Report. The first is an Outline Plan for development, which will add weight to the findings that the
desired outcome is achievable and the second is a Feasibility Prototype. The prototype is an optional product to demonstrate that a
solution is possible. It may not be a piece of software: it could be document-based.

The Business Study

Having decided in the Feasibility Study that DSDM is indeed the way to go, the Business Study provides the basis for all
subsequent work. Like the Feasibility Study, it is as short as possible (the duration measured in weeks rather than months), while
achieving sufficient understanding of the business requirements and technical constraints to move forward with safety.

As its name suggests the prime focus of attention is on the business processes affected and their information needs. The short
timescales of a DSDM project mean that this activity has to be very strongly collaborative, using a series of facilitated workshops of
knowledgeable staff who can quickly pool their knowledge and gain consensus as to the priorities of the development. The result of
these workshops will be the Business Area Definition which will not only identify the business processes and associated information
but also the classes (or types) of users who will be affected in any way by the introduction of the system. From these user classes,
the individuals who will participate in the development will be identified and agreement reached with their management as to their
involvement. The key users in a DSDM project are the Ambassador Users. Ambassador Users are so called because they operate
in the same way as diplomatic ambassadors. They reside temporarily in the project team and provide a two-way channel of
communication between the business and development communities. Their presence is essential to the success of a DSDM
project. They are not only responsible for providing information to the project, but also for ensuring that the wider business
community is kept up-to-date with progress. All key project roles in DSDM (including the Ambassador User role) have clearly
defined responsibilities, since DSDM's strength is in helping people to work effectively together.

Each of the requirements identified during the Feasibility and Business Studies has to be prioritised and recorded in the Prioritised
Requirements List so that the most important features will be developed in preference to less essential parts that can be added
later if required. The prioritisation will principally be led by business need but will also take into account the technical constraints
which may drive some requirement to be satisfied first even though it may be less important in business terms. Some non-
functional requirements, such as security, may also affect the prioritisation.

Because parts of the software will begin to be produced in the next phase (the Functional Model Iteration), it is not only important to
understand the functionality to be developed but also the system architecture that will be used. So another product from the
Business Study is the System Architecture Definition, which describes the development and operational platforms as well as the
architecture of the software to be developed in terms of its major components and their interfaces. As with everything else produced
during the Business Study, the System Architecture Definition will be refined during later work and may change as the project
progresses.

Last but not least, the Outline Plan produced as part of the Feasibility Study is refined to produce the Development Plan. This
provides the detail of how development will be carried out during the Functional Model Iteration and Design and Build Iteration
phases using techniques such as modelling and prototyping. It will also include how the activities and products are checked and
controlled as they are developed through timeboxing, risk management, configuration management, quality management and
testing.

http://www.dsdm.org/version4/2/public/Overview_of_DSDM.asp (2 of 4) [11-1-2008 15:45:05]


DSDM Public Versionl 4.2 - Overview

Functional Model Iteration

The focus of Functional Model Iteration is on refining the business-based aspects of the computer system, i.e. building on the high-
level processing and information requirements identified during the Business Study. To this end both standard analysis models and
software are produced.

Both the Functional Model Iteration and the Design and Build Iteration consist of cycles of four activities:

1. Identify what is to be produced.


2. Agree how and when to do it.
3. Create the product.
4. Check that it has been produced correctly (by reviewing documents, demonstrating a prototype or testing part of the
software).

The Functional Model that is built up in these cycles consists both of analysis models and of software components, which contain
the major functionality and will satisfy some of the non-functional requirements, particularly the requirements relating to ease of use.

The software parts of the Functional Model are tested as they are produced. This includes technical unit testing, but should also
include as many other classes of testing as possible including mini-acceptance tests by the Ambassador Users as soon as new
components are available. The focus of testing in the Functional Model is necessarily on what the components do (however limited
that is) and whether or not they form the basis of a usable set of functionality. Non-functional aspects such as performance are
tested in the Design and Build Iteration. This gives rise to the backwards arrow in the process diagram above from the Design and
Build Iteration to the Functional Model Iteration.

Any non-functional requirements not captured already should be captured during the Functional Model Iteration ready for the
Design and Build Iteration.

It will often be easier, and indeed more sensible, to address the detail of an area of functionality together with its non-functional
aspects in one chunk before addressing the detail of another area. The extent to which the Functional Model Iteration and Design
and Build Iteration merge, overlap and move backwards and forwards between each other will depend largely on how the
application being built can be partitioned into smaller functioning areas and the facilities of the development environment.

The preconditions for moving from functional modelling to design and build include agreement of a Functional Prototype that may or
may not be fully automated. The Functional Prototype may be for only part of the Functional Model. This means that design and
build activities may happen concurrently with the functional prototyping activities. Similarly, in a large DSDM project, the
subsequent Implementation may be phased, so design and build may be concurrent with some implementation.

Design and Build Iteration

The Design and Build Iteration is where the computer system is engineered to a sufficiently high standard to be safely placed in the
hands of the users. The major product here is the Tested System. The DSDM process diagram does not show testing as a distinct
activity because testing is happening throughout both the Functional Model Iteration and the Design and Build Iteration. Some
environments or contractual arrangements will require separate testing phases to be included at the end of the development of the
increment, but this should not be the major activity encountered in more traditional approaches to development. Testing is just as
important in DSDM and consumes just as much effort, but it is spread throughout development.

The Tested System will not necessarily satisfy all the identified requirements, but it will satisfy all the requirements that have been
agreed for the current increment. Due to the time constraints, some lesser parts of the system will have been agreed to be left to a
later date. However, the core of requirements (what DSDM calls the minimum usable subset) will be contained in the Tested
System, with as many other parts as time allows.

Implementation

The Implementation phase covers the cutover from the development environment to the operational environment. This includes
training the users who have not been part of the project team. Iteration of the Implementation phase is applicable when the system
is being delivered to a dispersed user population over a period of time.

The products of this phase include the Delivered System that contains all the agreed documentation, including the User
Documentation. The User Documentation is completed in this phase but must have been started earlier during the Design and Build
Iteration. One of the responsibilities of the Ambassador Users is to ensure the correct production of the User Documentation and
training, thus ensuring that the correct perspective is present.

http://www.dsdm.org/version4/2/public/Overview_of_DSDM.asp (3 of 4) [11-1-2008 15:45:05]


DSDM Public Versionl 4.2 - Overview

The other product of this phase is the Increment Review Document. This is produced immediately the computer system or
increment is deemed complete. The Increment Review Document is used to summarise what the project has achieved in terms of
its short-term objectives. In particular, it reviews all the requirements that have been identified during development and assesses
the position of the system in relation to those requirements. There are four possible outcomes (three of which are shown by
returning arrows on the DSDM process diagram above). The four outcomes are:

● All requirements have been satisfied. Hence, no further work is currently needed - and no returning arrow.
● A major area of functionality was discovered during development that had to be ignored for the time being in order to
deliver on the required date. This means returning to the Business Study and taking the process on from there.
● Lower priority functionality, which was known, had to be left out because of the timescale. This is now to be added, so the
process returns to the Functional Model Iteration.
● An area of lesser technical concern was omitted again due to time pressure, but can now be addressed by returning to the
Design and Build Iteration.

Post-Project

The Post-Project phase keeps the solution operating effectively. The iterative and incremental nature of DSDM means that
maintenance can be viewed as continuing development. Maintenance is an expected part of a system's lifecycle, which can be
accommodated using much the same approach as the initial development. Non-urgent fixes and enhancements may be batched up
and implemented using DSDM techniques. This work should follow the DSDM principles with a high level of user involvement and
should be treated as further iterations of the system, going round the DSDM method again starting with a quick pass through the
Business Study.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Overview_of_DSDM.asp (4 of 4) [11-1-2008 15:45:05]


DSDM Public Version 4.2 - How the Process Works

Introduction When Lifecycle People Products Management Development Tailoring Other

How the Process Works

Introduction

The five most important factors to for a successful DSDM project are strong user participation in the development activities, timeboxing,
requirements prioritisation, facilitated workshops and prototyping. How these make the process work are covered in this section.

Flexing requirements

The four possible outcomes described at the end of description of the Implementation phase in the Process Overview are a clear demonstration of
the major difference between DSDM and traditional approaches to software development. Traditionally, requirements are fixed and software
is delivered which satisfies all of them. To achieve this, time and resources vary during development. In DSDM, the exact opposite is true, time is
fixed for the life of a project, and resources are fixed as far as possible, but the requirements that will be satisfied are allowed to change. Hence
there is a need to prioritise requirements as they are elicited during the Business Study and refined during the lifecycle.

The flexibility of requirements to be satisfied has significant impact on the development processes and controls, and on acceptance of the system.
One of the nine underlying principles of DSDM is that fitness for business purpose is the essential criterion for the acceptance of deliverables.
This moves away from the approach of satisfying all the "bells and whistles" in a requirements specification, while maintaining a quality-
oriented approach to development.

The basic mechanism for handling flexibility of requirements in DSDM is timeboxing. A timebox is a simple concept: a period of time with a
fixed completion date. DSDM refines the concept of timeboxing by nesting shorter timeboxes within the higher-level timebox that delivers
an operational solution. It is these nested timeboxes that demonstrate progress and also drive the project forward. Fixing completion dates will
not work on its own. Clear but negotiable prioritisation of what must be achieved within the timebox is also required. DSDM applies the MoSCoW
rules for prioritising the requirements addressed by each timebox to ensure that what is delivered now will satisfy the immediate business needs.

Timeboxing as a milestone-to-milestone process is really key and can work wonders even if when it isn't done very well. No other method exists
with such a well-defined process for milestone-to-milestone work.

http://www.dsdm.org/version4/2/public/How_Process_Works.asp (1 of 3) [11-1-2008 15:45:40]


DSDM Public Version 4.2 - How the Process Works

Communication channels

DSDM is above all about improving the communication channels between the various stakeholders and the project team. One of the most
effective mechanisms for improving communications is the facilitated workshop. This is used throughout DSDM to ensure that the project
works quickly towards the best solution for all concerned.

DSDM also achieves delivery to tight timescales through shortening communication lines between users and IT staff within the project,
between analysts and designers, between team members, and between differing levels of management. The mechanisms by which
these communication lines are shortened differ from one channel to another. In particular, the communication between developers and users is
eased by the use of prototyping rather than the production of lengthy documents. This is why DSDM defines a Functional Model rather than
a functional specification.

Documents in DSDM

DSDM incorporates an approach for defining what the necessary documentation set will be for a given project. Much of the documentation that
is traditionally produced is for the transfer of ideas from one developer to another or from the developers to the users. By keeping mixed
user/developer teams small and constant throughout development, DSDM renders such documents largely unnecessary.

For the management documentation, local practices should be followed but perhaps scaled down to minimise unnecessary barriers to rapid
movement through the project. On the technical side, DSDM provides guidance on how to decide what sort of documentation it is necessary to
control and why. The basic criterion for deciding to control a technical document is that it is either essential to the developers' progress
to implementation or it is required for maintenance purposes. When the documentation that is often required to be delivered is compared with
the documentation that is actually useful after delivery, there is quite a wide gap. DSDM's focus on doing the minimum necessary for safety is one
of the ways that systems can be delivered faster and yet meet their quality objectives. Some documents may be required for audit purposes.

A question that is often asked is "How much documentation is enough?" Enough can be defined as when any extra documentation will not add to
the understanding of what is being built. For example, in traditional projects, a lot of effort is devoted to writing, reviewing, agreeing and maintaining
a detailed requirements specification, which often has zero value in the longer term.

People, Process and Technology

The DSDM approach views people, process and technology, as the intertwined components of any business solution. Changes to one component
will impact the others. A business change project must include and manage all three aspects.

The basic approach to providing business solutions should be:

● understanding the business objectives


● re-engineering business processes and aligning people and technology to achieve the objectives.

http://www.dsdm.org/version4/2/public/How_Process_Works.asp (2 of 3) [11-1-2008 15:45:40]


DSDM Public Version 4.2 - How the Process Works

Whilst the standard DSDM lifecycle does not expressly encompass strategic business planning methods, the approach assumes that a
business strategy exists and that it both influences the DSDM project, and is influenced by it. A feedback mechanism should be established to
facilitate this.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/How_Process_Works.asp (3 of 3) [11-1-2008 15:45:40]


DSDM Public Version 4.2 - Principles

Introduction When Lifecycle People Products Management Development Tailoring Other

Underlying Principles
The following principles are the foundations on which DSDM is based. Each one of the principles is applied as
appropriate in the various parts of the method.

I. Active user involvement is imperative DSDM is a user-centred approach. If


users are not closely involved throughout
the development lifecycle, delays will
occur as decisions are made and users
may feel that the final solution is imposed
by the developers and/or their own
management. Users are not outside the
development team acting as suppliers of
information and reviewers of results but
are active participants in the development
process.
II. DSDM teams must be empowered to make DSDM teams consist of both developers and
decisions users. They must be able to make decisions as
requirements are refined and possibly changed.
They must be able to agree that certain levels of
functionality, usability, etc. are acceptable
without frequent recourse to higher-level
management.
III. The focus is on frequent delivery of A product-based approach is more
products flexible than an activity-based one.

The work of a DSDM team is


concentrated on products that can be
delivered in an agreed period of time. This
enables the team to select the best
approach to achieving the products
required in the time available. By keeping
each period of time short, the team can
easily decide which activities are
necessary and sufficient to achieve the
right products.

Note: Products include interim


development products, not just delivered
solutions.
IV. Fitness for business purpose is the essential The focus of DSDM is on delivering the
criterion for acceptance of deliverables necessary functionality at the required time. The
computer system can be more rigorously
engineered later if such an approach is
acceptable. Traditionally the focus has been on
satisfying the contents of a requirements
document and conforming to previous
deliverables, even though the requirements are
often inaccurate, the previous deliverables may
be flawed and the business needs may have
changed since the start of the project.

http://www.dsdm.org/version4/2/public/Principles.asp (1 of 3) [11-1-2008 15:46:20]


DSDM Public Version 4.2 - Principles

V. Iterative and incremental development is DSDM allows systems to grow


necessary to converge on an accurate incrementally. Therefore the developers
business solution can make full use of feedback from the
users. Moreover partial solutions can be
delivered to satisfy immediate business
needs.

Iteration is inherent in all software


development. DSDM recognises this and,
by making it explicit, uses iteration to
continuously improve the system being
developed.

When rework is not explicitly recognised


in a development lifecycle, the return to
previously "completed" work is
surrounded by controlling procedures that
slow development down. Since rework is
built into the DSDM process, the
development can proceed more quickly
during iteration.
VI. All changes during development are reversible To control the evolution of all products
(documents, software, test products, etc.),
everything must be in a known state at all times.
This means that configuration management must
be all-pervasive.

Backtracking is a feature of DSDM. However in


some circumstances it may be easier to
reconstruct than to backtrack. This depends on
the nature of the change and the environment in
which it was made. The ability to reverse
changes is limited to within the development of
an increment.
VII. Requirements are baselined at a high level Baselining high-level requirements means
"freezing" and agreeing the purpose and
scope of the system at a level that allows
for detailed investigation of what the
requirements imply. Further, more
detailed baselines can be established
later in the development, although the
scope should not change significantly.

Changing the scope defined in the


baselined high-level requirements usually
requires escalation.
VIII. Testing is integrated throughout the lifecycle Testing is not treated as a separate activity. As
the system is developed incrementally, it is also
tested and reviewed by both developers and
users incrementally to ensure that the
development is moving forward not only in the
right business direction but is technically sound.
Early in DSDM, the testing focus is on validation
against the business needs and priorities.
Towards the end of a project, the focus is on
verifying that the whole system operates
effectively.

http://www.dsdm.org/version4/2/public/Principles.asp (2 of 3) [11-1-2008 15:46:20]


DSDM Public Version 4.2 - Principles

IX. A collaborative and co-operative approach The nature of DSDM projects means that
between all stakeholders is essential low-level requirements are not necessarily
fixed when the developers are originally
approached to carry out the work. Hence
the short-term direction that a project
takes must be quickly decided without
recourse to restrictive change control
procedures. The stakeholders include not
only the business and development staff
within the project, but also other staff such
as Service Delivery or resource
managers.

When development is procured from an


external supplier, both the vendor and the
purchaser organisations should aim for as
efficient a process as possible while
allowing for flexibility during both the pre-
contract phase and when the contracted
work is carried out.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Principles.asp (3 of 3) [11-1-2008 15:46:20]


DSDM Public Version 4.2 - When to Use DSDM

Introduction When Lifecycle People Products Management Development Tailoring Other

When to Use DSDM

Assessing the risks

The decision as to whether or not to use DSDM is an important one to be made at the outset of a development project.
Some projects are clearly ideal for DSDM. Others require careful consideration to decide whether the use of DSDM will
provide business benefits.

To assist management in assessing the risks associated with a given project, DSDM provides a risk identification tool -
the Suitability/Risk List. The list considers the critical success factors for DSDM and characteristics of projects that are
especially effective for DSDM. Each potential project should be judged individually using the risk list. If the project
provides a good match against the list, then DSDM can be considered a very appropriate development approach.
However inability to satisfy all of the criteria does not automatically prohibit the use of DSDM. However, it will be
necessary for risk management strategies to be developed to address any non-compliance.

The criteria included within the DSDM Suitability/Risk List are intended as guidance material only and should not be
considered exclusive. It is expected that an organisation using DSDM will enhance the list with their own specific
factors identified from experience of using the method within their environment.

The choice of DSDM as the development method should be carefully monitored during the early stages of the project.
If it becomes apparent that the system does not clearly demonstrate all of the expected characteristics and yet the use
of DSDM will still provide benefit, then again it is important that risk management strategies are developed to address
the problem areas.

When to use DSDM and XP

This version of DSDM incorporates certain Extreme Programming (XP) techniques within the DSDM framework. The
Suitability/Risk List has been extended so that it can be used to assess the risks of using DSDM and XP together. This
has been done by including new questions specifically aimed at XP. If the project provides a good match against the
list, then the combination of DSDM and XP can be considered an appropriate development approach. However failure
to satisfy all of the criteria does not automatically prohibit the use of XP with DSDM but it will be necessary for risk
management strategies to be developed to address any non-compliance.

Further guidance is provided throughout the manual in the form of "Guidance for those looking to use XP with
DSDM".

Characteristics of systems where DSDM should be the Framework of choice

In addition to considering the critical success factors, DSDM will be especially effective for systems that demonstrate
the following characteristics:

● interactive, where the functionality is clearly demonstrable at the user interface. DSDM is strongly based
on incremental prototyping with close user involvement. Therefore users must be able to assess the
functionality easily through viewing and operating working prototypes. Hence the need for demonstrable
functionality. The user interface includes screens, reports and file-prints (where file-prints may be solely for
interim demonstration and verification of the functionality). If the user interface is not highly demonstrable,
there must some other way that users can verify that partially built solutions are correct.

This characteristic relates in part to Principles I and IV.

● has a clearly defined user group. If the user group is not clearly defined, there may be a danger of driving
the development from a wrong viewpoint or (worse) ignoring some important aspect of the project entirely.

This characteristic relates to Principle I.

http://www.dsdm.org/version4/2/public/When_to_Use.asp (1 of 3) [11-1-2008 15:48:33]


DSDM Public Version 4.2 - When to Use DSDM

● if computationally complex, the complexity can be decomposed or isolated. If the internals of the system
are hard to understand via the user interface then there is a risk. The level of computational complexity is often
quite difficult to determine in advance and will vary from one project to another. Moreover there can be
interactions between different components, which can be difficult to identify up front.

DSDM can be used where there is a great deal of computational complexity provided that the application can
be decomposed to reduce the complexity.

For instance, if an application requires some complex statistical modelling, a project may consider two
approaches to development: using existing, well-tested statistical modelling components or developing the
models from scratch. The first would be totally acceptable in a DSDM project. The second would require care
in the use of the method, unless it is possible either to decompose the complexity into simpler components or
to make it transparent at the user interface.

If there is complexity but it can be isolated from the rest of the computer system, then it can be handled in a
more formal manner and re-integrated later.

This characteristic relates in part to Principle V.

● if large, possesses the capability of being split into smaller functional components. If the proposed
computer system is large it should be possible to break it down into small, manageable chunks, each
delivering some clear functionality. These can then be delivered sequentially or in parallel. Indeed, some of the
functionality may be delivered using traditional waterfall methods. However, each sub-project must be
constantly aware of the overall system architecture. Indeed, all aspects of the project must be controlled and
co-ordinated.

Note: When DSDM teams are working in parallel on a project, the number of teams should be minimised,
without exceeding DSDM's recommended maximum team size. This will aid the overall control of the project
and minimise the integration overheads. The task of managing and co-ordinating timeboxes should not be
underestimated.

This characteristic relates in part to Principles III and IV.

● time-constrained. There should be a fixed end date by which the project must be completed. If there is no
real case for the end date to be fixed, it will be relatively easy to allow schedules to slip and the fundamental
benefits of DSDM will be lost. The time constraint is usually defined by the business objectives but could also
be due to the availability of IT staff within a defined timescale, the imminent removal of support for old
technologies, etc.

This characteristic relates in part to Principle III.

● the requirements can be prioritised. The requirements should be prioritised using the MoSCoW rules.

Note: If the requirements have already been written before the decision to use DSDM is taken, then it will be
necessary to gain acceptance from the "owner" of the project for the requirements to be variable, and to revisit
them using the MoSCoW rules.

This characteristic relates in part to Principle VII.

● the requirements are unclear or subject to frequent change. In periods of rapid change it may be difficult
to specify the requirements in detail at the outset of the project. This makes traditional approaches unsuitable.
DSDM is designed specifically to deal with requirements that change and evolve during a project.

Many applications are difficult to specify in advance because the users do not know exactly what is needed at
the outset. Examples include when a business process is being redesigned and when new products and
services are being built. DSDM is well suited to building such applications because it enables users to change
their minds as development proceeds.

This characteristic is really checking whether or not there is anything of significance to discuss with the users
during development. If the detail of the requirements for the system is clearly understood, there will be less
ability to save time through prototyping with the users for requirements elicitation. If they are all fixed there will
be less ability to allow some requirements to be left to later developments in order to meet the timescales
required.

This characteristic relates to Principles V and VI.

http://www.dsdm.org/version4/2/public/When_to_Use.asp (2 of 3) [11-1-2008 15:48:33]


DSDM Public Version 4.2 - When to Use DSDM

Characteristics of systems where special care is needed in applying DSDM

Many systems may appear not to demonstrate compliance with the critical success factors and the required
characteristics. However, if the development support environment is strong enough and the development team is
experienced in the DSDM approach, benefits can be gained by using DSDM techniques where appropriate.

There are some systems where using DSDM will need special care. Such systems will display one or more of the
following characteristics.

● process control/real-time applications. Much of the processing of process control/real-time applications (e.
g. systems that control manufacturing equipment, power plants or weaponry) is not visible at the user
interface, is often very complex and cannot be decomposed into smaller components. In addition, extensive
validation and verification is frequently needed. For these reasons DSDM would normally be considered
unsuitable for such applications.

● requirements have to be fully specified before any programs are written. In some projects, it may be
demanded or considered essential that the requirements be fully specified and approved before programming
takes place. The attempted use of DSDM in this situation could be disastrous. DSDM is an iterative approach
and the momentum and synergy of the DSDM project team would be seriously affected by defining all
requirements in advance. Time delays in the project would inevitably occur while waiting for all the
requirements to be defined, the value of business knowledge within the project team will diminish and senior
management might seriously question the credibility of DSDM as a rapid development approach. Techniques
such as facilitated workshops might still be useful for defining requirements but it is unlikely that full DSDM
could be used.

● safety-critical applications. As well as the need for detailed specifications, the exhaustive validation and
verification activities required for safety-critical systems (i.e. systems that can endanger lives) make it unlikely
that they will be suitable for the iterative development approach of DSDM.

It should be noted that safety-critical systems have been developed using DSDM. In this sort of project, the
skill and experience of the Technical Co-ordinator will be a critical factor in ensuring success.

● delivering re-usable components. Projects may be required to produce re-usable components. Such
components must be exactly right. Generally, the speedy delivery of business benefits and the creation of re-
usable components are two contradicting goals, with different sponsors. As you cannot have two sponsors,
satisfy the business-benefit goal first, then move on to the second. That said, DSDM will be very suitable if the
re-usable components are highly modular and can be built incrementally without prejudicing the rest of the
application.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/When_to_Use.asp (3 of 3) [11-1-2008 15:48:33]


DSDM Public Version 4.2 - Critical Success Factors

Introduction When Lifecycle People Products Management Development Tailoring Other

Critical Success Factors


The critical success factors for DSDM are:

1. acceptance of the DSDM philosophy before starting work. It is important that the sponsor/senior
management understands and accepts the DSDM philosophy. This includes the concept that delivering less
than everything is agreed by all parties. Furthermore, as work continues ongoing agreement to the DSDM
philosophy is essential.

This CSF relates to all the underlying principles of DSDM

2. the decision-making powers of the business people and developers in the development team. The
senior business management must either agree to delegate decision-making to the business representatives
in the development team or to participate in the team themselves, otherwise progress will slow down while
awaiting decisions to be made elsewhere. Junior business staff should feel able to make decisions without
referral to higher authorities outside the team. Similarly, the developers in the team should also be empowered
to make decisions, for example regarding technical feasibility. Checking empowerment involves ensuring that
the people concerned are willing to take on the responsibility, as well their managers being willing to delegate
it.

This CSF relates to Principle II.

3. the commitment of senior business management to provide significant end-user involvement. The
business commitment and agreed participation is absolutely key. If this commitment is not achieved by the end
of the DSDM Feasibility Study, DSDM should be abandoned in favour of a more traditional approach.

This CSF relates to Principle I.

4. incremental delivery. The organisation should be amenable to the delivery of systems in an incremental
fashion. This applies to both the business and the development side of the project. For instance, the business
areas will need to handle incremental system growth, retraining, etc. and the developers will need good
configuration management procedures that will not slow down the process of delivery

This CSF relates to Principles III and V.

5. easy access by developers to end-users. Ideally the developers and end-users will be collocated in their
own dedicated environment, free from daily interruptions. However, the ideal is not essential as long as contact
is continual and frequent throughout the project.

This CSF relates to Principle I and IX.

6. the stability of the team. Due to the overlapping development skills required (i.e. strong interaction
throughout between business analysts, system designers and programmers) and the speed of development,
the project will be put at risk if staff are swapped in and out. Of course, specialists can be called in as required
to support a team, but core teams should be constant throughout. In organisations that have specialist groups
(e.g. business analysts) responsible for certain areas of the development lifecycle, which then pass their
products to the next group in the sequence, the recommended approach is to structure project teams the way
DSDM describes. If this is deemed impossible, extra care needs to be taken to ensure smooth transition if the
stable team cannot possibly be achieved.

This CSF relates in part to Principle IX.

7. the development team skills. The team(s) must contain highly skilled people in terms of both the business
area as well as the technical environment. This does not mean that everybody needs to be a multi-skilled
expert but that all the core skills for the project must be present in the team. All team members should
demonstrate good interpersonal skills.

This CSF relates in part to Principle IX

8. the size of the development team. Each DSDM team within the project should be small in order to minimise
the overheads of management and communication, while optimising ownership. The team headcount includes
both Developers and Ambassador Users. DSDM advises no more than six full-time team members per team.

http://www.dsdm.org/version4/2/public/CSFs.asp (1 of 2) [11-1-2008 15:48:48]


DSDM Public Version 4.2 - Critical Success Factors

Note: One project can have many DSDM teams.

9. a supportive commercial relationship. Where developers and business people are from different
organisations and the development is covered by formal contract or where developers are from the same
organisation but working within a service level agreement, the relationship must accommodate the evolution of
the system's requirements without imposing onerous change management overheads.

This CSF relates to Principle IX.

10. the development technology. The development technology should be suitable for the DSDM approach. It
needs to allow for iterative development, demonstrable work products, and control of versions. Ideally code
construction should be rapid and easily testable.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/CSFs.asp (2 of 2) [11-1-2008 15:48:48]


DSDM Public Version 4.2 - DSDM Suitability/Risk List

Introduction When Lifecycle People Products Management Development Tailoring Other

DSDM Suitability/Risk List

Objectives of the Suitability/Risk List

The Suitability/Risk List consists of a set of criteria for helping the DSDM practitioner to determine the risks that need to
be addressed when applying the DSDM approach. The criteria are based on the DSDM critical success factors and
other project situational factors. These are both explained in When to Use DSDM. The criteria are intended as
guidance material only and are not considered to be fully comprehensive. Moreover as the experience of using DSDM
grows within an organisation, the list should be refined and expanded to fit with local constraints and practices.

Note: It is not necessary to be able to provide a positive response to each of the criteria: a negative response identifies
a risk to be managed as defined in the section on Risk Management.

A table of additional risk-related questions is also provided. Again, there is no right or wrong answer but their impact on
the project needs to be assessed.

Suitability/Risk List Output

Upon completion of the Suitability/Risk List, the DSDM practitioner will advise whether the project under consideration
should run under full DSDM, and if not, which techniques are appropriate to the project. Where the proposed project
team members are inexperienced with the use of DSDM, a very high level of positive answers in the first table is
advisable.

Suitable
Risk Factor Comments
(Y/N)
1. Does the sponsor/senior management Buy-in to the approach is essential.
understand and accept the DSDM philosophy?
2. Will the team members be empowered to An essential feature for DSDM.
make decisions on behalf of their
communities?
3. Is there senior user commitment to provide Identify whether there is a clearly defined
end user involvement? and empowered user group and the
commitment for them to be fully involved in
the development process.
4. Can the organisation accommodate the Configuration and Release Management
frequent delivery of increments? procedures are required. The business areas
will need to have incremental training, etc.
5. Will it be possible for the developers to have Do they need to collocate or will a lower level
access to the users throughout the project? of involvement be sufficient?
6. Will the development team(s) remain the The stability of the team including the user
same throughout the project? representatives is important.
7. Will the development team have the These include technical skills, knowledge of
appropriate skills? the business area and interpersonal skills.
8. Will the individual development teams consist Teams should contain no more than six
of six people or less? people including users.
9. Is there a supportive commercial relationship? Between the IT development staff and the
users and between the organisation / project
team and third parties.
10. Will the project use technology suitable for The development platform needs to allow for
prototyping? iterative and where necessary reversible
development.

http://www.dsdm.org/version4/2/public/Suitability_Risk.asp (1 of 3) [11-1-2008 15:49:01]


DSDM Public Version 4.2 - DSDM Suitability/Risk List

11. Is there a highly demonstrable user interface? Screens, reports, file prints etc.

12. Is there clear ownership? Is there a champion who will progress


political issues and ensure resources are
provided? Is there a clearly defined user
group?
13. Will the development be computationally non- The more complex the development the
complex? greater the risks involved.
14. Can the solution be developed in increments 80:20 solution, i.e. releases deliver some
if required? benefits early. If large, it possesses the
capability of being split into smaller
components.
15. Has the development a fixed timescale? Is the solution needed quickly? Is it business
critical?
16. Can the requirements be prioritised? Can the MoSCoW rules be applied? Cannot
only have "must haves".
17. Are the requirements not too detailed and Will users be able to define requirements
fixed? interactively?

Additional Questions Risk Level

Consider and assign a risk level


High Medium Low
What work has already been done to define the requirements?

What is the status of the business case?

What resources (e.g. people, accommodation) have been allocated to the project?

Who are the likely suppliers of development resource for the project?

What is the estimated cost of the project?

What are the estimated business benefits for the project?

Is there any previous experience in this type of project?

Could the project efficiently reuse (e.g. software components, business process, and
experience) from other projects?
Does the project conform to architectural guidelines (technical and business)?

Will the project call for the use of technology that has not been used before?

Will the project require changes on interfaces to other systems?

Will the project require changes to other systems?

Will database design be a substantial part of the project?

Will a lot of infrastructure be required? (e.g. hardware and training)

Are there any supplier issues e.g. long lead times?

Are there any Industrial Relations issues?

Is this project part of a larger programme?

How onerous are the non-functional requirements?

http://www.dsdm.org/version4/2/public/Suitability_Risk.asp (2 of 3) [11-1-2008 15:49:01]


DSDM Public Version 4.2 - DSDM Suitability/Risk List

Additional Questions when considering the use of XP with DSDM

Suitable
Risk Factor Comments
(Y/N)
1. Does the organisation intend cherry picking XP is a synergistic approach and choosing
certain XP practices? the wrong set of practices can easily create
serious problems e.g. refactoring without
test driven development.
2. Does the organisation accept the concept of Pair Pair programming has been empirically
Programming? shown to be more productive that solo
programming due to the increase in quality
of the solutions.
3. Is refactoring acceptable to the organisation? Refactoring is a practice that is an
essential programming skill for any
development approach but is particularly
important to XP. A key consideration is the
team’s empowerment to refactor as
required.
4. Is the organisation welcoming to the use of user User stories are the XP mechanism for
stories? capturing user requirements. They can
often be derived from other sources e.g.
Use Cases.
5. Does this approach conflict with any of the XP is a synergistic approach. Care should
existing organisation standards? be taken when adapting XP to existing
organisational standards.
6. Does this approach require the implementation of Automated testing is key to XP. You may
automated testing tools/suite? need to plan to build or buy a test
framework or harness as part of your
project.
7. Does testing and/or development support Continuous integration is vital to creating
continuous integration? the development feedback XP needs and
also ensuring that there is always a
working copy of software ready for the
customer.
8. Does the organisation culture support collective XP creates an emergent design that
code ownership? requires that all teams can evolve the
code. The risk brought about by this
approach is is mitigated by the use of Test
Driven Development and Automated
Acceptance tests.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Suitability_Risk.asp (3 of 3) [11-1-2008 15:49:01]


DSDM Public Version 4.2 - Lifecycle Introduction

Introduction When Lifecycle People Products Management Development Tailoring Other

Lifecycle Overview
DSDM provides a project lifecycle as well as a system lifecycle. Development projects are not the full story in the life of system.
There are activities that occur before a project even starts and after it has completed, i.e. once a system is in use. These are
contained in the following DSDM phases:

● Pre-Project
● Post-Project

The project lifecycle is illustrated below.

The project lifecycle is not mandated and is expected be tailored to meet the requirements of a particular project, hence it is called
the development process framework.

The development process framework is based mainly on Principles I, III, V and VIII. There are five project phases within DSDM:

● Feasibility Study
● Business Study
● Functional Model Iteration
● Design and Build Iteration
● Implementation

The diagram shows an incremental prototyping approach moving anti-clockwise from the top. Dark arrows show the transfer points
from one phase of the lifecycle into the next. The light arrows show the points where the development can easily return to an earlier
phase.

The lifecycle is described in the Overview of DSDM. The formal definitions of the phases together with some hints and tips can be
found by following the links above. Note that not all the products defined in the phase definitions are delivered at the end of a
phase. Some are necessarily interim deliverables that enable a given project to progress. Moreover some will start being developed
in an earlier phase than the one in which they are delivered. The points at which they start being developed and at which they are
delivered are decided on a project-by-project basis.A number of alternative paths, including an XP path, through the lifecycle are
included in the tailoring DSDM section of the manual.

http://www.dsdm.org/version4/2/public/Lifecycle_Overview.asp (1 of 2) [11-1-2008 15:47:07]


DSDM Public Version 4.2 - Lifecycle Introduction

If you are using XP in conjunction with DSDM the Using DSDM with XP section of the manual describes a combined lifecycle.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Lifecycle_Overview.asp (2 of 2) [11-1-2008 15:47:07]


DSDM Public Version 4.2 - Pre-Project

Introduction When Lifecycle People Products Management Development Tailoring Other

Pre-Project

Introduction

Projects do not exist in a vacuum: they need to be set up correctly from the outset to ensure success.

Pre-project activities will depend on local working practices for the initiation of projects: however some guidance is
offered here.

The evaluation and prioritisation of projects within an organisation's portfolio is beyond the scope of DSDM.

Preconditions

A project has been proposed

Products

Initial definition of the business problem to be addressed

An outline scope for the investigation to take place during the Feasibility Study

Decision to proceed with the project

Visionary and Project Manager assigned to the project

Initial plans for the Feasibility Study

Confirmation of alignment of the project with the appropriate strategy

Budget and resources allocated for the Feasibility Study at least and preferably the Business Study as well - with
outline budget/resources approval for the development phases.

The initial project governance in place, e.g. Project Board or Steering Committee

Points to Consider

Projects get started in many different ways that determine which pre-project activities are appropriate. These include:

● How the need for the project was identified:


❍ business and/or IT strategic planning: budget will need to be allocated and resource availability will

need to be checked before the project can proceed


❍ business reaction to a problem or opportunity: alignment to business and/or IT strategies will need to

be confirmed before any funding application or planning and resourcing activities take place
❍ the project is part of an overall programme: the budget will already have been allocated, the Business

Case approved, strategy alignment will have been checked - it remains to plan the early part of the
project and obtain the resources

● Who proposes the need for the project:


❍ Some one in a position of power within the organisation can direct that the project takes place

❍ Others will need to spend time in order to gain approval for the project from key decision-makers.

http://www.dsdm.org/version4/2/public/Pre-Project.asp (1 of 2) [11-1-2008 15:48:03]


DSDM Public Version 4.2 - Pre-Project

Often lots of work needs to be done before it becomes a project. Particularly important is obtaining the resources for
the Feasibility and Business Studies and gaining outline approval for resources thereafter. Many projects falter in the
early stages due to the right people not being available and consequently lose both credibility and buy-in from all
relevant areas (both customer and supplier).

Getting a project started is often a difficult task. Moreover, there is usually no specific budget for pre-project work. This
can result in it being done around the edges of normal management responsibilities, which can only cause delays that
might otherwise be avoided.

Sometimes the pre-project requirements and plans come together naturally: other times a lot of force is needed to
make them stick. Finding the people with the right level of authority is important here.

For organisations planning to outsource a project, the pre-project work is often done in isolation of a particular supplier.
This means that much of it will need to be revisited once the contract has been awarded.

The pre-project work should be minimal, just enough to get the project off the ground and to ensure that all key
stakeholders can be involved from the start of the Feasibility Study and thereby avoid the need for later rework.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Pre-Project.asp (2 of 2) [11-1-2008 15:48:03]


DSDM Public Version 4.2 - Feasibility Study

Introduction When Lifecycle People Products Management Development Tailoring Other

Feasibility Study

Introduction

The Overview of DSDM provides a description of the Feasibility Study phase.

The Feasibility Study should only go to the level of detail required to assess whether a feasible solution exists or to
select the most appropriate one. The detail of the requirements, risks, plans, costs, etc. for the solution will be
developed in the later phases.

Objectives

To establish whether a proposed development can meet the business requirements of the organisation

To assess the suitability of the application to DSDM development

To outline possible technical solutions to the business problem

To obtain first-cut estimates of timescale and costs

Preconditions

Agreement of the scope of investigation

Initial agreement of the definition of the business problem to be addressed

Products

Feasibility Report

Feasibility Prototype (optional)

Outline Plan

Risk Log

Points to Consider

The best way to start a DSDM project is with a kick-off Facilitated Workshop to ensure that key stakeholders buy in to
the project and everybody understands their respective responsibilities at least for the early stages. This could include
agreeing the problem definition, allocating project roles, agreeing that the risks identified by examining the Suitability/
Risk List are acceptable, early requirements definition, etc. as defined in the Facilitated Workshop for the Feasibility
Report.

http://www.dsdm.org/version4/2/public/Feasibility_Study.asp (1 of 2) [11-1-2008 15:49:17]


DSDM Public Version 4.2 - Feasibility Study

The Feasibility Study phase must be kept short and sharp. Having a fixed end-date will ensure that the detailed
consideration of what will be done is correctly left until the Business Study phase.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Feasibility_Study.asp (2 of 2) [11-1-2008 15:49:17]


DSDM Public Version 4.2 - Business Study

Introduction When Lifecycle People Products Management Development Tailoring Other

Business Study

Introduction

The Overview of DSDM provides a description of the Business Study phase.

Objectives

To scope the business processes to be supported

To outline the future development in terms of prototyping deliverables (defining which are incremental and which, if
any, are throwaway) and prototyping controls

To identify representatives of the user classes for prototyping activities

To prioritise the requirements of the proposed system

To reassess the risks of the project

To provide a firm basis for technical development to proceed

To scope the non-functional requirements, in particular to decide the maintainability requirements

Preconditions

Agreement of the Feasibility Report, including agreement of the feasibility of both the development and the applicability
of the DSDM approach

Products

Business Area Definition

Prioritised Requirements List

Development Plan

System Architecture Definition

Updated Risk Log

Points to Consider

Significant business input will be required during the Business Study phase. The relevant business representatives
must be identified early and their managers must allow them sufficient time to provide effective input to the project.

http://www.dsdm.org/version4/2/public/Business_Study.asp (1 of 2) [11-1-2008 15:49:29]


DSDM Public Version 4.2 - Business Study

Facilitated Workshops are the best technique for developing Business Study products and gaining agreement to their
content as quickly as possible.

Set a time limit to the Business Study and stick to it. The aim of this phase is to create a high-level but sound view of
the business and technical basis for the project. Only produce the Business Study products to the level that allows the
project to move into Functional Model Iteration with a realistic approach to the evolution of the Business Area
Definition, Prioritised Requirements List and System Architecture Definition.

The Business Case for the project must be assessed and a conscious decision taken to continue with the work beyond
this phase: stopping a project with a poor Business Case (too risky, too costly, low benefits, etc.) should be considered
a success.

Always assess the risks of the project using the Suitability/Risk List.

Later maintenance activities have a direct impact on determining the appropriate level of quality that is built into all
business and technical products - and hence the level of quality control and assurance activities needed. The guidance
on maintenance explains what needs to be considered during the Business Study.

Either all the necessary procedures and controls should be in place before leaving the Business Study or it should be
clear how they will be ready when required. The Project Manager and the Technical Co-ordinator are the roles that are
respectively responsible for setting up the management and technical controls.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Business_Study.asp (2 of 2) [11-1-2008 15:49:29]


DSDM Public Version 4.2 - Functional Model Iteration

Introduction When Lifecycle People Products Management Development Tailoring Other

Functional Model Iteration

Introduction

The Overview of DSDM provides a description of the Functional Model Iteration phase.

Objectives

To demonstrate the required functionality using a functional model consisting of both working software prototypes and
static models (e.g. class models and data models)

To record the non-functional requirements which may not be demonstrated by the working prototype.

Preconditions

Agreement of the Business Area Definition and the Development Plan

Prototyping environment in place

Commitment by senior user management of end-user time for prototype development

Products

Functional Model including Functional Prototypes

Non-functional Requirements List

Functional Model Review Records

Implementation Plan

Timebox Plans

Updated Risk Log

Points to Consider

This phase may be merged with Design and Build Iteration for several reasons, e.g.:

● The project is too small to warrant separation of the phases.


● The tools used for development generate good quality code from models.

Also, the phase may overlap with Design and Build Iteration, since full engineering of parts of the solution can begin
before all the business functionality has been prototyped. This will be determined by the prototyping, modelling and
testing approaches chosen for the project.

http://www.dsdm.org/version4/2/public/FMI.asp (1 of 2) [11-1-2008 15:49:40]


DSDM Public Version 4.2 - Functional Model Iteration

As the Functional Model evolves through prototyping activities, record the detail of hardware and software interfaces in
the System Architecture Definition - rather than in the Functional Model.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/FMI.asp (2 of 2) [11-1-2008 15:49:40]


DSDM Public Version 4.2 - Design and Build Iteration

Introduction When Lifecycle People Products Management Development Tailoring Other

Design and Build Iteration

Introduction

The Overview of DSDM provides a description of the Design and Build Iteration phase.

Objectives

To refine the Functional Prototypes to meet the non-functional requirements

To engineer the application so that it demonstrably satisfies user requirements

Preconditions

Agreement of (part of) the Functional Model including its associated non-functional requirements

Agreement of any findings and changes of scope in the Functional Model Review Records

Design and build environment in place

Products

Timebox Plans

Design Prototypes

Design Prototyping Review Records

Tested System

Test Records

Points to Consider

A pass through the Design and Build Iteration can begin as soon as a part of the Functional Model is agreed. This
could consist of a set of paper models, some textual definitions of the processes, working Functional Prototypes. What
must be known before moving into Design and Build is the non-functional requirements that apply to this part of the
Functional Model, e.g. performance and security.

The Tested System and its associated Test Records grow incrementally and are checked as they grow during this
phase. They are delivered at the end of the last pass through Design and Build Iteration. Guidance is provided on
Testing in DSDM.

http://www.dsdm.org/version4/2/public/DBI.asp (1 of 2) [11-1-2008 15:49:50]


DSDM Public Version 4.2 - Design and Build Iteration

While the technical people on the team are working to create the Tested System, the users should be producing the
User Documentation, so that both parts are available for user training at the same time.

Do not allow too many new ideas at this stage: they will endanger the delivery date. However, keep them in mind for
later increments if they are considered of value.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/DBI.asp (2 of 2) [11-1-2008 15:49:50]


DSDM Public Version 4.2 - Implementation

Introduction When Lifecycle People Products Management Development Tailoring Other

Implementation

Introduction

The Overview of DSDM provides a description of the Implementation phase.

Objectives

To place the Tested System in the users' working environment

To train the users of the new system

To determine the future development requirements

To train operators and support staff

Preconditions

Agreement of the Tested System by all interested parties, e.g. senior user management and technical support

Training time available for users

Target environment in place

Products

User Documentation

Trained User Population

Delivered System

Increment Review Document

Points to Consider

The review of the increment must be run as soon as possible after delivery of the solution so that the next phase of
development can be planned and kicked off with as little delay as possible.

If the current increment was not originally planned to be the final increment, the project must not assume that the next
increment will happen. The end of Implementation is a go/no go point for the project.

http://www.dsdm.org/version4/2/public/Implementation.asp (1 of 2) [11-1-2008 15:50:00]


DSDM Public Version 4.2 - Implementation

Both of the above points mean that the project's governing body must evaluate as quickly as possible the Business
Case for continuing the project.

An operational system includes not only the computer system but also the people who interact with it and the business
processes they use. All of these must be successfully migrated for the solution to be considered to be delivered.

Users of the system who may require training include not only the business end-users but also people working in
support functions.

If this is the final increment and a Post-Implementation Review is planned, get the date agreed and in people's
schedules now.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Implementation.asp (2 of 2) [11-1-2008 15:50:00]


DSDM Public Version 4.2 - Post-Project

Introduction When Lifecycle People Products Management Development Tailoring Other

Post-Project

Introduction

The Post-Project phase contains the activities that occur once the project team have disbanded. These include support
and maintenance activities and (optionally) a Post-Implementation Review to assess the system in use.

Objectives

To keep the Delivered System operational.

To assess whether or not the proposed benefits of the project as stated during its initial phases have been achieved.

To enable development processes to improve.

To review the Delivered System in use.

Preconditions

The Delivered System is signed off.

Products

Post-Implementation Review Report

Change Requests

New releases of the Delivered System in response to Change Requests

Points to Consider

Once the Delivered System is in place, celebrate success, e.g. reward the project team for their efforts and publicise
what has been achieved.

Conduct a Post-Implementation Review only if it is appropriate for the size of the project.

Maintenance guidance is provided.

http://www.dsdm.org/version4/2/public/Post-Project.asp (1 of 2) [11-1-2008 15:50:29]


DSDM Public Version 4.2 - Post-Project

A DSDM-based process is provided for developing and releasing Delivered System changes.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Post-Project.asp (2 of 2) [11-1-2008 15:50:29]


DSDM Public Version 4.2 - Maintenance

Introduction When Lifecycle People Products Management Development Tailoring Other

Maintenance

Introduction

This section discusses not only maintenance but also the consideration that should be given to maintainability as early
as possible in a development project.

One possible approach to changes to the system is to rewrite the area requiring change rather than amending it.
Producing a maintainable system is not incompatible with this approach. Each change to the system will have to be
reviewed on its own merits for cost and timescale of amendment and for rewriting. It is essential to be pragmatic about
this when deciding the best approach for changes.

It is important during maintenance that there is still an Executive Sponsor: there should be an Executive Sponsor for
both development and maintenance. There should also be an IT sponsor for maintainability.

All maintenance work should be prioritised with the users so that only high priority and value for money needs of the
business are met. This then saves the maintenance budget and resource capacity for the real requirements to meet
business objectives. A DSDM-based Delivered System Change Process for use in such maintenance activities is
provided.

The need to consider maintainability issues early

Maintenance is a fact of life since the business needs change, so although maintenance is necessarily in the Post-
Project phase, it has to be considered from the very beginning of the project. Computer systems with poor
maintainability:

● take more resources in maintenance


● take longer to change
● are more likely to introduce further errors with change and be unreliable
● will cost more to maintain.

Computer systems with poor maintainability are a real risk to the business. In the extreme case, a new system could
rapidly become a problematic, unmaintainable legacy system so triggering user requests to replace it. Future systems
developed using DSDM must not add to the already existing and considerable industry-wide burden.

One of the principles of DSDM is particularly relevant to maintenance and maintainability: namely, fitness for business
purpose is the essential criterion for acceptance of deliverables. In other words, delivering to the business goals is what
is required. Therefore if one of the business goals is a maintainable computer system delivering good cost benefits,
then nothing is compromised by building in maintainability.

Components with poor maintainability can slow the development of future increments. Maintainability and the ability to
deliver quickly therefore go hand in hand

http://www.dsdm.org/version4/2/public/Maintenance.asp (1 of 2) [11-1-2008 15:50:45]


DSDM Public Version 4.2 - Maintenance

Maintainability in DSDM

DSDM does not ensure maintainability by itself. Maintainability is made possible by a combination of four factors: tools,
people, documentation and good practice guidelines.

Good practice guidelines cover aspects such as standards, style guides, etc.: in fact everything that would probably be
done automatically for a waterfall project and should not be forgotten in DSDM projects. If all of these aspects are
considered early in the project lifecycle, maintainability becomes a natural attribute of all computer systems delivered
and is not an overhead. Indeed they should be considered on an installation-wide basis prior to project work so that the
cost and time of setting up guidelines, etc. is not borne by the projects.

Maintainability objectives (requirements)

In a DSDM project, there are three possible choices of maintainability objectives (requirements). The decision as to
which of them applies in a given project is mandatory in the Business Study. The three levels are:

● maintainability is a required attribute of the initial delivered computer system. Here the criterion for
deployment is not just to provide the required functionality in a robust way, but that the design and code meet
a maintainability standard before the system is accepted and released to the business.

● deliver first, re-engineer later. The business priority is to elicit and implement the required functionality
quickly. The system needs a long life and to be maintainable, but the business is prepared to pay for
subsequent (behind the scenes) re-engineering after implementation.

This means a greater development cost than engineering for maintainability first time, but gives a quicker initial
delivery, and may produce a lower lifetime ownership cost than struggling for years with maintenance
problems. (This is often the case where time to market is critical - either in software for sale into a fast moving
market or in software to satisfy a fast moving business.)

● short-term, tactical solution. Earliest delivery is the target. Acceptance will not consider maintainability. It is
agreed that the computer system will be replaced or rewritten before maintenance costs become a problem.

The system, or system component, should be developed with a limited in-service life. It should be followed up
by a planned successor that is well engineered and maintainable to replace the temporary solution. This
should be seen as no more than a "stopgap" that will also act as an executable specification of functionality for
the maintainable replacement.

It is particularly important that any decision to build a tactical solution is documented, as there is a tendency for
such systems to become long-term corporate business systems.

As for all key non-functional requirements, following the decision on maintainability within the business objectives, the
risks of the chosen approach must be defined and a risk management strategy agreed.

The decision taken at the start of the project should be reaffirmed at all major milestones of the development. It is valid
for the maintainability objective to change if, for example, the timescale becomes more critical. However, any change
should not be taken lightly and the risk management strategy should be revisited.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Maintenance.asp (2 of 2) [11-1-2008 15:50:45]


DSDM Public Version 4.2 - Delivered System Change Process

Introduction When Lifecycle People Products Management Development Tailoring Other

Delivered System Change Process

Introduction

This section provides an approach to using DSDM for support and maintenance activities. It describes a procedure for
implementing change requests. The procedure will need to be tailored to align with the organisation's standard
procedures.

Change Requests

The support and maintenance team classify (e.g. as bug-fix, enhancement to the functionality provided, enhancement
to non-functional aspects, such as performance) and cost all change requests as they are received. If a change
request requires urgent attention, it will be dealt with immediately using the appropriate local procedures. Otherwise,
the process continues as follows to address a set of changes. Note: Major enhancements could warrant the use of the
full DSDM development lifecycle.

Wherever possible, a set of change requests should be bundled together and treated as a DSDM project with iterative,
incremental development and active user involvement. The rest of this section describes a DSDM approach to tackling
such a bundled set of change requests.

The assumption is that the maintenance team consists of Team Leader, Developers and Testers and that the level of
Ambassador User involvement will be low.

Timeboxing approach

Every effort should be made to gain consensus between IT and business management for an agreed schedule of
deliveries of system changes.

However, rock-solid timeboxing is unlikely to be achievable in a maintenance project because of the likelihood that staff
will need to react to requests for immediate help on an ad hoc basis. Depending on the effort required for the
immediate work, the changes that are being developed may have to be put on hold. Once the problem has been
resolved, the maintenance team will determine the impact on the work on hold and then agree with the relevant
business managers any necessary corrections to the change delivery schedule.

Planning

This part of the process is the equivalent of a Business Study.

An initial Facilitated Workshop is run to decide the scope of the next set of delivered changes - taking into account both
business need and technical constraints. This means that the active participants must include customer managers from
all relevant areas, knowledgeable end-users from the same areas and the support and maintenance team.

http://www.dsdm.org/version4/2/public/Delivered_System_Change.asp (1 of 2) [11-1-2008 15:50:56]


DSDM Public Version 4.2 - Delivered System Change Process

The enhancements within the agreed scope are prioritised using the MoSCoW rules: this can be done in the initial
workshop.

The delivery date (or schedule of dates) is agreed. This can also be done in the initial workshop. If the (first) delivery
date is immovable, it is essential that not everything within the set of changes to be tackled is a Must Have. The same
constraints about having room for manoeuvre by dropping requirements of lower priority apply as in any DSDM
development project.

Having agreed the scope, prioritisation and delivery date(s), the maintenance team leader produces a detailed plan up
to the delivery date (with any further delivery dates shown as milestones with little detailed planning between them).

For each delivery, Ambassador Users should be identified who

● can participate in decision-making during the maintenance work, including the possibility of making decisions
about de-scoping the delivery or changing the priorities within it
● are given the responsibility for accepting work on an ongoing basis.

Build phase

This part of the process is the equivalent of Functional Model Iteration and Design and Build Iteration.

The changes are designed, coded and tested by themaintenance team, with the Ambassador Users clarifying
requirements as necessary.

Wherever possible, the following should be done on a frequent basis:

● The tested changes are shown to the Ambassador Users as soon as possible
● The Ambassador Users produce notes that supplement the system's User Documentation and that describe
the changes that they see from a user point of view
● The Ambassador Users use the notes as a basis for their acceptance tests
● The Ambassador Users perform acceptance tests incrementally.

Towards the end of the Build phase, the Ambassador Users use their notes to update the user Documentation.

Prior to the delivery date, the maintenance team will have completed all necessary system and integration testing of
the changes and have updated the relevant technical documentation.

Implementation

The changes are delivered to the operational environment.

The Ambassador Users are responsible for ensuring that:

● All relevant users receive any necessary training


● The updated User Documentation is published
● Defects identified by other users are reported promptly to the maintenance team.

Outstanding change requests are reviewed and potentially reprioritised.

The process returns to the planning phase to confirm the contents and date of the next delivery of system changes.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Delivered_System_Change.asp (2 of 2) [11-1-2008 15:50:56]


DSDM Public Version 4.2 - People Overview

Introduction When Lifecycle People Products Management Development Tailoring Other

People Overview

Introduction

People working together effectively is the foundation of any successful project. DSDM recognises this and assigns clear roles
and responsibilities to each person in a project, both from the customer and supplier side of the project. These two
communities work very closely together in DSDM projects - there is no "us and them".

The first part of this section covers the DSDM roles. The rest of the section describes how teams operate and are organised
in DSDM projects.

People and roles in DSDM projects

The DSDM roles to be filled are listed below. It is emphasised that these roles do not necessarily relate to individuals on a
one-to-one basis. One person may cover two or more roles, and a role could be split between two or more people. For
instance, on a large project, the Technical Co-ordinator's responsibilities will probably be split across more than one person, e.
g. the System Designer/Architect, Project Quality Manager and Project Configuration Manager.

The roles allow for a large project, split into a number of development teams working concurrently, or at least overlapping in
terms of the development time frame. In smaller projects some of the roles, for example that of Project Manager and Team
Leader, would probably be held by one person.

It is understood that such things as geographical constraints and staff availability can impact the setting up of the ideal team,
but it is strongly recommended that the roles are all considered and their individual responsibilities assigned as appropriate.
They can be used as the basis for personal terms of reference for the project.

Project Roles defined in DSDM Executive Sponsor


Visionary
Ambassador User
Advisor User
Project Manager
Technical Co-ordinator
Team Leader
Developer
Tester
Scribe
Other roles defined in DSDM Facilitator
Specialist Roles

Team dynamics

The main benefits of the DSDM approach arise from users (customers) being closely involved in the development teams. So
what is the best team structure for a DSDM project to maximise the benefit of user involvement? It is important that the team
is not too large, ideally no more than six people including users. The users must be allocated the time to really get involved,
and feel involved, so that they take ownership of the application being built.

Given that a team should not exceed six people, the number could be as few as two, with the optimum being three or four.
The important thing is that the team "works" in the prevailing environment. The following are all examples that have been
successfully used in practice:

● One user, one developer working as a pair. Although simple, this can prove a very successful method of creating
strong user/developer partnerships. The Tester role should be held by somebody else if the size of the project
permits.
● Two users, one or two developers. The users spark off each other to create a solution "greater than the sum of the

http://www.dsdm.org/version4/2/public/Roles_Overview.asp (1 of 4) [11-1-2008 15:51:12]


DSDM Public Version 4.2 - People Overview

parts", while the developers chip in. If two developers are used, then they should test each other's work.
● One user, one experienced DSDM developer, one non-DSDM experienced developer, who learns the DSDM
approach by participation. Each developer takes on the role of Tester for the other's work.

The decision as to how to compose the team depends on both personalities and practicalities. It is important to give
consideration to what mix of team will be most likely to produce a good result quickly. The Project Manager should be
prepared to change the structure if it is not working. However care should be taken that breaking up relationships that have
developed does not endanger the progress of future work.

Sometimes large teams will be necessary: the Large Teams section provides guidance on how to make these work effectively.

The anti-fault philosophy

Traditionally in IT/IS projects, the functional specification has been used as the final arbiter of what is or is not in scope or
intended. When the requirements are vague or ambiguous, the way is open for arguments and recriminations as to whose
fault it is, who should pay, and whether the developer should have known "because it was obvious". Joint responsibility and
development avoid this, but if traditional roles and ideas are allowed to persist, the dangers are greater. If developers and
users do not work together as a team and if they adopt their traditional roles and positions, there is no detailed specification to
refer back to.

It is essential that individual responsibility is understood and taken, but also that, as in any team, if problems do develop, it is
seen as a team failure rather than an individual's, and that the team continues to work together to resolve the difficulty. Users
and developers have equal responsibility for the development.

Organising the DSDM roles into project teams

The diagram below shows the possible relationships between the DSDM roles and the organisation and project infrastructure.

The DSDM project organisation

http://www.dsdm.org/version4/2/public/Roles_Overview.asp (2 of 4) [11-1-2008 15:51:12]


DSDM Public Version 4.2 - People Overview

Below are two examples of possible project structures showing how one individual may undertake multiple roles. In the
diagrams, an ellipse represents an individual. Its contents represent the roles undertaken by that individual. The lines
represent the typical lines of communication, rather than a reporting structure. Role names in red show full participation, the
lighter role names are less than full time. To simplify the network of communication inside a development team, teams are
represented as a ring with nodes. Note: the full participation of Ambassador Users is the ideal but it is recognised that this
may not be achievable.

Larger Project

A project with two teams

A smaller project with only one team, so far more role consolidation of roles but similar relative responsibilities

http://www.dsdm.org/version4/2/public/Roles_Overview.asp (3 of 4) [11-1-2008 15:51:12]


DSDM Public Version 4.2 - People Overview

Team management

In a DSDM team, the issue of how to organise the team structure and management arises. Within a peer team, roles are
discussed and allocated by the team members based on an appraisal of each individual's inherent skills, personal
characteristics and experience.

In general, traditional hierarchical team structures do not encourage the flexible working practices and open communications
so necessary for the DSDM approach to work, but the team members may decide to adopt any structure that works for them.
Since DSDM teams are a temporary social structure that must be effective from the very start, extra effort in building the team
mentality is essential when the team is originally formed. Team-building activities are strongly recommended early on and
whenever it is necessary to bring in a new team member.

The Project Manager can be from the business or the IT department. However, the basic rules are that the Project Manager
must:

● understand the business issues


● empathise with the users
● understand the technical issues.

The last consideration means that usually Project Managers come from an IT background, as their skills in computer system
development have been acquired over many years. It is unrealistic to expect user personnel to understand all the IT-related
issues that have to be addressed, without some direct support from the IT department. On large projects the Project Manager
would not be part of any individual team, and could manage more than one project concurrently.

One important aspect of the Project Manager role is that of arbitration. Where there is discussion about the relative priorities
or merits of some aspect of the system under development, the Project Manager does not supply the decision but assists the
parties involved in deciding the best approach for the project.

Motivating the team should not be too much of a problem in the early stages of the project. However if things start to go wrong
the impetus to deliver can disappear. User team members are particularly prone to losing their initial enthusiasm, since they
are not so inured to the many setbacks that can face an IT project. To avoid this, the team should plan for social activities that
enable the team to get together and talk about things other than work.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Roles_Overview.asp (4 of 4) [11-1-2008 15:51:12]


DSDM Public Version 4.2 - Large Teams

Introduction When Lifecycle People Products Management Development Tailoring Other

Large Teams

Introduction

Large teams bring particular challenges for a DSDM project and will require strong project management skills to be
handled appropriately. Certain control mechanisms can be put into place, but the leadership required should not be
underestimated. It is therefore imperative that the project has an experienced Project manager, who has run previous
DSDM projects and has also dealt with large teams.

Given this, the following suggests some techniques that may help to ensure success.

Note: Further guidance is available in the Large Projects section.

Structure

DSDM, and probably all projects, works best with small, focussed teams. However, sometimes a project may require a
large number of personnel either to complete the project in a given time frame or because of the areas of technical and
business expertise required. In the latter case, it is always worth asking the question:

● Is everyone really a core team member or are some people Advisor Users or technical experts, whose time is
required only for specific workshops, etc.?

This question may result in a perceived large project only having a small core team.

When a project does really require a large team, the Project Manager should make every effort to partition the project
into complete pieces of work that can be executed by small, focussed teams. This is normally carried out towards the
end of the business study, and can use the horizontal / vertical partitioning techniques to split the work into parallel
teams as shown the larger team diagram in the People Overview.

Co-ordination

Having split the project into small, focussed subteams, it is important that all subteams know and are understand the
"big picture". As well as the Project Manager, the Technical Co-ordinator plays an important role to ensure the
concepts formulated in the System Architecture Definition are maintained. It may also be necessary to have a special
Technical Co-ordination subteam supporting the project overall. This would contain expertise in database
administration, the operating system (e.g. UNIX), development and configuration management tools.

Both the Technical Co-ordinator and other technical experts can play an important role in passing information between
teams, and ensuring consistency. The Project Manager should promote this role.

http://www.dsdm.org/version4/2/public/Large_Teams.asp (1 of 2) [11-1-2008 15:51:27]


DSDM Public Version 4.2 - Large Teams

The Team Problem

The formation of small teams will help to ensure the well-focussed, motivated and empowered approach DSDM
requires, but has some challenges for the Project Manager.

Inter-team collaboration

A team is, by nature, self-motivated towards achieving its own defined goals. Teams can also be quick to blame other
teams for any problems or issues. The Project Manager must work hard to foster a collaborative and co-operative
approach between teams as well as within the teams. He or she must also encourage a "No Blame" culture - nipping
any cross-team sniping in the bud.

Team boundaries and interfaces (both human and technical) must be clearly defined, hence helping to define the level
of empowerment. Escalation procedures must be in place for when empowerment tolerances are breached. Whilst
teams must be allowed to progress autonomously, the Project Manager must be conscious that a team leader may
filter information, both from the Project Manager through himself to the team, or vice versa. This could lead to
misunderstandings, so effective communication methods are vital.

Communication

Communication is key to success for projects with a number of teams. It is important that all subteams remain aware of
the big picture and know the state of all the concurrent subprojects. This awareness will help to foster a sense of
belonging to the whole project, not just to their part of it.

Whilst collocation may not always be feasible, it is important for the whole project team to meet regularly - for instance
weekly. The meeting should be as short as possible - ½ hour may be a good duration. The purpose of the meetings is
to encourage an esprit de corps, to dispel myths and rumours and to ensure that everyone is correctly informed about
the project and its status. Ideally, these meetings should be face-to-face. If this is not possible, telephone or
videoconferences could be used, but it is easy for people not to attend these.

Regular daily meetings should also be held within each subteam. These should be open so that members of other
teams can attend: rotating attendance through the team members should be encouraged. The Project Manager should
also attend daily meetings as needed to keep a finger on the pulse.

The Project Manager should also take every opportunity to talk to individual team members. This ensures that
consistent information is being passed and also gets the current feelings of the project workers. This must be done with
caution and tact: the Project Manager must not be perceived as interfering in team decisions.

In addition, all project information should be easily accessible, for instance in shared central folders. This should
include subproject information. It is wise to maintain a central repository for recording any risks, actions, issues and
decisions relating to the project.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Large_Teams.asp (2 of 2) [11-1-2008 15:51:27]


DSDM Public Version 4.2 - XP And Teams

Introduction When Lifecycle People Products Management Development Tailoring Other

XP and Teams

Basic XP Concept

Although XP explicitly mentions a number of roles, it prefers to emphasise the ‘whole team’ culture whereby everyone
contributes to ensure that all required tasks are performed and the goals of the project achieved.

Early versions of XP advocated a single team with an on-site customer however this did not explicitly address some of
the other supporting roles and in essence made the Onsite Customer as the sole communication channel and decision
maker from a requirements and acceptance perspective. Current thinking is much more towards a single unified team
with a variety of customer roles to reflect the needs of the project. Further to this XP identifies roles such as Tracker
(metrics gatherer and progress checker), Coach (process mentor) and, where appropriate, Manager and Tester.

Assessment of XP

The XP concept of a Tracker provides a good way of explicitly keeping overall progress 'on track’. The philosophy of
having a Coach helps to steer and fine-tune the development process as it happens and to make sure the team is
applying their development practises.

It should be noted that, similar to DSDM roles, these roles are not necessarily full-time jobs for one individual and can
be seen as components of a multi-skilled team.

Two possible drawbacks with the XP approach to roles are:

● There are no formal role descriptions for each role and larger projects may suffer from this lack of clarity e.g.
duplication of effort and omissions
● The two-team culture could create a “them and us” divide if not managed appropriately which would eat away
at the ‘whole team’ principle.

Guidance when using XP

When using XP with DSDM it is felt that the DSDM definition of roles and responsibilities provides a more complete
and rigorous definition of what is required. DSDM role responsibilities can be used to make sure that, if roles are
removed or combined, no responsibilities fall down the gaps between roles.

It is also important to bear in mind that DSDM specifically addresses some interpersonal issues, such as team
dynamics, by embracing such techniques as facilitation and facilitated workshops. It is possible that the XP technique
of pair programming would be enhanced by facilitative techniques such as active listening.

The following table provides a cross-reference between DSDM and XP roles:

The formation of small teams will help to ensure the well-focussed, motivated and empowered approach DSDM
requires, but has some challenges for the Project Manager.

DSDM Role XP Role


Executive Sponsor Big Boss
Visionary Part of the Customer Team (Customer)
Ambassador user Part of the Customer Team (Customer)
Advisor User Part of the Customer Team (Customer)
Team Leader Would include the role of 'Coach'

http://www.dsdm.org/version4/2/public/XP_And_Teams.asp (1 of 2) [11-1-2008 15:51:41]


DSDM Public Version 4.2 - XP And Teams

Manager. In a similar way to DSDM, the manager is more of a


facilitative role, i.e. tasked with removing obstacles that stop
Project Manager
the team working effectively, rather than the more traditional
controlling role.
Developer Development Team (Developers) - may include 'Tracker'
Tester. A separate tester role is often used to work with the
Tester
customer to define acceptance tests.
Technical Co-ordinator Not defined as a separate role. Fits within the role of an XP Developer
Facilitator and Scribe Covered within the Development Team
Scribe Not covered by XP

XP’s emphasis on the process coach is worthy of note because this type of coaching may be low on the list of priorities
for a DSDM team leader – it may even be a role that lies outside the core team, e.g. with a process mentoring team or
QA. There are several advantages with continual assessment of process, in addition to the usual reviews, such as
timebox Close-out meetings (called retrospective meetings in XP) which suggests that, at the very least, this
responsibility should be high on the list of a Team Leader’s list of priorities.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/XP_And_Teams.asp (2 of 2) [11-1-2008 15:51:41]


DSDM Public Version 4.2 - Executive Sponsor

Introduction When Lifecycle People Products Management Development Tailoring Other

Executive Sponsor

Introduction

This is a high-level business role. The Executive Sponsor is the "Project Champion" who is committed to the project, its
approach and wants the system. The role ultimately "owns" the system and has responsibility for it. The Executive
Sponsor must hold a sufficiently high position in the organisation to be able to resolve business issues (e.g. to force
open closed doors) and make financial decisions. This role has a crucial responsibility to ensure and enable fast
progress throughout the project, cutting through the bureaucracy and politics that impede development.

Attributes

● Ability to commit appropriate funds and resources


● Ability to question
● Decisiveness
● Political awareness
● Business knowledge

Responsibilities

● Ensuring the decision-making process for escalated project issues is effective and rapid
● Responding to escalated issues
● Ensuring that funds and other resources are made available as needed
● Monitoring the continued business case for the project
● Commitment and availability throughout the development cycle.

Typical Phase-by-Phase Activities

Pre-Project Determine the need for the project and that is in line with the business
strategy

Allocate someone to the Visionary role for the duration of the project

Obtain initial funding for the Feasibility and Business Studies

Agree the approach to project governance with the relevant parts of the
organisation (see the Project Organisation diagram)

Commit the necessary business resources to the Feasibility Study, e.g.


especially Ambassador Users and Advisor Users as requested by the
Project Manager

Ensure that planning, co-ordination and management responsibilities


for both the IT/IS project and any associated business change are
clearly assigned to the relevant people.

http://www.dsdm.org/version4/2/public/Executive_Sponsor.asp (1 of 3) [11-1-2008 15:47:34]


DSDM Public Version 4.2 - Executive Sponsor

Feasibility Study Monitor project governance

Respond to issues escalated by the Visionary

Review/approve the Risk Log

Review/accept the Outline Plan (or not: the project can stop here if no viable
solution is possible)

Commit the necessary business resources to the Business Study


Business Study Monitor project governance

Respond to issues escalated by the Visionary

Review/approve the Risk Log

Approve the Business Case for the project to proceed beyond the
Business Study and obtain funding as necessary

Review/agree the Development Plan (or not)

This is a major go/no go decision point in the project

Commit the necessary business resources to the rest of the project


Functional Model Iteration Monitor project governance

Respond to issues escalated by the Visionary


Design and Build Monitor project governance
Iteration
Respond to issues escalated by the Visionary
Implementation Monitor project governance

Respond to issues escalated by the Visionary

Review/approve the Risk Log

Review/approve the Increment Review Document

Sign off the Delivered System

Determine whether or not the project is to deliver another increment or stop


now
Post-Project Ensure that the Post-Implementation Review is run if appropriate to the
size of project - especially to prove that the Business Case has been
achieved

Points to Consider

http://www.dsdm.org/version4/2/public/Executive_Sponsor.asp (2 of 3) [11-1-2008 15:47:34]


DSDM Public Version 4.2 - Executive Sponsor

The Executive Sponsor role and Visionary role may be held by the same person

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Executive_Sponsor.asp (3 of 3) [11-1-2008 15:47:34]


DSDM Public Version 4.2 - Visionary

Introduction When Lifecycle People Products Management Development Tailoring Other

Visionary

Introduction

The Visionary is a business role. The Visionary is the one who is usually responsible for getting a project started
through enthusiasm and commitment to the idea and business goals. The Visionary should remain involved throughout
the design and delivery process to ensure the original objectives are being met. If any issues arise during the project,
which must be considered by higher management, the Visionary will either provide the decision or provide higher
management with the business viewpoint.

The Visionary role ensures the project excellence from the business point of view and the Technical Co-ordinator does
the same from the technical point of view.

Skills

● Excellent communicator
● Excellent awareness of business goals
● High-level awareness of technological possibilities.

Responsibilities

● Promoting the translation of the vision into working practice


● Taking a wider view of the end-to-end business process
● Contributing to key requirements sessions
● Contributing to key design sessions
● Contributing to key review sessions
● Resolving conflicts across the business areas owned by the Visionary
● Ensuring user resources are available as needed
● Monitoring progress in relation to the original vision
● Commitment and availability throughout the development cycle

Typical Phase-by-Phase Activities

Pre-Project Attend DSDM training if this is the first DSDM project.

Agree with the Executive Sponsor to taking on the Visionary's


responsibilities for the duration of the project

Commit the necessary business resources to the Feasibility Study, e.g.


especially Ambassador Users and Advisor Users as requested by the
Executive Sponsor and Project Manager.

http://www.dsdm.org/version4/2/public/Visionary.asp (1 of 4) [11-1-2008 15:52:06]


DSDM Public Version 4.2 - Visionary

Feasibility Study Participate in the project kick-off workshop (if one is run)

Participate in Facilitated Workshops to create the Feasibility Report and the


Outline Plan.

Escalate issues as necessary to the Executive Sponsor.

Review/accept the Feasibility Report, the Feasibility Prototype (if it produced) and
the Outline Plan.

Advise the Executive Sponsor as to whether or not to continue into the Business
Study.

Review/accept the Risk Log.

Business Study Participate in key Facilitated Workshops to create the Business Area
Definition, the Prioritised Requirements List (applying the MoSCoW
rules) and the Development Plan.

Escalate issues as necessary to the Executive Sponsor.

Review/accept the Business Area Definition, the Prioritised


Requirements List and the Development Plan.

Advise the Executive Sponsor as to whether the project should proceed


or not.

Agree the level of empowerment to be given to Ambassador Users in


the project.

Review/accept the Risk Log.

Agree with the Project Manager how and when progress will be
reported and issues will be dealt with for the rest of the project.

If other commitments prevent the level of participation really needed by


the project, deputise someone else to stand in during necessary
absences of the key Visionary role or, for the sake of continuity,
consider handing over the responsibilities now.
Functional Model Iteration For each business-critical timebox, review/accept the Timebox Plan

Depending on the importance from the business point of view of a particular


timebox, do some or all of the following:

● Attend the kick-off meeting


● Attend workshops/prototyping sessions/reviews during the timebox as
agreed in the Timebox Plan.
● Attend the Closeout meeting

During development activity, receive regular reports (formally or informally) from


the Ambassador Users about progress and acceptability of what is being created.

With assistance from the Ambassador User(s) who will have in-depth
understanding of what has been created, review/accept the evolving Functional
Model (including Functional Prototypes, models, and other documentation) as it is

http://www.dsdm.org/version4/2/public/Visionary.asp (2 of 4) [11-1-2008 15:52:06]


DSDM Public Version 4.2 - Visionary

delivered by individual timeboxes.

Respond to issues raised by the Ambassador Users and the Project Manager.

Escalate issues as necessary to the Executive Sponsor.

Review/accept the Risk Log.


Design and Build For each business-critical timebox, review/accept the Timebox Plan
Iteration
Depending on the importance of a particular timebox, do some or all of
the following:

● Attend the kick-off meeting.


● Attend workshops/reviews during the timebox as agreed in the
Timebox Plan.
● Attend the Closeout meeting.

Enable business people other than the Ambassador Users to


participate in testing as defined in the Development Plan.

During development activity, receive regular reports (formally or


informally) from the Ambassador Users about progress and
acceptability of what is being created.

Escalate issues as necessary to the Executive Sponsor.

Review/accept the Tested System with assistance from the


Ambassador Users.

Review/accept the Risk Log.


Implementation Participate in the Increment Review workshop

Review/accept the Increment Review Document.

Sign off the Delivered System, the final User Documentation and the Trained User
Population, i.e. that user training has been completed successfully.

Advise the Executive Sponsor as to whether or not the project is to deliver another
increment or stop now.

Post-Project Participate in the Post-Implementation Review if it is run. If it is, also


review/accept the Post-Implementation Review Report.

Points to Consider

The Visionary and Executive Sponsor roles may be held by the same person.

The Visionary has the high-level view of the original reasons for initiating the project: this must not be dissipated during
development. Unfortunately, this happens in many projects. It is very easy once development is under way to involve
only those staff who will use the computer system on a day-to-day basis but who, perhaps, do not fully understand all
the business vision. This can result in a dilution of the original goals and a tendency towards simply re-specifying the
system to be replaced. It is imperative that the Visionary is present when important user events occur or when
management decisions about the progress of the project are made.

http://www.dsdm.org/version4/2/public/Visionary.asp (3 of 4) [11-1-2008 15:52:06]


DSDM Public Version 4.2 - Visionary

The Visionary must commit business staff to the project as Ambassador Users. These people should be available to
the project on a continuous basis throughout the life of the project - not necessarily full-time but "contracts" for the
Ambassador Users time should be agreed with the Project Manager before leaving the Business Study phase, e.g.
"Ambassador User X will work in the project team every Monday, Wednesday and Friday morning". The Advisor Users
involvement will be more ad hoc but should be well planned in advance.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Visionary.asp (4 of 4) [11-1-2008 15:52:06]


DSDM Public Version 4.2 - Ambassador User

Introduction When Lifecycle People Products Management Development Tailoring Other

Ambassador User

Introduction

The Ambassador User generally comes from the business area being addressed and becomes an integral part of the
development team. The role provides the key focus for design decisions. Working closely with the Team Leader,
Developers, Testers and the Technical Co-ordinator, the Ambassador User drives the system design, bringing other
users' input and ideas to the various sessions and keeping the other users informed of what is happening.

The holder of the Ambassador User role must have the desire, authority, responsibility and knowledge to be able to
ensure that the right system is built for the business. This does not necessarily imply a senior position within the
organisation, but a level of empowerment during the project to fulfil the role and a clear allocation of time to participate
in the project as required.

Skills

● Knowledge of the relevant business area goals and the organisation politics
● High-level view of how the computer system should function to support the business
● Good communication skills
● Ability to disseminate knowledge and ideas.

Responsibilities

● Providing key input to business requirements and design sessions


● Providing the detail of business scenarios
● Communicating with other users and getting their agreement
● Providing input into prototyping sessions
● Reviewing documentation
● Reviewing and accepting delivered software
● Providing user documentation
● Ensuring user training is adequately carried out
● Organising and controlling user testing

Typical Phase-by-Phase Activities

Pre-Project Attend DSDM training (This is essential the first time on a DSDM
project in order to understand key concepts such as timeboxing and
prioritisation and the importance of the Ambassador User role to
success.)
Feasibility Study Participate in the project kick-off workshop (if one is run)

Participate in Facilitated Workshops to create the Feasibility Report and the


Outline Plan

Agree to participate at the level requested throughout the project

http://www.dsdm.org/version4/2/public/Ambassador_User.asp (1 of 3) [11-1-2008 15:52:18]


DSDM Public Version 4.2 - Ambassador User

Business Study Participate in Facilitated Workshops to create the Business Area


Definition, the Prioritised Requirements List (using the MoSCoW rules)
and the Development Plan

Review/accept the Business Area Definition and the Prioritised


Requirements List from the user point of view

Get agreement from the Visionary as to the level of empowerment that


can be exercised during the subsequent phases (perhaps agree formal
Terms of Reference)
Functional Model Iteration Work each week in a development team at the times agreed during the Business
Study reporting to the nominated Team Leader within the project (or on smaller
projects to the Project Manager)

Attend the planning meetings and reviews defined in the timebox process and
agree to actions arising from these (e.g. agree the Ambassador User involvement
in the Timebox Plan created at the Timebox kick-off meeting)

Between these meetings and reviews:

● Provide the Developers in the team with detailed information about the
business, e.g. how the business works and what information is needed
when, where and by whom
● Define the business tasks and scenarios that the system will support
(Create them just in time rather than all in one go)
● Use the task descriptions and scenarios as the basis of testing prototypes
as they are built
● Accept prototypes as satisfactory from the business point of view
● Get detailed business information from the relevant Advisor Users
● Demonstrate prototypes to Advisor Users to get their feedback
● Check that all comments are satisfactorily recorded by the Scribe in the
Functional Model Review Records
● Participate in workshops as necessary
● Negotiate with the Team Leader, Developers and Testers as to what must
be done within a timebox and what can be left out
● Participate in modelling sessions with the Developers to provide the
business view
● Review/accept the models as they are produced
● Keep the Visionary and the Advisor Users up to date with what is
happening in the team
● Attend daily meetings if at all possible

Assist the Project Manager in creating the user training strategy part of the
Implementation Plan

Review/accept the Non-functional Requirements List from the user point of view, e.
g. how quickly the system should respond to user input: time to create reports,
display information on screens, etc.

http://www.dsdm.org/version4/2/public/Ambassador_User.asp (2 of 3) [11-1-2008 15:52:18]


DSDM Public Version 4.2 - Ambassador User

Design and Build Work each week in a development team at the times agreed during the
Iteration Business Study

Attend the planning meetings and reviews defined in the timebox


process

Between these meetings and reviews:

● Provide the Developers in the team with detailed information


about the business needs
● Use the business tasks and scenarios created earlier to test the
system as it grows
● Arrange testing by Advisor Users, if necessary
● Accept parts of the system as they pass their tests from the
user point of view (as opposed the technical tests that will also
be run)
● Negotiate with the Team Leader, Developers and Testers as to
what must be done within a timebox and what can be left out
● Create the User Documentation
● Ensure that appropriate training is being designed for delivery to
all other users
● Keep the Visionary and the Advisor Users up to date with what
is happening in the team
● Attend daily meetings if at all possible

Implementation Monitor the initial user training and collect feedback from the trainees

Make any necessary changes to the User Documentation that surface during user
training

Participate in the Increment Review workshop

Review/accept the Increment Review Document

Post-Project Participate in the Post-Implementation Review if it is run

Points to Consider

Ambassador Users must be representative of the entire community of users. The whole user community should see
them as such - not just the user management. They must have authority delegated to them to make decisions and to
guide the work of the developers. This is particularly important when considering changes of scope due to time
limitations.

Ambassador Users should have a positive attitude towards the development since they will be exposed to a whole raft
of new ideas and technologies that can be daunting.

Although the ideal situation is for Ambassador Users to be on the project full-time, this is often not possible. It is
perfectly acceptable for an Ambassador User to be part-time. However, the presence on the project needs to be
continuous, e.g. at specified times of the day and/or on agreed days of every week.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Ambassador_User.asp (3 of 3) [11-1-2008 15:52:18]


DSDM Public Version 4.2 - Advisor User

Introduction When Lifecycle People Products Management Development Tailoring Other

Advisor User

Introduction

The Advisor User brings day-to-day knowledge of the job being automated. The holder of this role will probably be one
of the people who will use the computer system when it is complete.

Skills

● Practical knowledge of the business area


● Ability to communicate knowledge and ideas.

Responsibilities

● Providing information on request


● Participation in the prototyping and review processes offering advice and guidance on issues of practical
import
● Approval of designs and prototypes as acceptable for use
● Assisting with business and usability testing.

Typical Phase-by-Phase Activities

Pre-Project
Feasibility Study Participate in Facilitated Workshops to create the Feasibility Report if requested by
the Visionary

Agree to participate at the level requested throughout the project


Business Study Participate in Facilitated Workshops to create the Business Area
Definition if requested by the Visionary
Functional Model Iteration Provide business information if requested by the Ambassador User(s)

Participate in prototype reviews and workshops if requested by the Ambassador


User

Participate in testing if requested by the Ambassador User

Provide feedback to the Ambassador User about the system under development
Design and Build Participate in testing and reviews if requested by the Ambassador User
Iteration
Implementation Participate in training and provide feedback on the training, the system and the
User Documentation

Post-Project Use the system and provide feedback through the specified channels

Participate in the Post-Implementation Review if requested by the


Visionary

http://www.dsdm.org/version4/2/public/Advisor_User.asp (1 of 2) [11-1-2008 15:52:30]


DSDM Public Version 4.2 - Advisor User

Points to Consider

The Advisor User role may be held by a panel of people who attend workshops and workshop-style presentations of
prototypes. In this way the breadth of user experiences can be captured in a dynamic environment.

Outside pre-arranged events, the Ambassador User role provides the two-way channel for information about the
project to the Advisor Users.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Advisor_User.asp (2 of 2) [11-1-2008 15:52:30]


DSDM Public Version 4.2 - Project Manager

Introduction When Lifecycle People Products Management Development Tailoring Other

Project Manager

Introduction

The Project Manager can come from the user community or from IT. The role operates outside the individual
development teams. Overall responsibility is for ensuring that all aspects of the project solution are delivered (whether
business or IT), together with responsibilities for co-ordination and reporting to management.

Skills

● Good communication ability


● Project planning and management skills
● Awareness of the organisation's politics
● Business awareness
● Problem solving abilities - for both technical and personnel problems

Responsibilities

● Reporting to senior management and the steering committee


● Project planning and scheduling
● Monitoring progress
● Risk management
● Targeting and motivating the teams
● Setting team objectives
● Chairing project meetings
● Management of user involvement with the development teams (for example, ensuring availability)
● Exception handling
● Identifying and calling in Specialist Roles as required
● Handling problems escalated from the project teams
● Coaching the development teams when handling difficult situations.

Typical Phase-by-Phase Activities

This section highlights the activities that are particular to DSDM projects. It does not cover all the usual activities such
as reporting progress, etc. as these will differ from project to project and organisation to organisation.

Pre-Project If this is the first DSDM project, attend DSDM training (1-day
Awareness plus 2-day Project Management) and, if possible, find a
DSDM mentor from inside or outside the organisation.

Initial Planning (The project planning section covers planning


throughout a DSDM project including useful hints and tips.)

Check the project against the Suitability/Risk List. Many of the


questions will be difficult/impossible to answer at this stage but definite
answers to all questions must be possible by the end of the Business
Study.

Agree the project de-commit criteria now with the Visionary and/or
Executive Sponsor.

http://www.dsdm.org/version4/2/public/Project_Manager.asp (1 of 4) [11-1-2008 15:52:41]


DSDM Public Version 4.2 - Project Manager

Open the Risk Log now.

See the Feasibility Study's Product Descriptions for ideas about the
respective responsibilities of the DSDM roles.

Obtain initial agreement from the Visionary/Executive Sponsor about


tolerance/empowerment levels for the business people in the Feasibility
and Business Study phases at least.

Confirm user involvement "contracts", even on internal projects: this


helps immediate escalation of problems.

Arrange for DSDM training for all people new to the method. Be aware
of roles external to the project: assess the impact on and from these
areas and determine whether they would benefit from Awareness
training.

Ensure that a Facilitator is available for the workshops in Feasibility


Study and the Business Study: they are crucial to the success of
DSDM on all but the smallest projects.
Feasibility Study Set up the Feasibility Study team.

Attend all workshops; otherwise decisions may be made that make the project
unmanageable.

Review/accept the Feasibility Report. Get the Feasibility Report signed off. Any
procrastination at this point should ring alarm bells as to the viability of achieving
delivery dates.

Ensure that all key stakeholders have bought in to the Prioritised Requirements
List and the proposed timescales for (incremental) delivery for the project.

Create a high-level Business Case for the project.

Create the Outline Plan. See the Business Study's Product Descriptions for ideas
about the respective responsibilities of the DSDM roles.

Get Business Study workshop dates into people's schedules now.


Business Study Manage production of the Business Study products.

Attend all workshops.

Revisit the Suitability/Risk List and update the Risk Log.

Create the Development Plan jointly with all relevant people, e.g. the
Technical Co-ordinator for the Testing and Configuration Management
Strategies, the Team Leader(s) for the timebox schedule as described
in the Timeboxing section. Use the Functional Model Iteration and
Design and Build Iteration Product Descriptions to determine individual
responsibilities within the project.

Refine the Business Case and get it agreed by the relevant people, e.g.
the Executive Sponsor.

http://www.dsdm.org/version4/2/public/Project_Manager.asp (2 of 4) [11-1-2008 15:52:41]


DSDM Public Version 4.2 - Project Manager

On the basis of the plan and the Business Case (including cost/
benefits, risks, etc.) obtain agreement to proceed into development
from senior management, e.g. the Executive Sponsor and Visionary.

Ensure that all Team Leaders are aware of the contents of the
Business Case so that they can use it as the basis for negotiation
about what is important within their timeboxes, as potential, new
requirements emerge or requirements change.
Functional Model Iteration Agree individual Timebox Plans with the relevant Team Leader.

Participate in timebox kick-off and closeout meetings.

Accept all timebox deliverables to the project at each timebox closeout meeting.

Monitor the team(s).

Create the Implementation Plan jointly with all relevant people, e.g. the
Ambassador User(s) for the Training Strategy, the Operations Co-ordinator for the
handover arrangements, etc.

Publish the Implementation Plan and get it agreed by the relevant people before
the end of the last pass through the Functional Model Iteration.
Design and Build Agree individual Timebox Plans with the relevant Team Leader.
Iteration
Participate in Timebox kick-off and closeout meetings.

Accept all timebox deliverables to the project at each timebox closeout


meeting.

Monitor the team(s).


Implementation Manage the migration of the system to the operational environment.

Ensure all necessary training takes place in a timely way.

Run the Increment Review workshop and produce the Increment Review
Document.

Obtain sign-off of the increment from all relevant parties.

Plan the next increment if there is one. If this is the last increment, set the date for
the Post-Implementation Review now, if the size of project warrants it.
Post-Project Ensure all lessons learnt are made available to other projects.

Participate in the Post-Implementation Review.

Points to Consider

Use the DSDM Role definitions to decide who is responsible for what during the life of the project.

The Project Management section contains special considerations for Project Managers of DSDM projects.

http://www.dsdm.org/version4/2/public/Project_Manager.asp (3 of 4) [11-1-2008 15:52:41]


DSDM Public Version 4.2 - Project Manager

Any new IT solution will usually necessitate some business change. The Project Manager role should either manage
the whole project, including recruitment of new user staff, informing end-customers, etc. or they should collaborate and
co-ordinate plan dependencies with the person responsible (e.g. the Visionary) in order for the full business change to
work. If the Project Manager manages the business change, then effectively, the business managers (e.g. from HR)
become Team Leaders managing different streams of activities.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Project_Manager.asp (4 of 4) [11-1-2008 15:52:41]


DSDM Public Version 4.2 - Technical Co-ordinator

Introduction When Lifecycle People Products Management Development Tailoring Other

Technical Co-ordinator

Introduction

Reporting to the Project Manager, the Technical Co-ordinator sits above the individual development teams, but is
involved on a part-time basis in all of them. The role ensures that teams work in a consistent way, and that the project
is technically coherent and sound overall. The role provides the "glue" that holds the project together while advising on
technical decisions and innovation.

The Visionary role ensures the project excellence from the business point of view and the Technical Co-ordinator does
the same from the technical point of view.

Skills

● Experienced in the tools being used


● Experienced in standards being used
● Senior technician who has seen the problems before
● Good technical vision
● Ability to effectively communicate the technical vision.

Responsibilities

● Determining the technical environment


● Controlling configuration management procedures
● Ensuring adherence to standards of best practice
● Advising on and co-ordinating each team's technical activities, particularly in terms of cross-team interfaces
and database usage
● Attending prototyping sessions to advise on the application of standards
● Ensuring the maintainability objectives are met
● Agreeing and controlling the software architecture
● Identifying opportunities for reuse
● Managing release control.

Typical Phase-by-Phase Activities

Pre-Project Attend DSDM training if this is the first DSDM project.

Assist the Project Manager in initial, pre-project planning if required.


Feasibility Study Participate in the project kick-off workshop (if one is run).

Assist in the creation of the Feasibility Report, specifically in the technical feasibility
of the proposed options and in determining the recommended solution from a
technical point of view.

Review/accept the Feasibility Prototype if it is produced.

Assist the Project Manager in creating the Outline Plan as necessary. Review/
accept the Outline Plan.

http://www.dsdm.org/version4/2/public/Technical_Co-ordinator.asp (1 of 3) [11-1-2008 15:52:53]


DSDM Public Version 4.2 - Technical Co-ordinator

Business Study Contribute to requirements definition and prioritisation activities to


ensure the technical feasibility and cohesiveness of the minimum
usable subset.

Create the System Architecture Definition.

Assist the Project Manager in creating the Development Plan,


specifically in the area of the Test, Configuration Management and
Prototyping Strategies and other technical standards and procedures to
be applied on the project. The Prototyping, Testing and Configuration
Management, and Modelling Techniques sections provide guidance on
the use of these activities in DSDM projects.

Ensure that the development environment is set up correctly.


Functional Model Iteration Ensure that the design is communicated to all Team Leaders, Developers and
Testers.

At the start of each timebox, ensure that teams are aware of the technical
constraints and the technical acceptance criteria that they are working towards.

Review/accept Timebox Plans from the design and technical control point of view.

Collaborate as necessary in detailed architectural/design issues raised by the


Team Leaders and Developers.

Ensure that all technical members of the development team(s) are following all
procedures and standards in the Development Plan.

Review Functional Prototypes from the technical point of view at the points agreed
in Timebox Plans.

Ensure that all models, etc. in the evolving Functional Model are fit for purpose.
Assist Developers as necessary in modelling activities.

Verify that the detailed Non-functional Requirements elicited during Functional


Model Iteration are achievable in the proposed system architecture and amend the
architecture as necessary.

Assist the Project Manager in the creation of the Implementation Plan. Review/
accept the Implementation Plan.
Design and Build At the start of each timebox, ensure that teams are aware of the
Iteration technical constraints and the technical acceptance criteria that they are
working towards.

Review/accept Timebox Plans from the design and technical control


point of view.

Collaborate as necessary in detailed architectural/design issues raised


by the team Leaders and Developers.

Ensure that all technical members of the development team(s) are


following all procedures and standards in the Development Plan.

http://www.dsdm.org/version4/2/public/Technical_Co-ordinator.asp (2 of 3) [11-1-2008 15:52:53]


DSDM Public Version 4.2 - Technical Co-ordinator

Review/accept Design Prototypes from the technical point of view at


the points agreed in Timebox Plans.

Verify/accept that the Tested System satisfies all relevant technical


standards and is adequately tested for migration to operational use, e.
g. review the Test Records.

Ensure that the operational environment is ready for migration of the


Tested System.
Implementation Manage the release of the current increment.

Verify/accept that the Delivered System is satisfactory from a technical point of


view.

Participate in the Increment Review workshop. Review the Increment Review


Document.

Post-Project Participate in the Post-Implementation Review if it is run

Points to Consider

In small projects, the Technical Co-ordinator role subsumes all the technical/design co-ordination roles, such as Test
Manager, Configuration Manager and System Architect. In larger projects, the Technical Co-ordinator role will probably
be held by a Technical Co-ordination team containing the appropriate specialists.

The role may incorporate that of Database Administrator (DBA) or provide the interface with the DBA during the
development process.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Technical_Co-ordinator.asp (3 of 3) [11-1-2008 15:52:53]


DSDM Public Version 4.2 - Team Leader

Introduction When Lifecycle People Products Management Development Tailoring Other

Team Leader

Introduction

The Team Leader ensures that a development team functions as a whole, and meets its objectives. Responsibilities
are for delivery of the system related to the team's business area, and for change control and project documentation.

Skills

● Good communicator
● Good listener
● Competent technician
● Business awareness
● Analytical skills
● Trained in the techniques to be used (e.g. facilitated workshops, prototyping)

Responsibilities

● Developing and maintaining agreement to the Business Area Definition


● Ensuring user-stated business requirements are addressed
● Organising prototyping and review sessions between users and developers
● Encouraging full participation of team members within defined roles and responsibilities
● Ensuring prototyping sessions achieve the objectives within the timebox and scheduling constraints
● Ensuring changes are documented and controlled
● Promoting team well-being and motivation
● Reporting progress to the Project Manager.

Typical Phase-by-Phase Activities

Pre-Project Attend DSDM training if this is the first DSDM project. (Consider the
possibility of attending DSDM Project Management training as well as
Awareness/Practitioner.)
Feasibility Study Participate in the project kick-off workshop (if one is run)

Assist in the creation of the Feasibility Report and the Outline Plan, e.g. through
attending Facilitated Workshops.
Business Study Lead the development of the Business Area Definition.

Participate in Facilitated Workshops as necessary to create all


Business Study products.

Assist the Technical Co-ordinator in the creation of the System


Architecture Definition as required.

Understand the Business Case for the project so that good decisions
about potential changes to scope and requirements can be made
during timeboxes.

Assist the Project Manager with the Development Plan, particularly in


the Timebox Schedule.

http://www.dsdm.org/version4/2/public/Team_Leader.asp (1 of 3) [11-1-2008 15:53:05]


DSDM Public Version 4.2 - Team Leader

Functional Model Iteration Create a draft Timebox Plan for each timebox just before it starts. (The plan is draft
because the timebox kick-off meeting may result in changes.)

Within each timebox:

● Arrange and run all timebox meetings from kick-off to Closeout as defined
in the Timebox Process.
● Agree the acceptance criteria for all timebox products with the relevant
parties, e.g. Visionary, Technical Co-ordinator, Project Manager.
● Arrange prototyping and review sessions with people outside the team as
necessary.
● As requirements change within the timebox, assess the impact of the
change on the Timebox Plan and their relevance to the project's Business
Case. Negotiate the priorities of new/changing requirements with the
Ambassador Users on the team and, if necessary, escalate any difficulties
to the relevant person.
● Ensure all team members are working effectively and according to all
project standards and procedures as stated in the Development Plan.
● Ensure all timebox team products are produced, documented, tested and
reviewed appropriately. (Check against all Functional Model Iteration
products quality criteria and the agreed acceptance criteria for specific
timebox products.)
● Run daily meetings.
● Assist Ambassador and Advisor Users as necessary.
● Check the status of all timebox products before the Timebox Closeout
meeting.

Co-ordinate activities, dependencies, etc. with other Team Leaders on the project.

Assist the Project Manager in creating the Implementation Plan

Design and Build Plan each Timebox in outline before it starts.


Iteration
Within each timebox:

● Run all timebox meetings from kick-off to Closeout as defined in


the Timebox Process.
● Agree the acceptance criteria for all timebox products with the
relevant parties, e.g. Visionary, Technical Co-ordinator, Project
Manager.
● Arrange testing by people outside the team as necessary.
● Ensure all team members are working effectively and according
to all project standards and procedures as stated in the
Development Plan.
● Ensure all timebox team products are produced, documented,
tested and reviewed appropriately. (Check against all Design
and Build Iteration products quality criteria and the agreed
acceptance criteria for specific timebox products.)
● Run daily meetings.
● Assist Ambassador and Advisor Users as necessary.
● Check the status of all timebox products before the Timebox
Closeout meeting.
● Review User Documentation

Co-ordinate activities, dependencies, etc. with other Team Leaders on


the project.

http://www.dsdm.org/version4/2/public/Team_Leader.asp (2 of 3) [11-1-2008 15:53:05]


DSDM Public Version 4.2 - Team Leader

Implementation Manage the team's activities as specified in the Implementation Plan.

Participate in the Increment Review workshop.

Review/accept the Increment Review Document

Post-Project Participate in the Post-Implementation Review if it is run

Points to Consider

Ideally Team Leaders have good business analysis skills, but this is not always necessary. It depends what the role of
the team is. For instance, if the major focus of the team is on architectural aspects such as technical interfaces, then
good technical skills/knowledge are of greater importance.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Team_Leader.asp (3 of 3) [11-1-2008 15:53:05]


DSDM Public Version4.2 - Developer

Introduction When Lifecycle People Products Management Development Tailoring Other

Developer

Introduction

The Developer models and interprets user requirements, and converts them into prototypes and deliverable code,
using the Business Study documents and interaction with the Ambassador User(s) as the initial input. The role also
documents and develops any non-prototypable elements of the system.

There is no concept of "analyst" and "programmer" in the sense that one person defines the work in detail for the other
to code. The traditional roles of analyst, designer and programmer all become merged within one team. Each
developer must be capable of understanding users' requirements and of interpreting them into a computerised form.
The method only works when developers have the correct skills and are given the authority to do this.

It follows that the skills required of DSDM developers are broader than those of the traditional programmer. In addition
to the ability to listen to what is being said and to reconstruct the words into a functional design and working models,
Developers need good interpersonal skills. They need to be good communicators and good diplomats: negotiation
skills are necessary throughout the project. Perhaps hardest of all, they must be willing to accept that they have
misinterpreted requirements and be prepared to change their views, even when it means discarding some of their
previous work.

Skills

● Knowledge or experience of the tools and development techniques being used


● Good listener/communicator
● Business area awareness

Responsibilities

● Creation of detailed documentation as necessary


● Working with users to define business requirements, create prototypes and finished programs
● Creation of other deliverables, such as a class model or data model
● Reviewing personal work and that of others.

Typical Phase-by-Phase Activities

Pre-Project Attend DSDM training (This is essential the first time on a DSDM
project in order to understand key DSDM concepts such as timeboxing
and prioritisation.)
Feasibility Study Participate in the project kick-off workshop (if one is run)

Participate in Facilitated Workshops to create the Feasibility Study products as


requested by the Project Manager
Business Study Participate in Facilitated Workshops in the creation of Business Study
products as requested by the Project Manager

Create models in the Business Area Definition if requested

Provide input to the System Architecture Definition if requested and


review if requested

Provide input to the Development Plan if requested

http://www.dsdm.org/version4/2/public/Developer.asp (1 of 3) [11-1-2008 15:53:16]


DSDM Public Version4.2 - Developer

Functional Model Iteration In every timebox:

● Contribute effort estimates, etc. to the Timebox Plan.


● Attend the planning meetings and reviews as in the timebox process and
agree to actions arising from these
● Between these meetings and reviews:
❍ Elicit detailed requirements (functional and non-functional) and

business information from the Ambassador User(s) in the team


❍ Create/review models as necessary

❍ Build prototype software collaboratively with the Ambassador User

(s) according to all relevant standards and procedures in the


Development Plan
❍ Review prototypes with the people agreed in the Timebox Plan

❍ Unit test prototypes

❍ Work with the Tester(s) to ensure that prototypes are handed over

in time for other testing within the timebox.


❍ Create/review the appropriate Functional Model documents

associated with the Functional Prototypes


❍ Participate in workshops as necessary

❍ Negotiate with the Ambassador User(s) as to what must be done

within a timebox and what can be left out


❍ Attend daily meetings

Review the Non-functional Requirements List

Assist the Project Manager as necessary to create the Implementation Plan, e.g.
with data migration requirements
Design and Build In every timebox:
Iteration
● Contribute effort estimates, etc. to the Timebox Plan
● Attend the planning meetings and reviews defined in the
timebox process and agree to actions arising from these
● Between these meetings and reviews:
❍ Evolve the relevant parts of the Functional Model

documentation and prototypes to the standard required


for delivery
❍ Build prototype software collaboratively with the

Ambassador User(s) according to all relevant standards


and procedures in the Development Plan
❍ Review prototypes with the people agreed in the

Timebox Plan
❍ Unit test protoypes

❍ Work with the Tester(s) to ensure that completed

software is handed over in time for other testing within


the timebox.
❍ Create/review technical documents and models required

to be delivered with the system


❍ Participate in workshops as necessary

❍ Negotiate with the Ambassador User(s) as to what must

be done within a timebox and what can be left out


❍ Attend daily meetings

❍ Assist the Ambassador User as necessary in the

creation of User Documentation - short of writing it

http://www.dsdm.org/version4/2/public/Developer.asp (2 of 3) [11-1-2008 15:53:16]


DSDM Public Version4.2 - Developer

Implementation Perform actions as required in the Implementation Plan

Participate in the Increment Review workshop

Review/accept the Increment Review Document

Post-Project Participate in the Post-Implementation Review if requested to do so

Points to Consider

User Involvement

Developers must not make assumptions about what is required at any stage during a project. Developers sometimes
think that users will not understand a problem and so do not involve them effectively The result is that wrong
assumptions can be made. This is potentially disastrous, as the users will see that their opinions are not as valued as
they should be and may withdraw support for the development.

The views of an Ambassador User may be consistently ignored. For instance, there may be another user in the team
who is extremely vocal and overrides all other opinions, or the Ambassador User may be afraid to voice an opinion. If
either of these is the case, the Developers must draw out the opinions of the user who is being set to one side, and
persuade more vociferous individuals to allow other opinions to be taken into account.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Developer.asp (3 of 3) [11-1-2008 15:53:16]


DSDM Public Version 4.2 - Tester

Introduction When Lifecycle People Products Management Development Tailoring Other

Tester

Introduction

The Tester performs the non-user testing in accordance with the Test Strategy in the Development Plan. The Tester is
part of a development team.

Note: The Ambassador User role is responsible for all user testing.

Skills

● Knowledge or experience of testing techniques


● Good communicator

Responsibilities

● Carrying out all types of testing except unit testing and user testing
● Creation of test documentation in accordance with the Test Strategy, e.g. test cases, plans and logs.
● Reporting to the Technical Co-ordinator on results of testing activities
● Assisting Ambassador and Advisor Users to ensure that they can plan and carry out their tests well enough to
ensure the important areas are covered.

Typical Phase-by-Phase Activities

Pre-Project Attend DSDM training if this is the first DSDM project


Feasibility Study

Business Study Assist the Technical Co-ordinator as necessary in creating the Test
Strategy part of the Development Plan. The Testing section provides
guidance on testing in DSDM projects.
Functional Model Iteration In each timebox:

● At the kick-off meeting agree to any proposed testing acceptance criteria.


● Collaborate with Developers in the team to ensure all necessary testing is
carried out in the timescale agreed.
● Perform non-user testing as required by the Timebox Plan and in
accordance with the overall Test Strategy
● Assist Ambassador and Advisor Users in thinking about how to test.

http://www.dsdm.org/version4/2/public/Tester.asp (1 of 2) [11-1-2008 15:54:02]


DSDM Public Version 4.2 - Tester

Design and Build In each timebox:


Iteration
● At the kick-off meeting agree to any proposed testing
acceptance criteria.
● Collaborate with Developers in the team to ensure all necessary
testing is carried out in the timescale agreed.
● Perform non-user testing as required by the Timebox Plan and
in accordance with the overall Test Strategy
● Assist Ambassador and Advisor Users in thinking about how to
test.

Implementation Perform the non-user testing specified in the Implementation Plan and in
accordance with the overall Test Strategy.

Participate in the Increment Review workshop.


Post-Project Participate in the Post-Implementation Review if it is run

Points to Consider

Depending on the size of the project, consider appointing one Tester as the Test Co-ordinator for the project. The focus
of DSDM testing should always be in line with the DSDM Testing Principles and the overriding priority of the Testing
Co-ordinator would be to ensure that these are understood and adhered to by the rest of the team, in order to
maximise the testing benefit in the time available. The Test Co-ordinator's specific responsibilities could include:

● producing the Test Strategy part of the Development Plan


● designing, specifying and monitoring the production of the test environment
● assisting Developers and Ambassador/Advisor Users in producing test plans
● assisting Ambassador Users in co-ordinating user resources for testing
● reporting on test progress
● resolving/escalating any issues or problems encountered when testing
● controlling environments (e.g. back-ups of databases)
● maintaining a log of which levels of testing have been performed on each element of code
● configuration management of test assets (in liaison with the Configuration Manager/librarian)
● providing support on testing best practice

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Tester.asp (2 of 2) [11-1-2008 15:54:02]


DSDM Public Version 4.2 - Facilitator

Introduction When Lifecycle People Products Management Development Tailoring Other

Credits
DSDM Version 4.2 has been created based on the experiences and comments collected from Consortium members
worldwide using DSDM and training people to use the framework. We should also mention the many people who have
contributed to DSDM White Papers over the years. Many of the White Papers have some content now transferred to
the core manual.

Ideas for what to include in this version of DSDM were received from too many members to name individually.
Nevertheless, our sincerest thanks go to all these people and organisations.

Contributors Reviewers
Kevin Barron, HP, New Zealand Steve Bellamy, Capital One, UK
Peter Coesmans, P2M, Netherlands Julia Godwin, be consulting
Andrew Craddock, RADTAC Mike Griffiths, Quadrus, Canada
Rachel Davies, XPAgile Vicky Howard, Xansa
Barry Fazackerley, Xansa Brenda Hubbard, Xansa
Sean Hanly, Exoftware Per-Magnus Skoogh, OWM
George Hay, Independent Consultant, UK Jennifer Stapleton, Independent
Steve Messenger, NAPP, UK Andrew Stringer
Mairi Osborne, Xansa Nils Wassenaar, Cap Gemini Ernst & Young,
Keith Richards, Keith Richards Consulting Netherlands
Mark Simmonds, Symmetrics
Jennifer Stapleton, Independent Consultant
Derek Thornley, Parity Training, UK
Rob Topley, LogicaCMG
Dot Tudor, TCC, UK
Paul Turner, Parity Training, UK
James Yoxall, Indigo Blue Consulting

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/credits.asp [11-1-2008 16:12:06]


DSDM Public Version 4.2 - Scribe

Introduction When Lifecycle People Products Management Development Tailoring Other

Scribe

Introduction

The Scribe is a team role that sits in on all team meetings, facilitated workshops and joint prototyping sessions and
demonstrations to record requirements, agreements, decisions reached. These are then either read back and agreed
by the team at the time or circulated for review or agreement.

Note: This is not the same role as the Scribe in Facilitated Workshops although the activities are the same. The team
Scribe is a role allocated for the duration of an increment to one or more members of the team. The workshop Scribe
role may be taken by many people in the life of a project.

Skills

● Good listener/communicator
● Business and technical awareness
● Good written communication skills

Responsibilities

● Recording all points made of system relevance on the media agreed (formatted documents can be extremely
useful)
● Assisting with later interpretation
● Managing distribution of project documentation

Typical Phase-by-Phase Activities

Pre-Project Attend DSDM training if this is the first DSDM project.


Feasibility Study Take notes at workshops if requested.

Publish notes (preferably within 24 hours of each workshop) to all participants and
any other parties identified by the Project Manager.
Business Study Take notes at workshops if requested.

Assist Developers, etc. in the creation of any models (e.g. in the


Business Area Definition and the System Architecture Definition) based
on the notes taken.
Functional Model Iteration Take notes at all timebox meetings and reviews, and other workshops.

Publish notes as required.

Create Functional Model Review Records.

Design and Build Take notes at all timebox meetings and reviews, and other workshops.
Iteration
Publish notes as required.

Create Design Prototyping Review Records.

http://www.dsdm.org/version4/2/public/Scribe.asp (1 of 2) [11-1-2008 15:54:24]


DSDM Public Version 4.2 - Scribe

Implementation Take notes during the Increment Review workshop if requested.

Assist the Project Manager on the basis of the notes in creating the Increment
Review Document

Post-Project Take notes at the Post-Implementation Review if requested.

Points to Consider

This is not a low-level, "secretarial" role. The Scribe needs to understand both the technology and the business in order
to create effective records of what has happened in a meeting, workshop, prototype review, etc.

The Scribe could be responsible for the keeping the project's Intranet/Extranet site up to date.

The Scribe may also be the team's Configuration Librarian as defined in the Configuration Management section.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Scribe.asp (2 of 2) [11-1-2008 15:54:24]


DSDM Public Versionl 4.2 - Specialist Roles

Introduction When Lifecycle People Products Management Development Tailoring Other

Specialist Roles
Specialist roles may need to be involved or be brought into the core DSDM teams on an ad hoc basis by the Project
Manager or Team Leader to fulfil specific functions. Not all of these roles will be required on all projects. The required
roles will depend on the size and nature of the project. Some of the roles are brought in with a view to facilitate skills
transfer to the core DSDM team.

These roles need to be properly integrated into the project team as appropriate. The required specialist input to the
core team should be formally planned, the individuals identified and their availability checked so that they can attend
relevant meetings, facilitated workshops, etc. There may be other roles required for special uses of DSDM, e.g. Web
Designer for Internet developments. These are specified in the relevant White Papers or e-DSDM.

Specialist role Responsibility


To undertake business planning, advise on business structure
Business Architect and flow, and undertake impact analysis/review on the overall
business model
An expert (internal or external) in a particular
business field to offer advice and guidance or to
produce a document. Areas to consider include
Business Consultant
lawyers, experts on new tax laws, experts on
financial issues that form just part of the system,
experts for some detailed calculation, etc.
To provide modelling expertise in a particular technique e.g.
Business Modeller
OO or structured modelling
To promote, develop and co-ordinate the new or
Business Process Co-ordinator
changed business processes
To advise on capacity requirements for final computer
Capacity/Performance Planner
system; to advise on any performance requirements
To advise on legal, data protection, audit trail and
Compliance Specialist
any other compliance aspects
If the organisation has identified configuration management
as a necessary independent function

Configuration Manager
Note: Depending on the size of the project, there should also
be Configuration Champion and Configuration Librarian roles
within the team.
To advise on common data standards, provide
Data Architect impact analysis on other systems via the use of
common data and review the data model
To advise on the design of the user interface for maximum
Human Factors Specialist
productivity, comfort, usability, etc.
To provide and set up the hardware, system software
Infrastructure Provider and comms environment required for both
development and production.
To assist with estimating and Function Point counting for the
Metrics Manager project. To collect and analyse metrics once the project is
complete to feedback into the estimating process

http://www.dsdm.org/version4/2/public/Specialist_Roles.asp (1 of 2) [11-1-2008 15:54:36]


DSDM Public Versionl 4.2 - Specialist Roles

The computer system must be acceptable to the


operations department. Therefore it is necessary to
involve the people who will be responsible for the
Operations Co-ordinator. operational aspects, both during design and
implementation. Also to ensure that the new system
is included in the Disaster Recovery Plan for the site
as relevant.
Quality Manager As required by the organisation's quality management system
To advise on any suitable reusable components from
the existing library which could be used in this
Re-use Assessor development. At the end of the project, to consider
any components which could be put into the reusable
library
Security Specialist To advise on any security requirements
To advise and negotiate the Service Level
Agreement for the final computer system if required.
Service/Help Desk Manager
To agree how the system will be handled by the Help
Desk if relevant.
If the support is not to be done by developers, the support
team needs to be involved in the development in order to gain
Support and Maintenance team representatives
knowledge to enable them to successfully provide support to
the end users
Depending on the size of the total project, there may
be a need for a Systems Integrator to take
responsibility for the final assembly of the project
Systems Integrator
components. This is normally either an individual
redeployed from one of the DSDM teams or the
Technical Co-ordinator
A technical expert (internal or external) to provide expertise in
Technical Consultants specific areas such as networks, database design,
operational considerations, tools usage, technical reviews.
To produce the testing strategy, to ensure the correct
Testing Manager setup of the test environment and to co-ordinate
testing activity

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Specialist_Roles.asp (2 of 2) [11-1-2008 15:54:36]


DSDM Public Version 4.2 - Products

Introduction When Lifecycle People Products Management Development Tailoring Other

Products Overview

Introduction

Each phase of DSDM generates certain deliverables, i.e. products. In some cases, these deliverables are themselves
essential products, but other "associated" products may be needed to support them. For example, from a particular
phase, a working prototype may be a main product; other, associated products might include review records and/or test
records whose primary purpose is to show that the main product has been properly validated. (In this case, the
associated products may also have some value during maintenance.) The associated products may be more important
in some organisations than in others. For example, organisations with certified Quality Management Systems are likely
to require that certain "quality records" be retained.

Products in DSDM

The table below identifies which products are produced during each DSDM phase.

DSDM Project Phase Products


No formally defined DSDM products, but see the Pre-Project phase
Pre-Project
description
Feasibility Report, possibly supported by a Feasibility
Prototype
Feasibility Study
Outline Plan
Risk Log
Business Area Definition
Prioritised Requirements List
Business Study System Architecture Definition
Development Plan
Updated Risk Log

Functional Model (including Functional Prototypes)


Functional Model Review Records
Non-Functional Requirements List
Functional Model Iteration
Timebox Plans
Implementation Plan
Risk Log
Timebox Plans
Design Prototypes (intermediate products)
Design and Build Iteration Design Prototyping Review Records
Tested System, including all design documentation, etc. together
with supporting Test Records

User Documentation
Delivered System, together with supporting build, delivery
Implementation and acceptance records
Trained User Population
Increment Review Document
Post-Project Post-Implementation Review Report

Outline product descriptions for each of the products defined within DSDM are provided. Each of these identifies:

http://www.dsdm.org/version4/2/public/Product_Overview.asp (1 of 2) [11-1-2008 15:54:49]


DSDM Public Version 4.2 - Products

● the purpose of the product


● when the product is produced
● who could be responsible for producing, contributing to, reviewing and accepting the product
● a set of questions that can be asked to ensure that the purpose has been met satisfactorily
● some hints and tips.

In order for the descriptions to be applicable to all possible environments in which DSDM may be used, no details are
provided as to how the products are built or what they should look like. However in many instances some hints and tips
are provided.

There may be many other products arising from a development project. In particular, there will often be products that
govern the relationship between the development organisation and the user organisation and there will be products
that are generated or used by project management to control and/or monitor the activity. These other products are not
addressed further within this section of the manual, which concentrates on those products that are particularly relevant
to the user community.

Where the development is contracted out to a separate development organisation, certain products may need to be
partitioned to protect the commercial sensitivities of the parties concerned.

Expanding the Product Descriptions

The product descriptions are generic and should be refined for the specific business and development environments of
each organisation using DSDM. This refinement can be achieved incrementally as experience in using DSDM grows.
Caution should be used in developing the product descriptions. They should not be made so prescriptive that the
flexibility that has been built into DSDM is lost through unnecessary bureaucracy. Guidance on choosing development
and modelling techniques that are appropriate for use in creating DSDM products is provided.

It should also be noted that many of the products, though generated in a particular stage of the lifecycle, will need to be
maintained during later stages.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Product_Overview.asp (2 of 2) [11-1-2008 15:54:49]


DSDM Public Version 4.2 - Business Area Definition

Introduction When Lifecycle People Products Management Development Tailoring Other

Business Area Definition

Introduction

The Business Area Definition provides a high-level view of the business processes, people and information to be
supported by the proposed solution.

The Business Area Definition evolves into the Functional Model during Functional Model Iteration(s). However, it must
be in enough detail to enable both the Development Plan and a sound business case in line with local procedures to be
created using this product and the System Architecture Definition.

Purpose

To identify the business needs that should be supported by the proposed solution.

To refine the Outline Business Case (documented in the Feasibility Report) to include benefits, risks, costs and impact
analyses.

To outline the information requirements of the business processes that will be supported.

To identify the classes of users impacted by the development and introduction of the proposed system.

To identify the business processes and business scenarios that need to change.

To clarify all interfaces with other systems (human or automated).

To verify that the proposed solution is still amenable to development using DSDM (tailored as necessary)

Quality Criteria

1. Are the business context, business process and business objectives defined and agreed?
2. Have all the currently identified requirements been prioritised (including non-functional requirements)?
3. Have all the priorities been assigned in collaboration with the users?
4. Have high-level acceptance criteria for the Delivered System been defined?
5. Are the business areas clearly documented, including high-level information needs that are affected by the
system?
6. Is the envisaged boundary of the proposed new system realistic in the timescales?
7. Are all classes of users affected by the new system identified?
8. Are the information and processing requirements of the proposed system defined at least in outline?
9. Is it still clear that the business needs are being addressed by the proposed new system?
10. Is the person responsible for each business process identified? Can they commit the necessary resources and
time?
11. Are all major business events (e.g. financial year-end, order received, new supplier taken on) identified?

Roles involved

http://www.dsdm.org/version4/2/public/BAD.asp (1 of 2) [11-1-2008 15:55:05]


DSDM Public Version 4.2 - Business Area Definition

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Team Leader


Contribution Visionary, Ambassador User, Advisor User
Review Visionary, Ambassador User, Project Manager
Acceptance Visionary, Ambassador User, Project Manager

Points to Consider

Facilitated Workshops are the best technique for creating a Business Area Definition quickly to which all key
stakeholders can agree.

The business model must be in enough detail to enable a Development Plan to be defined, an applications and
technical architecture to be defined (the System Architecture Definition) and a Business Case to be created.

Business scenarios created now by the users will prove useful throughout the project for the following reasons:

● They form the basis for models.


● They can be refined to drive the detailed content of business processing software.
● They can be used as the basis for all user testing.
● They can provide the basis for the content of user training and documentation.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/BAD.asp (2 of 2) [11-1-2008 15:55:05]


DSDM Public Version 4.2 - Delivered System

Introduction When Lifecycle People Products Management Development Tailoring Other

Delivered System

Introduction

The Delivered System is the Tested System put into operational use during the Implementation phase. The method by
which this is done is defined in the Implementation Plan.

The Tested System may be the full solution or it may be an incremental delivery contributing to the full solution.

Purpose

To perform the functionality described in the Functional Model in accordance with all constraints defined in the non-
functional requirements.

Quality Criteria

1. Have any changes made to the Tested System been properly authorised, implemented and tested?
2. Does the system work as required in its target environment?
3. Does it appear to operate to the required service levels?
4. Are there any unforeseen problems in the system's placement in the target environment that remain
unresolved?
5. Have all data loading and conversion activities been completed successfully?
6. Have all configuration items been properly archived?
7. Are all configuration items identified?
8. Is the correct version of each configuration item recorded?
9. Are all known outstanding problems recorded?

Roles involved

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Project Manager, Team Leader


Ambassador User, Advisor User, Technical Co-ordinator, Team Leader,
Contribution
Developer, Tester
Ambassador User, Advisor User, Project Manager, Technical Co-
Review
ordinator, Team Leader, Developer, Operations Co-ordinator
Executive Sponsor, Visionary, Ambassador User, Advisor User, Technical
Acceptance
Co-ordinator, Operations Co-ordinator

Points to Consider

http://www.dsdm.org/version4/2/public/Delivered_System.asp (1 of 2) [11-1-2008 15:55:26]


DSDM Public Version 4.2 - Delivered System

The Tested System must have been approved by the relevant people (e.g. the Visionary, the Operations Co-ordinator
and the relevant support area) before transferring it to operational use.

Careful configuration management must be used to track the status of the solution at this critical period in the project.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Delivered_System.asp (2 of 2) [11-1-2008 15:55:26]


DSDM Public Version 4.2 - Design Prototype

Introduction When Lifecycle People Products Management Development Tailoring Other

Design Prototype

Introduction

The Design Prototype is an interim product that addresses technical issues not covered during Functional Model
Iteration activities. It is a part of what will become the Tested System.

Purpose

To provide developers with assurance that a particular design strategy is feasible.

To provide users (particularly senior users) with evidence that development is progressing in the right direction.

To provide users with the opportunity to help improve the system through feedback to the developers.

Quality Criteria

1. Does the prototype satisfactorily address the intended issues?


2. Are all risks in progressing with the design clearly identified?
3. Does the design conform to all applicable user requirements?
4. Does the design conform to all applicable development standards and guidelines?

Roles involved

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Team Leader


Contribution Ambassador User, Team Leader, Developer, Tester
Ambassador User, Project Manager, Technical Co-ordinator,
Review
Team Leader
Acceptance Ambassador User, Technical Co-ordinator

Points to Consider

● Create documentation alongside the prototyping activities. Leaving it till later often means that it is
inadequately done.
● Do not allow too many new design ideas to come in at this stage or the project timescales will be endangered.
● When a Design Prototype does not pass the required tests within the timebox, then it should be removed
either partially or in its entirety from the timebox deliverable. This approach means that within a timebox Must
Have requirements should be prototyped and tested first and that Must Have tests should be applied first.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Design_Prototype.asp [11-1-2008 15:56:03]


DSDM Public Version 4.2 - Design Prototyping Review Records

Introduction When Lifecycle People Products Management Development Tailoring Other

Design Prototyping Review Records

Introduction

Design Prototyping Review Records are used to capture feedback from the users (particularly the Ambassador Users)
about the prototypes as they evolve towards the Tested System. Even though the reason for many Design Prototypes
will be technical, the business should have a chance to review prototypes (rather than test them) as early as possible.

Purpose

To record the user feedback for all Design Prototypes.

To help steer future developments clear of any pitfalls that may have been encountered.

To highlight, and plan for, any areas that should be implemented or tuned either during the build phase or which may
be addressed following delivery of the system.

Quality Criteria

1. Do the review documents cover all Design Prototypes?


2. Are all comments from users and developers recorded to their satisfaction?

Roles involved

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Scribe
Contribution Ambassador User, Technical Co-ordinator, Team Leader, Developer, Tester
Ambassador User, Project Manager, Quality Manager, Team
Review
Leader
Acceptance Ambassador User, Project Manager, Quality Manager

Points to Consider

Review Design Prototypes as early as possible, even if they are only partial: this will save more work later.

Capture positive as well as negative comments in the Review Records to ensure that the good parts do not get
changed in error and then have to be reworked.

When reviewing, focus on the acceptance criteria that have been set for the prototype to ensure that the scope of the
work does not extend beyond what is achievable in the timescales.

The Review Records can be used to record the proposed actions resulting from the comments and the action
completion dates.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Design_Prototyping_Review_Records.asp (1 of 2) [11-1-2008 15:56:19]


DSDM Public Version 4.2 - Design Prototyping Review Records

http://www.dsdm.org/version4/2/public/Design_Prototyping_Review_Records.asp (2 of 2) [11-1-2008 15:56:19]


DSDM Public Version 4.2 - Development Plan

Introduction When Lifecycle People Products Management Development Tailoring Other

Development Plan

Introduction

The Development Plan defines the plans and controls for the whole project or just for the next increment.

See Project Planning for an overview of the planning activities in DSDM projects.

Purpose

To refine the Outline Plan to provide a more detailed plan for activities within the Functional Model Iteration and Design
and Build Iteration.

To provide the development team with a strategy for development.

To prioritise prototyping activities.

To define the categories of prototypes that will be developed and when.

To define the mechanisms for deciding when a particular prototyping activity should terminate.

To identify individuals who will take on the various roles and responsibilities on forthcoming phases of the project.

To identify which items are to be subject to configuration management and to outline how configuration control is to be
applied.

To define the approach to be taken to testing: what types of tests are to be run, how they are to be specified and
recorded.

Quality Criteria

1. Are the timescales consistent with the business objectives in the Feasibility Report and the Business Area
Definition?
2. Does the order of activities within the Development Plan reflect the priorities, dependencies, etc. in the
Prioritised Requirements List?
3. Is the timebox schedule realistic in terms of currently estimated effort and the flow of products?
4. Does the timebox schedule reflect the need to address areas of risk at appropriate times?
5. Are all affected classes of users identified in the Development Plan?
6. Is the proposed user effort consistent with the needs of both the existing business processes and the
development?
7. Will the necessary effort (from all personnel) be available when required?
8. Is the selection of the categories of prototypes feasible within the expected development environment?
9. Is the method of configuration management appropriate to the environment?
10. Are the proposed extent, depth and formality of testing appropriate?

Roles involved

http://www.dsdm.org/version4/2/public/Development_Plan.asp (1 of 3) [11-1-2008 15:56:40]


DSDM Public Version 4.2 - Development Plan

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Project Manager


Contribution Ambassador User, Project Manager, Team Leader, Developer, Tester
Executive Sponsor, Visionary, Technical Co-ordinator, Team
Review
Leader
Acceptance Executive Sponsor, Visionary, Technical Co-ordinator

Points to Consider

The first Development Plan produced in a project should cover the overall development approach and the plan for the
Functional Model and Design and Build Iterations for the first increment. As new increments are started, the controls
should be checked for their validity and possibly updated. Then the plan for the next increment (e.g. the prototyping
approach and the timebox schedule) is added to the Development Plan.

Functional Model Iteration and Design and Build Iteration do not have to be distinct phases: they can be separate or
merged depending on the needs of the project and the ability of the tools being used to generate code.

The plan should include the schedule of timeboxes but not their details. Planning at the detail level is left until individual
Timebox Plans are produced.

The Project Manager should discuss with the team the appropriate categories of prototype to build (and when) and the
approach to be used. See Managing the Prototyping Process.

The Configuration Management Strategy part of the Development Plan may include some or all of:

● The frequency at which baselines will be taken


● What items will be placed under configuration management and when. Candidate configuration items include
products which will evolve during development (e.g. the Business Area Definition and the System Architecture
Definition), models, modules, libraries, objects, methods, prototypes, functions, test scripts, test data,
documentation, build states, timebox plans and business scenarios
● The configuration management library structure
● The ultimate authority for configuration management on the project (usually the Technical Co-ordinator)
● The method by which every team member will be made aware of the configuration management procedures
and mechanisms.

The Test Strategy part of the Development Plan maps the types of testing against the project lifecycle, indicating if and
where each type of testing will be done. If it is decided not to perform certain types of testing, then the risk of these
deliberate omissions should be described in business terms, so that the business is fully aware of the implications.

A contents list for the Test Strategy part of the Development Plan for a medium to large project may include:

● Testing Overview
❍ Cross-reference of testing types to DSDM phases

❍ Test Data Approach - general

❍ Testing Environment(s)

❍ Outline schedule for testing

● For each stage of testing:


❍ Objectives

❍ Commitments from other teams and third parties

❍ Strategy for test data

❍ Acceptance procedures

❍ Testing roles and responsibilities

❍ Deliverables

● Security and Control (if applicable)

http://www.dsdm.org/version4/2/public/Development_Plan.asp (2 of 3) [11-1-2008 15:56:40]


DSDM Public Version 4.2 - Development Plan

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Development_Plan.asp (3 of 3) [11-1-2008 15:56:40]


DSDM Public Version 4.2 - Feasibility Prototype

Introduction When Lifecycle People Products Management Development Tailoring Other

Feasibility Prototype

Introduction

A Feasibility Prototype is an optional product. It may be produced as a "proof of concept" for two reasons:

● to prove one or more of the possible technical solutions contained within the Feasibility Report
● to demonstrate to the business the possible content of the user interface and the look and feel.

Purpose

To support the Feasibility Report in its findings.

To provide a visualisation of the possible new computer system.

To obtain buy-in to the proposed solution.

Quality Criteria

1. Does the prototype add value to the findings of the Feasibility Report?
2. If the prototype is automated, does it assist in the assessment of risks associated with the application and
development environment?

Roles involved

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Developer
Contribution Developer
Review Visionary, Project Manager, Technical Co-ordinator
Acceptance Visionary, Technical Co-ordinator

Points to Consider

Only produce a Feasibility Prototype if it will really aid the decisions made in the Feasibility Study.

A Feasibility Prototype should be discarded: it should rarely be used as the basis for later evolutionary prototyping
since it is unlikely to have been built to the requisite standard required of operational software and could cause more
problems than it solves.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Feasibility_Prototype.asp (1 of 2) [11-1-2008 15:56:50]


DSDM Public Version 4.2 - Feasibility Prototype

http://www.dsdm.org/version4/2/public/Feasibility_Prototype.asp (2 of 2) [11-1-2008 15:56:50]


DSDM Public Version 4.2 - Feasibility Report

Introduction When Lifecycle People Products Management Development Tailoring Other

Feasibility Report

Introduction

The Feasibility Report enables the project steering committee or other governing body to decide not only which option
to choose for the way forward, but also whether or not the project should proceed beyond the Feasibility Study. It
should be regarded as a success for a project to be stopped or put on hold if the Feasibility Report is not convincing in
its findings.

Since the value of the Feasibility Report lies in the short term. It should be kept as brief as possible while still
addressing the purpose and quality criteria below.

Purpose

To outline the problem to be addressed by the new system.

To define the scope of the project or set of projects.

To give a preliminary indication of any areas within the scope which may be desirable but not essential.

To state, at least in outline, the Business Case for the project(s) - including where possible expected costs, benefits,
assumptions and risks (whether quantifiable or not).

To indicate what alternative solutions have been or could be considered.

To define the major products to be delivered by the project.

To report on the suitability of DSDM for use on the project, which may vary for each solution.

To document the objectives of the project including process performance criteria.

To document high-level technical and business constraints, e.g. timescale, hardware and software platforms.

To identify whether the system may be safety-related or if there may be any product liability issues.

To describe at a high level the business processes and data that are expected to be automated.

To identify at a high level the interfaces necessary to existing data and applications.

To identify which business processes and/or systems (whether automated or not) might be impacted by the new
system and which might need to change in order to accommodate it.

To define the expected life of the computer system and hence the requirements for maintainability

http://www.dsdm.org/version4/2/public/Feasibility_Report.asp (1 of 2) [11-1-2008 15:57:02]


DSDM Public Version 4.2 - Feasibility Report

Quality Criteria

1. Is the problem definition in line with the needs of senior business management?
2. Is the scope of the project sufficiently clear for it to be refined within the Business Study?
3. Are the business objectives to be met by the development clearly defined?
4. Is the solution to the problem, as laid out in the major products to be delivered and in the objectives of the
project, feasible in both technical and business terms?
5. Is the case for the project approach sound, i.e. are the risks acceptable after checking the Suitability/Risk List?
6. Does management accept what has been included and excluded from the scope?
7. Are all associated systems and their interfaces identified? Is any impact on those systems acceptable?
8. Is the Business Case for the project to proceed valid?

Roles involved

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Project Manager


Contribution Visionary, Ambassador User, Technical Co-ordinator
Review Visionary, Technical Co-ordinator
Acceptance Visionary

Points to Consider

A facilitated workshop consisting of all the important stakeholders is an excellent way of creating this product. Such a
workshop can explore different ideas and ensure that all the stakeholders buy into the recommended solution.

In order to avoid bias, the criteria to be used when evaluating the different options should be determined in advance of
creating the options.

The determination of which solution to recommend should be based on the solution that is likely to exhibit the most
favourable business case.

Always consider the "do nothing" option unless there are legal or regulatory requirements to be addressed.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Feasibility_Report.asp (2 of 2) [11-1-2008 15:57:02]


DSDM Public Version 4.2 - Functional Model

Introduction When Lifecycle People Products Management Development Tailoring Other

Functional Model

Introduction

The Functional Model defines what the solution will do without going into the detail of how non-functional aspects such
as security and performance will work. It evolves over the life of the project, expanding in scope and deepening in
content with each pass through Functional Model Iteration within an increment, and with each increment.

The Functional Model consists of both documents and software (Functional Prototypes). As much as possible of the
Functional Model is contained within the Functional Prototypes but there will necessarily be documents produced as
well. For a given project, these will include some or all of the following:

● Models (e.g. class models and data models)


● Supporting documentation for the prototypes
● Textual description of other system aspects either addressed now or to be addressed during Design and Build
Iteration, e.g. system startup and closedown, audit trails, business continuation policy, recovery from failure.

The documentary parts of the Functional Model evolve from the Business Area Definition created during the Business
Study.

Purpose

To provide a cohesive demonstration of the functionality and data requirements to be met, including all currently known
constraints.

To demonstrate the feasibility of achieving the non-functional requirements.

Quality Criteria

1. Does the Functional Model match the users' needs as elicited during discussions and prototyping sessions?
2. Is it within the scope of the development as defined in the Business Area Definition?
3. Are all parts of the Functional Model mutually consistent?
4. Does the model contain the minimum usable subset?
5. Are all essential aspects of integrity and security contained within the Functional Model?
6. Are the requirements for system administration visible?
7. Are all static models (e.g. data models) consistent with the Functional Prototype(s), and vice versa?
8. Does the model give confidence that the right levels of performance, capacity and maintainability will be
achievable?
9. Is any necessary supporting documentation available and to an adequate standard?

Roles involved

http://www.dsdm.org/version4/2/public/Functional_Model.asp (1 of 2) [11-1-2008 15:57:14]


DSDM Public Version 4.2 - Functional Model

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Project Manager, Team Leader


Contribution Ambassador User, Technical Co-ordinator, Developer, Tester
Visionary, Ambassador User, Advisor User, Project Manager,
Review
Technical Co-ordinator, Team Leader, Developer
Visionary, Ambassador User, Advisor User, Project Manager, Technical Co-
Acceptance
ordinator, Team Leader

Points to Consider

The Functional Model is a refinement of the Business Area Definition. Reuse as much as possible rather than reinvent
the wheel. Indeed, reuse of any appropriate existing models or architectures will give the project a head start.

Do not produce a model unless it adds value to development activity or is necessary for later support and maintenance.
Projects slow down when they create models just because the tool being used suggests that they should rather than
make a decision about what the project really needs.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Functional_Model.asp (2 of 2) [11-1-2008 15:57:14]


DSDM Public Version 4.2 - Functional Model Review Records

Introduction When Lifecycle People Products Management Development Tailoring Other

Functional Model Review Records

Introduction

Functional Model Review Records capture the feedback on all parts of the Functional Model, not just the Functional
Prototypes. They validate the solution as it is built up progressively during Functional Model Iteration (FMI). They
should be used in each and every FMI timebox to record comments on the work so far.

Purpose

To record the user feedback for all functional models and prototypes.

To assist in planning and executing design activities.

To highlight any areas that can be implemented in future development work.

To assist any future development in avoiding any pitfalls similar to ones that may have arisen so far on this project.

Quality Criteria

1. Do the review records cover all parts of the Functional Model, including all Functional Prototypes?
2. Are all comments from users recorded to their satisfaction?
3. Has user management agreed any areas for which users have requested further development?
4. Where unresolved conflicts of user requirements have arisen are these highlighted for management and/or
technical consideration?
5. Do the review records provide sufficient information to show where the prototypes currently fall short of
expectations?
6. If there are areas that should be "frozen" as they are (e.g. some part of the user interface), do the review
records highlight them?

Roles involved

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Scribe
Visionary, Ambassador User, Advisor User, Technical Co-ordinator, Team
Contribution
Leader, Developer, Tester
Ambassador User, Project Manager, Team Leader, Quality
Review
Manager
Acceptance Project Manager, Quality Manager

http://www.dsdm.org/version4/2/public/FM_Review_Records.asp (1 of 2) [11-1-2008 15:57:24]


DSDM Public Version 4.2 - Functional Model Review Records

Points to Consider

Capture positive as well as negative comments in the Review Records to ensure that the good parts do not get
changed in error and then have to be reworked.

When reviewing focus on the acceptance criteria that have been set for the (part of the) Functional Model to ensure
that the scope of the work does not extend beyond what is achievable in the timescales.

The Review Records can be used to record the proposed actions resulting from the comments and the action
completion dates.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/FM_Review_Records.asp (2 of 2) [11-1-2008 15:57:24]


DSDM Public Version 4.2 - Functional Prototype

Introduction When Lifecycle People Products Management Development Tailoring Other

Functional Prototype

Introduction

Functional Prototypes are part of the Functional Model. They enable the Ambassador Users in a team to drive the
project forward in the right direction for the business. They will usually be business and usability category prototypes.

Purpose

To provide a first-cut system component that contains most of the functionality required to support the business
processes being addressed at the moment. (It does not necessarily have to meet the non-functional requirements,
though it should give confidence that such requirements will be achievable.)

To enable users to comprehend the facilities which the system will provide.

To enable users to understand easily to what events they will be expected to respond, so that they can operate the
new computer system effectively.

To provide a basis for agreement with users at all levels about the direction that the project is taking.

Quality Criteria

1. Are any and all paper-based components of the Functional Prototype achievable in the development
environment?
2. Are all the necessary system interfaces apparent, at least in outline? Does their later implementation look
feasible?
3. Are all essential business process requirements identifiable in the Functional Prototype? Where they are not,
is supporting documentation available?
4. Are all essential data requirements identifiable in the Functional Prototype? Where they are not, is supporting
documentation available?
5. Where non-functional requirements have been addressed by the Functional Prototype are they clearly
demonstrated?

Roles involved

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Developer
Contribution Ambassador User, Developer, Tester
Visionary, Ambassador User, Advisor User, Technical Co-
Review
ordinator, Developer, Team Leader
Acceptance Visionary, Ambassador User

Points to Consider

http://www.dsdm.org/version4/2/public/Functional_Prototype.asp (1 of 2) [11-1-2008 15:57:38]


DSDM Public Version 4.2 - Functional Prototype

Wherever possible, the Ambassador User should be given Functional Prototypes to try out rather than have the
prototypes demonstrated to them (carefully avoiding the pitfalls that will exist in early prototypes). Even though the
gaps that exist will sometimes cause problems, the business use and understanding of what is being created (however
partial or buggy) is essential to building the right system in the longer term.

Test Functional Prototypes to the level defined in the Timebox Plan and/or the Test Strategy part of the Development
Plan. This together with the user review and test will save work later.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Functional_Prototype.asp (2 of 2) [11-1-2008 15:57:38]


DSDM Public Version 4.2 - Implementation Plan

Introduction When Lifecycle People Products Management Development Tailoring Other

Implementation Plan

Introduction

The Implementation Plan is produced no later than during the last pass through Functional Model Iteration in an
increment. It defines the activities needed to move the current system increment from the development environment to
full operational use. This includes not only the migration of the system itself but also the Training Strategy to ensure
that the operational system is used effectively.

See Project Planning for an overview of the planning activities in DSDM projects.

Implementation is first considered during the Feasibility Study.

Purpose

To define the detail of how the increment being currently developed will become operational.

To define the costs and effort in more detail, enabling management to reassess the costs and benefits of the
development.

Quality Criteria

1. Are the plans agreed with the people who will support the increment in operation?
2. Does the timetable still fit in with business needs?
3. Do the cost and effort estimates (both developer and user) look realistic for achieving delivery of the solution?
4. Are the necessary resources (both developer and user) available to meet this plan?
5. If relevant, are the procedures for handover to maintenance and support staff clear?
6. If relevant, have the requirements for data take-on and/or system cutover been adequately considered?
7. Is the Training Strategy appropriate?
8. Have all changes to the physical environment been adequately considered?
9. Have issues relating to third parties been considered?
10. Has communication (e.g. within the organisation and customers) been considered?

Roles involved

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Project Manager


Ambassador User, Technical Co-ordinator, Team Leader, Developer, Tester,
Contribution
Operations Co-ordinator (and see Points to Consider below)
Review Technical Co-ordinator, Team Leader, Operations Co-ordinator
Acceptance Technical Co-ordinator, Operations Co-ordinator, Visionary

http://www.dsdm.org/version4/2/public/Implementation_Plan.asp (1 of 2) [11-1-2008 15:57:51]


DSDM Public Version 4.2 - Implementation Plan

Points to Consider

All Implementation phase stakeholders (e.g. networks support and help desk) must be involved in the creation of the
Implementation Plan and agree that it is realistic. One of the biggest risks to successful project delivery is "forgotten
dependencies" which are discovered after planning and too late to be fulfilled.

Identify the point in the overall Implementation Plan by which time it will be necessary to finalise the content of a
software release, for it to be possible to proceed on schedule with acceptance and cutover.

Build in a review of the content of the increment (i.e. the configuration items) for completeness and consistency with
previous increments.

In order to train the users it is necessary to:

● identify the various classes of users


● define the skills and/or training they may need in order to use the system and any new business processes
● identify the gap between the skills required and those currently held by the different classes of users
● plan the training method, e.g. classroom, computer-based training, one-to-one sessions, guided tutorials
● produce the training material needed
● produce training schedule if appropriate to the training method
● deliver the training.

Much of this requires specialist training skills. However, it is the responsibility of the Ambassador Users on the project
to ensure that the training is targeted correctly and that the material is produced.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Implementation_Plan.asp (2 of 2) [11-1-2008 15:57:51]


DSDM Public Version 4.2 - Increment Review Document

Introduction When Lifecycle People Products Management Development Tailoring Other

Increment Review Document

Introduction

The Increment Review Document is the final document produced in a pass through the DSDM development lifecycle.
Its aim to provide the planning activities for subsequent increments with the latest information about what has been
achieved, what went well, what could have been done better but most importantly to have a view of which requirements
from the Prioritised Requirements List need to be addressed next.

Purpose

To assess the success of the development work.

To enable decisions on future development work to be made.

To decide what deliberate omissions could now be addressed.

Quality Criteria

1. Have all areas, which were omitted in this increment, been identified?
2. Is there sufficient information to enable management to decide whether or not to proceed with further
development work?
3. Have all lessons learned during the increment been documented?

Roles involved

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Project Manager


Contribution All roles
Executive Sponsor, Visionary, Ambassador User, Project
Review
Manager, Technical Co-ordinator
Acceptance Executive Sponsor, Visionary, Ambassador User

Points to Consider

To keep the project moving, the Increment Review should take place within one week of increment completion.

An Increment Review is not the same as a Post-Implementation Review, which will normally take place several months
after an increment has been in operational use to check that no outstanding issues exist and to check whether or not
the expected business benefits have been achieved.

http://www.dsdm.org/version4/2/public/Increment_Review_Document.asp (1 of 2) [11-1-2008 15:58:02]


DSDM Public Version 4.2 - Increment Review Document

The best method of obtaining views is through a Facilitated Workshop at which all project stakeholders are
represented. All core project team members should attend unless the project is very large.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Increment_Review_Document.asp (2 of 2) [11-1-2008 15:58:02]


DSDM Public Version 4.2 - Non-functional Requirements List

Introduction When Lifecycle People Products Management Development Tailoring Other

Non-functional Requirements List

Introduction

The Non-Functional Requirements List is a subset of the Prioritised Requirements List and as such they should be
prioritised using the MoSCoW rules. They are delivered during the Functional Model Iteration because the detail of the
non-functional requirements will emerge during discussions between the Developers and Ambassador Users in this
phase.

Non-functional requirements define how well the system should operate rather than what it should do. They can be
considered under the following categories:

● Performance Requirements These specify numerical values for the measurable variables within the system,
such as response rates, capacity volumes and communication rates.
● Interface Requirements These specify the hardware or software elements with which the system, or system
component, must interact or communicate.
● Operational Requirements These specify how the system will run and communicate with the system users.
Operational requirements include all user interface requirements.
● Resource Requirements These specify the limits on physical resources, such as memory capacity, disk
capacity, processor power.
● Security Requirements These specify the requirements for the system for securing against threats to
confidentiality, integrity and availability.
● Portability Requirements These specify the need to install the software components on other hardware
platforms and/or operating systems.
● Reliability Requirements These specify the acceptable mean time between failures of the system, averaged
over a significant period.
● Maintainability Requirements These specify how easy it is to repair faults and adapt the software to new
requirements.
● Safety Requirements These specify the requirements to reduce the possibility of causing damage as a direct
result of system failure.
● Recovery Requirements These specify what needs to be done before and after system failure, e.g. backup
requirements to enable recovery when needed, business continuity requirements (the minimal service) and full
recovery requirements.

Purpose

To refine and expand the non-functional requirements for use in the Design and Build Iteration (even if they have been
satisfied in a Functional Prototype).

Quality Criteria

● Are all the non-functional requirements sufficiently quantified?


● Where non-functional requirements have already been addressed by a Functional Prototype, are these noted
as such in the list of non-functional requirements?
● Have all areas identified in the high-level constraints in the Feasibility Report been considered?
● Is the set of non-functional requirements complete and consistent both within itself and with the Functional
Model?
● Do all the non-functional requirements add value to the business processes?
● Are the non-functional requirements realistic and achievable?

Roles involved

http://www.dsdm.org/version4/2/public/NFR_List.asp (1 of 2) [11-1-2008 15:58:13]


DSDM Public Version 4.2 - Non-functional Requirements List

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Technical Co-ordinator


Visionary, Ambassador User, Technical Co-ordinator, Team Leader,
Contribution
Developer
Ambassador User, Project Manager, Technical Co-ordinator,
Review
Team Leader, Developer, Tester
Acceptance Ambassador User, Technical Co-ordinator

Points to Consider

Detailed design cannot be soundly based until all the key non-functional requirements are understood for the area
under development. Global non-functional requirements need to be captured as early as possible, but many will relate
to a particular part of the system, e.g. requirements for response times will differ for functionality that is used all the
time from that which is performed less frequently, say, at month-end.

The non-functional requirements will have significant impact on the degree to which quality controls are applied to
software products. All non-functional requirements need to be carefully examined to see the impact on the flow of
development and the rigour that will be applied in static and dynamic testing. Requirements relating to performance,
reliability, security and maintainability are of particular importance in projects that are trying to deliver a system quickly.
Decisions have to be made by the business as early as possible in the project about what has to be done now and
what can be left until later. The description of the three levels of maintainability requirements demonstrate the sort of
decisions that will be made with respect to all key non-functional requirements.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/NFR_List.asp (2 of 2) [11-1-2008 15:58:13]


DSDM Public Version 4.2 - Outline Plan

Introduction When Lifecycle People Products Management Development Tailoring Other

Outline Plan

Introduction

The Outline Plan is the first planning product within the project. It sets deadlines and milestones for various major
phases of work, or key deliverables (particularly incremental delivery dates). These deadlines become the major
control points around which the later, lower level plans will be developed. Also it provides the detailed plan for how the
Business Study will be run.

See Project Planning for an overview of the planning activities in DSDM projects.

Purpose

To provide management with ballpark estimates of the financial and resource implications (both developer and user) of
the proposed project.

To provide a basis for agreement of timescales for the proposed development activities.

To define the high-level acceptance criteria for the proposed deliverables, e.g. the system will conform to all agreed
requirements.

To define and agree the approach to the Business Study.

To identify any particular facilities which the development team(s) will require (e.g. clean rooms, collocation).

To define the expected path through DSDM for this project. (Note: Some guidance on tailoring DSDM for specific
projects is provided.)

To identify any currently known issues surrounding the implementation of the system, in particular aspects such as
data take-on and user handover.

Quality Criteria

1. Are the estimates for effort realistic in the light of the details within the Feasibility Report?
2. Are the estimated timescales consistent with the business needs of the project? Conversely, have the
business needs been addressed in terms of what is delivered and when?
3. Is business management able to commit to the level of business resources required for the Business Study
and to ongoing user involvement for the proposed duration of the project?
4. Is development management able to commit to the level of development resources required for the Business
Study and to ongoing involvement for the proposed duration of the project?
5. Will all necessary equipment and facilities be available as required?
6. Is it clear what the criteria for acceptance are and are they rigorous enough to define the quality of deliverables
while allowing the requirements to flex during development?
7. Are all the currently identified standards and guidelines available; for any that are not yet available, is there
sufficient resource to enable their development or procurement?

Roles involved

http://www.dsdm.org/version4/2/public/Outline_Plan.asp (1 of 2) [11-1-2008 15:58:24]


DSDM Public Version 4.2 - Outline Plan

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Project Manager


Contribution Visionary, Technical Co-ordinator, Team Leader
Review Executive Sponsor, Visionary, Technical Co-ordinator
Acceptance Executive Sponsor, Visionary, Technical Co-ordinator

Points to Consider

At the end of the Feasibility Study, it will not be possible to provide solid answers to many of the questions placed by
production of the Outline Plan. This is perfectly acceptable. The detail will evolve to the level required for development
activity to be conducted in a controlled way during the Business Study.

The Business Study should be timeboxed, i.e. it should have a date set on which it will end. This will prevent too much
time being spent on detail that should be left until during Functional Model Iteration.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Outline_Plan.asp (2 of 2) [11-1-2008 15:58:24]


DSDM Public Version 4.2 - Post-Implementation Review Report

Introduction When Lifecycle People Products Management Development Tailoring Other

Post-Implementation Review Report

Introduction

The Post-Implementation Review Report captures lessons learnt about the system in use and an assessment of the
benefits achieved.

Purpose

To determine whether or not the product has caused any problems in use.

To decide if there are any enhancement opportunities that have been revealed by use of the product.

To demonstrate how well the expected benefits from the project were actually achieved

Quality Criteria

1. Does the report include comments from representatives of all those affected by the end product?
2. Does the report make recommendations in cases where a problem has been identified?
3. Have all proposed benefits from the Business Case been considered?
4. Where benefits have not been realised is there a clear approach to addressing the issue?

Roles involved

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Project Manager


Contribution All roles
Review Visionary, Technical Co-ordinator, Operations Co-ordinator
Acceptance Executive Sponsor

Points to Consider

The Post-Implementation Review usually occurs up to six months after the final delivery of the project. If the expected
business benefits cannot have accrued by this time, a later review specifically aimed at reviewing the benefits should
be planned. This could be as much as two years later.

Consider the volume of incident reports and change requests to assess the quality of the Delivered System.

http://www.dsdm.org/version4/2/public/PIR_Report.asp (1 of 2) [11-1-2008 15:58:37]


DSDM Public Version 4.2 - Post-Implementation Review Report

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/PIR_Report.asp (2 of 2) [11-1-2008 15:58:37]


DSDM Public Version 4.2 - Prioritised Requirements List

Introduction When Lifecycle People Products Management Development Tailoring Other

Prioritised Requirements List

Introduction

The Prioritised Requirements List defines what the proposed solution must do and how well it must do it.

It provides the foundations for all planning decisions throughout the project. It is used to determine:

● the order in which increments take place


● which products will be essential to achieve project success
● what timeboxes will deliver.

All requirements are prioritised using the MoSCoW rules.

Initially (in the Feasibility and Business Studies), the requirements will all be high-level, they will be refined and
amended throughout the project. In particular, the non-functional requirements are defined in detail during Functional
Model Iteration activities.

Purpose

To provide the Functional Model Iteration with a prioritised list of requirements (both functional and non-functional) for
investigation.

To identify the minimum usable subset of functionality that will support the business. (This subset is guaranteed to be
delivered.)

Quality Criteria

1. Have all the currently identified requirements been prioritised?


2. Have all the priorities been assigned in collaboration with the users?
3. If the development is in one project, does user management accept the possibility that solutions to low priority
requirements may not be delivered (at least initially)?
4. If the development is a set of projects, does user management the possibility that solutions to low priority
requirements may not be delivered until a later?

Roles involved

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Project Manager


Contribution All roles
Ambassador User, Project Manager, Technical Co-ordinator,
Review
Team Leader
Acceptance Visionary, Ambassador User, Project Manager

Points to Consider

http://www.dsdm.org/version4/2/public/PRL.asp (1 of 2) [11-1-2008 15:58:50]


DSDM Public Version 4.2 - Prioritised Requirements List

Prioritisation is best achieved collaboratively in a Facilitated Workshop.

The requirements evolve from the objectives that are detailed in the Feasibility Report. These will be further analysed
and detailed in Functional Model Iterations throughout the project to create a Functional Model.

The Prioritised Requirements List should be reviewed throughout the project. The list must be updated (and possibly re-
prioritised) every time a new requirement is identified or an existing requirement's priority is changed.

A high-level Must Have requirement may well decompose into a set of requirements some of which have lower level
priorities. To ensure that the focus of development is on what is really needed it is advisable to check that priorities are
not inherited from the higher level by default. A decomposed Prioritised Requirements List could be structured as
follows:

● Business Requirement X (Must)

❍ Function/Feature X.1 (Should)


■ Quality Criterion X.1.a (Must)

■ Quality Criterion X.1.b (Should)

■ Quality Criterion X.1.c (Could)

❍ Function/Feature X.2 (Must)


■ Quality Criterion X.2.a (Must)

■ Quality Criterion X.2.b (Should)

■ Quality Criterion X.2.c (Won't)

● Business Requirement Y (Should), etc.

Where a project plans to purchase a solution (e.g. a package), it is important to understand the key requirements
independently of what is in the market. This will make it possible to evaluate alternative solutions in terms of their fit
with the real business needs.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/PRL.asp (2 of 2) [11-1-2008 15:58:50]


DSDM Public Version 4.2 - Risk Log

Introduction When Lifecycle People Products Management Development Tailoring Other

Risk Log

Introduction

The Risk Log is opened at the start of the project, since Risk Management is an ongoing process throughout the life of
a project. The Risk Log is officially "published" at the end of the Functional Model Iteration to provide a risk assessment
checkpoint. However it is used throughout the life of a project to record the risks as they are identified at any point in
the lifecycle. The reason that it is defined as a product of the Functional Model Iteration (FMI) is that the end of the final
pass through FMI in an increment is the latest point at which the development of risk countermeasures are feasible.
Risks that emerge after that point in an increment will have to be handled more reactively.

Purpose

To assist management in deciding the future of the project.

(Note: Risk analysis starts at the beginning of the project, but given the short time scales of DSDM projects to delivery
of an increment, this is the latest point at which the development of risk avoidance or containment strategies are
feasible. Risks that emerge from here on will probably be handled more reactively.)

Quality Criteria

1. Are all the factors potentially affecting the success of the project discussed?
2. Are risks sufficiently quantified for a decision to be made?
3. Does each risk have at least one countermeasure identified?

Roles involved

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Project Manager


Contribution All roles
Executive Sponsor, Visionary, Project Manager, Technical Co-
Review
ordinator
Acceptance Executive Sponsor, Visionary, Technical Co-ordinator

Points to Consider

No project should continue if the level of risk or the costs associated with their associated countermeasures is
unacceptable. The Risk Log should be reviewed at key management milestones (e.g. at the end of a phase)
throughout the project to ensure that this is not the case.

http://www.dsdm.org/version4/2/public/Risk_Log.asp (1 of 2) [11-1-2008 15:59:00]


DSDM Public Version 4.2 - Risk Log

The first entries in the Risk Log are likely to be those identified during the initial analysis of the Suitability/Risk List.

For risk monitoring and reporting purposes, the top five to ten risks at any given time should be extracted to provide
focus in discussions between the Project Manager and other parties. The simple act of maintaining a list of current
risks helps to keep risk management at the forefront of the Project Manager's mind.

The Risk Log can be as simple as a table held in a spreadsheet, which contains the following columns:

● The class of risk (business, systems or technical).


● A description of the risk. This should be in sufficient detail to be understood by all interested parties but short
enough to enable a checklist approach to risk monitoring throughout the project.
● The likelihood of the risk occurring (high, medium or low).
● The severity of impact on the project should the risk occur (high, medium or low).
● One or more proposed countermeasures, which will mitigate the risk either by preventing it occurring or by
containing when it arises. The countermeasures should include the dates beyond which they are no longer
applicable.
● The status of the risk (open or closed), open risks are still possible, closed risks have either happened and
have been dealt with or the time at which they were likely to happen has passed.

In larger projects where communication channels need to be more formal, the Risk Log could also contain:

● The owner of the risk (who is responsible for monitoring the risk and/or implementing any countermeasures)

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Risk_Log.asp (2 of 2) [11-1-2008 15:59:00]


DSDM Public Version 4.2 - System Architecture Definition

Introduction When Lifecycle People Products Management Development Tailoring Other

System Architecture Definition

Introduction

The architecture described in the System Architecture Definition is for both the functional architecture and the technical
architecture. The architecture describes the coherence of hardware, software and available components.

The System Architecture Definition is produced during the Business Study because it is needed as soon Functional
Model Iteration begins. The Developers must know the high-level design and they must know what their development
tools are so that they can work effectively from the outset.

Purpose

To provide a common understanding of the technical architectures to be used during development and implementation.

To describe the target platform and (if different) the development platform.

To give an outline description of the software architecture (i.e. the major software objects or components - both
process and data - and their interactions).

Quality Criteria

1. Is the architecture appropriate for the requirements?


2. Have the risks in the proposed architecture been properly considered - in particular, are all components of the
proposed architecture available and mutually compatible?
3. Will migration from the development platform to the target platform be able to occur easily? If not, are all
foreseeable problems identified?
4. Is the outline software architecture sufficiently well defined to give developers a high-level view of the
proposed computer system?
5. Is the architecture defined at an appropriate level, so that it will not be too vulnerable to change as the project
progresses?
6. Has advantage been taken of any opportunities for reuse of existing components?
7. Can the architecture be expected to cope with performance, capacity and resilience requirements?

Roles involved

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Technical Co-ordinator


Contribution Technical Co-ordinator, Team Leader, Developer, Tester
Review Technical Co-ordinator, Team Leader, Developer
Acceptance Technical Co-ordinator, Project Manager, Operations Co-ordinator

Points to Consider

The System Architecture Definition must be in enough detail to enable both the Development Plan and a sound
business case in line with local procedures to be created based on this product, the Business Area Definition and the
Prioritised Requirements List.

http://www.dsdm.org/version4/2/public/SAD.asp (1 of 2) [11-1-2008 15:59:13]


DSDM Public Version 4.2 - System Architecture Definition

For the development platform, include not only development tools but also control tools such as configuration
management, testing and requirements tracking tools. The techniques, procedures, etc. to be used with all tools should
be included in the Development Plan.

Although it is produced during the Business Study, the System Architecture Definition will evolve during the
development activities of the project as more detail is added about the architecture and design of the system. Note:
The system architecture and design will be included in the Delivered System.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/SAD.asp (2 of 2) [11-1-2008 15:59:13]


DSDM Public Version 4.2 - Tested System

Introduction When Lifecycle People Products Management Development Tailoring Other

Tested System

Introduction

The Tested System is the system when it is ready to be migrated into operational use. It consists of the system
increment to be delivered, all supporting documentation and Test Records.

Purpose

To provide a system that performs all agreed functionality and which meets all the agreed non-functional requirements.

To provide a working system which can be placed safely in the users' environment.

To provide support and maintenance staff with sufficient information to perform enhancements, support the users,
perform system management tasks, etc.

Quality Criteria

1. Does the system satisfy all the user-defined acceptance criteria?


2. Are the developers satisfied that the system is sufficiently robust to be put into full operation?
3. Has the system been tested at an appropriate level, considering its intended use?
4. Is there evidence that all the essential requirements (functional and non-functional) have been tested and,
where necessary, demonstrated to the users?
5. Have any and all safety-related and product liability aspects of the system been properly validated?
6. Has all functionality that is provided to support implementation been adequately tested (in particular, has
account been taken of any need for data conversion/uploading software)?
7. Are all components of the Tested System traceable to the Functional Model?
8. Are all components rejected in the design review documents omitted from the Tested System?
9. Is the system documentation consistent with the software?

Roles involved

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Project Manager, Team Leader


Contribution Ambassador User, Advisor User, Developer, Tester
Visionary, Ambassador User, Advisor User, Technical Co-
Review
ordinator, Team Leader, Developer, Operations Co-ordinator
Visionary, Ambassador User, Technical Co-ordinator, Operations Co-
Acceptance
ordinator

http://www.dsdm.org/version4/2/public/Tested_System.asp (1 of 2) [11-1-2008 15:59:24]


DSDM Public Version 4.2 - Tested System

Points to Consider

Due to business timescale constraints, the Tested System might cover only an agreed subset of all the functional and
non-functional requirements. What is important here is that the subset is agreed.

The documentation in the Tested System could include some or all of the following:

● User Documentation
● Handover documents
● Support guide
● Operating procedures
● Backup and recovery procedures
● Disaster recovery procedures
● Build procedures
● Install procedures
● Help desk scripts
● Design documentation (evolved from the System Architecture Definition)
● Selected models and textual parts of the Functional Model
● Business procedures
● Service level agreements
● Training documentation

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Tested_System.asp (2 of 2) [11-1-2008 15:59:24]


DSDM Public Version 4.2 - Test Records

Introduction When Lifecycle People Products Management Development Tailoring Other

Test Records

Introduction

Test Records prove the quality of product that has been achieved. They also provide maintenance and support staff
with the information that they need when testing changes to the operational system.

Because of the tight timescales of DSDM projects, the production and update of Test Records should be as
unbureaucratic as possible. DSDM provides guidance on Testing.

Purpose

To show that tests have been performed in accordance with the Test Strategy identified in the Development Plan.

Quality Criteria

1. Have tests been appropriately documented (for example does each test identify the requirements and
business rules addressed by the test)?
2. If appropriate, have test specifications been reviewed?
3. Are records available to show that all required tests have been performed and that the user involvement in that
testing is as required?
4. Have all problems noted during testing been properly identified and recorded?
5. Have regression tests been performed appropriately?
6. Do the Test Records contain sufficient detail to enable the tests to be run again in future?

Roles involved

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Tester, Ambassador User


Contribution Developer, Ambassador User, Advisor User
Review Technical Co-ordinator, Team Leader
Acceptance Project Manager, Quality Manager

Points to Consider

Records should be kept of both user and developer tests.

Test plans (or specifications) contain the scope of conditions to be tested and describe how the testing will be done, via
test cases, environment and data. They are essential as a basis for test execution and monitoring progress of tests,
coverage and gaps. For DSDM it is still necessary to plan testing, and a test plan is necessary to ensure repeatability
of tests; however, they are not generally as detailed as traditional Test Plans.

Regression testing is a very important aspect of testing in DSDM because of the iterative and incremental development
approach. Good test records will enable a regression test library to be built up for use during both development and
maintenance.

Although needed for repeatability, test scripts should be kept brief and are often a simple checklist of actions and
expected results.

http://www.dsdm.org/version4/2/public/Test_Records.asp (1 of 2) [11-1-2008 15:59:36]


DSDM Public Version 4.2 - Test Records

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Test_Records.asp (2 of 2) [11-1-2008 15:59:36]


DSDM Public Versionl 4.2 - Timebox Plan

Introduction When Lifecycle People Products Management Development Tailoring Other

Timebox Plan

Introduction

The Timebox Plan provides the plan for an individual timebox within Functional Model and Design and Build Iteration.
The Timeboxing section describes the recommended process to follow in a timebox and what to plan when.

The Timebox Plan assumes that all procedures, standards, etc. defined in the Development Plan will be adhered to.

Purpose

To define the products of an individual timebox

To define key milestones, e.g. technical or user review dates, within a timebox

To agree the prioritisation of products and activities within a timebox

Quality Criteria

1. Are the estimates of effort reasonable? Were they produced by the people doing the work?
2. Have acceptance criteria been agreed for the products of the timebox? If they have not, is it clear when these
will be available?
3. Is there a high degree of certainty that the Must Haves will be created, developed and tested to the required
standard?
4. Are the review dates agreed with all key personnel?
5. Have lessons learnt in previous timeboxes been applied?
6. Can the team commit to delivering at least the Must Haves by the agreed end date?

Roles involved

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Team Leader


Contribution Ambassador User, Technical Co-ordinator, Developer, Tester
Review Ambassador User, Technical Co-ordinator, Developer, Tester
Acceptance Project Manager, Technical Co-ordinator

Points to Consider

Creating Timebox Plans more than a week before the timebox is due to start is often a waste of time since the results
of preceding timeboxes may well affect the content and nature of the products required.

Do not, under any circumstances, load the timebox with only Must Have items. It is the flexibility provided by the lower
priority requirements that enables the teams to guarantee delivery on time.

See Project Planning for an overview of the planning activities in DSDM projects.

http://www.dsdm.org/version4/2/public/Timebox_Plan.asp (1 of 2) [11-1-2008 15:59:50]


DSDM Public Versionl 4.2 - Timebox Plan

The Visionary may wish to review and approve the plans for timeboxes that are particularly critical from the business
point of view.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Timebox_Plan.asp (2 of 2) [11-1-2008 15:59:50]


DSDM Public Version 4.2 - Trained User Population

Introduction When Lifecycle People Products Management Development Tailoring Other

Trained User Population

Introduction

No project solution can be considered delivered until all the people who will need to use it can do so effectively. The
Trained User Population product is included in DSDM to highlight this important aspect of project success.

Purpose

To enable all users to use and operate the computer system and any new business processes effectively.

Quality Criteria

1. Do the trained users have sufficient knowledge and skill to manage and operate the system?
2. Have all relevant users received the necessary training?
3. If required, is any ongoing training material for future users available?
4. Is the User Documentation easily available to all users?
5. Has a strategy been devised to train future new members of the user population?
6. Has a strategy been devised to train existing users in future developments of the system?

Roles involved

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Project Manager, Trainer


Contribution Ambassador User, Team Leader, Developer, Trainer
Review Visionary
Acceptance Visionary

Points to Consider

Users from outside the project who are involved in acceptance testing will have to be trained prior to the test. One
purpose of the acceptance test is thus to validate the training before it is given to remaining users.

The Trained User Population may extend beyond end-users to other people, i.e. those who will administer the system,
provide help desk support, etc.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Trained_User_Population.asp [11-1-2008 16:00:01]


DSDM Public Version 4.2 - User Documentation

Introduction When Lifecycle People Products Management Development Tailoring Other

User Documentation

Introduction

The User Documentation is created during Design and Build Iteration. It is finally delivered during the Implementation
phase as it may well undergo change as a result of feedback from user training activities.

User Documentation may be published documents, help text, what to do as a result of error messages, indeed
anything that needs to be available to the users to help them use the system effectively.

Purpose

To describe to the users how to use the Delivered System.

Quality Criteria

1. Is user guidance available to users in an appropriate format (e.g. electronic documents, paper documents, and
help facilities)?
2. Does it offer a complete and unambiguous step-by-step guide to using the Delivered System?
3. Does it cover all the functionality within the system as delivered?
4. Does it explain how the system interacts with other systems, manual or otherwise?
5. Where there are different classes of user, does it explain who should read what?
6. Is it easy to reference by business-based tasks?
7. Is it written in the language of the user population?
8. If required, does it offer step-by-step explanations of any manual procedures associated with the computer
system?
9. Does it contain guidance on what to do when errors arise, for instance, whom to call and standard approaches
to recovery and problem solving?
10. If it contains a tutorial, is this easy to follow? Has a new user tried it out?

Roles involved

The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular
responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate.

Production Ambassador User


Contribution Developer
Review Project Manager, Team Leader, Developer
Acceptance Visionary, Ambassador User

Points to Consider

Ambassador Users will understand the system better from a non-IS point of view than anybody else. Hence, the User
Documentation should be created largely by the Ambassador Users on the project to ensure that it is in the language
understood by the user population. This includes writing such items as help text.

http://www.dsdm.org/version4/2/public/User_Documentation.asp (1 of 2) [11-1-2008 16:00:42]


DSDM Public Version 4.2 - User Documentation

There may well be a need for special documentation for technical users, e.g. system administrators. This should be
produced by the Developer role and reviewed and accepted by the Operations Co-ordinator. This is included in the
Tested System product definition.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/User_Documentation.asp (2 of 2) [11-1-2008 16:00:42]


DSDM Public Version 4.2 - Management techniques

Introduction When Lifecycle People Products Management Development Tailoring Other

Management tools and techniques in DSDM projects


Since DSDM projects are flexible in their development activities, all aspects of their management need to be equally
flexible, while maintaining a level of control that ensures successful delivery of the required business solution. The
management techniques described here do not define everything there is to know about the particular subject but
provide guidance about the special considerations to be given in an agile project environment.

The management tools and techniques are:

● Timeboxing, a fundamental technique for ensuring that projects deliver solutions exactly on the date required
(a detailed timebox process is provided)
● MoSCoW Prioritisation, the technique twinned with timeboxing that enables the project to be flexible about
what it needs to do at any point in the project and keep the focus throughout on delivering the real business
benefits
● Project Management highlighting the differences in approach from traditional activity-based project
management to a focus on managing empowered teams working to tight deadlines
● Project Planning, which covers how planning is carried out iteratively and incrementally in line with the DSDM
approach to development
● Risk Management, which focusses on when and how risk management activities occur in DSDM projects and
highlights risks that accompany weak application of the DSDM principles
● Measuring DSDM projects, which provides guidance on what to measure and when to ensure that a project is
to be successful
● Estimating, which covers what to estimate, when and how in line with the project planning approach
● Quality Management, covering how the DSDM framework provides an excellent basis for all aspects of quality
assurance and control activities and which includes a project health checklist targeted at DSDM projects.

If you are using XP in conjunction with DSDM the Using DSDM with XP section of the manual describes a combined
lifecycle.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Management_Overview.asp [11-1-2008 16:00:59]


DSDM Public Version 4.2 - Timeboxing

Introduction When Lifecycle People Products Management Development Tailoring Other

Timeboxing

Overview

Timeboxing is a very important aspect of DSDM projects. Without timeboxing, project teams can lose their focus and run out of
control. Timeboxing is a process by which defined objectives are reached at a pre-determined and immovable date through
continuous prioritisation and flexing of requirements using the MoSCoW rules.

There are various levels at which timeboxing takes place.

● The project end-date is fixed and the overall business objectives to be achieved by that date are defined
● The end date for each increment within the project is fixed and the prioritised set of business and technical requirements
to be satisfied by that date are defined
● The end date for phase level activities is fixed, e.g. for the Feasibility Study, and the objectives for this project defined
● The end date for part of the prototyping activity is fixed and the prototype is created, reviewed and tested according to the
objectives defined in the timebox schedule contained in the Development Plan
● The end time for a workshop, meeting or review is fixed and the participants work to the predefined and prioritised
objectives.

None of these is possible without the ability to prioritise what must be achieved within the given timeframe. This enables items of
lesser importance to be dropped (or items with greater importance to be added) as more is learnt about what needs to be done to
satisfy the predefined objectives of the timebox.

The rest of this section covers the development (or prototyping) timeboxes that are run throughout the Functional Model Iteration
and Design and Build Iteration phases. These will be referred to simply as "timeboxes".

A timebox must have an agreed scope and clear objectives based on a subset of the Prioritised Requirements List. An important
aspect of timeboxes is that control is not activity-based. The aim of a timebox is to make something. How that thing is put together
will be decided by the people doing the work, as long as the project's standards and procedures are followed.

A timebox will produce something visible in order for progress and quality to be assessed. Examples of what such a timebox could
deliver include a part of the Functional Model, a partial system component or an early version of the system. All necessary
reviews and tests are contained within the timebox, otherwise it will be difficult to fit any necessary rework or change into
subsequent timeboxes. This means that a timebox contains at least one complete cycle of the Functional Model Iteration or the
Design and Build Iteration, though possibly for only part of the total system.

Timeboxes are typically between two and six weeks in length: the shorter the better. However these limits are not mandatory. A
major advantage of keeping timeboxes short is that the amount of work to be achieved within a timebox is smaller and therefore a
greater degree of confidence is possible in effort estimates.

Timeboxes work through the effective application of empowerment. The team working in the timebox must agree the objectives
and the developers and testers must themselves estimate the time required. At the deadline, the users must be able to approve
the delivery of the products covered by the timebox. If it appears that deadlines could be missed, the deliverable should be de-
scoped dropping the lower priority items, i.e. Should Have and Could Have requirements can slip and timing never does.
Continuous negotiation of what is important is at the team level. The Ambassador Users must decide whether a requirement must
be included in the current timebox or could be dropped from the increment or (worst case to be avoided if at all possible) slipped
to a later timebox, which means that the whole timebox schedule needs to be revisited. (Note: the slippage of Must Have
requirements usually necessitates escalation). The one factor that does not change is the timebox deadline. This approach leads
to the frequent delivery of products to the users on the project. It gives good project control, but makes management more intense.

The detailed planning of a subsequent timebox containing dependent work cannot be started before the current timebox is
complete. This is because the current timebox may deliver something that is incomplete. This could affect the objectives and
activities of the dependent timebox.

The timebox (like DSDM in general) works best when the development team has good tool support that enables speedy delivery
of products, be they models, documents or software. The teams must be able to build and evolve products quickly without being
hampered by the technology they are using.

The rest of this section describes how timeboxes are scheduled within an increment of the project and the recommended timebox

http://www.dsdm.org/version4/2/public/Timeboxing.asp (1 of 6) [11-1-2008 16:01:12]


DSDM Public Version 4.2 - Timeboxing

process to be followed in an individual timebox.

Scheduling Timeboxes

At the project level, the Development Plan defines the timeboxes within an increment. This ensures that the key business
requirements (both functional and non-functional) are addressed in the most appropriate order, and that the availability of
resources and ordering of timeboxes matches those requirements.

Each timebox should guarantee to deliver something. Guaranteed deliverables can only be achieved if the development teams
agree that the estimated effort to satisfy the requirements is well within their capability in the time available. As a rule of thumb,
the following breakdown should be used:

Must Have approximately 60% of effort


Should Have approximately 20% of effort
Could Have approximately 20% of effort

The estimated effort in the Must Haves should never be above 75% (except in rewrites of well-documented systems).

What to consider

The order of timeboxes should not only be driven by the requirements for the increment but also by the need for architectural
components to be in place on which to build the functionality and by the risks to the project. There are two key categories of risk to
consider: architectural and estimating. Architectural risk applies (a) to those parts of the system, which, if left until later, may cause
earlier work to be abandoned or require significant rework and (b) to elements of the system architecture that are uncertain and
need to be tried out early. Estimating risk applies to requirements where developers cannot confidently say that they have a
reasonable understanding of the time required to satisfy them. Clearly, in many instances, architectural risk and estimating risk will
be closely connected, but it is worth considering them separately when determining the order of timeboxes.

Early timeboxes should address key functionality, architectural risk and/or estimating risk.

Examining the functionality

To determine the functionality to be addressed by timeboxes, it is necessary to decide on suitable functional groupings that will
make sense to the users as a discrete set of activities taking either a horizontal or a vertical view. The obvious groupings are by
user tasks or Use Cases. These functional groupings should be kept as small as possible at this stage. A functional grouping of
only one item is the ideal, but obviously this cannot be enforced at all times.

Design considerations may occasionally override business considerations. Some functionality will necessarily appear in more than
one functional grouping. For instance in an order processing system, the operation of viewing the stock level of an item could
appear in many different user functions. Such common functionality is probably fundamental to the success of the increment and
needs to be scheduled as early as possible however trivial it may seem to the business processes to be supported by the
increment.

Determining architectural dependencies

The Prioritised Requirements List and the System Architecture Definition provide the basis for deciding what architecture
components must be present in the increment. For instance, if it is essential that some information from an existing system is
available then the interface to that system must be provided by the increment.

The architecture components should ideally be available before the function that needs them is built. Therefore the prioritisation of
the functional requirements will drive the prioritisation of the architecture components to a degree. However there will be some
components which are acknowledged as important but which cannot be aligned to particular functions. For instance, if fast
response times are of the essence, it may be necessary to change part of the standard platform to achieve this. When this is done
is not dependent on the functionality offered rather on when it will fit best with other tasks to be carried out.

When planning the timebox schedule, the aim should be to identify all architecture components (i.e. Design and Build activities)
that will be needed by the increment and to distribute them across the increment.

Architecture components should be as clearly prioritised as the functions. Just as the functions are prioritised to allow some
functions to be dropped because of time constraints, ideally there should be the possibility of moving away from an architecture
component that creates problems.

http://www.dsdm.org/version4/2/public/Timeboxing.asp (2 of 6) [11-1-2008 16:01:12]


DSDM Public Version 4.2 - Timeboxing

Other scheduling considerations

All the normal planning considerations apply, such as holidays. Additionally, try not to end timeboxes on a Friday. It may be
necessary to use the weekend for emergency overtime. However, overtime should not be built into the estimates. The plan should
assume normal working hours. Overtime should only be used in emergency situations such as after technical failures or
unexpected sickness by key team members.

The Timebox Process

Overview

At the timebox level, it is essential to ensure that each timebox addresses the correct objectives, and that a process is followed
that is disciplined enough to promote acceptable quality levels yet allow for creativity within the team.

The process outlined here provides a framework of controls. It is not prescriptive: additional review points or development
refinement cycles can be added for any timebox as appropriate or review points may be omitted. However, if at all possible, the
end of refinement review point should be kept in place, since this allows the team time to correct errors and tidy up ready for the
next timebox.

Every timebox can be considered as comprising five main stages:

1. Kick-off meeting
2. Initial investigation of the products to be delivered by the timebox
3. Refinement (development of the timebox products including testing and reviews)
4. Consolidation (final testing of software products, completion of documentary products and merging with previous
products)
5. Closeout meeting

Investigation duration should be approximately 15%

Refinement duration should be approximately 70%

Consolidation duration should be approximately 15%

Pre-timebox activities

The Team Leader should revisit the planned products for the timebox against the Development Plan with the Project Manager and
possibly the Technical Co-ordinator. If, given the current state of the project, there are any issues regarding the feasibility of the
planned products, then the objectives of the timebox should be redefined and all future timeboxes reassessed.

The Project Manager delegates monitoring and control to the timebox Team Leader of any risks contained in the Risk Log that are
relevant to the timebox activities and products.

http://www.dsdm.org/version4/2/public/Timeboxing.asp (3 of 6) [11-1-2008 16:01:12]


DSDM Public Version 4.2 - Timeboxing

Note: Inside the timebox, the Team Leader should keep a mini risk log (starting with the delegated risks from the project Risk
Log). While the Team Leader is the nominated risk controller, every member of the timebox team shares the responsibility for
ensuring that risks are identified and recorded in the mini risk log and are monitored effectively. The timebox risks should be
considered on a daily basis at the daily meetings held throughout the timebox. If during a timebox, the team identifies a risk that is
obviously beyond the scope of the timebox, it is immediately escalated to the project level with the agreement of the Project
Manager.

When determining the feasibility of a timebox, particular attention needs to be paid to:

● products on which this timebox is dependent and which have been dropped from earlier work because they were not
Must Haves
● the actual speed of delivery by the team in previous timeboxes compared with estimated effort in the Development Plan
● issues arising from the current work, such as the agreement of new Must Haves
● architectural constraints.

Clearly all the normal planning considerations apply to this exercise, such as verifying the availability of key resources (both
personnel and equipment).

Before the kick-off meeting, the Team Leader should send out the agenda and any necessary documents to all participants (see
below).

Kick-off meeting

The aim of the kick-off meeting is to agree and confirm:

● The MoSCoW prioritisation for this timebox.

Note that requirements do not necessarily inherit their priority from the Prioritised Requirements List. For the purposes of
a particular timebox, a Must Have requirement may have a lower priority for the purposes of scheduling activity, e.g. it
could be covered in this timebox, but it must be covered in the next one.

● That delivery of the Must Haves for this timebox can be guaranteed in the time available.

● The acceptance criteria for products to be considered delivered. If possible, these should also be prioritised. Hence a
Must Have requirement must satisfy acceptance criteria X and Y and could satisfy acceptance criterion Z. If it is a
software product, the testing to be carried out in the timebox can be similarly prioritised, e.g. it must be unit-tested,
should be link-tested and must be user-tested.

In many cases, it will not be possible to determine the detail of the acceptance criteria at this point. However, they must
be determined during investigation and, at the latest, agreed during the review at the end of Investigation.

● The dates for key reviews.

Key reviews include not only those at the end of Investigation and Refinement but also reviews by Advisor Users of
prototypes and reviews by the Technical Co-ordinator of the design decisions taken.

● (For projects with more than one team) all interfaces with, and dependencies on, concurrent timeboxes.

The kick-off meeting should explicitly recognise whether further timeboxes are planned to address the same area of
business needs at a later time in the project.

The following roles should be present at the kick-off meeting:

● The Team Leader, who will lead the meeting.


● The Project Manager to ensure that any changes to the timebox products and acceptance criteria do not adversely affect
current and future activities elsewhere in the project.
● The Technical Co-ordinator to ensure that any system-level issues are considered (particularly those which affect
concurrent timebox teams) and to agree the technical aspects of the acceptance criteria. The Technical Co-ordinator is
specifically responsible during the meeting for ensuring that team members understand the architecture and design
decisions that are relevant to the timebox, that they know what standards and procedures to follow and that they are
aware of non-functional requirements that cross timeboxes, e.g. performance and reliability.
● For key timeboxes only, the Visionary, to agree the business aspects of the acceptance criteria and, if necessary, to
agree to the involvement of additional business people.
● All Ambassador Users, Developers and Testers in the timebox team, since their agreement to the timescales and
acceptance criteria is essential.

Investigation

http://www.dsdm.org/version4/2/public/Timeboxing.asp (4 of 6) [11-1-2008 16:01:12]


DSDM Public Version 4.2 - Timeboxing

The aim of Investigation is to provide a firm foundation for the work to be carried out during Refinement. In Functional Model
Iteration timeboxes, this will entail the Developers and Ambassador Users jointly investigating the requirements in more detail and
producing an initial prototype, draft document, etc. In Design and Build Iteration timeboxes, this will include determining the detail
of testing and acceptance activities. Investigation in DBI is much shorter than in FMI, but should not be ignored.

The review point at the end of Investigation should be attended by all team members. The Technical Co-ordinator should also
attend, particularly if there are design decisions to review. The aim of the review is to confirm the developers' understanding of
what is required and that the acceptance criteria will satisfactorily demonstrate that the products are of the required standard. This
is a critical review, at which all Advisor Users with an interest in the business functions being implemented should attend and
provide feedback on the scope and approach.

Refinement

Refinement is where the bulk of the work of the timebox is carried out. It begins with a team planning session. This session can be
run back-to-back with investigation review. The only participants are the team working in the timebox.

It is a good idea to consider the end of refinement as the end of the timebox when planning how to carry out the work. Then
Consolidation can be used to tidy up all the loose ends, which will often be omitted in the drive to create new product. The end of
refinement review is then a major review, which looks at what the timebox has created and tested and determines what
amendments will be necessary to satisfy the acceptance criteria. If this approach is taken then the people responsible for
accepting the timebox products should all attend the end of refinement review or at the very least provide their feedback into the
meeting. The Closeout meeting then just confirms that all necessary actions raised at the end of refinement review have been
satisfactorily carried out.

During refinement, all necessary updates to the requirements documents should be noted. All system-level documentation
changes should be noted and carried out either now or during Consolidation. The system-level documentation thus evolves to
capture both the logical and physical architectures.

Further iterative cycles can be carried out during Refinement. However informal these are, each iteration must end with a review
by peer developers, the Ambassador users or the Technical Co-ordinator, depending on the work carried out.

Testing is performed as agreed in the kick-off meeting and the procedures stated in the Test Strategy defined in the Development
Plan are followed.

Refinement ends with a review with (at least) the Ambassador Users, and other users as appropriate. The review should
determine what actions are necessary to achieve completion of the work according to the acceptance criteria. No new functionality
should be added or changes introduced to the products after this point. Major change requests made at this time should be raised
as issues to be addressed in subsequent timeboxes. However if major changes do surface at this time, it is probably because
decisions made during the timebox have not involved the right people. If this is the case, the Team Leader and Project Manager
should review the knowledge required for future timeboxes.

Consolidation

During Consolidation the actions agreed at the end of refinement review are carried out together with any work required to satisfy
organisational or project standards. Testing is completed. If any software product does not pass its tests, it is not considered
delivered and is fed into the planning exercise needed before the next timebox begins. This does not mean that it automatically
moves into the next timebox, it simply becomes something to be considered during planning. Its inclusion will depend on the
objectives of the next timebox, which could be very different.

The Team Leader plans the next timebox while the team is completing the timebox products.

The Technical Co-ordinator checks that the timebox products have passed the relevant checks and tests and then incorporates
documentary products into the project deliverables. The Developers build the software products into the project deliverables.

Consolidation ends with a short team review and then passes into the Closeout meeting.

Closeout meeting

The aim of the Closeout meeting is to gain sign-off of all the products delivered by the timebox. Hence the people responsible for
accepting the products should either attend or give their prior consent. If the timebox has been well controlled, this meeting should
be very short and can be run back-to-back with the kick-off meeting for the next timebox.

http://www.dsdm.org/version4/2/public/Timeboxing.asp (5 of 6) [11-1-2008 16:01:12]


DSDM Public Version 4.2 - Timeboxing

During the Closeout meeting, the Technical Co-ordinator confirms that the products are to the required technical standard and the
Ambassador Users provide feedback on the fitness for business purpose of the products.

Each of the risks in the mini risk log should be examined to see whether or not the risks are closed or not. There are two ways that
a timebox risk can be closed:

● It has been dealt with by the timebox team and is no longer a risk
● It was only relevant to the activities within the timebox and therefore is now redundant.

If any risk on the mini risk log is not able to be closed at the end of the timebox and will therefore affect the work in other
timeboxes then it should be passed up to the project level for risk management and recorded in the project Risk Log.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Timeboxing.asp (6 of 6) [11-1-2008 16:01:12]


DSDM Public Version 4.2 - Daily Meetings

Introduction When Lifecycle People Products Management Development Tailoring Other

Daily Meetings
During each timebox, the team working on the timebox should meet daily to review their progress and to raise issues.
This meeting provides the team with evidence regarding their progress and the problems they face. It also enables
team members (who may have spent the day working on their own) to see what is happening around them, which may
impact or be impacted by their own work.

Each daily meeting is guillotined at 30 minutes and ideally lasts no longer than 15 minutes. Discussion of issues,
disagreements, details, etc. should not be included in the daily meetings. Instead, the relevant team members should
discuss them afterwards.

The daily meetings should be held at the same place and time every day. This is one of the first things to be agreed
once the team is constituted. Ideally the meeting would be held at the very start of the working day or at the very end.
Where an organisation operates flexible working hours this is difficult to achieve, but it should be as near as possible to
the start or the end of the working day.

All team members attend. One person is assigned as Meeting Leader to be in charge of all daily meetings: either the
Project Manager or, where there are multiple teams, a Team Leader. This person is responsible for:

● Conducting the daily meeting.


● Ensuring that everyone reports progress.
● Making decisions at the meeting as needed.
● Recording impediments and causing them to be resolved.
● Keeping the meeting brief and in focus
● Documenting any action points, this is in effect keeping the project/team diary up-to-date.

The Meeting Leader asks every team member to answer three questions:

● "What work have you completed for this timebox since the last daily meeting?"
● "What (if anything) got in the way of completing the work you planned?"
● "What will you be doing between now and the next daily meeting?"

The outcome of the daily meeting could include:

● The transfer of a task to another team member because of task loading


● A new task identified
● The decision to get 2-3 team members together to decide how to solve a problem.

The Meeting Leader is also responsible for the measurement and management of the team's timeboxes in an
increment through:

● Monitoring that the to-do work is being steadily reduced


● Monitoring that risk is being reduced
● Managing all timebox issues

The daily meetings should provide the Meeting Leader with the required empirical evidence to carry out these tasks.

http://www.dsdm.org/version4/2/public/Daily_meetings.asp (1 of 2) [11-1-2008 16:03:51]


DSDM Public Version 4.2 - Daily Meetings

The daily meetings should highlight risks as they occur, such as an Ambassador User not being able to undertake
prototype review activities at the time expected within the timebox because of pressures from the business. These
should be entered in the team's mini risk log (described in Timeboxing) and monitored at future daily meetings as
necessary. The Meeting Leader should report immediately to the Project Manager on any areas that will either affect
the success of the timebox or will have an impact outside the timebox.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Daily_meetings.asp (2 of 2) [11-1-2008 16:03:51]


DSDM Public Version 4.2 - MoSCoW Prioritisation

Introduction When Lifecycle People Products Management Development Tailoring Other

MoSCoW Prioritisation

The MoSCoW Rules

Delivering on a guaranteed date (without working overtime) means that what was originally envisaged for an individual
delivery may have to be left out. However it is important that essential work is done and that only less critical work is
omitted. The method of ensuring that this is true is clear prioritisation of the requirements.

The simple MoSCoW rules are used to achieve this. The o's in MoSCoW are just there for fun. The rest of the word
stands for:

● Must have for requirements that are fundamental to the system. Without them the system will be unworkable
and useless. The Must Haves define the minimum usable subset. A DSDM project guarantees to satisfy all
the minimum usable subset.

● Should have for important requirements for which there is a workaround in the short term and which would
normally be classed as mandatory in less time-constrained development, but the system will be useful and
usable without them.

● Could have for requirements that can more easily be left out of the increment under development.

● Want to have but Won't have this time for those valuable requirements that can wait till later development
takes place; in other words, the Waiting List.

All of these requirements are needed for the full system. The "wish list" does not appear in the categorisation. The
MoSCoW rules provide the basis on which decisions are made about what the project team will do over the whole
project, within an increment of the project and during a timebox within an increment.

As new requirements arise or as existing requirements are defined in more detail, the decision must be made as to
how critical they are to the success of the current work using the MoSCoW rules. All priorities should be reviewed
throughout the project to ensure that they are still valid.

It is essential that not everything to be achieved within a project or a timebox is a Must Have. It is the lower level
requirements that enable teams to deliver on time by dropping out lower priority requirements when problems arise.

Hints and Tips

During the Business Study, prioritisation and scheduling can be tackled in two ways:

● The priorities for all the project's requirements are determined and then these are used to decide which set of
Must, Should and Could Haves are dealt with in which increments.
● The set of Must, Should and Could Haves are agreed for the first incremental delivery only - the rest of the
requirements are thus Won't Haves.

In both cases at the end of an increment, all unsatisfied requirements are reprioritised in the light of the needs of the
next increment. This means that, for instance, a Could Have that is unsatisfied in an increment may be demoted
subsequently to a Won't Have, because it does not contribute enough towards the business needs to be addressed
next. It does not mean that the Could Have remains as a Could Have forever.

http://www.dsdm.org/version4/2/public/MoSCoW.asp (1 of 2) [11-1-2008 16:01:25]


DSDM Public Version 4.2 - MoSCoW Prioritisation

MoSCoW prioritisation can be applied to activities as well as requirements. Examples of this are given in the
description of the kick-off meeting in the Timebox Process.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/MoSCoW.asp (2 of 2) [11-1-2008 16:01:25]


DSDM Public Version 4.2 - Project Management

Introduction When Lifecycle People Products Management Development Tailoring Other

Project Management

Introduction

The aim of all project management is to deliver the right output, on time and on budget using the available resources
wisely. It involves a number of activities that can be grouped broadly under headings such as planning, monitoring and
control. It also involves a wide range of skills involving people management as well as technical resource management.
In these broad respects managing a DSDM project is no different from managing any other project. It is the detailed
activities involved in DSDM project management that are usually very different from those involved in traditional project
management.

DSDM projects take a wide variety of forms from IT systems development through to business process design. An IT
system development may be a bespoke system created from scratch or it may involve the implementation of an
existing package. The project may be done in-house or by a software supplier. The DSDM project may be stand alone
or embedded in a larger development, which may in turn be managed by traditional methods or by DSDM.

The Project Manager may have an IT background or come from the system's user community. The Project Manager
may have a wealth of DSDM experience or none and he or she may have a wealth of project management experience
or none. In some organisations the Project Manager will only be appointed when the terms and conditions of the
project have been negotiated and agreed. In other organisations the same person may be in charge throughout the
project.

As a consequence of the wide range of project situations, the following advice relating to the responsibilities of the
project manager (as described in the Project Manager role definition) must be tailored to fit the specific circumstances
of the project and the individual performing the role.

Managing the DSDM approach

Management of traditional projects is about control: trying to prevent drift from the signed off specification, controlling
resources, etc. Managing a DSDM project is about enabling constant change while continuously correcting the course
of the project in order to maintain its aim at the target - a fixed delivery date for a usable system (as described in How
the Process Works). To be successful with DSDM, the organisation may have to change organisational, social and
technical elements at the same time. These all have impact on the management of the project.

In DSDM, users and developers collaborate to produce a system that both meets the business need and is
maintainable. This requires a change of style for those project managers, who are used to controlling their developers
tightly. They can be made very uncomfortable by the user/developer consensus approach taken in DSDM projects.
Indeed enabling the day-to-day activities in a DSDM project can be challenging for any project manager.

The collaboration in DSDM projects enables a "no blame" culture that requires a very different approach to project
management from that of more traditional methods. Such methods tend to assume that the requirements are fixed, at
least for the duration of the IT project and project managers can spend a lot of time protecting the specifications from
change in order to prevent time and budget overrun. Then, if the computer system fails to meet the requirements as set
out in the specification, it seen as the fault of the developers or, if it meets the specification but is of little use to the
business, the fault is claimed to lie with the users. Such confrontational attitudes should not be allowed to persist in
DSDM projects, so it is the responsibility of the DSDM Project Manager to ensure that collaboration is effective so that
these attitudes do not emerge.

This is not a license for an ill-disciplined project. Control still needs to be exercised to ensure that the project retains
focus on the business objectives and on the high-level Must Have requirements agreed during the Business Study.
These form the "goalposts" for the project and are important, especially in a multi-project environment. However, even
these may change during the project, but such a change will usually need agreement with the Executive Sponsor and
major stakeholders.

http://www.dsdm.org/version4/2/public/Project_Management.asp (1 of 6) [11-1-2008 16:02:02]


DSDM Public Version 4.2 - Project Management

Reporting to senior management and the steering committee

Communicating progress

The overall communications responsibility of the Project Manager cannot be stressed too highly. The team members
will probably communicate very effectively with each other especially if they are collocated with their users. In these
circumstances the Project Manager will be more concerned with ensuring that senior managers and other stakeholders
are kept up to date frequently. The rate of progress will be such that it is easy for people to get out of date quickly with
the project. The Project Manager cannot afford to wait for decisions from steering groups and committees so it is
especially important to keep the purse string holders well informed at all times.

Project planning and scheduling

The Project Planning section covers planning considerations throughout the DSDM process.

Monitoring progress

In a traditionally managed project, the project manager has a detailed plan against which to monitor and control
activities. In a DSDM project, there are typically more activities going on in parallel. Consequently, the DSDM Project
Manager has a number of distinctive responsibilities to ensure that the project is under control in each phase. These
are covered in the Typical Phase-by-Phase Activities in the PM Role description.

There will be no need for complex and bureaucratic monitoring systems in a small DSDM team working with clear
objectives in timeboxes of short duration. However, it is important to capture information on how much time is spent on
deliverables in order to ease the task of further estimating.

Sustaining a high rate of progress

The speed of development can pose some difficulties for managers from a traditional background in IT development. If
problems arise during a timebox then it is often tempting for the traditional manager to renegotiate the end date, as that
is what they would normally do. In a DSDM project, the timebox deadline is sacrosanct usually because it is set by the
business need. Consequently, the approved practice is to renegotiate the content of the timebox rather than its
duration. This is made a lot easier if the deliverables have been ranked using the MoSCoW rules.

Risk management

The Risk Management section contains the recommended risk management approach in DSDM projects and particular
risks to consider.

Targeting and motivating the teams

Self Directed Teams

DSDM projects are very dynamic, with rapidly evolving prototypes and frequent demonstrations to the users. There is
not time to manage this daily activity using a bureaucratic approach. The developers and users will know what is
happening because they are in a small team working in close proximity, ideally in the same room. A daily
"achievement" meeting is a good way of ensuring every team member is aware of how things are progressing.

DSDM teams are self-directed. The table below compares such teams with those that are more tightly managed:

Tightly managed teams Self-directed teams


Take directions Take initiative
Seek individual reward Focus on team contributions

http://www.dsdm.org/version4/2/public/Project_Management.asp (2 of 6) [11-1-2008 16:02:02]


DSDM Public Version 4.2 - Project Management

Focus on low-level objectives Concentrate on solutions


Compete Co-operate
Stop at preset goals Continually improve
React to emergencies Take steps to prevent emergencies

Tightly managed and self-directed teams

Sustaining team culture and morale

The Project Manager takes prime responsibility for sustaining the motivation and morale of the team. Usually this is no
problem as the morale of a DSDM team is sustained by the high rate of progress and the very positive feedback from
users about the quality of the frequent deliverables. To avoid morale slipping when any setbacks occur, it is important
to monitor the health of the team closely and to build in frequent rewards. Minor triumphs along the way can be
rewarded according to the culture of the organisation e.g. bringing in pizza, cakes or fruit and taking the team out of the
working environment for an hour.

Project managers also need to be on the lookout for burnout in themselves as well as in their team members. It has
been said that DSDM Project Managers are the ones that go prematurely bald or grey!

Project managers with very strong personal control needs can also encounter difficulties in executing DSDM projects.
A DSDM team has to be empowered to make decisions if the rate of pace of development and delivery is to be kept
high. This tends to lead to democratic methods with a high communications load on the manager and team members.
Again it helps if the manager has agreed clearly the roles and responsibilities of individual team members and other
stakeholders: use the DSDM Role definitions to decide who is responsible for what during the life of the project. The
role of the Project Manager must be closer to that of an arbitrator than to the ultimate decision making authority.

Keeping the teams on track

Project Managers need to protect the development teams from external interruptions. For instance, consider requesting
that email only be read at certain times of the day.

An open, "no blame" culture needs to be engendered so that nobody is afraid of raising issues.

The Project Manager should ensure that each team is holding daily meetings. Experience shows that as soon as the
meetings lapse, problems arise because the team is not sharing issues and responsibilities successfully, even though
they sit next to each other.

Team-building events are very useful, even if the development part of the team has worked together on projects
before, the Ambassador User(s) are a new element and need to be integrated quickly to get the most effective work
from the team as a whole.

Setting team objectives

DSDM teams consist of both developers and users working together. DSDM advocates setting clear objectives for the
team and empowering the team to achieve these objectives in its own way, rather than trying to plan every task in
detail in advance. The task-driven approach does not work in a DSDM project, since planning and controlling
sequential tasks are not appropriate in an environment that emphasises change and the inevitability of iteration.

For the DSDM approach to be successful the objectives must be measurable in some way and teams must be kept
small, with the users and developers working together towards the objectives. How a team organises itself to meet an
objective is not important. The only criterion of success is "Have the business objectives been met?" (See the Risk
Management and Testing sections). Having a task (such as writing a program) completed on time is worth nothing if it
does not meet the business requirements.

http://www.dsdm.org/version4/2/public/Project_Management.asp (3 of 6) [11-1-2008 16:02:02]


DSDM Public Version 4.2 - Project Management

Management of user involvement with the development teams (for


example, ensuring availability)

Working together effectively

Many of the problems that beset computer system development can be put down to poor communication between the
end-users and the developers. In many organisations the processes used to develop computer systems have been
developed to reduce the risk of either side being held responsible for the problems caused by poor communications.

In DSDM's collaborative approach, there is a great deal of interaction between users and implementers in task
completion. There are established and integral feedback mechanisms. These mechanisms respond quickly to changes
in the environment that affect the nature and purpose of the development tasks being performed. One main advantage
is that the need for formal documentation of every issue is reduced. This brings with it a further advantage: less need to
place detailed documentation under change control. Additionally, the striving by individuals for a perfection that may be
unattainable is kept in check by the team culture.

It is crucial that communication is clear and concise if rapid development is to be achieved. Unfortunately many
developers and users are not specifically trained in communication skills. It is assumed that it is something everyone
can do naturally. This is a mistake. Dynamic system development staff must be excellent communicators. Back-room
"techies", who are unable or unwilling to explain technical issues in such a way that the users can understand them,
cannot be user-facing DSDM developers. (Access to technical experts is important but they may not be full members of
the development team.) Equally, users must be able to articulate their needs in a way that is meaningful to someone
who is outside their field.

DSDM projects should have an informal but planned communication process, such as the regular achievement
meetings mentioned above. A small team housed in the same location (ideally beside the rest of the users) can avoid
the communication problems experienced by large teams. Also, physically dispersed teams simply cannot hope to form
the team mentality envisaged by this approach. Therefore the ideal DSDM project locates team members in the user
environment and ensures that teams are kept small. Wherever possible, projects should be broken down into small,
self-sufficient teams.

There must also be the facility to occasionally remove the development team from its normal working environment to
ensure success, such as for facilitated workshops.

Getting agreement on priorities and detailed content of timeboxes

As each timebox is completed, it is the responsibility of the Project Manager to ensure that there is a clear
understanding about what is to be delivered in the following timeboxes and to ensure that the relevant requirements
are established in detail. It is extremely likely that the users will change their minds about priorities and requirements.
The Project Manger must be open to making such changes whilst ensuring that any consequences are fully understood
by the users.

Managing customer relationships

In DSDM, users will normally be fully integrated members of the project team or at least there will be an intimate
working relationship. This close and collaborative relationship will usually be an asset in speeding up development and
building commitment to the successful use of the system.

Just occasionally the inclusion of users in a development team can cause stresses for the Project Manager if the roles
and relationships haven't been clearly established at the outset. It is also important to deal with administrative
differences which each group represented in the project team bring to the project. For example, recording and costing
user time can become an issue if the users do not normally do it and the IT department does.

Specific team-building activities should be incorporated early in the project to ensure that any "them and us" attitude is
quickly broken down.

Involving the business

If the users inside the team have their decisions overruled by someone else in the user organisation, either that outside

http://www.dsdm.org/version4/2/public/Project_Management.asp (4 of 6) [11-1-2008 16:02:02]


DSDM Public Version 4.2 - Project Management

person (or their delegate) should be recruited into the project team and/or a clear directive should be obtained from the
senior user management about decision-making.

If the users have difficulty in agreeing or reaching consensus quickly or if some Ambassador Users are not actively
participating, there are probably too many people involved. Therefore the number of user participants should be
reduced while ensuring that sufficient knowledge of the business process is retained within the project team.

During development the system may seem to be converging towards something which does not meet the business
needs or is over- or under-specified, in which case the Visionary should be called in to verify that the direction is still
valid.

Identifying and calling in Specialist Roles as required

The core development teams may well not have all the skills needed to complete the project successfully. A list of
possible Specialist Roles is provided as a checklist to ensure that they are called in at the best time for the project.

Handling problems escalated from the project teams

Note: Guidance on various levels of escalation is provided.

Ensuring that lessons are learnt and plans updated

A Project Manager new to DSDM should also ensure that he or she understands the importance of user feedback
concerning deliverables and the consequential adjustment of the project plans. At the end of each timebox there will be
a formally agreed meeting or presentation of the deliverables to interested parties demonstrating the quality of the
deliverables. These meetings also collect feedback, confirm user expectations and agree objectives for the next
iteration. This activity is crucial to ensuring that the final deliverables are truly fit for the business purpose.

Guidance for some specific situations

Experienced project managers new to DSDM

A newly appointed manager without DSDM experience should only consider adopting the DSDM approach if there is a
highly supportive environment with a wealth of DSDM experience to tap into. If this isn't present in the organisation
then experienced DSDM support from outside should be brought in.

Experienced DSDM practitioners new to project management

A newly appointed project manager with a lot of DSDM experience as a programmer or analyst should focus on
developing the more general skills of a manager rather than the aspects specific to DSDM. These will typically include
people management and the skills of handling the politics of the organisation. It could be useful to adopt a more
experienced manager as a role model or coach and to develop a supportive relationship with that individual.

Project managers from the user community

The bulk of this section has been written for the IT project manager experienced in traditional methods. A project
manager appointed from the user community who is about to manage his or her first DSDM project should focus on
ensuring that IT staff with the right experience are recruited into the project. Such staff must have DSDM experience
and they should have highly productive IT tools with which to work.

Managing mixed DSDM and traditional projects

It may be that the DSDM project is a part of a larger project being managed by other, more traditional, methods. This
can pose special risks because the DSDM project might be dependent on a delivery from another part of the overall
project.

http://www.dsdm.org/version4/2/public/Project_Management.asp (5 of 6) [11-1-2008 16:02:02]


DSDM Public Version 4.2 - Project Management

This might be late or it might not meet the real needs. It is important to have contingency plans to cope with the
problems that might be posed by the rest of the project. It is also important to have open, frank and trusting
communications. The other project may well be suspicious about any dependence that they have on the DSDM project
deliverables. They may be worried about quality for example. It is the role of the project manager to allay any such
fears.

If the projects are large, then it might be possible to second staff from the DSDM project after the development of an
increment to the rest of the project and vice versa. However, the need to keep the DSDM team stable and as free from
other responsibilities as possible should always be borne in mind. The cross-fertilisation will help improve
communications and build understanding of each other's methods. For smaller projects, the same can be
accomplished by installing good communications links or collocating the teams.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Project_Management.asp (6 of 6) [11-1-2008 16:02:02]


DSDM Public Version 4.2 - Escalation

Introduction When Lifecycle People Products Management Development Tailoring Other

Escalation in DSDM projects

Introduction

Escalation can occur in every project when situations develop that make reaching the projected results difficult or
impossible. This can occur at different hierarchical levels within the project. The necessary decision-makers then jointly
determine whether or not to change the parameters of the project (usually time, scope or budget) in order to create a
feasible (sub)project while maintaining coherence.

This section describes how escalation can be handled in a DSDM project. There is a difference between standard
status reports and escalation. Escalation occurs when on a situation arises which the current level cannot handle within
their terms of reference, especially the level of empowerment. As long as it is possible to reach the projected results
within the agreed limitations, escalation does not occur and the usual reporting guidelines apply (as described in the
Outline Plan and Development Plan).

Decision levels

In DSDM projects, usually there are three decision levels, as shown in the project organisation diagram. These will be
referred to as team level, project level and steering level. When a DSDM project is part of a multi-project or a
programme, more levels may occur.

Typical decision topics at the three levels are:

Decision Topic
Level

Steering Project Scope (goals and high level results), time, budget, high-level resources,
other management constraints

Defined in the Outline Plan, Feasibility Report and also in strategy plans or portfolio
plans
Project Approach, phasing, increments strategy, Functional and non functional requirements on a high
level, intermediate results, resources, technical architecture, technical guidelines

Defined in the Development Plan, Business Area Definition and System Architecture Definition
Team Daily and weekly planning, decisions on who does what, low-level functional and
non-functional requirements, the approach to delivering results

Defined in prototypes, models, Timebox Plans

http://www.dsdm.org/version4/2/public/Escalation.asp (1 of 3) [11-1-2008 16:04:05]


DSDM Public Version 4.2 - Escalation

Escalation at the team level

Escalation occurs at the team level for every foreseen or unforeseen situation that endangers reaching the goals for
the team's objectives within the current timebox or increment and where the team does not have the ability to solve
this. Problems that can be escalated from team level include:

● Not enough time or resources to complete the work, i.e. too many Must Haves in the timebox with no
possibilities to de-scope the work
● The team does not function because of their:
❍ Ability: they do not have the required knowledge or skills

❍ Actual empowerment: empowerment does not work in practice, i.e. too many decisions are withdrawn

or decisions take too much time


❍ Team Structure: the promised personnel are not delivered (both business and development)

❍ Team Dynamics: the team does not gel

■ There are too many external interventions

■ The chosen approach does not work

❍ Technical basis: the technical architecture is lacking

❍ Process: DSDM is not the right approach; the chosen prototyping or increments strategy is flawed

❍ Communication: communication with other teams or with the project level is disturbed

● Projected results are not delivered


❍ The quality of prototypes is too low

❍ The expected quantity of work is higher than expected, or productivity is lower

❍ Scope creep

❍ Projected results do not match the objectives set as new insights occur

In general: every foreseen or unforeseen situation that endangers reaching the goals for the current timebox or
increment and where the team does not have the ability to solve this.

Escalation at the Project Level

Escalation is caused by every foreseen or unforeseen situation that endangers the project reaching the projected
results within the set tolerances and which mean that the entire project plan needs to be changed to an extent that is
outside the powers of this level. Problems that can be escalated from project level include:

● Project results are not reached within time scales


● Empowerment is not functioning
● External issues
❍ Other projects

❍ Changing priorities in the business

❍ Dependencies on other parties not actively involved in the project

● Agreements are not adhered to


● Projected results do not match with the set goals for the project
● The available technical options are insufficient to reach results within the set boundaries
● The approach to increments does not work
● High-level scope creep: functionality that was not previously identified proves to be crucial to the increment.

How to handle escalation

What should happen when an escalation occurs in DSDM projects? Speed of decision making, empowerment and
cooperative and collaborative approach are key in what happens next.

1. The person or group who wants to escalate has to decide whether there is something they can do within their
own terms of reference to secure the situation (i.e. it is not worth escalating).
2. If the issue has to be escalated, a short note should be written to describe the situation, possible hazards,
possible solutions outside the current mandate and recommendations. This should be done on 1 page. The
reason for writing the note is to rethink the situation once more and get to the core of the problem.
3. The situation is immediately (parallel to step 2) mentioned informally to the next level, so that they can prepare
for the decision to be taken.
4. Within 48 hours (or within the previously agreed timescale for resolving escalated issues), the next level jointly
decides upon what action is required. It is essential that all parties to the decision are sufficiently empowered
to make the decision work. The decision could be either to escalate up the management hierarchy, or to solve

http://www.dsdm.org/version4/2/public/Escalation.asp (2 of 3) [11-1-2008 16:04:05]


DSDM Public Version 4.2 - Escalation

the problem: waiting is not an option. The decision reached has to be carefully documented, together with the
main reasons why the decision was reached and which actions should be taken by whom in order to
implement the decision.

While the problem is being escalated, the team(s) involved should concentrate on consolidating results or on activities
that are not influenced by the decision at hand. In this way, no time is wasted.

The Steering Level

The steering level is the top of the escalation ladder. The possible decisions now are: how to solve the problem,
redefine the project or stop it (waiting is not an option). If an escalation reaches steering level, any decision reached
should be carefully documented and all involved should be informed in the right way.

Quality of the escalation process

The following factors are important in ensuring a good quality escalation process:

● the speed of decision-making, the project is working at a high speed and should not lose momentum
● open communication to all involved about decisions taken
● working on the basis of insight into the possible consequences (without taking too much time gaining such
insight)
● consent about the decisions on all levels
● acceptance of the situation, respect for the problem owner and messenger
● collaboration and cooperation
● maintaining empowerment

Politics

One thing often forgotten when thinking analytically about escalation is that escalation may also be about politics.
When the issue is lack of cooperation and collaboration, the Project Manager has to be very sensitive in the approach
so as not to create a bigger problem than the one that already exists. This must be done without threatening the speed
of the project.

Word of warning

People tend to hesitate about escalating problems until it is (almost) too late.

In DSDM projects, with an open, no-blame culture, situations that occur and might become problematic should be
discussed and communicated as soon as they occur. This culture should be encouraged at all levels: people in general
do not like to be the bearer of bad news. When trust is demonstrable, a good, collaborative relationship between the
Executive Sponsor, Project Manager and teams is possible that will lead to a better project result.

Sometimes issues such as shame, looking for alibis, loss of power or position, innuendo, etc., prevent a certain level
from taking the correct action fast enough. People become protective of the level that they are working at. There are no
standard answers to this situation, a Project Manager (if not the one causing the delay) should have enough political
awareness to spot it and always have some plan up his or her sleeve when this situation occurs.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Escalation.asp (3 of 3) [11-1-2008 16:04:05]


DSDM Public Version 4.2 - XP And XP and Project Management

Introduction When Lifecycle People Products Management Development Tailoring Other

XP and Project Management

XP and Project Management

The following XP practices and techniques can be used in conjunction with DSDM:

Technique Description
XP delivers end-to-end business value as quickly as possible. The
planning game is a practice that puts the business people and
developers together to decide what features of the system need to
be implemented and in what order for the next release of the
system. In essence programmers estimate the features and the
customer selects features into releases.

System features are briefly described on cards in business


terminology. Each of these is called a User Story. The developers
Planning Game estimate how long each user story will take to implement. They also
decide how much effort can be put in during a certain period of
time. The business prioritises each story in implementation order.
User stories are then combined to form an iteration, with several
iterations forming a release.

This joint approach of a combined team of developers and business


users is typical of the workshop approach employed throughout the
DSDM lifecycle. The Planning Game is an example of how a
planning workshop would operate in a DSDM project.
The customer understands his or her business better then
anyone else on the team. Having an actual system user
on site throughout development ensures that questions
will be answered quickly and correctly - programmers will
never develop based on assumptions. The customer is of
course maintaining their regular workload, but is on hand
Onsite Customer for questions. There is often reluctance by the business to
give up a resource to dedicate to the system. This begs
the question whether the system is important enough to
the business. Having an on-site customer means better
software delivered quicker. Easy access to the business
users has always been important in DSDM with the users
and developers co-located being the best option.
XP suggests working a regular and reasonable week. DSDM also
suggests there is no overtime. XP gives good reasons for this in
Sustainable Pace
that it hopes for a sustainable level of work. If there were too much
(40 hour week)
to do in one iteration, less would be planned for in the next. Use the
XP advice directly. It is more specific than DSDM’s.
These are the same as DSDM's daily wash-up meetings.
Stand up meetings You may find that standing up throughout helps keep
them short and to the point!

http://www.dsdm.org/version4/2/public/XP_And_PM.asp (1 of 2) [11-1-2008 16:06:08]


DSDM Public Version 4.2 - XP And XP and Project Management

XP uses YAGNI (You Aren’t Going To Need It) to stop developers


over engineering solutions and making design decisions on behalf
of the customers, i.e. making business value decisions. This is
often referred to as "gold plating". YAGNI is often used in
conjunction with Do The Simplest Thing That Could Possibly Work.
In using DSDM and XP together we should really use WAGNI (We
YAGNI
Aren’t Going To Need It) as DSDM and XP emphasise the idea of a
single team made up of both users and developers, the “We” of
WAGNI. This provides collective ownership of prioritisation
decisions. Priorities are recorded using the MoSCoW rules and
these offer a range of priorities with meanings to help the business
decide on the relative importance of requirements.
XP states that actuals should be compared to estimates
and used as the basis for estimating the next XP Iteration.
Project Velocity Although the term 'Project Velocity' is new to DSDM this
approach is familiar and is described in the estimating
section of the manual.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/XP_And_PM.asp (2 of 2) [11-1-2008 16:06:08]


DSDM Public Version 4.2 - Project Planning

Introduction When Lifecycle People Products Management Development Tailoring Other

Project planning

Introduction

The purpose of planning in DSDM, as in traditional approaches, is to ensure the success of the project. However, in
DSDM, planning is not just an activity that takes place at the beginning of the project: it continues throughout the
lifecycle.

The DSDM approach to planning described here includes a consideration of the differences from more traditional
approaches. It covers the steps in the planning process and the planning products within DSDM. In addition, it includes
some "hints and tips" for planning for success and for avoiding pitfalls in planning.

The DSDM approach to planning

Project Plans

Rather than having detailed plans for the whole project at the start, DSDM project plans evolve with more and more
detail as the project progresses, as requirements are progressively refined and as lessons are learnt. However, it will
be an unusual organisation that does not have standards or requirements for the production of overall project plans.

In some organisations (particularly those which develop similar computer systems on similar platforms for similar
customers), it might be possible to define a plan that applies to all projects. At the other extreme, each project is
sufficiently different from all others to require that a specific project plan be written for each project with little
commonality from one project to the next. In most cases, an intermediate situation exists, whereby substantial parts of
the quality-related aspects of the plan can be completed by reference to existing documentation. This particularly
applies to the procedures and standards to be used.

The plan should address all products generated by, and activities undertaken in, the project. This will include the
deliverable products (prototypes, models, documentation, etc.), but it should also address, either within the document
or by reference to other documents:

● project initiation
● configuration management
● change control
● product breakdown structure
● product descriptions
● risk management
● work instructions.

The rigour and formality applied to the production of the plans will vary for each situation. In some cases, a meeting
minute or brief note may suffice, whereas in contractual situations, the customer may want to approve a separate
quality plan at the start of the project.

It is important that the effort applied to planning should be appropriate and in proportion to the size of the project. It
should also be noted that there is no fundamental reason why the complete project plan has to be written at the start of
the project. On the contrary, the DSDM approach (as noted above) is that the plan evolves throughout the project.
What is important is that the required parts of it are ready when needed. This must not be taken to imply that quality
can be considered a moving target, which can change as the project progresses.

The change in focus from traditional planning

Planning a DSDM project can be especially taxing for a project manager steeped in traditional methods.

A traditional project manager will normally focus on agreeing a detailed "contract" with customers about the totality of

http://www.dsdm.org/version4/2/public/Project_Planning.asp (1 of 5) [11-1-2008 16:02:17]


DSDM Public Version 4.2 - Project Planning

the system to be delivered along with the costs and timescales. In a DSDM project, the Project Manager is focused on
setting up a collaborative relationship with the customers, bringing them fully into the make-up of the team.

In the traditional project, the manager is concerned with understanding the requirements in complete detail so that the
right level of resources can be secured and an estimate of the completion time can be made. In the DSDM project, the
manager is concerned with agreeing with the users the process by which the business requirements will be met.

Also in a traditional project, the plan is created in a great detail and is ideally executed with minimal change. In a
DSDM project, the initial plans are created in sufficient detail to establish the main parameters of the project and with
the firm expectation that the customers will change the plan during the course of the project as they gain a deeper
understanding of their needs.

Transition from traditional planning

An experienced IT project manager lacking in personal DSDM experience would be wise to ensure that the team either
contains members with DSDM experience or has free and easy access to such experience. Also the acceptability and
experience of DSDM within the organisation is an important factor. If DSDM is well known and understood then the
risks will be low. If, on the other hand, the organisation relies exclusively on traditional methods and has a conservative
approach to new methods then the risks will be correspondingly higher. In this case, the section on introducing DSDM
into the organisation provides important advice.

The DSDM Project Manager has part of the traditional planning role reversed. Timebox Plans and the day-to-day
planning of activities is the responsibility of the Team Leader(s). Hence, the Project Manager accepts Timebox Plans
rather than produces them.

The Planning Process

Plans

The Project Manager ensures the delivery of the following plans during a DSDM project. Note: Each plan is developed
by the roles defined in the relevant DSDM Product Description - rather than being the sole responsibility of the Project
Manager as in traditional projects.

● Outline Plan in the Feasibility Study

The outline plan can be viewed as a mechanism to define and agree the terms and conditions for a successful
project. It also acts as a detailed plan for the Business Study.

● Development Plan in the Business Study

The Development Plan serves to agree how the project will be carried out, in particular which prototypes will
be built and when.

● Timebox Plan at the start of each timebox

The Timebox Plan refines the Development Plan. Each Timebox Plan contains at least one complete cycle of
the Functional Model Iteration or Design and Build Iteration for part of the system.

● Implementation Plan in Functional Model Iteration

The Implementation Plan sets the scene for successful implementation of the system.

Planning Steps

The steps in planning a DSDM project can be considered under the following headings:

● Pre-project planning
● Planning at project start
● Planning during the project
● Planning at increment end

http://www.dsdm.org/version4/2/public/Project_Planning.asp (2 of 5) [11-1-2008 16:02:17]


DSDM Public Version 4.2 - Project Planning

Pre-project Planning

Pre-project planning takes place before the project proper starts in the Pre-Project phase. The aim of pre-project
planning is to provide the basis for carrying out the project successfully. At this stage, the project manager needs to:

● Understand the requirements just sufficiently to assess the risks and suitability of the project for a DSDM
approach. See When to Use DSDM and the Suitability/Risk List in particular.

● Establish the right conditions for the project with the user management.

Ideally, the team will comprise experienced IT developers and users, will be collocated at the users' site and
will be empowered to make a wide range of decisions concerning the development of the system. All of these
aspects need to be negotiated at the outset of the project. The roles of the project team and other stakeholders
need to be established. The People section provides essential reference material for setting up the creating
the best project organisation and culture for a DSDM project.

● Ensure that the managers from the business have agreed to release their staff into the development team for
significant periods of time (including full-time secondment when the project requires it).

The business management need to release staff who have the authority, desire, responsibility and knowledge
to make decisions on behalf of the rest of their community. The Project Manager therefore needs to develop a
good relationship with the Executive Sponsor and other senior management in the business, support, and
development organisations to gain their commitment to making this happen.

● Agree a definition of "fitness for business purpose" for the system being developed with the business

When starting to plan, it is especially important for the Project Manager to establish with the business (e.g. the
Visionary) what will constitute a system fit for business purpose. One criticism that is often laid at the door of
DSDM is that the term "fit for business purpose" is taken by Project Managers as an excuse for producing
systems quickly that contain bugs or are difficult to maintain or incomplete. However, such claims are untrue of
well-managed DSDM projects.

If the business needs a complete system before any part can be used, then the DSDM process will be
managed accordingly. If the business requires a system without any errors in it, then the DSDM process will
produce such a system. If the business requires a system that is low on maintenance and further development
then DSDM is ideally suited! The meaning of fit for business purpose will form an important part of the quality
aspects of the plans produced by the Project Manager.

A sound understanding of what the users regard as fit for purpose is needed to decide how to undertake
correctly the key activities involved in planning. These include:
❍ establishing those requirements that need to be tackled first

❍ developing a sound prototyping plan

❍ setting and agreeing timebox schedules and initial content.

● The successful completion of these activities will depend both on a good grasp of the DSDM development
process framework and on the tool support, management techniques and development techniques appropriate
to DSDM.

It may be that the Project Manager is appointed after pre-project planning has been undertaken. Also, it is not always
possible to set up the environment fully. In these situations the Project Manager will need to make a careful risk
assessment and put in place appropriate actions to mitigate the risks.

Planning at Project Start

http://www.dsdm.org/version4/2/public/Project_Planning.asp (3 of 5) [11-1-2008 16:02:17]


DSDM Public Version 4.2 - Project Planning

Planning at project start takes place during the Feasibility Study. Its aim is to provide the basis for successful exit from
the project when it has been completed. At project start, the Project Manager needs to develop an Outline Plan. This
includes establishing milestones (similar to a traditional phase plan), developing acceptance criteria (similar to a
traditional quality plan), and defining project metrics (along with an approach for capturing them).

Planning during the Project

Planning during the project takes place throughout the remaining phases of the DSDM lifecycle. Its aim is to provide
the basis for smooth progress throughout the project. Critical success factors for this planning include:

● Gaining an understanding of business needs early


● Setting up environments early. Independent environments for development, testing, training, and production
may be required
● Identifying and removing barriers early by using meetings and other communication channels

The following plan products evolve during the project:

● Development Plan
● Timebox Plans
● Implementation Plan

Planning at Increment End

Planning at increment end may seem like a contradiction in terms. However, when one considers that it provides the
basis for successful future increments by capturing lessons learned from the current one, its significance becomes
clear. As the increment comes to an end, the project manager needs to:

● Gather metrics
● Gather lessons learned
● Identify ways of improving the process

The Increment Review Document is the vehicle for recording this information for posterity. It also provides the basis for
planning the next increment starting again with the Development Plan and moving on from there.

Planning for Success in DSDM Projects

The following "hints and tips" based on the practical experience of DSDM project managers may be of assistance in
planning:

● The contents of timeboxes are crucial. Follow the Timeboxing approach when planning them.

● Plan deliverables, not activities. Consider the key questions "who, when what, where, how" when planning.

● Define quality criteria for each deliverable. See the DSDM product descriptions for examples of quality criteria.

● Plan for frequent delivery of products. Distinguish "delivery to the project" from "delivery to the end user
population".

● The focus of planning and control in DSDM is on sustaining a high rate of progress, agreeing priorities,
keeping relationships healthy, learning as the project progresses, and allowing plans to evolve based on
experience gained.

● Make project planning work for you by focusing on principles, products, and people rather than methods and
techniques.

● Manage expectations by planning appropriate briefings and training on DSDM, addressing roles and
responsibilities, and defining and agreeing products and acceptance criteria.

● Whenever possible, plan to shadow key roles, such as Project Manager, Team Leader, and Ambassador User.

● Plan for the use of method and tool mentors where there is insufficient experience in the team.

http://www.dsdm.org/version4/2/public/Project_Planning.asp (4 of 5) [11-1-2008 16:02:17]


DSDM Public Version 4.2 - Project Planning

● Plan to do the work during normal working hours. Work additional hours only to achieve "Musts" within a
timebox.

● Plan contingency only for prerequisites (software, hardware, setup, etc.) but not for time or resource on the
project itself. Contingency in DSDM is managed through prioritisation of requirements.

● Plan for regular daily team meetings.

● Plan formal reviews at the end of each timebox and establish dates in diaries early.

● Plan early for testing interfaces, theoretical performance analysis, and performance prototyping.

Avoiding Project Planning Pitfalls

As with any method, there are a number of potential pitfalls to avoid when planning DSDM projects. These include:

Objectives and requirements that are either too vague or too detailed

Requirements need to be baselined at a high level and focus on what is to be done rather than how. If they are too
vague, the baseline scope will not be sufficiently clear. If, on the other hand, they are too detailed, there will be
insufficient flexibility to allow for prioritisation and varying what is delivered in each timebox.

Failure to architect the approach

DSDM is a model-driven process. Two key products of the Business Study are the Business Area Definition and the
System Architecture Definition. These form the basis for the models that will drive future development. Their
importance must not be underestimated.

Frequent changes to the schedule for user involvement

Schedules for key deliveries and workshops need to be agreed and kept stable for each timebox to maintain user
commitment. If users are continually being asked to change agreed dates in their diaries, they will soon lose the sense
of urgency for the project.

Incomplete and conflicting information

This can be avoided by using effective workshops, run by trained facilitators. In order to be seen to be impartial, the
facilitator should be from a different business area from the project in question. Workshops need careful preparation,
including defining and agreeing specific goals and deliverables and selecting the appropriate participants.

Introducing too much change at one time

A method such as DSDM requires carefully planned introduction because it involves changes in the organisation's
project culture. If these cultural changes are combined with the introduction of new technologies and new tools on a
project that is highly critical for the business and severely time constrained, the pressures may become too great to
manage. An experienced DSDM consultant can reduce the risks by assisting in the introduction of DSDM, mentoring
teams, and reviewing progress during early projects.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Project_Planning.asp (5 of 5) [11-1-2008 16:02:17]


DSDM Public Version 4.2 - XP and Planning

Introduction When Lifecycle People Products Management Development Tailoring Other

XP and Planning

Basic XP concept

In XP, the planning hierarchy consists of two levels: releases and iterations (in DSDM terminology, these are
increments and timeboxes). Typically, releases are of the order of 2/3 months but this is decided by the customer who
chooses a minimum collection of user stories that warrants release, i.e. the minimum that delivers business value to
the users. The emphasis here is on minimum. XP is an approach that needs and thrives on feedback. It considers that
the most valuable feedback possible is gained from putting the system in a production environment.

A release is made of a number of fixed length iterations that are normally 1 to 3 weeks in length. The team delivers
working software at the end of each iteration with a release being available at the end of the final iteration. It is
important to emphasise that all iterations are the same length and that iteration deadlines should never be slipped. If
necessary, scope should be reduced to ensure the iteration deadline is met. This is important for a number of reasons
most important of which is to gain to establish trust with the customer by delivering working software on time. These
regular iterations are the described as the “heartbeat” of an XP project.

XP captures requirements in the form of user stories. The scheduling of the user stories into iterations and releases is
done using the XP practice of the "The Planning Game".

The planning game is a joint practice between users and customers to schedule releases and iterations. Programmers
estimate user stories through discussion with the customer and other team members; the customer prioritises the user
stories to be delivered within each iteration and the overall release and a schedule is planned. It is important to note
that XP expects there to be a consistent stack of user stories that are ordered in strict relative priority, i.e. we ensure
that we are working in the most important story possible at any given time. Units for estimation vary from team to team.
One common practice is the use of “ideal engineering days”, i.e. the number of days it will take to code the story
without interruption, other assignment, including testing and refactoring.

The first part of the Planning Game is the Release Planning. Here the Customer chooses stories to deliver in the
overall release based upon the relative priority of these stories and their estimates. The capacity of the team is defined
by their velocity. Velocity is essentially the number of units the team delivers per iteration. For example if we have a
velocity of 20 and there are 4 iterations in the release then there is an overall capacity of 80. The release plan is seen
as a soft commitment to what will be delivered in the releases i.e. it is expected to change as more feedback is
generated. The important point is that there should be a high degree of confidence in the release plan and the stories
scheduled should constitute a meaningful release. Where the project is a greenfield development and there is no
previous experience to draw on XP recommends some level of exploration iteration before making the release
commitment. This is used to remove uncertainty by exploring risk areas through the use of spikes. The length of this
exploration varies from project to project and a consideration is the degree of risk that is present and can be taken on.

The next level of planning is iteration planning. This is done at the beginning of every iteration. It is where the detailed
planning is done for the iteration ahead. It is usual at this point for the stories to be changed/merged/dropped and
estimates updated. This can be due to any number of reasons ranging from more information, feedback from previous
iterations, market feedback etc. The user stories are re-estimated and planned according to the recorded velocity of the
previous iteration. Where appropriate, user stories can be broken down into task cards if they are found to be too big to
estimate accurately. It is also recommended that acceptance tests for the stories scheduled in at this stage be
delivered as early as possible. Additionally, this meeting also gives an opportunity to do a mini retrospective on the
project as a whole.

http://www.dsdm.org/version4/2/public/XP_And_Planning.asp (1 of 2) [11-1-2008 16:06:21]


DSDM Public Version 4.2 - XP and Planning

Assessment of XP

An XP Release is equivalent to a DSDM Increment, while an XP iteration is equivalent to a DSDM timebox. As a result,
it is likely that the term iteration will be a source of confusion for the DSDM and XP communities. An XP iteration fulfils
the need to deliver products frequently but, at one to three weeks, may not be long enough to deliver the system
components envisaged by DSDM’s two to six week timeboxes.

A description of how XP plans (the Planning Game) releases and iterations is given at a lower level of detail than
DSDM offers, but generally follows the process that a DSDM Development or Timebox planning workshop takes.

One area in which XP and DSDM differ is in the variability of length of an [XP] iteration / [DSDM] timebox. Whilst
DSDM suggests that the length of a timebox can vary according to its contents (requirements), XP advocates a
constant iteration length regardless of User Stories. In fact XP is looking for a heartbeat effect for projects so that there
is a regular pattern to the development of the project. The constant iteration length is chosen by the team to suit the
project. In practice the vast majority of teams pick two weeks. As in DSDM, requirements (user stories) may have to be
broken down in order to fit into an iteration.

Guidance for those looking to use XP with DSDM

Issue Guidance
Terminology When using XP in conjunction with DSDM use the DSDM terminology to avoid
confusion. This will give a wider vocabulary to help communication, e.g. to
allow iterations of a single prototype within a Timebox.
Length of timeboxes DSDM gives greater freedom by allowing longer timeboxes. In
practice one week timeboxes have been known so long as it is long
enough to produce a deliverable. Some practitioners have already
seen value in making DSDM timeboxes a regular length, especially
where software release cycles need to map on to periodic business
processes.
The Planning Game The basic process may be used as the basis for the planning workshops:

● Identify requirements and prioritise (producing the BAD and PRL)


● Estimate requirements
● Group into timeboxes
● Allocate requirements/stories to timeboxes
● Negotiate on the allocation, reviewing priority, resource levels and
lengths of timebox.

Note: While planning is best done in one session, the requirements may well
have been identified and prioritised earlier. A Facilitator should be used to run
the workshop. Index cards or post-its are useful tools for the workshop
because they may be moved around. Whether the result needs to be formally
written up will depend on the quality procedures surrounding a given project.
The result however, should conform to the Quality Criteria given in DSDM.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/XP_And_Planning.asp (2 of 2) [11-1-2008 16:06:21]


DSDM Public Version 4.2 - Quality Management

Introduction When Lifecycle People Products Management Development Tailoring Other

Quality Management

DSDM's quality philosophy

From the point of view of a user, the "quality" of the computer system will often be defined in terms of the way in which
that system provides the capability and support required by the user. This can be termed the "fitness for purpose" of
the system. Given that one of the DSDM principles is that fitness for business purpose is the essential criterion for
acceptance of deliverables, it should be expected that DSDM will serve to provide high quality computer systems. In
other words, quality will be built in to the system, facilitated by the DSDM process.

Many techniques recommended by DSDM are used to ensure the quality of the project's products:

● facilitated workshops ensure that the system's requirements are properly considered at the outset
● continuous and focused user involvement helps to ensure that all parties understand each others - needs and
viewpoints
● reviews (whether of prototypes or of supporting documentation) serve to ensure (and record) that the system
continues to meet the needs of the business - the quality criteria against which products should be reviewed
are identified the Product Descriptions
● thorough testing validates the delivered system against its requirements
● Configuration Management and Change Control serve to ensure that quality, once built in to the system, is
preserved.

In some environments, quality-related activities are seen as onerous because they are perceived as adding
bureaucracy and overheads. Clearly this must be avoided, particularly on a DSDM project, where it is crucial that all
activities add benefit to the end results. DSDM does generate far fewer products than traditional methods - for
example, intermediate design products may not be required - and that fact alone could reduce the amount of inspection
that is necessary.

It is particularly important that an organisation's approach to quality is flexible enough to meet the needs of a DSDM
project. If it is too rigorous, for example in defining that certain actions must be taken, or records kept, regardless of
their benefit to the project, that will clearly distract from the DSDM project's emphasis on maintaining the business
focus. Quality aspects of a DSDM project will differ from a "traditional" project because:

● where there are fewer products there are correspondingly fewer reviews, inspections, tests and other
verification activities
● the emphasis on keeping the project's focus on the business requirements means that there is constant
emphasis on validation against those requirements
● there will be fewer formal "contract" changes, because change is accommodated within the process itself
● there is much refinement of requirements, as the business needs change and the opportunities presented by
the developing system become apparent.

Quality Planning

Although proper use of DSDM will help to ensure that quality is inherent within a project's products, it is still necessary
to consider in the early stages of the project what mechanisms and techniques are to be used by which members of
the team and at what times. In other words, quality needs to be planned for.

http://www.dsdm.org/version4/2/public/Quality_Management.asp (1 of 2) [11-1-2008 16:03:36]


DSDM Public Version 4.2 - Quality Management

Thus quality planning should be an integral part of the project planning activity. Some organisations require that a
separate Quality Plan is produced, while others hold that it is better not to encourage a perception that Quality is a
separate activity, but to have the contents of a Quality Plan incorporated within an all-embracing Project Management
Plan. DSDM advocates determining who will review and accept Feasibility and Business Study products in the pre-
project planning. Detailed quality planning is then carried out during the creation of the Development Plan.

Whatever approach is taken to the presentation of the project's plans, the following quality-related aspects should be
addressed:

● identification of which products are to be produced and which of those warrant specific quality-related activities
● how the quality of each type of product is to be checked - for example by review and/or by testing
● when quality checks are to be performed; and whether they are they optional or mandatory, whether or not all
examples of a particular type of product must be checked or only a sample, and whether items are checked
during development or only on completion
● who is responsible for reviewing and testing each product, who has authority to accept the product and what is
to happen if such a review or test is unsuccessful. (DSDM's Ambassador User and Tester role have specific
responsibilities for testing software products. Also suggested roles to perform reviews and acceptance are
provided in each of the DSDM Product Descriptions.)
● which criteria are to be used to assess each product's quality - typically by reference to the quality criteria
defined in each of the DSDM Product Descriptions
● which procedures are to be used to define quality-related processes
● which records are to be kept to document decisions and actions taken - DSDM's Functional Model Review
Records and Design Prototyping Review Records provide a mechanism for such records.
● which standards are to be applied to products (for example, coding standards and user interface style guides).

Quality Audits

Many organisations require that development projects be audited from time to time in order to determine their
compliance with the organisation's procedures, practices and standards. It is critical in DSDM projects that such audits
are not allowed to result in unnecessary rework or ineffective effort expenditure (e.g. on records whose only purpose is
to satisfy an auditor).

Experience has shown that the greatest benefit obtained from audits is frequently in causing corporate procedures,
practices and standards to be revised in the light of real experience. Early experience with DSDM should be used to
refine the organisation's approach on later projects.

Extensive guidance on auditing software projects can be found elsewhere; particular questions to consider when
auditing a DSDM project include:

● is the user involvement there?


● are the users empowered?
● is the life-cycle being followed?
● are comments from prototype reviews being incorporated?
● is backtracking allowed when necessary?
● are priorities being adhered to?
● are timeboxes being respected?

A more extensive Project Health Checklist is provided.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Quality_Management.asp (2 of 2) [11-1-2008 16:03:36]


DSDM Public Version 4.2 - DSDM Project Health Checklist

Introduction When Lifecycle People Products Management Development Tailoring Other

Page 1

DSDM
Project
Health
Checklist

Information
Sources:
Key Area Question
Overview of
project history
and subjective
Background
assessment of
issues by project
manager
Roles Are all DSDM
roles allocated to
the team?
Do all team
members
understand their
roles and
responsibilities?
Do all team
members carry
out their
responsibilities?
Sponsorship What is the
status of senior
management
involvement,
commitment, and
satisfaction?
Is the project
visible through
frequent
deliverables?
User Expectations How satisfied are
users with
progress to date?
How well are
user
expectations
being managed?
User Involvement How is user
involvement
being done?
Is it working?
Do we have all
the right users?

http://www.dsdm.org/version4/2/public/HealthCheck.asp (1 of 6) [11-1-2008 16:06:36]


DSDM Public Version 4.2 - DSDM Project Health Checklist

Empowerment Are the users


empowered?
Is the team self-
directed?
How does
escalation work,
if at all?
Team Structure What is the
project team
structure?
What is the size
of the team(s)?
Do the team(s)
have the right
skills?
Is there any
outsourcing?
How is it
managed?
Is the team
collocated? Or
else how is this
managed?
Is the physical
environment
suitable?
Are team
members fully
dedicated?
Page 2

DSDM
Project
Health
Checklist

Information
Sources:
Key Area Question
Team Dynamics Are the team
goals clearly
defined and
understood?
How well does
the team work
together?
How is team
morale,
enthiusiasm,
commitment?
What is the
turnover?
Training Have all project
members
received training?

http://www.dsdm.org/version4/2/public/HealthCheck.asp (2 of 6) [11-1-2008 16:06:36]


DSDM Public Version 4.2 - DSDM Project Health Checklist

Do all project
members buy in
to the philosophy
and approach?
Is there effective
mentoring on the
project?
Workshops Are workshops
used?
How effective
are workshops?
Is facilitation truly
independent?
Prioritisation Are priorities
being adhered
to?
Are Must Have
requirements
really Must
Haves?
Do all users buy-
in to the priorities
in the plan?
How much
reprioritisation
has been done
and how?
Timeboxing Are timeboxes at
right level of
granularity?
Are timeboxes
being respected?
Do timeboxes
have a good mix
of must, should,
and could?
How much
functionality is
being passed
between
timeboxes and of
what priority?
How is the end
of timebox
process working?
Page 3

DSDM
Project
Health
Checklist

Information
Sources:
Key Area Question

http://www.dsdm.org/version4/2/public/HealthCheck.asp (3 of 6) [11-1-2008 16:06:36]


DSDM Public Version 4.2 - DSDM Project Health Checklist

Prototyping Is iterative
prototyping
taking place
effectively?
Are the
prototyping
controls being
followed?
Are the iterations
(investigate,
refine,
consolidate)
being followed?
Have the DSDM
products been
tailored?
Is product quality
satisfactory to
users?
Do the products
meet their DSDM
Products
quality criteria?
Have non-
functional
requirements
been considered?
Is appropriate
documentation
produced?
Reviews How are
prototypes
reviewed?
Are comments
from reviews
being
incorporated?
How were
reviews
documented?
How were
deliverables
accepted?
Technical Is the
development
environment
appropriate for
DSDM?
Is the
infrastructure in
place? Familiar
to the team?
Are technical
standards
defined and
followed?
Lifecycle Is the lifecycle
being followed?
Has the life-cycle
been tailored?

http://www.dsdm.org/version4/2/public/HealthCheck.asp (4 of 6) [11-1-2008 16:06:36]


DSDM Public Version 4.2 - DSDM Project Health Checklist

Is the suitability/
risk list used
effectively?
Project Management Is the project
management
style appropriate
to DSDM?
How is the
project's
governing body
working?
Page 4

DSDM
Project
Health
Checklist

Information
Sources:
Key Area Question
Planning Are DSDM
planning
deliverables
produced: is
there an outline
plan, outline
prototyping plan,
implementation
plan?
Are estimates
realistic? How
are estimates
done?
Is project
resourced as
planned?
Change Control / Configuration Is backtracking
Management done where
necessary?
Is there a
change control
process? Is it
followed?
Is the change
control process
too bureaucratic?
Are products
baselined?
Is there a
configuration
management
process? Is it
followed?

http://www.dsdm.org/version4/2/public/HealthCheck.asp (5 of 6) [11-1-2008 16:06:36]


DSDM Public Version 4.2 - DSDM Project Health Checklist

Are
reprioritisations
fed into the
change control
and configuration
management
processes?
Risks and Issues Have risks and
issues specific to
DSDM been
identified?
Are risks being
managed
proactively?
Are issues being
managed?
Testing Is there a Test
Strategy? Is it
followed?
Who is involved
in testing?
Are the testing
principles being
followed?
End of increment Have all
requirements
omitted in the
increment been
identified?
Is there sufficient
information to
decide to
proceed with
further
development?
Have all lessons
learned been
documented?

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/HealthCheck.asp (6 of 6) [11-1-2008 16:06:36]


DSDM Public Version 4.2 - Risk Management

Introduction When Lifecycle People Products Management Development Tailoring Other

Risk Management

Introduction

The purpose of risk management is to actively control all the risks facing a project or the implementation of the solution it is
delivering. This includes:

● Identification of any and all risks that may threaten the project for business, systems or technical reason.
● Assessment of the impact of those risks on the success of the project should they arise. This assessment involves
deciding on the likelihood of the risk occurring and if it does on the severity of its impact on the project.
● Management of those risks through defining specific countermeasures that are aimed at either avoiding the identified
risks or accepting them and minimising their detrimental effect on the project.
● Applying the appropriate countermeasures when a risk materialises.

This section addresses how and when risk management happens within a DSDM project. It includes possible
countermeasures to risks that arise in DSDM projects.

Additional information can be found in the White Paper on Risk Management available via the Webshop.

Risk assessment in general

Most procurers of IT systems are concerned with two risks. These are that the system will not meet the needs of the business
and that the project will overrun on time and/or cost. DSDM is designed to counteract both of these risks. Systems that meet
the needs of the business are delivered through the incremental and iterative approach with its continuous feedback from
users. Cost and time overruns are avoided by the use of timeboxes.

Some risks that arise in traditional development also arise in DSDM projects. For example, the use of leading edge
technologies can give rise to major benefits in capability and in performance. But they can also carry risks associated with
their immaturity. A DSDM approach by its nature helps mitigate the risks of using new technologies. Prototypes can be used
to test performance and stability issues. The incremental DSDM approach can test out new technologies on a limited scale
before rolling them out fully.

It is often asserted that agile development approaches carry some specific risks not present in traditional methods.
Unmaintainable code is one such claim. Another is that agile projects produce computer systems that contain all kinds of
unknown faults. Both are possible in poorly managed agile projects but DSDM builds in safeguards to ensure high quality
products.

This does not mean that managing a DSDM project is a risk-free activity. In the main the risks arise from not complying with
one or more of the underlying principles of DSDM followed by a failure to implement risk mitigation activities to allow for the
non-compliance.

Risk management principles

Certain fundamental principles apply in risk management. These are as follows.

● Risks must be identified and their impact assessed as early as possible.

● Risks should be continuously reviewed throughout the life of the project, particularly at critical go/no go decision
points within the project such as the end of the Business Study and before initiating the development of a new
increment.

● All risks should be assessed in terms of their potential impact.

● Risks must be actively managed through countermeasures to minimise their possible impact.

● The emphasis of risk management activities should be on the risks with the highest levels.

http://www.dsdm.org/version4/2/public/Risk_Management.asp (1 of 8) [11-1-2008 16:02:43]


DSDM Public Version 4.2 - Risk Management

● Projects with risks determined as unacceptable by the Executive Sponsor should not be started.

● Projects whose risks rise to an unacceptable level should be stopped.

Risk Management process

The diagram below provides an overview of the Risk Management process. The process commences with the Suitability/Risk
List as this is deemed the entry point for assessing the risk of any potential problem. Thereafter the risk management cycle
progresses through the identification and documentation of risk and the subsequent monitoring and assessment.

Risk Identification

Risk identification is an integral part of the risk assessment process for the successful initiation and completion of a DSDM
project. It is therefore essential that risk identification be undertaken at the earliest opportunity. The first formal risk
identification is analysis of the Suitability/Risk List.

The Prioritised Requirements List provides another tool for identifying the risk associated to the requirement. Risk
identification should focus on those requirements that have a high prioritisation.

http://www.dsdm.org/version4/2/public/Risk_Management.asp (2 of 8) [11-1-2008 16:02:43]


DSDM Public Version 4.2 - Risk Management

For projects considered to be 'small', it may be deemed that the Suitability/Risk List without the generation of the Risk Log
provides sufficient means for recording and monitoring the risk. In addition, if all risks have been identified as low, there may
not be a need to continue with the risk management process for the project.

As the risk identification process is integral to the successful completion of the project both the supplier and customer should
be involved in the identification process, whether the work is carried out internally to the organisation or not.

Categorisation

For the risk identification process it may be prudent to categorise the risks. The categorisation would be dependent upon the
size of the project, i.e. for small projects the categorisation may be limited to Business, Systems and Technical, whereas for
larger projects these categories may be expanded or subcategorised as in the list below, which also suggests owners for the
risk (sub)categorisation.

● Business Risk: Executive Sponsor


❍ Mission and Goals: Visionary

❍ Requirements: Ambassador User

❍ Decision Drivers: Ambassador User

❍ Organisation Management: Visionary or Ambassador User

❍ Budget/Cost: Executive Sponsor

● Systems: Ambassador User


❍ End/Key users: Ambassador/Advisor User

❍ Characteristics: Project Manager

❍ Implementation / Roll-out: Project Manager

❍ Processes: Team Leader

● Technical: Project Manager


❍ Technology: Technical Co-ordinator

❍ Operation Environment: Technical Co-ordinator

❍ Development Environment: Team Leader

❍ Design Tools: Technical Co-ordinator or Developer

❍ Personnel/experience: Project Manager

Risk Log Update

The output of risk identification, categorisation and assessment activities is a DSDM product, the Risk Log.

Resource Assignment

The prioritisation of the risk will aid in the assignment of the resource in that the high-level risk areas can be addressed early
within the project - in early timeboxes. In addition, using Risk-Based Testing means that those risks deemed as high level can
be focused on.

At all times the assignment of resource should focus on the top risks for the work that is either current or imminent.

Monitor

Within each timebox it is vital that the risk or risks associated with the timebox are monitored by the risk owner.

Alert

This process is concerned with responding to the occurrence of a risk.

Preventive countermeasures are implemented as part of the project. They are carried out as scheduled and periodically
evaluated to assess their success or the need for further actions.

Reactive countermeasures are brought into play when the risk occurs. To ensure that all actions are implemented as
planned, the risk owner monitors the status of the risk to its closure. After the reactive strategy is activated, the Project
Manager must revise the plans to reflect the actions required. This revision may well necessitate reprioritisation of other
planned work.

Assessment

http://www.dsdm.org/version4/2/public/Risk_Management.asp (3 of 8) [11-1-2008 16:02:43]


DSDM Public Version 4.2 - Risk Management

In assessing and updating the Risk Log, the following steps should be taken:

● Review the countermeasures that have been implemented to date for effectiveness and the possible need for further
action.
● Identify the top risks for the current time and check if anything has changed or if the countermeasures should be
modified.
● Develop new countermeasures or modify old ones, if the current approach is working poorly or further risk mitigation
is necessary.
● Update plans, as appropriate.
● Escalate management of any current or imminent (high-level) risk that has increased its likelihood.
● Close all risks that have not occurred and are no longer a risk to the project.
● Close all risks that have occurred and have been satisfactorily managed.

Phase by Phase Activities

Pre-Project

Use the DSDM Suitability/Risk List together with any other risk checklist in use in the organisation to ensure that all possible
risk areas are considered.

Review the identified risks together with the person expected to take the role of Visionary. The project should not seek
funding from the Executive Sponsor if the level of risk is unacceptable.

Feasibility

Open the Risk Log, incorporating any risks identified during the pre-project work.

Ensure that the risks associated with alternative solutions are clearly communicated to the Visionary and the Executive
Sponsor. This is most easily achieved by addressing the risks in a Facilitated Workshop that they attend together with other
key business and technical representatives.

Terminate the project if no solution has acceptable risks.

Dependent on the expected size of the project decide on the level of formality to be applied to risk management: the larger
the project the greater the likelihood of severe risks occurring and, hence, the greater the formality. If a project is very small,
a light but consistent hand is needed in risk management activities. In all cases, the risk management activities in the rest of
this section will need to be carried out.

Business Study

Maintain and update the Risk Log as understanding of the needs of the project is clarified during the Business Study. In
particular, as the business benefits of the project are clarified, the risk of not achieving these must be addressed.

Preventative measures should be suggested for every risk and, if appropriate, costed. These may include a complete fallback
scenario for the project which, to be valid, must include the latest time at which the fallback could be initiated.

For risks where no preventative measures are possible the less favoured approach is to identify the effects of adding extra
resource and/or timeboxes in the event of the risk materialising.

For large projects, risk management activities should be clearly identified in plans.

This phase includes a major go/no go review of the project in which risk assessment will be considered.

Functional Model Iteration

Risk assessment and implementation of preventative and contingency measures continue. Risks are managed at both the
project and timebox level.

http://www.dsdm.org/version4/2/public/Risk_Management.asp (4 of 8) [11-1-2008 16:02:43]


DSDM Public Version 4.2 - Risk Management

Particular care should be taken when producing the Implementation Plan to ensure that any risks likely to arise during
implementation are assessed and countermeasures proposed. The ownership of those risks should be clear in the plan.

Design and Build Iteration

Risk assessment and implementation of preventative and contingency measures continue. Risks are managed at both the
project and timebox level.

This is the stage at which most risks for the current increment must be closed off. Certainly all relevant technical risks should
be closed and as few as possible business risks should remain.

Implementation

Risk assessment and implementation of preventative and contingency measures continue.

While producing the Increment Review Document, ensure that all risks are considered as to whether or not they are relevant
to the next increment. If not, close them. Additionally, on the basis of the aims and activities of the next increment, identify
new risks and define appropriate countermeasures. This together with the Prioritised Requirements List for the next
increment should be used to assist in the go/no go decision for future development work.

Post-Project

Use the outcome of the project to make recommendations about any necessary enhancements to existing risk checklists.

Risk countermeasure suggestions

Risks related to not satisfying DSDM's principles

The necessary level of user involvement is not present

Full compliance with DSDM requires an integrated team of developers and business staff collocated where the system will be
used. Anything less than this constitutes a risk to successful implementation. There are several approaches to avoiding or
minimising this risk.

One key factor in getting the right level of user involvement is in identifying not only the classes of users to be involved but
also in identifying an appropriate level of involvement based on the size of the user population. It can be easy to get users
into the project full-time when the eventual users are numbered in hundreds, but this gives rise to the problem of choosing a
representative set and selling the results to the rest of the user population. An approach to solving this problem must be
defined very early on in the project - perhaps even before the project starts.

If the system is intended for a very small business population, everyone can be involved but the percentage of their time that
can be made available to the project is obviously limited. For the Ambassador Users, it is a good idea for the Project Board to
set Ambassador User involvement at the start, fixing regular times in their staff's weekly schedules when the project has first
priority, as well as allowing for more ad hoc contact as required.

For more infrequent but important user sessions such as key facilitated workshops, the dates and necessary user roles must
be agreed and fixed as early as possible in the project, in order to give user management sufficient notice of any disruption to
their own or their staff's schedules. To ensure that the users turn up on the day, their roles in the activity should be confirmed
and clarified by the Project Manager or Facilitator nearer the date.

All of the above require some selling of the advantages to both users and their managers of their active involvement. For user
departments that have not been exposed to DSDM before, one approach could be to provide the user area with a one-day
DSDM Awareness course.

Severe difficulties in achieving users as part of the team can be mitigated by using groupware and video email/conferencing
facilities to create a virtual team, but this is very far from the ideal and should only be used as a last resort.

If the eventual user population covers a wide variety of departments within the organisation, it is essential that all sections of
the user population are either in the development team(s) or are frequently consulted as to their requirements. If they are not,
the final system may not be accepted into those departments that are not represented.

http://www.dsdm.org/version4/2/public/Risk_Management.asp (5 of 8) [11-1-2008 16:02:43]


DSDM Public Version 4.2 - Risk Management

A particular and very high risk occurs if the level of user involvement that was agreed at the start of the project is not
forthcoming. In this case, the issue needs to be escalated urgently up the organisation's hierarchy and resolved to everyone's
satisfaction.

The time spent in decision-making endangers the project schedule

One problem that can arise is that the level of empowerment is not understood by the development teams. This can lead to
fear of overstepping the boundaries of responsibility and hence the activities slow down. There are several approaches to
avoiding this risk:

● The project Terms of Reference can include the decision-making process for "show stoppers"
● The empowerment levels can be clearly stated in each person's terms of reference
● The decisions on policy should be separated from operational decisions. The responsibility for the latter lies within
the team, whereas policy decisions are referred to higher authorities. There needs to be a fast approval process
decided for such decisions before the project undertakes any serious investigative work.

Another problem that can slow progress down is that when a decision falls outside the remit of the team and the decision-
maker takes too long in deciding on the best strategy. To alleviate this, the Project Manager should present the decision-
maker with a set of recommendations from which to choose. (Giving the team the task of putting together these
recommendations ensures that they can live with the decision.)

In the short timescales of a DSDM project, any delay is more noticeable than on a project working to a longer elapsed time.
For instance, if the team has to wait five days for a senior user to make a decision, the delay is a far greater percentage of
the time available in a 60-day project than in a 12-month project. Moreover, in a DSDM project, it is the delivered functionality
that will suffer rather than the timescales.

Team members become focused on activities rather than products

Risks begin to multiply when the length of a timebox is set arbitrarily and the development team becomes more absorbed by
its activities than by the delivery of useful products.

These risks are best avoided by careful team selection, appropriate reward and recognition systems and by setting short
timeboxes. Good DSDM developers are characterised by a passion to see their work used rather than primarily being
interested in technical problem-solving activities. Selection processes should be geared to finding delivery-focused staff.
Reward and recognition systems should be similarly focused on the timely delivery of products that are used by the business.
Where the needs of the business are not dictating the length of an increment, it is still vital to keep the duration short to
maintain focus.

Deliverables are not fit for their business purpose

There are several symptoms of this risk. They include creeping functionality and runaway focus on technical solutions. The
end result is always that the business benefits are not delivered as expected.

The prime risk management approach is to use DSDM properly with controlled, objective-driven prototyping, strong user
involvement to constantly push the business needs to the fore of the developers' minds, iterative development, etc.

However there are specific risk management approaches to use. One area where the developers (often assisted by the
Ambassador Users) can spend too much time is in enhancing the user interface unnecessarily. Having a well-defined Style
Guide will limit unnecessary creativity in this area.

It is a good idea to expect the team members to report progress by delivery against objectives rather than discussing how far
through a particular task they are. This helps to produce the right mindset within the team.

Regular formal reviews should be held inside the team where deliverables are assessed against the minimum usable subset
and against the business benefits expected from a particular deliverable. The business objectives should be revisited to
ensure that the project is moving in the right direction. For instance, if the maintainability objective is not constantly in the
developers' minds, the system may not achieve its long-term business benefits.

Iterative and incremental development activities are not well controlled

A particular risk associated with iterative and incremental development is that of creeping functionality that does not converge

http://www.dsdm.org/version4/2/public/Risk_Management.asp (6 of 8) [11-1-2008 16:02:43]


DSDM Public Version 4.2 - Risk Management

to a working system. The ability to change one's mind is a cornerstone of value in DSDM, but it is also a weakness if the
team cannot get closure on the delivery of a useful product. Short timeboxes, appropriate reward mechanisms and properly
focused staff are once again keys to avoiding this trap. Additionally, frequent access to key user management helps if closure
is needed.

Another risk arises when compliance with the iterative, incremental approach is low. In the degenerate case, a development
of one iteration and one increment is the traditional waterfall lifecycle itself with all its attendant difficulties and dangers.
Chunking the system into too few increments must be resisted, as must reducing the number of iterations since the
importance of user feedback cannot be underestimated.

Note: Both delivery focus and incremental development are considerably aided by a system design that is highly modular. If,
at the point when requirements are baselined, the design is not modular then this may be sufficient reason for escaping from
DSDM as a delivery process or for continuing round the design process for another iteration.

Backtracking is difficult or even impossible

It is often tempting to cut corners in fast-delivery projects by implementing an increment of development without the ability to
fall back to an earlier version if the enhancement needs to be withdrawn. This constitutes a major risk and is why
configuration management is stressed in DSDM. Sound tools and proper management controls are needed to avoid the
problem. Where configuration management tools are not available, good manual methods will be needed.

Because configuration management can be both labour-intensive and time-consuming, it is recommended that the
development process is audited frequently to ensure compliance.

The high-level requirements are not baselined

A failure to baseline high-level requirements is likely to lead to creeping functionality and timebox overruns. In some ways,
this risk is greatest when the team is empowered and the users are fully involved. The tendency to do too much research on
the detail of the requirements before freezing the scope is a natural human instinct. Chunking the system into modules that
will correspond to timeboxes is a powerful way to freeze the scope of all but the next timebox before moving into greater
detail on that timebox.

Another risk mitigation action is to agree early, immovable sign-off dates with senior users so that too much detail is avoided.

Testing is not integrated throughout the lifecycle

If a system is being developed in an iterative, incremental way by a team that has high user involvement, then it is difficult not
to test throughout the lifetime of the project. However, continuous testing can be encouraged by building a measurement
system into project control. This will not only help formalise the testing but it will also help ensure that it is done thoroughly.

With so much changing so fast within a DSDM project, a clear approach to testing which is visible to all is essential. Clearly
allocating the responsibilities of the Tester role in every team mitigates this risk.

Not all stakeholders are committed to a collaborative and co-operative approach

Large-scale computer systems often involve a wide range of stakeholders, including suppliers and vendors. In these cases,
the development team can have to handle a broad range of contractual terms and conditions. Where a fully collaborative
state is not possible, the team should build in reviews to mitigate risks as and when required.

A particular instance occurs where purchasing contracts apply. DSDM recommends a time and materials approach to labour
procurement rather than a fixed cost approach. Where this is not possible, risk mitigation activities will include actions such
as frequent reviews, on-site location of staff and mutual secondment.

An adversarial approach to deciding development activities, changes in scope, requirement priorities, etc. must be avoided.
As soon as this occurs, communication and decision channels become rigid and the close partnership that is essential to
DSDM's success falters. If there is lack of trust between developers and users, DSDM can be a liability rather than an asset.

Other risks

DSDM is not wholly applicable

http://www.dsdm.org/version4/2/public/Risk_Management.asp (7 of 8) [11-1-2008 16:02:43]


DSDM Public Version 4.2 - Risk Management

It is strongly recommended that a risk assessment should be performed at the outset of every project starting with the
Suitability/Risk List and the other criteria discussed in When to Use DSDM. A formal risk assessment should then be
performed and the Risk Log updated with every iteration of the Functional Model.

The development team does not understand the development process

If the developers are unfamiliar with the process, in-depth training needs to be carried out before the project begins. If the
users are new to DSDM, it is worth spending a day training them at the beginning of the project. The user training should
cover not only those who are to be part of the development team but their managers. This will also minimise a common
problem in user-centred development, that of users committing, say, 60% of their time to the project and still being required to
perform 50% or more of their normal job.

The organisation of the user area will change dramatically as a result of the introduction of the system

If the users in the project may not be those eventually involved with the finished product, then the project needs to be certain
that the users in the project are willing and capable of participating in development. It is likely that staff who feel threatened
by change will not participate as wholeheartedly as DSDM requires.

The original project approach turns out to be inappropriate during development

As the nature of the development becomes clearer during the life of the project, it may be necessary to move out of DSDM
into another development approach or to alter the approach within DSDM.

As requirements are elicited and better understood, the minimum usable subset may be too large and complex to manage
successfully with the project team as it was originally set up. The strategy could be to quickly set up another DSDM team or
project. This may cause excessive pressures on the users who are involved in the initial project, so it may be necessary to
change to a less user-intensive approach to development.

During Design and Build Iteration, technical difficulties may slow down development as the team strives to achieve the levels
of service that are deemed essential in the Delivered System. If this happens the Project Manager should either negotiate
with the user management to reduce the required levels of service or, if that is unsuccessful, negotiate for a transfer to a
slower, more techno-centric approach to development.

The development toolset does not truly support incremental delivery

If the tools and techniques selected for development of the software are designed for a waterfall approach to development,
this may cause unavoidable delays to the development team. An example of this is an upper CASE tool with very rigorous
completeness and consistency checks that do not enable partial models to be built and used effectively. Another example is
the configuration management tools and techniques. These must be readily usable by the whole team in order for all team
members to be certain that they are working on the correct version at any one time.

The development environment is unfamiliar to the developers

Long learning curves are not an acceptable feature in a DSDM project. Developers are expected to be familiar with the vast
majority of the components of the development environment. This includes everything related to development activities and
control, such as hardware, tools, techniques, standards, and configuration management procedures. Where new areas of
expertise are necessary, specialist support should be arranged at the start of the project to be available on demand.
Attempting to arrange specialist help very shortly before it is needed on a DSDM project is courting disaster.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Risk_Management.asp (8 of 8) [11-1-2008 16:02:43]


DSDM Public Version 4.2 - Measuring DSDM Projects

Introduction When Lifecycle People Products Management Development Tailoring Other

Measuring DSDM Projects

Why measure?

The purpose of measurement is to investigate and highlight some aspect of a project. Measurement is necessary in
order to:

● establish a baseline for predicting what will happen in the future


● provide evidence that the process is successful and working
● investigate the process itself in order to highlight and quantify problems.

Where the intended purpose of the size metric is estimation and planning, Mark II Function Points, based on the
business functions (tasks) and data requirements of an application, have become widely used as a standard. They do,
however require experience in the appropriate application of the approach.

Analysis of measures taken during a project provides the basis for tracking progress and can highlight issues that
demand management attention.

Measurement can provide the ammunition to convince management that the introduction of DSDM can provide
tangible benefits to the organisation. However, when building the case, some acknowledgment should be given to the
"Measurement Effect", i.e. the human behavioural phenomenon that introducing measurement will impact what is being
measured. Studies have found that the process of introducing visible measurement alters the outcome of a process.
Often this has a bigger impact than the change that the measurement was introduced to assess. So, be aware of the
measurement effect when projecting the effectiveness of new techniques or approaches.

What measures?

It should be decided at the outset of the project what measurements are to be collected. It is important first to establish
the purpose of any measurements to be taken. Different organisations and projects will have different objectives; hence
it is not possible to prescribe a standard set of measures to be used on all projects.

However, most organisations will be interested in estimating the next project(s), planning the content of timeboxes,
achieving quality products, tracking the progress of a project and successfully meeting their objectives. Therefore basic
measurements of the productivity of the process and product delivery and quality will normally be required.

Two kinds of measurements can be taken, referred to here as "hard" and "soft" metrics. "Hard" metrics are realised by
counting some empirical attribute of the project or software (e.g. number of screens in the system). "Soft" metrics are
realised by using questionnaires for ascertaining the views and perceptions of people about the project or the process.

Measuring size

Measurement will almost always include a concept of the "size" of the software or the "size" of the task since most
useful measurements are size-related. The "size" of software is not something that can be expressed in easy physical
dimensions. There are however many metrics that can be employed to give a feel for "size", e.g.:

● number of executable lines of source code


● number and complexity of business functions
● number and complexity of inputs and outputs
● number of entities in the data model or objects in the object model
● number of function points.

Where the intended purpose of the size metric is estimation and planning, Function Points, based on the business
functions and data requirements of an application, have become widely used as a standard. They do, however, require
that trained and experienced practitioners are available.

http://www.dsdm.org/version4/2/public/Measuring.asp (1 of 3) [11-1-2008 16:02:56]


DSDM Public Version 4.2 - Measuring DSDM Projects

Cautionary note: When measuring the size of a completed delivery, be sure to measure only what was actually
delivered. Do not measure products that did not achieve deliverable status, however near completion they became.
Otherwise, any future estimates based on these measurements will be inaccurate.

Measuring effort

Most projects measure effort related to the activities in the project. It should be recorded at a low level of granularity
then aggregated to cover larger activities. Unlike traditional projects that record man-hours for each task in the project
plan, DSDM project plans are based on products and timeboxes rather than low-level tasks. It is useful, therefore, to
collect effort expended on each prototyping cycle.

When measuring effort it is important to make sure that all the relevant effort expended is recorded, including long
hours worked and excluding non-project time. Also, DSDM projects expect more user effort than conventional projects
and a record and subsequent analysis of the project's success will show if sufficient was available. Certainly user
management will want an estimate of user time required on future projects.

Having recorded effort at a low level of granularity it is possible to aggregate it. It is recommended that effort is
recorded by prototyping cycle and aggregated:

● by prototype
● by DSDM phase
● by increment
● by project.

Measuring and recording the percentage of effort and time expended on each of the DSDM phases is important

Measuring defects

Projects should keep careful records of defects. For constructive analysis, defects should be classified according to
their severity and type. A 3-way severity classification is probably adequate for distinguishing (1) those that cause the
application to fail from (2) those that cause the application to miss one or more of its business objectives and from (3)
those that are relatively trivial and cosmetic. Suggested defect types are:

● functional
● data
● internal interface (e.g. inconsistent parameter usage)
● external interface (to other systems, manual or automated)
● non-functional (e.g. performance or security).

Defects should be recorded with the information about when during the lifecycle they were discovered and the probable
cause. A DSDM project should discover most of the significant business problems during the prototype testing in
Functional Model Iteration. If serious business problems are being discovered later than this, it might indicate that
something is wrong with the prototyping process

Overall comparative indicators of the quality of the final delivered application are based on defects recorded, usually
after the application goes live. Typical are:

● mean time to failure


● the number of severity 1 and 2 defects reported per 1000 function points during the first month (or other
period) of live running
● effort required in corrective maintenance.

The DSDM process is particularly designed to give a good fit for business requirements and high quality applications. If
this is failing, then something is probably wrong with the application of quality management procedures.

http://www.dsdm.org/version4/2/public/Measuring.asp (2 of 3) [11-1-2008 16:02:56]


DSDM Public Version 4.2 - Measuring DSDM Projects

Measuring success

The success of a project will be whether or not it achieved the objectives that it set out with. It is necessary, therefore,
to describe objects at the onset in precise measurable terms. The DSDM method is focused on satisfying all of the
"must haves" within a fixed elapsed time frame; hence any measurement of success will include all of these.

This concept is extended to individual timeboxes where the objectives of each timebox are established and prioritised
at its start. These objectives should also be expressed in measurable terms so that the review at the end of the
timebox can easily assess the outcome.

DSDM projects are trying to deliver the "must haves" in short time frames by not realising all of the lower priority
requirements. If "could haves" and "should haves" are also all satisfied, then the estimates are probably not tight
enough and should be tightened up on future projects.

DSDM also sets out to achieve user buy-in and ownership of the delivered application. "Soft" measures are a useful
way of establishing how acceptable the delivered application is within the user community.

Using productivity measurements

Productivity is probably the basic measurement for estimating. It is also one likely to be of considerable value when
"selling" the benefits of DSDM to management. Productivity is a function of several project aspects, particularly:

● The type, size and complexity of the application (projects that pass the suitability filter are likely to be those
that generate greater productivity)
● Team size (4 - 6 being the most productive team, higher being less productive than lower numbers, hence the
recommendations for DSDM development team size)
● Motivation (provided, at least partially, through effective use of DSDM timeboxing)
● Experience with the approach or method and the tools being used.

It is important to both record and to attempt to predict these characteristics along with any other standard metrics
gathered. They help both to explain or predict anomalies in the measurements from different projects and to adjust
estimates for the current project.

Care must be taken when using DSDM purely with the intention of squeezing timescales. Figures published by the
UK's Office of Government Commerce show that shortening a timescale by more than 25% from that calculated to be
required, by adding extra staff is very difficult as productivity declines with numbers. Indeed, Barry Boehm has shown
that a timescale compressed below 75% of that predicted becomes "The Impossible Region", i.e. cannot be attained as
the decline in productivity becomes so marked.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Measuring.asp (3 of 3) [11-1-2008 16:02:56]


DSDM Public Version 4.2 - Estimating DSDM Projects

Introduction When Lifecycle People Products Management Development Tailoring Other

Estimating DSDM Projects

Introduction

Estimating provides the information that is required for two main purposes:

● to assess project feasibility by evaluating costs and benefits


● to use in project planning, scheduling and control.

Estimating for DSDM projects is not fundamentally different to estimating for any other project. The same type of
information is required as inputs, the outputs are similar and the same techniques may be used.

Some of the major differences are in handling of contingency, who estimates and how frequently estimating is carried
out during the project.

The principles for estimating

There are two refinements of the underlying principle that the focus is on frequent delivery of products rather than on
activities. The principles for estimating affect the way estimating is done in DSDM projects, namely:

● Estimates should be tight from the outset with frequent deliverables;


● Estimates that are based on outline business functions provide the closest match with the DSDM development
process.
● Estimates should be tight from the outset with frequent deliverables;
● Estimates that are based on outline business functions provide the closest match with the DSDM development
process.

The first estimating principle means it is unacceptable in DSDM for activity overrun and for long timescales for agreeing
the quality of products. The aim is to deliver the core system by the date required. By keeping effort estimates tight and
short term, the development team cannot waste time on any activities not directed towards meeting the business
objectives. It also precludes any justification for making provisions for contingency in estimates - other than that
provided within the flexibility of requirements.

The second estimating principle means that the starting point for estimating should be the expected functionality of the
end products rather than the activities used to deliver those products. This maintains the focus on delivering business
benefit.

The use of timeboxes in DSDM projects, which are aligned to delivering particular business components, supports both
these principles.

http://www.dsdm.org/version4/2/public/Estimating.asp (1 of 8) [11-1-2008 16:03:20]


DSDM Public Version 4.2 - Estimating DSDM Projects

Estimating basics

Estimating is a prediction based on the information available at the time - essentially an extrapolation from past and
current knowledge to the future. This cannot be done with complete certainty because the future is unknown, therefore
the actual effort or cost to deliver will almost always be different to the estimate. The better the quality of the
information available for estimating, the closer the estimate is likely to be to the actual figures.

The estimating process

Estimating must be based on a defined process so that it is rigorous and repeatable. Whatever process is used the
primary information required to estimate is:

● Scope of what is to be delivered


● Delivery capability

Scope defines the size of what is to be delivered, and may be measured (or estimated) in different ways. It defines the
business requirements of the system - generally expressed as the functionality of the system, but may also include non-
functional requirements and products such as trained user population.

Delivery capability defines the ability of the team to deliver this scope. This should ideally be based on past experience,
i.e. metrics from previous projects.

This information is input to the estimating process to derive an estimate for the effort (and/or cost and elapsed time)
required to meet the defined business objectives.

The estimate must be documented sufficiently to allow its derivation to be understood at a later date, and to allow
revisions

Contingency

Contingency must be included in any estimate in order for it to be realistic. The main reason is that estimates are
predictions, which will be affected by future events both internal and external to the project. These events cannot be
known with certainty and the estimate must make reasonable allowance for them. Additionally, software development
itself is not an exact science.

The size of the contingency in an estimate must reflect the degree of uncertainty.

This is one of the main areas where estimating for DSDM differs from traditional project development methods, and is a
consequence of the principle that requirements are baselined at high level.

All projects have constraints: in software development projects the three main ones are functionality, time and
resource. If any one of these three is changed then either one or both of the others must change. This is illustrated in
the two triangles diagram in How the Process Works, which also shows the difference in the way these apply in
traditional and in DSDM projects.

In traditional projects, the functionality is fixed in the detailed requirements or functional specification. This is what will
be delivered although it may take longer or use more resources to do so that originally estimated. The variability and
therefore the contingency is in the time and resource.

By contrast, in DSDM the requirements are flexible and it is the time and resource that remain fixed - the project
timebox. The project guarantees to meet the business objective by delivering must-have functionality, and will deliver
as much lower priority functionality as time and resource permits. Thus the contingency is in the functionality.

This affects the scope of the estimate and is covered in more detail in the estimating techniques section.

http://www.dsdm.org/version4/2/public/Estimating.asp (2 of 8) [11-1-2008 16:03:20]


DSDM Public Version 4.2 - Estimating DSDM Projects

When to estimate

Estimating is done throughout DSDM projects. The purpose of these estimates, and the information on which to base
them, varies at each phase of the project and therefore different estimating techniques may be used.

Pre-project

Before the project begins properly an estimate must usually be prepared for the Feasibility Study itself. This may be
based on a timebox, i.e. defining a fixed team for a fixed period, or may be based on a schedule of workshops and the
associated effort to complete the products.

Feasibility Study

The first estimate for the whole project is prepared towards the end of Feasibility Study, after the majority of the work
has been carried out. This is a rough estimate, based on high level requirements. Its purpose is to assist management
to assess the value and practicality of continuing with the project It is based on the current high-level understanding of
the business processes, data and interfaces as scoped by the Feasibility Report and is used to develop the Outline
Plan.

Business Study

The second estimate is produced at the end of the Business Study. At this point, the scope of the project is decided,
the necessary business functionality to be delivered is defined and prioritised, and the system architecture is defined.
The primary purpose of this estimate is to plan and schedule the project, i.e. to prepare the Development Plan. It is
also used in re-evaluating the Business Case, to assess whether the project is still viable. This estimate is relatively
detailed as it based on the likely major components of the delivered software identified from the prioritised
requirements. The team is defined at this point, and together these enable the definition of the length of timeboxes to
be allowed for developing the various components. In a commercial environment, the estimates produced during the
Business Study will usually form the basis of a contract. Therefore the estimates must reflect a level of risk and
confidence that is acceptable to the relevant stakeholders.

Functional Model and Design and Build Iterations

The detailed estimate from Business Study provides the basis for the whole project, and throughout the remainder of
the project this estimate is frequently monitored and revised. This estimating is done for each timebox, the purpose
being to assess whether the timebox plan is achievable, and to evaluate the impact on the project if any revisions to
the estimate are required. The focus of timebox estimating is on what can be delivered within the timebox, rather than
how long will it take to complete tasks.

Before the start of each timebox an estimate for the expected work is carried out to ensure that it remains achievable in
light of project experience to date. If necessary the work is re-estimated and the impact on the project evaluated.

Early in each timebox, as the timebox team learns more about what it actually has to do and if, as a result, significant
changes to the original assumptions have emerged, the estimates for the timebox will need to be revisited again.

Where there is evidence of significant deviation from the estimates, the original estimates should be carefully reviewed.
If seen to be reasonable from the information that was available at the time of their production, the current scope and
complexity of the project should be reviewed to ensure that the project has not inadvertently drifted outside the original
scope. Where priorities have changed or new required functions revealed through prototyping, trade-offs must be made
to accommodate them.

http://www.dsdm.org/version4/2/public/Estimating.asp (3 of 8) [11-1-2008 16:03:20]


DSDM Public Version 4.2 - Estimating DSDM Projects

Implementation

Until the Implementation Plan is prepared during Functional Model Iteration, there are only very high level estimates
available for this phase. During preparation of the plan, the more detailed estimates of effort for each product and
activity are derived.

Before the Implementation phase begins, the estimates must be reviewed to ensure they are still reasonable - and
similarly for any lower level timeboxes during this phase. If any changes to the estimates are required then the impact
on the project must be evaluated.

At the end of an increment the work should be measured and the measurement fed back into the increment review and
the metrics database of the organisation.

Who estimates

Estimates should be made in DSDM by the team that will do the work in order to get the team to buy into the tight
timescales. If outside estimates are made for commercial reasons, the team must satisfy itself that those estimates can
be met.

During the Feasibility and Business Studies the full development team is not yet in place, and the Project Manager and/
or independent estimator generally prepares the estimates with input from the relevant experts, such as the Technical
Co-ordinator. During the prototyping phases, the development team needs to estimate how much functionality they can
produce in a timebox and re-estimate as they go along.

As progress is made in a timebox and as requirements evolve, the team continually re-estimates what they can deliver
in the timebox and the Project Manager continually re-estimates to ensure that the project can meet its objectives on
time. As evolving requirements are generally expressed as business tasks - new, refined or modified, then the
estimates need to be related to business tasks. Hence, whatever estimating method is chosen, the presentation and
calculation of the detailed estimates produced from Business Study onwards should reflect business tasks.

Estimating techniques

Estimating techniques can be broken down broadly into two categories: top-down and bottom-up.

Top-down estimating

Top-down estimating techniques generally have the following characteristics:

● They are based on the business requirements (rather than system components).
● They give a figure for the project as a whole, which may be broken down into phases on a pro rata basis.
● They are fast to prepare.
● They can be derived from very high level requirements.
● They give a high level view of the project (its overall cost and timebox) which can be used in evaluating the
feasibility of the project.

The most familiar top-down approach is estimating by analogy, where the proposed project is compared to similar
completed projects.

Bottom-up estimating

Bottom-up estimating techniques generally have the following characteristics:

● They are based on tangible system components.


● They give detailed figures for low level components of the project which can be aggregated to give higher level
views
● They take time to prepare

http://www.dsdm.org/version4/2/public/Estimating.asp (4 of 8) [11-1-2008 16:03:20]


DSDM Public Version 4.2 - Estimating DSDM Projects

● They need sufficiently detailed information to allow identification of system components


● They provide a good basis for project planning, scheduling and management

Bottom-up approaches involve counting programs, screens, reports or other implementation-related information shown
in a design and estimating the effort for each of those.

Function Point Analysis

Function Point Analysis (FPA) is a measurement technique that can be useful for estimating DSDM projects as function
points can be derived at an early stage in the lifecycle. They are based on business requirements and are independent
of the technology used to implement the system. FPA is, in effect, a technique for quantifying the size of the "users'
view" of the functionality provided by the system. Estimates based on function points are top-down in that they give a
figure for the whole development, which may be split into phases on a pro rata basis.

In order to count Function Points, it is necessary to have an understanding of the business requirements of the
application. It is important therefore to structure the Feasibility and Business Study workshops to capture known or
main business functions in a way that provides the type of detail required for FPA. If is not practical to gather sufficient
detail to allow actual counting of function points, then techniques may be used to estimate function points. For
example, default function point values may be defined for a range of sizes of functions. The requirements need only be
defined sufficiently to assess the sizes of functions.

The calculation of Function Points, expressed as a Function Point index, is only the first part of the estimating process.
It is then necessary to apply a productivity rate to develop a time and effort estimate. To be accurate, this requires
measurements to be taken relevant to the specific environment, but industry standards may be used as a first pass. As
these are very variable any organisation using them must collect their own metrics to validate them.

The following guidelines are included for reference, but must be used with caution. An experienced team in the right
circumstances could produce around 45 Mark II Function Points from every 100 hours effort, whereas a team using
new tools and who are new to DSDM would produce around 18 or so. Most teams would be somewhere in between.
(This compares with an expert team on a large "waterfall" project probably producing around 15 Mk II Function Points
from the same effort).

Estimating from system components

This is the most common bottom-up estimating technique, and consists of identifying tangible system components such
as screens, web pages, functions, reports, etc., and assessing the size and/or complexity of these. Estimating
guidelines (metrics) are then used to allocate development effort to these. This can be done at various levels of detail,
depending on the guidelines available and on the project requirements.

This technique relies on the quality of the guidelines or metrics, and on understanding of what they include. For
example, at the simplest level the metrics may cover just the build of components. Further guidelines would then be
used to multiply these pro rata to cover the other phases and activities that must be included in development, such as
analysis, design, testing, project management etc. An estimate produced from this rather high level of detail is often
referred to as a ballpark.

Alternatively, metrics may be maintained for all individual development activities and these may be used to provide a
detailed bottom-up estimate showing effort for every activity, product and function. A detailed estimate can be cut and
sliced or aggregated in various ways as required for preparing the Development Plan, for example by groups of
functions and/or by phase.

This approach allows inclusion of extra activities and products required for the development that might be
underestimated in a top-down method - often these are to meet the non-functional requirements. The best way of
estimating for these is to identify the product and then estimate the effort required to deliver it, e.g. to provide a security
module, to set up a complex infrastructure, to run a stress and performance test, or to build a capability prototype. An
alternative way to estimate is to identify the specialist role that is required and include effort for this person on a full or
part-time basis.

Collaborative estimating

http://www.dsdm.org/version4/2/public/Estimating.asp (5 of 8) [11-1-2008 16:03:20]


DSDM Public Version 4.2 - Estimating DSDM Projects

A facilitated workshop environment is an excellent approach to gaining both sound estimates and buy-in to these
estimates from the team and the stakeholders. The general principle is that the workshop participants should, between
them, have expertise in all the main technical and business areas covered by the project, as well as in project
management and estimating. Estimating workshops require considerable preparation in order to achieve their
objectives.

The Wideband Delphi Technique is a formal definition of such an approach and is described in Barry Boehm's
"Software Engineering Economics".

General estimating principles and guidelines

The following are some principles and guidelines that apply to all estimating, including DSDM.

● Use more than one technique to allow cross-checking, e.g. top-down and bottom-up
● Produce estimates by workshops involving all stakeholders, rather than by individuals
● Ensure the estimate includes sufficient effort for all timebox activities not just those directly resulting in
business functionality. For example:
❍ Project management, team leading, technical co-ordination

❍ User involvement

❍ Non-functional requirements and technical products

❍ Specialist roles, such as business and technical consultants, quality and test managers, security

specialists, and so on
❍ Specialist roles, such as business and technical consultants, quality and test managers, security

specialists, and so on.


❍ Workshop preparation, attendance and follow up, including facilitation and scribing

❍ Completion of project documentation

❍ Quality reviews, inspections, walkthroughs, timebox planning and estimating

❍ Travel and meetings particularly if cross-site

❍ Mentoring if project and/or organisation is new to DSDM

❍ Specialist testing such as stress and performance, or operational acceptance.

● Ensure all areas of development are included: avoid focus on pure coding effort.
● Capture project metrics and feed back actuals vs. estimates into the estimating process.
● Ensure that anyone who estimates is trained, particularly for specialist techniques such as function point
analysis.

Applying estimating techniques to DSDM projects

Feasibility Study

Generally a top-down approach is most suited at this phase as the aim is to obtain a view of the overall project cost
and timebox. As this phase is usually very short it is important that the estimate can be produced quickly, and that it
can be produced from very high level requirements.

Function Point Analysis may be used, or alternatively system components may be used to provide a ballpark estimate.
The approach selected depends on the organisation's estimating process.

At this phase it may be appropriate to add some contingency to the estimate, or to present it as a best and worst case.
This would be required if there is a significant level of risk associated with the project, for example the requirements
and/or the solutions are at such a high level that many assumptions have had to be made about their eventual size and
form.

http://www.dsdm.org/version4/2/public/Estimating.asp (6 of 8) [11-1-2008 16:03:20]


DSDM Public Version 4.2 - Estimating DSDM Projects

Business Study

During this phase the requirements are being defined in sufficient detail to provide a bottom-up estimate, which is
suitable for preparing the Development Plan. It is also useful to revise the initial top-down estimate from the Feasibility
Study to reflect the refined requirements as this provides a crosscheck.

From this point no extra contingency should be added on to estimates. Instead, the scope of the estimate should be
defined so that it provides as much contingency as is required to meet the perceived risk. Thus the estimate cannot
include just must-have requirements as this will contain no contingency and delivery of the minimum usable subset
cannot be guaranteed in the planned timebox with the planned resource. This is illustrated in the 'triangles' diagram.
Nor is it generally appropriate to include all requirements, as this is likely to give an unrealistically high figure.

The scope must be identified at some level between these extremes, and there are various options for doing this. One
is to select must-have and should-have requirements only, or to select must-have requirements only but add a
percentage to cover the should-haves. The degree of flexibility or contingency required depends on the level of risk that
has been identified. In general, to be able to guarantee to meet the business objective, the must-have requirements
should make up no more than 50-70%. This figure may be higher if the risk is low, e.g. where the team is experienced,
has worked together before in the same technical and organisational environment. If the converse is true, then the
proportion should certainly not be above 50% of total requirements.

The Business Study estimate must contain sufficient detail to allow the Project Manager to partition the project into
suitably sized chunks to be addressed by development teams in timeboxes. To support the desired prototyping
approach, it may be necessary to partition in various ways, e.g. by groups of requirements, by project phase, or by
prototype category. Project planning and timeboxing have more detail on planning for timeboxes

Prototyping timeboxes (Functional Model and Design and Build Iterations)

Top-down estimates are not suitable for detailed timebox planning - they are at too high a level of detail. An estimate
based on tangible system components provides the best match with development activities at this level of detail. It is
essential, however, that these components can be directly related to the business requirements.

In timebox estimating the focus is on identifying what will be delivered in the time available. The same principle holds
as for the whole project, that to be able to guarantee a minimum delivery there must be some flexibility in the
requirements. Thus it is necessary to include an appropriate balance of priorities - generally similar to that for the whole
project. This approach may be refined however throughout the life of the project, with earlier timeboxes having a
relatively lower proportion of must-haves to allow for the greater degree of unknowns. As more experience is gained,
the proportion of must-have can be increased.

Implementation

Estimating for Implementation is bottom-up based on the planned activities and products. It may be cross-checked by
evaluating it as a percentage of overall development to determine whether this falls within a reasonable range. This
varies according to the type of development but somewhere around 10-15% is a reasonable rule of thumb, which
should be validated from project metrics

http://www.dsdm.org/version4/2/public/Estimating.asp (7 of 8) [11-1-2008 16:03:20]


DSDM Public Version 4.2 - Estimating DSDM Projects

Tools

Tools are essential to allow the frequent estimating and re-estimating that is required in DSDM projects. These range
from simple spreadsheets to sophisticated estimating applications.

The essential criteria for selecting tools are:

that they support the DSDM estimating requirements

● that they are applicable to your organisation


● that they use metrics that you are able to collect from your projects and use for validation
● that they are compatible with other related tools used by the organisation, e.g. for system design and project
management.

Some estimating tools provide estimating metrics based on industry experience. These can be valuable to support an
organisation whose own metrics are insufficient, or to provide an independent cross-check of estimates produced by in-
house tools.

Resourcing and estimating user involvement

The balance of effort across the lifecycle is different in DSDM from traditional methods because:

● the use of incremental prototyping will introduce not only design effort into the analysis activities but also
implementation and testing effort into design
● activities that are usually at the tail end of development, such as acceptance testing, are minimal as blocks of
activity since they are spread thinly throughout the lifecycle with probably a composite system and acceptance
test stage before implementation.

The result is that a graph of resource levels across the project will be much flatter than with traditional approaches. The
classic resource level curve ignores the important but sporadic involvement of users at key points in the lifecycle. In
DSDM, the user involvement is fairly uniform across all the development phases. The number of developers in the
team may well rise after the Feasibility and Business Studies, but from that point it should be reasonably static.

It is imperative to include user resource levels in all DSDM estimates. They should be clearly identifiable so that the
actual user involvement can be monitored and recorded against the estimates.

If your standard estimating model only calculates technical (i.e. developer) effort, then allowances must be added on
for user effort. Empirical observation shows that around 20% (minimum) to 30% (maximum) of the total project
resource should be provided through the user roles in DSDM. Most are quite easily calculated through standard task-
based estimating, in that the things to be done can be planned for and scheduled for the Executive Sponsor, Visionary
and Advisor User roles. The role for which it is difficult to do a task-based estimate for is the Ambassador User. The
best starting point is to estimate the technical effort, assume that is approximately 75% of the total project effort, and
assess the total user effort as the rest. Calculate the effort required to perform the tasks required of the Executive
Sponsor, Visionary and Advisor Users, and subtract those from the user total. The remainder will be a reasonable
guide for Ambassador User commitment to the project as a whole.

As with all estimating guidelines, it is essential to collect metrics from projects so that they can be validated and refined
for use in estimating future projects, i.e. to provide continuous improvement of the estimating process. The section on
measuring DSDM projects provides further information.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Estimating.asp (8 of 8) [11-1-2008 16:03:20]


DSDM Public Version 4.2 - XP and Estimating

Introduction When Lifecycle People Products Management Development Tailoring Other

XP and Estimating

Basic XP concept

In XP, the start of the estimation process is for developers to estimate how long user stories will take to implement.
Estimates are defined in agreed units, typically "ideal programming days", i.e. the number of days it would take to code
the story if there were no distractions, no other assignments for the developer, and the exact specification was clear.
Estimates also include testing time and time for refactoring. If an estimate is longer than the iteration then you will need
to break the story into smaller stories. An important principle is that the team owns the estimate and in practice this is
best achieved through the developer who is doing the work also making the estimate.

Spiking (DSDM prototyping) can be used to increase the accuracy of an estimate by clarifying the design of the
solution.

Assessment of XP

Estimation is not easy, especially when developers are new to a technology or development approach. XP and DSDM
agree that the developer doing the work estimates it.

Guidance for those looking to use XP with DSDM

In order to produce an accurate estimate for a story, developers will sit down together with users to discuss the detail of
each story. The aim of this discussion is to ensure a clear understanding of the required functionality and the proposed
solution. It is possible to gauge the risk of an estimate by considering the following questions:

1. Do we know exactly how to do this?


2. Do we think we know how to do this?
3. Do we have any idea at all what this means or how to do this?

In estimating, architectural dependencies are considered, i.e. estimates are made with reference to a particular context,
e.g. with the code for Story X already delivered, Story Y may take 5 days to code. Without Story X, Story Y may take
10 days.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/XP_And_Estimating.asp [11-1-2008 16:07:26]


DSDM Public Version 4.2 - Development techniques

Introduction When Lifecycle People Products Management Development Tailoring Other

Overview of Development Techniques


There are many development techniques that can be applied in a given project. Indeed, no one technique is applicable
in a uniform way to all projects and not all techniques can or should be used in every project. This section focuses on
the ones that are most critical to success in a DSDM project.

Hence, the techniques contained within this section of the manual are described in terms of what is important to
consider when applying them in DSDM's business-centred development approach as well as providing practical
guidance as to how and when they should be used in projects.

The techniques covered are:

● Facilitated Workshops, which are an important technique in keeping a project moving along quickly and in the
right direction both in business and technical terms. They are used throughout DSDM projects to both create
products and make decisions quickly incorporating a wide range of stakeholder views.
● Prototyping, which is fundamental to successful DSDM projects. This technique enables real user involvement
in development activities from a very early stage and thereby enables the users in the project team to steer the
developers in the right direction needed to achieve maximum business benefit. Prototyping encourages
creativity. However, it needs to be controlled: this section shows how this is done in DSDM.
● Modelling Techniques. Guidance is provided about what to model, when and how, while enabling each
organisation and project to determine the best set of models to produce in particular circumstances: one size
does not fit all!
● Testing, which is performed throughout DSDM in order to ensure that the project solution is of the required
quality. This section provides guidance about how to test in such a way that the focus is on what must be done
rather than on what could be done if more time were available. Much of the guidance is aimed at medium to
large projects. However, the underlying principles and approach can and should be applied on even the
smallest projects.
● Configuration Management, a key factor in managing the evolving products (both software and documents)
that are created throughout the DSDM lifecycle from project initiation to the completion of the final delivery.
The section covers how to decide what to control using configuration management, who should be responsible
for configuration management and when to do it.
● Support Environments, i.e. the toolset that developers use to create the project's technical products. The
support environment is an important factor in enabling fast delivery: a poor toolset will hinder the creativity of
developers within the teams. Guidance is provided about what tools to focus on and how to choose ones that
are most suitable for the iterative and incremental approach of DSDM.

XP can be used within the DSDM framework where team members may prefer a very dynamic approach to
programming. Alternatively, they may wish to deliberately reduce the amount of 'up front analysis' that would typically
occur on a DSDM project, in order to allow solutions to emerge 'XP style' (Often referred to as 'emergence'). XP is
often regarded as being particularly strong on programming techniques and practices - therefore many of its practices
are discussed in this section. (For XP management techniques such as project control see the section on DSDM
Management Techniques.)

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Development_Overview.asp [11-1-2008 16:08:09]


DSDM Public Version 4.2 - Facilitated Workshops

Introduction When Lifecycle People Products Management Development Tailoring Other

Facilitated Workshops

Introduction

Facilitated Workshops have been used in business and systems development in particular for years. Initially they were
used for JRP (Joint Requirements Planning) and JAD (Joint Application Design) but their usefulness was quickly seen
in other areas.

They are a core technique in DSDM for speed and efficiency as a way of making high quality team-based decisions in
short timescales.

If you would like additional resources on running Facilitated Workshops visit www.globalfn.org

Whether they are used for DSDM or any other business project, they are run in the same way. This section examines
how the approach maps directly onto DSDM and where in DSDM they can be used. It seeks to show the potential of
possible use of Facilitated Workshops in a DSDM project, rather than mandate their use at any particular point. It is up
to the project members themselves to decide whether a workshop is necessary, or whether another technique, such as
interviewing or research is more applicable.

Used properly, Facilitated Workshops are a useful tool for effecting cultural change in an organisation because they
promote buy-in from and empowerment of participants. When used effectively, they can set the tone for the whole
project.

Note: It is not intended to explain here how to set up and run facilitated workshops but to show how the technique can
be applied to DSDM projects.

What are Facilitated Workshops?

Definition

A facilitated workshop is a structured approach to ensure that a group of people can reach a predetermined objective in
a compressed timeframe, supported by an impartial facilitator.

Benefits

Using Facilitated Workshops brings both direct and indirect benefits to a project.

● Rapid, quality decision-making Because all stakeholders are present at the same time, there is great
confidence in the result. The group is focused on the objectives to be achieved in the session so that the
information gathering and review cycle is performed at a greater speed. Also, misunderstandings and
disagreements can be worked out at the time. Any concerns should therefore have been raised and resolved
or noted by the end of the workshop.

● Greater user buy-in Workshops, run effectively, lead to participants feeling more involved in the project and
decisions being made. They build and maintain enthusiasm.

● Building team spirit It is a controlled way of building rapport as well as delivering. It can promote
understanding and co-operation between departments, which is particularly important when a development
involves many groups.

● Process redesign by the user community If practices are reviewed as a result of a workshop, participants
can gain a greater understanding of the inputs and implications of their work. This can lead to improved
efficiencies that are led by the participants themselves, giving greater buy-in and commitment and therefore a
greater chance of successful implementation.

http://www.dsdm.org/version4/2/public/Facilitated_Workshops.asp (1 of 6) [11-1-2008 16:08:19]


DSDM Public Version 4.2 - Facilitated Workshops

● Clarification of requirements when they are unclear Business users can be led through their objectives and
processes to define what they may require. In the facilitated environment, participants can explore and model
ideas. This is successful through a combination of structured discussion and the presence of knowledgeable
participants.

Aligning Workshops to the DSDM framework

Aligning Workshop Roles to DSDM Roles

This section gives some guidance on which DSDM roles would fill the roles of a workshop. These are defined as being
Workshop Owner, Facilitator, Participants, Scribe and Observer.

Workshop Owner

This is the owner of the problem that the workshop is set to solve. It is up to them to set the objectives and deliverables
of the workshop, although these should also be agreed by the participants.

The owner of a Feasibility Study workshop could well be the Executive Sponsor whereas the owner of a timebox
planning session could be the Project Manager or Team Leader or even the Ambassador User.

Facilitator

The Facilitator should be impartial, with no stake in the outcome of the workshop, and therefore should come from
outside the project. The Facilitator maps directly onto the DSDM role.

Participant

Participants represent the views of the project stakeholders (e.g. the business and software development community).
They are the individuals who are knowledgeable in the areas under consideration. They manage and operate the
system and include managers, supervisors, clerical staff, and IT staff.

A participant could be one of many roles within the business or IT side. They could be a business user, a customer, a
supplier, a business analyst or data modeller or systems architect, a member of the financial staff, an auditor, or indeed
any of the core DSDM or specialist roles.

Observer

Observers are not allowed to contribute towards the output of the workshop. If they need to take part at all, they should
be Participants. Examples of the use of an Observer are therefore limited but could include someone auditing the
workshop process or the facilitator's ability, or a trainee facilitator who would want to observe the group dynamics
without being part of the group. Observers could also be development or support staff gathering useful background, but
in these cases it should be checked whether they should really be contributing to the session.

Scribe

http://www.dsdm.org/version4/2/public/Facilitated_Workshops.asp (2 of 6) [11-1-2008 16:08:19]


DSDM Public Version 4.2 - Facilitated Workshops

The Scribe records what is happening within the workshop. The role could be held by a co-facilitator, a business
analyst, developer or user so long as the individual has the required understanding of the issues in order to know what
to record. There may be two Scribes in a workshop. For example, one of the Developers might use a CASE tool to
directly model what's being discussed while another scribe takes down the discussion notes for later reference.

Applying the DSDM principles

Facilitated Workshops are like a DSDM project in miniature with defined deliverables in a tight timescale and
empowered users. Early workshops can build the foundation for this approach to continue throughout the project. This
list below shows how the DSDM Principles apply in Facilitated Workshops.

● Active user involvement is imperative. Workshops provide an ideal format for the business to be directly
involved in planning, designing and implementing a solution.

● DSDM teams must be empowered to make decisions. Workshop participants need to be empowered and
have the right level of knowledge and authority within the scope of the workshop, so that decisions can be
made without delay.

● The focus is on frequent delivery of products. It is good practice to structure a workshop so that there are
intermediate deliverables. It helps to order participants' thinking as they progress in logical steps. This enables
them to work towards an ultimate goal and gives them a growing sense of achievement as the workshop
progresses.

● Fitness for purpose is the essential criterion for acceptance of deliverables. The Facilitator checks that
fitness for purpose is achieved by keeping participants focused on delivery against an agreed set of objectives.
They ensure all are involved in decision-making.

● Iterative and incremental prototyping to converge on an accurate business solution. One of the
strengths of workshops is the synergy achieved by the group. Ideas do not have to be born fully developed but
can grow during discussion. In effect, they are being prototyped. It is an ideal setting to try out ideas with all
stakeholders and it is up to the facilitator to provide a safe environment in which this may happen.

● All changes during development are reversible. Information and decisions should be recorded as
necessary by either one or both of the facilitator and scribe so that ideas can be backtracked where necessary.
Often what happens in practice is that an idea or decision is redeveloped.

● Requirements are baselined at a high level. Objectives must be set during the preparation for a workshop.
As the workshop progresses, information is gathered, analysed and interpreted so that discussion can be
effective and a decision reached as a result of an increased understanding of the issues involved.

● Testing is integrated throughout the lifecycle. Because all stakeholders are present, this provides the
quality control approach of testing ideas and deliverables as they are discussed. Participants have the
opportunity to challenge or agree.

● A collaborative and co-operative approach between all stakeholders is essential. The facilitator is
responsible for creating the climate of co-operation within the workshop and enforcing any ground rules for the
group to behave effectively. This is only possible with the co-operation and commitment of all stakeholders. It
is an effective way of achieving either compromise or consensus.

Workshops in the DSDM lifecycle

The list below gives suggestions for the types of workshop that could be run during a project. Some of them could be
combined and become sessions within a longer workshop. Depending on the size and complexity of the problems
being addressed, it may not be necessary to obtain answers and decisions through a formal workshop although
workshop techniques could still be used in an interactive session. The duration of workshops varies from project to
project.

http://www.dsdm.org/version4/2/public/Facilitated_Workshops.asp (3 of 6) [11-1-2008 16:08:19]


DSDM Public Version 4.2 - Facilitated Workshops

Business case Prototype design


Context setting Prototype review
Configuration management strategy Prototyping strategy
Contingency planning Requirements change control
Cutover plans Requirements gathering
Data conversion requirements Risk mitigation planning
Data modelling Roles and responsibilities
Escalation procedure definition Scenario modelling
Estimates Solution options evaluations
Feasibility prototype Suitability/Risk List
Feasibility prototype review Support level definition
Functional modelling System architecture definition
Implementation plan Test plans
Outline planning Test reviews
Development planning Test strategy
Prioritisation Timebox planning
Problem definition Timeboxing strategy
Problem resolution Training needs analysis
Process and roles Training plans
Process modelling User classes
Increment review User documentation requirements

The table below groups workshop types under DSDM Products to show the kind of workshops that may be used to
help deliver them. It is not intended to be an exhaustive or definitive list.

Note: The products are listed by phase but in many instances the workshop will be held well before the product is
finally delivered, e.g. a workshop to determine the training plans for the Trained User Population (a product of the
Implementation phase) should be carried out no later than during the Design and Build Iteration phase.

Phase Product Workshop Type


Feasibility Study Feasibility Report Problem definition
Solution options evaluation
Context setting
Estimating
Business case building
Risk Log Suitability/Risk List
Risk mitigation planning
Feasibility Prototype Prototype design
Prototype review
Outline Plan Outline planning
Business Study Business Area Definition User classes definition
Requirements gathering
Process modelling
Data modelling
Prioritised Requirements List Prioritisation
System Architecture Definition System architecture definition
Development Plan Timeboxing strategy definition
Test strategy definition
Development planning
Roles and responsibilities definition
Risk Log Suitability/Risk List
Risk mitigation planning
Functional Model Iteration general Timebox planning

http://www.dsdm.org/version4/2/public/Facilitated_Workshops.asp (4 of 6) [11-1-2008 16:08:19]


DSDM Public Version 4.2 - Facilitated Workshops

Problem resolution
Functional Model Functional modelling
Process modelling
Data modelling
Scenario modelling
Process and roles cross matching
Functional Prototype Prototype design
Functional Model Review Records Prototype review
Risk Log Risk mitigation planning
Implementation Plan Implementation planning
Data conversion requirements
Training needs analysis
Training plans
Design and Build Iteration general Timebox planning
Risk mitigation planning
Problem resolution
Design Prototype Prototype design
Design Prototype Review Records Prototype review
Tested System Test planning
Test reviews
Test Records Test reviews
Implementation User Documentation User documentation requirements
Support documentation requirements
Trained User Population Training needs analysis
Training plans
Delivered System Cutover plans
Contingency planning
Support level definition
Problem resolution
Increment Review Document Increment review

How to achieve successful workshops

The Facilitator

Workshops should be run by skilled facilitators. They should be impartial to the issues under discussion with no stake
in the outcome. An ineffective facilitator can bias a workshop or at worst lead to its failure. It is a highly skilled role
requiring sensitivity, diplomacy, quick thinking and highly developed communication skills. The role of the Facilitator is
not one to be taken lightly. It is a skilled job and is instrumental in ensuring a workshop is successful. One way to
ensure an effective facilitator is to use one who has been accredited by the Facilitation Accreditation Scheme (FAS).

The role of the Facilitator is to concentrate on the workshop process so that all participants have an equal opportunity
to contribute. The main task of the Facilitator is to deal with all of the "people" aspects of the workshops by getting
participants to work as a team. The Facilitator documents results and decisions on flip-charts, for example, that act as
"group memory". The Facilitator does not contribute to the content of the workshop.

Objectives

http://www.dsdm.org/version4/2/public/Facilitated_Workshops.asp (5 of 6) [11-1-2008 16:08:19]


DSDM Public Version 4.2 - Facilitated Workshops

Objectives should be set for the workshop and checked for their alignment with the scope of the whole project. They
should be set by the Owner and agreed by Participants, but the Facilitator should check for measurability and any
priority.

Scope

Along with the objectives, the scope of the workshop should be defined. This could be described in terms of business
functions, organisational lines or other defining limits.

Participants

Without the right people present for the workshop, a quality solution cannot be reached. The Owner should suggest
who the participants should be but this should be reviewed by the participants themselves. They need to be committed,
empowered and prepared.

Intermediate deliverables

If the workshop is structured so that the road to the final deliverable is staged, it will make it easier to review progress is
in the right direction.

Workshop reports

Workshop outputs should be produced as soon as possible after the workshop. An efficient Scribe, working with a
computer during the sessions, may be able to provide outputs for participants to go away with.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Facilitated_Workshops.asp (6 of 6) [11-1-2008 16:08:19]


DSDM Public Version 4.2 - Modelling techniques

Introduction When Lifecycle People Products Management Development Tailoring Other

Modelling techniques used within DSDM

Introduction

This section describes the application of development and modelling techniques to DSDM business system developments. The
approach taken here is to identify where techniques fit into the DSDM framework, and give an overview of their objectives during
each phase of the lifecycle. This manual cannot carry a detailed consideration of the techniques, as they are many and only a small
subset would be relevant to any particular application.

DSDM divides the development of systems into a number of phases. Each phase is characterised by a change of emphasis, for
example, from Feasibility Study to Business Study, from Business Study to the functional prototyping of the Functional Model
Iteration.

This reflects the commonly held view that a method should provide:

● a structured framework to define the development process

● a set of techniques to model the particular system under development

● a set of procedures and techniques to assist in the derivation of the models

● a set of heuristics to help in the development process

● a common language to communicate design ideas and decisions.

The use of techniques by a DSDM project fall into two main groupings:

● Project techniques: These would be undertaken within any project using DSDM regardless of the specific type of
development or local organisation standards.

● Development techniques: These will vary according to the nature of the project, existing standards, software tool support
and best practice in the marketplace, e.g. object-oriented modelling, website navigation models, business process models.
In this case, a selection of suitable techniques may be chosen due to their definition within specific established standards,
e.g. UML, Soft Systems and CBD.

Project techniques Development Techniques

● Prioritisation (MoSCoW)
● Workshops
● Prototyping
● Timeboxing
● Testing

Hence the aim of this section is to identify and describe the various perspectives from which a system should be modelled and the
system models that may be produced during any DSDM development.

http://www.dsdm.org/version4/2/public/Modelling.asp (1 of 12) [11-1-2008 16:08:32]


DSDM Public Version 4.2 - Modelling techniques

Definition of terminology

The following terms are used throughout this section:

● Model: an abstraction of some characteristic of the business or system, as seen from a particular viewpoint

● Modelling Technique: a means by which a diagrammatic representation of a specific aspect of the system or business
area is developed

● DSDM Product: a collection of one or more models, plus other project information

● DSDM Tool: computer assisted support for one or more techniques, including the building of the final computer system.

Issues when selecting techniques for DSDM

In trying to identify a set of candidate modelling techniques suitable for application to rapid development there are several issues
that need to be borne in mind.

Rapid development

DSDM is concerned with the faster introduction of systems into operational use. Therefore any technique identified should not
impose any undue bureaucratic overheads on the project. Many techniques can cause an unnecessary burden on the project, in
particular when a project moves between differing phases, for example from requirements analysis to logical design.

Many techniques require a change in the way that the system is thought about in different development phases. This means that a
smooth transfer from, say, analysis to design is often difficult. For DSDM, with its inherent iteration and incremental delivery, the
techniques used must be easily understood by user and developer alike and provide the means by which the system can be
developed in a series of refinements. It is important, however, that the chosen modelling techniques should be capable of
representing sufficient detail to assist with the build process, as required.

Communication

One of the main sources of misunderstandings and errors being introduced into a system development is the lack of good
communication between all parties involved in the development process. Each party has its own particular jargon, whether it is the
users, the developers, the technical experts or the managers, which leads to difficult communications. Therefore any technique
must help communications by prompting developers in asking the right questions and by providing users with a means of checking
that the system being developed is what is required. Any technique, together with the resultant model produced, should be easily
understood by the users, at least in outline.

Semantic Gap

The semantic gap refers to the natural difference in the viewpoint taken on any system development between the end users and the
system developers. Naturally the business concerns are with the business tasks and scenarios, and they will talk about the
proposed computer system in these terms. On the other hand, the developers and implementers view the computer system from a
more technical viewpoint. They view it in terms of specific applications, and in terms of databases, communications, computers and
support packages (see figure below).

http://www.dsdm.org/version4/2/public/Modelling.asp (2 of 12) [11-1-2008 16:08:32]


DSDM Public Version 4.2 - Modelling techniques

Computer System Development Communication Problems

These differing viewpoints have historically led to misunderstandings and the development of computer systems, which did not live
up to the users' expectations. The DSDM team can bridge the semantic gap caused by these alternative languages by adopting a
user-centred approach to computer system development and ensuring that, as much as possible, the system is viewed from the
user/business perspective.

One approach that could be considered within a DSDM project is as follows:

● produce a subset of models, each reflecting the perspective of an individual class of user, focusing on their own limited
view of the system. This can be used to support Functional Model Iteration.

● once each view has been refined via a series of functional prototypes, a consolidated model of the various individual views
can be constructed to assist in achieving performance, reducing duplication, encouraging reuse and in subsequent
maintenance. This more detailed technical view is best constructed during Design and Build Iteration, perhaps even after
some early increments of functionality have actually been implemented.

A precursor to the first step, to reduce the risk of developing components which do not integrate together well, is to set screen/
development standards in place and to identify an outline design architecture to act as a guiding framework for the user-focused
developments. This does not need to be a lengthy process, and the key principles may be appropriate for development during a
facilitated workshop.

Modelling the system

Modelling helps the DSDM development team gain a good understanding of the business domain. In understanding the problems,
accurate models can be produced which reflect the realities of the business world. This understanding can be gained by analysing
the problem from different viewpoints. Five common views, which can be used to generate differing levels of models, are:

● the business view, which uses a selection of techniques to understand and interpret the business need and to model the
business from a future perspective. Use of techniques such as business modelling, SWOT analysis and Critical Success
Factors would be included in this view.

● the processing view, which models the system as a set of business processes, or activities, which transform input data
items to output data items. Processes can be either combined to form higher level processes, which in turn can be
combined again to form yet higher level processes, or decomposed into their constituent sub-processes. This corresponds
to the traditional "Why, What and How" type of questioning used during requirements elicitation.

● the data view, which models the business information as a set of objects, or entities, and the relationships that exist
between these objects

● the behavioural view, which models the behavioural characteristics of the system in terms of a set of events and states,
where events cause changes in the states of the system. Events may be generated within or external to the system.

● the user interface view, which models the interactions and interfaces between the system user and the system itself.

http://www.dsdm.org/version4/2/public/Modelling.asp (3 of 12) [11-1-2008 16:08:32]


DSDM Public Version 4.2 - Modelling techniques

Approach to selecting techniques

The approach adopted for identifying suitable techniques for any DSDM development is to concentrate on those techniques that
can be easily understood by business and IT staff alike and which provide a powerful means of communication between all
interested parties. Additional modelling techniques may sometimes be needed purely by the developers, for example to ensure the
integrity and state-consistency of data within the system. Frequently these contain concepts that are not easy for the business staff
to understand. Where they are necessary, the IT professional should consider whether non-IT staff need to be involved in their
development, or whether they are effectively just a part of the build process.

The preferred approach is to consider the development process as a series of refinements of various models of differing aspects of
the computer system being produced. This "model-building" approach is inherent in a number of formal development methods.
However, the DSDM developer must choose which models to use on the basis of their importance in building the right computer
system with the right level of integrity and flexibility.

User-centred development

The techniques selected to support DSDM should initially concentrate on modelling the computer system from a user's perspective.
This approach has been called "User-Centred Development" (UCD), as the techniques are not only easily understood by the user
but they also model concepts familiar to the user. UCD should contain not only the techniques to describe the internal processing
and data aspects of the development, but also a set of techniques for the development of user interfaces, in respect of both
requirements and constraints. User interface techniques are oriented both to the user and to more formal models, and include the
following:

● User Analysis, which provides insight into the range and responsibilities of the end-users of the proposed computer
system and produces a catalogue of the various classes of users, their jobs, skills, access requirements, etc.

● Usability Analysis, which determines the characteristics of the proposed interface design which will satisfy the users' non-
functional requirements

● Task Modelling, which models the various activities to be performed by the users of the system

● Task Scenario Definition, which identifies particular instances of task execution for any given system user

● User Conceptual Modelling (User Object Modelling), which produces a model of the computer system from the user's
perspective that is simply understood by the users of the system. An illustration of such a model is the typical map of the
railway network or Metro, where the detail provided is just sufficient to allow journey-planning, without unnecessary
technical details

● Graphical User Interface Design, which produces the interface for the user which provides support for the identified
tasks, within the project constraints, e.g. using Windows or web technology and navigation

● User Interface Prototyping, which provides an animated view of the proposed design of the user interface.

Finally, these initial user-centred models are refined further by the application of more formal IT-centred design techniques, such as
data, behaviour and process models. These need to be cross-referenced to the user-centred views for consistency. Further
refinements are performed on the formal models of the computer system, until the most detailed model of the system is developed,
namely code itself. The choice of interface modelling techniques is not influenced by the approach taken to modelling the
underlying functionality and data.

The above list of techniques is not meant to be exhaustive, but it provides a carefully selected range of techniques that could be
applied on a DSDM project. Many other techniques can be used. Indeed the approach proposed within DSDM is to capitalise on
existing knowledge and experiences within any user organisation. However, care should be taken to document only what is
absolutely essential and only to the level of detail which enables understanding. The system should be documented in the code (or
at the level at which it is generated). Longer, slower projects, without consistent user involvement, by their very nature tend to need
more interim documentation than DSDM projects.

http://www.dsdm.org/version4/2/public/Modelling.asp (4 of 12) [11-1-2008 16:08:32]


DSDM Public Version 4.2 - Modelling techniques

DSDM Modelling Techniques

A full picture of the business requirements and the developing system can be gained from modelling the perspectives: what, how,
where, who, when and why.

These broadly follow a framework developed by John Zachman, and can be expanded as follows:

The entities and relationships within the business (data and relationships). This
WHAT
gives the data view.
The functions and processes within the business, which transform input to outputs together with
HOW
their interfaces (process and I/O). This gives the processing view.
The locations at which the business operates, considered as nodes and lines
WHERE
(locations and network links).
The people (agents) within the organisation and the work they do (users and tasks). This gives the
WHO
user interface view and the interactions between who, what, how and when.
The events of importance to the business (time and scheduling). This is the
WHEN
behavioural view.
The business view, which models the business objectives and strategy from various perspectives
WHY
and the ways of achieving them (rationale, ends and means).

The interactions between the above six perspectives may also require modelling. For example, the "why" perspective (rationale,
ends and means) could usefully be mapped to the "how" perspective (process and I/O), allowing the business justification for each
process to be confirmed.

The interrelated perspectives for modelling

Rather than model the entire business area at once in these terms, it may be more appropriate to model the aspects needed for the
user to be able to carry out a specific task. This approach is more likely to achieve individual user buy-in. It will ensure that each
user is able to focus on areas which are of most interest to themselves, and in which they have the most knowledge and experience
to contribute.

The user-centred (task-based) view cuts across the above perspectives, providing the answer to all six questions for a specific user
responding to a specific business event. Techniques that support the user-centred view will need to be supported by broader, IT-
centred techniques and models to provide the detailed and integrated view of data, behaviour, and processing necessary to build
the computer system.

http://www.dsdm.org/version4/2/public/Modelling.asp (5 of 12) [11-1-2008 16:08:32]


DSDM Public Version 4.2 - Modelling techniques

Modelling from the User Perspective

In order to avoid duplication of identical components across users, care should be taken to consolidate the individual user views
into a single model supporting the overall system. Once a model has been identified in this way it should be reused as much as
possible throughout the current and subsequent developments. It may be useful to consider maintaining a repository of the
components of these models (either as items of data, process or interface or as integrated objects) in order to encourage a
component-based approach to development. Tool support is strongly recommended to provide the means for achieving this.

Modelling and Abstraction

Modelling usually incorporates some degree of abstraction, which involves omitting certain details from any particular model to
allow clear focus on another particular aspect. Some models may be physical, incorporating aspects of how, when, where, why,
who, what, and some logical, concentrating on just what (what data, what processes, what interactions between these).

For some complex systems, where the non-functional requirements of the system are considered to be a prime risk, additional
models may have to be developed to model such characteristics as security or performance.

Within DSDM some models can be animated, in the form of various prototypes. Some tools can generate working prototypes from
the models, and some will allow models to be extracted from the prototypes themselves. Ideally, tools should be capable of
maintaining the models and prototypes in synchrony with each other.

Modelling the system from different perspectives

The various models can be viewed from the perspectives of different agents or roles at different points in the DSDM lifecycle.

DSDM Lifecycle
DSDM role View Description
Phase
This corresponds to an executive summary for the planner
Feasibility Executive Sponsor/ Visionary or investor and covers the "size and shape" of the system
and cost/benefit analysis
This depicts the business entities and processes
and how they will interact, from the perspective of
Business Study Ambassador User
the owner, who will have to live and work with the
system.
This gives a detailed logical specification from the
Functional Model Iteration Developer
designer's perspective

http://www.dsdm.org/version4/2/public/Modelling.asp (6 of 12) [11-1-2008 16:08:32]


DSDM Public Version 4.2 - Modelling techniques

This gives a detailed physical specification from


the perspective of the builder, who will physically
Design and Build Developer
construct the element. It incorporates the
Iteration Technical Co-ordinator
constraints of tools, technology and other
resources,
Ambassador User This is the documentation and working components of the
Implementation
Advisor User final system.

Perspectives for Modelling within DSDM

Examples of the types of modelling techniques that may be appropriate for each lifecycle phase are given in the DSDM Products
and Models Table. When consulting the table, it should be borne in mind that the Functional Model and Design and Build Iterations
may overlap or even merge, depending on the tools used to build the system.

Using models for the DSDM products

The DSDM development process framework has identified a number of development products to be generated by the end of each
phase of the lifecycle. Of necessity, these products will be a combination of technical information and project objectives and
constraints. The models will provide and present some of the required technical information.

The application of each modelling technique will result in the production of a model, which will form part of a phase's final product
delivery. During any one development phase, a number of techniques may be applicable. Therefore any single DSDM product may
consist of a number of models.

Model development decisions

Models used in software development can be grouped into two main categories:

● Development Models, those models that are produced and required during the development of the system

● Maintenance Models, those models that are required by the maintainers of the Delivered System.

Therefore two categories of DSDM modelling techniques can be defined:

● Core Techniques, which produce key models of the system which will be required to develop and maintain the system

● Support Techniques, which contain supporting information which is usually only required during the development phases.

Generally speaking, at a minimum the models produced by the Core Techniques should be included in all DSDM documentation.
Examples of Core Models are shown in DSDM Products and Models Table.

The decision as to which technique, or set of techniques, will be deployed on any given DSDM development will be the
responsibility of the nominated technical authority for the project. Guidelines for selecting appropriate techniques are provided.

http://www.dsdm.org/version4/2/public/Modelling.asp (7 of 12) [11-1-2008 16:08:32]


DSDM Public Version 4.2 - Modelling techniques

Key models and information required during development and maintenance

Cross-referencing the various Core Models to each other can be very beneficial. For example, assume that the development has
involved the identification of the following:

● Critical Success Factors (Why)

● Functions or Tasks (How)

● Data or Object (What)

Then, cross-referencing the critical success factors to tasks can assist in the prioritisation of functionality and in the identification
and planning of timeboxes. The cross-referencing of tasks and data will help in ensuring that the dependencies between different
tasks are apparent.

Application Development

The table below summarises the DSDM products and suggests the models to be considered during each phase of DSDM. This
should allow the developer to identify appropriate models, whether the approach is structured, object-oriented or some other flavour
of computer systems development good practice. In reality, creation of many of the models may well be started during an earlier
phase in DSDM. This is fine as long as the models have reached the required level of usefulness by the end of the phase indicated
in the table.

Many of the models listed fulfil exactly the same purpose as each other. It would not, in any project, be appropriate to attempt to
develop them all. The techniques should be selected carefully to achieve the objectives stated for each phase, and to produce the
set of products necessary to the project.

The decision as to which specific techniques are used to populate the table for a particular development is influenced by a number
of factors including:

● type of system (e.g. traditional information system, internet/intranet development)


● development environment
● skills/experience of the development team.

For example, those taking an object-oriented approach would populate the table with O-O techniques, backed by their own selected
O-O approach and related tool support. Whatever the approach taken, all areas of the framework should be considered for
coverage by modelling techniques. All are important to the development of a computer system of the appropriate quality and

http://www.dsdm.org/version4/2/public/Modelling.asp (8 of 12) [11-1-2008 16:08:32]


DSDM Public Version 4.2 - Modelling techniques

integrity to support the business, irrespective of the development techniques actually used.

DSDM Products and Models

Objectives of Examples of
Examples of
DSDM DSDM modelling interactions
models
phase products (What, How, Where, that may be
(documentation)
Who, When, Why) appropriate
Feasibility Feasibility Report Scope and Enterprise Core Models: Entity/organisation
Study Model Entity/process
Process/location
Feasibility Prototype Critical success factors Process/organisation
Key business data Context diagram Major event/location
Key business activities
Outline Plan Location/role
Key business locations
Support Models: Objective/
Key people/users
responsibility
Key events
Business vision/scope/ Rich picture
objectives Function hierarchy
plus Network architecture plan
Key interfaces Workflow diagram
Organisation chart

Business Business Area Enterprise Model Core Models: Process/entity


Study Definition Process/location
High-level System Entity relationship Event/location
Model model (high-level) Person role/
System
Business process system role
Architecture CSF/process
Business functions Data/ model
Definition Task/object
relationships/rules High-level data flow
Business events diagrams
Prioritised Business scenarios Critical success factors
Requirements Business architecture Business object model
List (including the System locations Use cases
Non-Functional System users Technical architecture
model
Requirements
List)
Support Models:

Function dependencies
Business scenarios
Task models
Business event model
Business roles
definition

Functional Functional Model System Model Core models: Process/entity


Model Iteration User role/function
Functional Functional Prototypes Logical data model
Prototype Requirements (functional Use cases
and non-functional) Task models
Screens/menus
updated Prioritised Class model
Requirements List Website navigation model

Support Models:

Process dependencies
Scenario analysis
Object interaction /
collaboration diagrams
Object role models

http://www.dsdm.org/version4/2/public/Modelling.asp (9 of 12) [11-1-2008 16:08:32]


DSDM Public Version 4.2 - Modelling techniques

User conceptual model


User interface object model
Screen navigation design
System events
State transition diagram
Object dynamic models

Design and Design Prototype Technology Model Core models: System role/user
Build System event/
Iteration Tested System Components Model Physical data model business event
(includes Physical process model Application/object
documentation) Tested System: Object distribution map Platform/
Network topology application
model User/application
Screens/menus/reports Data structure/
Code
System users and application
locations Data structure/
Technology strategy Support models:
storage
Entity/data
Detailed User Process structure
Models

Implementation User Documentation Functioning, Tested, Core models: Function/access


Documented System control
(including User User/function
Delivered System Physical components
Documentation / Help
(includes structure
Information)
documentation) Help information
User/operational task
descriptions

Support Models:

Physical components
definition
Security architecture

Guidelines for Selecting Techniques

Introduction

The development techniques described in the preceding sections were selected for good pragmatic reasons. However, the
consortium recognises that DSDM will be used in a multitude of different environments where staff are skilled in other techniques.
To assist an organisation in deciding whether the techniques that it uses are appropriate to DSDM, this section contains the set of
principles used by the consortium to evaluate techniques. Therefore when selecting appropriate techniques to support any DSDM
approach to system development, the Development Technique Principles should be considered.

When selecting modelling techniques there are two driving considerations.

● Ensure that the products of techniques that are to be used or reviewed in conjunction with business users are as user-
centred as possible and can be built incrementally throughout the lifecycle, usually through joint working as in facilitated
workshops.
● Wherever possible, models produced should be linked to prototypes via software tool support and ideally capable of being
automated, updated and checked for consistency by these tools.

Development Technique Principles

DSDM must be supported by a software engineering discipline

System development is the art of turning an abstract idea into reality. It is a very complex, interactive and error-prone process. The
concerns are with identifying business problems and finding technical solutions. If these problems occur in the developed system,
then repair will be costly. The principle behind DSDM is to adopt a disciplined engineering approach to system specification and
development. Within this discipline the philosophy is to:

http://www.dsdm.org/version4/2/public/Modelling.asp (10 of 12) [11-1-2008 16:08:32]


DSDM Public Version 4.2 - Modelling techniques

● gain an understanding of the application, before development can start


● develop a series of essential models, and/or prototypes, to help gain this understanding, with each model representing a
different view of the system
● model the system in business terms.

System development can be represented as a continuous process of model development

Business systems are very complex. The main problems facing the DSDM practitioner are the management and control of this
complexity. The generally agreed approach is to describe the system using a set of models that are sufficiently constrained as to
describe the essential features of the system, but at the same time filtering out nonessential information. See the modelling views
required.

Techniques must be able to support the model-building approach at all levels of abstraction

As the DSDM development process evolves, models developed during the Feasibility Study and/or the Business Study will be
refined further throughout the later development phases. Two levels of model are usually developed. These are:

● the logical model, which provides a description of the business and which is independent of any particular technology.

● the physical model, which represents either a currently implemented and operational system or the implementation of the
new system. The model describes physical file stores and processes introduced to meet particular implementation
constraints, for example device handlers.

Techniques must act as a communication aid between users, developers and managers

System development is concerned with developing differing views of the system under consideration and communicating these
representations to all parties involved in the development process. In particular, misunderstandings and ambiguities can be
introduced into the development process by the development team.
Techniques are required which represent the development models in non-ambiguous ways.

Techniques should actively encourage reuse

DSDM is concerned with the faster development of business information systems from start to finish, possibly through a number of
planned increments. One means of achieving this objective is to reuse components between different system developments.

Techniques should therefore be encouraged that produce development components that can be reused between differing
developments. This may lead to DSDM being used in conjunction with a Component-Based Development approach as described in
the White Paper DSDM Component Based Development available via the Webshop.

Techniques must support traces between each level of refinement of the development models

Any system development can be represented as a series of refinements of a set of models of the system under construction. In
order to ensure that the correct system is still being developed, it is important to ensure that each successive refinement of the
models is complete and consistent with respect to relevant previous models. In other words, it must be possible to trace a
component in a model back to its origins and forward to its implementation, whether in this project or a later one.

At the outset of the development it is important to maintain traces between the user requirements and system design components
to ensure all agreed system requirements are being satisfied. In addition, it is recommended that traces be made between user
requirements and system acceptance tests, to ensure good test coverage.

Techniques must produce models that can be incorporated within the DSDM product set

DSDM is a product-based approach to system development. Various development products have been identified. The DSDM
techniques must support the requirements on these DSDM deliverables.

Techniques must be able to incorporate business issues as well as information system issues

DSDM is concerned with identification and provision of technical solutions for business problems. Techniques are required which
can enable the modelling of the business activities and rules and the organisation itself.

Techniques must encourage the involvement of the business users in the development process

DSDM actively encourages the participation of users within the development process. Therefore the system users and designers

http://www.dsdm.org/version4/2/public/Modelling.asp (11 of 12) [11-1-2008 16:08:32]


DSDM Public Version 4.2 - Modelling techniques

alike must easily comprehend any technique selected for development.

Wherever possible, the techniques should provide animated support

The development of prototypes is fundamental to any DSDM development. Differing categories of prototypes exist. Some
prototypes can be built directly from the models developed. Wherever feasible, techniques should be selected for DSDM that
encourage the development of prototypes and/or animated development models.

Techniques must support the non-functional requirements of the system, in addition to the functional modelling

Non-functional requirements represent those system characteristics that determine whether the final system is fit for its intended
purpose.

The techniques must build on best of breed techniques used in traditional development methods

DSDM represents an evolutionary change to system development within any organisation. Many organisations have made
significant investment in time and skills training in existing development methods. Therefore the techniques used within DSDM
should as far as possible build on existing technical knowledge.

The techniques must support both traditional and modern development approaches

System development methods are continually evolving to accommodate changes in technologies. Many methods, first introduced
during the 1970s, are still in use today within organisations. DSDM must be able to support the techniques employed within these
methods.

In addition, newer development methods are used by organisations to help increase productivity on information system
development projects, e.g. object-orientation.

The techniques selected for use within a DSDM project should not force any organisation to adopt a particular system development
approach.

DSDM must support techniques for managing business requirements

Developing a set of consistent, unambiguous business requirements is fundamental to any system development project. During the
period of system development, these requirements often either change or new requirements emerge.

The development of a prototype, or prototypes, during the early phases of a project provides an excellent vehicle for eliciting user
requirements. However, during the system design and build phases, new business requirements may emerge. These requirements
should be captured (as they may form the basis for future system development), but they should not be included in the current
incremental development.

Therefore, on any DSDM development project, requirements are elicited throughout the development process. Hence the
management of these requirements is important in controlling and managing the development process.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Modelling.asp (12 of 12) [11-1-2008 16:08:32]


DSDM Public Version 4.2 - Prototyping

Introduction When Lifecycle People Products Management Development Tailoring Other

Prototyping

Why prototypes are necessary in DSDM

Facilitated workshops define the high-level requirements and strategy, whereas prototypes provide the mechanism
through which users can ensure that the detail of the requirements is correct. The demonstration of a prototype
broadens the users' awareness of the possibilities for the new system and assists them in giving feedback to the
developers. This speeds up the development process and increases confidence that the right system is being built.

A cautionary note is needed here. A prototype is just that - a prototype. A prototype need not be complete and tested
with respect to all its related functional and non-functional requirements. However, DSDM prototypes are intended to
be incremental, in other words they evolve into the final system. Hence, although they will be incomplete in the early
stages, what is present in the prototypes has been built to organisation/project standards.

Categories of prototypes

Four categories of prototype are recommended by DSDM:

● business for demonstrating the business processes being automated

● usability for investigating aspects of the user interface that do not affect functionality

● performance and capacity for ensuring that the system will be able to handle full workloads successfully

● capability/technique for trialling a particular design approach or proving a concept. This is the only category
of prototype that is not expected to evolve into being part of the final solution.

In practice most prototypes will be some combination of the above categories, but for clarity they are treated separately
here.

Business prototypes

Purpose

A business prototype demonstrates the developers' understanding of the functional requirements. The developers can
use this prototype to demonstrate to the users how the final system could work. This will enable the users to better
formulate their real business requirements.

Description

A business prototype is designed only to demonstrate how the business processes are supported by the computer
system. It is not designed to look good or to be particularly user-friendly: nor will secondary functionality, such as error-
checking, necessarily be implemented. It is very important that the users understand the purpose of demonstrating a
business prototype.

How used

A business prototype enables the developers to demonstrate to the users their understanding of the key system
requirements early in the project. This early prototype can then be evolved to cover more of the functionality and to
incorporate non-functional aspects.

Typically, the developer will use a scripted demonstration to ensure that the functionality is demonstrated to best effect.

http://www.dsdm.org/version4/2/public/Prototyping.asp (1 of 7) [11-1-2008 16:08:59]


DSDM Public Version 4.2 - Prototyping

Any discrepancies between the developers' understanding and the business requirements are noted.

Position in the project lifecycle

The first business prototype will be demonstrated as early as possible in the project lifecycle (possibly as early as the
Feasibility Study, but no later than early in the Functional Model Iteration). This will confirm the right system is being
built. First, the fundamental functionality of the system will be demonstrated. Later on, more detailed functional
requirements can be demonstrated and/or other areas can be business prototyped.

The final business prototype will clearly demonstrate to the users how the system will work. It may not look very
pleasing, and have lots of missing functionality, but it will ensure the right system is being built.

Usability prototypes

Purpose

A usability prototype ensures the computer system will be as easy and intuitive to use as possible. Users should enjoy
using the system and it should be obvious how the system can be used. If this is done well, end-users will need less
training before they can use the system effectively, while still having a good understanding of the full capabilities of the
system.

Description

Well-designed computer systems are simple and straightforward, easy to learn and understand, and fun to use. It is
impossible to achieve usability without trying the system out on the users. A usability prototype demonstrates how the
user interacts with the system. It may not actually automate the business process. For example a form is displayed, the
user adds data, but nothing is written to disk. The user can understand how to move around the system and how the
interface works.

How used

A user carries out a number of tasks using the prototype. Any difficulties encountered by the user in achieving those
tasks are noted so that the usability of the system can be improved.

Contrast this with the business prototype where the developer will typically demonstrate the system, to show the
functionality only. A business prototype may be rather user-unfriendly so it is better if the developer removes the need
for a user to learn the interface.

There is a danger of building a usability prototype that cannot be developed into the final system. Developers must take
care not to create any unrealistic expectations.

Position in the project lifecycle

A usability prototype may be built during either the Functional Model Iteration or the Design and Build Iteration, but
there are many benefits in building it as early as possible. For a computer system to be easy to use, it must have a
simple conceptual model that the users can easily understand to help them move around the system.

http://www.dsdm.org/version4/2/public/Prototyping.asp (2 of 7) [11-1-2008 16:08:59]


DSDM Public Version 4.2 - Prototyping

A usability prototype confirms that a good conceptual model has been chosen. If this is not done early on in the project
and the model is wrong, it could adversely affect the design of the system. To reduce the risk of this, a high-level
usability prototype should be built in the Functional Model Iteration or early on in the Design and Build Iteration. More
detailed usability, such as the buttons in a window, can be designed later. If standards for the user interface are chosen
early on, then all programs can be built to the agreed standard, reducing the need for rework. Having a stable
installation Style Guide in place before prototyping commences on any project would help even more.

In practice there are many benefits in combining the business and usability prototypes.

Performance and capacity prototypes

Purpose

A performance and/or capacity prototype ensures that the final computer system will be able to handle the full peak
time workload required. While users may be involved, this category of prototype is typically for the benefit of the
developers.

Description

This prototype deals with the non-functional aspects of the system, such as concurrent transaction volumes, data
loading, overnight batch reports, and month end batch runs, as well as on-line screen performance. Checks will be
made that the target system has enough resources to function adequately in the live environment, even when other
systems are competing for machine resources.

How used

Performance and capacity prototypes are usually developed for the benefit of the developers to ensure the computer
system can meet its desired performance requirements. A test scenario is set up and repeated while changing different
aspects of the system to see how it performs. This process is best automated so that it is easily repeated, but it can be
done manually where a group of users follow a script. The system is monitored to see where any "bottlenecks" occur.

Position in the project lifecycle

This category of prototype is typically used during Design and Build Iteration, after the required functionality has been
determined. Often existing business prototypes will be used for performance testing. Sometimes early in the project
design, the developers may be concerned as to whether a certain piece of functionality can be provided within the
constraints of the machine/network environment. In this case, a performance and capacity prototype can be specially
built to check where the limits might be. Such a prototype might look very different from the final system.

Capability/technique prototypes

Purpose

Developers often have a range of design options and sometimes a choice of tools to use. A capability/technique
prototype tries out a particular design approach or tool to help in choosing between these options.

Description

This category of prototype is typically limited in functionality and is for the benefit of the developers only. The prototype
demonstrates the capabilities and limitations of an approach, a technique or a tool to the developers.

How used

The developer builds a number of prototypes and weighs up the benefits of each technical approach.

Position in the project lifecycle

http://www.dsdm.org/version4/2/public/Prototyping.asp (3 of 7) [11-1-2008 16:08:59]


DSDM Public Version 4.2 - Prototyping

Although selection of a tool is usually made outside any one particular project, a tool capability prototype can be
developed during the Feasibility Study to ensure that the potential technical approach will be soundly based. Later
design capability/technique prototypes are created during the design phase of a project.

Different designs or tools are used to build prototypes that represent the options available to the developer. Each
prototype can then be assessed and the best approach, technique or tool selected.

Prototyping cycles

Each of the development phases (the Functional Model and the Design and Build Iterations) contains iteration through
prototyping. There are basic controls that must be implemented in order to ensure the success of these activities.
These controls are built into a prototyping cycle and are aligned to the cycles within the timebox process.

A prototyping cycle passes through four stages:

● identify prototype
● agree plan
● create prototype
● review prototype.

Identify prototype

Before embarking on building a prototype, what is to be prototyped must be clearly identified. This decision will be
based on the relative priorities given to the functional and non-functional requirements. Having partitioned the
application into possible prototypes, it should be made clear which are the essential parts of each prototype and which
are "extras" through applying the MoSCoW rules. This will limit the scope of activity in each prototyping cycle and
determine the priorities of the developers and users who are building the prototype.

The prototypes can be selected by various criteria: business area, basic processing required, the user groups,
information accessed and the criticality of the processing to the final system.

The results of reviews from previous prototyping cycles provide valuable information when identifying the prototypes to
be developed.

Acceptance criteria for the prototype should be defined in outline before any development takes place in order to lead
the prototyping activity in the most useful direction.

Agree plan

The Development Plan in its schedule of timeboxes sets a limit on the time to be spent on each prototype. The team
must agree the detailed plan for the current prototyping cycle. This includes prototyping the Must Haves first. Lesser
parts will be dealt with if time is available.

The plan should not be allowed to slip unless significant problems arise, e.g. unexpected and dramatic changes in
scope. However, such problems will probably require halting all activity temporarily while the project direction is
rethought.

It is important that the reasons for the time limit are clearly understood by the users. It is their priorities that will identify
the essential components of a prototype. They must be made fully aware that asking for in-depth investigation of a
particular area may mean that they have to decide what other area they can do without.

Create prototype

The prototypes are usually developed collaboratively with users. However later in development where issues such as
performance are being addressed, the users will take a back seat.

Prototypes are not necessarily automated. For instance, early in development, a paper-based storyboard may be more

http://www.dsdm.org/version4/2/public/Prototyping.asp (4 of 7) [11-1-2008 16:08:59]


DSDM Public Version 4.2 - Prototyping

cost-effective and flexible than a fully automated user interface to unexplored functionality. Both business and technical
imperatives will drive the choice of prototyping medium.

Review prototype

Each prototype should be reviewed by the prototyping team (both developers and users) and other interested parties,
where appropriate, (e.g. business analysts and senior user management) to ascertain:

● which objectives it has met successfully


● which areas will have to be included in later development
● which missed areas can be safely postponed (or possibly incorporated in another project) in order to achieve
the project's timescales
● the acceptability of what has been produced.

As well as verifying that the relevant quality criteria have been met, there are two major aims of the review:

● to ensure that the development team are following the right track
● to get the users at all levels to buy in to the completed and future work.

Managing the prototyping process

This section discusses a number of key issues that surface in the management of the prototyping process.

Managing iteration

There are several aspects that have to be managed in order to achieve successful passage through prototyping
activities. These are:

● timeboxing
● change control
● configuration management
● user involvement
● quality assurance of products
● learning from earlier iterations.

Strict adherence to timeboxes ensures that prototyping cycles are not allowed to lose their focus on delivering to the
agreed priorities and that the quality of products is assessed within each timebox.

The procedures for change control must enable change to be introduced quickly and effectively. Over-prescriptive
procedures will slow down development.

In order to be able to backtrack to a previous prototype, strong configuration management must be enforced. For
instance, users may decide that a previous user interface was preferable to the current one or that the functionality is
progressing in the wrong direction to meet their most immediate business needs. In such circumstances, it must be
possible to move backwards smoothly and for all developers to be sure of which version or variant is the current one.

While prototyping without user involvement is impossible, it is important that the users do not drive the development in
the wrong direction through lack of knowledge outside their own sphere of activities. Senior user management must
ensure that a representative set of users is included in prototyping activities.

To ensure that prototyping progresses as fast as possible, it is important that the selected user representatives are
available at all times when they are needed.

By keeping the team consistent throughout development, the team can learn from previous prototyping activity and so
improve the quality of the products and the efficiency of working.

The number of iterations

http://www.dsdm.org/version4/2/public/Prototyping.asp (5 of 7) [11-1-2008 16:08:59]


DSDM Public Version 4.2 - Prototyping

As a general rule, it is recommended that three iterations be allowed - and that they are aligned to the timebox process:

● investigation to see whether the right approach is being taken


● refinement to build on the comments and feedback after the investigative prototype
● consolidation to fully satisfy the objectives of the prototype.

This will mean three prototype cycles leading to a part of the Functional Model and three prototype cycles leading to a
part of the Tested System. However, if the nature of the application and/or the technical environment mean that
functional modelling and design and build merge then the number of prototypes will obviously be reduced. It is
generally advisable to avoid more than three iterations since this can encourage a feeling that things can be left until
later.

Collaboration and consensus

Prototyping requires collaboration and consensus between the developers and the users, as distinct from a contract
negotiated at the start of the process, which can frequently be a source of confrontation between developers and users.

Choosing what to prototype

When producing the Development Plan, the project manager and the team decide where the categories of prototypes
(and any combinations of them) are most appropriate, given the business and technical environment.

Horizontal vs. vertical approach

Having chosen the area to prototype, the DSDM team must first choose whether to build their prototypes in a horizontal
or a vertical way. The choice is simply a way of slicing up the application, so any category of prototype may appear in a
horizontal or a vertical application slice.

With a horizontal approach the whole system is first built at a high level to check how it will cover the scope of the
project. The detail is filled in later. With a vertical approach a section of the computer system is built incrementally until
it is fully understood, then the next section is started.

Both approaches have their advantages and disadvantages. If the whole concept of the system/business area is new
then a horizontal approach may be safer. If the overall structure of the system is well understood but the detail is
unclear then a vertical approach might be better. One advantage of the vertical approach is that it allows incremental
deployment of subsystems for immediate business benefit. Generally, systems will be built using a combination of
horizontal and vertical approaches.

Testing Prototypes

A DSDM prototype serves two different roles:

● it is a partial build of the system that will be delivered


● it is a technique for gathering information to clarify functional or non-functional requirements.

Different test criteria apply depending on the role the prototype is serving:

● To the extent that the prototype represents part of the functionality of the final system, a test pass/fail can be
based on whether or not the test result from the prototype matches an expected result based on the known
requirements.

● To the extent that the prototype is intended to clarify requirements, the criterion for test success or failure is
whether or not the prototype generates the expected information. This is exploratory. The expected
information cannot be predefined in the same way that an expected result can be. The test of the prototype is
being used to expand the knowledge and understanding of the prototype builder. The test is successful if this
is achieved in the area under investigation.

A single prototype may serve in both roles and therefore should be tested against both criteria.

http://www.dsdm.org/version4/2/public/Prototyping.asp (6 of 7) [11-1-2008 16:08:59]


DSDM Public Version 4.2 - Prototyping

In the Functional Model and Design and Build Iteration phases, prototyping generally iterates up to three times in line
with the timeboxing process. The prototypes that are produced can fall within any one of four categories. Prototypes of
all categories can be tested against a mixture of "expected result" and "expected information" criteria.

This iterative lifecycle is summarised in the table below, which shows the categories of prototype and the type of
testing criteria that will tend to apply at each iteration.

Iteration within Timebox


Prototype Category Investigation Refinement Consolidation
Business EI EI/ER ER
Usability EI EI/ER ER
Performance EI EI/ER ER
Capability EI EI EI

Testing criteria for the categories of prototype (EI = Expected Information, ER = Expected Result)

Running prototype demonstrations

In order to get the best value out of prototype demonstrations, the guidelines below should be followed.

The demonstrators should prepare the audience for any prototype demonstration session. The objectives of the
session should be clearly stated together with the known limitations of what will be seen. It can be too easy to assume
that, since one or two users have been involved in the development of a prototype, the rest of the user community are
as knowledgeable about what is going on. Indeed, the Ambassador Users will talk to their colleagues but this
communication channel should not be totally relied upon until working software has been demonstrated to the wider
user population, as it is often difficult to explain what has not been seen - the reason why DSDM is the way it is.

During the session, discussion should be encouraged. Putting the prototype through its paces at such a speed that the
users cannot see what may be expected of them in the future is worse than useless. The development team may come
away from the session feeling reassured that they are following the right track, whereas all that has happened is that
any comments have been stifled.

The Scribe should record all comments made during the demonstration. Otherwise, since the focus of the developers
and the users will be on the behaviour of the prototype, some feedback may be forgotten.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Prototyping.asp (7 of 7) [11-1-2008 16:08:59]


DSDM Public Version 4.2 - Testing

Introduction When Lifecycle People Products Management Development Tailoring Other

Testing

Introduction

The approach to testing in DSDM is that it takes place throughout the lifecycle and is based on good software engineering principles.

Having a time imperative is a key justification for using DSDM. Inevitably this means that DSDM projects are often very important to the
business. As testing is a discipline that improves the quality and reliability of a software system, it is no less important in a DSDM project
than any other.

For further guidance download the Public Access White Paper Practical Testing Guidelines.

DSDM testing principles

Testing in DSDM is based on the following six principles.

Testing Principle Comments


Validation In DSDM, the correctness of test results is judged at all stages of
development against whether the system performs in a way that
meets the business needs, whether or not statements of requirement
The overriding objective of DSDM testing at all stages is
are accurately represented in baseline documents.
to check that a system is fit for business purpose (c.f.
DSDM Principle IV).
In order to achieve a business-orientated measure of fitness for
purpose, the emphasis in validation should be placed on whether the
business process, with its supporting computer system, meets the
objectives for the development.

The validity of business processes should be revisited when new


requirements emerge or when changes are made to the MoSCoW list
or when tradeoffs are made between manual and automated
processes.
Benefit-directed testing Testing is always subject to constraints of time and
resource, and even if there were ample time and resource
Testing the parts of a system that deliver the key available, no amount of testing would be sufficient to locate
business benefits is the highest priority. all errors. Testing should be targeted at the system features
that deliver the key business benefits.
Error-centric testing
Testing can never prove that a computer system works: it can only
The objective of designing and running a test is to find build up a feeling of confidence. Confidence is derived from finding
an error. errors, which are then fixed.
Testing throughout the lifecycle In DSDM there is no "test phase" per se. Software products
and associated design and user documents emerge
Testing must be performed on all products at all throughout the development process. Therefore testing
stages of the DSDM development process. must be planned as an integral part of the iterative lifecycle.
Independent testing
Independent testing is more effective than testing performed by the
author of a DSDM product. The active and constant involvement of
A DSDM product should be tested by someone other users in a DSDM project ensures that an independent perspective can
than its creator. be applied.

http://www.dsdm.org/version4/2/public/Testing.asp (1 of 6) [11-1-2008 16:09:08]


DSDM Public Version 4.2 - Testing

Repeatable testing Although tests may become obsolete as new prototypes


evolve, in many circumstances earlier tests remain useful.
Tests must be repeatable. Rerunning earlier tests is essential where a prototype is
extended. It is always possible that there will be a need to
resurrect an earlier prototype, which means not only
recovering the software and supporting design and user
documentation, but also the test suite that is pertinent to the
configuration being established.

To make a test repeatable, it must be documented. A test


tool can help in building repeatable tests quickly and
efficiently, and can reduce the effort in creating and
maintaining test documentation.

Guidance for those looking to use XP with DSDM

A seventh testing principle is needed when using XP in conjunction with DSDM, "test before you code". Test Driven Development is one
of the XP practices and ensures that tests are specified and used by users and developers early in the development process.

The testing approach

Fitness for business purpose

In a DSDM project, all parties involved must be clear on the approach to be adopted to determine fitness for business purpose. The
computer system, which is part of the business system, is fit for business purpose if it supports the achievement of the organisation's
business objectives and requirements. Business requirements can be thought of as a hierarchy of goals attached to the set of business
processes that deliver the supplier's products or services.

This hierarchical business-driven view replaces the traditional baselines of a Requirements or Functional Specification. It is a better
means of defining what the business system has to do, as it focuses on the outcomes rather than the mechanisms used to meet the goals.

The establishment and baselining of business requirements occurs in the Business Study. Using this as a basis, a hierarchy of business
goals can be created to decide what is needed to achieve a "quality" delivery. The relationship between the business goals and the
computer system is represented in the figure below.

http://www.dsdm.org/version4/2/public/Testing.asp (2 of 6) [11-1-2008 16:09:08]


DSDM Public Version 4.2 - Testing

How business goals translate into tested project deliverables

Prioritisation of testing

As with everything in DSDM, testing activities must be prioritised based on the business goals. Priority should be given to those system
features that support:

● overall business process performance (i.e. business processing cycle times)


● large processing volumes (i.e. very frequently occurring events)
● labour-intensive or complex business tasks
● the human computer interface, particularly if the computer system will be visible to the customer's customer (e.g. a front-office
application, an Internet application or a kiosk).

Risk-Based Testing (RBT)

With the majority of IT projects, testing can be both resource-hungry and expensive. To overcome this, efficient use of time available can
be made through Risk Based Testing.

The premise behind RBT is to base testing on risk as most IT projects are subjected to constraints of time, resource and money. To
maintain the overall quality of the application the test coverage must ensure that the critical business processes are covered.

In essence, RBT is covered by the following steps:

● Identify the risk areas


● Assess the impact of errors
● Plan for RBT
● Reduce the risk of errors

Note: Unit Testing is completed as normal, whereas an RBT approach can be applied to all subsequent stages of testing.

Identify the risk areas

Time is of the essence in DSDM projects and whilst testing and quality should not be compromised it is essential that best use is made of
the time available. Therefore, some form of Risk Based Testing may be appropriate. Risk can be assessed from the moment that the
Suitability/Risk List has been checked.

Risk assessment, as the basis for a Test Strategy and Test plans, is performed by all members of the project team. This will ensure that a
balanced view of the impact of each area of functionality on the business can be obtained.

The project is broken down into relevant functional areas and the risk to the development team and the business is assessed against
certain arbitrary factors; e.g. complexity of processing, usability, knowledge and experience of the developer, consequence of failure, etc.
Once this grading has been undertaken it will then be possible to identify those areas of the system likely to be at high risk and to ensure
that testing resources are concentrated at these points.

Assess the impact of errors

For each function in the application, the impact of failure is assessed. For example, failure of customer facing software has higher impact
than non-production of an internal report (unless, perhaps, the report is produced for the Board). This impact, together with the probability
of risk, can be used as input to Test Planning.

Plan for RBT

Based on the outcome of the risk identification and impact assessment, plans are then developed with test cases prioritised according to
risk and impact. In this way, should the timebox expire before testing is complete, the higher risks will have been addressed first.

Reduce the risk of errors

In addition to prioritisation of tests, other steps will be taken to manage and reduce risk. These may include introduction of inspection
activities on high-risk deliverables/tasks.

Evolutionary validation of the emerging business system

http://www.dsdm.org/version4/2/public/Testing.asp (3 of 6) [11-1-2008 16:09:08]


DSDM Public Version 4.2 - Testing

The business system is first visited in the Business Study. Through the Functional Model and the Design and Build Iterations it evolves to
meet the business requirements. Testing must occur within each iteration. The testing that is applied is either static or dynamic,
depending on the techniques used. The choice of technique is dependent upon the nature of the product and the type of test to be
executed. All documentary products can be subjected to inspection, and all models (including the software prototypes) can be subjected
to dynamic tests.

The final test of the built software will normally be performed in a single test stage combining system test, high-level integration testing
and business (user) testing.

Since DSDM encourages incremental delivery, test procedures need to ensure that system cutover of later increments does not adversely
affect the functionality and data that are already in place. This means that regression testing will be necessary between the development
of vertical prototypes and/or full incremental releases of the business system.

DSDM Phase Testing Activity


Feasibility Study Test the Feasibility Prototype (optional)
Business Study Produce Test Strategy
Unit test
Link test
Functional Model Iteration Business Acceptance Test - against functional requirements only
Usability test
Regression test of unchanged parts of prototypes
Unit test
Link test
System testing
System test against functional and non-functional requirements
Integration test, both internal and external
Performance test
Design and Build Iteration
Volume test
Multi-user test
Break test (i.e. test that the system handles breakdown and
disconnections in the technical infrastructure)
Regression testing of unchanged parts of the prototypes
Business Acceptance test against the business processes
Operational acceptance test against the technical infrastructure
Portability test
Implementation Installation test
Recovery test
Regression test of unchanged parts of the application

Example Testing Activities by Phase

Testing techniques

Generally speaking, testing techniques fall into two categories: static testing and dynamic testing.

Static testing includes all forms of "human" testing (i.e. inspection, reviews, walkthroughs, etc.) as well as analysis of a system's code with
special purpose utility software (i.e. static analysers). This should be applied to the documents that the plans identify as critical to success.

Dynamic testing is mainly aimed at dynamic prototypes, the Tested System and the Delivered System. The dynamic tests to be applied to
the Tested System and the Delivered System should be chosen in the light of the history of prototypes. Where the Delivered System has
evolved from a series of prototypes, the objective of unit and low-level integration testing should have been covered during the production
of prototypes, as well user acceptance testing of the low-level detail.

The testing techniques are not special for systems built using DSDM. The usual combination of structural and functional (i.e. white box
and black box) techniques applies. The choice of test technique, test depth and coverage depends on the technology used to build the
system and project circumstances considered in the light of the DSDM testing principles. However, the level of formality of testing must be
reduced in DSDM because of the short timescales. To see how this is achieved, consider various ways that the formality of testing
manifests itself:

● the documentation of tests


● the formality of the techniques used to design or choose tests
● the control over the test environment and running of tests.

DSDM requires less documentation of tests. A list of conditions to test (test cases) derived from the business and technical objectives is
all that is needed. The list will clarify the test coverage and enable prioritisation of testing to focus on the areas that are most responsible

http://www.dsdm.org/version4/2/public/Testing.asp (4 of 6) [11-1-2008 16:09:08]


DSDM Public Version 4.2 - Testing

for delivering the benefits. The same list can be used to track test pass/fails. Prediction of expected results will, in many cases, not be
documented, but will be based on the judgment of the testers at the time a test is run. In many instances, those testers are likely to be
users. A capture/replay tool can be used to enhance this basic level of documentation.

All formal test design techniques, such as Equivalence Partitioning, can be applied in DSDM. However, because of the constraints on
time, the only practical way to take advantage of these techniques is if the Testers are proficient in using them, which requires good
training and some practical experience of their use.

For many DSDM projects, testing will be a matter of designing tests from the end-user perspective via the visible user interface. User
tests will be based on business scenarios. However, the Testers must also cover the non-visible functionality (e.g. database updates) and
the non-functional characteristics such as performance.

Testing tools

The use of tools to support testing activities will speed up the process and ease the testing burden on a project. Various tools are
discussed in this section that will enable Testers to get on with the job in hand, ensuring the software meets the business objectives
without slowing down the project.

DSDM recommends the use of Static Code Analysers since they provide a degree of "code inspection" almost for free. By eliminating the
wait for third party verification, the project can move forward more quickly.

Since it is likely that more formal test designs will be missing for a large part of testing activities, Dynamic Analysis tools like array bounds
checkers, memory leakage detectors, profilers, etc., should be used. These will detect errors during demonstrations of software that might
otherwise be missed.

A further useful class of testing tools is used for capture and replay. Capture/replay tools can be used to great advantage to help build up
and repeat tests. As the software is being continually modified, the old tests can be rerun to ensure that stable functionality has not been
affected by changes. Properly developed and maintained, the automated tests can be run every night. This helps reduce the effort in
system testing.

However, capture/replay tools are sensitive to changes in the user interface and this often renders them useless. There are two
recommendations to make:

● ensure that the tool chosen has the capacity to ignore cosmetic changes in the user interface (it works based on objects, not
pixels) and has good facilities for maintaining scripts
● consider a prototyping strategy that gets the user interface largely stable as soon as possible. This doesn't mean that the
interface must be frozen at an early stage. It might happen incrementally for different parts of the interface. While the interface is
undergoing major changes, the capture/replay tool (even a very good one) will not be of benefit for repeating tests. The sooner
the prototypes move beyond this stage, the sooner the tool can add benefit to the project.

A capture/replay tool can be employed in testing for another purpose other than repeating tests. It can be used to document tests. In the
absence of test scripts, the quickest way to document tests in a DSDM project is to record them as they are performed, using the capture
facility of the capture/replay tool. The recorded scripts might be repeatable, but what is more important they can be archived as a record
of what testing has taken place.

Prototype Integration System Acceptance Regression


Type of tool
testing testing testing testing testing
test data generators
static analysers
dynamic analysers
test harnesses,
drivers, simulators,
emulators
capture/ replay,
comparator
performance testers
test management

Where testing tools might be used

http://www.dsdm.org/version4/2/public/Testing.asp (5 of 6) [11-1-2008 16:09:08]


DSDM Public Version 4.2 - Testing

Inspections

It is widely accepted that static testing, in the form of inspections, is a very efficient method of identifying defects, with the additional
benefit of improving team learning and speeding up knowledge transfer. An "informal review" is a relatively spontaneous deskcheck of a
product by a peer. A "formal review" is a review which has been planned several days in advance, involves all relevant stakeholders (both
from inside and outside of the team), has clearly assigned roles (e.g. moderator, scribe), and for which each participant prepares in
advance. Obviously there can be types of review in between the two extremes.

Formal reviews tend to identify more defects but are more costly in terms of time and effort. Therefore the DSDM team will need to find
the right balance for the product being inspected depending on the associated risk.

Difficulties and benefits of using inspections in DSDM

There are several difficulties associated with using inspections in DSDM that would not be encountered in a waterfall lifecycle.

Iterative development

Because of the iterative nature of the development and the fact that products are continuously evolving it is difficult to know when a
product is ready for inspection. Inspect too early and the exercise may be wasted as the product may be subject to further dramatic
change. Inspect too late and the defects may have already cascaded down to subsequent products and the benefits will have been lost.
Therefore a product should be considered ready for inspection when it is "finished" for the time being. Note that finished does not
necessarily mean complete as more work on that product may be planned, but it does mean that it is in a stable state.

One of the DSDM principles is that changes are reversible. Clearly, therefore, there will be points in the development of each product
where it is re-baselined. These should be the points where inspections should be considered.

Time constraints

Because of the tight timescales typical of DSDM there will often be a tendency to treat inspections as unaffordable luxuries rather than an
essential tool. However, the following features of DSDM make inspections easier to arrange.

● Collocation: Because the right people are (ideally) located close to each other, and probably already have a dedicated meeting
area it should much easier to plan and organise inspections than in a typical waterfall environment.
● Timeboxing: Despite the fact that time constraints may "squeeze out" inspections they can also have the opposite effect. If a
timebox is due to finish on a certain day, and as time, not functionality, is sacrosanct in DSDM it should be relatively easy to
identify when inspections should occur, and arrange them in advance. The scenario should never arise in DSDM where an
inspection has to be postponed because "the product is not quite ready yet".

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Testing.asp (6 of 6) [11-1-2008 16:09:08]


DSDM Public Version 4.2 - Configuration Management

Introduction When Lifecycle People Products Management Development Tailoring Other

Configuration Management

Introduction

This section contains guidelines for the effective use of configuration management (CM) within a DSDM project and describes why
CM is important.

The following points (some of which are underlying principles) are fundamental to the application of configuration management on a
DSDM project:

● DSDM team members must be empowered to make decisions without bureaucratic overheads
● The CM methods and tools must not hinder development
● Change is inevitable in an iterative development
● All changes during development of an increment are reversible
● Any release/prototype is reproducible, including build information, test scripts and expected results, etc.

Taken together, these principles mean that configuration management must be taken very seriously during DSDM development.

Why Configuration Management is essential

It is the dynamic nature of DSDM, which renders good configuration management essential. Since there are many things happening
at once and products are being delivered at a very fast rate per week, it is imperative that products are strictly controlled as they
achieve completion (whether partial or otherwise).

During prototyping activities, developers may well be working on the same product. This is particularly true of the data structures,
which are common to all. It is therefore necessary for all developers to know that they are working with information that is controlled
and in a known state, and that they can resolve clashes or prevent the possibility of them occurring.

A prototype may go down a blind alley. When this occurs, the ability to return to a known, safe state before setting off again is
essential. This process is tightly coupled to the testing and reproducibility aspects of the project.

It is necessary to be able to carry out regression testing easily on different build states. So the ability to easily identify the versions of
components within the different builds is important.

Human resource aspects of CM

It is imperative that all development staff on the project are trained in the CM procedures and tools to be used. Those who are
concerned with the effective establishment of a CM system need to ensure that the developers are not only trained in the technical
tools themselves but also in both the amount and the kind of information which needs to be recorded about design decisions and
changes to products.

If this is not the case, then some important information, which should be available to all developers, may go unnoticed. CM is above
all else about communication of the status of the system. The developers must be sure of working from a safe foundation whenever
they are taking a component of the system forward or are backtracking to a previous version.

The control of products must be an integral part of the development team activities. Using the more "standard" approach of having a
Librarian who is not part of the team or a CM Manager who is an organisation-wide administrator will endanger the development
process. In DSDM, the control of Configuration Items rests with the development team. In this way, the bottlenecks will be eliminated
that can arise through using a third party who has different priorities from those of the developers.

It is the developers who must make the decisions as to what impact a particular change will have. It is the developers who decide
what the Configuration Items are. It is the developers who decide when a product they are working on is to become a Configuration
Item.

http://www.dsdm.org/version4/2/public/Configuration_Management.asp (1 of 4) [11-1-2008 16:09:32]


DSDM Public Version 4.2 - Configuration Management

That said, all too often when developers are left to their own devices, they will avoid deciding to baseline a product and very little
baselining will take place. Therefore the CM system needs a champion within the project who holds the responsibility for
administering it and resolving any differences of opinion, etc., regarding its use. The CM champion is usually the Technical Co-
ordinator. If the person undertaking that role is divorced from the rest of the development team, a team member should be the
nominated CM champion.

Configuration Management Strategy

A configuration management strategy must be decided and documented in the Development Plan before leaving the Business Study.
It should be visible to all developers. At the very least, the strategy should cover the frequency at which changes will be baselined.
Examples include:

● baselining every prototype before demonstration


● baselining daily, which enables flexibility but can be very onerous
● baselining software items once they have been unit-tested
● baselining at the end of a timebox, which is the absolute minimum and should only be used if short timeboxes are used. If the
project regularly uses timeboxes over three weeks long then this strategy is not recommended.

The other components of the CM strategy include definition of the Configuration Items, the granularity of Configuration Items and the
change control approach. A good guideline for selecting items and granularity is provided by the Modelling Techniques section, which
specifies core models and techniques and support models and techniques. Support models help the developers to get to a certain
place, and then may no longer be required. Core models are required to facilitate longer development and maintenance. Therefore, if
a product either is, or contains, a core model, it must be a Configuration Item. It is also important to allocate responsibility for
Configuration Management, and there needs to be a responsibility within the development teams. The Scribe will normally act as the
"Configuration Librarian" for the team.

The Change Control approach may differ depending on whether the IT supplier is internal or external, but it is important to define the
method of agreement to change early in the project, including the need for impact analysis. This can often be done at small
workshops after prototype and product reviews and tests, where the development team, other users, Project Manager and Technical
Co-ordinator may be present.

Characteristics of CM in DSDM development

CM procedures

CM clerical procedures can be easily automated, although there is always a human element as discussed above.

In order to eliminate any third party clerical element, tool support is essential and ideally should be integrated into the tools being
used for development. Some high-level development tools have built-in CM capabilities. If a choice is available to the DSDM team
then such tools are preferred.

Whatever the CM tool used, it needs to have update and create restrictions, since all the developers should have access to all of the
developing Configuration Items. With the parallel working which is inherent in DSDM, there needs to be a way of locking out
concurrent development of the same Configuration Item, or resolving the clashes that can arise when parallel development occurs.

DSDM Configuration Items

A major question to be answered is what to select as Configuration Items during DSDM development, i.e. what has to be controlled in
order to keep every team member informed of the status of the various products, both intermediate and deliverable. Due to DSDM's
dynamic nature, the answer has to be "as much as possible" without placing too much of an administrative burden on the developers.
Where overload occurs will depend largely on the tools and procedures used, however, some guidance can be provided for the ideal
approach. The choice of Configuration Items will be a balance between what is worth doing, achieving maximum flexibility in
development and the usability of the Configuration Items and the tool.

http://www.dsdm.org/version4/2/public/Configuration_Management.asp (2 of 4) [11-1-2008 16:09:32]


DSDM Public Version 4.2 - Configuration Management

Configuration Management is often only applied at the latter end of development to software products, which will be part of the
Delivered System, and to associated documentation. In this scenario, document control is treated separately. The advice for DSDM
development is to introduce CM as soon as possible in the project and to treat all documents in the same way as software products.
The project should decide what the Configuration Items will be at the start of the project. Certainly all products emanating from each
phase of DSDM should be placed under configuration management before they are taken into the next phase.

Obvious candidates for Configuration Items are the dynamic system models, the prototypes. At the completion of a prototyping cycle,
the relevant prototype should be placed under CM. Therefore, where there are three iterations of prototyping of part of the Functional
Model, each of the three prototypes should be placed under configuration management. The agreed prototype is passed onto the
next phase as a controlled set. A prototype configuration item will consist of the prototype itself, the tests run on it and a record of the
user comments. The user comments are necessary in order to guide the direction of the next phase.

Controlling the configuration of prototypes

The requirements will be incrementally elicited and refined, and all team members must be aware of the latest state of the
requirements. Hence all requirements, even those defined as early on as the DSDM Feasibility Study, should be considered as
Configuration Items.

The high-level requirements should be baselined as soon as possible to ensure that all developers are working towards the same
business objectives. The point at which they are baselined will probably be on acceptance by the user management of the Business
Study products.

The demonstration and review results, etc. serve another useful purpose, which should be controlled using the same CM procedures.
Just as there is a need to demonstrate that any problems have been corrected, it is equally important to ensure that what the users
have agreed to is kept in the developing system and not removed at a later date. However trivial some of these may seem to the
developers, they should be recorded with the requirements.

It is important to be able to do impact analysis on proposed changes, particularly where the change is shared between development
teams. For instance, if the size of a field in the database is changed, the developers should know what reports, programs, screens,
etc. will be affected. This means that each field in the database is potentially a Configuration Item, but the impact analysis can be
done at the table level. Therefore it is a project decision as to the level of granularity to use in CM.

All testing-related products should be placed under CM and linked to the relevant software version. This ensures that as the system
develops incrementally, all previous tests are available for any regression testing which is required. Also, if it is necessary to
backtrack to a previous version, the tests for that version will not have to be reproduced.

It is advisable to keep backup copies of all known build states and to record in the CM system that they exist.

Enabling CM in DSDM projects

It is recommended that a generic CM approach should be developed for use on all DSDM development within an organisation. The
generic approach will be based on the prevailing culture and processes while bearing in mind all the above guidance for CM on a
DSDM project. It should endeavour to be as close as possible to the normal way of working so that developers are not hindered by
too many unfamiliar procedures.

It is recognised that this is not a trivial task. However, failing to do this and attempting to build CM procedures during a DSDM project
will present significant risks to timely and efficient product delivery.

http://www.dsdm.org/version4/2/public/Configuration_Management.asp (3 of 4) [11-1-2008 16:09:32]


DSDM Public Version 4.2 - Configuration Management

Tool support

CM tools are important. However, if effective control can be achieved with paper, then they are not essential. Simple controls can be
achieved through using the directory structures that come with the development and documentation tools. However, the problem to
be addressed here is the need not only to maintain control of a product as it progresses, but also the need to link it horizontally with
related products, which have been produced in another tool as shown in the diagram below.

The tool should have the capability to handle at different levels all Configuration Items, such as objects, functions, documents, the
configuration map, libraries, groups of software components, data structures, etc.

The tool should enable the easy capture of different testing states (including test scripts and data) in order to perform regression
testing on different builds.

Example related Configuration Items

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Configuration_Management.asp (4 of 4) [11-1-2008 16:09:32]


DSDM Public Version 4.2 - Tool Support Environments

Introduction When Lifecycle People Products Management Development Tailoring Other

Tool Support Environments

Introduction

During development, the information generated grows rapidly in size and complexity. Software development tools provide
automated or semi-automated support for various software development techniques. Many tools exist to support modelling
activities. However, tool support is not limited to analysis and design tools but also includes testing tools, debuggers, code
generators, etc.

A good support environment is fundamental to an agile approach. To gain the full benefits of adopting DSDM, the use of
well-engineered development support environments is recommended. In fact, some would go as far as saying that agility
without tool support is impossible.

One of the main problems facing any prospective purchaser of a toolset is selecting the most appropriate environments for
development. There are many similarities between the characteristics of the tools needed for a DSDM development and
those for any other type of development. However, in adopting a DSDM approach, particular requirements for a
computerised support environment have to be satisfied.

The aim of this section is to identify some of the main characteristics of support environments for DSDM. At the outset, it is
worth pointing out that it is unlikely that any single environment exists that will meet all the requirements. Therefore a range
of tools may have to be used on any single development project. However, the range of requirements needs to be stated in
the hope that one day such an environment will exist.

The diagram below shows an ideal integrated DSDM support environment. A number of "Vertical" tools support the various
phases of a DSDM project from Feasibility Study through to Design and Build Iteration, including in some case the option of
reverse engineering some legacy code. "Horizontal" tools provide support throughout the DSDM development process;
such tools include configuration management and process control tools.

Such an environment provides integration at a number of levels:

● Presentation, which provides a common "look and feel" across all tools
● Data, where differing tools share the same data repository
● Control, where one tool can notify and/or initiate actions in other tools
● Platform, where the tool set can be ported onto a number of differing platforms.

An ideal DSDM support environment

http://www.dsdm.org/version4/2/public/Support_Environments.asp (1 of 6) [11-1-2008 16:09:43]


DSDM Public Version 4.2 - Tool Support Environments

When selecting a DSDM support environment, it is important first of all to decide on the development process, then select
the techniques that support that process and then decide on the required level of tool support. Many organisations fail to
achieve the most from their support tools by buying the tools first.

Results from DSDM projects show that significant quality and productivity gains can be achieved from the use of
inexpensive support tools. In particular in the areas of:

● Code and schema generation


● Prototype generation
● Animation
● Automated document generation

There is a White Paper on Package Selection and Deployment available on the Webshop which provides a process to
follow when selecting tools bearing in mind the tools requirements and selection criteria listed below.

DSDM tool support environment requirements

One of the initial problems to be faced when selecting a support environment is the large choice of candidate tools. Time
does not normally allow a detailed evaluation of all tools before a final selection can be made. Therefore guidance is
required to help filter out inferior tools and to concentrate on a few competing front runners.

This section lists the requirements for the ideal DSDM environment. While it is recognised that no one tool or integrated
toolset meets all these requirements, the organisation should use this list as a set of optimum requirements and assess
which ones they can do without, given the prevailing culture.

The support environment must provide support to the DSDM development process

Any support environment must add value to the development value chain. For example, information generated within one
phase of the development process should be easily accessed within later phases. Much effort can be lost on a
development project using support environments, which can hinder the development process.

The support environment should provide support for the selected modelling technique

DSDM has adopted a model-building approach to system development. The various development models are produced by
the application of a number of techniques. The range of development techniques will depend on whether a structured
application development approach or an object-oriented application development approach has been selected.

The various models developed are interrelated and there are dependencies between them. These relationships should be
supported within the support environment.

The user interface within the support environment must take due regard of the needs of the developers when
interacting with the support environment

The look and feel of the user interface of any support environment often determines the usability of the tool. A good user
interface results in a highly productive environment that people will want to use. A poor user interface will result in a toolset
that no one will use.

Usability can be considered under the following categories:

● Productivity What productivity gains can be made in using the tool


● Learnability How easy it is for the user to become familiar with the tool
● User satisfaction How content the user is in using the tool
● Memorability How easy it is for the user to remember how to use the tool
● Error rates The ability of the tool to decrease user-induced errors.

The support environment should be able to import information from other support environments and be able to
export information to other support tools

It is unlikely that any one tool will meet all the DSDM requirements. Therefore development projects will be using a range of
tools supporting differing parts of the DSDM development process.

http://www.dsdm.org/version4/2/public/Support_Environments.asp (2 of 6) [11-1-2008 16:09:43]


DSDM Public Version 4.2 - Tool Support Environments

Information held within the repository of one tool will need to be accessed by other tools. Therefore all DSDM support
environments must conform to an open policy.

The support environment must provide support for user involvement

User involvement and participation are fundamental to the DSDM approach. If business staff are going to be part of the
development team and playing a very proactive role in the development process, then the support environments must be
able to accommodate this work practice.

The support environment must be able to support iterative development

Iteration is part of the DSDM development approach. Each increment may undergo a number of iterations before final
acceptance. A support environment is therefore required that can directly support this way of working. In particular, if after
the latest iteration the new version is unacceptable, reversion to the previous state must be possible.

Configuration management and version control are fundamental facilities in the support

A DSDM development environment can represent a very chaotic situation. Various areas of functionality may be in the
process of development at any point in time. Within each area of development, different cycles of iteration are in progress.

Within a DSDM environment, new products or upgrades to existing products are being generated at a much faster rate than
on traditional projects. Therefore tight control must be maintained over the products.

Therefore, due to this dynamic situation with DSDM, configuration management is vitally important to ensure the project
does not degrade into anarchy. Wherever possible, configuration management should be automated.

The support environment should be based on a controlled repository

The number of products, and the variants of these products, available on a DSDM project is potentially very large. Tool
users performing different development roles will require different access rights to the underlying information. Therefore the
control and management of the information within the project repository has to be strictly controlled. Automated support for
this is highly desirable.

The use of an underlying open repository will greatly improve either the importing or the exporting of information between
differing DSDM support environments.

Components developed on one project must be accessible to other projects

DSDM is concerned with the production and delivery of business solutions that satisfy business needs in short time frames.
One way of achieving this objective is to reuse components developed either on previous projects or earlier in the current
project.

Reuse at the component level has the potential of dramatically reducing development timescales.

The support environment should support a navigation, or browsing, facility

The support environment will be used by a number of developers with differing responsibilities. Infrequent users should be
able to find their way around the design repository with ease and be able to navigate from one area of design to another.
Facilities to enable the browsing for reusable components between development projects should be provided.

The support environment must be able to produce the required project documentation set

Deliverables are as important within a DSDM project as in any other IT project. As DSDM concentrates on the production of
systems in shorter time frames, it is important to produce the required system documentation as quickly as possible.

http://www.dsdm.org/version4/2/public/Support_Environments.asp (3 of 6) [11-1-2008 16:09:43]


DSDM Public Version 4.2 - Tool Support Environments

Ideally, the support environment should be able, without recourse to manual procedures, to generate the documentation for
the DSDM development products. These products range from the initial Feasibility Report through to code generation.

The support environment must be able to produce the final working system

Inherent in DSDM is incremental delivery. As the number of increments increases, so too do the problems associated with
integrating the new version of the system with the existing system.

System cutover must be managed with extreme care. As much support as possible must be provided by the support
environment. This support can take several forms, from providing a fully working system to a prototype of the final system,
which may be exercised and tested before introduction into service.

The support environment must be able to support many tool users working concurrently

As the size of the system under development increases, so too does the size of the development team. In addition, there
may be several teams working on the project at the same time. Therefore support for multi-user operation is a must.

Wherever feasible, the support environment should conform to recognised standards

Standardisation is key to the support environment usability, openness and tool portability.

The support environment should support testing of all products

Testing in DSDM takes place throughout the project lifecycle. Support is required for both static and dynamic testing,
together with regression testing. Consistency checks are required between the various development products. These
checks should not be intrusive and should be under the control of the user.

Support Environment Selection Guidelines

The detailed requirements for support tools will vary from project to project. The following criteria are offered for guidance.
The set will require tailoring to meet project-specific or organisation-specific requirements.

Supplier

The tool supplier should be well established and should have representatives within easy reach of the purchasing
organisation. Other issues include:

● Where has the tool been developed?


● Where is the distributor of the tool?
● What is the likelihood of delivery delays?
● Is an evaluation copy of the tool available?
● Does the supplier offer support consultancy on the tool?
● Are there references from other installations?

Host Environment

The environment on which the tool is hosted must be considered. Factors which must be addressed include:

● Does the tool run on different platforms?


● Can the tool be configured to work over a network of machines?
● Can the tool support multi-user operation, accessing the information concurrently?
● Does the host platform conform to the organisation's current IT Strategy?
● Is the hardware for the tool support environment the same as for the target environment? If not, will additional
hardware have to be bought?

User Support

Consider what support the tool offers to its users, in terms of:

http://www.dsdm.org/version4/2/public/Support_Environments.asp (4 of 6) [11-1-2008 16:09:43]


DSDM Public Version 4.2 - Tool Support Environments

● Does the user interface conform to local house style of interface?


● Is the tool simple to operate, and does it present information in a clear, precise manner?
● What are the response times like under high loading levels?
● What is the quality of the training documentation? Does the tool offer on-line help facilities?
● What length of learning curve is likely to be involved in using the tool? Is the supplier training considered to be
sufficient?
● What is the quality of the user manuals? How much documentation is available?
● Are any reports available on the known bugs within the tool?

Lifecycle Coverage

What facilities does the tool offer to cover the phases in the DSDM development lifecycle? If the tool does not offer total
coverage then additional tools may have to be considered.

Techniques Covered

What support does the tool offer in supporting the proposed DSDM modelling and development techniques?

Integrated Techniques

Are the techniques integrated? That is, does the information defined within one technique have to be re-entered within
another? If a change is made to one model, are modifications to other models performed automatically?

Navigation

Does the tool allow the user to navigate between the differing development models?

Does the tool automatically navigate the user to the problem area of concern?

Does the tool provide browsing of the repository for reusable components?

Consistency Checking

Does the tool ensure consistency of information within the tool database or provide facilities whereby it may be checked?

What consistency checks are performed?

Open Architecture

Is the structure of the database made available to allow the developer to access the underlying database to enable
additional checking and document preparation?

Is the tool open? Can information be exported from the tool and can information be imported into the tool from other
environments?

Can the tool be interfaced to other support tools?

Are there any restrictions on the size of the underlying database, concerning the number or type of data items that can be
entered?

Documentation

Does the tool offer a set of facilities for printing documentation? Issues to be assessed include:

● Is documentation available for each technique, for example, entity descriptions, process descriptions?
● Can the information be generated in a form suitable for interfacing to a word processing system?
● Does the tool support the automatic production of documentation?
● Can differing document layouts and standards be defined?

http://www.dsdm.org/version4/2/public/Support_Environments.asp (5 of 6) [11-1-2008 16:09:43]


DSDM Public Version 4.2 - Tool Support Environments

● Does the tool support automatic code generation?

Change Control

Does the tool offer facilities to cater for different versions of the defined system and provide an audit trail of changes made
to the system?

Testing

Does the tool offer a set of facilities for testing DSDM products? Issues to be assessed include:

● Can the tool support the results of static testing?


● Can the tool support dynamic testing?
● Can the tool support regression testing?

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Support_Environments.asp (6 of 6) [11-1-2008 16:09:43]


DSDM Public Version 4.2 - XP Development Tools and Techniques

Introduction When Lifecycle People Products Management Development Tailoring Other

XP Development Tools and Techniques

Basic XP concept

XP focuses on maximizing the business value delivered to the customer. It does this by early and continuous delivery
of software using emergent design techniques and practices such as test driven development, refactoring and
continuous integration in order to generate continuous feedback.

This section covers those XP practices that could be classed as development techniques.

Assessment of XP

XP is a very powerful way of programming. Many of the XP practices are often regarded as programming 'best
practice'. Therefore individual practices can sit very easily within FMI and/or DBI.

XP has evolved from a culture of small to medium sized projects where I.T. and the business are co-located. DSDM
too was initially used on these kinds of projects but has been shown to be equally successful when projects become
larger or geographically dispersed. Its more formal approach addresses the potential limitations of XP with respect to
scalability and communication and makes it more versatile.

Guidance for those looking to use XP with DSDM

The following offers advice on how to make best of XP Development Practices when applied as part of a DSDM
project. For definitions of the practices follow the hyper-links:

XP Practice Guidance
Pair Programming ● Create an open workspace that encourages open
communication and pairing
● Specifically, desk setup should be suitable for side-by-side
pairing
● Encourage dynamic pairing to ensure high level of knowledge
sharing
● Do not track individual productivity
● Make sure that people 'share the driving'
● Common environment including develoment tools
● Pairs are self-selecting. The coach may assist in choosing
pairings, e.g. to ensure that two inexperienced programmers
have to work together.

Test Driven Development (TDD) ● Create or use an existing unit testing framework
● Learn the basic TDD techniques
● Introduce a Unit Test (UT) metric that is visibly tracked
● Track defects against UT and non-UT code

Refactoring ● Train developers in the concepts of refactoring and the


familiarise them with the code that can be refactored
● Ensure adequate unit test coverage to allow for courage in
refactoring e.g. test driven development
● Investigate tool support
● Supported by test driven development, pairing
● Relates to the backwards arrows in the DSDM Lifecycle. This
can be seen as refactoring.

http://www.dsdm.org/version4/2/public/xp_techniques.asp (1 of 3) [12-1-2008 11:58:12]


DSDM Public Version 4.2 - XP Development Tools and Techniques

Simple Design ● Design should be sufficient for today’s needs


● WAGNI (We aren't going to need it) or YAGNI (You
aren't going to need it)
● DTSTTCPW (Do the simplest thing that could possibly
work)
● Simple acceptance criteria for a simple design
❍ Passes all the unit tests

❍ Contains no duplication

❍ Communicates every intention important to the

programmer.
❍ Contains the fewest possible functions,

methods/classes
● Supported by test driven development and refactoring.

Continuous Integration ● Configuration management is vital


● Create a build environment that allows easy updates and rebuild
● Use an integration machine to serialise integration
● Investigate tool support for continuous integration e.g. Cruise
Control

Collective Code Ownership ● Configuration management should be such that


anybody can make changes to any part of the code
base.
● Evolve and enforce a coding standard.
● Supported by pairing and test driven development

Coding Standard ● Should be evolved and owned by the team.


● Should not be overly burdensome
● Should be specific to environment e.g. logging standards,
naming conventions, emerging architecture

Acceptance/Customer Tests ● Obligatory practice for XP. Closes the loop between
developers and customers understanding of user story.
● Where possible, work should only start when
acceptance criteria have been agreed
● Should be written by the customer and understandable
by the developer
● Quality Assurance can help the customer write the
acceptance tests
● Ideally need to be automated to ensure that they are
continuously run
● The acceptance testing frameworks used by XP
projects tend to be project specific and are evolved by
each project. Often the unit testing framework can be
evolved to address the need for acceptance tests

http://www.dsdm.org/version4/2/public/xp_techniques.asp (2 of 3) [12-1-2008 11:58:12]


DSDM Public Version 4.2 - XP Development Tools and Techniques

User Stories ● Should not capture detail but be sufficient provide a clear basis
for discussion.
● Ideal User Story Characteristics
❍ Terse short description of feature

❍ Should be meaningful to the customer

❍ Should be estimatable

❍ Should be testable

❍ Should be prioritisable

❍ Are written by the customer with input from the

developers

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/xp_techniques.asp (3 of 3) [12-1-2008 11:58:12]


DSDM Public Version 4.2 - Tailoring Overview

Introduction When Lifecycle People Products Management Development Tailoring Other

Overview of Tailoring DSDM to Specific Projects


DSDM provides a project framework that is tailored for each project or for each class of project tackled by an
organisation.

It is also possible to take many paths through the framework depending on the needs of the project. Guidance on
possible Paths through DSDM is provided. The section on paths also highlights key differentiators between DSDM and
waterfall projects to assist in determining the best path through the development process framework for a given project.

This section on tailoring DSDM also provides guidance on three particular classes of project that the Consortium has
found may require a bit more thought than is usually required. These are:

● Small Projects: Even though DSDM is aimed at fast delivery, and is very well suited to small projects, at the
lower end of small, there is often a need to reduce the product set and merge the roles. Guidance is provided
about how to go about this
● Large Projects: When projects are "large" as defined in the Large Projects section, some special consideration
needs to be given to management and control aspects, such as increasing the formality of organisational
structures, procedures, communications, etc., while keeping important DSDM concepts working, such as
empowered teams.
● Hybrid Projects: Not every part of every project will be able to use full DSDM: some parts will not achieve
sufficient affirmative answers in the Suitability/Risk List. These projects will then need to use DSDM and
waterfall techniques in tandem to achieve the best results. The Hybrid Projects section provides guidance
about how to make these two streams of activities work together.

Lastly but by no means least, since DSDM is a framework, it can be used (and has been used) for projects with no IT/
IS element at all. The section on Business Process Change Projects shows how this is achieved.

If you are using XP in conjunction with DSDM the Using DSDM with XP section of the manual describes a combined
lifecycle.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Tailoring_Overview.asp [11-1-2008 15:41:39]


DSDM Public Version 4.2 - Paths through DSDM

Introduction When Lifecycle People Products Management Development Tailoring Other

Paths through DSDM

Introduction

This section shows the various paths that can be taken through the five project phases of the DSDM Development Process
Framework. The assumption is that DSDM is the method of choice and that because of failure to satisfy sufficient critical success
factors within the DSDM Suitability/Risk List that alternative paths are sought through the lifecycle.

The major paths through DSDM can be effectively categorised by their level of iteration and increments as shown in the figure
below. From this, it will be seen that, if a project is to be considered as really using DSDM, it must demonstrate iterative
development. Other factors that differentiate DSDM from waterfall development regardless of paths through the DSDM lifecycle are
shown in the DSDM/Waterfall Differentiators table. These will help decide in the middle ground whether or not a project with
iterative development is waterfall in nature or DSDM.

Paths through DSDM based on the level of increments and iteration

Choosing a path through DSDM

Whenever all the answers of the Suitability/Risk List are either all positive or any risks identified by the suitability filter are
manageable, the iterative and incremental development path through DSDM should be used. This path is essential for real
business-centred development where the need is to satisfy current business requirements and to grow the system for both
imminent and future business and technical requirements.

When there is no budget for development beyond the current expected delivery, then the one-pass iterative development path
should be used. If the project is working to a very tight timescale, this strategy for development is very risky as it may lead to cutting
corners to meet the deadline with no allowance for returning later to tidy things up. This path through the lifecycle may be taken
when building a product. In this case the time to the first customer shipment should not be so tight that a poor quality product is
delivered.

http://www.dsdm.org/version4/2/public/Paths.asp (1 of 5) [11-1-2008 16:10:13]


DSDM Public Version 4.2 - Paths through DSDM

Some technologies are alien to the evolutionary prototyping inherent in DSDM. This can mean that the Functional Model Iteration
and Design and Build Iteration are treated as totally separate phase of development (i.e. they disregard the returning arrow from the
Design and Build Iteration to the Functional Model Iteration. Examples include:

● mainframe systems with no 4GL tool support


● a 4GL toolset which can generate from design models but usability prototypes cannot be generated until all the data is
stable and the processing for the user task is in place
● some packages.

The common feature of all of these is the high cost of going back to rework something which is already in place. If this is the case,
the path for waterfall development with iteration is recommended. The level of user involvement and other differentiators will
determine how near such a style of development is to DSDM.

Where there is negligible advantage to be gained from user involvement, then the waterfall development path without iteration will
probably be preferred.

If the project contains elements where user involvement is advantageous, then the project could opt for taking different paths
through the lifecycle depending on the level of user involvement. Guidance on managing such mixed projects is the section on
Hybrid DSDM and Waterfall Projects.

DSDM/waterfall differentiators

The different paths show that the DSDM lifecycle can be used even though full DSDM is not the approach being used. This can
lead to all sorts of discussions about when a project is DSDM and when it is not. For a project to claim correctly that it is using
DSDM it must be able to demonstrate that:

1. It is applying all the nine principles or if one (and no more than one) is difficult to apply that the project has put in place a
method to minimise the risks involved in its absence.
2. It is using timeboxes, both nested within the Functional Model Iteration and Design and Build Iteration phases and as
delivery milestones.

Note that MoSCoW prioritisation is not stated as a requirement in this definition since timeboxing will not work without the ability to
prioritise requirements, products and activities effectively.

Beyond the definition above and the path chosen through the lifecycle, there are basic differences between the DSDM approach to
development and that found in a waterfall project. The table below shows what the key differentiators are.

Differentiator DSDM project Waterfall project


Requirements level of detail Very high when development starts in the As fully detailed as possible before analysis
Functional Model Iteration. models are produced in the Functional Model
Iteration
When requirements are Throughout the lifecycle for an During the Feasibility and Business
elicited increment to allow for requirements for Studies and subject to formal change
the current and further increments to requests thereafter
be captured
Design activity Design and architectural aspects are All design products from the high-level
produced using the "build then refine" system architecture to individual module
approach based on the starting point of a designs are produced using a "refine then
high-level architecture in the Business Study. build" approach. In other words, the design is
as detailed as possible before it is
implemented.
Designs are investigated rather than
stipulated - at least as far as the development
environment allows flexibility of design
products.
Formal user feedback Very frequent indeed throughout the At predefined points in the lifecycle
on products lifecycle with formal user feedback and on production of near final
occurring at least three times in a versions of products
timebox of 2-6 weeks

Users provide feedback on embryonic


products.

http://www.dsdm.org/version4/2/public/Paths.asp (2 of 5) [11-1-2008 16:10:13]


DSDM Public Version 4.2 - Paths through DSDM

When learning about the In DSDM, learning about the project happens In waterfall projects formal lessons learnt or
project takes place throughout the lifecycle. The end of a often only captured during a Post-
timebox is a key point when lessons learnt Implementation Review for use on later
are fed back into the planning processes for projects. This is reflected in the fact that
future timeboxes within an increment and for changes to waterfall plans are often avoided
future increments. wherever possible.
Empowerment Within given terms of reference for the Typically all decisions are taken by
project all lower level workers on a senior people on the project, such as
project are empowered to make the Project Board, the Project Manager
decisions about the direction that is and the System Designer.
being taken.

Project Boards and Steering


Committees delegate decisions that
they would "normally" take.
Teams Small, self-managing and multifunctional Hierarchically controlled and often based on
a single function, e.g. the programming team
is separate from the analysis team

An individual team may be large in number


Testing Occurs throughout the Functional Unit testing occurs on creation of
Model Iteration and Design and Build coding units. Thereafter testing is
Iteration carried out in phases after the
programming activity is complete.
Users test and accept very small parts
of the system iteratively and User acceptance testing is one of the
incrementally. final phases of testing.
Facilitated workshops Used throughout the lifecycle If used, workshops occur in the Feasibility
and Business Studies and their use is very
limited thereafter.

Iterative and Incremental Development Path

This is the standard path through DSDM.

http://www.dsdm.org/version4/2/public/Paths.asp (3 of 5) [11-1-2008 16:10:13]


DSDM Public Version 4.2 - Paths through DSDM

As in all paths the Feasibility and Business Studies are carried out sequentially and completed before moving into the Functional
Model Iteration.

The models, descriptive text and software of the Functional Model are built up iteratively and incrementally. In this case,
incrementally refers to the fact that the Functional Model may be partial when activities within the project move into the Design and
Build Iteration. The Functional Model for an increment is not complete until the last iteration round the Functional Model Iteration,
which may be after much of the Design and Build Iteration work has been done. The iteration cycle above means that partial
products are tested and accepted before they reach the completion.

Timeboxes can be pure Functional Model Iteration, pure Design and Build Iteration or a mixture of the two. The separation of
concerns is useful but may be deemed unnecessary with some tool environments or when building small systems.

In common with all paths discussed in this paper, the final phase is Implementation, which depends on the completion of the Tested
System. There can be iteration within this phase, when the increment has to be delivered to a large or dispersed user population.
As each delivery is made, lessons are learnt and fed back into the process of the next delivery.

One-pass Iterative Development Path

This path is the same as in iterative and incremental development path but has only one delivery of operational software, i.e. there
is no return for growing the system incrementally towards a fuller solution. This is DSDM the hard way! The flexibility of what is
delivered in DSDM projects needs to be managed very carefully since there is no option of returning to work through a further
increment.

The use of this path requires close management of all activities to be sure of success. Prioritisation using the MoSCoW rules must
be assiduously carried out during the Business Study to the level where activities within timeboxes can be defined. The effort
estimates must be thorough in order to be sure of satisfying all the Must Haves and most of the Should Haves and still have the
flexibility of requirements that will be needed once prototyping is underway. As each new requirement is raised, its relative priority
and effort must be carefully considered. In this style of development, the Won't Haves do not have the subtext of "at this time". They
really are Won't Haves. This means that very clear decisions must be made about what is in scope and what is out and that such
decisions must be made quickly as they arise throughout development in order not to endanger either the effectiveness of the
resulting system or the committed delivery date.

If the system appears to be growing beyond what is manageable with the current team, then new staff will need to be brought in
immediately to ensure delivery. This will introduce the problems of learning curves and team disturbance that DSDM aims to
eliminate, but with a demanding business need, the lack of flexibility in one-pass development means that this must happen.

http://www.dsdm.org/version4/2/public/Paths.asp (4 of 5) [11-1-2008 16:10:13]


DSDM Public Version 4.2 - Paths through DSDM

Waterfall Development Path

In waterfall development, each phase of the DSDM lifecycle is enacted separately from the others. There is no overlap of the
Functional Model Iteration with the Design and Build Iteration.

This style of development can be pure waterfall development where the delivery is performed once at the end of development or it
may return to the Functional Model Iteration for the development of further increments of operational software. The latter is the
traditional approach to phased delivery.

All the usual guidance in DSDM about testing as early as possible applies, but it is recognised that if a project has been forced to
use a waterfall lifecycle because of the nature of the (partial) system then "as early as possible" may in fact be very late in the
development process. Therefore, the Design and Build Iteration may well contain separate phases for the various stages of testing
finishing with User Acceptance Testing and Site Acceptance Testing.

Separate phases with internal iteration

The iteration in this path occurs solely within each phase. Hence the Functional Model is accepted as complete before moving on to
the Design and Build Iteration.

If there are time constraints on the project, timeboxing can be used for the Functional Model Iteration and Design and Build
Iteration, but these are necessarily at a higher granularity than the nested timeboxes in DSDM. The timeboxes will probably be less
focussed on the close feedback loops evident within DSDM projects. This is because the decision to use a waterfall approach
should be taken whenever a project fails too many questions in the Suitability Filter. However if timeboxing is really necessary to
achieve the project's timescales, the decision to use a waterfall lifecycle should be seriously reconsidered.

Separate phases with no iteration

It is possible to follow the DSDM lifecycle with no iteration either within phases or between phases. This is the traditional waterfall
lifecycle with lower levels of user involvement than are predicated by DSDM.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Paths.asp (5 of 5) [11-1-2008 16:10:13]


DSDM Public Version 4.2 - Hybrid Projects

Introduction When Lifecycle People Products Management Development Tailoring Other

Hybrid DSDM and Waterfall Projects

Introduction

Hybrid projects are divided into subsystems that focus on:

● business and user-centred aspects (DSDM)


● the supply of services that must be 100% complete and correct for an increment to be satisfactorily delivered
(waterfall).

Such services are usually well hidden from the users and are unlikely to benefit from the strong user involvement, which is
inherent in DSDM. However, every attempt should be made to make "hidden" parts of the system visible. Consortium
members have successfully used full DSDM on large systems with little or no user interaction through many, varied and
inventive approaches to involving users in back-end process development.

It is assumed that DSDM is the method of choice for the project, and the need to use waterfall arises solely because the
application of the Suitability/Risk List has identified part of the project for which DSDM is unsuitable. It is critically important
that the interfaces between the DSDM part of the project and the waterfall part are carefully defined. The parts should be
decoupled as much as possible to minimise the potential impact of one on the other. It may be difficult for the waterfall part
to accommodate any impact caused by the rate of change inherent in the DSDM part, while the DSDM part may be impacted
by any failure of the waterfall part to achieve promised delivery dates. These impacts must be fully understood at the outset
and carefully monitored thereafter.

The obvious problem is that the delivered functionality from the DSDM part is not set in stone and this may impact the
waterfall part which may:

1. Require functionality from the DSDM part that is not delivered OR


2. Supply functionality to the DSDM part that cannot be used.

Decoupling the two parts as much as possible alleviates these two risks but the risks must be managed.

Further guidance is contained within the White Paper Managing Mixed DSDM and Waterfall Projects available via the
Webshop.

The hybrid approach

http://www.dsdm.org/version4/2/public/Hybrid_Projects.asp (1 of 6) [11-1-2008 16:10:23]


DSDM Public Version 4.2 - Hybrid Projects

There are a number of points at which it may be decided to move a part of the system over from DSDM development to
waterfall development.

1. During the Feasibility Study, it becomes apparent that part of the proposed system would be more suitable to
waterfall development. This is particularly true when integrating a new system with existing systems, for example it
is often known very early on that particular interface elements will need to be in place for the integration to be
successful.
2. At the end of the Business Study, a set of requirements is identified as being most suited to waterfall development.
(An example of this might be a highly complex internal calculation.) There should be sufficient information in the
Business Area Definition, the System Architecture Definition and the Prioritised Requirements List to commence the
System Specification for the identified waterfall element. The Business Area Definition may need more detail added
in order to provide the level of detail required for specifications to be adequate for the waterfall elements.
3. During the Functional Model Iteration or (less likely) the Design and Build Iteration, part of the system may be
identified as more suitable for waterfall development than DSDM. A decision will need to be made to go to either the
System Specification or Detailed Design Specification stages depending upon the nature of the work to be done and
the amount of detail that has been gathered during the Functional Model Iteration. This decision will generally be a
judgment call on the part of the project manager, senior developer/team leader and the Technical Co-ordinator. All
previous work on the identified part should form the basis for further waterfall development.

Identified waterfall elements would be expected to "cut back" at the Design and Build Iteration stage of the subsystem that
would use them. This is necessary so that a well-tested system can become the Delivered System at the appropriate point.
The decision about when the waterfall elements need to be integrated will depend on their MoSCoW priority within the
overall development. They may wait for integration in a later increment if this is possible, in order to minimise delays in
delivery.

The waterfall development will need detailed "mini-specs" to progress safely through the lifecycle. Therefore the
management of the development process may need to be adapted to allow the identified waterfall element(s) to proceed
without the usual full User Requirements Specification, Functional Specification or System Specification that would normally
come before the stage at which they cut over. Each element will have some level of specification at the point at which the
need to cut over is identified.

http://www.dsdm.org/version4/2/public/Hybrid_Projects.asp (2 of 6) [11-1-2008 16:10:23]


DSDM Public Version 4.2 - Hybrid Projects

Issues

Most of the issues relate to the business part of the project team, who will experience the different development cultures
within one project, and to the project manager who must manage the different approaches.

Some of the misunderstandings and "them and us" attitudes that may arise due to the two distinct development approaches
could be alleviated by training the waterfall developers in DSDM, possibly at DSDM awareness days during the early stages
of the project.

It is expected that users will have received DSDM training in order to understand their roles and responsibilities and the way
that the project will depend on their skills and judgment. It may be advisable to make them aware of the way waterfall
projects operate as well.

User Issues

The user issues arise because the users are inside the DSDM development and outside the waterfall development.

● Users may find it difficult to handle the different levels of requirements specification that are requested of them from
the two streams of development. They need to understand why vague requirements are acceptable to one set of
developers and not to the other.
● The differences of user/developer interaction styles could be very marked. The interaction between users and
developers should be co-operative and dynamic for the DSDM team but may necessarily be more defensive on the
part of the waterfall team.
● The users will also have to keep two mindsets as to what they should look for in products. When the users are
initially shown a DSDM prototype, they must accept that it is not perfect. It might be easy to find faults and it may be
buggy - but the point of the evaluation is to think about the business functionality. In contrast, when users see
waterfall elements (often the first time is in acceptance testing), they will be expected to be more concerned with the
errors that they see. The difference in testing and reviewing approaches needs to be made very clear.
● Integrated testing may cause problems. The Ambassador Users should not expect to be able to reject the system at
the end of the project. They should be encouraged to accept the system incrementally, including the waterfall
elements before they are integrated with the DSDM work. This approach to acceptance may be endangered by the
fact that they have to wait for the integration of the two streams of development before a full view of the increment is
possible.
● The users may well see two very different responses to requests for change from the different teams. This can
cause confusion as to procedures, etc. and can cause the users to be unsure as to where their power to influence
the direction of the project starts and finishes.

Project Management Issues

Governing Body

The different approaches to development will require two different styles of communication with the project's governing body.
It is likely that the waterfall part will be reported against the planned activities whereas the DSDM part will be reported
against the requirements. The speed of change in the DSDM work may seem chaotic when reported beside the formal steps
in the waterfall process. Moreover the higher management will probably need to meet more frequently for the DSDM part
than for the waterfall part in order to keep abreast of the status of the project. As always, the project manager will be
responsible for setting and managing their expectations throughout.

Change control

DSDM's approach to small change requests is most often instant and flexible whereas the waterfall approach will necessarily
be more cautious.

The Project Manager needs to be very clear what a change request is: a change to something that has been previously
agreed. This is more obvious in a waterfall project, whereas change is embraced by DSDM. However work that has been
agreed from a much earlier timebox should not be changed without questioning the validity of the change.

Change requests that straddle the boundaries of the DSDM and waterfall teams need very clear procedures. It needs to be
made clear for the project who agrees that such a change request will be accepted and the action that will be taken.

Risk Log

http://www.dsdm.org/version4/2/public/Hybrid_Projects.asp (3 of 6) [11-1-2008 16:10:23]


DSDM Public Version 4.2 - Hybrid Projects

A common Risk Log should be kept, since there are risks that are common to the whole project, risks that are specific to one
or other of the lifecycles and risks that relate to the dependencies between the two.

User involvement

User involvement spilling over from the DSDM team into the waterfall team may cause problems because of the different
personal focus of some waterfall developers. Also waterfall developers have been used to pressure coming from only one
person, their immediate manager. The project manager may find it necessary to "protect" the waterfall developers from what
they could see as intrusion from the users.

Requirements management

Requirements management will be different for the two streams. The methods of traceability, etc. should be the same for
both styles of development, but other areas of managing require modification between the two parts. For instance, the
possibility of having requirements unclear and unsatisfied at the end of a DSDM increment should not cause any problems. It
may be easier to manage the "clean finish" of the waterfall work but this should not force the Project Manager towards
adopting the same approach in the DSDM work.

Testing

Early waterfall testing (i.e. pre-integration of the two parts) may need to use DSDM elements. It is easy to freeze waterfall
code for a period of testing but may not be as easy to freeze the DSDM bits that it needs because of the flexibility that DSDM
requires. Wherever possible the DSDM parts should be left out of any waterfall testing activities.

Configuration Management

It may be necessary to hold separately managed libraries of configuration items in order to allow the more frequent change
that is required in the DSDM part. At the very least a different approach to configuration management is likely, where the
waterfall items are placed under configuration management much later in their development life.

Potential cost overrun

An important decision to make early on in the project is what to do if the waterfall team eats too far into the budget for the
project. DSDM works with a fixed team for a fixed time and budgeting is therefore somewhat easier. However, if the project
funds are dissipated as the waterfall team strives for completion of its 100% solution, the decision has to be made as to
whether or not functionality will be lost from the DSDM stream of development.

DSDM Products

Note: Only those products that will be affected by the hybrid development are shown in the table below.

Product Impact of hybrid working


Feasibility Report If it is known this early in the project that a hybrid approach is necessary, then a risk to address
specifically in the Feasibility Report is that of potential delay to delivery of the proposed system.
This will be due to the nature of the work being undertaken in the waterfall part of the project.

The report should make clear why part of the project is not amenable to DSDM.
Outline Plan The split between the waterfall and DSDM parts of the project should be very clear,
as they will be monitored differently throughout the project
Business Area There is very little impact on the content of the Business Area Definition. However, reference
Definition should be made to the services and calculations that require detailed specification during the
waterfall development.

http://www.dsdm.org/version4/2/public/Hybrid_Projects.asp (4 of 6) [11-1-2008 16:10:23]


DSDM Public Version 4.2 - Hybrid Projects

System This document needs to contain detailed definitions of the interfaces between the
Architecture DSDM and waterfall elements to ensure that they are well understood by both sets
Definition of developers. Particular care should be taken with the "minimum usable interface":
this defines the very least that will be acceptable for the elements to work together
and to provide a system that will provide the minimum usable subset of
requirements (the Must Haves).

If the hybrid nature of the project is discovered after the System Architecture
Definition has been produced, it must be revisited.
Development The Development Plan should show which parts will be developed using DSDM and which will
Plan be developed using a waterfall approach. This includes showing where completed work will be
handed over to the team responsible for testing the integration of the system. It is necessary to
show who is responsible for integration testing and when it will take place.

There may be a need to have a different emphasis in the testing strategy for the two parts in
terms of depth and coverage. If the waterfall approach has been deemed necessary, then it is
very likely that a partial solution is not acceptable for that part of the project. This could mean a
difference in the style of test records to ensure as full coverage as is possible. Every attempt
should be made to keep the test documents, prototype review records as light as possible for the
DSDM work.

The Project Manager should consider including a Service Level Agreement with the waterfall
team leader for delivery of the relevant parts, since it is likely that they will be on the critical path
of the project.
Prioritised There is no impact on the content of the Prioritised Requirements List. There
Requirements should be a common requirements list covering both styles of development. Since
List care should be taken to specify the necessary interfaces, it will be useful to have
them available across the project using the Prioritised Requirements List.
Functional Model The Functional Model should have "stubs" in the diagrams, text and prototypes to allow for future
integration with the waterfall elements.
Implementation Particular attention needs to be paid to the integration of the DSDM and waterfall
Plan elements.
Tested System Where the project is largely DSDM with a smaller waterfall element, it would be a good idea to
include the integration of the waterfall deliverable into a timebox that the DSDM team intends to
devote mainly to testing. The waterfall team should be kept within the project until the
Ambassador User is happy that all elements are working together. That way errors can be
corrected quickly. After that the waterfall team may disband or move onto another project. If that
happens then the DSDM developers need to be confident that they can maintain the system
either by receiving training/documentation from the waterfall developers, or having a
maintenance agreement with them.

The correctness of the interface between the two parts is the responsibility of the Technical Co-
ordinator. If errors arise in the interface, the Technical Co-ordinator will decide who should
correct them. Errors that occur in either the DSDM part or the waterfall part are the responsibility
of the relevant teams.

If the waterfall development suffers slippage, which will endanger the achievement of the Tested
System, it may be necessary to sacrifice more of the DSDM functionality than would otherwise
be necessary. This will enable effort to be transferred from the DSDM stream of work to the
waterfall development.
User Ambassador Users should be able to produce excellent system documentation
Documentation during the project because of their heavy involvement in the DSDM project
element. If the waterfall element requires user documentation too, this could prove
more difficult to achieve. In these circumstances, the project should allow the
Ambassador Users to spend time with the waterfall developers and the new system
so that they can gather all the required information before the final product is
needed for the Implementation stage.

http://www.dsdm.org/version4/2/public/Hybrid_Projects.asp (5 of 6) [11-1-2008 16:10:23]


DSDM Public Version 4.2 - Hybrid Projects

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Hybrid_Projects.asp (6 of 6) [11-1-2008 16:10:23]


DSDM Public Version 4.2 - Large Projects

Introduction When Lifecycle People Products Management Development Tailoring Other

DSDM in Large Projects

Introduction

This section provides some guidance on using DSDM in large projects where a project is defined as large if it has one
or more of the following characteristics:

● more than 5 developers per team


● more than 5 development teams
● more than 1,000 function points per development team
● more than 6 months elapsed time.

However, these measures are not absolute. The key question for an organisation that should be asked is not simply
"How large is it?", but "How large is it in relation to our capability to deliver successfully based on past experience?"

Structure

The following diagram depicts the structure of a large DSDM project and serves to highlight the following:

● the multiplicity of subprojects


● the role of the technical and business architectures in integrating these subprojects;
● the diversity of the subprojects: IS and non-IS related projects, such as Business Process Change Projects
● further diversity is reflected in the IS subprojects represented by one of more DSDM subprojects as well as a
number of 'waterfall' subprojects

http://www.dsdm.org/version4/2/public/Large_Projects.asp (1 of 5) [11-1-2008 16:10:34]


DSDM Public Version 4.2 - Large Projects

* the content and scope of this phase may be reduced by the top-level Feasibility/Business Study

Strategies to adopt

Smaller projects

One of the most practical means of addressing a large project is to break it up into smaller, more manageable
subprojects. The following provides some guidance on how this might be achieved:

● prioritise functions within the application on the basis of the value they are expected to deliver to the business
to produce a 'value stack'
● aim for a low level of functional binding to enable parallelism in development
● use the value stack to drive the Development Plan and to construct work packages, each of which is self-
contained, has a well-defined scope and builds on the previous work packages. Each work package should be
deliverable within in 6 months
● construct a release strategy based on a grouping of work which reflects the implicit value of the work packages
as derived from the value stack and the ability of the business to use the functionality
● assign the work packages to development teams. Adjust the size and profile of individual teams within overall
DSDM guidelines to reflect the needs of the work package. The work packages will provide a clear framework
for project management
● avoid partitioning the project into teams along "traditional" lines, e.g. a team for housekeeping, a team dealing
only with system interfaces. If at all possible, each team should have a visible business-centred deliverable.

Sequential subprojects

If time permits, this is the preferred way of breaking a large project down into smaller more manageable subprojects
Breaking a project down into smaller subprojects which are scheduled to run sequentially offers the following key
advantages:

http://www.dsdm.org/version4/2/public/Large_Projects.asp (2 of 5) [11-1-2008 16:10:34]


DSDM Public Version 4.2 - Large Projects

● team sizes can be kept down to the optimum size for a DSDM project
● as each subproject is implemented there is an opportunity to review the remaining requirements to see if they
are still needed - the way DSDM is meant to operate
● if the same team is retained for subsequent subprojects their experience, both of the business and the project,
will increase with an attendant increase in productivity.

Concurrent subprojects

If time does not permit the project to be broken down into smaller, sequentially phased subprojects, an alternative
approach is to run several subprojects in parallel. Whilst this offers the advantage of compressing the development
timescales there are some disadvantages:

● a larger overall team size (maybe composed of several subteams) is required which introduces problems of
communication and control
● more co-ordination is required between the teams both in the technical aspects of the project and the business
aspects
● the parallel developments may adopt different approaches (that will need to be managed as in the Hybrid
DSDM and Waterfall Projects section).

More formalisation

The relatively small number of people involved in a small DSDM project means that sharing knowledge of how things
should be done can accomplished fairly informally. However, the number of people on a large project demands that
standards, procedures and agreements are formally documented as follows:

● procedures covering project management, change control, configuration management, estimating, escalation,
training, etc.
● standards describing the approach to modelling, development, system test, HCI style, etc.
● agreements/SLAs covering user involvement and availability, response times (to questions or issues raised by
the project team) and escalation.

Organisation

A large project demands increased organisation and co-ordination within teams, between teams and between the
project and the business. This means that:

● The organisation structure must be formalised and include clearly defined roles and responsibilities in order
that it is well understood what each person on the team is doing. A large project may require a number of
temporary or transient organisation structures over its lifetime.
● Careful co-ordination of the larger number of activities and deliverables with complex interdependencies will be
required. This will demand a rigorous approach to progress reporting.
● The continuity both of developers and users over an extended timescale, both within a single project and
across multiple related projects, is a key success factor.
● A DSDM competency centre could be set up that can act as the 'broker of best practice' across the project
● A project office could be established to act as a central point of reference for the project and facilitate
consistency in information sharing.
● A Technical Co-ordination team could be established that creates, monitors and enforces:
❍ the system design

❍ technical standards and procedures

❍ configuration management procedures

❍ testing procedures

● Large teams may need to be set up but this should be avoided: each team within a large project should be
kept within the size recommended by DSDM of six people.

http://www.dsdm.org/version4/2/public/Large_Projects.asp (3 of 5) [11-1-2008 16:10:34]


DSDM Public Version 4.2 - Large Projects

Testing in large projects

Large projects bring with them a number of issues:

● not all teams in the project may be using DSDM, leading to tensions around levels of documentation and co-
ordinating delivery
● teams using timeboxing as a project management discipline will have a "flexible" deliverable, which may give
rise to integration problems
● teams that are using timeboxing may have excess development capacity, which is difficult to use, due to
slippage arising in teams not using timeboxing.

However, the mechanics of testing in large DSDM projects is no different from any other testing in DSDM projects.
However, the scale of the project (principally the number of people on the project and the number of items or
components to be tested) highlights the importance of the following.

Integration testing

On a large project with many subsystems and multiple and frequent deliveries, the importance of integration testing
increases. The size and structure of the team (comprising a number of DSDM development teams) is such that there
may be a need for a separate integration testing team responsible for taking the products from the development teams
and integrating and testing them to form a system increment.

The strategy for testing needs to reflect the importance of integration testing and defines how developed modules are
to be integrated and tested within the overall computer system (parts of which may already be live) such that they
cannot have a destabilising effect on previously released modules. On a large project, the scope of integration test will
potentially include non-software modules, e.g. hardware, training, new organisation structures. It is important to start
integration testing early and to maintain consistency throughout the project. The people involved in test planning should
include project infrastructure and support staff (who will be responsible for the operational system) as well as senior
developers.

A focus on interfaces

To ensure an integrated solution (that is fit for business purpose), it may be necessary to prioritise the interfaces with
legacy or new computer systems under development. These interfaces should be identified in the Business Study (part
of the overall System Architecture Definition), and defined at a level of detail that is useful for all parties concerned with
developing the interface.

Architectures

The importance of architectures is highlighted in integration testing. They provide the basis for validating that
assembled modules and subsystems support the overall business processes and requirements.

Confidence can be built early in the project with architecture testing which seeks to highlight potential problems with the
System Architecture Definition. Although confidence can be built in this way the final capacity and performance cannot
be predicated, which means that architecture testing should evolve along with the business system.

Testing Tools

It is a good idea to establish a "model office" for prototype testing in large projects. Also, the greater volume of testing
required on a large project (principally integration testing) increases the scope for using automated testing tools and
the value which may be derived, especially when applied to regression testing. The test strategy and test planning
should reflect the potential to use such tools.

The level of formality

Notwithstanding the above, the single most important implication of scale on testing is the need for formality. Whereas,
on a smaller DSDM project, a relatively informal approach may work successfully, it will not necessarily be appropriate
on a large project where the increase in scale, principally in terms of people, will demand a higher degree of
formalisation. The key is to apply just sufficient formalisation to overcome the issues of scale without compromising the

http://www.dsdm.org/version4/2/public/Large_Projects.asp (4 of 5) [11-1-2008 16:10:34]


DSDM Public Version 4.2 - Large Projects

principles and benefits of DSDM through over-bureaucracy.

Further guidance is available in the Application of DSDM to Large Projects White Paper available via the Webshop.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Large_Projects.asp (5 of 5) [11-1-2008 16:10:34]


DSDM Public Version 4.2 - Small Projects

Introduction When Lifecycle People Products Management Development Tailoring Other

DSDM in Small Projects

Introduction

This section describes how DSDM could be adapted for a small project lasting a matter of weeks rather than months
with one or two Developer/Testers and one or two Ambassador Users and that is to use a standard technical
infrastructure for the organisation.

DSDM is designed to be lightweight and agile but full DSDM can be too heavy for this sort of project, which can really
benefit from applying the DSDM principles and techniques, such as timeboxing and MoSCoW prioritisation.

All the phases address the usual concerns but are minimal in what they produce, i.e. all the objectives need to be
thought through for each of the phases but the product set will be reduced and minimal.

Warning: This adaptation of the DSDM process is only for very small projects. It must not be taken as a standard short
cut for other DSDM projects. The product set in DSDM is considered to be the smallest possible for successful
implementation of anything other than a very small application.

Phases

The Pre-Project phase will, as usual, determine the need for the project and, if the business case (however informal) is
agreed, allocate resources (people, funding, etc.) to it.

The Feasibility Study and Business Study merge and are completed in approximately one week. Note: It is assumed
that there are no technical architecture issues to address, i.e. the work to be done is based on existing technical
infrastructure and technical standards.

As usual, the end of the Business Study phase is a go/no go decision point for the project.

The Functional Model Iteration and Design and Build Iteration merge to form timeboxes of approximately two weeks in
length that take a set of requirements through from initial investigation through to being tested for non-functional
requirements. These are effectively increments that do not deliver to the organisation but to the project.

The Implementation phase will be a separate activity and its contents will depend on things such as the number of
users to be trained, the amount of data to be migrated, etc.

The Post-Project phase may not include a Post-Implementation Review but all other activities are the same.

Products

The merged Feasibility and Business Studies produce:

● A Study Report which combines the essential elements of the Feasibility Report, Business Area Definition and
System Architecture Definition with everything captured in a few pages. Such a report would need to address:
❍ The business problem or opportunity

❍ The scope of the project (what is in and what is out)

❍ A high-level description of the business processes and the classes of users involved

❍ A list of the development tools and techniques to be used

❍ A high-level description of the target environment in which the Delivered System will operate

❍ The deliverables of the project

❍ The costs of the project

❍ The Suitability/Risk List assessment results

http://www.dsdm.org/version4/2/public/Small_Projects.asp (1 of 2) [11-1-2008 16:10:45]


DSDM Public Version 4.2 - Small Projects

● The Prioritised Requirements List. This should be a very short document on a small project but it is worth
keeping it as a separate document from the Study Report so that it can be updated easily, if necessary.
● Project Plan combining the concerns of the Outline Plan, Development Plan and Implementation Plan and
containing:
❍ Schedule from Functional Model Iteration through to the end of Implementation, including a Timebox

Plan for each timebox


❍ Key dates, such as user reviews, handover to support staff

❍ Project organisation, i.e. who holds each of the DSDM roles (see below)

❍ Delivery date

❍ Progress reporting, the frequency of reports, to whom progress will be reported by whom and how.

This could simply be via timebox closeout meetings if the Visionary and Project Manager are in
attendance.
❍ Reference to any relevant organisational standards and procedures to be used and comments about

how these are to be applied if there are any special considerations


❍ Important dependencies between other parts of the organisation

❍ Who will accept and sign off all deliverables from timeboxes

The combined Functional Model Iteration and Design and Build Iteration will produce:

● The Tested System, including the necessary supporting technical documentation (including Functional Model
diagrams, etc. as necessary)
● User Documentation
● Test Records.

Subsidiary products of this phase of development are:

● Functional Prototypes (These will be created during timeboxes for review by the Ambassador User(s) but the
end product of an individual timebox should be tested beyond the basic processing to include non-functional
aspects.)
● Functional Model Review Records capturing comments on Functional Prototypes. These may be informal
notes.

The Implementation phase will produce the Delivered System and the Trained User Population. The Increment Review
Document can be used as an end-project reporting mechanism, if this is required.

Roles

Many of the roles will be held by one person in a small project, e.g.:

● Executive Sponsor and Visionary (Note: There may well be no need for a separate governing body)
● Project Manager and Team Leader
● Developer, Tester and Scribe

A Facilitator is recommended in the combined Feasibility and Business Studies if there are sufficient views to be
considered. In this case, the Study Report, the Prioritised Requirements List and an initial cut of the Project Plan would
be the workshop deliverables.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Small_Projects.asp (2 of 2) [11-1-2008 16:10:45]


DSDM Public Version 4.2 - Business Process Change Projects

Introduction When Lifecycle People Products Management Development Tailoring Other

DSDM for Business Process Change Projects

Introduction

All projects involve some degree of business change. Even if the overall business processes remain unchanged, the
physical procedures which support them will change. This may be a redistribution of the degree of clerical and
automated activity, or a different approach to the manual activities that the new software supports, and which, in turn, is
supported by new tasks.

The DSDM roles of Executive Sponsor, Visionary and Project Manager are the same. Other key roles, such as Process
Owner, are covered as they arise in the description of the process.

Feasibility Study

The objectives of the Feasibility Study are:

● Assess current business process


● Define problems and opportunities
● Produce the initial Business Case
● Define the scope of the change and prioritise (initial)

The Feasibility Report will show the following:

● that the business process change is possible (as well as desirable)


● the justification for investment in the change
● the objectives, based on the scope of the proposed changes
● the risks of not making the change
● an initial prioritisation of changes
● potential solutions to existing business process issues.

Assess current business process

The business process change project will have been started on the basis of some quantitative or qualitative
assessment of the quality of the current business processes. This could be in terms of the quality of its products, the
satisfaction of the customers, identified bottlenecks in the business process, etc. On a more positive note, the drive for
business process change could be due to the identification of new business opportunities.

The business process change project needs to determine what its starting point is and what will aid or hinder it
reaching its objectives (which will be expressed as high-level prioritised requirements for the business process change
project). The success of the project will depend on the infrastructure to support it. So in order to achieve success it is
necessary to assess what the existing business infrastructure enablers and inhibitors are. These will come from:

● The existing organisational culture and any potential resistance to change contained within that
● The organisational hierarchy which could include restrictive management practices
● Current roles and responsibilities and the enablers and inhibitors with respect to introducing new or changed
roles and responsibilities (e.g. workload or headcount strategy)
● The existing business process controls and how effective and/or respected they are
● Outside influences such as external customers demanding different practices.

Much of this will not be documented but will be understood by the members of the organisation. It will be difficult to
capture all of this information in a reasonable timescale, so the focus needs to be firmly placed on what is important for
the current (and any immediately foreseeable) initiatives. It is important to start small and grow the business process
change over several iterations and increments. However, the difficulty lies in identifying where to start. The following
mindsets cause problems:

http://www.dsdm.org/version4/2/public/Business_Change_Projects.asp (1 of 9) [11-1-2008 16:10:56]


DSDM Public Version 4.2 - Business Process Change Projects

● That's the way we have always done it here


● We've tried this sort of thing before and it hasn't worked
● Changing anything is difficult round here.

So a possible strategy would be to hold a series of workshops preceded by a series of interviews and discussions in
the organisational area under consideration including the relevant stakeholders together with some experienced
newcomers who may be more open-minded. Stakeholders include the workers within the organisational area, their
managers, providers of feedback on business process performance and the business change champions.

Define problems and opportunities

A major result of the workshops would be a list of what needs to change. This would result in the ability to formulate
definitions of the problems and opportunities that the organisation faces.

For each of the problems/opportunities identified, it is necessary to identify a Process Owner who will be responsible
for the actions taken during the business process change project. Their first responsibility will be to participate in the
production of the Business Case. The people assigned to these tasks must be very willing to undertake the work and
firmly believe that it is the right thing to do. Committed leadership is necessary in any change programme.

Produce initial Business Case

The business case should be based on the expected beneficial impact of improvements on the overall business
process or on individual processes. Such improvements should be measurable and if none of the current metrics can
be used to justify the improvement activities, then new metrics should be identified in the business case. The
introduction of any new metrics should be considered as part of the change project and the case for their introduction
included in the business case.

Define the scope of the change and prioritise (initial)

The scope of the work should be decided based on the business strategy.

The aim should be to have something visibly changed in the short term so that the impetus for further change will
become part of the organisational culture. So initial prioritisation will depend on what can be achieved most easily as
well as cost and long-term impact. Many organisations have foundered in their business process change projects
through taking too long-term a view and the staff just see what is happening as "another initiative" that is going
nowhere. If DSDM is being used as the underlying process for improvement then we should see quick improvements
that are incrementally built on.

Business Study

The objectives of the Business Study are:

● Identify and prioritise key processes that need to be changed (the requirements)
● Identify new or changed processes to prototype
● Confirm process owners and process participants
● Establish measured targets (including benefit)
● Plan the next phases

http://www.dsdm.org/version4/2/public/Business_Change_Projects.asp (2 of 9) [11-1-2008 16:10:56]


DSDM Public Version 4.2 - Business Process Change Projects

The main objectives of this phase are the elaboration of the process change requirements identified in the Feasibility
Study, and the development of a plan of deliverables (including any process prototypes and pilots) to be produced and
tested within the project's timescales and costs.

Products

Every care should be taken to keep this document as lightweight as


possible. As always in DSDM, the detail will be in the Functional
Business Area Definition Model and Functional Prototypes.
It should include the current processes if they exist and show where
they are expected to change.
The functional requirements in this product are the new processes or the
changes to be made to existing processes.

When putting together the non-functional requirements for a particular process


improvement, consider the following:

Prioritised Requirements List


● Measurability As the new processes are developed start to identify
measures that can be used to assess their success
● Usability The processes must be easy to use
● Maintainability How easy should it be to change the processes?
● Sustainability of the changed process: will it last?

Includes not only how the processes will be designed, etc. but also
Development Plan the first-cut plan for piloting the change(s) during the Design and
Build Iteration.
System Architecture Definition The high-level blueprint for the new/changed process(es)

Identify and prioritise key processes that need to be improved

The identification and modelling of current practice in an organisation's processes is an important activity in its own
right.

As the next phase will produce prototypes of some of the processes, it is important to ensure that an overview of the
processes and their interfaces with other processes is defined and understood.

The various facts, opinions, beliefs and wishes, relating to the business processes, identified during the Feasibility
Study must now be examined, evaluated and integrated into a prioritised set of change requirements that should result
in real improvements in existing processes, or in new processes.

An estimate of the business benefits and costs to deliver each of the changes will have to be made as an aid to
determining the relative importance of each proposed change and therefore enable the requirements to be prioritised.

In terms of scope, changes can be categorised as:

● Of a general nature: potentially impacting the whole organisation


● Of a specialist nature: impacting only particular business areas.

http://www.dsdm.org/version4/2/public/Business_Change_Projects.asp (3 of 9) [11-1-2008 16:10:56]


DSDM Public Version 4.2 - Business Process Change Projects

The changes are then prioritised using the MoSCoW rules once the importance, scope, costs and benefits have been
thought through.

Identify new or changed processes to prototype

Adopting a prototyping strategy for changed or new processes greatly reduces the risks and costs of introducing the
processes into the relevant business areas. Whenever possible, prototypes that simulate or animate processes should
be considered. These will identify the information requirements of a process, its bottlenecks, how different people are
involved and will clarify the metrics needed for effective process management.

Another useful strategy to adopt is not to attempt to improve activities that add little or no value to a process.
Concentrate on high value activities and processes and deliver them first. DSDM is ideal in distinguishing between
Must Haves and the rest of the requirements.

The method to be used, like everywhere in DSDM is to use facilitated workshops where knowledgeable and
empowered representatives from all affected areas gather to identify, design (high level) and plan the production and
evaluation process of proposed prototypes.

Confirm process owners and process participants

Every process should have a specific Process Owner as stated above. Appointing a Process Owner ensures that a
process' activities and improvements are co-ordinated across the affected business area.

The Process Owner role approximates to the DSDM Team Leader role, but with ongoing responsibility for a business
process rather than limited to the duration of the project. There is likely to be a number of process owners, each
responsible for a part of the development process rather than the whole. Each process owner must have a vested
interest in ensuring the process that they are accountable for operates as efficiently and effectively as possible and
therefore must have a detailed understanding of the process and how it interfaces with other business processes. The
Process Owner must be fully supportive of the changes and of their eventual deployment. The Process Owner leads a
Process Change Team and will be assigned the task of managing the development and implementation of the process
changes. In summary, the Process Owner:

● Acts as the ultimate authority for the process


● Participates in all process (re)design activities
● Liaises with other business areas impacted by the process change
● Ensures the new/changed process is implemented successfully, including ensuring that the training is
appropriate and that the necessary infrastructure is in place
● Monitors all related process change activities
● Manages the implementation of the changes
● Ensures that the changes are communicated to the impacted business areas
● Manages the activities of the Process Change Team.

Establish measured targets

The specific criteria for measurement and targets are defined now and relate to the objectives of the changed process.
The metrics show what needs to be measured to evaluate the effect the change is having. The metrics will be refined
at the same time as the changes to the process itself are refined.

The following are categories of metrics to consider:

● The basic productivity metric is effort, which should be collected at as low a level of detail as is necessary
and practical. The usual issues apply, e.g. include actual effort, collect only what is needed, make collection
simple or automated.
● The other main category is the quality of the process' products, i.e. defects found and corrected. Defects can
be classified according to severity and type, at what stage of the business process they were found (the worst
case is that they were found by the customer), and at what stage they were introduced. In a project where the
aim is to improve the process itself, these defect analyses will be one of the main tools to evaluate the success
of the resulting change.
● There are also more 'soft' measures. For business process change projects, these will often relate to the
views of the people working in the affected business area, e.g. whether they prefer the changed process to the
old one. Such assessments (e.g. using questionnaires) can be used along with the 'hard' metrics in the other

http://www.dsdm.org/version4/2/public/Business_Change_Projects.asp (4 of 9) [11-1-2008 16:10:56]


DSDM Public Version 4.2 - Business Process Change Projects

two categories but are generally not enough on their own to evaluate any benefits achieved.

It is worth noting that when setting measurement targets, it is more useful to set targets on trends rather than on
volumes. Trends measure incremental improvement: for instance, defect rates show trends and also imply the
volumes, e.g. the annual cost and effort of corrective work. Measuring trends is also essential to create an environment
where continuous improvement is encouraged, whilst an endpoint volume implies the organisation can stop improving
once the target is achieved.

Additionally, changing the targets is psychologically unacceptable as it gives people the impression of trying to reach a
moving target set arbitrarily by management.

Plan the next phases

The Development Plan minimises risk during the development of new/changed processes by ensuring that the
supporting infrastructure is established and tested early on in the first few process prototypes (Functional Prototypes in
DSDM terminology).

The Development Plan identifies the areas that are to be involved in the pilot studies. The process may be piloted from
end-to-end. Alternatively, it may be more appropriate to run a pilot solely on a key part of the part of the business
process that is being changed.

The criteria for selecting pilot areas include:

● The business area's manager supports and understands the need for change
● The manager accepts the potentially negative impact of the pilot on normal business activities
● All workers in the pilot area accept that need for the change: anybody in the area who actively opposes the
change will endanger the success of the pilot.

The plan covers the infrastructure needed to support the change pilots, e.g. who will provide support to the business
area and how much effort this will involve.

Prototyping tools

Prototyping tools to use during development of process changes include:

● Paper
● A graphical process management tool
● A CASE tool for process models
● The organisation's Intranet
● Role play
● Video cameras.

One scenario for prototyping is to produce a paper-based description of the business process for use on pilots that
could later form the basis for the creation of IT support systems and for training.

Attention must be paid to the 'scalability' of the prototyped process and to the IT infrastructure required to benefit from
potential integration of workflow and organisation-wide data.

The aim is for an Implementation Plan that lends itself naturally to a gradual evolution and integration of processes via
incremental introduction of business tasks.

Functional Model Iteration

http://www.dsdm.org/version4/2/public/Business_Change_Projects.asp (5 of 9) [11-1-2008 16:10:56]


DSDM Public Version 4.2 - Business Process Change Projects

The objectives of the Functional Model Iteration are to:

● Model the future business process, including participants, process products, tasks and what triggers the
various parts of the process (iteratively with process owners and representative process participants), i.e.
create the Functional Model
● Plan implementation

Once the Feasibility and Business Studies have been conducted for a business process change programme, each
individual business process change project commences with a Functional Model Iteration led by the relevant Process
Owner. This means that sometimes the iteration will be for a major change and sometimes it will be for a smaller,
incremental change. For a major business process change project, the approach discussed here can be followed quite
closely, but for a smaller project only certain elements of the iteration will be required.

Typically, the aim of the first Functional Model Iteration is to enable the major components of the process infrastructure.
Subsequent iterations will fill the gaps in the infrastructure as necessary.

Model the process

It is important that the iterative involvement required of Process Owners and Process Participants with standard use of
facilitated workshops and reviews is maintained just as it would be for any other DSDM project.

The first iteration for a new business process change programme will require a static outline of areas to be improved
covering:

● Processes and interfaces between them, i.e. the overall business model of the area
● Process participants, e.g. job descriptions, skills required
● Triggers, e.g. customer query about an order received
● Mechanisms, e.g. the order processing system
● Outputs, e.g. letter sent to customer

It is important to also consider the creation of processes to verify the improvements. One important process is clearly
that of capturing measurements. It is essential that such measurement processes cause as little disruption to the
business as possible. As far as possible, measures should be derived as by-products of other activities.

All iterations will build or refine a functional prototype of the process(es). A functional prototype will include:

● For each (sub)process, a process definition covering what the process is for, its inputs and outputs, the
activities which make up each process, any specific behaviours e.g. triggers (often temporal) which will affect
the activity and the business role that will carry out the activities
● Links between processes
● The flow of the above elements and cross references between them
● Definition of the outputs
● Working examples of the mechanisms.

The initial approach to modelling processes will depend on personal preference. Some may start with a process flow
diagram and then move to text to describe the detail of processes. Others may start with the text and then create a
diagram to demonstrate the written processes pictorially.

Plan implementation

http://www.dsdm.org/version4/2/public/Business_Change_Projects.asp (6 of 9) [11-1-2008 16:10:56]


DSDM Public Version 4.2 - Business Process Change Projects

An important product of this phase is the Implementation Plan for introducing the redesigned and new processes into
full operation. The choice must lie somewhere between a high-risk 'Big Bang' simultaneous introduction of all changed
processes (no backing out!) and a gradual transition to new processes (less risky but adds to the cost and to
prolonged, frequent disruption of operations).

In addition to how the processes will be put in place and who will be responsible for ensuring the processes continue
effectively, the methods of both communicating the processes and providing any training are planned.

The people who will provide support once the processes are in use is also identified together with estimates of the time
required from them as the business areas take on the process changes.

At least one member from the Process Change Team should be allocated to review a particular process once it is in
operation.

Identify and consider the people implications of the change, such as:

● Skills analysis for new roles


● Skills gap analysis within the organisation
● Training and education programmes
● Changes to measures and rewards.

For successful change, communication is compulsory in order to generate understanding and commitment, to reinforce
messages, to counter fear, and to build community. Hence, an important part of the Implementation Plan is the
Communication Strategy. This is often a significant enough document to be treated separately.

Design and Build Iteration

The objectives of the Design and Build Iteration are:

● Pilot the new or changed process


● Refine the functional prototype up to the point that it can be rolled out to all process participants
● Evaluate the degree of achievement of benefit.

In business process change projects, the Design Prototypes take the form of pilots of the new/changed processes.
Hence the Design Prototyping Review Records consist of the feedback from these pilots. (Note: IS/IT system changes
may be needed. These can be developed either in this project or a parallel DSDM project.)

The piloted (and subsequently amended) process together with any supporting tools and infrastructure form the Tested
System. The feedback from the pilots provides the associated Test Records.

Pilot the process

Apart from those process changes that could be described as cosmetic, changes must be tested in practice. It is
essential that there be commitment for this policy at the highest level and a recognition that there is likely to be a cost
or time penalty, albeit often small.

Piloting the process allows it to be tested and modified if necessary to demonstrate that it meets its requirements.
During this phase, the functional prototype of the process is refined to make it suitable for full, operational use.

Throughout the pilot there has to be commitment from the process participants. They have to feel that it is improving
the business process for them, i.e. making it easier, faster, or delivering better products. The process owner and
visionary have an important role in making clear why the process improvement is being done - particularly if the
reasons are not immediately visible to the participants.

The process participants must be trained in the new processes before they need to apply them.

Refine the model

http://www.dsdm.org/version4/2/public/Business_Change_Projects.asp (7 of 9) [11-1-2008 16:10:56]


DSDM Public Version 4.2 - Business Process Change Projects

This step is very much the same as the 'standard' DSDM. The process participants and process owner review the
prototype and their feedback is used to refine the model. The usual timeboxing and prioritisation rules apply. If the
users identify any major changes, i.e. to the model itself, then it has to go back to the Functional Model Iteration.

Training materials and methods should be piloted alongside the processes themselves. This means that the training
will also be amended, if necessary, based on the pilot project feedback, even if the processes themselves are deemed
successful.

Evaluate the degree of achievement of benefit

The measurements from the pilot projects is collated and analysed. The measurements achieved are compared with
the measurement targets defined during the Business Study. The degree of improvement of the business process
cannot be evaluated unless the metrics from the pilots are compared with metrics collected before the change was
piloted.

Implementation

The objectives of the Implementation phase are:

● Full process roll-out (including training)


● Prove the target was met
● Feedback to continuous improvement

The Delivered System is the change in full operation.

The Trained user Population and Increment Review Document are the same as for standard DSDM.

Roll-out

Activities include:

● Keep everyone informed of how the process change is being introduced


● Prepare training materials for new processes
● Inform process participants about when the change will be implemented
● Provide training in the new processes to coincide with the take up of new processes
● Monitor the use of the new/changed processes and feed back issues as necessary
● Provide consultative support to the process participants
● Capture metrics to monitor effectiveness of new processes
● Feed issues into the next cycle of change

It is important to closely monitor the impact of process changes as early as possible.

Post-Project

A prime vehicle for proving that the planned target was met is to perform a Post Implementation Review. The scope of
the Post Implementation Review must be consistent with the size and level of risk of the change(s). Consider
conducting a review soon after the introduction of the change (a DSDM Increment Review), to assess how successful
the definition and implementation of the change has been. In addition, a further review is desirable, some months after
Implementation, that assesses the actual process change itself and its impact on the business areas that have used it.
However, in the majority of cases, this two-stage approach will be inappropriate.

http://www.dsdm.org/version4/2/public/Business_Change_Projects.asp (8 of 9) [11-1-2008 16:10:56]


DSDM Public Version 4.2 - Business Process Change Projects

What must be reviewed in all cases is the degree to which the improvement target/benefits, defined in the Business
Study, have been achieved.

The results of any review should be fed back into the business plans for further iterative and incremental delivery of
changes.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Business_Change_Projects.asp (9 of 9) [11-1-2008 16:10:56]


DSDM Public Version 4.2 - XP EnterpriseXP-XP and DSDM

Introduction When Lifecycle People Products Management Development Tailoring Other

Using XP with DSDM

Introduction

It is anticipated that this tailoring of DSDM will appeal to organisations that like what XP has to offer in terms of a developer-
focussed approach to software development, whilst wishing to ensure that such developments have the proven rigour and
strong business focus of DSDM to address the potential project size limitations of XP.

The hybrid approach described in the following sections will allow for an XP software development approach within a strong
DSDM framework that takes advantage of the core strengths of both, such as the use of timeboxing and prioritisation of
requirements.

XP practices may be introduced into the development approach if required.

● Active Customer Participation


● A Clear System Metaphor
● Collaborative Planning
● Small System Releases
● Simple Design
● Constant Re-factoring
● Fully Integrated Testing
● Continuous Integration
● Pair Programming
● Agreed Coding Standards
● Collective Code Ownership
● 40 Hour Week

Pre-Project and Feasibility Study Phases

XP assumes that a feasible solution exists and that investment in that solution is justified. In the combined approach these
phases in the DSDM lifecycle should be used to demonstrate that this is at least likely and to justify further investigation.

All of the DSDM products identified in the Feasibility Study should be produced.

Business Study

The products of the Business Study provide the information necessary to justify the development of a solution to meet the
needs of the business. Very importantly, they also provide a solid foundation on which development of the solution is based,
along with an agreement of the way development activities will be managed and controlled.

In some cases, information contained within the DSDM products is simply assumed by the XP process and in some cases it
is considered to be unnecessary. In the combined approach all the products should be delivered. The following paragraphs
describe the key value of some of these products as a foundation for a successful project.

BUSINESS AREA DEFINITION

It is important to realise that it is not the provision of a solution but the use of it that delivers benefit to the business. It
therefore follows that it is necessary to consider not only the solution but also the context in which that solution is to be
placed. The Business Area Definition focuses on the business context for the solution and describes how the proposed
solution will meet the needs of the business. It also seeks to identify the impact the solution will have on the business,
specifically any business process change that may be required. This wider perspective is considered by DSDM to be vital in
both the evolution of the best business solution and also in the successful adoption of it once it has been implemented.

SYSTEM ARCHITECTURE DEFINITION

Within the XP community there is a broad spectrum of opinion of what constitutes "sufficient" up-front design. Like XP, DSDM

http://www.dsdm.org/version4/2/public/DSDM_with_XP.asp (1 of 5) [11-1-2008 16:11:06]


DSDM Public Version 4.2 - XP EnterpriseXP-XP and DSDM

seeks to avoid "big design up front" but the two approaches differ in the way they address design requirements. Regardless
of the approach, the key question is "How much work should be done to define hardware and software architecture before
development starts?" or, alternatively, "How much should the architecture be allowed to emerge during development?"

XP advocates taking a design and putting it into code as soon as possible in order to verify the design and get some
feedback. XP addresses architectural requirements by:

● Postponing architectural decisions for as long as possible, thus minimising the cost of change.
● Bringing the architecturally significant / risky user stories up front.
● Codifying the non-functional requirement e.g. performance, capacity, scalability etc. in automated acceptance tests.

DSDM advocates the construction of functional prototypes in Functional Model Iteration, to demonstrate the required
functionality. These prototypes are then engineered in the Design and Build Iteration to meet non-functional requirements. In
so doing, detailed design of the solution to deal with performance, reliability, scalability etc. is dealt with later rather than
sooner. However, in order to allow sensible evolution of the functional prototype into the design prototype, DSDM does
require the software architecture to be defined in advance to a level of detail sufficient to mitigate risk associated with
meeting the non-functional requirements.

The primary users of the System Architecture Definition (SAD) are the developers, for whom it provides a solid technical
framework in which to evolve an appropriate software solution. Other stakeholders are interested in the definition of the
hardware and supporting software (Operating Systems, Middleware, Databases etc.) required for both development and
target live environments.

PRIORITISED REQUIREMENTS LIST

XP does not explicitly describe a minimum usable subset which makes it difficult to know at the outset when to stop
developing. The PRL addresses this risk and should always be created and baselined before development starts.

The Prioritised Requirements List describes requirements in enough detail to be clear about the scope of the project but not
in enough detail to preclude evolution of the best solution. Importantly, it also defines a minimum subset of requirements that
must be met if the solution is to meet the fundamental needs of the business.

In XP, requirements are expressed in terms of User Stories which have a development estimate associated with them usually
expressed in 'ideal engineering days'. Although requirements expressed in this way are entirely consistent with DSDM, care
needs to be taken to avoid going into too much detail too early. Do enough to adequately describe the full scope of the story
but leave the detail to the Functional Model Iteration.

The use of the MoSCoW prioritisation technique should be applied to the requirements regardless of how they are
expressed.

DEVELOPMENT PLAN

As well as providing guaranteed dates for software releases and a schedule of timeboxes for the delivery of interim products,
the development plan also provides vital information on the way the project will be managed. This covers both the controls
vital to delivery of the solution (e.g. configuration management and testing) but also those controls related to the ongoing
viability of the project (e.g. Risk Management and Change Management). It also provides an important focus on Roles and
Responsibilities the neglect of which has been shown to have disastrous consequences for a project.

http://www.dsdm.org/version4/2/public/DSDM_with_XP.asp (2 of 5) [11-1-2008 16:11:06]


DSDM Public Version 4.2 - XP EnterpriseXP-XP and DSDM

Functional Model Iteration

XP does not differentiate between Functional Modelling activities and Design and Build activities in the same way as DSDM
does although, as one would expect, both are as much of a feature of XP as they are of DSDM.

XP advocates the definition of user requirements in terms of User Stories and Task Cards. DSDM advocates the use of
Functional Prototypes supported by appropriate static models (e.g. data models) to fulfil the same purpose. Both prototypes
and user stories are encompassed by the Functional Model product described by DSDM.

From the software development perspective it is vital that a functional model evolves to define the required system. Whether
the Functional Model contains prototypes, user stories, both, or neither is far less important than the fact that it contains at
least some means of describing the required functionality.

Defining Requirements - User Stories or Prototypes?

DSDM principle IV states that fitness for business purpose is the essential criterion for the acceptance of deliverables. This
principle applies to all products, including the Functional Model, and compliance with this principle dictates simply that we use
the techniques for describing requirements which will lead most effectively to a positive conclusion. In considering Functional
Prototypes and User Stories the best solution may, in many cases, be a combination of both rather than simply one or the
other.

If we are to accept the premise that “a picture paints a thousand words” and that prototypes (like movies) improve on still
images, then there is no better way of illustrating the appearance and behaviour of a system than through the creation of a
working prototype. The creation of a prototype alone, however, is often not sufficient to fully describe a requirement. Under
such circumstances User Stories could be used to most effectively describe usage scenarios and test cases for the
prototypes that cannot be sensibly illustrated through interaction alone. It is likely that such documentation will be extremely
useful in the Design and Build Iteration phase.

XP strongly advocates Test Driven Development, a process whereby the test for the solution (whether in terms of a user
acceptance test or a unit test for code) is written before the development work on that solution starts. Describing tests up
front helps to define the solution, promote simplicity in it and provide a clear criterion by which to judge completeness. Using
Test Driven Development, prototypes created in the Functional Model Iteration can simply be refactored in the Design and
Build Iteration, being engineered for simplicity at the same time as they are refined in terms of functionality and non-functional
qualities such as performance, capacity, security, etc.

As and when necessary, both DSDM and XP make use of 'throw away' prototypes used to explore potential design
approaches. DSDM refer to these as capability/technique prototypes, XP refers to them as spikes.

Design and Build Iteration

The end product of this phase is the Tested System, which describes the system when it is ready to be migrated into
operational use.

Following the DSDM approach, the Tested System evolves from the Functional Prototypes created in FMI as they are refined
to meet the non-functional requirements previously specified, engineering the application so that it demonstrably satisfies
user requirements.

What is involved with the engineering process will depend on how requirements have been defined in the Functional Model
Iteration phase and whether or not Test Driven Development (TDD) has been used.

● Where prototypes have been used to demonstrate requirements, these will be refined and re-factored into Design
Prototypes.
● Requirements expressed as User Stories will, in DSDM language, need to be engineered into Design Prototypes.

Regardless of the original source of the requirements, Design Prototypes containing functionality to meet all the agreed
requirements for the system release will be integrated, tested and become the Tested System.

The XP development cycle can be used to create and refine the Design Prototypes. The first step in the process is to define
the “development tasks” required to refine the prototype. Such tasks will be related to the enhancement of the prototype to
perform a specific testable function. Once defined the development tasks can then be processed thus:

http://www.dsdm.org/version4/2/public/DSDM_with_XP.asp (3 of 5) [11-1-2008 16:11:06]


DSDM Public Version 4.2 - XP EnterpriseXP-XP and DSDM

Refactoring

XP explicitly advocates the linked practices of design simplicity and constant refactoring. Refactoring can be defined as "a
change to the system that leaves its behaviour unchanged but enhances its design".

Simplicity of design is an extremely valuable quality that has been demonstrated to reduce the lifetime cost of the system by
reducing the cost of maintenance and enhancement activities post-project. Similarly, it ensures that continued evolution of
the solution during development is based on the simplest and therefore clearest and most flexible foundation.

Refactoring is shown in the development cycle above as a process distinct from "coding the solution". These two distinct
focuses in the evolution of the system in XP reflect the FMI and DBI focuses in DSDM with the associated controlling forward
and back-arrows. The switch between functional refinement and refactoring in XP would, however, preclude the application of
FMI and DBI as separate physical phases in this context, requiring FMI and DBI activities to be merged into a single
incremental evolution. It is already common practice to combine FMI and DBI activities with a single timebox but XP adds
value here by describing the relationship between them.

Timeboxes

Time-constrained development cycles are a key feature of the DSDM approach as they are with XP. Development-focussed
DSDM timeboxes are recommended to last between two and six weeks and are typically split into three prototyping iterations.
A significant fully integrated, fully tested evolution of either a Functional Prototype or a Design Prototype is normally the major
deliverable of a timebox along with related evolutions of supporting products (e.g. static models, test documentation). As
requirements to be reflected in the end products are prioritised using MoSCoW and estimates are tight, it is not usual to
deliver everything identified within the timebox however, the minimum usable subset (Must Haves) are guaranteed to be
coded and tested by the timebox end date.

At this level DSDM Timeboxes are analogous to XP Iterations. XP Iterations, whilst formally time-constrained, do not work
with requirements prioritised using MoSCoW but with requirements in a simple priority order. As a result it is more difficult to
predict what will (as opposed to what might) be included in the prototype by the end of the Iteration. This apparent weakness
is however compensated for by the fact that the requirements to be met are of a more uniform size in XP and XP Iteration
lengths are fixed. This requires more detailed analysis of the requirements than DSDM expects but actually makes it simpler
to predict what will be delivered, as a more or less uniform number of requirements are delivered in each XP iteration. The
number of requirements delivered is known as Velocity and once baselined by the first few XP iterations, provides a measure
of progress and predictability of what will be delivered in an Increment (or Release to use the XP terminology).

http://www.dsdm.org/version4/2/public/DSDM_with_XP.asp (4 of 5) [11-1-2008 16:11:06]


DSDM Public Version 4.2 - XP EnterpriseXP-XP and DSDM

Both techniques have their advantages and disadvantages so consider trying both and seeing which provides the best fit with
the organisation or project but be careful not to mix the techniques within a single increment/release.

Implementation

No tailoring of the DSDM approach is required when considering the use of XP.

Post-Project

With a little thought, the Delivered System Change Process described by DSDM can be sensibly tailored to reflect the
approach described above.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/DSDM_with_XP.asp (5 of 5) [11-1-2008 16:11:06]


DSDM Public Version 4.2 - Introducing DSDM into an Organisation

Introduction When Lifecycle People Products Management Development Tailoring Other

Introducing DSDM into an Organisation

Cultural change

Every organisation that wants to introduce a new project approach has an existing culture and accepted working
practices. Some of these will work against the effective introduction of DSDM even before the issues of whether a
particular project is appropriate for DSDM are considered or whether the staff have the right skills and tool support.

Issues to consider include:

● How are projects currently staffed? Do developers only work on tasks for which their position/rank/grade in the
organisation fits them? (Junior staff are not allowed near analysis and senior staff have long forgotten their low-
level technical skills through lack of use.)

● Have the project managers in the organisation got "real teeth"? Or do they constantly feel that they are
hampered by rules and regulations that they cannot work round?

● Is the current working environment controlled by consensus or by regulations?

● How amenable are the developers to change in working practices?

● Can people relocate freely to another part of the organisation on a project-by-project basis? Or does the
technical and business environment tie each person to one office/desk?

● Can facilitated workshops be accommodated, e.g. are there suitable rooms that can be commandeered by the
project for uninterrupted work over a matter of days?

● Will operations staff be able to respond quickly to requests for system cutover and support when required?

● Is the development environment suitable for prototyping with users?

If an unsatisfactory answer is given to any of these questions, IT and business management should consider how to
change or work round the situation. Above all they should be convinced that none of the DSDM principles presents an
insurmountable barrier. If the organisation has not been involved in a similar style of project before, it should find
someone who has, to assist in the move to DSDM.

An Outline Plan For Introducing DSDM Into An Organisation

The introduction of DSDM into any organisation must be a carefully planned and managed programme to achieve a
successful outcome. Below is a selected list of key activities for introducing DSDM into an organisation. The list is not
intended to be exhaustive, but rather illustrative of some of the issues that will require addressing.

Firstly, it should be pointed out, that the introduction of DSDM into an organisation should be viewed as a Business
Process Re-engineering exercise on the organisation's system development process. Therefore it should be
considered as any other process re-engineering activity; namely the change to the culture, the people and the
organisation are more important than the technology changes.

Secondly, the DSDM Consortium would recommend an incremental approach. Pilot projects should be selected to
prototype and review the use of DSDM. The key risks need to be identified and managed by iteration and refinement, i.
e. the DSDM approach itself should be used to introduce DSDM into the organisation.

Thirdly, the approach below can be used to introduce DSDM into a particular functional unit, as well as into the whole
organisation.

Further guidance is available in the DSDM White Papers with both Introducing DSDM into an Organisation and DSDM
Organisation Suitability Filter available as public access white papers.

http://www.dsdm.org/version4/2/public/Introducing_DSDM.asp (1 of 5) [11-1-2008 16:11:16]


DSDM Public Version 4.2 - Introducing DSDM into an Organisation

Feasibility Study

● Qualify the organisation


Identify the type of organisation you are dealing with. This will help to determine some of the potential risks
and pitfalls you are likely to encounter later.

● Determine whether the organisation has the right culture


DSDM requires a fundamental shift in thinking for system development.

● Empowerment is key
Does the culture within the organisation encourage risk taking? Is the organisation prepared to change? The
success of DSDM is pivotal on its underlying principles. Is the organisation prepared to accept them? A short
culture audit may be necessary.

● Identify key problem areas where DSDM would be most easily applicable
What are the main problems facing the business? Identify the key business needs. This will help to sell DSDM
later.

● Identify the DSDM Champion(s)


The key to any successful DSDM introduction is the identification of a senior manager as a DSDM Champion,
preferably a board-level director. You must ensure the champion is a real champion and not likely to disappear
if difficult decisions are to be made. The champion should be acting as your coach. Ideally, you should have
both a business champion and an IT one.

● Educate the DSDM Champion


Ensure the identified champion is knowledgeable in DSDM and is aware of the consequences. Check the
strength of initial DSDM acceptance by 'acid tests' on the stated level of commitment. These could include
willingness to:
❍ Train people in DSDM

❍ Tailor training to meet organisation specific needs

❍ Attend a DSDM Executive Briefing.

● Produce strategy for way forward


The options for introducing DSDM are varied. Determine the strategic approach to be adopted. Note: Several
increments will be needed to achieve the required cultural change.

● Produce the project plan


Identify the key activities.

Business Study

● Identify key stakeholders within the organisation


You need all key stakeholders 'on board' to maximise the ease of introducing DSDM. There is a need for
stakeholders to have a minimum level of understanding of DSDM and Awareness training or executive
briefings are often the best way to achieve this.

Other than those directly associated with a given project, the areas that need to be buy in include:
❍ the production department

❍ the infrastructure / network department

❍ the support department

❍ the test laboratory

❍ quality management department

❍ procurement department

❍ other specialist departments, such as security and business continuity.

A formal method adoption approach can help identify these stakeholders.

1. What level of involvement is needed?


2. What are the dangers of the wrong level of involvement?
3. How can we get the correct level of involvement?
4. What are the stakeholders' critical success factors?
5. What are the drivers for the stakeholders?
6. How can we sell DSDM to the stakeholders, stressing the benefits?
7. How can we check we have the correct level of involvement?

http://www.dsdm.org/version4/2/public/Introducing_DSDM.asp (2 of 5) [11-1-2008 16:11:16]


DSDM Public Version 4.2 - Introducing DSDM into an Organisation

● Promote DSDM
It is important that all the stakeholders within the organisation are aware of the key benefits of DSDM for their
organisation. Possible options include:
❍ Encourage access to the DSDM Website

❍ Identify Consortium members from within the same sector

❍ Encourage key influencers to attend their local user group meeting and talk to other members

❍ Attend one day awareness course

❍ Run short awareness seminars (1-2 hours) within the area of the organisation identified as the pilot

area
❍ Advertise the DSDM initiative using local methods, such as in-house newsletters and magazines.

● Determine business benefits


What are the advantages in using DSDM within your organisation? Try to make the benefits measurable.
Perform a cost/benefit analysis.

● Talk to other Consortium members


Support can often be provided by other Consortium member organisations. Check the list of members on the
DSDM Web Site.

● Produce programme of candidate DSDM projects


The introduction of DSDM must be planned over a number of projects to ensure success. Examine the
portfolio of future projects and produce a programme of suitable candidate projects using the Suitability/Risk
List. Aim for good coverage of the major types of project within the usual portfolio of development work.
Choose projects for which there is a real business need - otherwise there will not be the necessary business
buy-in to the various DSDM techniques, such as user participation, prioritisation and timeboxing.

● Determine Reward Scheme for Development Team(s)


You may wish to reward the team for producing a quality system, plan early how you intend to reward the
team's success.

● Gain commitment to proceed


This will involve the key influencers within the organisation committing to the requirements of the DSDM
project.

Identify Suitable Project(s)

● Select suitable pilot project(s)


This is largely common sense. There is no point in an early failure due to the wrong application being chosen.
Use the DSDM Critical Success Factors and Suitability Filter as a guide. Do ensure that you choose projects
that are really important to the business. Otherwise the business involvement could evaporate as more
important issues arise for them.

Other criteria include:


❍ Requirements not over specified

❍ Needs active user involvement

❍ Business benefit can be delivered within 3 - 6 months

● Determine main project risks


Every project has a number of risks associated with it. DSDM projects are no exception. Create a risk register.

● Identify required environment


Determine the project environment. Where are the developers and users going to sit? What tools and
infrastructure support do they require? What skills are required?

● Review Quality Procedures


DSDM has been designed to accommodate an organisation's existing quality and management procedures.
However not all the procedures will be required on a DSDM project. Therefore need to review existing
documentation and determine what needs to be updated. It may be necessary to agree that the pilot projects
do not have to conform to existing organisation standards and procedures that are counterproductive in DSDM
projects.

● Review other procedures Take this opportunity to review other existing documentation, such as handbooks
and contracts to determine what needs to be updated. Again you may need to gain agreement for these to be
suspended for pilot projects.

● Determine key project metrics


Identify what measurements are to be made to ensure the DSDM method is producing the required business

http://www.dsdm.org/version4/2/public/Introducing_DSDM.asp (3 of 5) [11-1-2008 16:11:16]


DSDM Public Version 4.2 - Introducing DSDM into an Organisation

benefits and to assess how well DSDM is working in the pilot projects.

Deliver DSDM Pilot Project(s)

Before all pilots consider whether or not you need to do the following now:

● Procure DSDM environment


Buy the necessary tools and support environments or identify what can be done in the short term to achieve a
good DSDM toolset with what is available.

● Update quality procedures


Only update the key procedures at this point.

● Update other procedures


key procedures identified in the previous stage.

For each pilot project:

● Select the development team


Identify who will be part of the development team. Who will be performing the key roles? May have to
complement the project team with suppliers' personnel.

● Train the development team


Training and education in DSDM is key to its success. A range of training courses is available from several
training suppliers. (See the DSDM Web Site for the latest up-to-date list of DSDM training providers.) It is
strongly recommended that both end users and developers attend the course, then a common understanding
of terminology can be gained. In addition, the DSDM training course can be viewed as an important team-
building event, where the roles and responsibilities can be identified. Try also persuading the training supplier
to address your application problem, rather than the contrived exercises on the course

● Collocate the project team The environment for a DSDM project is key. Try to select a room or location away
from the normal environment where the team's interruptions can be minimised.

● Produce the business application


Run the DSDM project. Monitor what is working and what can be improved next time. Collect measures
against agreed metrics.

● Monitor the project


Ensure the metrics are being collected.

● Review the project


Hold a lessons learnt review at an agreed review point of the project. Determine whether the project has
delivered a system fit for its business purpose.

Post pilot projects

● Measure Business Benefits


Determine whether the identified business benefits have been realised. This may take many forms from end-
user or customer surveys to full quantitative and quality audits.

● Promote Project Success


DSDM has been successful!! Raise the awareness within the organisation.

● Develop Communication Plan


What is the best means disseminating the news? Try Roadshows, Newsletters, Presentations, or maybe
holding a conference.

● Amend standards and procedures


Based on the lessons learnt in the pilot projects, update key relevant standards and procedures now so that
DSDM can be used more widely. Create a plan for the amendment and update of other standards and
procedures while DSDM is being rolled out.

● Develop DSDM Mentors


The more senior people (e.g. Project Managers and the more senior development staff) in the pilot projects
could be formed into a support group for future projects. This does not need to be full-time assignment but if

http://www.dsdm.org/version4/2/public/Introducing_DSDM.asp (4 of 5) [11-1-2008 16:11:16]


DSDM Public Version 4.2 - Introducing DSDM into an Organisation

the scale of the proposed rollout warrants it, then other activities should be only minor.

● Identify/run the next project or set of projects


Identify how DSDM can now be used on other suitable projects. Maybe this time take some more risks. Go
round the setup/training/monitoring/reviewing cycle until you are confident that DSDM is really well embedded.

Critical Success Factors

Every project should identify a number of critical success factors (CSFs). When introducing DSDM into an organisation,
the following CSFs should be considered:

● Expectation managed
● Customer satisfaction
● Measured business benefit of solution
● Empowerment
● Client buy-in
● Satisfied customer
● Time and cost improvements
● Better business-fit solutions
● Satisfied team
● Satisfied Quality Manager
● User satisfaction

For each of the above CSFs, additional activities need to be considered to ensure the goal is satisfied.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Introducing_DSDM.asp (5 of 5) [11-1-2008 16:11:16]


DSDM Public Version 4.2 - Overview of eXtreme Programming (XP)

Introduction When Lifecycle People Products Management Development Tailoring Other

eXtreme Programming
DSDM and XP were both developed because of recognition that there were fundamental problems with existing
approaches taken to software development. Although coming from differing angles, DSDM focusing on business
centred development and XP originating from a developers point of view, the two have much in common, for example
the importance of communication between all stakeholders throughout the project lifecycle. This page gives on
overview of XP and emphasises what is common between it and DSDM by giving an overview of XP and its associated
practices. The aim is to indicate where XP practices and techniques can be used to supplement DSDM for all sizes of
projects.

What is XP?

" XP is a lightweight methodology for small to medium sized teams developing software in the face of vague or rapidly
changing requirements".
Kent Beck, author Extreme Programming Explained

Software development is risky. There are many variables to manage which, if left uncontrolled, can lead to spiralling
costs, missed deadlines, poor quality and worse: software that is of no real business value. This is especially true in
today's ever-changing environment where the ability to react to change is essential to success. What is needed is a
rigorous, disciplined and lightweight process model that limits these risks, saves time, money and hassle. eXtreme
Programming is such a method.

As with DSDM, at the core of XP is a set of values, principles and practices that fully support each other in order to
reduce software development risk: improving productivity, quality and the ability to respond to changing business
needs and requirements.

The reason DSDM and XP both work is because its values and principles are supported by executable practices,
ensuring that the values and principles are not just nice ideas, but actually work in practice and produce measurable
results.

Values

eXtreme Programming was developed on a value system. This core set of values helps to steer the development
process and provides a benchmark for decisions. These values ensure that long-term benefits are not sacrificed for
short-term gain.

The four XP values are Communication, Feedback, Simplicity and Courage. These are reflected in DSDM’s own Nine
Principles. Importantly in both XP and DSDM, these values do not stand-alone. They are supported with practices that
ensure the values have real meaning throughout the development process. In XP, simply "following" its values will only
get you so far. Implementing some XP practices will get you even further. Implementing all the practices will give you
true value out of the eXtreme Programming value system and process. However using XP techniques within a DSDM
framework will take this to a different level. It will allow organisations to use XP techniques but also gain the rigour and
structure with agility that the DSDM framework provides.

Let's look at each of these shared values more closely.

Communication

" Good communication is as stimulating as black coffee and just as hard to sleep after. "
Anne Morrow Lindbergh

It may seem so obvious that it's hardly worth mentioning. Everyone on a development team knows that it is essential to
communicate honestly and regularly with fellow developers and customers. Seems relatively easy. However, even with
the best of intentions, a lack of communication, or worse, bad communication inevitably creeps into projects. Poor

http://www.dsdm.org/version4/2/public/Overview_of_XP.asp (1 of 6) [11-1-2008 16:11:29]


DSDM Public Version 4.2 - Overview of eXtreme Programming (XP)

communication can cause suspicion and mistakes, and usually ends in defensive positioning and an unmotivated,
frustrated team. Poor communication often fatally damages projects.

Both DSDM and XP recognise the importance of good communication and put in place practices that cannot work
without good communication. XP practices that explicitly require communication include the :

● Planning game
● Onsite Customer
● Small releases
● Metaphor
● Pair Programming
● Coding Standards

The most value comes from practicing all of these together but if a team is just starting out using XP with DSDM, think
small, incremental change, don’t try trying to use them all at once. DSDM already contains many practices that address
communication including variations on some of these, but adding some of the XP practices can only help improve
things further, providing they are used appropriately.

Feedback

" Progress happens when inventors become unafraid of feedback - they accept it and crave it."
Samuel Linfrey

How do we know that we are developing what is needed unless we ask? Developing systems based on assumptions -
without real understanding - causes problems. Rapid and continuous feedback, a core eXtreme Programming value,
ensures that the development team knows exactly what the customer wants and how the system is functioning at any
given time. Practices that foster feedback in the XP process are:

● Planning game
● Test first design
● Small releases
● Onsite Customer
● Continuous Integration

Just as in DSDM, feedback is evident right through the XP process and takes many forms. Customer feedback is
explicitly addressed in the planning game, and the early production of functional software to the customer. Continuous
integration coupled with unit tests ensures that feedback is built into the code development. These practices can be
used to add depth to DSDM’s descriptions of joint planning, facilitated workshops, prototype and timebox reviews and
testing throughout the lifecycle.

Simplicity

" Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius (and a lot of
courage) to move in the opposite direction."
E.F. Shumacher

Simplicity in XP means doing the simplest thing that could possibly work - and it is one of the hardest values to do well.
We all want to do a good job and help the customer. Sometimes that means we try to predict future needs, losing focus
on the needs of today. We end up complicating what may be a very simple solution.

If we do it simply, leaving the system flexible, it ensures that the customer gets what they asked for right now, and they
can make changes in the future based on the reality of their needs. Practices that support simplicity are:

● Metaphor
● Simple Design
● Refactoring

Spending a short amount of time doing what needs to be done is much more productive than spending a lot of time on
a complex solution that may never be used. These practices can be used to help achieve the DSDM principle of
acceptability being measured by fitness for business purpose and work well with such techniques as MoSCoW

http://www.dsdm.org/version4/2/public/Overview_of_XP.asp (2 of 6) [11-1-2008 16:11:29]


DSDM Public Version 4.2 - Overview of eXtreme Programming (XP)

prioritisation.

Courage

" Courage and perseverance have a magical talisman, before which difficulties disappear and obstacles vanish into
air."
John Quincy Adams

Anyone who has ever been involved in a software development project has come to a situation where a difficult
decision needs to be made. It is hard to make decisions like 'we need to start again from scratch' or to tell the customer
that 'we need to drop some functionality in the next release'. The DSDM techniques of timeboxing and MoSCoW
prioritisation greatly assist in this event. The key is realising that at times "going for" the harder decision will in the end
result in a better solution. Those familiar with DSDM will again recognise some of the practices that support XP’s value
of Courage:

● Onsite Customer
● Test Driven Development
● Retrospectives
● Collective Ownership
● Sustainable Pace

Aided by the other three values of communication, feedback and simplicity make courage easier in day-to-day
development decisions.

XP Principles

Where XP values are the foundation for good development, XP principles are the guide by which we can accomplish
great development.

The five basic XP Principles:

Rapid Feedback
The quicker we know something the faster we can react to it, whether that is customer feedback or feedback from the
system

Assume Simplicity
Develop the simplest solution that could possibly work. Do not build in unnecessary complexity.

Incremental Change
Making lots of changes all at once does not work. Making a series of small changes over time will be more successful.

Embracing Change
Change is inevitable. Rather than fight change, accept that this is normal and healthy for the project.

Quality Work
This is a non-negotiable. People want to do excellent work and the system requires it.

Other ancillary XP Principles:

Teach Learning
Rather than being prescriptive on how to do XP development, teach people to learn what is the best way forward.

Small Initial Investment


Throwing resources at a project in its early stages can be harmful. Having a tight focused team that grows organically
over time will be more effective. It's also good to keep some tension between resources and workload, most projects
can get by on fewer resources.

Play to Win

http://www.dsdm.org/version4/2/public/Overview_of_XP.asp (3 of 6) [11-1-2008 16:11:29]


DSDM Public Version 4.2 - Overview of eXtreme Programming (XP)

When software development teams are burdening themselves with overheads used solely to prove that they followed
the process - it is evidence of playing to lose. "At least we can prove that we did what we should have and it wasn't our
fault." Playing to win means doing whatever is necessary to make the project successful and nothing which doesn't.

Concrete Experiments
Experiments are used to prove something. Testing abstract decisions each and every time ensures you don't
compound bad decisions.

Open, Honest Communication


When everybody on the team is communicating openly, honestly and regularly then suspicion and negative surprises
are eliminated.

Work with People's Instincts, not against them


People like to do a good job, they like to communicate and they like to learn. Working with these natural drivers will
create a happy and successful team.

Accepted Responsibility
People who take ownership of tasks will do a better job than those who have tasks assigned to them.

Local Adaptation
No situation is the same as the next, software development is not a formulaic process. The project needs to adapt and
change depending on the circumstances.

Travel Light
XP does not rely on the creation of top-heavy software development artefacts for the sake of it. Use whatever tools,
techniques etc. that help make the project successful, however do not feel compelled to maintain these after their
usefulness is over.

Honest Measurement
Choose measurement techniques that are related to the way the team works. Do not choose a measurement technique
for the sake of having one.

XP Practices

Planning Game
XP delivers end-to-end business value as quickly as possible. The planning game is a practice that puts the business
people and developers together to decide what features of the system need to be implemented and in what order for
the next release of the system. In essence, programmers estimate the features and the customer selects features into
releases

System features are broadly described on cards in business terminology. Each of these is called a User Story. The
developers then try to estimate how long each user story will take to implement. The developers also decide how much
effort can be put in during a certain period of time. The business then prioritises each story in implementation order.
User stories are then combined to form an iteration, several iterations form a release.

Small Releases
Features should be delivered as early and as often as possible to the business. Make the release cycles as short as a
month or two rather than every six months. Within these releases software is delivered in each iteration, typically every
two weeks.

System Metaphor
The system metaphor is a high level, easily understood explanation of the system that uses common naming
conventions. It helps developers and the customer understand the basic elements of the system, and their interactions.
For example a financial services product may use "calculators" as a system metaphor.

Simple Design
Design only what needs to be designed for today. XP recognises that the future is uncertain, so design the simplest
solution for the problem at hand, leaving the system flexible for future changes. Simple design can be summed up by
using a number of catch phrases:
YAGNI - You aren't going to need it.
DTSTTCPW - Do the simplest thing that could possibly work.

http://www.dsdm.org/version4/2/public/Overview_of_XP.asp (4 of 6) [11-1-2008 16:11:29]


DSDM Public Version 4.2 - Overview of eXtreme Programming (XP)

OAOO - Once and only once, i.e. no duplication

Test Driven Development


Set out by building unit tests for all production code first i.e. development is driven through tests. These are specified at
two distinct levels. First of all, we have unit tests, which are at the level of individual code modules. These are used by
developers to drive the implementation of a story. They give the programmer courage to evolve the design and enable
them to continuously refactor and improve the design of the code. Secondly, there are customer specified acceptance
tests that capture the detail of a user story into form that can be executed. These demonstrate the implementation of a
user story to a customer in an unambiguous format.

Refactoring
Refactoring is a disciplined incremental approach to improving the design of code. Refactoring the code mercilessly
results in simpler, non-duplicated and easier to understand code. It completes the core development cycle at the heart
of XP, "test, code and refactor".

Pair Programming
Pairing is a dynamic collaborative approach to writing code. Pairs of developers at one machine write all production
code. This means that all code is being reviewed as it is written. One person "drives", using the keyboard and mouse to
code what is at hand. The other developer keeps an eye on the big picture, thinks about what tests could be written,
how could the code be refactored, etc.

Collective Ownership
Everyone on the team owns the code. Anyone can improve a piece of code, even if they haven't written it. Having the
safety net of unit tests means that this can be done confidently, and the team has the freedom to continuously improve
and evolve the code.

Continuous Integration
All changes being made to the code should be integrated into the code base at least once a day. When changes have
been loaded up all tests must run 100%. If the tests do not run 100%, then the changes must be removed and the code
fixed until all tests run 100%. A 100% tested system is available all of the time. Integration tends to be a high cost
practice in software development, however paradoxically the more often you integrate the smaller the cost becomes.

Sustainable Pace
Like it or not, programmers make mistakes when they get tired. XP therefore suggests that developers work no more
than a 40-hour week. A general rule used by most XP projects is: If it is necessary to work overtime then the following
week is a 40-hour week. Furthermore, XP suggests that consistently working overtime indicates that something is
going wrong in the project.

Onsite Customer
The customer understands his or her business better then anyone on the team. Having an actual system user on site
throughout development ensures that questions will be answered quickly and correctly - programmers will never
develop based on assumptions. The customer is of course maintaining their regular workload, but is on hand for
questions. There is often reluctance by the business to give up a resource to dedicate to the system. This begs the
question whether the system is important enough to the business. Having an on-site customer means better software
delivered quicker.

Coding Standards
Having such practices as pair programming and collective code ownership would not be possible without having coding
standards. These standards need to be light weight, aid communication and be adopted voluntarily by everyone.
Coding standards become another way of communicating.

Open Workspace
Communication and especially face-to-face communication is essential to the success of an XP team. To facilitate this
teams works in an open workspace where all the people and equipment are easily accessible.

Retrospectives
As a project evolves the team generates a lot of feedback on how the project is progressing and how well the process
is working. Retrospectives are a means for the team to capture this learning as a group and through this continuously
improve. At its most basic this means answering three basic questions, "What worked? What did not? and What can
we do to address theses issues". This should form part of every iteration with an in depth retrospective at the end of
end of each release.

http://www.dsdm.org/version4/2/public/Overview_of_XP.asp (5 of 6) [11-1-2008 16:11:29]


DSDM Public Version 4.2 - Overview of eXtreme Programming (XP)

One Team
As XP has developed the concept of a "lone customer, orbiting a team of programmers" has evolved into the One
Team idea where the team is made of programmers, customers and managers working together towards a common
goal. The key difference here to traditional approaches is one of attitude i.e. simplicity, communication, feedback and
courage is at the heart of the way these groups work together.

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Overview_of_XP.asp (6 of 6) [11-1-2008 16:11:29]


DSDM Public Version 4.2 - Glossary

Introduction When Lifecycle People Products Management Development Tailoring Other

Glossary

Advisor User A project role that represents a particular user point of


view. This is usually a business, end-user point of view.
However, it may also provide the IT operational/support
view.

The Advisor User is not a Core Team role.


Ambassador User A project role that actively contributes to the project's set of
deliverables and guides the developers in their activities to ensure
that the solution being developed will accurately meet the needs of
the business.

The Ambassador User is a Core Team role.

Business Area Definition A product of the Business Study that defines the high-level
business processes, including people and information. It
evolves into the Functional Model.
Business Case A statement of the costs, benefits and risks associated with the
project, providing an overall justification of the need for the project.
Business Study A phase within the development lifecycle that lays the
foundations for all development and implementation work
to be performed within the project.
Core Model A model or set of documentation that is essential to development
and/or maintenance activities and is therefore subject to the relevant
quality controls: compare this with Support Model.

Core Team The central project team consisting of Project Manager,


Technical Co-ordinator, Team Leader, Ambassador User,
Developer and Tester roles. (Other roles are more ad hoc
in their participation in the project.)
Countermeasure A countermeasure is a defined response to a given risk or set of
risks. It can be one of the following:

● Risk avoidance: eliminating the risk by eliminating the


source of the risk.
● Risk reduction: reducing the probability of the risk occurring
or the impact if it does occur.
● Risk acceptance: accepting that if the risk occurs the project
will take a different course and defining that course. This is
basically a conscious decision to take no action.
● Transfer: transferring all or part of the risk to another party.
The probability and impact remain the same but their
management is now someone else's problem.

De-commit criteria The factors that will lead the project to be abandoned
altogether or for the DSDM approach to be abandoned. For
instance, if the user involvement is not forthcoming then
the viability of using DSDM is highly questionable.
Delivered System The solution to the business problem or opportunity in operation.
This may initially be a partial solution but will be the final solution
when the project has completed all its increments.

http://www.dsdm.org/version4/2/public/Glossary.asp (1 of 5) [11-1-2008 16:11:47]


DSDM Public Version 4.2 - Glossary

Design and Build Iteration A phase within the development lifecycle that ensures that
the project's solution will be technically sound.
Design Prototype An interim deliverable created during the Design and Build Iteration.
It is a part of the Tested System.

Design Prototyping Review Record A record of comments and feedback resulting from a
review of one or more Design Prototypes.
Facilitated Workshop A team-based meeting that creates products and makes decisions
about project-related issues. It is led by an impartial Facilitator.
Guidance is provided on using Facilitated Workshops in DSDM
projects.
Developer A project role that creates technical components of the
project's solution.

The Developer is a Core Team role.


Development Plan A plan produced during the Business Study to define how the
products of the Functional Model Iteration and Design and Build
Iteration will be created and controlled. It includes a schedule of
timeboxes.
Executive Sponsor The project role with management responsibility for the
business success of the project.

The Executive Sponsor is not a Core Team role.


Facilitator An impartial project role with the responsibility for ensuring that
Facilitated Workshops achieve their objectives.

The Facilitator is not a Core Team role.

Feasibility Prototype An optional product. It provides a business or technical


"proof of concept" during the Feasibility Study and is
discarded thereafter.
Feasibility Report The key product of the Feasibility Study. It provides an assessment
of whether or not the project is feasible in both business and
technical terms.
Feasibility Study The first phase of the development lifecycle. It investigates
what options are available to the project in addressing the
business problem or opportunity. It also lists the major
business milestones to be met and provides extremely high-
level costs.
Functional Model The key product of the Functional Model Iteration. This provides both
a definition of what will be in the Delivered System and partial
software components of the Delivered System. These will be
completed in the Design and Build Iteration. The Functional Model
evolves during each of the project's increments.
Functional Model Iteration A phase of the development lifecycle where software and
models are created that address a set of business
processing and information requirements.
Functional Prototype A partial demonstration (preferably software) of a solution to a set of
business processing and information requirements.
Functional Model Review Record A record of comments and feedback from reviews of (a part
of) the Functional Model - be it software, text or model.
Implementation The phase of the development lifecycle in which the project's (partial)
solution is put into operational use.
Implementation Plan The plan for the Implementation phase.

http://www.dsdm.org/version4/2/public/Glossary.asp (2 of 5) [11-1-2008 16:11:47]


DSDM Public Version 4.2 - Glossary

Increment 1. A part of the total system that is delivered and used by the
business before the total system is operational
2. A part of the project that develops and delivers an
implementable part of the total system, e.g. a set of
Functional Model Iteration, Design and Build Iteration and
Implementation phases.

Increment Review Document The record of what worked and what didn't work during the
development of the increment just delivered. Importantly it
addresses those requirements tat were omitted in order to
meet the timescale and assesses what should be done
about them (if anything).
Iteration An iteration follows one cycle of:

● Identify what is to be produced and its acceptance criteria


● Plan how to produce it
● Produce it
● Check that it is satisfactory by reviewing or testing the
product against the acceptance criteria.

Iteration occurs both within the Functional Model Iteration (FMI)


phase and the Design and Build Iteration (DBI) phase and between
the two phases.

In other words, there is:

● low-level iteration inside timeboxes as defined in the


Timebox process
● higher level iteration that will be evident by the move from an
FMI timebox to a DBI timebox and back to an FMI timebox
to address another area
● a mixture of the two iterations as evident in timeboxes that
contain both FMI and DBI activities and products.

Minimum Usable Subset The essential set of requirements that are to be satisfied
either within an increment or the whole project (i.e. the
Must Haves in MoSCoW prioritisation)
Outline Plan A very high-level project plan produced during the Feasibility Study
providing a draft schedule for incremental deliveries and a detailed
plan for the Business Study.
Phase A part of the DSDM system lifecycle that has a distinct set
of objectives and products.
Post-Implementation Review Report A post-project record of the lessons learnt from the solution in
operation and an assessment of whether or not the expected
business benefits have been achieved.
Post-Project A phase in the system lifecycle (as opposed to the
development lifecycle) in which the project's solution is
kept operational.
Pre-Project The phase in which a development project is initiated.
Product Anything that is created by the project, e.g. documents and
software.
Project Manager The project role with day-to-day responsibility for the success of the
project.

The Project Manager is a Core Team role.

http://www.dsdm.org/version4/2/public/Glossary.asp (3 of 5) [11-1-2008 16:11:47]


DSDM Public Version 4.2 - Glossary

Prototype A part of the total system solution that is incomplete from


the business and/or technical point of view. It is used within
the project to learn more about what is required and what
can be achieved.
Risk Log A record of all identified risks that may affect the success of the
project and their associated countermeasures.

Role A set of responsibilities within a project. One person within


the project team may hold several roles. Conversely, the
responsibilities within a role may be shared by several
people.
Scribe A project role that is responsible for recording the results of
workshops and reviews.
Support Model A model or set of documents used to clarify understanding
and not required after it has served this purpose. Support
Models are not subject to quality controls. They can be
notes in daybooks, whiteboard diagrams, etc.
System A set of mutually consistent increments that fulfils a set of defined
business benefits. Hence a system consists of hardware, software,
business and technical procedures, documentation, etc. It is not just
the software.
System Architecture Definition A product of the Business Study that documents at a high-
level what technical project solution will be, together with
the technical environments in which the solution will be
developed and ultimately reside.
Team Leader A project role responsible for managing the day-to-day activities of
one of the development teams within the project (or the only team).

The Team Leader is a Core Team role.

Technical Co-ordinator A project role that determines the technical solution and
ensures its technical quality.
Tested System The key product of the Design and Build Iteration. It is the (partial)
solution that is ready to be moved into operational use.
Tester A project role responsible for verifying the technical
accuracy of the software. (Note: the Ambassador User role
is responsible for verifying the business accuracy.)

The Tester is a Core Team role.


Test Records A record of testing activities used to verify and validate the Tested
System.
Timebox A period of time within the project that has a fixed duration
and a set of prioritised objectives to achieve within that
time. A timebox always creates one or more (sub)products.
What the products contain at the end of the timebox is
driven by the prioritised objectives, i.e. to achieve the
objectives; part of the product may be added or dropped as
time permits.

Note: A timebox process is defined for timeboxes within the


Functional Model Iteration and Design and Build Iteration
phases. Such a timebox is typically two to six weeks in
length and has a team of people working within it, e.g. to
create a set of prototypes, review and test them.

http://www.dsdm.org/version4/2/public/Glossary.asp (4 of 5) [11-1-2008 16:11:47]


DSDM Public Version 4.2 - Glossary

Timeboxing The act of working within a fixed timeframe to achieve a stated


objective. To achieve the major objective within the fixed end-time,
lower priority items are dropped. The Timeboxing section provides
more detail.
Timebox Plan A plan for one team working in one timebox within the
Functional Model Iteration and Design and Build Iteration.
Trained User Population A product of the Implementation phase. A solution is not considered
delivered until all relevant people have been trained to use it as
intended.
User Documentation The documentary support provided to all those using the
operational solution. Despite its name, it may not be paper-
based: it could be on-line help, tutorials, etc.
User class A set of people who will use the system once it is produced who
have the same job, skills, etc. For instance, supervisors could be
user class if all supervisors have the same business responsibilities,
have the same training and are expected to use the system in the
same way - as opposed to their staff who would probably need to
use different parts of the system.

Visionary A project role with the responsibility for ensuring that the
activities within the project are aligned to the needs of the
business.
Waterfall A system development lifecycle that progresses through discrete
steps from analysis and design specification to code, then through
several stages of testing to final acceptance.
Workshop See Facilitated Workshop

©2002-2008 DSDM Consortium View this page on the DSDM site

http://www.dsdm.org/version4/2/public/Glossary.asp (5 of 5) [11-1-2008 16:11:47]


DSDM Public Version 4.2 - What's New

Introduction When Lifecycle People Products Management Development Tailoring Other

What's new in DSDM Version 4.2?

Introduction

This section highlights the differences between versions 4.1 and 4.2 of DSDM – the main difference being the inclusion
of content about eXtreme Programming (XP). There are many small changes throughout the manual, so those who are
familiar with the method will need to read everything. However the key differences are as follows.

When to use DSDM

● Additions to the Suitability / Risk List to assess the risks of using XP in conjunction with DSDM

Lifecycle

● Includes a link to a DSDM and XP Lifecycle

People

● Guidance about teams and roles when using XP with DSDM.


● Cross-reference of DSDM and XP roles

Products

● There are no changes to the DSDM products.

Management Techniques

● Project Management includes guidance for when XP is used in conjunction with DSDM.
● Project Planning includes guidance for when XP is used in conjunction with DSDM, including a description of
the Planning Game.
● Estimating includes guidance for those using XP in conjunction with DSDM.

Development Techniques

● A discussion of the XP development practices which can be used in conjunction with DSDM. These include:
❍ Pair Programming

❍ Test Driven Development

❍ Refactoring

❍ Simple Design

❍ Continuous Integration

❍ Collective Code Ownership

❍ Coding Standards

❍ Acceptance / Customer Tests

❍ User Stories

Tailoring DSDM

● A new path through the lifecycle that provides guidance when using XP in conjunction with DSDM.

http://www.dsdm.org/version4/2/public/Whats_New.asp (1 of 3) [11-1-2008 16:11:56]


DSDM Public Version 4.2 - What's New

Other

● An overview of eXtreme Programming including values, principles, and practices.


● An updated glossary to include XP terminology.

What was new in DSDM Version 4?

Introduction

This section highlights the differences between versions 3 and 4 of DSDM. There are many small changes throughout
the manual, so those who are familiar with the method will need to read everything. However the key differences are as
follows.

Lifecycle

● The lifecycle has been extended to include pre-project and post-project phases.
● Each phase description has been expanded to include practical hints and tips.
● A new DSDM-based process for maintenance projects is included.

People

● Each of the role descriptions has been extended to include practical hints and tips and includes a "personal"
view of the activities undertaken by the role throughout the extended lifecycle.
● The Senior Developer role has been removed. All developers are now equal in the eyes of DSDM.
● A new role of Tester has been introduced to reinforce the testing principle about independent testing.
● The Scribe role is now clearly a team role and is distinct from the workshop scribe.
● A new section on Large Teams is included.

Products

● Each product description has been extended to include a list of possible producers, contributors, reviewers
and acceptors, and some practical hints and tips, e.g. about how to use them and what they contain.
● The Outline Prototyping Plan has been redefined and renamed as the Development Plan.
● The Implementation Strategy is now the Implementation Plan and addresses only Implementation phase
issues.
● The Timebox Plan is an explicit DSDM product.
● The Development Risk Analysis Report is replaced by the Risk Log, which is opened at the start of the project
and updated throughout.
● The Non-Functional-Requirements List is now clearly part of the Prioritised Requirements List and, as such, is
first addressed during the Business Study.
● The new Post-Project phase produces a Post-Implementation Review Report.

Management Techniques

● Timeboxing is explained more definitively, including guidance for scheduling timeboxes and a default timebox
process aligned to the iteration cycles and prototyping phases.
● Project planning contains planning steps aligned to the various planning products.
● Risk management has been significantly altered to include risk management principles and a new risk
management process aligned to the DSDM development process.
● New guidance on how to run daily meetings is included.
● Quality Management now contains guidance about when to plan for quality and a Project Health Checklist.
● Estimating is generally more practical in its focus, including guidance on what on what to estimate, what goes
wrong when estimating, estimating user effort, and making the guidance on functions points fit with the DSDM
process better.
● New guidance on escalation is included.
● Measurement has improved guidance on productivity measurement.

http://www.dsdm.org/version4/2/public/Whats_New.asp (2 of 3) [11-1-2008 16:11:56]


DSDM Public Version 4.2 - What's New

Development Techniques

● The guidance on facilitated workshops covers what workshops to run in each phase defining different
categories of workshops that contribute to the DSDM products.
● The modelling section now includes the business view, and the models by phase table has been updated.
Guidelines for selecting modelling techniques have been added.
● The Development Environments section no longer contains a process for selecting and introducing tools. This
is better addressed in the Package Selection and Implementation White Paper.
● Testing includes risk-based testing.
● Configuration management is more practical and uses the Core Models concept (from modelling techniques)
when determining what to control.
● The section on prototyping now includes prototype testing.

Tailoring DSDM

This is a new topic and provides guidance on different paths through the DSDM lifecycle and tailoring for specific
project types as follows:

● Large projects
● Small projects
● Hybrid DSDM and waterfall projects
● Business Process Change projects

Other

● The section on the DSDM Business Environment has been removed: business change, etc. is now addressed
throughout the method.
● Introducing DSDM into an organisation has been made more practical in its content and provides an iterative
and incremental approach to introducing the method

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/Whats_New.asp (3 of 3) [11-1-2008 16:11:56]


DSDM Public Version 4.2 - Facilitator

Introduction When Lifecycle People Products Management Development Tailoring Other

Credits
DSDM Version 4.2 has been created based on the experiences and comments collected from Consortium members
worldwide using DSDM and training people to use the framework. We should also mention the many people who have
contributed to DSDM White Papers over the years. Many of the White Papers have some content now transferred to
the core manual.

Ideas for what to include in this version of DSDM were received from too many members to name individually.
Nevertheless, our sincerest thanks go to all these people and organisations.

Contributors Reviewers
Kevin Barron, HP, New Zealand Steve Bellamy, Capital One, UK
Peter Coesmans, P2M, Netherlands Julia Godwin, be consulting
Andrew Craddock, RADTAC Mike Griffiths, Quadrus, Canada
Rachel Davies, XPAgile Vicky Howard, Xansa
Barry Fazackerley, Xansa Brenda Hubbard, Xansa
Sean Hanly, Exoftware Per-Magnus Skoogh, OWM
George Hay, Independent Consultant, UK Jennifer Stapleton, Independent
Steve Messenger, NAPP, UK Andrew Stringer
Mairi Osborne, Xansa Nils Wassenaar, Cap Gemini Ernst & Young,
Keith Richards, Keith Richards Consulting Netherlands
Mark Simmonds, Symmetrics
Jennifer Stapleton, Independent Consultant
Derek Thornley, Parity Training, UK
Rob Topley, LogicaCMG
Dot Tudor, TCC, UK
Paul Turner, Parity Training, UK
James Yoxall, Indigo Blue Consulting

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/credits.asp [12-1-2008 11:59:46]


DSDM Public Version 4.2 - Site Map

Introduction When Lifecycle People Products Management Development Tailoring Other

Site Map

● Introduction ● Products (in alphabetical ● Management Tools and


❍ Front Cover order) Techniques
❍ Introduction ❍ Overview ❍ Overview

❍ How to use this site ❍ Business Area ❍ Timeboxing

❍ Process Overview Definition ■ Daily Meetings

❍ How the process works ❍ Delivered System ❍ MoSCoW Prioritisation

❍ Underlying Principles ❍ Design Prototype ❍ Project Management

❍ Design Prototyping ■ Escalation

Review Records ■ XP and Project


● When to Use DSDM
❍ Development Plan Management
❍ When to Use DSDM
❍ Feasibility ❍ Project Planning
❍ Critical Success Factors
Prototype ■ XP and Planning
❍ Suitability/Risk List
❍ Feasibility Report ❍ Quality management

❍ Functional Model ■ Project Health

● Lifecycle ❍ Functional Model Checklist


❍ Overview
Review Records ❍ Risk Management

❍ Pre-Project
❍ Functional ❍ Measuring DSDM Projects

❍ Feasibility Study
Prototype ❍ Estimating

❍ Business Study
❍ Implementation ■ XP and Estimating

❍ Functional Model Iteration


Plan
❍ Design and Build Iteration
❍ Increment Review
● Development Tools and
❍ Implementation
Document Techniques
❍ Post-Project
❍ Non-functional
❍ Overview
■ Maintenance
Requirements List ❍ Facilitated Workshops
■ Delivered System
❍ Outline Plan
❍ Modelling
Changes ❍ Post-
❍ Prototyping

Implementation ❍ Testing

● People Review Report ❍ Configuration management

Overview ❍ Prioritised
❍ ❍ Tool support environments

■ Large Teams Requirements List ❍ XP Development Tools and

■ XP And Teams ❍ Risk Log


Techniques
❍ Executive Sponsor ❍ System

❍ Visionary Architecture
● Tailoring DSDM (project scenarios,
❍ Ambassador User Definition
etc.)
❍ Advisor User ❍ Tested System
❍ Overview

❍ Project Manager ❍ Test Records


❍ Paths through DSDM

❍ Technical Co-ordinator ❍ Timebox Plan


❍ Hybrid Projects

❍ Team Leader ❍ Trained User


❍ Large Projects

❍ Developer Population
❍ Small Projects

❍ Tester ❍ User
❍ Business Process Change

❍ Facilitator Documentation
Projects
❍ Scribe ❍ DSDM With XP

❍ Specialist Roles

● Other
❍ Introducing DSDM into an
organisation
❍ Overview of eXtreme
Programming (XP)
❍ Glossary of terms
❍ What is new
❍ Credits
❍ Site Map

http://www.dsdm.org/version4/2/public/site_map.asp (1 of 2) [11-1-2008 15:50:13]


DSDM Public Version 4.2 - Site Map

©2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/site_map.asp (2 of 2) [11-1-2008 15:50:13]

You might also like