Comment dénicher le faux Scrum/agile en entretien ?
Quelques questions à poser en entretien
On a posé la question suivante à propos de mon article qui dénonçait les impostures de l’agilité et de Scrum… (lien en fin d’article)
Du coup, vous auriez des éléments de questions à poser en entretien pour éviter les faussaires ?
Voici donc une liste non exhaustive de questions qu’un développeur pourrait poser en entretien à son futur employeur, avec un focus particulier sur Scrum et ses Sprints.
Je me rends compte en l’écrivant que la liste pourrait être sans fin…
Quelle est la durée de vos Sprints ? Pourquoi cette durée et pas une autre ?
C’est bien le pourquoi qui nous intéresse. Il n’y a pas de mal à faire des itérations de 3 voire 4 semaines si le contexte le justifie. Et justement, si c’est un produit sur une stack moderne, par exemple web ou mobile, il faut alors de sacré bonnes raisons pour le justifier.
Evidemment, la meilleure réponse est celle qui fait écho à des expériences précédentes et donc avec des arguments factuels. Ce qui nous amène à la question suivante…
Quelles sont les différentes durées de Sprint que vous avez essayé ? Qu’en avez-vous retiré ?
Et oui car c’est ça le plus important : essayer !
S’ils ont effectivement testé et pas juste suivi l’industrie ou le reste de l’entreprise, vous pourrez alors discuter de ce qu’ils en ont retiré… Mais aussi de comment ils ont mené l’expérience : pendant combien de Sprints ? Et à quel moment de l’année ? Il est facile de “tester” des durées de Sprint différentes quand il est juste question de faire face aux absences pendant les périodes de fêtes et les vacances…
Comment estimez-vous ? Faites-vous des roadmaps ? Comment sont-elles tenues à jour ?
Question piège
Ces questions sont pernicieuses à plusieurs égards. Tout d’abord elles partent du principe que bien sûr, il faut estimer et que bien sûr, il faut des roadmaps. C’est donc potentiellement un piège que vous tendez à votre interlocuteur qui, s’il en est lui-même convaincu, n’envisagera même pas qu’il soit possible de faire autrement.
À l’inverse, il va de soi que si on vous parle de #NoEstimates ou d’un Kanban de suivi des initiatives produit, c’est un bon début. Vérifiez quand même que ce n’est pas juste un discours bullshit bien préparé mais ça semble peu probable.
Les estimations
Si donc on vous parle justement d’estimations et de roadmaps, challengez la manière dont elles sont faites et maintenues, et surtout le pourquoi de ces pratiques.
Ainsi, il y a plein de bonnes raisons qui justifient l’usage des points plutôt que des heures. Mais les heures ne sont pas intrinsèquement mauvaises. Méfiez-vous tout de même de phrases comme :
On a essayé les points et puis au final tout le monde faisait le calcul par rapport aux jours-hommes donc ça ne servait à rien, alors on a arrêté et on est revenu aux heures.
… Autant dire qu’ils n’ont jamais réellement compris et appliqué le concept.
Les roadmaps
Au niveau des roadmaps, challengez aussi la compréhension de l’incertitude et du coût que représente la maintenance d’une roadmap par rapport à la valeur qu’elle apporte.
Mais aussi : qui est en charge de sa maintenance ? Est-ce un travail du chef de projet ? (tiens, tiens, il y a donc un chef de projet…) Du Product Owner ? De “l’équipe produit” ? (qui c’est au juste ?) De toute l’équipe, développeurs inclus ? Vous avez compris où je veux vous emmener.
La boîte de Pandore
Ce qui est vraiment super avec le sujet des estimations, c’est qu’on peut se retrouver à parler des trois quarts des sujets importants juste en partant des estimations :
- Importance de la prédictibilité dans l’entreprise ou sur le projet — et pourquoi ? Est-ce réellement nécessaire ?
- Comment gère-t-on l’engagement de l’équipe ? Qui décide ? Qui a le dernier mot ? Sur quoi se base-t-on ? Que fait-on quand on découvre en cours de Sprint que “ça va pas le faire” ? Qu’est-ce qui compte réellement, qui définit le succès du Sprint ?
- Comment est mesurée la performance de l’équipe ? Et sa capacité de production ? (quoi c’est pas la même chose ?)
- Comment est définie la liste des fonctionnalités à venir ? Comment sait-on si le ROI sera bon ?
Faites-vous des objectifs de Sprint ? À quoi cela ressemble-t-il ?
L’oublié de Scrum
Une question intéressante à poser notamment si les réponses sur l’estimation semblent un peu bancales.
D’une manière générale, la majorité des équipes ont “oublié” ce détail essentiel du framework Scrum et ne définissent pas d’objectif de Sprint. Il reste ensuite une bonne portion d’équipes qui essaient de définir des objectifs de Sprint mais s’y prennent mal et restent peu ou prou sur un objectif qui ressemble à :
Finir tout le périmètre du Sprint (autant dire aucun objectif de Sprint)
Ou encore :
Faire les sujets A, B, C, D et E (modèle liste de course)
Finalement, il y a assez peu d’équipes qui définissent réellement des objectifs de Sprint.
Continuous Delivery | Kanban
Ceci dit, si l’équipe est déjà en transition vers du Kanban sans le dire ou sans s’en rendre compte, et qu’elle délivre de la valeur au fil de l’eau, ce n’est pas si grave.
Il faudrait quand même penser à arrêter de faire Scrum, ça éviterait de s’ennuyer durant des rituels inadaptés…
À quelle fréquence livrez-vous en production ?
Finalement, c’est peut-être la question la plus importante. Mal appliquer Scrum ce n’est pas si grave. S’empêtrer dans des problèmes techniques est inacceptable.
Par contre, il faut être vigilant car il peut être facile de répondre à la question en faisant du pipeau.
Il faut faire la différence entre le fantasme de la personne en face de vous, que cela soit la cible qu’il aimerait atteindre ou la perception erronée qu’il a de la réalité, et les chiffres réels. Un classique serait :
On livre à chaque fin de Sprint.
Alors que la réalité serait :
… quand on y arrive.
Les régressions
Et le tout n’est pas de livrer souvent : en moyenne, combien de régressions sont introduites par chaque mise en production ?
On a peut-être une super architecture en micro-services, avec plein de développeurs qui poussent en prod tous les jours… Sans vérifier les impacts sur le reste du système, et on se retrouve avec des régressions toutes les semaines.
Vous me montrez votre dashboard ?
Evidemment, le top serait de vous montrer les dashboards des différents outils de mise en production, de monitoring de la prod’, des suivis de bugs…
Que les chiffres soient bons ou mauvais, si on accepte de vous les montrer c’est déjà un très gros bon point sur leur transparence et leur volonté de s’améliorer.
Comment documentez-vous le produit ? Quels outils utilisez-vous ?
On s’en fiche de l’outil, mais ça rend la question plus anodine, notamment si vous êtes développeur. Parce que, selon les clichés, un développeur n’aime pas écrire la doc mais aime bien les outils. Donc parler d’outil est un bon cheval de Troie.
Revenons donc à la question : pourquoi demander comment le produit est documenté ? C’est un peu une question piège justement. Il doit y avoir eu un débat autour de la documentation et une réponse réfléchie et argumentée :
- S’il n’y a pas de débat parce que de toutes façons on écrit des spécifications fonctionnelles détaillées… C’est du Cycle en V brandé agile ?
- S’il n’y a pas de débat parce que de toutes façons “en agile on fait pas de doc”…C’est du L’arrache brandé agile ?
En cascade, cette question peut déboucher sur les différents rôles et responsabilités dans l’équipe et en dehors de l’équipe, mais aussi sur la stratégie de test et la mise en place de tests automatisés. On peut aussi parler des clients et partenaires, ou des départements Sales et Marketing qui ont en général besoin d’une doc pour réussir à vendre ou promouvoir le produit.
Est-ce que les objectifs annuels sont individuels ? Ou liés à la performance de mon équipe ?
Cette question risque de faire bondir votre futur N+1 si la transformation agile n’a pas réellement été consommée.
C’est aussi l’occasion de mener un débat quasi-philosophique sur les fondements de l’organisation et sur la culture managériale.
Car fondamentalement, il n’y a pas de moyen réellement pertinent de mener des évaluations individuelles lorsque le but est de favoriser le travail d’équipe.
Je ne dis pas qu’il faut absolument que votre nouvelle entreprise soit une entreprise libérée, mais a minima cette question devrait mener à des débats passionnants si le sujet a été réellement abordé au sein de l’entreprise.
Au passage, vous pourrez aussi débattre d’un sujet aussi simple que la période d’évaluation : si on vous dit que l’évaluation est annuelle avec aucun ajustement en cours d’année… Où est l’adaptation au changement dans tout ça ?
Et vous, quelles autres questions poseriez-vous ?
La liste est sans fin !
Pour aller plus loin
L’article d’origine dénonçant les impostures de l’agilité et de Scrum et le commentaire de Pierre Tondereau sur LinkedIn
Board Kanban d’initiatives
Consultez les nombreux excellents articles de John Cutler sur le sujet.
Les estimations agile
#NoEstimates c’est quoi ?
L’objectif de Sprint
Que pensez-vous de cet article ?
Si vous avez aimé cet article, merci d’applaudir 👏 et de le partager !
Et pensez à souscrire à ma newsletter !
À bientôt 😊