Transition Agile : les 3 principales conversations à avoir avant de se lancer

Les trois conversations dont vous avez besoin avant de commencer

Martin Suntinger Par Martin Suntinger
Parcourir les rubriques

Trop souvent, les entreprises partent avec la mission de « devenir Agile » avant de vraiment comprendre ce que cela signifie. Des fissures se manifestent, les attentes ne sont pas atteintes, tout le monde commence à s'interroger sur la valeur de « devenir Agile », ce qui nuit à vos chances d'y parvenir.

La vérité est que devenir Agile permet aux équipes d'être plus productives et de livrer plus rapidement des projets, mais c'est uniquement possible lorsque les règles du jeu font l'unanimité. Rejoignez Heather Fleming et Justin Riservato (du géant du commerce électronique Gilt) pour discuter des raisons pour lesquelles l'obtention d'un consensus sur les principes de l'agilité est plus importante que la mise en œuvre d'un processus.

Plus précisément, Heather et Justin explorent les réponses à trois questions essentielles auxquelles toute équipe doit être prête à répondre avant de se lancer dans le parcours Agile :

  • « Mais quand aurez-vous terminé ? » Pourquoi la conversation la plus importante (et la plus difficile) lors du passage à Agile concerne l'abandon du concept de dates butoirs.
  • « C'est ma priorité absolue, mais je ne peux pas vous rencontrer avant la semaine prochaine. » Que faire lorsque votre partenaire commercial ne peut (ou ne veut) pas être un membre à part entière de l'équipe.
  • « Je veux juste programmer. Pourquoi dois-je participer à toutes ces réunions ? » Pourquoi l'implémentation de Scrum n'est pas la première étape pour devenir Agile.

Regarder et apprendre

Questions réponses

Heather et Justin ont sélectionné certaines des questions les plus importantes de la séance de questions réponses de cette présentation. Lisez la suite pour en savoir plus sur les techniques d'application des méthodologies Agile.

Q1 : Tableau Agile numérique et tableau Agile physique ? Qu'en pensez-vous ?

R1 : Cela dépend vraiment de votre équipe. Travaillez-vous tous au même endroit ? Quelle est la taille de votre équipe ? Avez-vous de l'espace pour un grand tableau physique ? Chez Guilt, nous avons essayé les deux méthodes, mais nous avons constaté que lorsque nous grandissons et développons des dizaines d'équipes, les tableaux Agile de Jira Software sont plus pratiques que les tableaux physiques. Ils sont plus faciles à configurer et à modifier, mais aussi à partager avec les membres d'une équipe distribuée. Les tableaux physiques ont un avantage : vous ne pouvez pas les ignorer, ils vous sautent aux yeux. En outre, c'est l'endroit idéal pour discuter spontanément du travail en cours ou pour organiser des stand-ups, le cas échéant.

Q2 : Comment pouvez-vous travailler avec un responsable ou un client qui ne suit pas ou ne comprend pas le processus Agile ? J'ai parfois l'impression de ne pas réussir à expliquer le workflow.

R2 : Il est essentiel de réfléchir à l'ordre de vos opérations. Si vous essayez de travailler suivant un processus Agile avec des personnes qui n'y croient pas, vous brûlez les étapes. Le plus important est d'obtenir un consensus au niveau de la philosophie avant de lancer un processus. Nous l'avons fait par le passé en analysant les problèmes spécifiques rencontrés par une équipe au cours du processus actuel et en les résolvant de façon Agile. Pouvez-vous passer en revue les réels problèmes que votre manager ou client tente de résoudre et lui expliquer votre approche basée sur le framework Agile ? Pouvez-vous l'aider à devenir Agile, plutôt que de modifier du tout au tout le processus global ? Vous obtiendrez ainsi de vrais résultats (de façon incrémentielle), étant donné que l'équipe est plus efficace. Bref, adoptez une approche Agile pour devenir Agile. ;)

Q3 : Comment pouvez-vous mettre en œuvre un processus Agile lorsque le projet est soumis à un forfait et/ou un horaire fixe et que vous devez mettre en œuvre une liste d'exigences ?

R3 : Tout d'abord, il est impossible de mener à bien un projet avec un calendrier fixe ET une liste fixe d'exigences à mettre en œuvre, alors y a-t-il un moyen de mettre tout le monde d'accord que ce n'est qu'un rêve ? La plupart des contraintes liées aux délais et aux exigences ne sont pas de vraies contraintes : ce sont des souhaits. Déterminez les raisons pour lesquelles vous faites le travail, et le problème que vous essayez de résoudre. Si vous comprenez vraiment les objectifs du projet et les raisons derrière les contraintes, vous pouvez vous assurer que l'équipe fait le bon travail au bon moment. Lister toutes les exigences en indiquant des dates n'assure pas le respect des délais.

Q4 : La plupart des projets ont une date de livraison, généralement communiquée aux partenaires et aux clients. Dans ce scénario, seul l'ensemble de fonctionnalités est négociable (même si certains compromis sont faits sur la qualité). Comment surmontez-vous les contraintes liées à une échéance stricte ?

R4 : Nous pensons que vous avez répondu vous-même : en négociant le cahier des charges. Dans le cas contraire, vous avez raison : la qualité en pâtira. Penser que vous pouvez tout simplement bourrer le cahier des charges est un rêve : vous devez vous assurer que vos équipes sont en phase avec la réalité, même si ce n'est pas ce que les gens veulent entendre. Heather a écrit un petit billet de blog sur ce sujet. Vous pouvez le lire ici.

Q5 : Selon vous, qu'est-ce qui devrait changer dans l'implémentation de Scrum ?

R5 : La rigidité de Scrum est notre plus gros problème. Penser qu'un seul processus très prescriptif fonctionnera pour toutes les équipes, indépendamment de leur domaine de travail et de leur identité, serait présomptueux. Nous avons vu que cela fonctionnait pour certaines équipes, mais Scrum n'est pas la seule façon d'être Agile, et beaucoup d'équipes échouent parce qu'elles pensent qu'elles doivent implémenter Scrum d'une manière spécifique avec l'ensemble des rôles, user stories, critères d'acceptation, réunions et artefacts. Heather a également un ticket intitulé « Scrum Master ». ;)

Q6 : Comment pouvez-vous empêcher les parties prenantes d'influencer directement les membres de l'équipe ?

R6 : Eh bien, une bonne partie prenante EST un membre de l'équipe. Idéalement, intégrez donc la partie prenante clé à votre équipe afin que tout le monde puisse travailler de concert. Si vos parties prenantes sont promptes à jeter la patate chaude à votre équipe, ou à faire irruption en cours de projet et essayer de tout changer, il est essentiel que tous les membres de l'équipe comprennent ce qu'ils font et pourquoi. Peu importe à qui parlent les parties prenantes, elles obtiendront la même réponse. C'est ce qui fait de vous une véritable équipe, et pas une somme d'individus. Vous devez communiquer (beaucoup) et vous assurer que tout le monde est sur la même longueur d'onde et rame dans le même sens.

Q7 : Pour réaliser une estimation des stories, utilisez-vous de vagues estimations d'ordre de grandeur (en heures) ou des points ?

R7 : Les deux, et certaines équipes ne réalisent aucune estimation. Les points sont pratiques, car ils sont plus abstraits et ne sont liés à aucun calendrier spécifique. Les heures peuvent constituer une bonne transition si votre équipe est réticente à l'estimation, puisqu'elles sont plus tangibles. L'objectif de l'estimation est de pouvoir déterminer si votre sprint est trop lourd ou trop léger et l'ajuster. Elle ne sert plus à rien une fois le sprint lancé. Nous avons remarqué que lorsque vous travaillez avec une équipe depuis un certain temps, le processus d'estimation devient inutile. Nous pouvons tous analyser les tâches et dire assez facilement si le sprint convient ou non.

Q8 : Quelle valeur accordez-vous aux chefs de projets qui ont des compétences approfondies en matière d'analyse et une parfaite maîtrise des produits et ne se contentent pas de coordonner les réunions entre les parties prenantes des secteurs de la technologie et du commerce pour rassembler les exigences ?

R8 : À peu près toute la valeur :) Les aptitudes comme l'organisation de réunions et la prise de notes (entres autres) ne sont pas des compétences spécialisées. Elles sont à la portée de tout un chacun. Bien qu'elles soient importantes, ce n'est pas vraiment la plus grande valeur ajoutée que vous pouvez apporter à l'équipe. Si vous ne faites que du travail administratif, l'équipe peut légitimement se demander pourquoi vous en faites partie. Chaque membre de l'équipe PMO de Gilt comprend parfaitement le domaine, les outils et les techniques pour accomplir le travail, et en fait profiter toutes les personnes avec lesquelles il travaille. Auparavant, bon nombre d'entre nous étaient ingénieurs ou travaillaient avec d'autres départements de Gilt, et disposaient d'une expertise unique en la matière.

Q9 : En général, quelle est la taille des équipes et quelle est l'expérience des membres avec Gilt ?

R9 : Idéalement, nous souhaitons que nos équipes soient épurées, mais suffisamment grandes pour être autonomes, leur permettant ainsi d'avancer sur les projets sans dépendre des autres équipes. Nous suivons la règle des « deux pizzas » : deux pizzas doivent suffire pour nourrir une équipe. Nous avons la conviction que chaque individu apporte un ensemble de talents uniques à l'équipe, et ce, quel que soit le poste qu'il occupe. Par conséquent, si en principe le responsable produit est chargé de toutes les présentations mais n'est pas à l'aise, et si un ingénieur est un excellent orateur et sait conquérir un public, nous allons permettre à cet ingénieur d'apporter ce talent à l'équipe. Vous êtes bien plus qu'un intitulé de poste !

Q10 : Comment gérez-vous une équipe d'assurance qualité distincte, en particulier lorsque les tests sont réalisés dans un sprint distinct du développement ?

R10 : C'est l'un de nos points de vue les plus controversés, mais, chez Gilt, nous n'avons pas d'équipe QA distincte. Nous croyons aux tests d'automatisation tout au long du processus de développement et de déploiement. Les équipes sont responsables de la qualité de leur code. Si vous avez le temps et l'expertise nécessaires pour écrire du code, vous êtes en mesure d'écrire des tests afin de vérifier la qualité. Pour nous, transmettre directement le code à une équipe QA n'a jamais donné de bons résultats. En outre, cela nécessite beaucoup de documentation supplémentaire et de temps pour informer les équipes QA.

Q11 : Si vous avez des équipes qui travaillent simultanément sur plusieurs « produits », serait-il viable de rassembler tous les gestionnaires de produit dans le groupe de discussion pendant la planification du sprint et de leur faire déterminer les priorités relatives entre les produits ? D'autres idées ?

R11 : Stop ! Ce ne serait clairement pas viable. L'équipe doit compter un gestionnaire de produit et ne doit pas travailler sur différents produits qui impliquent plusieurs gestionnaires de produit extérieurs à l'équipe. Qui que soit le chef d'équipe, il doit s'imposer et expliquer clairement la méthodologie de priorisation de l'équipe et l'ordre d'exécution des tâches en fonction de cette méthodologie. Cela renvoie au point suivant : « vous devez être aligné sur votre méthodologie avant de mettre un processus en place. »

Q12 : J'essaie d'amener l'équipe des services de création marketing à utiliser Agile. Certains livrables DOIVENT être livrés à une certaine date (conception d'une publicité à imprimer dans un magazine). Comment pouvons-nous adapter ces projets au framework Agile ?

R12 : Agile peut gérer ce genre de contraintes. C'est à l'équipe d'identifier les mesures à prendre et les délais associés, et de planifier des sprints en conséquence. Agile devrait vous aider à respecter ces délais, puisqu'il vous permet d'ajuster vos priorités et vos tâches planifiées (périmètre) dans le cadre de chaque sprint. Si vous commencez à suivre votre vélocité, vous pourrez très vite savoir si vous allez respecter ces délais rapidement ou non. Il incombe ensuite à un bon chef d'équipe de négocier les éléments dont l'équipe a besoin pour réussir.

Q13 : Changer les objectifs ne semble-t-il pas une perte de temps ?

R13 : Oui, mais nous ne parlons pas de « dérive des objectifs », car nous voulons encourager le changement au cours du projet. L'un des principaux avantages d'une philosophie Agile est qu'elle vous permet de vous adapter aux facteurs que vous ne contrôlez pas. Si le paysage concurrentiel ou vos besoins métier évoluent, ou si de nouvelles technologies sont disponibles, souhaitez-vous réellement continuer avec la matrice d'exigences élaborée plusieurs mois auparavant ? Si vous voulez livrer le meilleur produit à vos clients, opérez le changement et tirez-en parti. Aucune « dérive des objectifs » n'existe dans Agile (insérez ici la persuasion de Force Jedi).

suivant
DevOps