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.
Bonjour,
RépondreSupprimerje conçoit que l'application d'une itération courte peut amener à une dérive managériale d'augmentation de la pression. Ceci dit, pour partager mon expérience, nous avons plutôt obtenu un rythme nettement plus soutenable en passant à Scrum.
Les indicateurs sont valables sur 3 semaines (durée de nos sprints). Ce qui fait que certaines personnes vont avoir des "bons" sprints et d'autres des sprints + durs, mais celà tourne dans l'équipe et toutes les 3 semaines, nous repartons à 0.
Il est clairement nécessaire de ménager une période de respiration (ne serait-ce que la journée de retropsective + plannification ou la diminution de la dette technique), permettant de bien vivre ce changement de sprint.
J'aime bien l'analogie avec une course de F1. Pour arriver 1er, il ne faut pas avoir le pied tout le temps sur l'accélérateur et chercher à augmenter sa vélocité, mais il faut l'optimiser pour économiser l'essence et éviter les arrêts au stand. Pour nous, ce qui crame trop d'essence, c'est les période de développement "à l'arrache".
Enfin, c'est tout le rôle du ScrumMaster de ne pas entrer dans le jeu du management et de limiter les "mauvaises perturbations" de l'équipe (pression sur les charges, course à la vélocité, surcharge de backlog de sprintc...)
Je ne dis pas que c'est simple, mais les outils sont + nombreux et mieux adaptés pour limiter ce stress. La charge de travail est toujours en "dents de scie", mais sur des cycles + courts, les relâches existent + régulièrement.
Je ne pense pas que nos difficultés soient liées à la durée d'itération ou à la méthode utilisée. (Pour info, on pratique - entre autres - SCRUM avec des sprints - quelle horreur ce mot - de 20 jours ouvrés).
RépondreSupprimerUn des problèmes est qu'il n'y a pas de relâche. La rétrospective et la planification s'étalent sur 2 jours. Cette période est même plus stressante étant donné les enjeux. Et même si ces 2 jours étaient plus calmes, ils ne pourraient rattraper la succession de 17 sprints, agrémentés d'audits clients, de livraisons formelles et de démos.
Certes, c'est au ScrumMaster de protéger l'équipe. Néanmoins, il est difficile pour lui de ralentir le rythme lorsque management et clients en veulent plus.
C'est là la limite des principes: ils sont très louables mais ils se heurtent au contexte économique, aux pénalités de retard, au style de management, à l'horrible Loi de Parkinson et à la culture de l'entreprise.
Bonjour,
RépondreSupprimer"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é. 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."
Agile et lean sont proches l'un de l'autre. Le second est sensé fonctionner avec des machines-outil. Quand on l'applique aux humains, en l'occurrence aux développeurs, c'est sur que ça peut être éprouvant.
Si la loi de Parkinson n'est pas à jeter (peut être le manager ;-) ), il faut certainement l'aménager.
Tout comme la machine-outil, la machine humaine supporte un certain rythme, c'est ce "bon" rythme que doit trouver le manager et édulcorer la loi de parkinson sur cette base, un peu comme le compte-tour d'une machine-outil sur lequel a été défini la zone rouge qui permet d'utiliser la machine à l'optimum de la capacité imaginé par ses concepteurs et la garder longtemps en bon état de fonctionnement.
Une autre analogie que celle de la F1 de Christophe que je partage.
Un des principes important est que c'est l'équipe qui définie la charge qu'elle accepte de prendre (le nombre de story).
RépondreSupprimerA partir de là cela marche si on la laisse réellement gérer correctement cela (et qu'elle connait les enjeux) et qu'on ne la juge pas négativement sur cet aspect (et oui, la vélocité doit rester un indicateur interne à l'équipe, pas un indicateur du management...), l'équipe va pouvoir s'autoriser elle même de "souffler" quand cela s'avère nécessaire. Je conçois que cela soit compliqué comme vision à accepter dans pas mal d'entreprise. Mais généralement les améliorations induites par le passage à Scrum permettent de le faire passer. Et oui, pour faire de l'Agile, il vaut mieux avoir un manager Agile !
Bonjour,
RépondreSupprimerJe suis a la recherche de conseil pour le choix d'une méthode de gestion d'équipe/de projet.
Voici un peu le point sur la situation actuelle: nous sommes < 5 developpeurs et on se partage une grosse farde avec tous les "dossiers" des programmes a écrire.
Il n'y a pas de communication ni d'entrain, celui qui travaille le plus vite se recupere le plus de dossier. Celui qui a le plus de compétence récupère aussi les problemes (basique) que les autre ne savent pas corriger...(d'ailleurs des fois ils ne font même pas semblant de chercher a les corriger...)
le chef de projet ne suit pas vraiment la chose : il se contente de demander si les développements avancent (il y a plus de 200 programmes / sous programmes...). Le projet a deja commencé en retard , les dossiers sont succincts / incomplets.
On nous balance les dossiers comme si on donnait du grain a des poules.
Le gros probleme c'est qu'au dessus (aux réunions ou les programmeurs ne sont pas invités) ils disent que ca va.... et de toute facon eux ils ont pondu des dossiers apres le reste c'est de la faute des programmeurs qui ne vont pas assez vite.
J' essaye depuis peu la méthode pomodoro qui ne force un peu a (re-)travailler, mais si j'améliore mon travail en terme de rapidité je recupere celui des autres et de nouveau le rythme (et le moral) baisse.
Avez vous qq conseils a me donner
Alfred Dupont
fox_kzrolb@trashmail.net
Merci