Dynamic Systems Development Method (DSDM)

Finally, the Dynamic Systems Development Method (DSDM) methodology refers to an organized and commonsense driven process that prioritizes fast and efficient delivery of business solutions to clients. In many different ways, it is comparable to XP and Scrum, but its single best advantage over the two is it’s the best methodology where timelines are fixed.

Instead of simply focusing on development teams’ activities, DSDM makes the delivery of solutions to its client its primary focus. This methodology does what’s necessary to make sure that every project’s business sense and feasibility have been established prior to designing and implementing. Collaboration and cooperation among all stakeholders are emphasized under the Dynamic Systems Development Method, and to make sure all those who are concerned have a very clear idea of all the important aspects of a particular system, it conducts a lot of prototyping.

DSDM grew because of the need for a standardized framework for delivering projects for a popular project development methodology during the early 1990s, which was called Rapid Application Development or RAD. Despite RAD’s massive popularity during those times, its software delivery methodologies were lacking in structure.

Because of a lack of such structure, The DSDM Consortium was born and assembled in 1994 for the purpose of coming up with and promoting a standardized or structured rapid software delivery system for the industry. And since then, DSDM – as an Agile project management methodology – has morphed and grown into a comprehensive and iterative Agile project planning, management, execution, and scaling methodology for developing software.

This methodology is grounded on 9 important principles that are built around business needs: high user involvement; team empowerment; frequent delivery; assimilated testing; and collaborations with stakeholders. These 9 principles are:

1. Active involvement of end-users
2. Empowered project teams
3. Repeated releasing and updating of iterations
4. Business needs-driven software development processes
5. Incremental developments
6. Acceptance of change
7. High level of initial requirements
8. Efficient integration of testing and development, with emphasis on creation of small teams with very good communications among teams and members of such teams
9. Putting great importance on cooperation and collaboration among stakeholders.

While the Dynamic Systems Development Method is one that is perfectly capable of being implemented by itself, it can also work well other Agile methods like eXtreme Programming (XP).

DSDM Benefits

Using DSDM as a primary Agile project management system can provide significant benefits to any organization. These include:

• Swiftly and directly visible development results
• High end-user acceptance of developed systems because of their significant active participation in the development process, which gives them a sense of ownership over such systems
• Swift delivery of basic features or functionalities, and regular delivery – at intervals – of additional ones
• Minimal, if any, communications barrier between stakeholders because of minimal or no bureaucracy
• Much higher chances of developing systems that meet clients’ needs, or even exceed them, because of regular communications with end users and frequent receipt of feedback from the same
• The ability to evaluate whether a project will be able to successfully meet or exceed clients’ needs and expectations early in the development process instead of having to wait for having a significant portion of the development completed before being able to do so
• Timely and cost-efficient delivery or systems and solutions
• End users have the opportunity to steer systems development in directions that are best aligned with their interests.

Let’s take a look at what’s possibly the most popular version or variant of the DSDM – Atern.

DSDM – Atern

The Dynamic Systems Development Method or DSDM is possibly the most senior Agile methodology around, being launched in 1995 and as such, is the only Agile methodology that concentrates on managing Agile projects.

Over the years, DSDM continued to evolve and the latest model or evolved version of this Agile methodology is Atern, which is an Agile project delivery framework that provides timely delivery of needed solutions to clients. Atern – as a project management methodology – is able to do this because Atern project teams operate under the guidance of 8 key principles, which are:

• Concentration On Business Needs: Each decision made in every project must be done so with clear ideas of a particular project’s main goal, i.e., what the client needs to have delivered, and when such needs need to be delivered. It’s crucial to keep in mind that the project itself is not the be-all-and-end-all but simply a means to achieve a goal, which is meeting clients’ needs.
• Timely Delivery: Often, timely delivery of products is considered to be the most important factor when it comes to successful completion of projects because in many instances, late delivery can render the development of projects practically useless, most especially when strict legal deadlines and fleeting business opportunities are involved.
• Collaboration: Teams whose members are highly committed and actively cooperate with each other will always trump a team of loosely connected members. With high levels of collaboration come better understanding, faster completion of tasks, and a strong sense of accountability and project ownership that can result in a high level of member synergy.
• No Compromise On Quality: Under the Atern method, the expected quality level of systems for development and eventual delivery are established from the get-go. With a clear expectation of quality for delivery, all efforts are geared towards achieving – or even exceeding – the expected quality level. In other words, solutions developed under the Atern methodology must be at least “good enough” based on clients’ expressed needs and quality expectations.
• Firm Foundations For Incremental Development: Atern is big on incremental delivery, i.e., delivery of solutions in smaller but more frequent iterations. The reason for this is simple: early delivery of real and practical business benefits. Incremental delivery makes stakeholders, especially the end-users, confident about the solutions being developed because of their regular feedback to developers, and leads to better succeeding iterations because of such feedback. With the regular deployment of incremental builds, clients have the opportunity to much more quickly enjoy the benefits of solutions being developed instead of having to wait to receive the entire solution in one big, final version. And incremental delivery – with feedback from end-users for every increment – provides information that can help make succeeding iterations even better.
• Iterations-Based Development Of Solutions: Using an iterative approach to developing business solutions allows Atern teams to provide solutions that are able to accurately meet end-user customers’ needs. The concept of iteration is nestled throughout any Atern project’s life cycle. It’s unusual for systems or solutions to be perfectly built and get everything right just on the first try or delivery and practically all projects experience change in one way or another. In order to effectively ride the waves of change and to be able to come up with optimally effective solutions, the Atern methodology encourages an iteration-reliant and realistic approach to dealing with changes. Through this, the Atern methodology is able to ensure that solutions developed will be able to meet clients’ needs.
• Clear And Continuous Communications: In most cases, projects fail because of horrible communications between team members, teams, and stakeholders. Techniques used in the Atern methodology were particularly made with the intention of – among others – to make communications more free-flowing, unimpeded, clear, and effective not just among teams but most especially among individuals. Through things like Stand-ups and Facilitated Workshops, user involvement in the development processes, and clearly defined roles, Atern emphasizes the importance of human interactions, which can often be much more effective at getting things done optimally compared to largely textual communications with very little or no human interactions.
• Exercise Of Control: For any project to be successfully completed, team leaders must exercise a great degree of control. Within an Atern environment, teams have to be proactive instead of reactive when it comes to progress monitoring and control. Otherwise, things may not go as planned or worse, get out of hand.

Project Variables
Projects usually have four parameters within which they’re managed: quality, features, cost, and time. It would be impractical or unrealistic to ensure all parameters are fixed from the get-go. In fact, doing so is one of the reasons why many projects encounter delays or worse, bog down and don’t get completed.

For example, only the features of a solution are fixed when it comes to traditional or non-Agile project management systems, while cost and time are considered to be variable. Thus, additional resources or extensions to project delivery times are required when projects go off track.

But here’s the thing: merely adding more resources to a project that’s already late only makes it, well, later! From a business and credibility perspective, unmet project deadlines can be fatal. At this point, quality can also be affected, making it variable factor as well that’s dependent on cost, delivery, and late delivery.

But such isn’t the case when using an Atern project management methodology, which is able to address the quality, cost, and time issues during the Foundations Phase and the issue of contingency is managed well by tweaking a to-be-delivered solution feature.

And as is the case when contingency measures are needed, lower or low priority features may be removed or postponed upon the express agreement of everyone concerned in order to successfully and promptly deliver solutions. In the end, Atern projects will always be able to deliver working solutions.

Suitable Levels Of Formality
At the core, the Atern project management methodology needs to identify the appropriate levels of formality or rigor for every project because no two projects are the same. If there’s so much rigor or formality, it’s highly possible for projects to be slowed down unnecessarily or worse, get stuck.

Very little rigor or formality can result in a very loose or spontaneous approach to solutions development that foster a working environment of no urgency, which can lead to regular procrastinations and eventually, delays.

The key is to identify the suitable level of formality for every project, just enough to ensure projects won’t get “out of governance” and foster progress, not hinder it.

Roles In DSDM Project Management

When it comes to applying a DSDM project management methodology, there are many different roles that need to be played and filled up by different but capable people. These roles can be grouped by interest and by actual responsibilities or function. The following are the various interest-based roles in DSDM:

• Business-oriented roles, i.e., business perspective or expertise
• Technical or solution-oriented roles, i.e., technical perspective or expertise
• Leadership or management-oriented roles, i.e., leadership and general management skills or perspective
• Process-oriented roles, i.e., process definition and monitoring perspective or expertise.

Next are the 13 specific roles played under a DSDM project management methodology. Keep in mind that DSDM’s key principles are generally focused on communications and collaboration. An efficient working team of capable individuals are at the core of successful DSDM projects. Remember, the most effective solutions are borne of empowered and self-organizing teams.

And before going into each specific DSDM role, keep in mind 3 important factors that can substantially influence any such project’s success rate, which are mutual respect among all team members, commitment and accountability for work responsibilities, and continuous improvements in the way team members work together. So without further ado, here are the 13 roles team members of a DSDM project need to fill:

1. Business Sponsor: At the project level, this is the highest role or position. Because of their business-focused interest, their commitment to any project, proposed solutions, and means by which to achieving them are unquestionable. They are accountable for both the project’s budget and business case.
2. Business Visionary: As the name suggests, this role is responsible for giving the project its vision, identifying the project sponsor’s needs, identifying the end-users of a solution being developed through the project, communicating such information to all team members, and giving the team instructions to follow for successfully completing a project. And to avoid role inconsistencies or duplications, it’s best to assign this role to just one person.
3. Technical Coordinator: This role is primarily responsible for coming up with solutions that are congruent with the clients’ needs, ensuring that people that fill up technical roles are adequately skilled, and making sure that the technical people are working properly. This is the technical equivalent of the previous role, the Business Visionary.
4. Project Manager: Aside from giving leadership to the DSDM project team in accordance with Agile PMS principles, people who fill up this role are primarily responsible for managing the solution development team’s working environment. Being the coordinator and facilitator of a project, they are responsible for assigning the scale and details of problems that may potentially arise in their team, which may be beyond the decision-making authority of the team.
5. Business Analyst: People who fill up this role are the only ones with multiple interests, i.e., they have sufficient knowledge of both the business needs of the project and the technical solutions that can meet the end-users’ functional and non-functional requirements. Typically, business analysts belong to a Solutions Development group and are deployed at the level of projects.
6. Team Leader: Those who occupy this role have the responsibility of making development teams optimally productive, functioning as the service leader. It’s somewhat akin to a Scrum Master role, in that people occupying this role preferably should be selected by work colleagues within the respective Solutions Development Teams as well as be the team’s meetings facilitators.
7. Business Ambassador: People who fill up this role act as the development teams’ key business representatives, particularly in the areas of prioritization and creation of requirements during the foundations and feasibility stages. Business ambassadors are responsible for every detail and prioritization in the development process. The role of a business ambassador is akin to a product owner’s in that it requires making business decisions for development teams.
8. Solutions Developer: People occupying this role are competent and able to improve or expand solutions by identifying and converting requirements effectively in order to ensure that all of the client’s business and technical needs are met. Solutions developers function similarly to a Scrum team member, but they have skills that are more concentrated on solutions or software development.
9. Solutions Tester: Because the DSDM methodology highlights clear definition and assurance of a specific level of quality, people occupying this role are responsible not just for identifying but also for conducting tests in accordance with an agreed-upon strategy. Like the solutions developer, the solutions tester role is akin to that of a Scrum team members except that this role requires skills that are more focused on solutions testing.
10. Business Advisor: People who fill this role provide support to the team by way of business-specific expertise and knowledge that other project or development team members do not possess. Business advisors are considered as subject matter experts on the business side of projects and may represent compliance or legal aspects that need to be taken into consideration, focus groups, or end-users.
11. Technical Advisor: People filling up this role have responsibilities similar to those of business advisors except that such responsibilities are geared more towards the technical areas of solutions development. Examples of such responsibilities include having extensive know-how of the technology utilized in the project, providing technical support, and identification and meeting of production or development requirements, among others.
12. Workshop Facilitator: DSDM recommends several key practices, which include workshops. People who fill the role of workshop facilitators need to be neutral, i.e., taking neither the side of end-users nor the development or project teams, and must have the ability to facilitate workshops among people of different backgrounds and attitudes very well.
13. The Coach (DSDM Coach): Adopting specific processes and mindsets necessary for transitioning into an Agile framework can be very challenging, the latter being the most challenging. In general, people who fill up this role are responsible for helping project teams deal with these challenges in order to make the successful transition to an Agile framework. Basically, think of what NBA coaches Steve Kerr of Golden State Warrior dynasty and Brad Stevens of the young and overachieving Boston Celtics do, except think of it within an Agile PMS context.

Don’t be surprised that despite the many roles that need to be filled in DSDM project management teams, some people may occupy multiple roles and assuming all the relevant responsibilities of those roles, especially in relatively small or young project teams.

Also, don’t be surprised to find that some roles aren’t around for the entire project’s duration. Some supporting roles will only need to be activated as needs arise.