Agile

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 :

Tout change dans le logiciel…

• Les exigences
• La conception
• L'entreprise
• La technologie
• L'équipe
• Les membres de l'équipe

Le problème n'est pas le changement, car il va forcément se produire.

Le problème, c'est plutôt notre incapacité à faire face au changement.

(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 :

Quelques principes pour faire échouer votre transformation :

➤ Se concentrer sur les process/les outils et ne pas prendre en compte les aspects humains

Ce n'est pas de la psychologie qu'il faut pour manager, c'est de l'autorité.

➤ Effet pygmalion négatif

Se convaincre que la plupart des managers et des collaborateurs sont incompétents. Conjuguer ses tendances à la sophomanie (se croire plus intelligent que les autres) et l’effet Dunning Kruger (se penser plus compétent qu’on ne l’est en réalité).

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 avez du mal à comprendre la différence entre les rôles de "Product Manager" et de "Product Owner" ?

(Cet article est destiné aux organisations mettant en œuvre Scrum.)

Un peu de vocabulaire

📌 Project Manager

C'est un chef de projet. Ce rôle n'existe pas dans une équipe Scrum. Ses responsabilités sont réparties entre les membres de l'équipe (PO, Scrum Master, Developers).

📌 Product Management

C'est un ensemble d'activités quels que soient le contexte et les pratiques/méthodes (Cycle en V, agile, ...)

Par exemple :

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.