DSDM® - Agile Project Management - a (still) unknown alternative full of advantages E-Book

Robert M. Richards

• Herausgeber: Books on Demand
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 89

Veröffentlichungsjahr: 2021

Beschreibung

Everyone is talking about agility and praising it as THE approach for successful project management. However, many approaches offer hardly any methods for external steering, budgeting, reporting, controlling. Many only cover the development process and leave it to the users to add further parts as needed. This repeatedly leads to the desire for hybrid project management, which combines agile development with project control and planning. However, most hybrid approaches are patchwork. Different philosophies are cobbled together, some of which contradict each other. DSDM® is different here. The method is completely based on agile approaches, but not only covers production, but also offers project planning, project steering and controlling, risk management and reporting with a goal-oriented role and responsibility management. In this booklet, the book author, himself an expert in DSDM® for many years, offers the reader a good overview of the method and shows why many more companies should get to grips with it.

Leseprobe

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

Manifesto for Agile Software Development

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan