Sur son blog, sur les mailing list XP France et FrenchSUG, David Brocard a relancé la discussion sur la mise en pratique du principe agile du rythme soutenable.LE RYTHME SOUTENABLE
"Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment." (Agile Manifesto)Ce principe est très louable:
- Il privilégie les objectifs à long terme sur les objectifs à court terme.
- Il assure un flux continu et constant de création de valeur qui maintient la qualité du produit, assure l'avancement et améliore la prédictibilité du développement.
- Il instaure un rythme permettant de mettre en place la résolution systématique des problèmes et l'amélioration continue.
- Il rappelle que le développement est réalisé par des hommes et qu'il faut respecter leur rythme de travail - dans leur intérêt, dans celui du projet et des clients.
- Il permet d'enchainer les projets, les uns après les autres, car les développeurs restent disponibles (en bon état ...).
LE PROBLÈME
- En revenant sur plusieurs années de projet, est-ce que le rythme soutenable a été appliqué?
- Est-il compatible de la mise en pratique des autres principes du Manifeste Agile?
- A t-on au moins gagné un rythme plus soutenable qu'auparavant, lorsque nous utilisions des méthodes plus théoriques et (faussement) prédictives?
- Après 150 jours ouverts de développement sur un même projet, j'avais écrit que nous étions passé de l'itération au sprint sur notre projet en perdant le rythme soutenable (voir billet). Qu'en est-il après 350 jours ouvrables de développement sur ce même projet?
LE PLUS DUR EST A VENIR
Avant l'adoption de démarches de type agile, le rythme sur les projets était soutenable le long du V descendant. Pour tenir un jalon intermédiaire (spécification, conception, codage) il suffisait presque de décréter que l'activité était terminée. Concrètement, il était impossible de prouver objectivement le contraire puisque qu'aucune preuve n'était pertinente. Aussi, on savait sans trop oser le dire que le travail serait repris et terminé lors des phases remontantes du V.
Puis, le rythme devenait bien plus désagréable lors de la remontée du V. L'intégration du code tournait au vrai cauchemar et les heures s'accumulaient pour mettre au point (et réécrire) ce logiciel. Cette phase était le point culminant de la fatigue et du stress sur le projet. Le plus pénible était que la durée de cette phase était imprévisible ...
Tout cela pour dire qu'avant l'introduction des méthodes de type agile, le rythme des projets était déjà insoutenable, mais essentiellement sur la branche remontante du V.
C'EST DUR TOUT LE TEMPS
Avec la pratique du cycle de vie itératif et incrémental court, le stress et les heures de travail n'ont pas disparu. Ils ont été lissé assez uniformément le long du développement (il reste des pics lors des itérations qui précèdent une livraison formelle). Aussi, le stress et le surcroit de travail apparaissent très tôt dans le développement.
Ce changement est dû à la nature même du cycle itératif et incrémental qui installe un rythme court pendant lequel toutes les activités du développement sont menées, levant les problèmes tôt et souvent.
Avec les revues d'itérations et les démonstrations d'incrément, le stress de la livraison devient périodique. La mise à disposition très tôt et en continu de la vélocité (et d'autres indicateurs) peut conduire à une course à la productivité, entretenue par les attentes toujours plus ambitieuses des managers.
Ainsi, les méthodes agiles ne semblent pas générer un rythme plus soutenable ou plus insoutenable. Par contre, elles lissent tôt et tout au long du projet le stress qui culminait auparavant vers la fin (théorique) du développement.
Notez que la technique du Heijunka dans la Lean recherche spécifiquement ce lissage de la charge de travail et du stress.
SANS PIC NI RELÂCHE
Certes, avec une approche de type agile, il n'y a plus de gros pic de travail et de stress. Par contre, il n'y a plus non plus de relâche. Avec les démarches plus théoriques, les pauses n'existaient pas formellement, mais il était possible de calmer le rythme lors de la descente du V. Par contre, avec un daily-stand-up-meeting, avec le burndown chart actualisé quotidiennement, avec un build publié et avec des tests de recette automatisés mesurant l'avancement, il devient très difficile de calmer le rythme sans que cela soit perceptible. Et cela s'enchaine itération après itération. Nous en sommes à 18 itérations de 20 jours ouvrés sur le même projet - et cela use!
Pour calmer le jeu, nous avons essayé de prendre une journée sans incrément fonctionnel entre la revue d'itération et la planification de la suivante. D'une part, cela passait mal auprès du management, d'autre part cela ne rattrapait absolument pas un sprint de 20 jours ouvrés précédant un autre sprint de 20 jours.
LA COURSE A LA VÉLOCITÉ
Pour maintenir un rythme soutenable, il faut de viser une vélocité moins élevée en planification d'itération. Cela semble évident. C'est sûrement applicable dans le meilleur des mondes, dans les entreprises éclairées, chez Google et chez les Bisounours. Malheureusement, cela n'est pas envisageable avec des managers qui pensent que les développeurs consomment le temps qu'il leur est alloué (loi de Parkinson). Ce modèle de management reste appliqué. Par extension, il s'agit de fixer des objectifs intenables pour être "sur" que les développeurs se donnent à fond. Changer ce schéma de pensée peut être une révolution culturelle pour certaines organisations.
STRESSANTE TRANSPARENCE
Au rythme s'ajoute le stress de la transparence. Il faut du courage pour afficher sa courbe de productivité et sa courbe de non-qualité. Il faut du courage pour mettre une lumière qui devient rouge lorsque le build est cassé. Il faut du courage pour montrer ses problèmes. Donner des indicateurs, cela peut aussi être donner le bâton pour se faire battre. Être transparent, c'est aussi accueillir la critique: "Quand on a perdu ses clefs la nuit, on les cherche sous le lampadaire" (François Brun).
NOUVEAUX SYMPTÔMES
Avec la pratique des démarches de type agile, nous constatons que les équipes deviennent plus soudées. Avec le stress, elles développent un riche folklore d'équipe. Par exemple, notre équipe passionnerait un sociologue tellement elle a développé des pratiques telles que "le Gizmo", "le Perfect", "le saut de la troisième corde", "le J'off" et bien d'autres encore.
Ce riche folklore d'équipe est bien moins séduisant si on l'interprète comme étant des mécanismes collectifs de protection contre la souffrance au travail. Malheureusement, c'est un fonctionnement très classique étudié par la psychodynamique du travail. Avec les équipes soudées, nous sommes passé de mécanismes individuels de protection à des mécanismes collectifs.
Le fait qu'une équipe soit soudée et développe un riche folklore peut être un signe d'une souffrance au travail ressentie par les équipiers. Cela peut être un symptôme du rythme insoutenable. Le pire est quand ces symptômes sont mal interprétés et qu'ils sont reprochés à l'équipe comme étant de mauvais comportements. Cela revient a réprimer le symptôme du malêtre.
QUEL QUE SOIT LA MÉTHODE
Quel que soit la méthode, le travail en mode projet est éprouvant. Tant qu'il y aura des jalons, ils seront ambitieux (pour des raisons économiques) et il sera éprouvant de les tenir. Ceci n'est pas propre au développement logiciel. Chez les créatifs, les publicitaires, les journalistes, les écrivains et les architectes cela s'appelle les périodes de charrette (période intense de travail pour terminer à temps une commande, une tâche sous contrat).
NÉANMOINS
Les démarches de type agile ont la particularité de lisser cette charge de travail dans la durée et de monter très tôt le rythme. Ce rythme est sans pic ni relâche. A cela s'ajoute le stress de la transparence. Clairement, il faut du courage pour pratiquer une démarche du type agile.
La variable d'ajustement reste le curseur de la vélocité. Après, cela se joue à la culture d'entreprise et au style de management. Le rythme insoutenable n'est pas dans le patrimoine génétique des méthodes agiles mais dans l'utilisation que les commanditaires, les développeurs et les utilisateurs peuvent (très facilement) en faire.
Ces démarches sont diablement efficaces et motivantes mais elles ne peuvent bien sur pas tout résoudre.
Avant l'adoption de démarches de type agile, le rythme sur les projets était soutenable le long du V descendant. Pour tenir un jalon intermédiaire (spécification, conception, codage) il suffisait presque de décréter que l'activité était terminée. Concrètement, il était impossible de prouver objectivement le contraire puisque qu'aucune preuve n'était pertinente. Aussi, on savait sans trop oser le dire que le travail serait repris et terminé lors des phases remontantes du V.
Puis, le rythme devenait bien plus désagréable lors de la remontée du V. L'intégration du code tournait au vrai cauchemar et les heures s'accumulaient pour mettre au point (et réécrire) ce logiciel. Cette phase était le point culminant de la fatigue et du stress sur le projet. Le plus pénible était que la durée de cette phase était imprévisible ...
Tout cela pour dire qu'avant l'introduction des méthodes de type agile, le rythme des projets était déjà insoutenable, mais essentiellement sur la branche remontante du V.
C'EST DUR TOUT LE TEMPS
Avec la pratique du cycle de vie itératif et incrémental court, le stress et les heures de travail n'ont pas disparu. Ils ont été lissé assez uniformément le long du développement (il reste des pics lors des itérations qui précèdent une livraison formelle). Aussi, le stress et le surcroit de travail apparaissent très tôt dans le développement.
Ce changement est dû à la nature même du cycle itératif et incrémental qui installe un rythme court pendant lequel toutes les activités du développement sont menées, levant les problèmes tôt et souvent.
Avec les revues d'itérations et les démonstrations d'incrément, le stress de la livraison devient périodique. La mise à disposition très tôt et en continu de la vélocité (et d'autres indicateurs) peut conduire à une course à la productivité, entretenue par les attentes toujours plus ambitieuses des managers.
Ainsi, les méthodes agiles ne semblent pas générer un rythme plus soutenable ou plus insoutenable. Par contre, elles lissent tôt et tout au long du projet le stress qui culminait auparavant vers la fin (théorique) du développement.
Notez que la technique du Heijunka dans la Lean recherche spécifiquement ce lissage de la charge de travail et du stress.
SANS PIC NI RELÂCHE
Certes, avec une approche de type agile, il n'y a plus de gros pic de travail et de stress. Par contre, il n'y a plus non plus de relâche. Avec les démarches plus théoriques, les pauses n'existaient pas formellement, mais il était possible de calmer le rythme lors de la descente du V. Par contre, avec un daily-stand-up-meeting, avec le burndown chart actualisé quotidiennement, avec un build publié et avec des tests de recette automatisés mesurant l'avancement, il devient très difficile de calmer le rythme sans que cela soit perceptible. Et cela s'enchaine itération après itération. Nous en sommes à 18 itérations de 20 jours ouvrés sur le même projet - et cela use!
Pour calmer le jeu, nous avons essayé de prendre une journée sans incrément fonctionnel entre la revue d'itération et la planification de la suivante. D'une part, cela passait mal auprès du management, d'autre part cela ne rattrapait absolument pas un sprint de 20 jours ouvrés précédant un autre sprint de 20 jours.
LA COURSE A LA VÉLOCITÉ
Pour maintenir un rythme soutenable, il faut de viser une vélocité moins élevée en planification d'itération. Cela semble évident. C'est sûrement applicable dans le meilleur des mondes, dans les entreprises éclairées, chez Google et chez les Bisounours. Malheureusement, cela n'est pas envisageable avec des managers qui pensent que les développeurs consomment le temps qu'il leur est alloué (loi de Parkinson). Ce modèle de management reste appliqué. Par extension, il s'agit de fixer des objectifs intenables pour être "sur" que les développeurs se donnent à fond. Changer ce schéma de pensée peut être une révolution culturelle pour certaines organisations.
STRESSANTE TRANSPARENCE
Au rythme s'ajoute le stress de la transparence. Il faut du courage pour afficher sa courbe de productivité et sa courbe de non-qualité. Il faut du courage pour mettre une lumière qui devient rouge lorsque le build est cassé. Il faut du courage pour montrer ses problèmes. Donner des indicateurs, cela peut aussi être donner le bâton pour se faire battre. Être transparent, c'est aussi accueillir la critique: "Quand on a perdu ses clefs la nuit, on les cherche sous le lampadaire" (François Brun).
NOUVEAUX SYMPTÔMES
Avec la pratique des démarches de type agile, nous constatons que les équipes deviennent plus soudées. Avec le stress, elles développent un riche folklore d'équipe. Par exemple, notre équipe passionnerait un sociologue tellement elle a développé des pratiques telles que "le Gizmo", "le Perfect", "le saut de la troisième corde", "le J'off" et bien d'autres encore.
Ce riche folklore d'équipe est bien moins séduisant si on l'interprète comme étant des mécanismes collectifs de protection contre la souffrance au travail. Malheureusement, c'est un fonctionnement très classique étudié par la psychodynamique du travail. Avec les équipes soudées, nous sommes passé de mécanismes individuels de protection à des mécanismes collectifs.
Le fait qu'une équipe soit soudée et développe un riche folklore peut être un signe d'une souffrance au travail ressentie par les équipiers. Cela peut être un symptôme du rythme insoutenable. Le pire est quand ces symptômes sont mal interprétés et qu'ils sont reprochés à l'équipe comme étant de mauvais comportements. Cela revient a réprimer le symptôme du malêtre.
QUEL QUE SOIT LA MÉTHODE
Quel que soit la méthode, le travail en mode projet est éprouvant. Tant qu'il y aura des jalons, ils seront ambitieux (pour des raisons économiques) et il sera éprouvant de les tenir. Ceci n'est pas propre au développement logiciel. Chez les créatifs, les publicitaires, les journalistes, les écrivains et les architectes cela s'appelle les périodes de charrette (période intense de travail pour terminer à temps une commande, une tâche sous contrat).
NÉANMOINS
Les démarches de type agile ont la particularité de lisser cette charge de travail dans la durée et de monter très tôt le rythme. Ce rythme est sans pic ni relâche. A cela s'ajoute le stress de la transparence. Clairement, il faut du courage pour pratiquer une démarche du type agile.
La variable d'ajustement reste le curseur de la vélocité. Après, cela se joue à la culture d'entreprise et au style de management. Le rythme insoutenable n'est pas dans le patrimoine génétique des méthodes agiles mais dans l'utilisation que les commanditaires, les développeurs et les utilisateurs peuvent (très facilement) en faire.
Ces démarches sont diablement efficaces et motivantes mais elles ne peuvent bien sur pas tout résoudre.
