Professional Documents
Culture Documents
2 Manual
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).
● understand
● plan
● communicate
● control
● deliver
● all projects (IT or Business Change).
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.
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.
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.
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:
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:
DSDM aims not only to prevent failure but to bring success, by delivering systems that:
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.
Using an iterative process based on prototyping, DSDM involves the end-users throughout the project lifecycle. This
has many benefits, for example:
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.
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?
● 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.
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.
Use the Site Map to find what you are looking for.
Use the Site Map to find what you are looking for.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
● 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.
● 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.
● 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.
● 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.
● 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.
● 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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
11. Is there a highly demonstrable user interface? Screens, reports, file prints etc.
What resources (e.g. people, accommodation) have been allocated to the project?
Who are the likely suppliers of development resource for the 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?
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.
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 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.
If you are using XP in conjunction with DSDM the Using DSDM with XP section of the manual describes a combined lifecycle.
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
Products
An outline scope for the investigation to take place during the Feasibility Study
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:
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
❍ Others will need to spend time in order to gain approval for the project from key decision-makers.
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.
Feasibility Study
Introduction
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
Preconditions
Products
Feasibility Report
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.
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.
Business Study
Introduction
Objectives
To outline the future development in terms of prototyping deliverables (defining which are incremental and which, if
any, are throwaway) and prototyping controls
Preconditions
Agreement of the Feasibility Report, including agreement of the feasibility of both the development and the applicability
of the DSDM approach
Products
Development Plan
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.
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.
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
Products
Implementation Plan
Timebox Plans
Points to Consider
This phase may be merged with Design and Build Iteration for several reasons, e.g.:
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.
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.
Introduction
The Overview of DSDM provides a description of the Design and Build Iteration phase.
Objectives
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
Products
Timebox Plans
Design Prototypes
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.
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.
Implementation
Introduction
Objectives
Preconditions
Agreement of the Tested System by all interested parties, e.g. senior user management and technical support
Products
User Documentation
Delivered System
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.
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.
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 assess whether or not the proposed benefits of the project as stated during its initial phases have been achieved.
Preconditions
Products
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.
A DSDM-based process is provided for developing and releasing Delivered System changes.
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.
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:
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
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.
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.
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
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.
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).
● 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.
● 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 process returns to the planning phase to confirm the contents and date of the next delivery of system changes.
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.
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.
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
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.
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.
The diagram below shows the possible relationships between the DSDM roles and the organisation and project infrastructure.
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 smaller project with only one team, so far more role consolidation of roles but similar relative responsibilities
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:
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.
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.
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.
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.
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.
● 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.
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 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.
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.
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
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.
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
Agree the approach to project governance with the relevant parts of the
organisation (see the Project Organisation diagram)
Review/accept the Outline Plan (or not: the project can stop here if no viable
solution is possible)
Approve the Business Case for the project to proceed beyond the
Business Study and obtain funding as necessary
Points to Consider
The Executive Sponsor role and Visionary role may be held by the same person
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
Feasibility Study Participate in the project kick-off workshop (if one is run)
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.
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.
Agree with the Project Manager how and when progress will be
reported and issues will be dealt with for the rest of the project.
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
Respond to issues raised by the Ambassador Users and the Project Manager.
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.
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.
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.
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
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)
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)
● 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.
Design and Build Work each week in a development team at the times agreed during the
Iteration Business Study
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
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.
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
Responsibilities
Pre-Project
Feasibility Study Participate in Facilitated Workshops to create the Feasibility Report if requested by
the Visionary
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
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.
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
Responsibilities
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.
Agree the project de-commit criteria now with the Visionary and/or
Executive Sponsor.
See the Feasibility Study's Product Descriptions for ideas about the
respective responsibilities of the DSDM roles.
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.
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 the Outline Plan. See the Business Study's Product Descriptions for ideas
about the respective responsibilities of the DSDM roles.
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.
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.
Accept all timebox deliverables to the project at each timebox closeout meeting.
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.
Run the Increment Review workshop and produce the Increment Review
Document.
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.
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.
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.
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
Responsibilities
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.
Assist the Project Manager in creating the Outline Plan as necessary. Review/
accept the Outline Plan.
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.
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.
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.
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.
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
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.
Understand the Business Case for the project so that good decisions
about potential changes to scope and requirements can be made
during timeboxes.
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.)
● 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.
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.
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
Responsibilities
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)
❍ Work with the Tester(s) to ensure that prototypes are handed over
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
Timebox Plan
❍ Unit test protoypes
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.
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
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.
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:
Implementation Perform the non-user testing specified in the Implementation Plan and in
accordance with the overall Test Strategy.
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:
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
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
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.
Design and Build Take notes at all timebox meetings and reviews, and other workshops.
Iteration
Publish notes as required.
Assist the Project Manager on the basis of the notes in creating the Increment
Review Document
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.
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.
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
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.
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:
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.
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.
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 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
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.
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:
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.
Points to Consider
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.
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 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
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.
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.
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 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
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.
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 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
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.
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 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
❍ Testing Environment(s)
❍ Acceptance procedures
❍ Deliverables
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
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.
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 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 report on the suitability of DSDM for use on the project, which may vary for each solution.
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
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.
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.
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:
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.
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
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.
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.
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 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
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.
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
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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 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
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.
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.
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.
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.
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:
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
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.
Points to Consider
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:
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.
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
(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.
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.
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:
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)
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
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.
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.
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.
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
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.
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
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.
Points to Consider
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.
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 key milestones, e.g. technical or user review dates, 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.
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.
The Visionary may wish to review and approve the plans for timeboxes that are particularly critical from the business
point of view.
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.
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.
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
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.
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.
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.
● 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.
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.
● 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
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:
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.
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.
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.
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.
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.
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
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.
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
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.
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.
Investigation
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.
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.
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:
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 Meeting Leader is also responsible for the measurement and management of the team's timeboxes in an
increment through:
The daily meetings should provide the Meeting Leader with the required empirical evidence to carry out these tasks.
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.
MoSCoW Prioritisation
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
If the users inside the team have their decisions overruled by someone else in the user organisation, either that outside
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
❍ 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
❍ 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 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:
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
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 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.
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.
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.
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.
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.
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
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.
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.
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.
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.
The Development Plan serves to agree how the project will be carried out, in particular which prototypes will
be built and when.
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.
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
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
● 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 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 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:
● Development Plan
● Timebox Plans
● Implementation Plan
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.
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.
● 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 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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
Quality Management
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.
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:
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?
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?
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
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?
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?
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?
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.
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.
● 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.
● 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.
● Projects with risks determined as unacceptable by the Executive Sponsor should not be started.
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.
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.
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
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
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.
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.
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.
Risk assessment and implementation of preventative and contingency measures continue. Risks are managed at both the
project and timebox level.
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.
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
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.
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.
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.
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.
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.
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.
A particular risk associated with iterative and incremental development is that of creeping functionality that does not converge
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
Why measure?
The purpose of measurement is to investigate and highlight some aspect of a project. Measurement is necessary in
order to:
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.:
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.
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:
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.
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.
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.
Introduction
Estimating provides the information that is required for two main purposes:
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.
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:
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.
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.
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 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.
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.
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.
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
● 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 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 (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).
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
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".
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
❍ 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
● 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.
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.
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
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
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.
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.
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.
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.
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:
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.
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.
● 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.)
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.
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.
● 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.
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
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.
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.
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.
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.
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
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
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.
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:
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.
● 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.
Definition of terminology
● 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.
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).
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.
● 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 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.
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.
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.
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.
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 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.
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
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.
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.
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.
● 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.
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:
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:
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
integrity to support the business, irrespective of the development techniques actually used.
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
Function dependencies
Business scenarios
Task models
Business event model
Business roles
definition
Support Models:
Process dependencies
Scenario analysis
Object interaction /
collaboration diagrams
Object role 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
Support Models:
Physical components
definition
Security architecture
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.
● 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.
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:
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.
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
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.
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.
Prototyping
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
● 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.
Any discrepancies between the developers' understanding and the business requirements are noted.
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.
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.
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.
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.
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.
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.
● 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
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:
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.
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.
As a general rule, it is recommended that three iterations be allowed - and that they are aligned to the timebox process:
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.
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.
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.
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
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.
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.
Testing criteria for the categories of prototype (EI = Expected Information, ER = Expected Result)
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.
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.
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.
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.
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:
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.
Note: Unit Testing is completed as normal, whereas an RBT approach can be applied to all subsequent stages of testing.
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.
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.
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.
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.
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.
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:
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
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.
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.
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".
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
● 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.
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:
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.
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.
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.
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.
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.
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 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.
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 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.
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.
Standardisation is key to the support environment usability, openness and tool portability.
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.
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:
Host Environment
The environment on which the tool is hosted must be considered. Factors which must be addressed include:
User Support
Consider what support the tool offers to its users, in terms of:
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?
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?
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?
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:
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.
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
❍ Contains no duplication
programmer.
❍ Contains the fewest possible functions,
methods/classes
● Supported by test driven development and refactoring.
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
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 estimatable
❍ Should be testable
❍ Should be prioritisable
developers
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
Introduction
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:
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.
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.
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.
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
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.
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.
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.
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.
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:
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 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:
● 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
❍ 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.
● 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.
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
Further guidance is available in the Application of DSDM to Large Projects White Paper available via the Webshop.
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
● 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
❍ A high-level description of the business processes and the classes of users involved
❍ A high-level description of the target environment in which the Delivered System will operate
● 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
❍ 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
❍ 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.
● 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.
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 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:
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.
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.
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.
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
● 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
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
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)
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.
The changes are then prioritised using the MoSCoW rules once the importance, scope, costs and benefits have been
thought through.
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.
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:
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 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
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.
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 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
● 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.
● 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.
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
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:
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.
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.
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.
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.
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 Trained user Population and Increment Review Document are the same as for standard DSDM.
Roll-out
Activities include:
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.
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.
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 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.
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.
Within the XP community there is a broad spectrum of opinion of what constitutes "sufficient" up-front design. Like XP, 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.
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.
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.
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.
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:
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).
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.
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.
● 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?
● 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?
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.
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.
Feasibility Study
● 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.
Business Study
Other than those directly associated with a given project, the areas that need to be buy in include:
❍ the production department
❍ procurement department
● 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
❍ Encourage key influencers to attend their local user group meeting and talk to other members
❍ 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.
● 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.
benefits and to assess how well DSDM is working in the pilot projects.
Before all pilots consider whether or not you need to do the following now:
● 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.
the scale of the proposed rollout warrants it, then other activities should be only minor.
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.
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.
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
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
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.
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.
Teach Learning
Rather than being prescriptive on how to do XP development, teach people to learn what is the best way forward.
Play to Win
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.
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.
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.
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.
Glossary
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.
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.
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.
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:
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.
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.)
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
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.
● Additions to the Suitability / Risk List to assess the risks of using XP in conjunction with DSDM
Lifecycle
People
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
❍ Refactoring
❍ Simple Design
❍ Continuous Integration
❍ Coding Standards
❍ User Stories
Tailoring DSDM
● A new path through the lifecycle that provides guidance when using XP in conjunction with DSDM.
Other
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.
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
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
Site Map
❍ Pre-Project
❍ Functional ❍ Measuring DSDM Projects
❍ Feasibility Study
Prototype ❍ Estimating
❍ Business Study
❍ Implementation ■ XP and Estimating
Implementation ❍ Testing
Overview ❍ Prioritised
❍ ❍ Tool support environments
❍ Visionary Architecture
● Tailoring DSDM (project scenarios,
❍ Ambassador User Definition
etc.)
❍ Advisor User ❍ Tested System
❍ Overview
❍ 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