À mon sens, au-delà des pratiques, des principes… Un signe de véritable agile se situe dans certaines évolutions.
- La qualité du produit s’améliore : moins de défauts après mise en exploitation, plus de facilité à maintenir…
- Sa valeur également : Utilisateurs plus satisfaits, économie budgétaire (en dépriorisant ce qui n’apporte que peu de valeur)…
- Moral des équipes : vers plus de soleil.
Inversement, si vous constatez une diminution de la qualité, pas vraiment de différence au niveau de la valeur, un moral qui empire… C’est donc qu’il y a un problème quelque part !
Definition of Done : le faux-ami ?
Scrum se présente comme un cadre destiné à maîtriser le développement de produits complexes, indépendamment du domaine. Ce qui signifie concrètement que Scrum est inutilisable tel quel, sans ajout de pratiques spécifiques au domaine.
Ainsi, la Definition of Done (DoD), introduite dans Scrum en 2003 me semble-t-il, est particulièrement sensible à cet aspect du cadre. Dire qu’il est pertinent de définir une liste de critères qui précisent ce que signifie « fini » est une évidence. Cela rejoint les critères de transition (les « gardes ») dans un tableau Kanban. La question est alors : quelle DoD ?
Si, dans le cas de produit à forte composante logicielle, l’équipe (Développeurs, Product Owner, ScrumMaster) n’est pas spécialement aguerrie, la DoD a toutes les chances d’être… indigente. Quid des critères tels que
- Côté Product Owner
- Résultats de tests d’acceptance corrects
- Résultats des tests de non-regression…
- … et des tests non-fonctionnels (temps de réponse, volumétrie, respect de chartes graphiques…)
- Côté Développeurs
- Gestion de configuration
- Règles de codage
- Revue de code
- Tests d’intégration
- Mise à jour éventuelle de documentation ou modèle
Se doter d’une DoD est donc loin d’être suffisant pour assurer la qualité du code. Encore faut-il que cette DoD soit vraiment… professionnelle.
Priorité ou valeur ?
Si l’agile, via son premier principe, pose le but de la valeur (tout comme en Lean d’ailleurs), cette notion, pourtant bien présente au tout début de l’agile, a disparu des radars. Combien d’outils de gestion de backlog intègrent-ils nativement l’attribut « valeur » dans les items tels que « User Story » ?
Comment assurer que le plan (des Sprints et plus généralement des versions) optimise bien la valeur sans cette information ?
Comment éviter les biais cognitifs de priorisation, sans comptabiliser la valeur obtenue en fin de Sprint ?
Prioriser, c’est ce qui est fait dans le Cycle en V lorsque les activités de spécification sont priorisées puis celles de conception, etc. Mais sommes-nous sûrs qu’au prétexte de développement itératif nous ne retombons pas dans ces « guides » de priorisation ?
l’Humanisme : systématiquement oublié ?
Les cadres agiles (et Lean) sont par nature humanistes. Cela ne signifie absolument pas que c’est le monde des bisounours et encore moins freeStyle ! Humanisme signifie que ce sont des êtres humains qui sont directement concernés et que le respect est une valeur inaliénable. Autrement dit, ne pas porter atteinte à l’intégrité physique et psychologique des personnes.
Or, que constatons-nous ? Dans une situation complexe (difficile à prévoir), il est nécessaire d’ajuster le plan en fonction des feedbacks. Il n’existe pas – à mon sens – d’innombrables variables d’ajustement.
- Budget (rajouter des Développeurs, embaucher des experts, off-shore…)
- Planning (modifier une date de livraison…)
- Contenu (ajuste le périmètre : supprimer des features et/ou stories en fonction de leur valeur…)
- Dette technique (augmenter la dette technique en supprimant certains « garde-fous » de la DoD : moins tester, ne plus vérifier les règles de codage…)
- Respect des personnes (imposer une surcharge, ne pas tenir compte des avis des doers…)
Les trois premières variables sont « politiquement correctes » et apparaissent naturellement dans les reportings et indicateurs. Les deux dernières sont plus… sournoises. Peu d’équipes – et Managers – utilisent vraiment des indicateurs de qualité : si ils existent, ils sont ignorés… Par habitude !
Et que dire du respect ? Quels indicateurs pour s’assurer du respect des personnes ?
Et donc… ?
Donc… Ne considérons pas que nous sommes agiles au prétexte qu’il existe un PO, un SM, un backlog, des stand-ups le matin, etc.
Et revenons à ces indicateurs simples :
- Quid de la qualité ?
- de la valeur ?
- du moral des équipes ?