Agile terminology may vary from method to method, but the principle and the practice are similar. In Dynamic Systems Development Method (DSDM), development work is termed the ‘engineering activity’, and the output of each iteration is called the ‘emerging solution’. In Scrum the output is termed a ‘potentially releasable increment’. Ever since its launch in 1994, DSDM has been at the forefront of scalable Agile projects and solution delivery. DSDM is equally effective on small straightforward solutions or large complex corporate projects. DSDM has been used effectively on non-IT solutions and is not just about development of software. DSDM is often referred to as “mature Agile”, since it grew up with a strong base in the corporate world of projects from 1994 and retains a strong project focus in the 21st century. Under both methods, each item developed, whether an item on a Scrum ‘Product Backlog’ or an entry on a DSDM ‘Prioritized Requirements List’ needs a tight completion definition to ensure that the correct quality is achieved. In Scrum an increment is described as “Done” when it meets a “Definition of Done” for the Scrum Team. And it is a pre-condition before starting each increment that the ‘definition of done’ for the items subject to work for that increment must be agreed before the team can plan for the developed in the time available – the stricter the quality requirements the more time will be needed per product backlog item, and therefore less items should be attempted for that iteration. But it is unclear (or at least not specified) in the Scrum Guide as to when this ‘definition of done’ is agreed, the implication should be that tight criteria should only be agreed where this adds value and does not delay a solution. In practice one can use the rule of making the decision on the necessary quality at the ‘latest responsible moment’ (more on this in my forthcoming book) when the quality/time trade-offs can be understood in the light of progress to date and actual feedback from implementation. In DSDM as this definition work is carried out during the Foundations phase of the project, there is the danger that over-specification of quality based on unfounded assumptions may take place. The DSDM guidance does advise that any ‘definition of done’ work upfront during the Foundations phase should be reviewed regularly throughout the project lifecycle, but leadership is required to ensure that this does not encourage ‘Big Design Up-Front’ (BDUF), a signature feature of ‘waterfall’ approaches that are the antithesis of agile. Scrum Scrum pairs very well with XP. For most IT projects, Scrum and XP are paired. This is because Scrum easily provides the team management with process while XP provides the developers with techniques. This is not to say that Scrum cannot be combined with other frameworks. DSDM also pairs well with Scrum, because while the development team embraces and uses Scrum, the team uses DSDM as support and to facilitate development. Scrum is good for reinforcing the strength of a team. It enables autonomy, self-direction, immediate feedback, and true collaboration. The following are some other benefits that Scrum can bring to a team: Provides an enabling environment for happy team members, where they can thrive Releases the true potential of the team Provides an excellent team-based approach that enables work to be prioritized and delivered through the use of a constantly evolving backlog to provide the team’s workload Scrum has become popular because of its simplicity. It’s easy to explain and to adopt. Scrum does not emphasize project management but rather release planning and product backlogs. That is why combining DSDM and Scrum could be significantly beneficial from a project management perspective, especially scaling Scrum to work as a corporate-wide Agile method. Combining Scrum and DSDM for a big corporation might be more suitable than using the Scrum of Scrums technique DSDM The DSDM organization claims that DSDM can also incorporate other Agile delivery approaches, such as eXtreme Programming (XP) and Scrum, to provide the necessary Agile management framework to enable controlled delivery of Agile projects. DSDM is excellent with project variables (features, quality, time, and cost), and that is why it’s a great framework to combine with other Agile frameworks where Agile project management is essential. Yes, most projects have four parameters (time, cost, features, and quality), but trying to fix these four parameters at the outset is impractical and leads to many common problems associated with project management. For traditional approaches, the DSDM handbook states, "The feature content of the solution is fixed, whilst time and cost are subject to variation. If the project goes off track, more resources are often added or the delivery date extended. However, adding resources to a late project just makes it later." This quote and the diagram above are probably the main reason that the DSDM Agile framework appears to be the preferred framework for Agile project management. Summary of the Benefits of Using DSDM Using iterative development, DSDM involves the solution’s business stakeholders throughout the project lifecycle. This has many benefits, for example: The business is more likely to feel ownership of the solution as it evolves and, most importantly, as it transitions into live use Prioritization will enable a project to be delivered on time whilst protecting the quality of what is being delivered The risk of building the wrong solution is greatly reduced The final solution is more likely to meet the real business need Deployment is more likely to go smoothly, because of the co-operation of all parties concerned throughout development DSDM specifically addresses many of the problems which cause projects to struggle or to fail. For many organizations’, having the ability to deliver working solutions consistently, on time and on budget, is seen as a major step forward. DSDM will provide this. Individuals and interactions over processes and tools In an Agile project, great emphasis is placed on the team. Every individual in the team is expected to be ready, willing and able to play their part in the project, carrying out their role with competence and professionalism. Every member of the team is expected to work collaboratively with everybody else, using his or her knowledge, experience and judgment to shape a project outcome that best meets the need of the sponsoring business. Processes and tools play an important part in any project but much less emphasis is placed on these in an Agile environment. Agile processes need to be light touch and serve to guide and support rather than dictate what individuals and teams do and how they should do it. The assumption is that the team is best placed to understand what needs to be done and to work out the best way of doing it. DSDM provides appropriate light touch guidance on roles and responsibilities, whilst keeping the emphasis at all times on the people and the way they work together. Working software over comprehensive documentation The choice of words used here reflects the origins and primary focus of Agile – a focus solely on software delivery. However, changing a single word - “software” to “solution” - elevates this value from delivery of a software product to encompass the broader context of business change projects and often this is the interpretation for DSDM. DSDM has been proven to work equally well for non-software projects. The message behind this Agile value is to break the illusion of security and stability that comes from document-driven processes. Specification of every detail of requirements, solution design, plans etc. in documents that get ‘signed off’ by stakeholders before work is allowed to progress is both wasteful and ineffective. DSDM embraces the need for high-level versions of these artefacts in the early phases to frame development and delivery projects and to support governance. After the Foundations phase in a project, the framework employs collaborative techniques with active business engagement to ensure that the right solution is delivered. The framework also advocates light and timely documentation to support the solution in production beyond the end of the project. Customer collaboration over contract negotiation This Agile value encourages project teams and the sponsoring business to work collaboratively at all times. Typical commercial contracts assume that a traditional Waterfall process underpins development and ‘a fixed price for a fixed specification’ is the standard for project contracts. Agile projects emphasize collaboration, and therefore contracts need to reflect this. A contract can be as formal as a document signed by those responsible for sponsoring the solution and by those delivering it, or as informal as a shared verbal agreement on what is to be delivered. Regardless of formality, it is important to ensure that, where created, all parties follow the principle of such documents or agreements being ‘light touch’ and ‘guiding’ rather than being ‘detailed’ and ‘prescriptive’. By this definition, DSDM’s Prioritized Requirements List may represent a contract, effectively defining the scope of a project. However, as it is at a high level, it requires customer collaboration with less formality to expand on the detail of requirements throughout the iterative development of the solution during the project lifecycle. Responding to change over following a plan This Agile value emphasizes the fact that the world around a project is rarely frozen in time. Change occurs so quickly in the world of business now. that adopting an approach to building a solution which accommodates, or ideally embraces, change is likely to be the only way to a successful outcome. Change may also arise as a result of an emerging understanding of what is needed, what is valuable and even what is possible. The degree of change in detail that is typical of most projects makes creating detailed, long-term plans a waste of time. Where change is normal rather than the exception, the high-level ‘light touch’ and ‘guiding’ plans advocated by DSDM better meet the need of a flexible business. And the very important final sentence The DSDM Agile Project Framework specifically embraces the last sentence in the Agile Manifesto that clearly states, in the context of the values above “That is, while there is value in the items on the right, we value the items on the left more.” It is important not to ignore processes, tools, documentation, contracts and plans but instead to ensure that they are only created where they add value, and only to the level of detail that adds value. They should be created in a form relevant to and taking full advantage of the Agile values. 1.1 How Does DSDM Differ From More Traditional Approaches? DSDM is a vendor-independent approach focused on helping people to work effectively together to achieve business goals. It can be used in any business, in any technical environment for any project. A fundamental assumption of the DSDM approach is that nothing is built perfectly first time, but that as a rule of thumb 80% of the value of the solution can be delivered for 20% of the effort that it would take to produce the total solution (Pareto’s Principle). A basic problem with less Agile approaches is the entirely unrealistic and unreasonable expectation that those responsible for specifying a solution can predict what all their requirements will be at some distant point in time and in exact detail. This problem is compounded by the fact that a new solution as it evolves is a stimulus for change, as understanding of the impact the solution will have on the target business grows. In the traditional, sequential (or ‘Waterfall’) approach, the next step cannot be started until the current step is completed. In practice, a lot of time is wasted in each step aiming for perfection when actually an 80% solution would probably suffice. The additional effort to achieve 100% is justified on the basis that no step ever needs to be revisited if it was completed ‘properly’ first time around. In reality, considerable time is spent going back to ‘completed’ steps and unravelling the defects from work that has previously been accepted but was based on assumptions that turned out to be either false or which simply changed over time. The result of this potentially tortuous rework of detail is that projects are delivered late and over budget (if the rework is successful) or they fail to meet the business need (if the rework is avoided or rushed). In DSDM, the iterative approach encourages detail to emerge over time; therefore, the current step needs to be completed in only enough detail to allow the project to move to the next step with any shortfall in detailed understanding being dealt with in a subsequent iteration of development. There is also a very strong likelihood that the business requirements will change over time, and that such change is most likely to happen at the detail level. This being the case, the effort spent on detailed up-front work is very likely to be wasted. In addition, solutions built using the DSDM approach address the current and imminent needs of the business rather than, for example, the traditional approach of attacking all the perceived possibilities. The resulting solution is more likely to have a better fit with the true business needs, is easier to test and easier to integrate into existing and emerging business processes. The development cost of most solutions is only a small part of the total lifecycle costs; it therefore makes sense to build simpler solutions that are both fit for purpose on the day of delivery and easier to maintain and modify thereafter. This is preferable to trying to implement a more extensive solution that has been complicated and often compromised by failed attempts to predict future business needs. 1.1 How Does DSDM Differ From Most Agile Approaches? In addition to addressing many of the problems inherent in a traditional approach, DSDM also addresses many of the general concerns about Agile development. Specifically, DSDM requires basic foundations for the project to be agreed at an early stage. This allows businesses to understand the scope and fundamental characteristics of the proposed solution, and the way it will be created, before development starts. Clarifying and agreeing the foundations for the project from the combined perspectives of business, solution and management reduces the likelihood of nasty surprises on DSDM projects. In particular, for larger corporate organizations’ or organizations’ with a complex architecture and/or governance standards, agreeing the foundations early in the project is essential. DSDM also describes a broader set of roles than most Agile approaches giving it a better fit with most corporate environments without compromising Agility. 1.2 How DSDM Addresses Key Project Problems Managing any business change or developing any solution is rarely a simple task. Certain problems occur regularly whenever people from multiple disciplines work together on a project. DSDM is specifically designed to address many of these well-known problems. The following are seen as the key problems. Addressing "Ineffective communication" and "Late delivery" issues by DSDM Poor communication is highlighted time after time as a major failing on projects. Establishing clear and concise communication between the different areas and levels of an organization is not easy. DSDM provides a lot of guidance to strengthen communication and uses practices that encourage this to be visual and verbal wherever possible. DSDM’s emphasis on human interaction (e.g. through the use of workshops), visualization (e.g. through the use of modelling, prototyping and iterative development) and clearly defined roles is at the heart of excellent project communication. In particular, visualization has proved to be a far more effective way of communicating than the use of large, textual documents, passed from one person to another, and sometimes used to apportion blame when an unworkable solution has been delivered. Slippage of the promised completion date often causes much frustration, as well as having a detrimental impact on a business. DSDM sees this issue as one of the most important problems to address. The DSDM approach, and many of the practices it exploits, are focused on delivering on time. Being on time applies to short-term goals as well as to the project as a whole. If there is ever a need for compromise on a project, DSDM advocates that revising the scope of what is delivered should always be considered ahead of a extending the deadline. Under most circumstances the vast majority of the benefit of a solution can still be gained from a solution with the less important features left out. Addressing "Business functionality not met" issue by DSDM Another frustration arises when a solution is delivered which doesn’t meet the expectations of the business. It may have features that don’t do what the business really wanted it to do, or contain errors which prevent the deliverable from performing smoothly, or it simply might not be properly aligned with business processes. In DSDM, bringing the correct understanding of the needs of the business into the project is of paramount importance. To ensure that this is achieved business representatives are included as part of the Solution Development Team and DSDM encompasses practices which encourage collaboration and enable visual and verbal communication. Most importantly, DSDM teams are encouraged to embrace change, allowing them to deal with problems and opportunities that occur, to encompass new ideas that appear and to build the solution based on a deepening understanding of the solution detail. A frequent cry from those building the solution on a traditional project is that ‘the users have changed their minds’. Far from being a problem, DSDM embraces change and believes that change often arises as the result of a deepening understanding or an unavoidable external event. DSDM capitalizes on the greater depth of understanding and so ensures that the Deployed Solution meets the true business need. Addressing "Building the right thing – the business changing their mind" issue by DSDM DSDM enables change through iterative development, with regular reviews to make sure what is being developed is what the business really needs. Requirements change is a natural result of a better understanding: DSDM expects it and plans for it. Addressing "Unused features" issue by DSDM Research has highlighted that a relatively low percentage of features delivered as part of the overall solution developed using traditional approaches are actually used. This often happens because the business is encouraged to define all of its possible needs and wants at the outset of a project. By helping the business to prioritize its needs as understanding of the detail grows, DSDM keeps focus on what is important. This also avoids causing delays to a project by developing features that are never used. Addressing "Delayed or late Return on Investment (ROI)" issue by DSDM Usually, the business value of a feature decreases over time and therefore delivering everything towards the end of a project may reduce the ROI. DSDM uses incremental delivery to get the most important and most valuable features released to the business as early as is practical. When appropriate, it can aggressively harness techniques such as vertical prototyping in order to deliver a subset of the total solution to the business very early and therefore to enable early return on investment. Addressing "Over-engineering(‘Gold plating’)" issue by DSDM There is normally a diminishing return (on value) when trying to make a deliverable ‘perfect’. Usually the highest business value can be derived by getting something that is ‘good enough’ into a window of opportunity for the business. Indeed, sometimes the entire window of opportunity may be missed and no value at all delivered. DSDM is a pragmatic approach which focuses on the real business need in order to dissuade a team from being tempted to add the final extras which the business could live without. Prioritization ensures the whole team are clear about the relative importance of the work to be done and that low value ‘polishing’ of the solution does not impact deadlines and compromise ROI. Addressing “Fragile” Agile" issue by DSDM Many organizations’ have adopted Agile behaviors and approaches but have done so in a very casual and disorganized manner. In an attempt to reduce the burden of bureaucracy, they have gone to the other extreme and created a very ad hoc situation which is typified by poor discipline, little documentation and a general feeling of chaos. DSDM helps here by placing the right Agile concepts and constructs in a structured and controlled framework that enables a project to respond to change and stay in control, whilst still being fully Agile. Addressing “Waterfall dressed up as Agile" issue by DSDM A common mistake made when transitioning to Agile is to use the iterative and incremental way of working but constraining it by applying an overall Waterfall project lifecycle. The most common example is where iterative and incremental time boxed development follows on from traditional analysis and design steps in the waterfall and is followed by a traditional testing step. Whilst this may appear at the team level to be Agile and is probably more efficient than a big poorly controlled block of development activity, it fails to exploit the full potential of early delivery of real business value and does not mitigate the risks associated with inadequate business engagement. DSDM does just enough work up front to ensure clarity of objectives and to provide a foundation for solution development. This foundation is agreed before breaking the project down into Increments and within that to Time boxes, ensuring the appropriate elements of detailed analysis, design, build and test at each level. Active engagement of business roles in the detail of development ensures the right solution evolves. This, in combination with the limited up-front work creates a truly Agile way of delivering benefits to the business. "In general DSDM is very proactive in its nature with regard to these kinds of risks." 1.3 Why Choose DSDM As Your Agile Approach There are a number of Agile approaches available, and although all support an iterative style of working with continuous business involvement, beyond that, the focus is different. Choosing an Agile approach that does not actually address all the needs of the business can introduce unnecessary risk into an organization. DSDM has a broader focus than most other Agile approaches in that it deals with projects rather than just the development and delivery of a product (typically software). The project context requires a focus on the wider business need and all aspects of the solution that evolves to meet that need. DSDM has a long track record of successful Agile project delivery in all types of corporate environments, and has proved to be fully scalable, working effectively in small simple businesses, large, complex organizations’ and in highly regulated environments. It also has been shown to be equally effective for both IT and non-IT projects, for example business change projects. DSDM may also be used to supplement an existing in-house Agile approach, where this has proved to be lacking. For example, DSDM is often used to provide the full “project” focus to complement Scrum’s team focused product development process. The Agile Project Management and Scrum pocketbook provides guidance on this particular combination. DSDM also takes a pragmatic approach, recognizing that it often needs to work alongside existing standards and approaches. Examples of this are DSDM with Prince2, DSDM with ITIL, DSDM with formal quality processes, such as ISO or CMMI and DSDM with a PMO. DSDM is not only about developing new solutions; projects to enhance existing solutions are also well suited to the DSDM approach. The ethos of DSDM and the Agile Business Consortium is to embrace and partner with the Agile community at large. We recognize and value the various Agile approaches and practices and believe that good Agile can be a single or blended approach, whichever is the right solution for your project environment. As the use of Agile increases, new ideas surface frequently, and this is why DSDM sees the need to evolve and embrace the wider Agile community for the greater good and to continually improve what is seen as best practice. 1.4 Summary of the Benefits of Using DSDM Using iterative development, DSDM involves the solution’s business stakeholders throughout the project lifecycle. This has many benefits, for example: The business is more likely to feel ownership of the solution as it evolves and, most importantly, as it transitions into live use Prioritization will enable a project to be delivered on time whilst protecting the quality of what is being delivered The risk of building the wrong solution is greatly reduced The final solution is more likely to meet the real business need Deployment is more likely to go smoothly, because of the co-operation of all parties concerned throughout development DSDM specifically addresses many of the problems which cause projects to struggle or to fail. For many organizations’, having the ability to deliver working solutions consistently, on time and on budget, is seen as a major step forward. DSDM will provide this. Lean Lean management seeks to eliminate any waste of time, effort, or money by identifying each step in a business process and then revising or cutting out steps that do not create value. Lean is from the Toyota manufacturing environment in the 1940s. The goal is to reduce the amount of work in progress. Combining Scrum and Lean could be good for eliminating waste in specific areas, such as hand-offs, extra features, and partially done work. The combination could also translate to quality refined to test automation, test-driven development, continuous integration, and code reviews. Eliminating waste could also mean avoiding a task or a feature that does not add business value in an iteration. Other examples of Lean thinking: "Avoid doing all the detailed analysis up front, as it will change and may not be progressed to delivery," "Don’t waste time and resources working on tasks that do not add value to the business now." Why Agile and Lean, Scrum and Kanban were born and became popular? The first reason is the mother of all changes that happen in the business world — it’s market competition. 100 million businesses are launched every year, according to figures from GEM Global Report. And everyone wants to bite a bigger piece of the delicious market cake. Being agile or lean is a modern way of adapting and surviving in the face of enormous competition. 2. The second reason is the rapid growth of IT and Software market, that introduces other industries to Lean and Agile mindsets. Exponential growth is essential to the technology industry, and tech companies know their way around processes that enable and support it. But for slow traditional companies it sometimes appears to be some kind of magic tool. Software Development methodologies are perceived in traditional industries as hacks, so the number of managers who want to try them increases every day. 3. The next reason is the trend toward perfectionism. This is what makes me feel proud for the ages we live in — there are hundreds of entrepreneurs who want to make products of the best price and best quality. They live and work to produce legendary things, and they are ready to implement complicated management methodologies not only to win employees’ and customers’ hearts, but to be recognized (even across competitors) as leaders of iconic companies. 4. The last reason is the modern employees’ demands. It’s not a secret, that proper management reduces stress, over timing, increases welfare and satisfaction. In the 20th century people just wanted to work, and that is why traditional management was focused on the endless production cycle, considering the workforce as a part of this perpetuum mobile. Modern employees are very demanding and generally aim to work in a flexible company with a perfect process management system.