Méthodes agiles : 50 conseils pratiques (épisode II)
Cet article est le second d’une série de cinq épisodes intitulée Méthodes Agiles : 50 conseils pratiques.
11. Soyez droits dans vos bottes
Associez dès l’amont d’un projet le service juridique n’est pas une option. C’est indispensable. Ignorer les contraintes réglementaires peut conduire à s’aventurer dans le développement de fonctionnalités, voire de tout un service en ligne, bon à jeter à la poubelle ensuite, à minima nécessitant de sérieuses évolutions, retardant la sortie du site. N’oubliez jamais que la start up américaine qui a lancé le service que vous imaginez reproduire en France évolue dans un environnement réglementaire bien différent.
12. Bannissez l’interruption
Le cerveau humain est ainsi fait, qu’il lui faut parfois réfléchir continûment pendant deux heures à un problème afin d’en trouver la solution dans les cinq dernières minutes. Si un développeur informatique est interrompue par un collègue, un coup de fil ou une partie de baby-foot trop bruyante à proximité, au bout de la cent dixième minutes, tout l’effort fourni sera partiellement détruit, voir réduit à néant. Lorsqu’il reprendra sa réflexion, celle-ci repartira pour ainsi dire de zéro. Deux heures de perdues… pour lui et pour le projet. Remerciez l’inventeur des écouteurs.
13. Ecrivez des chef-d’œuvres
Le développement agile passe souvent par la rédaction de tickets, publiés par les utilisateurs, dans des logiciels dédiés aux méthodes agiles. La qualité de leur rédaction est primordiale. Le flot considérable de tickets logués dans le système ne saurait rendre tolérable l’imprécision, le flou, l’ambiguïté… Aucun développeur, ne sera comprendre une demande si elle est mal formulée. Pour chaque développeur essayez de comprendre son mode de prédilection pour comprendre une demande : a-t ’il besoin de captures d’écrans, de tableaux, de textes, de schémas, de liens hypertexts vers la page à laquelle l’utilisateur pense en écrivant sa demande d’évolution ?
14. Asseyez-vous sur les genoux des développeurs.
Rare sont les situations ou 100% des développeurs travaillent uniquement à votre projet (autrement vous avez de la chance). Pour s’assurer que vos demandes ne passent pas au second, voire au troisième plan, il peut être judicieux d’être très présent, physiquement, auprès des développeurs. Face à plusieurs demandes, provenant de différentes personnes ou émanant de différents projets, il est normal qu’un codeurs privilégie celle du plus haut gradé dans l’organisation, ou celle de son propre n+1, ou celle qui lui fait faire ce qu’il préfère, où celle qui présente un challenge qui l’intrigue, où celle de celui qui a crié le plus fort, ou celle qu’il a reçue en dernier, où celle gentiment demandée par la ravissante Eléonore… dont il est secrètement amoureux. C’est humain !
15. Protégez votre projet des interférences
Les développeurs sont souvent de bonne volonté et ne savent pas nécessairement dire non. Quelle équipe de développement ne s’est pas vu solliciter pour réaliser telle ou telle chose en marge du projet, provenant d’un autre donneur d’ordre que le Product Owner officiel, ou arrivant du sommet de la direction, ou émanant d’un autre service profitant de leur présence pour s’inviter dans le projet, pour en changer les contours, pour s’y greffer, pour le déstabiliser à des fins politiques… ? L’introduction de l’agilité dans l’entreprise ravive souvent les vocations des spécialistes des voies parallèles, des adorateurs des modes non-officiels, des francs-tireurs, des disrupteurs, des innovateurs dans l’âme, des anciennes stars déchues, des agitateurs, des revanchards…
S’ils ne savent pas toujours dire non, certains développeurs ont ce profil psychologique qui ne les prédispose pas à en informer le chef de projet. Alors, allez les voir, interrogez les et n’imaginez surtout pas que Greenhopper ou que tout autre tableau de bord apportant de la visibilité sur l’avancée des développements couvre l’intégralité de ce que font vos équipes de développement dans la journée.
16. Libérez la parole
Trop souvent, une fois un problème évoqué, les équipes marketing ou les leaders du projet (côté utilisateurs) se réunissent et réfléchissent à la solution. Quel dommage… de ne pas associer les développeurs à la discussion ! Certes souvent taciturnes ou en retrait, les codeurs ne sont pas pour autant les moins créatifs. Mieux, ils sont particulièrement précieux dans ce type de situations puisqu’ils sont familiers des approches innovantes, adeptes des solutions encore jamais vues, portés vers la pensée divergente, baignés dans un univers digitale fait de disruptions, coutumiers des mode dégradés, habitués à la difficulté, accoutumés à l’instabilité technique, rompus aux dysfonctionnements, prédisposés à emprunter des voies de contournement… Commencez par leur demander s’ils ont déjà été confrontés à un problème similaire par le passé. Vous serait surpris de la réponse.
17. Jouez les interprètes
Le marketing a son langage et les développeurs le leur. Les occasions d’incompréhensions ne manquent pas. Ne les laissez pas s’installer. Asseyez tout ce petit monde autour d’une table et jouez les interprètes. Animé vivement la discussion en vous assurant que chacun a bien posé toutes les questions dont les réponses importent pour l’avancée de son travail, a bien toute les informations nécessaires, a bien la même compréhension que chacun. Combien de fois a-t-on vu des équipes produits et des développeurs évoquer des usages très différents bien qu’utilisant les même mots. Reformulez la pensée des uns pour vous assurer que les seconds sont bien en phase avec eux.
18. Faites la guerre au re-work
Le re-work qui désigne le travail refait plusieurs fois au cours d’un projet n’est par un épiphénomène. Le cabinet Jupiter estimait qu’intervenir de manière pro active sur les erreurs identifiées dès la conception coûte jusqu’à 100 fois moins cher qu’intervenir de manière réactive sur la phase d’exploitation. Et que si les erreurs identifiées ne sont pas traitées immédiatement, les coûts sont d’autant plus importants que les corrections interviennent tard dans le processus de conception
19. Privilégiez le design thinking
Utilisez des techniques de design thinking pour faire émerger les idées. Elles sont libératrices, ouvrent les chakras de la créativité des collaborateurs, favorisent la figuration du résultat final attendu dans un langage compris de tous, permettent d’introduire de la méthode dans une démarche qui semble pouvoir s’en dispenser mais qui en a cruellement besoin : l’innovation.
20. Adaptez les méthodes d’innovations aux individus… et non l’inverse
On rencontre selon les entreprises où l’on met les pieds, une quarantaine de méthodes de design thinking (The 5 Whys, Stakeholder Map, Service Safari, A Day In The Life, Deskstop Walkthrough, etc.) tandis que certaines comme le Persona, le Lean Canvas, l’Elevator Pitch prévalent (peut-être un peu trop) et que d’autres issues du monde purement digitale (User Manual, FAQ, Press release…) méritent d’être explorées. Quoiqu’il en soit chaque individu à ses prédilections et il convient d’adopter la meilleure méthode pour votre projet, en fonction de sa nature et des personnes qui en seront les leaders, les contributeurs et les utilisateurs. Changez rapidement de méthode si le groupe ne parvient pas à avancer, patine, tourne en rond…