La vraie agilité ™

Puisqu’on me cite par ici, voici ma définition très personnelle de « bien faire un projet en agilité ».

Un projet en agile qui fonctionne bien, c’est un projet dont :

1. Les acteurs sont d’accord pour dire que l’organisation est agile;
2. Les acteurs sont d’accord pour dire que l’organisation fonctionne bien.

Oui, c’est tout.

Non, ça n’aide personne.

Oui, cette définition ignore l’intégralité de la littérature autour de l’agilité, y compris le fameux Manifeste Agile.

Pourquoi ? Parce que « agile » ça veut dire absolument tout et n’importe quoi, des hordes d’experts s’écharpent sur des définitions théoriques toutes incompatibles (et qui sont souvent des variantes de SCRUM). Beaucoup trop d’experts viennent essayer d’imposer de force des concepts théoriques sans jamais se demander s’ils sont bien adaptés à l’entreprise, au projet et à l’équipe. On trouve tout un tas de réunions et de procédures dont à peu près aucune n’est suivie correctement, souvent parce que personne ne comprends ni comment faire, ni pourquoi faire ça.

Je fais partie de ces gens qui ont appris la théorie du management agile, et qui ne l’ont pas appris avec SCRUM ou Kanban. Moi, c’était la méthode XP (pour « eXtrême Programing »), et ce que j’en ai retenu c’est qu’on devait développer en permanence en binôme sur des ordinateurs coupés d’Internet (au sens « distractions » : emails, chats, docs…) ; d’autres ordinateurs sont disponibles pour ça. Autant dire que mis à part pour certaines industries critiques, ça n’a pas grand intérêt pour grand monde.

Malgré ça, et à travers tous les essais plus ou moins réussis de « méthode agile » que j’ai pu voir passer dans ma vie professionnelle, j’ai quand même identifié quelques grandes lignes plus ou moins indispensables pour que ça fonctionne.

1. La direction a une vision claire de l’avenir du produit et des priorités. C’est pas du tout spécifique à l’agile, c’est indispensable pour qu’un projet se passe bien. Mais souvent l’agile est utilisé pour camoufler ce manque de vision.
2. « Être agile » n’est pas « On fait n’importe quoi ». Ce point est valable pour la direction et pour les équipes…
3. La satisfaction client (au sens « utilisateur du produit ») prime : le travail est fait d’abord pour sortir un produit de qualité, quitte à chambouler des process et des priorités pour y arriver.
4. L’équipe comprends les processus qu’elle applique et pourquoi elle les applique.
5. Il y a un facilitateur (« Scrum Master » dans le jargon Scrum), qui propose des améliorations d’organisation, notamment dans le cadre de « méthode agile » ; par contre il n’impose rien. Si l’équipe n’arrive pas à s’approprier et appliquer telle ou telle méthode théorique, tant pis, il n’insiste pas, s’adapte et trouve un moyen d’atteindre le but recherché autrement.
6. Les équipes et les projets sont différents. Un process qui fonctionnera parfaitement dans un cas A peut être totalement contre-productif dans un cas B, parce que les gens et/ou le sujet sont différents.
7. Les acteurs connaissent leur rôle dans l’équipe et le respectent (ça ne veut pas dire « ne jamais sortir de son rôle et ne rien dire et rien faire sous ce prétexte »).
8. Les acteurs se parlent et s’écoutent, et ainsi s’améliorent. C’est le dernier point et sans doute le plus important. Les gens n’ont pas peur de dire ce qui va bien, ce qui va mal, et comment faire en sorte que le boulot se passe mieux ; et les idées sont étudiées et prises en compte dans la mesure du possible. Il n’y a pas de sujet tabou, surtout pas dans les process quotidiens.

En un mot comme en cent : pragmatisme.

Faites ce qu’il faut pour que le projet fonctionne et que l’équipe soit heureuse. Si ça veut dire qu’il faut tordre la « norme » agile en place, ou utiliser un cycle en V, ou du waterfall, ou que sais-je… faites-le.

J’ai la chance d’avoir travaillé sur des projets (pas que informatique) avec des méthodes variées. L’objectif est toujours de satisfaire le besoin du client. La méthode n’est qu’un outil pour réaliser les fondamentaux. Les différentes méthodes sont là pour cocher les cases d’une manière qu’on espère appropriée pour le projet en question. Ce n’est pas forcément adapté de concevoir un pont comme un logiciel SaaS ou réciproquement.

Par exemple, le recueil du besoin du client est un de ces fondamentaux et on finit par le faire d’une manière ou d’une autre. Si le client sait parfaitement ce qu’il veut, ce n’est pas pareil que s’il ne sait faire des retours que sur ce qu’il a entre les mains.

On peut aussi citer le niveau de formalisme des spécifications. On va de choses dites vite fait en réunion jusqu’à des définitions mathématisées du résultat attendu.

Au passage, j’ai toujours du mal avec les mentions des modèles cascades et cycle en V décrits comme une succession temporelle d’étapes alors que ce sont plutôt des liens logiques entre activités. J’ai du mal à croire qu’il y ait un seul endroit où on suive les étapes rigoureusement dans l’ordre sans jamais revenir en arrière.

Le cycle en V moderne, c’est celui de l’ingénierie des systèmes. La descente du V, c’est le chemin logique entre le besoin du client (le pourquoi), satisfait par la spéc (le quoi), elle-même réalisée par le design (le comment). La remontée du V, ce sont les activités de test, vérification, validation. On teste le design, on vérifie que la spéc est remplie, le client valide que son besoin est satisfait. Il n’y a pas de notion de temps, ce n’est pas une méthode de gestion de projet.

En fonction des projets, on peut parcourir ce cycle de manière variée au cours du temps, et de manière plus ou moins formalisée :

• De ce que j’ai vu dans le contrôle-commande nucléaire, l’archétype de l’industrie vieille école, on boucle beaucoup au niveau des phases besoin/specs, pour clarifier au maximum. Ensuite, on fait un design, une implémentation, des tests, etc. et on boucle à chaque niveau (implémentation/test par exemple) et on boucle aussi sur tout le V jusqu’à aboutir à la version installable sur site. Et même après la livraison, ça continue. Tout ça est formalisé avec une architecture documentaire qui fait le miroir des activités du V.
• De ce que j’ai vu chez un équipementier automobile. Un premier cycle peu formalisé aboutit à un produit générique utilisable pour répondre à un appel d’offre. L’appel d’offre est le moment d’échanger sur le besoin/la spec. Ensuite, on fait 4–5 itérations du V, qui auront une maturité croissante. À la fin, le client à tout ce qu’il voulait et a pu faire des retours en cours de route à des étapes-clés. Idem que dans le nucléaire, il y a une architecture documentaire qui fait le miroir des activités.
• Dans ma boîte actuelle, on a un projet informatique. On tourne sur des itérations de deux semaines, on a un mélange de spéc orales, de maquettes d’interfaces, de retours de clients en démo, etc. On parcourt le cycle en V, mais différemment.

À la fin, j’ai surtout l’impression que l’application d’un méthode de manière dogmatique, c’est pour tenter de se raccrocher aux branches quand on n’est un peu perdu sur comment on devrait s’y prendre. Là, je rejoins SpaceFox : soyons pragmatiques ! D’ailleurs, les différentes méthodes utilisées classiquement dans différentes industries sont relativement pragmatiques, même s’il y a des marges d’amélioration et des inspirations à prendre ailleurs.

L’objectif est toujours de satisfaire le besoin du client.

Tout dépend qui est "le client" dans l’histoire, d’où ma précision à ce sujet. J’ai croisé beaucoup trop de projets où la priorité n’allait pas à l’utilisateur du produit, mais à la satisfaction d’un chef quelque part, à l’optimisation d’un indicateur absurde, au profit à court terme ou tout simplement au portefeuille de l’actionnaire.

Dans ces cas, le projet fini presque toujours à virer en n’importe quoi par absence de cohérence et de vision à long terme. Quelle que soit la méthode utilisée pour le gérer.

Je ne vais pas commenter tout le billet.

Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. C’est quoi la haute valeur ajoutée? La fonctionnalité qui ne se fait nulle part ailleurs? La fonctionnalité qui sera mieux intégrée chez nous? La réponse globale à un besoin au delà du développement de fonctionnalités? Quand est-ce que le client est satisfait? Quand le gros du process est là? Quand il a l’intégration global à son workflow? Quand il a le thème couleur et la police qu’il préfère?

Tu le dis toi meme ensuite : les environnements et les attentes des clients sont hétérogènes (ansi que les équipes de devs, les ressources utilisables, les contraintes, etc). Ça n’aurait juste pas de sens de définir précisément ce qu’est un client satisfait et une haute valeur ajoutée.

C’est la nature même du manifeste Agile de ne pas être précis, sinon il n’aurait plus de sens. Parce que je suis d’accord avec SpaceFox : "ça veut dire absolument tout et n’importe quoi". Ou dit autrement : c’est un outil qui DOIT être adapté à chaque situation, chaque projet, chaque équipe de devs.

Il ne faut pas oublier qu’avant les 12 principes du manifeste, il y a aussi 4 valeurs. Dont "Individuals and interactions (…)" et "Customer collaboration (…)". C’est quoi une haute valeur ajoutée ou un client satisfait ? Ben il suffit de leur demander ! Ce n’est pas définie dans le manifeste parce que c’est à chaque projet qu’il faut interagir avec les clients et collaborer avec eux.

La comparaison avec des cas concrets que l’on rencontre avec le cycle en V me semble justement pertinente pour définir ce que n’est pas (ou ne devrait pas être) une approche Agile.

• collaboration : dans un cycle en V classique, on est plus sur une relation de prestation. Le client donne ses besoins, paie pour le service et le prestataire execute le service. Le client n’est pas acteur du développement. Et le client va se plaindre des coûts, des délais, des bugs, etc. et les devs vont se plaindre que les clients ne sont pas clairs dans leurs besoins et leurs attentes. Ce qui est normal comme situation, puisque les 2 entités en collaborent pas.

• livrant rapidement et régulièrement : dans un cycle en V classique, il peut se passer des mois ou des années entre l’analyse des besoins. Et on se retrouve avec des clients qui disent que leurs besoins et priorités ont changées pendant ce temps là et qu’ils ne sont pas satisfait du produit livré. Ou qu’un besoin exprimé sur le papier, en pratique, quand ils ont le logiciel dans les mains, ils réalisent qu’en pratique, ça serait mieux de faire autrement ou d’ajouter une fonctionnalités. Le but d’Agile n’est pas de livrer des prototypes ou des trucs fait à l’arrache, mais juste d’éviter cette insatisfaction des clients due aux délais de livraison et des besoins qui changent.

Bref, je vais pas détailler plus, je pense que l’idée là : je ne pense pas que Agile soit si flou et inutile que cela. C’est un outil (assez abstrait) qui permet d’aider à réfléchir à sa gestion de projets. Mais qui permet aussi de faire n’importe quoi et d’appeler ça de l’Agile.

dans un cycle en V classique, on est plus sur une relation de prestation. Le client donne ses besoins, paie pour le service et le prestataire execute le service. Le client n’est pas acteur du développement. Et le client va se plaindre des coûts, des délais, des bugs, etc. et les devs vont se plaindre que les clients ne sont pas clairs dans leurs besoins et leurs attentes. Ce qui est normal comme situation, puisque les 2 entités en collaborent pas.

dans un cycle en V classique, il peut se passer des mois ou des années entre l’analyse des besoins. Et on se retrouve avec des clients qui disent que leurs besoins et priorités ont changées pendant ce temps là et qu’ils ne sont pas satisfait du produit livré. Ou qu’un besoin exprimé sur le papier, en pratique, quand ils ont le logiciel dans les mains, ils réalisent qu’en pratique, ça serait mieux de faire autrement ou d’ajouter une fonctionnalités. Le but d’Agile n’est pas de livrer des prototypes ou des trucs fait à l’arrache, mais juste d’éviter cette insatisfaction des clients due aux délais de livraison et des besoins qui changent.

J’ai vu deux organisations qui ne se voyaient pas agiles (et ne l’étaient pas plus que ça) et ne faisaient aucune de ces deux choses. Comme je sais qu’elles ne sont pas des exceptions, j’ai du mal à admettre que ta description est un "cycle en V classique". Ce ne serait pas juste que beaucoup de projets informatiques sont gérés de façon totalement inadéquate ?

Communiquer avec le client (la livraison de prototypes en fait partie), gérer ses attentes, ce sont des activités de base de la gestion de projet…

En relisant les quatre valeur du manifeste agile, j’ai l’impression qu’il y a un traumatisme de boîtes supercorpo avec un héritage de projets d’ingénierie plus classiques ou la flexibilité forte n’est pas praticable (on ne fait pas des prototypes de pièces mécaniques tous les quatre matins, ça coûte cher).

Et en lisant les principes, c’est assez clair qu’il s’agit de préconisations adaptées pour des projets logiciels (livrer souvent par exemple), mélangées avec des choses qui semblent de bon sens (mais ne sont pas déployées partout, malheureusement).

Ce ne serait pas juste que beaucoup de projets informatiques sont gérés de façon totalement inadéquate ?

J’ai corrigé, ça existe partout. Y compris dans des projets qui coutent littéralement des milliards.

Cela dit je suis d’accord avec toi : l’industrie informatique a cet énorme avantage de pouvoir être très flexible.

Disons que c’est une description "classique" a l’époque ou Agile a été écrit. Agile a plus de 20 ans. Il n’est pas surprenant qu’avec le temps, la majorité des méthodes de gestion de projets qu’on voit en pratique sont des hybrides un peu bordéliques de pleins de méthodes.

C’est assez discutable. Ou cela dépend de ce qu’on entend par client. J’ai connu plusieurs projets (en tant qu’utilisateur) qui étaient "pilotés" par des comités lambda, qui n’étaient pas les utilisateurs finaux. Et quand les utilisateurs finaux avaient le produit entre les mains, ça se passait pas toujours très bien.

Quand Agile parle de collaboration, ça veut pas dire discuter avec le manager qui tient le porte monnaie, mais de bosser directement avec la personne qui va utiliser le logiciel.

Puisqu’on me cite par ici, voici ma définition très personnelle de « bien faire un projet en agilité ».

Un projet en agile qui fonctionne bien, c’est un projet dont :

1. Les acteurs sont d’accord pour dire que l’organisation est agile;
2. Les acteurs sont d’accord pour dire que l’organisation fonctionne bien.

Oui, c’est tout.

Non, ça n’aide personne.

Oui, cette définition ignore l’intégralité de la littérature autour de l’agilité, y compris le fameux Manifeste Agile.

J’ai connu un tas d’organisation où tout le monde considérait qu’ils étaient agiles jusqu’au bout des doigts. Et pourtant, ils étaient incapables de mettre quoi que ce soit en production, généraient des bugs de façon exponentielle et se faisaient tailler des croupières par la concurrence (en plus d’être des énormes cultes du cargo). Par contre, ils avaient de superbes boards Jira, un obeya et des cartes de planning poker aux couleurs de leur entreprise.

Se considérer agile et l’être sont deux choses très différentes.

Pourquoi ? Parce que « agile » ça veut dire absolument tout et n’importe quoi, des hordes d’experts s’écharpent sur des définitions théoriques toutes incompatibles (et qui sont souvent des variantes de SCRUM).

Tu confonds deux choses : l’agile qui est une approche du développement produit et les méthodologies SCRUM qui sont des applications d’un modèle de cette approche.

SCRUM fonctionne pour des équipes qui ne sont pas agiles. C’est d’ailleurs son seul intérêt à mes yeux…

On sait mettre une définition claire sur ce qu’est "être agile". C’est simplement se poser deux questions : est-ce qu’on délivre le bon produit ? Comment peut-on faire pour livrer un truc de qualité ?

Ce n’est pas plus compliqué que ça. Là où ça se corse, ce que ça va tirer énormément de concepts : la boucle de feedback courte, l’approche centrée utilisateur, l’amélioration continue, etc. etc.

Mais je suis d’accord pour dire que le manifeste agile est flou dans le sens où les gens ne comprennent pas que les piliers sont un tradeoff entre la partie gauche et la partie droite (et de là découle encore de nouveaux concepts, tout ça, tout ça) et que les gens font absolument n’importe quoi…

Beaucoup trop d’experts viennent essayer d’imposer de force des concepts théoriques sans jamais se demander s’ils sont bien adaptés à l’entreprise, au projet et à l’équipe. On trouve tout un tas de réunions et de procédures dont à peu près aucune n’est suivie correctement, souvent parce que personne ne comprends ni comment faire, ni pourquoi faire ça.

C’est ça un des problèmes des organisations agiles qui disfonctionnent (la majorité) :

Les devs¹ ne s’intéressent que peu à l’agile en général. Combien fonctionnent en SCRUM mais n’ont pas lu le SCRUM guide ? Combien savent à quoi sert un daily meeting ? une rétro ? Et pourquoi l’équipe devrait chercher à ne plus en avoir besoin ?

• les PO ne sont PO que par leur titre : leur rôle n’a jamais été d’écrire des US (combien savent qu’il n’y a pas d’US dans SCRUM ?) ou de découper une US qui fait plus de 13 points (combien savent à quoi servent les points de complexité ?), ni maintenir le board Jira…

• les coachs agiles sont là pour faire appliquer une vision (biaisée) du management de ce qu’est l’agile et se concentrent sur un modèle (souvent SCRUM ou Safe) plutôt que sur les problèmes. En plus d’être souvent hors-sol (coucou les ice-breakers infâmes)

• Scrum, Kanban, XP, etc. ne sont pas des méthodes de gestion de projet ou de management. A la rigueur, les abonimations comme l’agile à l’échelle vont plus dans ce sens

On ajoute à ça le fait qu’on sait que l’agile seule ne fonctionne pas. Que c’est une approche faite par des devs pour des devs (donc on oublie le management agile). Que ça ne se suffit pas en soi (d’où l’émergence du mouvement craft qui complète l’agile). Que ça ne peut pas fonctionner sans une stratégie produit plutôt que projet, donc une organisation qui pousse dans ce sens (et je ne suis pas en train de parler de Safe, hein).

En tout cas, dès le moment où on considère que l’agile est une méthode de management, on se tire une balle dans le pied. Et, dès le moment où on doit mettre un expert pour faire appliquer notre méthode, l’équipe n’est pas agile (désolé les Scrum Masters mais vous n’êtes pas là pour faire appliquer les principes ou animer des rétros)

1. La direction a une vision claire de l’avenir du produit et des priorités. C’est pas du tout spécifique à l’agile, c’est indispensable pour qu’un projet se passe bien. Mais souvent l’agile est utilisé pour camoufler ce manque de vision.

C’est à l’équipe d’avoir une vision claire et de définir ses priorités (tout le principe des pizza teams). La direction est là pour la supporter.

Le moteur de l’agile étant de faire ressortir les problèmes des organisations, si elle est utilisée pour masquer une vision floue, ça ne fera pas illusion longtemps

5. Il y a un facilitateur (« Scrum Master » dans le jargon Scrum), qui propose des améliorations d’organisation, notamment dans le cadre de « méthode agile » ; par contre il n’impose rien. Si l’équipe n’arrive pas à s’approprier et appliquer telle ou telle méthode théorique, tant pis, il n’insiste pas, s’adapte et trouve un moyen d’atteindre le but recherché autrement.

Ce facilitateur n’est pas là pour proposer des améliorations mais plutôt de s’assurer que tout le monde travaille en sécurité (dans le sens où chacun peut s’exprimer librement) et avoir du recul pour s’assurer que l’équipe garde son cap (i.e. qu’on pousse dans la bonne direction). C’est à l’équipe de le faire et de s’auto-organiser. S’il ne fait pas partie de l’équipe, il n’a aucun mot à dire sur son fonctionnement. S’il en fait partie, alors, au même titre que tout autre membre, il peut imposer ce qu’il faut pour qu’on pousse tous dans le même sens.

7. Les acteurs connaissent leur rôle dans l’équipe et le respectent (ça ne veut pas dire « ne jamais sortir de son rôle et ne rien dire et rien faire sous ce prétexte »).

Ou mieux : chercher à ne plus avoir des rôles précis dans l’équipe. Voire en supprimer (ops, PO, SM, QA, etc.)

Si on doit tordre la "norme agile" (que ce soit l’agile en elle-même ou la méthodo), c’est que quelque chose ne va pas. Et souvent, c’est parce que nous n’avons pas de politique produit…

Par contre, oui, il faut absolument appliquer la méthodologie qui correspond le mieux à notre fonctionnement. Il n’y a absolument rien de mal à faire du cycle en V

Pour faire court, l’agile est quelque chose de bien définie mais qui est loin d’être simple parce que c’est loin de ce qu’on a tous en tête ; ça demande un état d’esprit particulier, une réorganisation complète (avec un sentiment de perte de contôle du point de vue de la hiérarchie) et une stratégie produit adaptée dans un domaine gangréné par les cultes du cargo, la hype et des gens qui font n’importe quoi, n’importe comment…

Si une organisation « étaient incapables de mettre quoi que ce soit en production, généraient des bugs de façon exponentielle et se faisaient tailler des croupières par la concurrence », alors ils ne satisfont pas le critère n°2 « Les acteurs sont d’accord pour dire que l’organisation fonctionne bien. » – en tous cas pas longtemps, même avec les meilleures œillères du monde.

Tu confonds deux choses : l’agile qui est une approche du développement produit et les méthodologies SCRUM qui sont des applications d’un modèle de cette approche.

Non justement, je dis que trop souvent par « agile » les gens entendent « SCRUM ou une variante », et que ça fait partie du problème.

C’est à l’équipe d’avoir une vision claire et de définir ses priorités (tout le principe des pizza teams). La direction est là pour la supporter.

Les deux visions sont nécessaires pour que le projet avance (je parle des projets assez gros pour être développés par plus d’une poignée de gens). La direction doit avoir une vision et des objectifs stratégiques pour le produit ; chaque équipe doit avoir une vision et des objectifs tactiques.

Ou mieux : chercher à ne plus avoir des rôles précis dans l’équipe. Voire en supprimer (ops, PO, SM, QA, etc.)

C’est un problème de définition du terme « rôle ». Dans ce que j’écrit, il faut le prendre comme « ce que la personne doit faire » et pas comme « titre théorique au sein d’une organisation ». Tous les acteurs d’une équipe doivent savoir qui fait quoi, et en particulier chacun doit savoir ce qu’il doit faire et s’y tenir (dans le sens : ne pas faire que la moitié de ce qui était prévu ; et ne pas faire boulot des autres en parallèle – oui ça existe, et oui c’est un problème). Ceci est indépendant des titres (PO, QA…) pour éviter que chacun de cache derrière son petit doigt en mode « Ça c’est pas à moi de le faire, c’est pas marqué sur mon contrat » (déjà vu aussi) (ça pose un problème quand tu fais effectivement trop de choses qui n’ont rien à voir avec ton contrat, mais c’est un autre sujet).

Si on doit tordre la "norme agile" (que ce soit l’agile en elle-même ou la méthodo), c’est que quelque chose ne va pas. Et souvent, c’est parce que nous n’avons pas de politique produit…

Pour moi ce point rentre en contradiction avec le nombre de fois où tu dis que l’équipe doit s’auto-organiser.

Les deux visions sont nécessaires pour que le projet avance (je parle des projets assez gros pour être développés par plus d’une poignée de gens). La direction doit avoir une vision et des objectifs stratégiques pour le produit ; chaque équipe doit avoir une vision et des objectifs tactiques.

Je pense qu’ici le soucis se trouve dans le fait que pour toi et moi, on se place surtout dans la situation d’une entreprise qui édite les logiciels qu’elle commercialise et non d’une SSII qui réalise un logiciel qu’une autre entreprise a commandé que ça soit pour utilisation interne ou commercialisation. Dans le second cas la direction a forcément moins de vision. Dans le premier cas, si la direction se place en simple "aide" c’est la foire à la saucisse et le produit ne deviendra jamais satisfaisant, parfois il aura du mal à être releasé d’ailleurs.

Si une organisation « étaient incapables de mettre quoi que ce soit en production, généraient des bugs de façon exponentielle et se faisaient tailler des croupières par la concurrence », alors ils ne satisfont pas le critère n°2 « Les acteurs sont d’accord pour dire que l’organisation fonctionne bien. » – en tous cas pas longtemps, même avec les meilleures œillères du monde.

Pour faire plus simple, il suffit de ne pas avoir une idée claire de ce qu’est l’agile pour que ton critère ne soit plus suffisant.

C’est à l’équipe d’avoir une vision claire et de définir ses priorités (tout le principe des pizza teams). La direction est là pour la supporter.

Les deux visions sont nécessaires pour que le projet avance (je parle des projets assez gros pour être développés par plus d’une poignée de gens). La direction doit avoir une vision et des objectifs stratégiques pour le produit ; chaque équipe doit avoir une vision et des objectifs tactiques.

L’agile nécessite une stratégie/approche produit. Pour un projet, ça ne va pas s’appliquer, voire poser de gros soucis (tout l’intérêt de l’agile est la découverte et les hypothèses de valeurs). Si plusieurs équipes travaillent en parallèle, chacune doit travailler sur son propre scope en tant que produit indépendant (pizza team, bounded context, etc.). Donc avoir sa propre vision et objectifs L’organisation s’occupe de la vision stratégique, certes. Mais c’est à l’équipe de porter la vision de leur produit. En fait, ça va être compliqué si l’équipe n’a pas la main sur la vision (comment faire un pivot ou s’adapter au marché/utilisateurs si ce n’est pas l’équipe qui décide ?)

C’est un problème de définition du terme « rôle ». Dans ce que j’écrit, il faut le prendre comme « ce que la personne doit faire » et pas comme « titre théorique au sein d’une organisation ». Tous les acteurs d’une équipe doivent savoir qui fait quoi, et en particulier chacun doit savoir ce qu’il doit faire et s’y tenir (dans le sens : ne pas faire que la moitié de ce qui était prévu ; et ne pas faire boulot des autres en parallèle – oui ça existe, et oui c’est un problème). Ceci est indépendant des titres (PO, QA…) pour éviter que chacun de cache derrière son petit doigt en mode « Ça c’est pas à moi de le faire, c’est pas marqué sur mon contrat » (déjà vu aussi) (ça pose un problème quand tu fais effectivement trop de choses qui n’ont rien à voir avec ton contrat, mais c’est un autre sujet).

Je suis plus adepte de considérer que l’unité est l’équipe dans son ensemble et non pas chaque membre individuellement. C’est l’équipe qui avance sur chaque tâche/US/fonctionnalité/whatever. Pas la personne qui y est assignée

Non, aucune contradiction : il y a une différence entre tordre une méthodologie parce que des choses ne nous plaisent pas et s’organiser pour répondre au mieux à notre produit (ou simplement évoluer vers une autre approche/pratique) En gros, je parle de scrumbut

On est donc d’accord sur le fait qu’on est pas d’accord.