Agile

🚨 La qualité ne doit pas être une variable d'ajustement dans vos projets. 🚨

Nous savons depuis plusieurs décennies que, sauf dans de rares cas (prototype ou dette technique contrôlée), la qualité logicielle ne doit pas être négligée.

⚠️ Rogner sur la qualité n’a aucun sens tant la vélocité à moyen et long terme des développeurs est abaissée.

Il n’existe donc que deux solutions pour produire des logiciels (fiables 😉) :

Connaissez-vous le "Deadline Driven Development" ("Le développement piloté par les échéances") ?

C'est un "double maléfique" 😈 de la philosophie agile, une pratique Agile Canada Dry ("Ça a la couleur de l'agile, le goût de l'agile… mais ce n'est pas de l'agile")

Voici son manifeste :

Nous découvrons comment développer des logiciels de manière acharnée en prétendant que nous sommes agiles et en aidant les autres à le faire.

Ces expériences nous ont amenés à valoriser :

Me voici maintenant certifié "SAFe® 5 Agilist" (SA). 🎉🍾

https://www.credly.com/badges/068295fd-6e22-47e9-a6bb-6123b5407d7f/public_url

(Remplacer X par le framework de votre choix : Scrum, SAFe, … 😉)

👉 Non.

La pyramide agile illustre le fait qu’il faut partir du haut pour aller vers le bas pour réellement réussir une "agilisation" que ce soit dans le cadre d’une transformation agile ou dans le cas de formation.

Pour une adoption réussie de l'agilité, il est nécessaire de comprendre le mindset agile, les valeurs et les principes.

Quand le mindset, les valeurs et les principes sont bien assimilés, les équipes peuvent :

L'agilité est une qualité d'ÊTRE, pas un exercice de FAIRE. Le jour où nous commençons à utiliser le mot « Agile » comme un nom propre (une méthode), plutôt que comme un adjectif (une qualité), est le jour où nous cessons d’ÊTRE agiles.

L'agilité particulièrement adaptée pour adresser les problématiques du domaine "Complexe" requiert une posture managériale différente de celle jusqu'ici adoptée et adaptée au domaine "Compliqué". (Cf. notions "Compliqué"/"Complexe" du framework Cynefin).

Petit rappel des 4 valeurs et 12 principes pour le développement Agile de logiciels.

📜 Manifeste

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire.

Ces expériences nous ont amenés à valoriser :

Vous connaissez le manifeste agile mais savez-vous par qui il a été écrit ? 🤔

Il a été rédigé par 17 experts du développement logiciel.

Ces experts estimaient que le traditionnel cycle de développement en cascade ne correspondait plus aux contraintes et aux exigences des organisations en évolution rapide.

Comme d'habitude dans la vraie vie, ce n'est ni tout noir ni tout blanc. L'environnement du projet est déterminant dans le choix de l'approche.

👉 Pour les projets parfaitement prévisibles (zone "Simple") : Waterfall

Vous êtes à la recherche de métriques pertinentes pour votre organisation ? 🤔

L'approche Evidence-Based Management (EBM) devrait vous intéresser.

EBM est une approche empirique basée sur des expérimentations intentionnelles et des preuves. C'est un excellent moyen d'identifier des indicateurs pertinents basés sur les résultats et non, comme la plupart du temps, sur les activités ou les productions.

Lors de l'adoption de Scrum, il est tentant de penser que la modification de certains éléments facilitera son adoption, mais c'est le contraire.

Scrum est un framework léger et volontairement incomplet.

Il s'appuie sur :

• 3 piliers empiriques : Transparence, Inspection et Adaptation
• 5 valeurs : Engagement, Focus, Ouverture, Respect et Courage

Chaque élément (événements, artefacts et rôles) est important et contribue à un objectif précis qui est essentiel à la valeur globale et aux résultats obtenus avec Scrum.