Dans un projet agile, le « pouvoir » du chef devient le « pouvoir » du groupe, puisque l’on instaure une auto-cratie pseudo-démocratique. Sauf que cette « démocratie » repose sur l’influence que chacun peut avoir (titre, prestige, aura, charisme, caractère, relations…). Que faire quand on sait que l’on a raison et que l’on ne sait pas convaincre ses collègues ?
- Se faire violence pour aller vers ses collègues
- Ecouter les autres et le leur montrer
- Envisager avec sincérité les autres alternatives
- Etayer son discours (de références, de preuves,…)
- Trouver des appuis
- Mettre de l’eau dans son vin, pour espérer faire avaler la coupe. Mettre du vin dans son eau, pour que cela serve à quelque chose
- Négocier point par point, savoir prioriser ses points
- Anticiper les objections
- Ne pas oublier pour qui l’on travaille (qui paye son salaire, qui paye la facture, qui finance le projet…). Ceci dit, un client vous sera gré de jouer le rôle de poil à gratter, si vous êtes habiles.
- Ne pas mettre les autres en porte à faux en leur absence
- Ne pas mettre les autres en porte à faux en public
- Etre irréprochable : on ne doit pas douter de la sincérité de la démarche
- Améliorer le crédit dont on dispose auprès de ses interlocuteurs
- Utiliser le système : prendre la parole en rétrospective, utiliser le bon sens, la bonne foi, puis s’appuyer sur le plan d’action établi.
- Revenir à la charge autant de fois que nécessaire, à chaque retrospective s’il le faut.
- Ne pas attendre de la reconnaissance ou des remerciements, viser juste l’efficacité.
Bref, la politique reste présente, elle se pratique dorénavant vers les côtés, en plus de vers le haut. On est loin des aspirations idéalistes du geek. On parle de guerilla facilitation, l’art de faire avancer les choses sans statut officiel.
Software and Humans 
C’est lié à une situation actuelle ?
Autres pistes :
* potasser l’art d’avoir toujours raison, de Schopenhauer, non pas pour utiliser les coups bas qui sont listés dans ce petit traité, mais pour pouvoir les reconnaître et s’en défendre quand d’autre les utiliseront
* si le sujet s’y prête (c’est souvent le cas dans le cas de discussion technique), investir un peu de temps pour démontrer la supériorité de sa proposition, avec du code par exemple. Suivant le projet, cet investissement peut nécessiter du temps hors heures de travail
Attention également lorsque tu dis « Revenir à la charge autant de fois que nécessaire, à chaque retrospective s’il le faut. » Il y a un danger énorme à avoir raison seul contre tous, pour celui qui (pense) avoir raison, et pour le groupe :
* risque d’exclusion / mise au placard avec des remarques du style « c’est encore Machin qui vient nous gonfler avec ses idées à la con »
* et par conséquent, risque pour le groupe de ne plus bénéficier des bonnes idées.
La tactique de guérilla n’a de mérite que si on pense sérieusement que le jeu en vaut la chandelle. J’ai croisé il y a 2 ans un projet sur lequel un membre avec pas mal de principes et de rectitude s’était vu complètement marginalisé de l’équipe, suite à ce qui avait été perçu comme du harcèlement par les autres. Il en a résulté pas mal de souffrance, de part et d’autre, et soigner l’équipe (travail pour lequel on m’avait fait venir) a été plutôt difficile.
J’avais essayé te tempérer mon propos (ne pas mettre en porte à faux, …)
Mais des évènements récents, postérieurs à mon post, montrent toute la pertinence de ton commentaire.
En outre, on ne peut pas seul assumer les demandes ou décisions de l’équipe, en particulier quand elles ont des conséquences vers l’extérieur de l’équipe.
Bref, il reste indispensable de faire du lobying, avec mesure et diplomatie.