This material (DSDM, Related Images, and Videos) was created by the Agile Business Consortium. https://agilebusiness.org

Think of Agile like a toolbox. Within this Agile toolbox, you have several options. You may not know what all the tools are, how they function – half the time your self-proclaimed Agile experts don’t even know. (not me though, I know it all).

Scrum is your Crescent wrench. It is great at what it does, it will even do more than probably intended. Sure, I have used a Crescent wrench like a hammer on several occasions, but is it the best tool for pounding a nail in? Well, it works, most of the time. Sometimes I miss and the nail head gets shoved up into the hole on the Crescent wrench, but I don’t feel like trying to find a hammer so I deal with it.

The point is, you need to study the toolbox. You need to learn what tools you have available before jumping in and just picking a tool that looks like it might work. Knowing what the tools are, what ability they have, and what operations they will perform is critical to choosing the right tool for the job. Your hammer is under the pliers by the way.

Picking the Right Tool For the Job

I am going to go over one of these tools and provide you with links to get more information. First, a couple of things to think about:

Do you find yourself trying to come up with a way to standardize the release of the products Scrum creates? (What happens when Scrum ends?)

Does the lack of a defined project manager role in Scrum cause you some concern? (it probably shouldn’t, but new things can be uncomfortable)

Are you afraid to drop everything and change your waterfall team into an Agile one?

Do you have a whole project or do you need to develop and deliver a product?

In this post, I will discuss one of those other approaches, the Dynamic Systems Development Methodology or DSDM. It just might be the tool you need for the job. Unfortunately, this is also where my toolbox analogy dies because I don’t know what tool to call DSDM. Hammer doesn’t seem quite right. DSDM seems more like a whole set of tools like maybe box end wrenches with a ratcheting end???

What is Dynamic Systems Development Methodology (DSDM)?

In Scrum, the focus is on creating the product. What you do after that product is created is not fully identified within the framework, as long as you create a potentially releasable product that meets the shared understanding of “Done” at the end of each iteration and deliver that product.

DSDM is intended to be more than just a framework for creating software development packages in increments. It is a full life-cycle approach with uses beyond software development projects. It includes the needed guidance to bring a product through the entire project, including the releases.

DSDM has some similarities with Scrum and some very large differences. Where Scrum defines 3 core roles, DSDM defines 9 core roles and 4 supporting roles. Your Sponsor, your Project Manager, and your Business Analyst are present in DSDM by name. You could almost take your existing waterfall team, tweak it a bit, and turn it into DSDM; it may be easier to use DSDM in your organization than Scrum.

You may find some of the terminology different between Scrum and DSDM, product backlog in Scrum is known as a prioritized requirements list in DSDM for example. DSDM has a set pre-project and post-project phase that line up well with a traditional predictive project management model, whereas these items are not defined in Scrum.

“Choosing an Agile approach that does not actually address all the needs of the business can introduce unnecessary risk into an organisation.” – Agile Business Consortium

Below, at the end of this post, I include some videos from the Agile Business Consortium that explain a few things about how you can use DSDM with Scrum. I recommend checking them out if you are curious about DSDM.

The Eight Principles of DSDM

As an introduction to DSDM, we will first look at the eight guiding principles. You may notice some similarities to Scrum and a few differences.

1. Focus on the business need
   1. You establish your business case and align it to your organizational goals
   2. You guarantee the Minimum Usable SubseT (MUST) – which is like the MVP
2. Deliver on time
   1. Use timeboxing to control your time
   2. Focus on the business priorities first
   3. Predictable delivery can build confidence
3. Collaborate
   1. Get the right people involved when needed during the entire project
   2. Push for pro-active involvement from the stakeholders
   3. Build a culture that revolves around being one team
4. Never compromise quality
   1. Define your level of acceptable quality at the beginning of the project
   2. Do not let quality become a variable
   3. Test early, test often, test continuously
   4. Constantly review the work and improve
5. Build incrementally from firm foundations
   1. Do Enough Design Up Front (EDUF) to create a strong foundation
   2. Re-assess priorities and ongoing project viability with each delivered increment
6. Develop iteratively
   1. Gain business feedback with each iteration
   2. Embrace and adapt to change, let the right solution evolve
   3. Detail should emerge later rather than sooner
   4. Encourage creativity, learning, and experimentation through iterative development
7. Communicate continuously and clearly
   1. Encourage informal communication at all levels
   2. Have daily standup meetings
   3. Demonstrate the evolving solution early and often and accept feedback
   4. Keep documentation limited and prepared when needed
   5. Manage stakeholder expectations of incremental deliveries throughout the project
   6. Be honest and transparent in all communication
8. Demonstrate control
   1. Ensure progress is visible to everyone
   2. Progress is measured by the delivery of products rather than completed activities
   3. Manage work and issues proactively
   4. Continue evaluating project viability based on the organization’s goals and objectives

In my opinion, I like number 5 the best, “Build incrementally from firm foundations.” It reminds me of the “software is like building a house” analogy. You lay down a solid foundation, working to ensure that what you build on top will be supported.

Read more about the DSDM principles: https://www.agilebusiness.org/page/ProjectFramework_04_Principles

Roles in DSDM

The roles within DSDM have more in common with a waterfall project than other major Agile approaches. If Agile is new, this could help provide a more comfortable transition and leave less open questions that revolve around a lighter framework.

The roles are color-coded by primary purpose or role type. Orange symbolizes roles that represent business interests. Green color-coded roles are for the technical staff, the people who contribute to the technical pieces of the solution. Blue means the management or leadership of the project. Gray symbolizes the process interests, those roles that help facilitate the project.

1. Project Level
   1. Business Sponsor
   2. Business Visionary
   3. Technical Coordinator
   4. Project Manager
2. Solution Development Team
   1. Business Analyst
   2. Business Ambassador
   3. Solution Developer
   4. Solution Tester
   5. Team Leader
3. Supporting
   1. Technical Advisor
   2. Business Advisor
   3. Workshop Facilitator
   4. DSDM Coach

Project Level

The Business Sponsor Is the senior project-level business role. He or she is the project champion and responsible for the business case and project budget. Their position should hold enough power within the organization so that they can help resolve business issues and make financial decisions.

The Business Visionary is meant to be very involved with the project, helping to create the business vision of the solution. They are required to help keep a single clear vision as the project moves forward.

The Technical Coordinator is the project’s technical authority. They work to ensure that the other technical roles work in a coordinated way. The Agile Business Consortium describes the role as providing “the glue that holds the technical aspects of the project together while advising on technical decisions and innovation.”

The Project Manager is tasked with providing an “Agile-style leadership”. This would make the Project Manager a servant-leader, not an authoritarian leader. A regular Agile Project Manager. The Project Manager should lead a self-empowered team using facilitation rather than a commanding approach to leadership.

Solution Development Team (SDT)

The Business Analyst supports Project Level roles as part of the Solution Development Team. It is a relationship facilitation role, bridging gaps between the SDT and the Project Level and between the technical/solution developer roles and the business roles. They give guidance to the SDT to assist in solution development.

The Team Leader is a servant-leader for the SDT. They are tasked with ensuring goals are met and working with the team to coordinate solution development and delivery. This role will ideally be an elected role, chosen by members of the SDT, as such they may also be performing one of the other roles on the SDT.

The Business Ambassador represents the business needs within the SDT. They provide daily requirements to the team during Evolutionary Development, being the primary decision-maker for the business.

The Solution Developer translates the business requirements into a Solution Increment that meets the needs of the increment. This should be a full-time role dedicated exclusively to the project to help reduce risk and waste.

The Solution Tester is tasked with making sure the solution works, testing to the decided standards.

Supporting

The Business Advisor’s role is to help ensure the testing of the solution meets the business needs. They may be a Subject Matter Expert and/or a future user of the solution, or they may provide regulation and legal advice.

The Technical Advisor provides technical support for the solution. They may be responsible for operational changes, assisting with the release, or ongoing maintenance of the solution.

The Workshop Facilitator will manage the workshop process. They are responsible for organizing meetings that achieve a workshop objective.

The DSDM Coach is responsible for helping the team understand the DSDM approach. They are there to ensure that DSDM is followed and to help those outside the team understand the process. They provide the details of DSDM.

DSDM Project Management Roles and Responsibilities

Read more about the DSDM roles: https://www.agilebusiness.org/page/ProjectFramework_07_RolesResponsibilities

The DSDM Lifecycle

There are 6 phases to the DSDM Lifecycle designed to take you from project inception to project end. If you recall from the 8 principles of DSDM, one of the principles is “Focus on the Business Need” which starts in the pre-project phase where you make sure projects are aligned with business objectives.

DSDM Phases

1. Pre-Project
2. Feasibility
3. Foundations
4. Evolutionary Development
5. Deployment
6. Post-Project

Pre-Project Phase

During the Pre-Project phase, you make sure projects are set up based on a clear objective. You must ensure that resources exist to begin the project’s feasibility stage. This phase would be carried out at a program or portfolio level. It is a gateway of sorts, ensuring projects are ready to begin based on the objective and business goals.

Feasibility Phase

Are the projects feasible? During the feasibility phase, you want to make sure projects are technologically possible and cost-effective. You do just enough to determine if further planning is acceptable to the organization’s goals.  This would be a high-level investigation of the technical requirements that would be needed for the project and solution, and whether it makes sense from a cost stand-point to continue with the project. You create rough estimates of completion time for the entire project, with a Delivery Plan to describe the Foundations Phase.

Foundations Phase

During Foundations you expand upon the work started in Feasibility. You create a basic understanding of the organization’s needs and how this project aligns with those needs. The idea here is to get a picture of the scope of work needed for the project and lay the foundation for defining it and estimations for completing items within the project, using ranged estimations if needed.

MoSCoW prioritization can be used to help decide where the priorities are. MoSCoW is a way of categorizing the features for the solution/product into  “Must Have”, “Should Have”, “Could Have”, and “Won’t Have this time” categories. MoSCoW prioritization is explained in greater detail here: https://www.agilebusiness.org/page/ProjectFramework_10_MoSCoWPrioritisation.

Planning in Foundations centers around:

• A strategy for deployment
• Development approach
• Schedule of timeboxes (rough idea of how many iterations and the duration of each iteration)

By the time the Foundations phase ends, you should be able to commit to at least the delivery date for the first increment and describe what it may consist of.

Evolutionary Development Phase

Now that you have built your project’s firm foundation, you should be ready to begin the iterative development cycle. The right solution should evolve over time.

Evolutionary Development makes use of timeboxing to control the iterations, with each iteration releasing a completed piece of a much larger whole. MoSCoW prioritization can be used with each timeboxed iteration to prioritize the items to be worked on (your iteration backlog).

Deployment Phase

You can either deploy the whole solution, which may make sense in some scenarios, or you can deploy small pieces of the solution with each loop through an iteration in evolutionary development.

The Agile Business Consortium provides these examples:

• Business change – introducing a new way of working in a factory (deploying a business change as a single release)
• The early deployment of a corporate intranet, providing a limited number of features, with more features to be provided later (deploying the first release of many)
• A complex product – e.g. the launch of a new mobile phone, bringing together parts of the solution from multiple projects run in different locations (deploying a new product as a single release)

Within Deployment, there are three sub-phases or sections; Assemble, Review, and Deploy.

In Assemble, you would perform those activities required to put all the pieces together. This may be integrating a chunk of software or laying out how a new business process fits within the processes around it.

The Review section is about making sure things work and getting approval to deploy the product. During this time you would also carry out a retrospective for the increment, sort of like a “lessons learned” session in a traditional project but aimed at looking back on the prior iteration.

The Deploy section is where you release the product or solution. It is when the work carried out in the iteration (or the entire project if you chose to release that way), is made available for everyone to use.

Post-Project Phase

When all of your iterations are complete and you have a solution or product fully developed, your project is complete and you enter the Post-Project Phase. In this phase, you determine if the expected benefits have been actualized – keeping in mind that the benefits may accrue over time.

During Post-Project, you would also carry out a retrospective for the entire project. The idea being a way to discuss what went well during the project and what could have gone better, and to reflect upon ways to improve in future projects.

Read more about the DSDM process:https://www.agilebusiness.org/page/TheDSDMAgileProjectFramework

Read more about the DSDM planning in the phases: https://www.agilebusiness.org/page/ProjectFramework_16_ProjectPlanningandControl

Reflection

I feel like I say this a lot, (because I do) Scrum is not the only Agile approach. Too often people try to define Agile by what Scrum is, and they don’t do a good job of it. It is like trying to define a restaurant by what McDonald’s is. I have no problem with McDonald’s, but sometimes I need a nice full-service sit-down restaurant. (that works much better than the toolbox analogy, I should have started with that.)

You have lots of options when it comes to choosing an Agile approach. I like DSDM because it can provide a similar infrastructure that many are already familiar with. It answers questions about how to handle an Agile project that Scrum does not. Scrum is great, I am not attacking it, but each one has its time and place for use.

Please take a look at the below videos from the Agile Business Consortium for more information on DSDM.

Practice your DSDM skills with the AgilePM Mock Exam based on DSDM: DSDM – AgilePM Practice Questions

For More Information: The DSDM Agile Project Framework

Videos from the Agile Business Consortium: What is DSDM

What is DSDM from Agile Business Consortium on Vimeo.

Designed To Integrate from Agile Business Consortium on Vimeo.

How Does DSDM Work from Agile Business Consortium on Vimeo.

Sources:

Agile Business Consortium: The DSDM Agile Project Framework

Scrum Guide: http://www.scrumguides.org/scrum-guide.html#events-review

Images, Videos, and DSDM from the Agile Business Consortium: https://www.agilebusiness.org