4squareviews

This is the seventh in a series of posts devoted to outlining the various agile frameworks that exist in the world of agile project management, based on the book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, by John Stenbeck.

The first three posts covered those frameworks which are covered on the PMI-ACP exam, namely, Scrum, Extreme Programming (XP), and Lean Software Development (LSD).   The next three posts covered the relatively “minor players” in the marketplace, Feature Driven Development (FDD), Agile Unified Process (AUP), and Crystal, that are covered in John Stenbeck’s textbook.

The next series of three posts will cover the very minor players that were considered to have too small a marketshare for John Stenbeck to even cover them in the textbook.    Nevertheless, out of curiosity and for completeness’ sake, I will include them in this series of posts.   Today’s post is about Dynamic Systems Development Method (DSDM).

DSDM is primarily a software development method, and is an agile project management framework.

1.DSDM History

• 1994–First release of DSDM, which was an attempt to provide discipline to the Rapid Application Development (RAD) Method.
• 2007–DSDM becomes a generic approach to project management that is capable of being applied out of the original application area of IT, branded as “DSDM Atern”
• 2014–DSDM Atern drops “Atern” and is referred to as simply “DSDM”; attempts to integrate with PMBOK, PRINCE2 traditional PM frameworks, as well as various agile approaches

2. 8 Principles of DSDM

1. Focus on the business need–focus on business priorities, particularly critical functionalities
2. Deliver on time–always meet deadlines by timeboxing the work
3. Collaborate–users and developers share a workplace so that decisions can be made collaboratively
4. Never compromise quality–quality level must be set at outset and not allowed to vary, by building in quality and testing early and continuously
5. Build incrementally from firm foundations–strive for early delivery of business benefit where possible, and formally reassess priorities and ongoing project viability with each delivered increment
6. Develop iteratively–it is better to deliver something “good enough” rather than “perfect”
7. Communicate continuously and clearly–foster cooperation among all project stakeholders
8. Demonstrate control–use appropriate level of formality for tracking/reporting, and manage proactively

3.  4 Stages of Project Life Cycle

1. Stage 1A–Feasbility Study:  feasibility of project for use with DSDM is examined and Stage 1B–Business Study:  stakeholders come together to discuss proposed system, and develop a set of requirements
2. Stage 2–Functional Model Iteration:  creation of a functional prototype and models
3. Stage 3–System Design and Build Iteration:  integrates functional components from Stage 2 into a single system that satisfies users needs
4. Stage 4–Implementation:  tested system is delivered to the users with documentation

4. 7 Core Techniques used in DSDM

1. Timeboxing–split up the project in portions each with a fixed budget and delivery date; each portion is assigned a number of prioritized rquirements
2. MoSCoW–priotizes requirements according to whether you MUST have, SHOULD have, COULD have, or WON’T have them in the project
3. Prototyping–creation of prototypes of the system under development at an early stage of the project
4. Testing–realize a solution of good quality by testing throughout each iteration using the test management approach of the team’s choosing
5. Workshop–brings the different stakeholders of the project together to discuss requirements, functionalities and mutual understanding
6. Modeling–used to visualize the diagrammatic representation of a specific aspect of the system or business area that is being developed
7. Configuration management–the products and the various versions of their design must be controlled strictly as they achieve completion, so that everyone is working on the current version

5. 13 Roles used in DSDM

1. Executive Sponsor–the “Project Champion” who has the authority to commit appropriate funds and resources. 
2. Visionary–has responsibility to initialize project by ensuring essential requirements are decided upon early on. Visionary has the most accurate perception of the business objectives of the system and the project. Another task is to supervise and keep the development process in the right track.
3. Ambassador User–brings the knowledge of user community into the project; ensures that the developers receive enough amount of user’s feedback during the development process.
4. Advisor User–any user that represents an important viewpoint and brings the daily knowledge of the project.\
5. Project Manager–anyone from user community or IT staff who manages the project in general.
6. Technical Co-ordinator–responsible for designing the system architecture and controlling the technical quality in the project
7. Team Leader–leads team and ensures that the team works effectively as a whole
8. Solution Developer–interprets the system requirements and models it, including developing the deliverable codes and building the prototypes.
9. Solution Tester–checks the correctness in a technical extents by performing some testing, detecting defects where necessary and retesting once defects are fixed. 
10. Scribe–responsible to gather and record the requirements, agreements, and decisions made in every workshop.
11. Facilitator–responsible for managing the progress of workshops.
12. Specialist Roles Business Architect, Quality Manager, System Integrator, etc.

Unlike XP and RUP development methods, DSDM is a framework that allows members of the team to use tools and techniques of their choosing (such as the test development method).   Like other development methods, the scope is allowed to evolve, whereas the other two of the triple constraints, time and budget, are relatively fixed.   Also like other methods, there is a strong focus on communication between stakeholders in the system and involvement of those stakeholders in the process of translating requirements into technical characteristics of the product.

The next post covers the Essential Unified Process, another methodology that, like Agile Unified Process (which was covered in an earlier post), was derived from the Rational Unified Process (RUP) methodology.

Filed under: Uncategorized |