Combining-AgilePM-AND-DSDM-WITH-SCRUM

Combining AgilePM/DSDM with Scrum

Introduction In the late-nineties Agile was still a niche area that mainly existed in the IT domain.

Today, however, increasing numbers of organizations are adopting Agile practices as they seek to gain advantages in product development, project management, efficiency and competitiveness.

DSDM and Scrum were two of the original and most prominent Agile frameworks at the start and they are still around today, although DSDM is now more commonly known as AgilePM (Agile Project Management).

This white paper (alongside a supporting webinar - https://tinyurl.com/yyvzbe3n) examines the merits of each method and the potential advantages of combining them.

AgilePM/DSDM AgilePM is a project management framework that is based upon DSDM which used to stand for the Dynamic Systems Development Method. As Agile evolved out of the IT arena it was decided to drop the link to ‘Systems Development’ and it was then simply referred to as DSDM. The project framework involves many components that provide rigour and structure when delivering projects in an Agile way. These components cover areas such as behaviours and mechanics as illustrated in the ‘the Greek temple’ diagram.

Importantly it addresses the key elements (e.g. processes, roles and deliverables) to support all stages of an Agile project’s design and execution. An additional example of this is the upfront work required before delivery of the project takes place. In AgilePM/DSDM this involves two phases: Feasibility and Foundations. There are a handful of techniques or ‘practices’ also included in AgilePM, the most prominent being timeboxing and the MoSCoW prioritization technique.

Since its introduction in 2010, AgilePM has quickly established itself as the world's leading framework and certification for Agile project management.

Scrum Arguably the most popular and widely adapted Agile framework, Scrum is now available in over 30 different languages. It’s a framework for product/solution development within which people can address complex adaptive problems, enabling the development of high quality and high value solutions.

Perhaps surprisingly, Scrum is very simple to understand and is defined in less than 20 pages in ’The Scrum Guide’. The framework is made up of products (artefacts), roles and events with ‘the sprint’ at the heart of this timeboxing approach.

Due to its simplicity the framework should only be used to develop new and evolve existing products. The framework should not be used to manage a project as it does not address the usual up-front activities associated with launching and managing the lifecycle of a project.

Horses for courses Although there are similarities between the two frameworks, they operate in very different environments. Scrum’s natural territory is in a product environment, whereas AgilePM/DSDM is designed to operate in a project environment.

It is quite normal for organizations to use both frameworks as they have business-asusual (BAU) work to do, as well as the need to address complicated pieces of work that are temporary in nature (i.e. projects).

It is important that each approach is used in the right context. In a similar way to the old saying about racehorses, you need the right horse at the right course.

Combining the two approaches There are advantages to combining AgilePM with Scrum but to understanding the benefit of doing this, it is key to understand the context (or environment) in which you intend to use them.

If the work is simply BAU then AgilePM has little-to-no role to play. If, however, the work is a project then AgilePM can (and indeed should) be used. They can both be used if there is a desire to use AgilePM as the structure for managing the project aspects of the work, whilst Scrum is used ‘within’ AgilePM to handle the product delivery / solution development elements of the project.

A project always delivers something - be it a product or output – which needs to be created by individuals and teams with the necessary skills required for creating the desired products/solutions. A project management framework typically does not involve guidance on the technical aspects of delivery. This is because project management frameworks are usually designed to be generic so that they can be tailored and applied to any project.

However, AgilePM contains a lot of guidance on timeboxing and prioritization so it could be said to already include mechanisms that can manage the product/solution delivery aspects. This actually mirrors the job carried out by Scrum so there is a strong argument that AgilePM can be used without the need to use Scrum at all because most, if not all, elements of Scrum are already in AgilePM (e.g. stand-ups, planning meetings, review meetings).

On this latter point, the question facing those looking to combine AgilePM with Scrum is a lot do to with the terminology being used. Many of the events and products have names that are synonymous (e.g. stand-up meeting/Scrum meeting, sprint/timebox).

Be careful about what you are trying to solve!

This white paper (alongside the supporting webinar - https://tinyurl.com/yyvzbe3n) provides several options on how to combine AgilePM and Scrum. Before embarking on a journey to combine the two, it is important to look at where you are first.

Are you using AgilePM and looking to become more aligned to Scrum for product delivery? Or are you familiar with Scrum but looking to wrap an established project management framework around it for use on complicated pieces of work (i.e. projects)?

Either of these scenarios can lead to an effective combination of the two. However, if AgilePM is working well – and the use of timeboxing terminology with AgilePM is not presenting any cause for concern – then don’t fix a problem that does not exist.

A final thought‌.

A good analogy to think about when considering combining AgilePM and Scrum is the fork and spoon. They do very different jobs, but they can be used effectively in tandem.

If you eat spaghetti with a fork, you should be fine, but eating soup with a fork is likely to prove problematic!

The key to the successful use of both is to use them in the right way and in the right environment. Sometimes this will be just AgilePM on its own, sometimes it will be Scrum on its own, and sometimes it can be using them both together.

Just like a fork and a spoon!