Impressum

Bibliografische Information der Deutschen Nationalbibliothek:

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über www.dnb.de abrufbar.

© 2021 Robert M. Richards

Herstellung und Verlag: BoD – Books on Demand GmbH, Norderstedt, Germany

ISBN: 978-3-7526-3663-5

Table of Contents

• Preliminary note
• Foreword
• Introduction to agility
  • The "Agile Manifesto
  • Twelve principles of the Agile Manifesto
• AgilePM - Basics
  • The elements of DSDM
  • 'Enough Design Up Front' (EDUF).
  • The benefits of DSDM for project success
  • Projects and project variables
    • Introduction
    • Understanding project variables
• The principles of DSDM
  • Introduction
  • Principle 1 - Focus on the business need
  • Principle 2 - Deliver on time
  • Principle 3 - Work together
  • Principle 4 - Don't compromise on quality
  • Principle 5 - Build progressively on solid foundations
  • Principle 6 - Develop iteratively
  • Principle 7 - Communicate continuously and clearly
  • Principle 8 - Demonstrate control
• ISF's - Instrumental Success Factors
  • Acceptance of the DSDM approach
  • An effective solution development team
  • Entrepreneurial commitment - active and continuous
  • Iterative development, integrated testing and step-by-step implementation
  • Transparency
• The DSDM process
  • Pre-Project Phase
  • Feasibility phase
  • Foundation Phase
  • Evolutionary Development Phase
  • Deployment phase
  • Post-Project Phase
• Roles and responsibilities
  • Roles at project level
  • Roles of the Solution Development Team
  • Supporting roles
• The individual roles and their responsibilities
  • Roles with business focus
    • Business Sponsor
    • Business Visionary
    • Business Advisor
    • Business Ambassador
    • Business Analyst
  • Roles with management focus
    • Project Manager
    • Team Leader
  • The roles with technical focus
    • Technical Coordinator
    • Technical Advisor
    • Business Analyst
    • Solution Developer
    • Solution Tester
  • Roles with process focus
    • Workshop Facilitator
    • DSDM Coach
• Methods and techniques
  • MoSCoW - Prioritization
  • Timeboxing
  • Iterative development
  • Modeling & Prototyping
  • Facilitated Workshops
• The DSDM products in the course of the project
  • Terms of Reference
  • Feasibility Assessment
  • Business Case
  • Prioritised Requirements List
  • Solution Architecture Definition
  • Development Approach Definition
  • Management Approach Definition
  • Foundations Summary
  • Evolving Solution
  • Timebox plan
  • Timebox Review Record
  • Project Review Report
  • Benefits Assessment
• Agile control
  • Risk Management
  • Requirements Management
    • User Stories
    • User Stories - The 3-C Approach
    • User Stories - INVEST Pattern
    • The Business Analyst
  • Estimate
• Success factors and adaptation possibilities of DSDM
  • The Project Approach Questionnaire (PAQ) - Assessing Options and Risks
  • Statement 1: "All members of the project understand and accept the DSDM approach (philosophy, principles and practices)."
  • Statement 2: "The Business Sponsor and Business Visionary clearly and proactively take ownership of the project."
  • Statement 3: "The corporate vision behind the project is clearly stated and understood by all members of the project team."
  • Statement 4: "All project participants understand and accept the importance of submitting an acceptable solution on time as a primary success factor."
  • Statement 5: "Requirements can be prioritized and there is confidence in meeting agreed costs and deadlines by varying the scope of the solution presented."
  • Statement 6: "All members of the project team accept the only rough definition of the requirements during the initial phase and the announcement of the details only during the development"
  • Statement 7: "All members of the project team accept the inevitability of changes to requirements and that the right solution can only be delivered if changes are welcomed."
  • Statement 8: "The Business Sponsor and Business Visionary understand the importance of active business involvement, and they are willing and empowered to commit appropriate business resources to the project."
  • Statement 9: "It is possible for the Solution Development Team members responsible for business and solution development to collaborate throughout the project."
  • Statement 10: "All Solution Development Team members are appropriately and sufficiently empowered to support the day-to-day decision making necessary for rapid solution development within the context of short, focused timboxes."
  • Statement 11: "DSDM roles and responsibilities have been assigned in an appropriate manner and all stakeholders understand and accept the responsibilities associated with their role."
  • Statement 12: "The Solution Development Team has appropriate shared knowledge and skills (soft and technical skills) to work together to develop an optimal business solution."
  • Statement 13: "Solution Development Team members are assigned to the project at an appropriate and consistent level sufficient to fully support the DSDM process for establishing timeboxes."
  • Statement 14: "The tools and common working practices within the Solution Development Team are sufficient to enable effective, iterative development of the solution."
  • Statement 15: "All necessary review and testing activities are fully integrated into iterative development."
  • Statement 16: "Project progress is measured primarily by incremental, demonstrable delivery of business value."
  • Statement 17: "There are no mandatory standards or other constraints that prevent the application of DSDM philosophy and practices to this project."
• Afterword

Preliminary note

DSDM® (stands for Dynamic System Development Method) and AgilePM® are both trademarks of Agile Business Consortium Limited (www.agilebusiness.org). This book has been produced independently of the copyright holder and represents the author's personal experience with the named method. In the text, the ® signs have been omitted for ease of reading. They should be kept in mind when reading.

Foreword

When I talk to customers and clients about agile approaches and methods, I always hear the prejudice after a very short time that they are all well and good, but that they are probably more suitable for companies that would implement any new ideas as a start-up on a greenfield site. In an environment like theirs, with all the divisions and departments and all the governance and controlling requirements, this would only be possible with considerable adjustments - if at all. Yes, there was a lot of good stuff in there and they had also used some agile ideas, but that was enough. We are not a start-up, but a stable company with solid values and clear processes. Rather, what is needed is a hybrid process management that encompasses the best of both worlds: flexibility and rapid value generation on the one hand, and planning, management, control and reporting on the other.

In fact, some agile frameworks do not emphasize the representation of process or organizational interfaces to the organization in their representations and this could be seen as a shortcoming. In most cases, however, this approach is simply due to the fact that a generic approach that is intended to cover different types as well as different complexities and sizes of product development simply cannot demand a single path and general interfaces and processes. Rather, it is up to the implementing organization to determine the appropriate customizations and process interfaces. This is actually normal when using any project approach and is part of the framework. The difference may simply be that some actually include a project management structure, while others focus on the core business, often "product development".

When I got to know AgilePM resp. DSDM a few years ago, I realized that it is a complete project method, which meets all requirements, even of large organizations, but is completely agile. You could say that it is the prototype of what some organizations understand under the keyword "hybrid project management", without being a "patchwork", as many hybrid approaches cobbled together from various frameworks are.

In this booklet I would like to give you a first insight into the DSDM method, which should allow the reader to find out for himself whether its approach is of interest for his own challenges. If you decide to use DSDM, I would like to recommend a suitable training as well as support by experts, who will support you in the introduction and the first projects with DSDM. Personally, I believe that there are very few projects for which the DSDM approach is not suitable. However, I am happy to leave the decision up to you and am pleased if I have been able to arouse your interest in this outstanding project management method.

The author

Introduction to agility

Agility in our context is a general style of working. Projects are viewed holistically and are not just a set of deployment techniques.

It has always been one of the biggest challenges in any development to make sure that what you develop actually meets the needs of the customer.

Solving this problem was one of the motivations for the Agile Manifesto. The first guiding principle of the Agile Manifesto is: "Our highest priority is to satisfy the customer by delivering valuable results early and continuously."

In a fast-paced environment, Agile ensures solutions meet business needs and focuses on on-time delivery.

Delaying decisions as much as possible until they are based on facts rather than uncertain assumptions and predictions is fundamental to an agile approach. This does not mean that no planning should be required - on the contrary, planning activities should focus on the various options and adapt to the current situation as well as clarify confusing situations by creating an environment in which action can be taken quickly.

Agile is all about flexibility. The principle of responding to change according to a plan is seen as a strength of Agile. This does not mean that Agile makes planning obsolete. Things change, and you want to have flexibility to adapt and respond to those changes. You clearly want to have a plan for where you are going and approximately how you are going to get there. But you also want to leave room to adjust your plan.

The "Agile Manifesto

In February 2001, seventeen people met in a ski lodge in the Wasatch Mountains of the American state of Utah to talk, ski, and relax together. They were all dissatisfied with the way software development was taking place and believed that alternatives to documentation-heavy, heavyweight software development processes were needed.

This group of organizational anarchists, who called themselves "The Agile Alliance", jointly formulated and signed the "Agile Manifesto". It should be noted that the people present later went quite different ways and developed different methods and frameworks based on the common foundation "Agile Manifesto". (Co-)developers of "Extreme Programming", "Scrum", "DSDM", "Adaptive Software Development", "Crystal" and others laid here a common foundation for the further unfolding of software development and in many cases also for issues far beyond software development.

For more information on the history of its creation, please

visit: http://agilemanifesto.org/history.html