En tant que scrum master, je veux arrêter de parler de « user story » dans le but de réconcilier le business et l’IT

Organisations agiles

Les entreprises pour lesquelles nous travaillons font face à des changements rapides et brutaux sur leurs marchés, avec notamment des enjeux digitaux et d’intelligence artificielle accrus. Pour autant, elles disposent des mêmes ressources pour accomplir ces challenges, à savoir leur système d’informations, leurs ressources humaines, et leur organisation.

Pour faire face à ces demandes, une réponse apportée a été de rendre les développements « Agiles ». Evidemment, les problématiques viennent toujours de l’IT. Alors, les entreprises ont recruté des scrum masters, et des coachs agiles pour accompagner les équipes à travailler différemment. Ces derniers se sont rapidement rendus compte qu’un des facteurs clé de succès (et d’échec !) est l’organisation au sens large.

D’une part, une transformation ne peut se faire sans impliquer tous les niveaux de management. Ceux-ci sont généralement des piliers dans l’entreprise de part leur expérience et leur connaissance des entreprises dans lesquelles ils agissent. L’accent est mis aujourd’hui sur la posture de ces managers, que l’on pousse aujourd’hui à être 3.0, dans le but de faire grandir à leur tour les collaborateurs qu’ils accompagnement, et d’agir en tant que leader dans leur organisation.

D’autre part, la transformation passe par la culture et les codes de l’entreprise, les valeurs véhiculées par celle-ci, et leur capacité à remettre en question leurs processus, leur manière de travailler, les outils utilisés afin de maîtriser leur chaîne de valeur.

Voici maintenant un petit exemple d’une organisation de projet qui pourrait se penser agile : elle a parfois la chance d’avoir un Product Owner dedié, qui travaille dans un bâtiment assez éloigné de celui de l’IT, et qui est secondé par un Proxy Product Owner (un business analyst ?), dans les locaux de l’IT pour écrire nos fameuses user stories. Les Proxy + Product Owner doivent solliciter d’autres Business Analysts et Chefs de projets, voire des personnes ne travaillant pas sur le projet pour comprendre le besoin et avoir des retours sur sa faisabilité. Ils échangent également avec les UI designers pour ajuster les maquettes à implémenter, même si le SI actuel laisse paraître une incompatibilité pour implémenter le besoin. L’utilisateur est aussi sollicité parfois, et est insatisfait des couleurs choisies pour les interfaces, et préfère les anciens outils car il en avait l’habitude. Et l’IT en profite pour faire quelques refontes techniques. On peut présager de la difficulté du projet (on est loin du produit), et de celle des user stories à écrire. Nous souhaitons du courage aux développeurs, qui peuvent facilement perdre de vue l’essentiel. Pensez-vous vraiment que cette organisation est agile ?

Pour pallier ces contraintes, voici quelques pistes de réflexion :

• Réalisez un schéma de l’organisation, afin de visualiser les personnes impliquées sur le projet, par type de population (développeurs, managers, analysts…), selon leurs dépendances hiérarchiques, site géographique… Cela peut être utile lorsqu’un grand nombre de personnes intervient sur le projet, notamment pour conduire le changement auprès des managers sur les délais de livraison des fonctionnalités (de l’idée à la mise en production), sensibiliser sur le ratio développeurs / intervenants sur le projet (il peut s’avérer surprenant !), ou simplement pour présenter la structure aux nouveaux arrivants.

• Initiez une matrice de connaissances, afin d’identifier les sachants, et créer plus facilement des binômes pour transférer les savoirs. Cela permet aussi d’identifier plus simplement les personnes à contacter. Le passage de connaissance peut être réévalué une fois par trimestre par exemple. Il peut aussi s’avérer judicieux d’identifier les personnes ayant des connaissances sur les sujets abordés, même s’ils ne font pas partie de l’équipe projet, afin d’établir au plus tôt un plan de communication au besoin.

• Capitalisez sur la connaissance de l’équipe en ayant une documentation minimale : j’ai souvent constaté que les applications développées possèdent soit un bottin en guise de documentation, soit des fichiers qui se promènent sur différents espaces de stockage, partagés ou non, soit une absence de documentation. Pour historiser les connaissances, les équipes peuvent utiliser un outil simple comme Confluence de la suite Atlassian et mettre à jour la documentation utile à une fréquence définie. Ce besoin de capitalisation peut d’ailleurs s’inscrire dans la Definition Of Done de l’équipe. Veillez au départ à définir une arborescence claire, ainsi que le contenu utile. La documentation doit servir à l’organisation et il convient à ce titre d’en définir l’objectif dès le départ. Elle doit également être élaborée en fonction du contexte de l’entreprise (organisation multi-sites, turnover…). Enfin, n’oubliez pas, la meilleure documentation, c’est le code 🙂

• Mettez en place des processus partagés : rapidement, il convient d’identifier par qui doit « transiter » la user story, et quelle est la contribution de chacun. Il peut être intéressant d’organiser un atelier pour coécrire une user story, et capitaliser dessus comme template pour les suivantes. Cela permettra en même temps d’aborder une partie des rôles et des responsabilités. Il conviendra de présenter la user story à l’équipe de développement afin d’obtenir leur feedback sur le format, et s’avoir s’ils disposent de toutes les informations nécessaires pour comprendre le besoin.