#dsdm

What is DSDM?

DSDM is dynamic in nature as it’s a Rapid Application Development (RAD) approach to software development. It is an iterative and incremental approach that emphasises continuous customer/ Client involvement.

What makes DSDM different is, active involvement of the user and the decision making power is with the teams working on it. The teams are empowered to make decisions.

It focuses on the formula: 80% system deployment in 20% time, i.e., it doesn’t take long to achieve a working stage or to get it to a stage where you can say it will work.

This method is used mainly for the system where software delivery requirements happen in a short span. Its goal is to deliver software in time and on budget while still adjusting for new conditions or changes along the way.

 Brief History:

According to Wikipedia, the Dynamic Systems Development Method (DSDM), its base was developed in the 1990s to meet the need for rapid business, but it was officially originated in January 1994 by a non-profit group in the UK, to provide an industry-standard framework for project delivery. Its first version got finished in January 1995. And the latest version, which is currently in use is 4.2, developed in 2003.

 DSDM Principles:

DSDM has nine fundamental principles revolving around the business needs:

                        1.    Active user involvement: the first and most crucial principle is user involvement. User, the people who will be using the final product, must be actively involved throughout the project development. It helps in reducing the errors which may occur due to user perception and thus reduces the cost of rework as well. DSDM emphasis on working with a small and selected group of users and stay in touch with them continually, rather than meeting them occasionally in periodic meetings and review sessions.

2.    Empowered teams: To proceed quickly and smoothly, this model encourages and empower teams to take decisions. Below are some areas where decision making as a team is very critical  

·         Requirements decision

·         Prioritizing the activities and features delivery

·         Details of technical requirements

·         Which functionality needs to add in a given incremental

3.    Frequent delivery: A frequent delivery of value to the customer ensures that the errors/bugs get identified, worked upon, and resolved/ reversed/fixed at an early stage. The source of the error and root cause is also found and fixed. It applies to all, requirement documents (user stories), working models as well as on program codes.

4.    Fitness for business: In DSDM, our focus is to deliver software which is efficient enough to solve a business need and accepts changes or enhancement in a later iteration. DSDM focuses on satisfying business needs first and doesn’t allow to create ad-hoc software. It keeps the process flow simple and effective.

5.    Incremental development: To keep the big project simple and less complicated, it becomes crucial to decompose it into multiple small feature projects. Every delivery ensures a new feature gets delivered to the client. This incremental development and delivery continue until the delivery of the complete set of business required features.

6.    Reversible changes: In DSDM iteration happens through small increments. As all the stages of development are well known to developers, so changes here are reversible. Therefore, the fear of total loss of work is also very less.

7.    Base-line the requirements: Some high-level baselines need to be set to limit the degree of freedom to make changes. During the business agreement phase, the Business and Development Team discuss and agree on the baseline when the change requests and requirements would be “frozen.”

8.    Integrated testing: In DSDM, testing is done as early as in the development phase to ensure that the product does not have any technical flaws. Developers and team leads cross-check even the testing documents. It helps in fixing issues at a very early stage and reduces rework and therefore reduces cost and time.

Vous avez certainement entendu parler d’agile. C’est la méthodologie de gestion de projets à la mode, qui permet de réagir vite au changement et qui promet de révolutionner le fonctionnement des entreprises. Néanmoins, connaissez-vous des projets agiles qui ont réussi?

Avec la méthodologie traditionnelle (waterfall), les projets commencent avec une longue phase d’analyses pour identifier les besoins et pour anticiper les problèmes. Ensuite, les phases suivantes sont planifiées en détail pour garantir l’excellence de l’exécution. Mais, que faut-il faire quand l’environnement change et le plan n’est plus valable?

La méthodologie traditionnelle, soit PRINCE2 ou PMP, est similaire aux trains: les faire accélérer prend du temps, cependant, ils peuvent voyager à haute vitesse et en effet, arriver très rapidement aux destinations fixées. En contrepartie, la méthodologie agile est plutôt comme les voitures: au bénéfice d’une grande accélération elles sont en route assez vite. De plus, elles peuvent changer de destination même après le début du voyage. En revanche, leur vitesse maximale est limitée. On pourrait dire que les voitures (agile) sont plus pratiques pour explorer une région, tandis que les trains (traditionnelle) sont plus efficaces pour les voyages longs.

Pour les projets de construction d’infrastructure tels que bâtiments ou routes, la méthodologie traditionnelle est la plus commune. Par exemple, pour la construction d’un pont, tout d’abord une étude d’ingénierie détaillée  est essentielle pour garantir la faisabilité du projet. Le risque du changement des besoins est limité même si la durée estimée du projet est longue. Par contre, les projets de transformation digitale sont plutôt gérés avec la méthodologie agile. Ils commencent avec beaucoup  d’incertitude qui rend difficile la planification détaillée ; par conséquent, la flexibilité pour s’adapter au changement est la clé du succès.

J’ai œuvré dans de nombreux projets informatiques dans le domaine bancaire où une bonne analyse et planification des tâches étaient développées avant leur début. Malheureusement, c’était habituel d’introduire des changements de besoins ou de priorités pendant l’exécution. Évidemment, celle-ci rendrait le plan plus valable. En outre, la re-planification en détail prenait du temps, ce qui engendrait des retards et l’augmentation des couts.

Les managers qui allouent du budget aux projets, s’attendent à savoir exactement ce que les fonds produiront au moment de l’allocation. Ceci est similaire à quand nous achetons des produits dans le supermarché; qui veut acheter du vin sans savoir l’origine, l’âge ou le type de raisin? En fait, le budget est toujours limité et la décision de comment l’utiliser y est bien réfléchie. De toute façon, parfois, la décision est d'expérimenter ; de tester un vin inconnu, pour découvrir un nouveau goût ; bon ou mauvais.

La méthodologie Agile suit le proverbe « diviser pour régner » : la portée est divisée entre l’essentiel et le reste. L’essentiel est délivré premièrement pendant que le reste est optionnel et susceptible de changer. Si la portée essentielle est bien choisie, elle sera limitée et sa mise en œuvre sera rapide. Elle permettra d’expérimenter et d’obtenir du feedback pour aider à spécifier la fonctionnalité suivante à délivrer. Néanmoins, l’identification de la portée essentielle n’est pas facile. En effet, j'ai travaillé avec de nombreux managers qui pensaient que toute la portée était essentielle. Heureusement, ils l'ont appris grâce au guidage des coaches Agile. Est-ce que c’est essentiel d’avoir une salle de bains pour chaque genre dans un restaurant neuf, pour découvrir si le restaurant réussira ?

J’ai eu l’opportunité d’expérimenter différentes méthodologies de gestion de projet avec plusieurs entreprises de domaines différents. En général, j’ai trouvé qu’un mélange entre PRINCE2 et DSDM permet de s’adapter aux environnements qui sont en transition entre la méthodologie traditionnelle et l'Agile. Il permet de faire une bonne analyse tout d’abord, suivie d’une planification en phases dont la première est bien détaillée. Cette phase est assez longue et contient un processus de validation et d’obtention de feedback. Après, les reste de phases sont planifiés en détail, qui, normalement, n’ont pas besoin de beaucoup changer. Les managers aiment la planification initiale ainsi que la possibilité d’évaluer le projet avec une quantité de portée significative. S’il faut pivoter, la prise de décision est facile car elle est évidente et les managers remercient la gestion du projet pour leur donner en visibilité.

mv (option) filename1.ext filename2.ext – How to rename stuff and make money

I’m sitting here on Sunday morning thinking about how there is a propensity in the “Agile” space to re-name or [re] label things that already exist so they become “new” things. That action in of itself is not bad. It can create new value, new wealth.

It becomes bad when it is sold as something entirely new. Where is the innovation? In the content or context — how the pieces were moved around or…

LESS Large-Scale Scrum

LeSS was created by Bas Vodde and Craig Larman from practical experience in scaling up Scrum, see their Scaling Lean & Product Development (2008) and Practices for Scaling Lean & Agile Development (2010), and founded as the LeSS Company in 2014.

1. Large-scale Scrum is Scrum. Multiple-team Scrum, not multiple Scrum teams.

LeSS is not only about coordinating multiple teams to build one Product but also about transforming the organization by applying System thinking and lean thinking.

Nexus

Nexus is a free extension to Scrum, coming from scrum.org themselves it is perhaps the lightest and uses the most scrum-compatible terminology.  Nexus defines a Nexus Integration Team and practice which helps to bind together the work of 3-9 scrum teams working on a single Product Backlog to build an Integrated Increment. Nexus does not define the wider organisation structure or opine on how to run an Agile transformation project.

Both Scrum and Nexus should be implemented in their entirety:

Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.

Although implementing only parts of Nexus is possible, the result is not Nexus.

Spotify “model” (Tribes, Squads, Chapters & Guilds)

Documented in a 2012 paper by Anders Ivarsson and Henrik Kniberg, role names from the Spotify model are now appearing in job adverts.  The core activity is in co-located multi-disciplinary Squads with a horizontal dimension for sharing knowledge, tools, and code.

The Spotify approach adopts Poppendieck Lean principles for software development – ship a Minimum Viable Product and tweak it:

Think it, build it, ship it, tweak it.

The DSDM Agile Project Framework

DSDM is mature, practical and essentially free to use.

DSDM started in the UK in the early 1990s as a management framework around RAD development, and DSDM’s Arie van Bennekum was one of the Authors of the Agile Manifesto which started the shift from RAD to Agile.

DSDM has been tuned from decades of experience to provide a practical approach to project delivery in the real world.

DSDM’s approach and style has always been founded on an underlying ethos of common sense and pragmatism. It may be useful to clarify the meaning of these words:

Common sense – “sound practical judgment independent of specialised knowledge or training; normal native intelligence.”

Pragmatism – “action or policy dictated by consideration of the immediate practical consequences rather than by theory or dogma.”

People: The DSDM project framework defines roles and responsibilities rather than organisational structure:

DSDM roles don’t require hiring new people and expensive training and certification programs, but rather identifying within the current organisation who needs to do what for the project to succeed.

One person may perform several roles, depending on the size of the project and organisation, and is it not mandated how these roles fit into the organisational structure.

In this respect DSDM does not require a transformation project but recognises that the project needs to be delivered now within a real-world organisation.

Products: DSDM is quite clear about what products (including documentation) should exist when, who they are for, what roles should approve them and whether they are a milestone product or an evolutionary product which will be maintained and updated going forwards.

Scrum and Timeboxes: DSDM defines the project management process from business case to post-project.  Within that the iterative development part of the project may be run as a DSDM Timebox or a Scrum Sprint, both of which have a lot of similarities if you look past the terminology.

DSDM Process

DSDM Team Model

DSDM has always recognised that an agile approach may not be applicable in every case and defines success factors and a suitability filter now called Project Approach Questionnaire.

SAFE SCALED AGILE FRAMEWORK

SAFE provides complete patterns for implementing Lean-Agile development at a variable number of levels defined as [Portfolio], [Large Solution (previously known as Value Stream),] Program, and Team.

SAFe was launched in 2011 and is continuously updated with 4.5 released in June 2017 as SAFe for Lean Enterprise reflecting the scope extending beyond the IT department.  SAFe4.5 also covers processes for Lean UX, Scalable DevOps and Continuous Delivery amongst others.

SAFe is particularly in demand for its approach to Agile Transformation at the organisational level.  A SAFe 4 Certified Program Consultant (SPC) is a SAFe implementation professional responsible for training leaders, change agents, consultants, and team members to drive a Lean-Agile transformation at enterprise scale. Key areas of competency include designing a SAFe implementation, launching and facilitating an Agile Release Train (ART), and extending the Lean-Agile portfolio by launching additional ARTs.

Conclusion?

The methodologies above have different starting points or viewpoints for their approach which are not necessarily incompatible:

DSDM Agile Project Framework is a project-centric view of a project lifecycle – also applied to business initiatives not just IT projects.  When applied to IT, management and budgeting processes which are heavily geared towards projects, may tend to lead towards costly replacement projects rather than Product evolution.

LeSS takes the Product management viewpoint with Whole Product Focus and Systems Thinking:  “Customers want the product, not a part”, “Customers care about the overall cycle time and flow, not individual steps.”

Nexus shares the single Product backlog but focusses on the Team interaction necessary to achieve the common goal.

The Spotify approach adds the dimension of knowledge interchange and sharing of best practice across the organisation.

SAFe adds the Enterprise-level transformation and perhaps requires it:  it might not be meaningful for an individual team leader or project manager to implement “SAFe” within their scope (though at team level Scrum is certainly compatible with SAFe), instead each department should have the management-level commitment and contribution to the Agile Release Train.

  In 2001 the Agile Manifesto was written by representatives from Scrum, DSDM, XP and different leading methodologies.

In 2017 different practitioners came together again to create the Agnostic Agile Oath to confirm a commitment to focus on the end result rather than one methodology and to acknowledge that:

one framework is not the answer, and the ‘what’ and ‘how’ should be suited to customer context and to a wider strategic vision. – agnosticagile.org

  DSDM® consortium

Disclaimer:  I am a community member of DSDM, I worked on DSDM pilot projects in the 1990s and produced the DSDM4 online manual in 2001.

I’ve omitted DAD (Disciplined Agile Delivery) and no doubt many other valuable and interesting points.