Résumé : Si vous avez à créer une équipe agile, commencez par vous demander ce qui différencie une équipe agile d’une équipe qui ne l’est pas. Dans cet article Johanna Rothman souligne six comportements nécessaires aux candidats souhaitant intégrer une équipe agile.
Les membres d’une équipe agile sont-ils différents des membres des autres équipes ? Oui et non. Oui car certains comportements sont plus présents dans les équipes agiles que dans les équipes non agiles. Et non car nous parlons de personnes !
Les équipes agiles qui fonctionnent sont fières de montrer certains comportements que les autres équipes projets n’ont pas car l’agile a besoin de ces comportements pour construire avec succès des équipes et des produits. Si on vous chargeait de construire une équipe agile, quelles seraient les qualités que vous regarderiez ? Ce document présente six comportements humains nécessaires au bon fonctionnement d’une équipe agile. J’ai également ajouté quelques questions que l’on peut poser dans les entretiens qui peuvent vous aider à déterminer si un candidat est apte à entrer dans une équipe agile ou pas.
Les personnes qui sont capables de - vraiment - travailler ensemble sont beaucoup plus précieuses que des personnes qui ne peuvent que travailler seules. Mais que signifie "vraiment collaborer" ?
La première chose que l’on remarque lorsque l’on observe une équipe agile est la forte collaboration entre les membres de l’équipe autour des fonctionnalités du produit. Dans les équipes non agiles, c’est classique de voir travailler individuellement les personnes sur les fonctionnalités du produit. Dans une équipe agile c’est courant de voir des développeurs et un testeur ou deux travailler ensemble pour s’assurer que la story a été correctement réalisée. On peut voir plusieurs testeurs travailler ensemble pour développer des tests, on peut également voir des développeurs et des testeurs travailler ensemble pour développer un système d’intégration continue pour l’équipe entière.
L’équipe entière travaille conjointement pour identifier, démarrer et terminer les fonctionnalités du produit. Les équipes agiles évitent d’avoir trop de fonctionnalités démarrées et non finies à la fin de l’itération, elles utilisent la coopération pour terminer en priorité les fonctionnalités en cours.
Une question que l’on pourrait poser à un candidat est : “Pensez à un projet récemment réalisé. Racontez moi un moment où vous avez eu à travailler avec une autre personne pour vous aider à terminer quelque chose. Que s’est-il passé ?”
Pour beaucoup de monde, ce n’est pas facile de demander de l’aide. Dans de nombreuses entreprises, demander de l’aide est une marque de faiblesse. Pourtant, les personnes qui sont capables de demander de l’aide sont des personnes que nous souhaitons recruter dans une équipe agile.
Pourquoi la capacité à demander de l’aide est-elle si importante ? Nous connaissons tous un peu mieux une partie du projet plutôt qu’une autre, mais aucun des membres de l’équipe ne maîtrise totalement l’ensemble. C’est pourquoi nous devons être capable de demander de l’aide et nous devons le considérer comme un atout - surtout pas comme une faiblesse. Dans une équipe agile, ce n’est pas un problème de demander de l’aide. Nous ne voulons pas qu’une personne reste bloquée, ce qui est important avant tout est que l’équipe livre toutes les fonctionnalités sur lesquelles elle s’est engagée sans donner plus d’importance à une personne qu’à une autre.
Une question que l’on pourrait poser à un candidat à propos de sa capacité à demander de l’aide : “Pensez au dernier projet que vous avez réalisé. Racontez moi une chose que vous n’arriviez pas à comprendre. Qu’avez-vous fait ?“
L’agilité, c’est avant tout l’écoute de l’autre. Nous procédons par itérations, pour pouvoir vérifier que ce nous venons de faire est correct. Nous avançons par étapes, afin que les utilisateurs puissent réagir sur le travail déjà réalisé.
Une des attitudes que vous recherchez chez un candidat est la capacité à avancer par petites étapes et à obtenir un retour sur chaque résultat qu’il a produit. Les gens qui ont besoin que les choses soient parfaites avant de les montrer ne sont pas faits pour l’agile (que ces gens soient développeurs, testeurs, ou autres).
Une des questions que vous pouvez poser est “Dites-moi comment vous aimez travailler. Rappelez-vous la dernière fonctionnalité sur laquelle vous avez travaillé. Avez-vous essayé de tout finir avant de demander des réactions?” Attendez la réponse. Puis demandez “Pourquoi?”. Le candidat pourrait vous déclarer que dès le premier jet il demande des avis. Ou bien il pourrait vous dire qu’on attendait de lui qu’il termine cette fonctionnalité à la perfection. Maintenant, vous pouvez demander “Quand vous travaillez sur un projet personnel, en dehors du travail, comment travaillez-vous?”
De la même manière, les gens qui sont capables d’avancer par étapes et d’accepter les avis doivent aussi accepter de faire des choses satisfaisantes, sans plus. Un des problèmes de l’agile est que nous n’avons pas le temps de faire les choses parfaitement à un moment donné. C’est pourquoi nous utilisons des timeboxes. Dans le temps imparti, nous faisons au mieux ce qui est à faire, et à partir des avis, décidons s’il faut ou non y revenir plus tard.
La capacité de se contenter de faire des choses juste assez bonne à un instant t et d’y revenir plus tard, lorsque ça a plus de valeur, n’est pas une attitude courante. Vous pouvez observer cette attitude chez les testeurs qui veulent absolument le meilleur système de test au début du projet. Vous pouvez également l’observez chez les architectes qui veulent définir complètement l’architecture au début du projet.
Un des problèmes de l’agile est qu’on ne peut pas dire quelle serait la perfection au tout début du projet. Quelquefois, on ne peut pas même pas le dire au milieu du projet non plus! Alors on a besoin de faire quelque chose qui est suffisamment bien à ce moment-là, et d’y revenir plus tard, quand on pourra augmenter la valeur du projet en se focalisant sur cette partie.
Pour déterminer si un candidat a la capacité de faire quelque chose qui est suffisamment bon à un moment, et de repousser la recherche de perfection, demandez: “Parlez-moi d’une période récente, pendant laquelle vous ne saviez pas tout au début du projet. Qu’avez-vous fait?”
Dans les projets agiles, comme dans tous les types de projets, les conditions de travail ne sont pas toujours idéales. Nous n’avons pas forcément un bureau pour toute l’équipe, nous n’avons pas forcément des critères d’acceptation pour toutes les fonctionnalités du projet, nous avons peut-être d’autres obstacles que nous ne pouvons enlever, mais le travail doit de toute façon être réalisé.
Nous ne recherchons pas des hommes parfaits; nous recherchons des personnes qui soient prêtent à s’adapter aux conditions de travail.
Vous saurez si vous avez trouvé une personne ouverte au changement en fonction des réponses que vous aurez à cette question : “Racontez-moi une anecdote où vous n’étiez pas dans des conditions de travail optimales. Qu’avez vous fait ?”
Un signe de la capacité d’adaptation d’une personne est sa capacité à travailler dans un domaine qu’il ne maîtrise pas. Je ne demande pas aux personnes de travailler sur des choses dont elles n’ont aucune idée de comment les réaliser - par exemple, un développeur ne doit pas se convertir en commercial (sauf s’il le souhaite). Je suggère simplement que si quelqu’un est très à l’aise avec les bases de données, peut-être qu’il devrait aussi essayer de travailler un peu sur les IHM. Si la personne est à l’aise avec le middleware, peut-être qu’elle aimerait travailler un peu sur la plate-forme ou sur le niveau applicatif. Si la personne est un testeur expérimenté, peut-être qu’elle pourrait essayer un peu le code. Si la personne est un expert en automatisation, peut-être qu’elle pourrait essayer l’écriture de tests unitaires.
Dans les équipes agiles, nous remarquons les personnes qui ont la volonté de travailler hors compétence lorsque ces personnes coopèrent en nombre sur le développement d’une fonctionnalité. Ces personnes travaillent en décalage avec leur domaine d’expertise mais toujours en gardant un lien. Pour en savoir plus sur cette capacité, demandez “Citez moi un moment où vous avez pris sur votre temps pour aider l’équipe. Comment ça s’est passé ?”
Les candidats ne seront pas forcément en mesure de répondre à la question. Vous pouvez les aider en leur précisant le contexte: “Nous travaillons sur des choses compliquées mais nécessaires à la réalisation d’une fonctionnalité pour l’échéance. Vous êtes-vous déjà trouvé dans cette situation ?”. Si le candidat ne répond pas oui, vous pouvez reformuler la question. Par exemple, j’ai parfois réussi en posant cette question: “Racontez moi une anecdote où vous avez réalisé une tâche qui ne faisait pas partie de votre description de poste. Qu’avez vous fait ?”
Il est possible que ce ne soient pas les seules comportements dont vous ayez besoin pour constituer votre équipe agile. Assurez-vous de bien analyser le poste pour identifier en quoi votre équipe agile est différente et vous saurez quel genre de candidats prendre en compte.
Article écrit en Anglais par Johanna Rothman et traduit en Français par Stéphane Gully et François Parmentier.
Discussion