Managers, coaches agiles et bras cassés

coach-agile

À l’occasion d’une conférence donnée par deux de mes collègues sur les outils agiles à disposition des managers, durant la phase de questions / réponses, un boss a posé la question suivante : Vous, coaches, que me proposez-vous pour gérer mes bras cassés ?

Je n’étais pas la personne interpellée, pourtant répondre me tentait très fort… Je me suis abstenu. Car derrière cette formulation malhabile, il y a une vraie question, et y répondre est possible sur plusieurs axes.

Adresser la performance individuelle dans un cadre agile

Les cadres agiles promeuvent le travail en équipe plus que la contribution individuelle. Pourtant, il n’est pas encore possible de se dédouaner totalement d’une forme de mesure individuelle. Normalement, une équipe agile ‘performe’ notamment par la simple utilisation des valeurs et bonnes pratiques qui sont portées par ses méthodes.

Je pense particulièrement à :

  • La transparence, qui permet de rapidement remonter les problèmes, de les afficher et donc de se pousser à les traiter le plus rapidement possible. On ne laisse pas de poussière sous le tapis, si un équipier est dans la difficulté, cela doit se voir et le groupe doit chercher à l’en sortir. On gagne toujours à élever l’équipe, et cela passe par faire progresser les équipiers.
  • Le parti-pris de former de petites (ou très petites) équipes. Cela bonifie la performance individuelle : en minimisant les interactions et les acteurs, on va à l’essentiel et la contribution de chacun est aussi bien plus mise en avant que dans une équipe plus large. Sur ce sujet, je vous encourage à vous pencher sur la paresse sociale.

Maintenant, se reposer juste sur ces valeurs ou bonnes pratiques n’est bien entendu pas suffisant. Une autre réponse simple à mettre en oeuvre est, pour le coup, du pur management : un suivi individuel qui va au-delà du classique entretien de fin d’année, semestriel ou de crise. Adoptez le one-on-one. Derrière cet anglicisme se cache un point récurrent, où manager et équipier peuvent prendre du recul par rapport à leur travail quotidien, se dire ce qui va bien, ce qui ne fonctionne pas et l’équipier peut s’appuyer sur le manager (ou le mentor ?) pour dessiner sa trajectoire dans l’entreprise au delà du projet du moment. Deux questions viennent rapidement quand vous proposez cela : à quelle fréquence et est-ce un rendez-vous fixe ? Pour ce qui est de la fréquence, se caler sur une fois par sprint ou par mois paraît raisonnable. Quant au pourquoi d’une forme de sacralisation, il repose dans une motivation toute simple : un rendez-vous récurrent permettra de mieux adresser les moments où des messages difficiles doivent être passés, les participants ayant pris l’habitude de l’évènement et de son format.

Mais qui fait ce point ? Scrum et Kanban n’adressent pas de dimension hiérarchique en soi. Dans la vraie vie, c’est pourtant bien souvent le cas : ces responsabilités de management peuvent se conjuguer avec d’autres comme celles du Scrum Master, par exemple… C’est une réflexion propre à chaque équipe ou service.

Les pratiques agiles ne remplacent pas le (bon vieux) management

Une fois que vous avez mis en place la batterie d’outils agiles qui conviennent à votre équipe, il est possible d’être dans une situation de performance (individuelle ou collective) insatisfaisante. Autre cas de figure, un manager hérite d’une équipe ou d’équipes qu’il n’a pas lui-même monté.  Ne nous voilons pas la face, nous touchons là aux limites de l’Agile. Alors la réponse n’est pas à chercher du côté des pratiques agiles mais plutôt du côté du management.

Que faire face à une telle situation ? Imaginez, vous êtes le manager d’une équipe dont un des membres n’est pas au rendez-vous, malgré l’entraide et le support du reste de l’équipe. Il faut alors faire face au dilemme : prendre ses responsabilités et sortir cet équipier, ou ne pas toucher à l’équipe. Dans les deux cas, le manager risque de casser la dynamique de groupe qui s’est instaurée. Dans les deux cas, il vous faudra assumer les conséquences de votre décision.

Sortir quelqu’un d’une équipe n’est pas anodin. C’est un acte fort et douloureux de manager. Il peut être fait de manière élégante : respecter la personne, lui proposer une autre mission, un autre projet, de nouvelles attributions, etc. Mais aussi, respecter l’équipe : communiquer. Il ne doit pas y avoir de doutes permis : c’est pour le bien de l’équipe, du projet, du produit et vous l’expliquez et l’assumez. 

Au delà de ça : une entreprise agile est apprenante… dans tous ses services

Revenons à la question de notre manager : ‘Que me proposez-vous pour gérer mes bras cassés ?’ Tout de suite, une réponse me venait à l’esprit : ‘Mais qui a recruté ces personnes ?’ Agile n’est pas une silver bullet, bien entendu, par contre adopter une démarche d’amélioration continue peut naturellement dépasser le cadre IT.

Et sur le problème soulevé, nous pouvons explorer la dimension RH. Le recrutement et la gestion de carrière sont très importants dans une société. Pour bien recruter des profils de développeurs et éviter au maximum les erreurs de casting, il n’y a pas 36 solutions : il faut solliciter un maximum les futurs équipiers de la recrue. Cela permet de valider la compétence technique et de répondre à une question toute simple, mais néanmoins très importante : avons-nous envie de travailler avec cette personne ?

Pour aller plus loin encore, il convient de demander le feedback sur le processus de recrutement aux candidats (recrutés ET malheureux :D) pour ‘chahuter’ notre manière de faire. Enfin, une entreprise réellement apprenante sur la dimension de la gestion des carrières et des ressources humaines sollicite toujours un entretien d’une personne qui a pris la décision de quitter l’entreprise… Dans le cas contraire, elle se prive d’une source très riche d’informations sur ce qu’elle est ! 

3 Responses

  • Revenons à la question de notre manager : ‘Que me proposez-vous pour gérer mes bras cassés ?’ Tout de suite, une réponse me venait à l’esprit : ‘Mais qui a recruté ces personnes ?’

    Vous mettez la main sur l’un des problemes de notre métier. Aujourd’hui pour recruter un dev en lui fait passer un test technique générale souvent sans grand rapport avec le cadre de la mission.

    Plus idiot encore, on ne consulte que très rarement l’équipe qu’il devrait intégrer…

    On pourrait presque faire le rapprochement avec le milieu sportif et notamment le football. Sans une cohésion de groupe, peu importe vos profils même exceptionnels sur le papier, les mauvais résultats seront possibles ;-)

  • Je suis assez en phase avec l’idée que les méthodes agiles ne sont pas des « silves bullets » et que les pratiques et les valeurs managériales sont la clé du problème.

    Au dela de question du recrutement (que je trouve mal adressée, car un recrutement peut être excellent dans un contexte donné et devenir inadéquat, plusieurs mois, plusieurs année après, au fur et à mesure que le contexte et les personnes changent, mais passons…), je suis choqué par plusieurs choses qui me semblent loin des valeurs agiles :

    - La question « Mais qui a recruté ces personnes? » est aux antipodes de l’agile. Ça serait comme dire « Mais qui a développé ce bug? » ou « Qui a planté le serveur de prod? ». La recherche de coupable prend le dessus sur la recherche de solution. Je trouve qu’on se trompe de question ici.

    - Le management agile (ou management 3.0) n’est pas évoqué ici. Les leviers de motivation interne, la montée en compétence, le supportive management… Autant de voix que l’on peut explorer dans le cas présent.

    - Le software craftsmanship est aussi une voix à explorer. On commence tous par être « ceinture blanche » dans un nouveau savoir. Devenir « ceinture noire 6ème dan » requiert de l’entraînement et des maîtres (sensei) capables de transmettre leur savoir et leurs bonnes pratiques. (Google les appellerait des « évangélistes »). Ces maîtres n’étant pas forcément internes à la société, d’ailleurs.

    Bref plein de moyens pour gérer les « bras cassés » sans passer par la case « c’est la faute à qui? » :-)

  • Bonjour Gilles,

    D’abord merci pour votre commentaire.

    Je suis désolé de vous choquer sur les éléments qui vous semblent loin des valeurs agiles, ce n’est pas le but de l’article bien entendu.

    Je relève une formulation malhabile qui m’a autant choqué, et je me rends coupable d’une formulation qui manifestement est ambigüe… Je n’étais pas dans la recherche du coupable. Simplement, je suis resté fidèle à ma pensée et répartie (intérieure) du moment.

    Pour ce qui est des propositions que poussent notamment Jurgen Appelo, il se trouve que la présentation de mes collègues y faisait plutôt la part belle. Bien entendu les lecteurs ne le savent pas forcément, mais si je donnais également cette portée à mon billet, ce serait une publication bien plus longue, et ce n’est pas le format de billet de blogs que j’affectionne d’écrire (et aussi de lire…).

    Je suis en phase sur le software craftmanship, rien à ajouter sur ce point.

Laisser un commentaire