A Complete Guide To Iterative Development in DSDM
In the domain of project management, maintaining agility and flexibility has transitioned from being merely advantageous to becoming imperative. Introducing the Dynamic Systems Development Method (DSDM), a robust framework that has not only endured the test of time but has also embodied the core tenets of iterative development.
This article delves deeply into the essence of DSDM’s iterative approach, probing into its capacity to redefine the project execution landscape, empower teams, and ultimately facilitate the consistent delivery of value. We invite you to join us on a journey to uncover the insights and tactics capable of revolutionising your project endeavours through the potent force of iterative development within the framework of DSDM.
What is Iterative Development?
Iterative development denotes a systematic procedure through which the Evolving Solution, or a specific component thereof, progresses from a conceptual stage to a state characterised by recognised business value. Each iteration within this process strives to advance the targeted solution segment toward its final form, and it consistently relies on collaborative efforts. Typically, this entails the participation of two or more members from the Solution Development Team, ensuring a cooperative approach throughout.
Applying Iterative Development To DSDM
To adhere to DSDM principles, each iterative cycle should aim for brevity, often spanning a day or two, allowing multiple cycles within a defined Timebox. Formality should be minimal and appropriate to the situation, typically consisting of an informal sequence of Thought, Action, and Conversation. The involvement of pertinent Solution Development Team members is essential, varying from a simple collaboration between a Solution Developer and a Business Ambassador to the engagement of the entire Solution Development Team, possibly including multiple Business Advisors.
Each cycle commences and concludes with a conversation, aligning with DSDM’s principle of continuous and transparent collaboration and communication. The initial discussion centres on task specifics, while the cycle advances into thought, which involves strategizing the approach to meet the requirement. This could be a collaborative planning session in more structured cases, yet generally, it entails a period of introspection and informal planning.
Action means refining the Evolving Solution or its features. Upon reaching a point where the work is reviewable, the cycle wraps up by revisiting the conversation to determine the adequacy of the outcome or the necessity for another cycle. Depending on the organisation and task nature, this conversation might range from an informal consensus to a formally documented presentation, or a comprehensive review involving a broader set of stakeholders.
Throughout the course of Iterative Development, it remains crucial to maintain a clear focus on the agreed-upon acceptance criteria for the solution or its components. This is essential to ensure the desired quality without undue complexity. Furthermore, a predetermined timeframe for each evolution cycle can help sustain concentration, foster collaboration, and minimise the risk of unproductive efforts.
How Do I Plan an Iterative Development Cycle in DSDM?
Working out how to run your development cycles in DSDM can be tricky. In this section, we’ll cover all of the steps that you need to get your DSDM team working as quickly as possible.
Defining Requirements
DSDM categorises requirements into three distinct types: Functional, Usability, and Non-functional. Notably, usability, although traditionally considered a subset of non-functional requirements, garners its own classification due to its critical significance for both business users of the final solution and facilitating business interaction with the wider Solution Development Team during the pivotal phase of solution design.
In the realm of Iterative Development, an individual cycle or a Timebox’s work may revolve around evolving the solution to fulfil one or more of these requirement types. In instances involving simple features, a cycle might encompass all three perspectives concurrently. However, when the iterative development of a feature spans multiple cycles and involves various team members, it can be beneficial to focus a cycle on one or perhaps two specific perspectives rather than attempting to cover all dimensions simultaneously.
For instance, the team could opt to initially concentrate early cycles on comprehending and agreeing upon the functional aspect of a requirement. Subsequent cycles could then target usability, ensuring effective and efficient interaction with the solution. In later stages, the team might shift their focus to guarantee the attainment of the required non-functional quality, such as performance or robustness. This involves verifying that all tests yield expected results and that all acceptance criteria for the feature are satisfactorily met.
If you’re interested in learning more about estimating requirements, check out our complete guide here.
How Do I Ensure My DSDM Outcome Is of High Quality?
An inherent principle within DSDM is the unwavering commitment to upholding quality. To fulfil this commitment, it’s essential to establish a standard of quality during the initial phases of the lifecycle and subsequently ensure its attainment. However, the ensuing challenge lies in delineating quality in a substantive manner and devising a method for its evaluation within the iterative framework.
Validation and Verification
Validation involves the question “Are we constructing the correct entity?” while verification focuses on “Are we constructing the entity correctly?” In the context of Iterative Development, validation seamlessly integrates with the collaborative design process of the solution, facilitated by direct participation from roles like Business Ambassadors and Business Advisors. As such, it becomes an inherent aspect and doesn’t necessitate a distinct endeavour. Nevertheless, explicit consideration is essential for verification activities, ensuring their seamless integration into the Iterative Development cycle. The specifics of how this integration is accomplished form part of the development approach and should be detailed within the Development Approach Definition, when appropriate.
Once the methodology for quality verification has been established, action is taken to guarantee the effective and efficient execution of verification. The individual responsible for producing the product naturally conducts their own assessments as a fundamental part of the development process. Concurrently, a distinct individual (typically the Solution Tester) readies themselves for the autonomous verification task. This preparatory phase can be as time-intensive as the actual product creation, and in some cases, even more so.
You can learn more about how to validate in our complete guide to validating your SaaS product here.
Static and Dynamic Verification
Verification can be categorised into two overarching types: static and dynamic. Static verification involves scrutinising a deliverable against its established acceptance criteria or agreed-upon best practices. The merit of this form of verification lies in its observational nature, ensuring it doesn’t pose any risk to the product under examination. On the other hand, dynamic verification involves actively assessing an item, commonly referred to as testing. In the domain of dynamic verification, three primary categories of tests hold significance:
- Positive tests: These tests validate that a deliverable functions as intended. For instance, when you add an item to an online shopping cart, the expected outcome is the appearance of the item in the cart.
- Negative tests: These tests confirm that a deliverable refrains from performing actions it shouldn’t. An example would be attempting to open a padlock using an incorrect key; the padlock should remain locked.
- Unhappy path tests: These tests explore the behaviour of a deliverable in response to uncommon or undefined circumstances. For instance, how does a car engine respond when it overheats? And is this behaviour acceptable?
Drawing from these test categories, with thoughtful consideration, it’s usually feasible to formulate numerous positive, negative, and unhappy path tests for each acceptance criterion. Each test generally encompasses the following elements:
- A specified initial state
- A predefined series of actions to be executed
- An anticipated outcome or result
Quality Criteria
Quality criteria must address the essential attributes of the product or feature, and these attributes should be influenced by the specific context in which the product or feature will be employed. For instance, consider a software application that is expected to possess certain key characteristics.
A crucial attribute might involve the ability to execute business processes within predefined time limits (such as achieving a response time of 3 seconds) and to execute calculations with a high degree of precision (like maintaining accuracy within a range of +/- 1%).
When it comes to contextual factors, consider web platforms that sell event tickets. These platforms often experience sudden surges of intense traffic during the release of major events, necessitating an elevated level of resilience due to these circumstances.
Acceptance Criteria
When the Iterative Development phase commences for a solution, the principal deliverables will already possess some associated acceptance criteria from the earlier Foundations phase. While achieving this level of detail during Foundations might not always be feasible or appropriate, by the time development initiates for a specific feature, the acceptance criteria should ideally be both objective and quantifiable, moving away from subjectivity.
For instance, consider an Online Purchase feature. To establish comprehensive acceptance criteria, a specific set of inputs (like product codes and purchase quantities) needs to be defined, alongside a planned response (such as calculating and displaying individual and total costs while separately computing taxes). Additionally, the contextual backdrop of this process should be outlined (for instance, verifying stock levels necessary to fulfil the request).
Should the acceptance criteria appear ambiguous or reliant on subjective judgement (which can be the scenario towards the end of Foundations), more deliberation becomes necessary to achieve agreement on precise details. It’s important to note that this information serves a dual purpose: it guides both the construction of the solution and the manner in which its correctness will be assessed. Consequently, it’s imperative that this groundwork is laid before any actual work begins.
This comprehensive thinking is applied not only to how the solution is constructed but also to how its correctness is verified. In cases where the structured timebox approach of DSDM is employed, the detailed work concerning acceptance criteria predominantly takes place during the Investigation step. When a less rigid structure is adopted, this process unfolds as the initial step in addressing a specific requirement once it has been chosen, regardless of when that occurs within the Timebox.
FAQs
What is Meant By Iterative Development?
Iterative development entails fragmenting the software development lifecycle (SDLC) of a substantial application into more manageable segments. This approach is commonly applied in tandem with incremental development, where an extended SDLC is partitioned into smaller units that progressively build upon one another.
Is DSDM Iterative and Incremental?
DSDM represents an iterative and incremental methodology that embodies Agile development principles, incorporating ongoing user and customer engagement. Introduced in 1994, DSDM was formulated with the intent of introducing structure to the then-prevalent Rapid Application Development (RAD) approach, which was also in circulation at that time.
Overview
In the realm of project-oriented Iterative Development, preliminary contemplation is essential. This, however, diverges from the concept of extensive upfront design (BDUF) or intricate planning. Instead, it entails formulating a developmental strategy. The guiding tenets—prioritising the business need, adhering to timely delivery, fostering collaboration, and preserving unyielding quality—also influence the modus operandi of the Solution Development Team. The meticulous orchestration of tasks at the granular level, ensuring appropriate personnel’s involvement at the precise junctures, and guaranteeing the progression of quality throughout development, necessitate the collective commitment of the entire team to a well-conceived developmental strategy, co-crafted during the Foundations phase. In suitable instances, this strategy finds its documentation within the Development Approach Definition.
For smaller, straightforward projects entailing relatively uncomplicated solutions, grappling with these matters might demand a mere hour or two, facilitated by informal discussions and agreement around the table. However, as a broad guideline, the necessity for a more structured and meticulously contemplated Iterative Development strategy becomes more pronounced in tandem with the project’s size, the complexity of its organisational structure, and the nature of the envisioned solution.
Ensuring the quality of the solution is a pivotal aspect of delivering something aligned with the business’s objectives. Nonetheless, the degree of formality and the meticulousness of testing hinge extensively on the project’s character and the standards established by the organisation.
Now that you understand how iterative development is used in DSDM, you can learn more about DSDM here, or see our complete guide to user stories, epics and tasks.
