L’agilité a fait ses preuves, et accompagne désormais le développement de nombreux produits. La question de la place de l’expérience utilisateur dans cette méthodologie reste entière, comme celle de la business analyse par ailleurs. Comment assurer la conception d’un produit sprint par sprint ? Quand faire intervenir l’UX dans un processus projet agile ? Retour sur quelques expériences récentes pour faire le point sur 2 hypothèses de travail.

Hypothèse 1 : Tout le monde en même temps

Dans l’hypothèse de départ, tout le monde commence en même temps, UX et BA compris. Or, il se trouve que les développeurs et les designers ont besoin de cet input avant de commencer. Sur un sprint de 2 semaines, le degré d’occupation va donc varier énormément en fonction des profils : on commence par le BA, qui devra terminer son analyse le plus vite possible, puis l’UX, dans le même cas. Pendant ce temps, les designers et développeurs seront plus tranquilles, alors qu’en fin de sprint, ce sera l’inverse. Le BA et l’UX pourront alors consacrer cette fin de sprint au testing, et à prendre de l’avance sur le sprint suivant. Avec cette hypothèse, on peut aboutir à une situation équilibrée au bout de quelques sprints, mais les premiers risquent d’être très stressants pour l’UX et le BA, avec par conséquent plus de risques de devoir revenir sur certaines décisions par la suite.

Hypothèse 2 : 1 sprint d’avance

Une autre option dont on parle souvent est d’accorder à l’UX et au BA un sprint d’avance. L’idée est bonne, et permet de lisser le taux d’occupation de tous les profils, ainsi que de préparer le travail en amont. Le jour du planning, une grande partie de l’analyse et de la conception étant réalisée, il sera plus facile pour toute l’équipe d’estimer le travail à faire. Un des problèmes de cette façon de procéder est le risque d’avoir un décalage entre les profils. Il devient alors essentiel que tous les membres de l’équipe s’efforcent de garder du temps pour des discussions avec les autres profils : les développeurs pour aider et valider les solutions UX, et les UX et BA pour répondre aux questions et ajuster en fonction des feedbacks des développeurs et designers. Dans cette hypothèse de l’UX dans l’agilité, la communication entre les équipes est clé. Une option pour éviter de mobiliser l’ensemble des équipes peut être de désigner un interlocuteur privilégié par profil, qui pourra identifier les sujets à discuter tous ensemble, et archiver ceux qui peuvent l’être.

En conclusion

Entre ces deux hypothèses mon cœur balance encore… J’ai récemment testé les deux, et aucune ne m’a paru absolument idéale. L’hypothèse 1 a effectivement généré beaucoup de stress pour moi en début des premiers sprints, ne me laissant que peu de temps pour mener mon analyse. L’hypothèse 2 n’est pas non plus idéale, parce qu’elle génère forcément un décalage entre les équipes.

Toutefois, je pense que le sprint d’avance est plus prometteur, à condition de faire encore plus d’efforts en termes de communication entre profils. Dans mon cas, le Scrum master a été clé dans cette démarche, en nous aidant à mettre en place des ateliers de conception communs à toute l’équipe, et des ateliers hebdomadaires de questions / validations UX. L’important est de ne pas déconnecter le sprint d’avance. Si cette condition est respectée, alors le sprint d’avance accomplit tout son potentiel, et permet de vraiment faciliter le planning en répondant aux questions majeures, et permettant d’identifier par avance certains risques à anticiper.