David Brocard, Consultant Agile

Ces derniers temps j'entends et je lis des témoignages toujours plus nombreux sur les surcharges de travail des équipes dans les projets agiles.

Après avoir retourné le problème dans tous les sens depuis ma rencontre avec l'agilité (2001, Extreme Programming en sous marin dans une SSII), j'arrive à un constat assez pessimiste.

On dirait que certains managements profitent du succès de l'agilité pour augmenter la pression sur les équipes, qui en général n'en ont pas besoin.

Contrats

Et c'est aussi encore un problème de contrat.

Si on a un forfait classique au départ et qu'on fait de l'agile, ca revient à découper le total du délai, les features et du budget en itérations surchargées
Si on a un contrat avec engagement de vélocité (ou plus exigeant, de productivité) sans calibrage suffisamment fiable par exemple, les équipes s'épuisent d'entrée et auront du mal à récupérer avec les sprints suivants puisque la MMF (Minimum Marketable Feature) sera toujours repoussée et le bénéfice du repos de fin de release aussi

Pour moi le vrai problème (induit car c'est avant tout un avantage !) est la transparence de la méthode :

Contrairement au waterfall et ses effets tunel, une méthode agile montre tout, tout de suite. Pour un projet de même budget et de même délai :

Waterfall : on prend son temps pour faire de beaux doc de spec, on phosphore avec plaisir sur l'archi SOA sur tableau blanc à coup de diagrammes de classes et de séquences, on attaque le dev des composants et on commence à mesurer le retard dans l'impuissance de ne pouvoir repousser la deadline et enfin on s'excite comme des malades à la fin pour livrer ce qui est livrable sans avoir baisser le front lors de la recette. Quoi qu'il en soit, on vit au moins des temps relativement "cool" en début de projet.
Méthode agile : on voit la pertinence des estimations, l'efficacité des équipes, les décalages de compétences (je n'ai pas livré la story alors que mon voisin l'a fait pour une story de même taille etc), le temps de mise à niveau des moins expérimentés, bref on met au grand jour la productivité du projet. Si la productivité n'est pas au rendez-vous, la pression est mise dès le début du projet et ne retombe pas facilement.

Dream Team

Je discutais récemment de ce sujet avec un chef d'une petite SSII prometteuse. Ce dernier arrive à la conclusion qu'il est très difficile de partir sur des engagements à l'itération sans avoir une équipe hyper compétente dans le domaine technique du projet. Malheureusement, je crois qu'il a raison. L'agilité requiert des savoirs-faire précis au regard de l"attention continue à l'excellence et à la qualité du code" (manifeste) :

Refactoring sans pitié ("mercyless refactoring", dixit XP) comme définition de fini du dev, bonne connaissance des patterns, des antipatterns. Mon expérience me dit qu'il vaut mieux ne pas employer des design patterns qu'on ne maîtrise pas suffisamment, juste pur la "beauté du geste". C'est ça aussi la culture du développement agile : savoir mettre le curseur entre la suffisance de la simplicité et la nécessité d'une solution plus compliquée
La mise en place de l'usine logicielle agile en plus du code qu'il doit produire : outil de TDR, intégration continue qui agrege tout ce qui est automatisable (builds bien sur mais pas seulement : analyse de code (ex: Sonar, Checkstyle, Metrics, Cobertura...), test unitaires, tests fonctionnels etc. Sans compter le besoin ou la tentation de changer d'outil en cours de route, tellement l'offre est riche et variée (ex TDR : Fitnesse, Robotframework, Greenpepper, Concordion, Cucumber, JBehave, RSpec etc)
Sans parler des nombreux travaux en marge du développement : respect des référentiels normatifs, mise à jour documentaire (et que dire de la valeur de certaines documentation exigée comme un diktat...), contrôles de traçabilité, reporting chargé et inadapté etc

Évidemment, je ne suis pas en train de dire que l'agilité n'est qu'une affaire de super-développeurs. Mais aujourd'hui les conditions sont rarement réunies pour laisser la place à la montée en compétences sur les projets agiles.

Les voies de solution

Je parle de voies, pas de solution, et ce n'est pas pour rien...

Selon mon expérience, un backlog de voies de solution par ordre de priorité :

Minimiser les vélocités des équipes qui débutent en agilité et même les moins débutantes qui démarrage un projet avec beaucoup de nouveautés. Systématiquement dans ces cas, on se plante de 50% à la fin de la 1ere itération. Le scrum master et l'éventuel coach agile ont un rôle clef à jouer ici.
Le terme "sprint" est une énorme erreur : Les moins scrupuleux le prenne au pied de la lettre ! il faut l'abolir et garder "itération". C'est un terme neutre, explicite qui va très bien à tout le monde.
La présence d'un coach agile sur les projets de déploiement à grande échelle : au delà de vendre mon business ici ;-) ce n'est pas un luxe mais c'est une absolue nécessité. Un de ses rôles sera notamment de trouver tous les leviers possibles pour garantir un rythme viable, car après tout, c'est être simplement professionnel que de vouloir satisfaire un manifeste sur lequel tout le monde est censé s'engager
Profiter du rythme de la release : en fin de release on est content, on a la satisfaction de l'artisan, du travail terminé et on se pose vraiment. Redéfinir les backlogs c'est aussi redéfinir le contenu des releases en terme de MMF. Un critère de définition devrait être la fatigue des équipes. L'idéal est de consacrer une semaine ou plus à décrocher du projet, ce qui ne veut pas dire partir en vacances (pourquoi pas ceci dit ;-). Un peu comme une récupération active après un long jogging : on ne s'assoie pas mais on continue de marcher par exemple.
Éloigner la fin d'une itération avec le début de l'autre. Mettre dans la même journée un revue de sprint, une rétrospective et la planification du sprint suivant est une hérésie, et pourtant on le voit. Cet exemple ouvre une réflexion bien plus importante : celle du respect des gens, tout simplement.
Négocier des contrats pertinents, c-a-d réellement gagnant-gagnant : un grande proportion de projets agiles sont encore des forfaits, il est temps de s'interroger sur la pertinence de cette démarche. Il faut inscrire noir sur blanc la possibilité de réellement négocier le contenu de chaque itération.Quoi qu'il en soit, le salut ne viendra pas des contrats. Au delà des 2 ou 3 possibilités, c'est le pilotage du projet et l'intelligence product-owner / scrum master qui fera la différence. J'ai connu un projet Scrum réalisé au forfait qui s'est très bien passé parce que les deux parties ont su s'asseoir sur les clauses de départ au profit de négociations quotidiennes. Même les achats ont fermés les yeux, ce qui a permis d'officialiser en qq sorte le nouveau paradigme de relation client-fournisseur, totalement nouveau pour ce contexte
Oser la confiance. Derrière les clauses contractuelles, si nécessaires soient-elles, se cache le manque de confiance. Or la confiance mutuelle est un vrai levier de productivité, mais sur la durée. Confiance rime donc avec patience. Il faut convaincre là dessus.
Être modeste en terme d'outillage technique : l'installation de l'usine logicielle prend du temps sur le développement. Certes, l'intégration continue par exemple peut difficilement être économisée tellement sa présence est vitale pour l'agilité technique. Mais les outils TDR peuvent surement attendre encore quelques itérations si l'équipe n'y est pas aguerrie et que le client met la pression d'entrée (ce qui est tout le temps le cas en fait)

Conclusion

Pour Extreme Programming, le rythme viable est une pratique, pas un vulgaire concept fumeux sur lequel tout le monde s'assoit.

Pour Scrum, rien n'empêche d'ajouter cette pratique que je sache !

Mais dans la réalité malheureusement, on n'y arrive pas très bien.

Misons d'abord sur la généralisation progressive des compétences agiles - surtout techniques - pour sortir de cette situation. En effet, beaucoup d'acteurs se sont autoproclamés experts agiles un peu vite peut être. Moi-même, j'ai parfois négligé la nécessité d'une expérience plus longue sur certaines pratiques techniques. Sachons reconnaître honnêtement nos insuffisances et suivre un backlog d'apprentissage pendant les projets !
Maintenant, il est aussi normal de s'investir plus que d'accoutumé lorsqu'on démarre un projet agile. Tout en devant rester raisonnable, le surcroît d'effort est vite récompensé par un sentiment de dépassement de soi, plutôt salutaire à entendre les développeurs, quand on cueille les premiers fruits de ces méthodes si bien pensées.

Mais ça ne suffira pas : l'agilité en appelle avant tout à l'humain, depuis ses fondements et aujourd'hui plus que jamais.

Enfin, le rythme soutenable, si cher au manifeste, au même titre que les 11 autres principes, a une réalité économique, dans le sens d'un retour sur investissement garanti sur le long terme, voire le moyen terme.

Ce n'est pas un principe dissociable.

L'agilité est un tout.

Ajout du 4 mai :

De façon écrasante, ce billet a été le plus lu de mon blog. Cela me fait dire que le problème est bien réel et surtout qu'il concerne de nombreuses équipes.