DSDM: A Framework for Business-Centered Development

DSDM: A Framework for Business-Centered Development


$35.66 $41.99 Save 15% Current price is $35.66, Original price is $41.99. You Save 15%.

Product Details

ISBN-13: 9780321112248
Publisher: Addison-Wesley
Publication date: 01/13/2003
Series: Agile Software Development Series
Pages: 239
Product dimensions: 7.40(w) x 9.20(h) x 0.58(d)

Table of Contents

What is DSDM?
A Bit of History.
Overview of the Framework.
Why is DSDM more Rapid than the Waterfall?
About this Book.
About the Agile Software Development series.


1. DSDM Process Overview.
The Feasibility Study.
The Business Study.
Functional Model Iteration.
Design and Build Iteration.
Key Points.

2. The Underlying Principles.
Principle 1: Active User Involvement is Imperative.
Principle 2: DSDM Teams Must be Empowered to Make Decisions.
Principle 3: The Focus is on Frequent Delivery of Products.
Principle 4: Fitness for Business Purpose is the Essential Criterion for Acceptance of Deliverables.
Principle 5: Iterative and Incremental Development is Necessary to Converge on an Accurate Business Solution.
Principle 6: All Changes During Development are Reversible.
Principle 7: Requirements are Baselined at a High Level.
Principle 8: Testing is Integrated Throughout the Lifecycle.
Principle 9: A Collaborative and Co-operative Approach Between all Stakeholders is Essential.
Key Points.

3. The Process in Action.
When to Use DSDM.
The Reality of Iteration and Incremental Delivery.
Analysis and Design Techniques.
Key Points.

4. Time Versus Functionality.
Fitting Quarts into Pint Pots.
MoSCoW Rules.
Controlling Timebox Activity.
To Timebox or Not?
The Disaster Scenario.
Key Points.

5. People Working Together.
A Potential for Global Change.
The Project Roles.
Project Structures.
Key Points.

6. The Agile Project Manager in Action.
What is Different?
Planning a DSDM Project.
Managing Risk.
Monitoring Progress.
Key Points.

7. Impact on the Organization
Making Decisions.
User Involvement.
Better Communication.
Facilitated Workshops.
Training Users.
Key Points.

8. Never Mind the Quality?
'Good Enough' Software.
Building in Quality.
DSDM and TickIT.
New Procedures for Old.
The Capability Maturity Model.
Key Points.

9. Prototyping is not a Waste of Time.
Bridging the Language Barriers.
But the Users keep Changing their Minds!
Categories of Prototypes.
Getting Effective Feedback.
Keeping Control.
Key Points.

10. The Agile Professional.
'No More Quick and Dirty'.
Skills and Attributes.
Key Points.

11. Extreme Programming (XP) in a DSDM Environment.
Competing Agile Methods?
DSDM and XP in Harmony.
Some Requirements Unique to XP.
Key Points.

12. Technology Support.
The Need for Technology Support.
DSDM Support Environments.
Testing Tools.
Configuration Management Tools.
Effective Tool Usage.
Key Points.

13. Keeping the System Going.
Timeboxing Approach.
Setting the Priorities.
Delivering the Change.
Key Points.


14. Implementing DSDM in eBA.
Creating eBA.
Introducing DSDM.
eBA Roles.
Reward Schemes.
The Environment.
Technique Coaching.
Typical Projects.
DSDM Support.
Project Readiness Reviews.
Use of UML.

Example Project.
Account Status.

15. DSDM and Eliminating the Contractual Divide.
Project Lifecycle.
The Project.
Personalities and Roles.
Functional Model Iteration and Design and Build Iteration.
The Benefits.
Lessons Learned.

16. DSDM in a Non-IT Project.
The Environment of the Project.
The Project.
Feasibility/Business Study.
Functional Model Iteration.
Design and Build Iteration.

The Functional Model Iteration Workshop.

17. An Object-oriented DSDM Project.
Theoretical Compatibility of OO/UML with DSDM.
Project Motivation.
Feasibility Study.
Business Study.
Business Area Definition.
System Architecture Definition.
Prioritized Requirements list.
Development Plan.

Functional Model Iteration.
Design and Build Iteration.
User Documentation.
Trained User Population.
Delivered System.

Senior Management Understanding.
User Availability.


18. How DSDM can De-risk Offshore Working.
Challenges of Managing an Offshore Project.
Why Move to the Fully Integrated Onshore and Offshore Model?
The Benefits of Combining DSDM with the Fully Integrated Onshore and Offshore Resourcing Model.
Transition to DSDM Offsite.
An Overview of the DSDM Offsite Lifecycle.
Feasibility Study.
Business Study.
Functional Model Iteration.
Design and Build Iteration.

New DSDM Roles to Accommodate Offsite Working.

19. What Happens When it all Goes Horribly Wrong.
Our Technical Co-ordinator is Missing!
The Case of the Disappearing Ambassador User.
Timeboxes for Fun (and no Profit).
Who Needs Testing?
We Can't Talk to the Users.

20. A Measured DSDM Project—BT.
The Approach to DSDM.
Quality and Testing.
Training and Team-building.
Project Roles and Planning.
External Relationships—Managing Critical Interactions.

The Project Diary.
Project Data.
Effort and Resource Data.
The Team's Perceptions of the Project.
The Unit's Perception of DSDM and the Project.

Conclusions and Lessons Learned.
Appendix: Results of the Project Review Meeting.
What Worked Well.
What Worked Less Well—Lessons, Issues, Questions.

21. From DSDM Adhocracy to DSDM Factory.
Project Situation.
Lessons Learned about a Fixed End Date.
Lessons Learned about the Kick-off Meeting.
Lessons Learned about the Involvement of Functional and Technical Maintenance Departments.
Lesson Learned about Testing.
Lessons Learned about Configuration Management.
Lessons Learned about IT Roles Within the Development Team Lesson Learned about Tool Support.

The 'DSDM Suitcase'.
What is the 'DSDM Suitcase'?
How is the Information in the 'DSDM Suitcase' Structured?
How is the 'DSDM Suitcase' Used?.

Project Group.
'DSDM Suitcase'.

22. DSDM in Process Improvement.
Background Information.
Experiment Objectives and Means of Measurement.

Starting Scenario.
Experiment Context.
Company Context.
Baseline Project Context.

Experiment Description.
Phases of the Experiment.

Resulting Scenario.
Technical Impact.
Business Impact.
Organization Impact.
Culture Impact.
Skills Impact.

Key Lessons Learned.
Technological Point of View.
Business Point of View.


23. DSDM and Business Rules.
How this Chapter is Organized.

The Project.
About the Customer.
Initial Requirements and Expectations.
Project Overview.

Business Rules Based Methodology.
Rules Repository.
Rules Implementation.

Business Rules in ACUMEN.
BRM and Feasibility Study.
BRM and Business Study.
BRM and Functional Model Iteration.
Evaluation of BRM in ACUMEN.

DSDM and Business Rules.


24. Where do I go From Here?
Contact the DSDM Consortium.
Get Trained.
Mentor is Essential.


Appendix A. e-DSDM, a Specialization.
Focusing on the Net.

Appendix B. The Agile Manifesto.
Formation of the Agile Alliance.
The Agile Manifesto: Purpose.
The Agile Manifesto: Principles.
Toward an Agile Future.
The Manifesto for Agile Software Development.

Index. 0321112245T11012002



For 40 years the business community has looked to the automation of clerical processes both for efficiency and to gain elusive competitive advantage. In that period, information technology practitioners have consistently failed to deliver the necessary solutions on time, within budget, or to provide the functionality needed by the business.

It has taken us this amount of time to understand that business requirements change rapidly and are difficult to define, and that the people who understand business processes best are the people who use them day-by-day. We have seen that development projects can gain a life of their own, and become enmeshed in their own complexity, but we have learned that applications development is not a black art, and is amenable to structure and discipline.

During the last two decades of the twentieth century, a number of serious attempts have been made to understand the application development process and to codify ways in which these failures can be overcome. In 1994, information systems professionals in the UK from large and small organizations in a wide variety of industries, came together with consultants and project managers from some of the largest companies in the IT industry to form a not-for-profit consortium. This consortium is dedicated to understanding the best practice in application development and codifying it in a way that can be widely taught and implemented.

The result is DSDM (Dynamic Systems Development Method), a project delivery framework that truly serves the need of the business: DSDM projects deliver on time, to budget, and they don't cut importantcorners. Everything in the published framework has resulted from practical experience and successful application by the membership. This strongly practical approach leads many people to view the framework as being 'just common sense', but it is apparent to anyone trying to control agile developments just how uncommon 'common sense' can be.

Today, the framework is being used on a wide variety of projects, small and large, simple and complex, IT and non-IT, in many countries, and the consortium continues its work to refine the content of the framework. For instance, in June 2001, the consortium issued a version of DSDM specifically aimed at e-business projects where all the reasons for delivering quality systems quickly are possibly even more important. The basic framework underwent a significant update in the summer of 2001 and an incremental improvement was made in January 2002.

Given that we are predominantly building business systems with some IT content, the philosophy behind DSDM is simple:

u Development is a team effort. It must combine the customers' knowledge of the business requirements with the technical skills of IT professionals.

u High quality demands fitness for purpose as well technical robustness.

u Development can be incremental — not everything has to be delivered at once, and delivering something earlier is often more valuable than delivering everything later.

u The law of diminishing returns applies — resources must be spent developing the features of most value to the business.

DSDM is about people, not tools. It is about truly understanding the needs of the business and delivering solutions that work — and delivering them as quickly and as cheaply as possible. The framework will not solve every project's problems, but it will go a long way towards ensuring that the business gets the systems it needs in the twenty-first century.

What is DSDM?

The first questions to ask when coming to DSDM are what is it and why is it different? Despite its full name it is not a method in the accepted sense, but a framework of controls focused on delivering quickly, supplemented by guidance on how to apply those controls. It is a method in as much as it defines a process and a set of products, but these have been deliberately kept at a high level so that they can be tailored for any technical and business environment. There are no prescribed techniques but suggested paths are supplied for implementers of both structured and object-oriented approaches. It is different because it is possibly the only publicly available approach that covers all aspects of system development from the first idea for a project up to the final removal of the project's solution. It addresses the needs of all project participants: business management, project managers, solution architects, solution developers, solution users, and quality assurance personnel.

DSDM describes project management, estimating, prototyping, timeboxing, configuration management, testing, quality assurance, roles and responsibilities (of both users and IT staff), team structures, tool environments, risk management, building for maintainability, reuse and vendor/purchaser relationships — all in a fast-moving, business-centered environment.

The purpose of the framework is to achieve rapid time to market: building what the business needs, when it needs it. If the system is to meet the business needs, then it must be sufficiently robust to be usable in the operational environment. Secondly, the immediate needs of the business can probably be met in the short term and allow for delivery of additional functionality later on.

A bit of history

Businesses are putting increasing pressures on their IT suppliers to deliver better systems, faster and cheaper. In today's rapidly changing world, they are no longer able to wait for years for a system to be provided: the business may have changed radically during the years of development. It is imperative to find a different way of building IT systems. The technology that is now available to developers allows for more speedy production of systems but the answer lies not only in the use of tools. The whole process needs to change. The classical, waterfall lifecycle does not take full advantage of modern technology and does not facilitate the change that is inherent in all systems development. It has been around for about 40 years and is basically the solution to an old problem — that of not having a full understanding of the problem to be solved and not having a coherent approach to solving the problem before starting to code a solution.

The waterfall approach of a strict sequence of stages has been seen to be flawed for many years now. Several attempts have been made to move away from it, including Barry Boehm's iterative style of development using a spiral model of planning, risk analysis, engineering, and customer evaluation. Though excellent, the spiral model did not achieve the penetration into IT practices that it deserved. The emergence in recent years of many 'Agile' methods proves the need for a different approach. While some, such as Extreme Programming, have gained wide acceptance they do not cover all aspects of a project and can leave an organization confused as to how to integrate the many solutions on offer. This provides one explanation for the less than optimal acceptance of agility as the way forward by the majority of IT solution providers. Another could be that, until recently, there has not been sufficient pressure from their customers.

In the early 1990s, the IT industry had become increasingly aware of Rapid Application Development following James Martin's book Rapid Application Development, which gave some excellent pointers as to how to make the concept work, but did not provide the total solution. There are many tools on the market, but to use them often meant buying the vendor's process as well. The founding members of the DSDM Consortium saw this as a block to the growth of successful and fast solution delivery.

The Consortium was inaugurated in January 1994 with the aim of producing a public domain, commonly agreed method which would be tool-independent. Ed Holt who chaired the Consortium for the first two years said that every organization that bought a RAD tool really needed a new process. DSDM aims to provide that process for building and maintaining systems that meet tight time constraints in a controlled project environment. The Consortium had 17 founder members who represented a mix of organizations that remains today: large IT vendors, smaller tool vendors, and user organizations of all sizes. The Consortium now has hundreds of members with established regional consortia in North America, Benelux, Sweden, France, and Denmark with interest growing in other countries, such as Australia, India, and China.

During 1994, the Consortium's Technical Work Group put together the process and produced guidance material based on the experiences and best practices of Consortium members. A few components of the framework were original ideas from experts in particular areas, but most of them were tried and tested — but they had never been brought together as a cohesive approach.

After Version 1 of the framework was published early in 1995, an Early Adopter Programme was put in place to monitor the use of the framework in practice. After feedback from the Early Adopters and the addition of material that had been deliberately left out of Version 1 to get the framework visible as soon as possible, Version 2 was published in November 1995. Following feedback from the wider use of the framework, Version 3 was published in August 1997. Up until 2001 additions to the framework came via UK government White Papers on topics as diverse as using DSDM in data warehousing, component-based development and prototyping business processes. In 2000, it became clear that there was a need for a version of DSDM that was less generic in its definitions and specifically aimed at e-business projects. The technical work of the consortium continues: it is still collecting feedback from users of the framework, and addresses particular needs as they arise through the production of White Papers. A recent White Paper covers the use of UML in DSDM projects.

To ensure that the framework is well understood and applied correctly, a training and examination process was launched alongside Version 1 and continues to evolve. At the time of writing, over 20,000 people have been trained by accredited training providers and increasing numbers are going through the examination process to become certified DSDM Practitioners.

Overview of the framework

The whole framework is based on nine principles, which are discussed in more detail later on, but it is useful to list them here. The first four define the foundations on which DSDM is built and the other five provide the principles that have guided the structure of the framework.

1. Active user involvement is imperative.

2. DSDM teams must be empowered to make decisions.

3. The focus is on frequent delivery of products.

4. Fitness for business purpose is the essential criterion for acceptance of deliverables.

5. Iterative and incremental development is necessary to converge on an accurate business solution.

6. All changes during development are reversible.

7. Requirements are baselined at a high level.

8. Testing is integrated throughout the lifecycle.

9. A collaborative and co-operative approach between all stakeholders is essential.

All of these principles have been found to be necessary, if a quality system is to be supplied in the timescales required by the business.

The iterative and incremental process embodied in the fifth principle consists of five development phases. (There are two non-development phases: pre-project, which ensures that the project is set up on a sound basis, and post-project, which includes keeping the delivered solution operational.) The first two development phases are sequential: feasibility to assess the suitability of the system to the approach and to provide an initial view of the costs, etc., followed by the business study which builds the business and technical foundations of the rest of the project. After the business study, the first of the iterative phases is the functional model iteration in which the analysis started in the business study is done in more detail. The analysis is supported by evolutionary prototyping of functionality inside the system architecture that is also defined at a high level in the business study. When an area of functionality is well enough understood, the design and build iteration engineers the system component to sufficient quality to be delivered in the implementation phase. Implementation covers not only moving the system to the production environment but also training the users. At the end of implementation, the increment is reviewed and a business decision is made about what further work (if any) needs to be done in subsequent increments.

No process is complete without the people to enact it. The first principle states that the solution's users must be closely involved throughout development: their regular input and feedback are essential to the framework. DSDM defines roles for the people involved in a DSDM project. These include both users and development staff. For example, one user role is that of Visionary. This is usually taken by the person who is responsible for getting the project started through their vision for IT support in the business area. A key IT role is that of Technical Co-ordinator, who is basically the system architect and keeper of the technical vision. The combination of these two roles ensures the business and technical foundations of the project are secure, but there are many more roles defined in both areas of specialism.

The aim of DSDM is to deliver systems to timescales that would be impossible using the waterfall approach. The impact is that the work processes have to be managed in a different way and the techniques used within those processes need to be honed down to reduce overheads as much as possible. The major instrument for controlling work is the timebox. The timebox in DSDM is a short period of time (a matter of days or a few weeks) within a project when something is produced to defined quality objectives, so satisfying the third, fourth, and eighth principles. By taking a product-based view rather than an activity-based view of process, DSDM allows the controls to be focused on what is produced rather than the method of production. This enables a flexible approach to be taken to the techniques used within the framework.

Application of the sixth principle of reversible change means that everything that is produced must be controlled sufficiently well in order to move back to a known state when any product proves to be wrong.

So DSDM is about controlling a style of development that is often viewed as a way of producing unmaintainable systems. It keeps a firm focus on satisfying the business needs rather than IT's perception of them. The application of DSDM's user-centered, iterative, and incremental approach results in many benefits. As has been proven on thousands of projects, these include:

u the users are more likely to take ownership of the system;

u the risk of building the wrong system is reduced;

u the final system is more likely to meet the users' real business requirements;

u the users will be better trained;

u the system implementation is more likely to go more smoothly.

Why is DSDM more rapid than the waterfall?

DSDM produces 'industrial strength' systems that meet users' needs and are fully extendible and maintainable over long periods of time — they are not one-off or throwaway. In business terms, they are the exact peer of good systems developed by the waterfall approach, but take a lot less time to develop.

There are two main reasons. Less is actually done. There is much less time spent in briefing people, and bringing them repeatedly up to speed. Little time is lost through task-switching by users or developers. Most importantly of all, only the features that are needed are actually developed.

The second reason is that problems, misunderstandings and false directions are identified and corrected early, so avoiding the massive rewrites often required late in waterfall projects. This has a further benefit. The resultant code developed under DSDM is consistent and of a piece, whereas waterfall code, by the end of the project, is often already patched and out of synchrony with its documentation. The result is that DSDM-delivered code is also easier to maintain.

About this book

While the online manual is obviously the first port of call when the framework needs to be understood in depth, it is necessarily focused on what the framework contains rather than stories and comments on how the framework has been used in varying environments. The first edition of DSDM: The Method in Practice was commissioned by the DSDM Consortium to provide a practical rather than theoretical view of the framework. It is now out of date since both the framework and the world in which the framework is used have moved on. Alongside the evolution of the framework, organizations are using it for many more types of project than it was originally designed, from business process change programs to advertising campaigns. This book will focus on application development projects but one case study shows the use of DSDM in a non-IT program.

Part I offers an overview of the framework as described in the online manual but more importantly it contains anecdotes and information from real projects. Part II contains some case studies that have been provided by participants in the projects described. They cover what their authors felt were important aspects of their projects. They are definitely a miscellany, being of varying lengths and of varying depth of description, but we hope that you will find something of value in each one. Part III provides information about how to contact the consortium, how to become a member, and how to access the resources of the consortium. In Part IV you can read about the birth of the Agile manifesto and find out where to go next.

About the Agile Software Development series

The Agile Software Development series highlights effective light, human-powered development techniques, based on two core ideas:

u Different projects need different processes or methodologies.

u Focusing on skills, communication, and community allows the project to be more agile and effective than focusing on processes.

Two books anchor the Agile Software Development series:

u Agile Software Development (Cockburn, 2002) describes the economic and psychological principles underlying agile development. It introduces two ideas, that a methodology is the set of conventions a development team agrees to adopt, and that systems and software development is fruitfully viewed as a resource-constrained co-operative game of invention and communication. From those views and principles, practitioners can select and personalize an agile approach for their local situation.

u Agile Software Development Ecosystems (Cockburn, 2002) describes the people behind the Agile Software Development Manifesto, the methodologies they developed, and experiences in using agile techniques.

The series has three tracks:

u Techniques to improve the effectiveness of a person who is doing a particular sort of job. This might be a person who is designing a user interface, gathering requirements, planning a project, designing, or testing. Whoever is performing such a job will want to know how the best people in the world do their jobs. Writing Effective Use Cases (Cockburn, 2001), Configuration Management Principles and Practices (Hass, 2002), and GUIs with Glue (Hohmann, in preparation) are technique books.

u Techniques to improve the effectiveness of a group of people. These might include techniques for team-building, project retrospectives, decision-making, or running effective meetings. Improving Software Organizations (Mathiassen, 2001) and Surviving Object-Oriented Projects (Cockburn 1998) are two group technique books.

u Examples of successful methodologies. Whoever is selecting a methodology will want to find one that has been successfully used in a similar situation. Personalizing that methodology will be easier than creating a new one from scratch and is more effective than using one that was designed for a different situation. This DSDM book and Crystal Clear (Cockburn, in preparation) are descriptions of tried methodologies.

You can find resources about DSDM and agile development on the Web. Specific sites and topics are included in the References at the back.

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews