🤹 [23/02/2023] Venez, on lit les 12 principes du manifeste AGILE !

Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

L'entrée des pratiques dev-ops commence enfin à entrer dans les boites, même les grosses. L'arrivée d'Accelerate redit la même chose avec des chiffres. L'insistance sur le fait que ce sont des fonctionnalités et non des tâches techniques montre l'intérêt pour la vision produit de l'agile. Il y a encore beaucoup trop de projets qui ne sont pas en production, mais on sent que les choses avancent sur ce point.

Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.

Oui, c'est mis en place dans beaucoup de projets AGILE aujourd'hui.

1er problème : Il y a encore une tendance à remettre les cahiers des charges et dossiers d'architecture dans les critères d'acceptance des tickets Jira…

2e problème : On trouve beaucoup de boites qui, sous prétexte d'agile, changent du jour au lendemain de grosses priorités dans le sprint. Dans SCRUM, le respect de l'inviolabilité du sprint me semble une pierre angulaire.

Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.

Cf. Le point numéro 1

Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.

Un des points que je vois le moins dans la réalité. Les développeurs ne voient que très très rarement les utilisateurs finaux. Les PO sont très souvent externes aux projets et ne sont pas de vrais owner de leurs produits.

L'arrivée des UX ces dernières années est une très bonne chose. Mais l'idéal, que je n'ai jamais vu, reste quand même de faire travailler les développeurs avec de vrais utilisateurs finaux avant et après les démos.

Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.

VPN en carafe, connexion internet lente, sites internet censurés pour des raisons de sécurité, machine de travail hyper lente, choix du système d'exploitation imposé, interdiction d'installer ses logiciels sur son poste de travail…

Faut-il encore parler des langages de programmation et technos imposés par d'obscurs architectes déconnectés du terrain à des développeurs qui les détestent et ne les maîtrisent pas ? Je ne compte plus les fois où j'ai vu ce genre de conditions de travail détestables pour les dev…

On me rétorquera que les dev font leurs divas, que l'accès à YouTube n'est pas nécessaire pour coder et qu'il est légitime, pour des raisons de sécurité, qu'on leur interdise d'installer tel ou tel logiciel…

Certes, mais dans un marché hyper tendu où les salaires des bons développeurs sont hyper hauts, brider de telle manière les techs me semble dangereux, voire stupide d'un point de vue managérial.

La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.

Après un émerveillement du télétravail dû à la crise covid, la réalité est revenue rapidement. Les projets avancent mieux lorsque l'équipe travaille dans un même bureau. Bien sûr le full-télétravail semble une utopie, mais la formule 3 jours de présentiel / semaine s'ancre peu à peu. Une victoire a été obtenue, les équipes mixtes en offshore (notamment en Inde) semblent avoir montré leur nullité. Ouf !

Un logiciel opérationnel est la principale mesure d’avancement.

Le point 7 est clairement un point éludé de nombreux projets AGILE actuellement : on y trouve davantage de discussions autour des Story Points ou pire, des jours/hommes, que de démonstrations de logiciels qui fonctionnent. Les managers et les comptables rêvent d'avoir un voyant vert qui leur dit "tout va bien" et un "voyant rouge" qui leur dirait "tout va mal". L'agile rappelle ce point essentiel, il faut aller sur le terrain, voir les projets "en vrai" pour savoir ce qui se passe. Les rapports Excel de jours-hommes traversent mal le mur de la réalité.

Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.

Je crois qu'il y a moins de problèmes sur ces questions-là tellement le marché des dev est tendu. Forcer sur les heures de travail d'une équipe tech c'est clairement prendre le risque d'en voir se barrer en cours de réalisation du projet. En revanche, je trouve des rythmes plus poussés chez les PO.

Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité.

Rien de particulier à dire. À vue de nez, j'ai l'impression que 20% des projets autour de moi font des tests automatiques et du TDD. La qualité s'observe et commence à se mesurer avec le taux de couverture de code et les analyses type SonarQube. Certes, c'est loin d'être parfait, mais j'ai l'impression que les choses bougent sur le sujet de la qualité. C'est encourageant.

La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.

Si je devais parler de ce qui complexifie les projets tech, je dirais que ça vient principalement des pratiques de sécurité et d'OPS imposées par les grosses boites.

Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.

Je suis tellement fan de ce point-là ! Mais vraiment. C'est ce qui fait toute la substance de l'agilité. La présence d'archis, de responsables sécurité et co sont pour moi des entraves à l'autonomie. On commence à savoir que les component teams ne fonctionnent pas. Pourtant ça ne bouge pas et la bureaucratie technique reste une réalité très douloureuse.

À vouloir materner les équipes, on les empêche d'être créatives et responsables. L'auto-organisation est une vraie réponse aux questions de motivation. (Cf. point 5)

À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

C'est tout le sens de la rétro. Ça commence à entrer, et quand c'est fait régulièrement, on voit des miracles. Au-delà de l'aspect amélioration continue, il y a quelque chose de psychanalytique de groupe dans la rétro que j'aime beaucoup.

Voilà pour les 12 principes relus rapidement. En espérant que cela vous a intéressé !