Chapter 2: Choosing DSDM

2 Choosing DSDM as your Agile Approach

2.1 RAD and Agile - How It All Started

When DSDM was created in 1994, the world of solution delivery through projects was very different from how it is today. For example, the corporate world predominantly used a traditional (Waterfall) approach. Far too many of these projects were failing, for a variety of reasons, but mainly because projects were just too big, and too long, communication was poor and progress was measured in percentages, rather than deliverables. When projects did deliver, they often delivered late, and often delivered the wrong thing, due to lack of on-going business involvement and reliance on specifications which tried, and usually failed, to capture and fix detailed requirements right at the start.

To counter these problems, some projects had tried a completely different approach – Rapid Application Development (RAD) - with users of the solution working closely with developers to iteratively and incrementally build software applications, not based on a formalised specification, but on discussions, demonstrations and short feedback loops. This addressed many of the problems of the traditional approach but, in doing so, it introduced a whole new set of problems, particularly around the supportability and scalability of the solutions. RAD provided quick fixes but often its application adversely affected the quality of the solutions because the disciplines of analysis and design were thrown out with the up-front phases that used to contain them.

At that time, DSDM was launched to address the problems of the traditional approach (too slow, too big, not transparent enough, not enough on-going business involvement) as well as the problems introduced by RAD (focus only on speed and quick fixes, no focus on quality, no view of the big picture issues). DSDM achieved this by recognising that both approaches had strengths and areas for improvement, and that to be effective in all environments requires the ability to deal with wider context issues as well as the here and now. So DSDM brought together the best parts from a traditional approach (control and quality) and from RAD (good communication, business involvement, transparency).

The term “Agile” was first used in 2001 after a group of like-minded people, including Arie Van Bennekum from the DSDM Consortium, agreed to meet for a weekend in Snowbird, Utah. At this meeting, they acknowledged that they all shared common values and ways of working and agreed a formalised set of those values and 12 supporting principles that defined an Agile way of working. This new way of working is fundamentally different in style from the traditional Waterfall approach that dominated the world of IT projects at the time. From this meeting sprang the Manifesto for Agile Software Development, and a group called the Agile Alliance, which still exists today. In recent years, the use of Agile has grown significantly.

2.2 DSDM, Agile and the Agile Alliance

Ever since its launch in 1994, DSDM has been at the forefront of scalable Agile projects and solution delivery. DSDM is equally effective on small straightforward solutions or large complex corporate projects. DSDM has been used effectively on non-IT solutions and is not just about development of software. DSDM is often referred to as “mature Agile”, since it grew up with a strong base in the corporate world of projects from 1994 and retains a strong project focus in the 21st century.

As a founder member of the Agile Alliance, DSDM has been at the heart of Agile since 2001. The philosophy and principles of DSDM helped shape the Manifesto for Agile Software Development, although DSDM takes the concept of Agile far wider than just software. The DSDM Agile Project Framework fully adopts the values laid out in the Manifesto.

Individuals and interactions over processes and tools

In an Agile project, great emphasis is placed on the team. Every individual in the team is expected to be ready, willing and able to play their part in the project, carrying out their role with competence and professionalism. Every member of the team is expected to work collaboratively with everybody else, using his or her knowledge, experience and judgement to shape a project outcome that best meets the need of the sponsoring business. Processes and tools play an important part in any project but much less emphasis is placed on these in an Agile environment. Agile processes need to be light touch and serve to guide and support rather than dictate what individuals and teams do and how they should do it. The assumption is that the team is best placed to understand what needs to be done and to work out the best way of doing it. DSDM provides appropriate light touch guidance on roles and responsibilities, whilst keeping the emphasis at all times on the people and the way they work together.

Working software over comprehensive documentation

The choice of words used here reflects the origins and primary focus of Agile – a focus solely on software delivery. However, changing a single word - “software” to “solution” - elevates this value from delivery of a software product to encompass the broader context of business change projects and often this is the interpretation for DSDM. DSDM has been proven to work equally well for non-software projects.

The message behind this Agile value is to break the illusion of security and stability that comes from document-driven processes. Specification of every detail of requirements, solution design, plans etc. in documents that get ‘signed off’ by stakeholders before work is allowed to progress is both wasteful and ineffective. DSDM embraces the need for high-level versions of these artefacts in the early phases to frame development and delivery projects and to support governance. After the Foundations phase in a project, the framework employs collaborative techniques with active business engagement to ensure that the right solution is delivered. The framework also advocates light and timely documentation to support the solution in production beyond the end of the project.

Customer collaboration over contract negotiation

This Agile value encourages project teams and the sponsoring business to work collaboratively at all times. Typical commercial contracts assume that a traditional Waterfall process underpins development and ‘a fixed price for a fixed specification’ is the standard for project contracts. Agile projects emphasise collaboration, and therefore contracts need to reflect this.

A contract can be as formal as a document signed by those responsible for sponsoring the solution and by those delivering it, or as informal as a shared verbal agreement on what is to be delivered. Regardless of formality, it is important to ensure that, where created, all parties follow the principle of such documents or agreements being ‘light touch’ and ‘guiding’ rather than being ‘detailed’ and ‘prescriptive’. By this definition, DSDM’s Prioritised Requirements List may represent a contract, effectively defining the scope of a project. However, as it is at a high level, it requires customer collaboration with less formality to expand on the detail of requirements throughout the iterative development of the solution during the project lifecycle.

Responding to change over following a plan

This Agile value emphasises the fact that the world around a project is rarely frozen in time. Change occurs so quickly in the world of business now. that adopting an approach to building a solution which accommodates, or ideally embraces, change is likely to be the only way to a successful outcome. Change may also arise as a result of an emerging understanding of what is needed, what is valuable and even what is possible. The degree of change in detail that is typical of most projects makes creating detailed, long-term plans a waste of time. Where change is normal rather than the exception, the high-level ‘light touch’ and ‘guiding’ plans advocated by DSDM better meet the need of a flexible business.

And the very important final sentence

The DSDM Agile Project Framework specifically embraces the last sentence in the Agile Manifesto that clearly states, in the context of the values above

“That is, while there is value in the items on the right, we value the items on the left more.”

It is important not to ignore processes, tools, documentation, contracts and plans but instead to ensure that they are only created where they add value, and only to the level of detail that adds value. They should be created in a form relevant to and taking full advantage of the Agile values.

2.3 How Does DSDM Differ From More Traditional Approaches?

DSDM is a vendor-independent approach focused on helping people to work effectively together to achieve business goals. It can be used in any business, in any technical environment for any project.

A fundamental assumption of the DSDM approach is that nothing is built perfectly first time, but that as a rule of thumb 80% of the value of the solution can be delivered for 20% of the effort that it would take to produce the total solution (Pareto’s Principle). A basic problem with less Agile approaches is the entirely unrealistic and unreasonable expectation that those responsible for specifying a solution can predict what all their requirements will be at some distant point in time and in exact detail. This problem is compounded by the fact that a new solution as it evolves is a stimulus for change, as understanding of the impact the solution will have on the target business grows.

In the traditional, sequential (or ‘Waterfall’) approach, the next step cannot be started until the current step is completed. In practice, a lot of time is wasted in each step aiming for perfection when actually an 80% solution would probably suffice. The additional effort to achieve 100% is justified on the basis that no step ever needs to be revisited if it was completed ‘properly’ first time around. In reality, considerable time is spent going back to ‘completed’ steps and unravelling the defects from work that has previously been accepted but was based on assumptions that turned out to be either false or which simply changed over time. The result of this potentially tortuous rework of detail is that projects are delivered late and over budget (if the rework is successful) or they fail to meet the business need (if the rework is avoided or rushed).

In DSDM, the iterative approach encourages detail to emerge over time; therefore, the current step needs to be completed in only enough detail to allow the project to move to the next step with any shortfall in detailed understanding being dealt with in a subsequent iteration of development. There is also a very strong likelihood that the business requirements will change over time, and that such change is most likely to happen at the detail level. This being the case, the effort spent on detailed up-front work is very likely to be wasted. In addition, solutions built using the DSDM approach address the current and imminent needs of the business rather than, for example, the traditional approach of attacking all the perceived possibilities.

The resulting solution is more likely to have a better fit with the true business needs, is easier to test and easier to integrate into existing and emerging business processes. The development cost of most solutions is only a small part of the total lifecycle costs; it therefore makes sense to build simpler solutions that are both fit for purpose on the day of delivery and easier to maintain and modify thereafter. This is preferable to trying to implement a more extensive solution that has been complicated and often compromised by failed attempts to predict future business needs.

2.4 How Does DSDM Differ From Most Agile Approaches?

In addition to addressing many of the problems inherent in a traditional approach, DSDM also addresses many of the general concerns about Agile development. Specifically, DSDM requires basic foundations for the project to be agreed at an early stage. This allows businesses to understand the scope and fundamental characteristics of the proposed solution, and the way it will be created, before development starts. Clarifying and agreeing the foundations for the project from the combined perspectives of business, solution and management reduces the likelihood of nasty surprises on DSDM projects. In particular, for larger corporate organisations or organisations with a complex architecture and/or governance standards, agreeing the foundations early in the project is essential.

DSDM also describes a broader set of roles than most Agile approaches giving it a better fit with most corporate environments without compromising Agility.

2.5 How DSDM Addresses Key Project Problems

Managing any business change or developing any solution is rarely a simple task. Certain problems occur regularly whenever people from multiple disciplines work together on a project. DSDM is specifically designed to address many of these well-known problems. The following are seen as the key problems.

The Issue	How DSDM Helps
Ineffective communication	Poor communication is highlighted time after time as a major failing on projects. Establishing clear and concise communication between the different areas and levels of an organisation is not easy. DSDM provides a lot of guidance to strengthen communication and uses practices that encourage this to be visual and verbal wherever possible. DSDM’s emphasis on human interaction (e.g. through the use of workshops), visualisation (e.g. through the use of modelling, prototyping and iterative development) and clearly defined roles is at the heart of excellent project communication. In particular, visualisation has proved to be a far more effective way of communicating than the use of large, textual documents, passed from one person to another, and sometimes used to apportion blame when an unworkable solution has been delivered.
Late delivery	Slippage of the promised completion date often causes much frustration, as well as having a detrimental impact on a business. DSDM sees this issue as one of the most important problems to address. The DSDM approach, and many of the practices it exploits, are focused on delivering on time. Being on time applies to short-term goals as well as to the project as a whole. If there is ever a need for compromise on a project, DSDM advocates that revising the scope of what is delivered should always be considered ahead of a extending the deadline. Under most circumstances the vast majority of the benefit of a solution can still be gained from a solution with the less important features left out.
The delivered solution does not meet the business needs	Another frustration arises when a solution is delivered which doesn’t meet the expectations of the business. It may have features that don’t do what the business really wanted it to do, or contain errors which prevent the deliverable from performing smoothly, or it simply might not be properly aligned with business processes. In DSDM, bringing the correct understanding of the needs of the business into the project is of paramount importance. To ensure that this is achieved business representatives are included as part of the Solution Development Team and DSDM encompasses practices which encourage collaboration and enable visual and verbal communication. Most importantly, DSDM teams are encouraged to embrace change, allowing them to deal with problems and opportunities that occur, to encompass new ideas that appear and to build the solution based on a deepening understanding of the solution detail.
Building the right thing – the business changing their mind	A frequent cry from those building the solution on a traditional project is that ‘the users have changed their minds’. Far from being a problem, DSDM embraces change and believes that change often arises as the result of a deepening understanding or an unavoidable external event. DSDM capitalises on the greater depth of understanding and so ensures that the Deployed Solution meets the true business need. DSDM enables change through iterative development, with regular reviews to make sure what is being developed is what the business really needs. Requirements change is a natural result of a better understanding: DSDM expects it and plans for it.
Unused features	Research has highlighted that a relatively low percentage of features delivered as part of the overall solution developed using traditional approaches are actually used. This often happens because the business is encouraged to define all of its possible needs and wants at the outset of a project. By helping the business to prioritise its needs as understanding of the detail grows, DSDM keeps focus on what is important. This also avoids causing delays to a project by developing features that are never used.
Delayed or late Return on Investment (ROI)	Usually, the business value of a feature decreases over time and therefore delivering everything towards the end of a project may reduce the ROI. DSDM uses incremental delivery to get the most important and most valuable features released to the business as early as is practical. When appropriate, it can aggressively harness techniques such as vertical prototyping in order to deliver a subset of the total solution to the business very early and therefore to enable early return on investment.
Over-engineering (‘Gold plating’)	There is normally a diminishing return (on value) when trying to make a deliverable ‘perfect’. Usually the highest business value can be derived by getting something that is ‘good enough’ into a window of opportunity for the business. Indeed, sometimes the entire window of opportunity may be missed and no value at all delivered. DSDM is a pragmatic approach which focuses on the real business need in order to dissuade a team from being tempted to add the final extras which the business could live without. Prioritisation ensures the whole team are clear about the relative importance of the work to be done and that low value ‘polishing’ of the solution does not impact deadlines and compromise ROI.
“Fragile” Agile	Many organisations have adopted Agile behaviours and approaches but have done so in a very casual and disorganised manner. In an attempt to reduce the burden of bureaucracy, they have gone to the other extreme and created a very ad hoc situation which is typified by poor discipline, little documentation and a general feeling of chaos. DSDM helps here by placing the right Agile concepts and constructs in a structured and controlled framework that enables a project to respond to change and stay in control, whilst still being fully Agile.
Waterfall dressed up as Agile	A common mistake made when transitioning to Agile is to use the iterative and incremental way of working but constraining it by applying an overall Waterfall project lifecycle. The most common example is where iterative and incremental timeboxed development follows on from traditional analysis and design steps in the waterfall and is followed by a traditional testing step. Whilst this may appear at the team level to be Agile and is probably more efficient than a big poorly controlled block of development activity, it fails to exploit the full potential of early delivery of real business value and does not mitigate the risks associated with inadequate business engagement. DSDM does just enough work up front to ensure clarity of objectives and to provide a foundation for solution development. This foundation is agreed before breaking the project down into Increments and within that to Timeboxes, ensuring the appropriate elements of detailed analysis, design, build and test at each level. Active engagement of business roles in the detail of development ensures the right solution evolves. This, in combination with the limited up-front work creates a truly Agile way of delivering benefits to the business.

"In general DSDM is very proactive in its nature with regard to these kinds of risks."

2.6 Why Choose DSDM As Your Agile Approach

There are a number of Agile approaches available, and although all support an iterative style of working with continuous business involvement, beyond that, the focus is different. Choosing an Agile approach that does not actually address all the needs of the business can introduce unnecessary risk into an organisation.

DSDM has a broader focus than most other Agile approaches in that it deals with projects rather than just the development and delivery of a product (typically software). The project context requires a focus on the wider business need and all aspects of the solution that evolves to meet that need. DSDM has a long track record of successful Agile project delivery in all types of corporate environments, and has proved to be fully scalable, working effectively in small simple businesses, large, complex organisations and in highly regulated environments. It also has been shown to be equally effective for both IT and non-IT projects, for example business change projects.

DSDM may also be used to supplement an existing in-house Agile approach, where this has proved to be lacking. For example, DSDM is often used to provide the full “project” focus to complement Scrum’s team focussed product development process. The Agile Project Management and Scrum pocketbook provides guidance on this particular combination.

DSDM also takes a pragmatic approach, recognising that it often needs to work alongside existing standards and approaches. Examples of this are DSDM with Prince2, DSDM with ITIL, DSDM with formal quality processes, such as ISO or CMMI and DSDM with a PMO.

DSDM is not only about developing new solutions; projects to enhance existing solutions are also well suited to the DSDM approach.

The ethos of DSDM and the Agile Business Consortium is to embrace and partner with the Agile community at large. We recognise and value the various Agile approaches and practices and believe that good Agile can be a single or blended approach, whichever is the right solution for your project environment. As the use of Agile increases, new ideas surface frequently, and this is why DSDM sees the need to evolve and embrace the wider Agile community for the greater good and to continually improve what is seen as best practice.

2.7 Summary of the Benefits of Using DSDM

Using iterative development, DSDM involves the solution’s business stakeholders throughout the project lifecycle. This has many benefits, for example:

The business is more likely to feel ownership of the solution as it evolves and, most importantly, as it transitions into live use
Prioritisation will enable a project to be delivered on time whilst protecting the quality of what is being delivered
The risk of building the wrong solution is greatly reduced
The final solution is more likely to meet the real business need
Deployment is more likely to go smoothly, because of the co-operation of all parties concerned throughout development

DSDM specifically addresses many of the problems which cause projects to struggle or to fail. For many organisations, having the ability to deliver working solutions consistently, on time and on budget, is seen as a major step forward. DSDM will provide this.

Next chapter: 3 Philosophy and Fundamentals