Register your product to gain access to bonus material or receive a coupon.
DSDM: Business Focused Development, 2nd Edition
- By DSDM Consortium, Jennifer Stapleton
- Published Jan 13, 2003 by Addison-Wesley Professional. Part of the Agile Software Development Series series.
Book
- Sorry, this book is no longer in print.
About
Features
- Written by members of the DSDM Consortium.
- Discussion of how DSDM can speed up delivery of projects.
- Emphasis on the key techniques of DSDM, inclusing 'timeboxing' and 'MoSCoW Rules'
- Discussion of how agile methods such as DSDM can help deliver business benefits quicker.
- Discussion of how user involvement is imperative in delivering a usable solution.
Description
- Copyright 2003
- Dimensions: 7-3/8x9-1/4
- Pages: 272
- Edition: 2nd
- Book
- ISBN-10: 0-321-11224-5
- ISBN-13: 978-0-321-11224-8
The Dynamic Systems Development Method is a process that is used to deliver new software systems.
- Practitioner's guide addressing issues such as how to get people from different disciplines to work together as a team, how to gain commitment and how to manage projects within normal business constraints.
- New edition covers how to use DSDM with other methodologies such as Extreme Programming and UML.
- Updated case studies showing how DSDM is used in companies such as BT and British Airways.
- Based on best practices and lessons learned by DSDM Consortium members and is vendor independent.
- Members of the DSDM Consortium include Hewlett Packard, BT, British Airways, Ministry of Defence, PWC, Vodafone and KPMG.
User Level:
Professional
Audience:
Software developers.
Author Biography:
The DSDM Consortium aimes to produce and evolve the de facto approach to building systems both quickly and efficiently. In the UK, DSDM is the most commonly used method for RAD since it has repeatedly demonstrated success in organizations of all sizes. It is now gaining acceptace on a worlwide basis
Sample Content
Table of Contents
Contents at a Glance
Part I The Framework
Chapter 1 DSDM Process Overview
Chapter 2 The Underlying Principles
Chapter 3 The Process in Action
Chapter 4 Time Versus Functionality
Chapter 5 People Working Together
Chapter 6 The Agile Project Manager in Action
Chapter 7 Impact on the Organisation
Chapter 8 Never Mind the Quality?
Chapter 9 Prototyping is Not a Waste of Time
Chapter 10 The Agile Professional
Chapter 11 Extreme Programming (XP) in a DSDM Environment
Chapter 12 Technology Support
Chapter 13 Keeping the System Going
Part II Case Studies
Chapter 14 Implementing DSDM in e-BA
Chapter 15 DSDM and Eliminating the Contractual Divide
Chapter 16 DSDM in a non-IT Project
Chapter 17 An Object-oriented DSDM Project
Chapter 18 How DSDM can de-risk Offshore Working
Chapter 19 What Happens When it all Goes Horribly Wrong
Chapter 20 A Measured DSDM Project BT
Chapter 21 From DSDM Adhocracy to DSDM Factory
Chapter 22 DSDM in Process Improvement
Chapter 23 DSDM and Business Rules
Part III Information
Chapter 24 Where Do I Go From Here
Part IV Appendices
Appendix A e-DSDM, a Specialisation
Appendix B The Agile Manifesto
References
Preface
Background
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 important corners. 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 (http://agilemanifesto.org), 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. A starter set includes these sites:
u
www.DSDM.org is the home site for the DSDM Consortium, with news and leads to other resources.u
www.AgileAlliance.org describes the activities of the non-profit organization the AgileAlliance, and has links to agile development discussion groups around the world.u
www.Alistair.Cockburn.us/crystal holds a growing library of papers, sample work products and agile processes, and a discussion area for agile development topics.0321112245P11012002