Je sais ! Encore un article qui tourne autour de Jira… Désolé pour ça, c’est mon blog, j’y parle de mon quotidien, et en ce moment ça tourne beaucoup autour de Jira 😁
J’ai mené pas mal d’échanges récemment autour de la remise à plat d’espaces Jira. Quelque chose m’a frappé, et c’est ce que je voulais partager aujourd’hui :
Lors de ces sessions de travail, les concepts de l’outil, et donc sa configuration, étaient des sujets annexes.
Nous avons avant tout parlé d’équipes et d’organisation.
Une fois que les équipes, leurs périmètres et leurs modes d’interactions sont clairement identifiés, une fois que l’organisation est définie, la configuration de l’outil coule de source et est assez directe.
En quoi est-ce inhabituel
J’imagine qu’une fois dit comme cela, ça doit sembler assez évident.
Pour autant, tout au long de ma carrière j’ai assez rarement participé à des échanges avec ce type de dynamique quand on parle de Jira.
En général, on discute avec des experts Jira qui parlent de l’outil, avec :
Soit une posture ouverte, tournée vers les équipes, mais focalisée sur l’outil : les questions tournent alors autour de comment configurer l’outil. Ce qui ne marche pas trop mal quand le bénéficiaire sait ce qu’il veut, avec tout de même le risque de mettre en place un grand n’importe quoi.
Soit une posture fermée, tournée vers la gouvernance et l’homogénéisation collective. Au mieux, les questions prennent plus de hauteur et essayent de comprendre le besoin profond… Généralement pour expliquer au bénéficiaire qu’il n’en a pas besoin, qu’il devra se contenter du standard et que ça lui suffira bien.
Dans les deux cas, on ne se pose qu’assez peu les questions organisationnelles. On est en plein dans le syndrome du “Quand on a un marteau dans la main, tout ressemble à un clou” : ce sont des experts Jira qui se concentrent par réflexe sur Jira. 1
La notion d’équipe
Or, la dimension organisationnelle n’a rien d’évident.
Il y a de nombreux implicites dans Jira.
Par exemple, la notion d’espace (anciennement projet) est très liée à celle d’équipe. La recommandation par défaut de Jira c’est de fournir à chaque équipe son propre espace. Ce n’est pas une règle absolue mais cela devrait être la structuration dans la majorité des cas. Et comme pour bien comprendre les mécanismes de Jira il faut s’approprier sa philosophie, il faut donc avoir ce type d’élément en tête.
Sauf qu’en général, on parle d’équipe sans vraiment dire ce que c’est, sans le définir. Se dire simplement “on va créer un espace Jira par équipe” n’aide pas vraiment tant que l’on n’a bien compris ce qu’est cette fameuse équipe, au sens de Jira.
Bien entendu, cette définition d’équipe, au sens de l’imaginaire Jira, ne colle probablement pas avec toutes les “équipes” d’une organisation donnée.
On doit donc aller plus loin que cette simplification qui parle d’équipes sans définir ce que c’est.
De mon expérience, on doit alors poser des critères qui aident à définir et délimiter ce qu’est une équipe. On y voit…
Une notion de rythme, de cadencement. Si on a plusieurs rythmes en parallèle, cela pose la question d’est-ce une ou plusieurs équipes.
Une notion de pluridisciplinarité, d’un groupe de personnes capable de se saisir d’un ensemble de tâches. Si on a d’un côté des personnes capables de prendre en charge certaines tâches seulement et pas les autres tâches, et inversement pour les autres personnes du groupe, il faut alors se demander si c’est quelque chose que l’on veut changer ou si on est justement en face d’équipes distinctes.
Une notion de métriques et de reporting, comme un bon moyen d’identifier si on est en train de mélanger des choux et des carottes. Les rapports par défaut donneront des informations pertinentes si on a une forme d’homogénéité dans le travail qui est inspecté par les rapports. Pour des activités très différentes, on ne regarde pas les mêmes métriques, on ne fixe pas les mêmes types d’objectifs, on n’utilise pas les métriques de la même manière. Si ces éléments de travail différents sont portés par des personnes différentes alors il y a peu d’ambigüité sur le fait qu’il s’agit d’équipes différentes.
Il y a aussi la notion la plus intuitive : un groupe de personnes qui travaillent ensemble. Finalement, c’est cet aspect qui aide le moins :
Tout d’abord car ces groupes de travail sont imbriqués : on appartient à une équipe mais également au pôle qui contient cette équipe, ainsi qu’au département qui contient ce pôle, mais également à la division, à l’entreprise au global… Parmi tous ces niveaux, quel est le niveau à prendre et à considérer comme équipe ?
Ensuite parce que de nombreux rôles sont au moins partiellement transverses et c’est alors dans leur nature d’appartenir à plusieurs équipes, ou du moins d’y contribuer. Il est très important d’expliciter ce point, car cela éclaircit instantanément les réflexions autour de ces équipes.
Actuel vs cible
Dans ces réflexions, il faut bien sûr faire la part des choses entre l’actuel, l’existant, et la cible, là où on veut aller.
Un bon exemple classique serait une équipe de type Scrum composée de plusieurs pôles d’expertise : conception, développement Front-End, développement Back-End, test. On pourrait se dire que chacun de ces pôles d’expertise a ses propres tâches et travaille comme s’il était sa propre équipe. Ils ont aussi leurs propres rythmes, avec une conception qui travaille surtout en amont des sprints, un développement Front-End qui construit une release par sprint, un développement Back-End qui livre en continu chaque jour, et le test qui vit une période intense à chaque fin de sprint, quelques jours avant la release et la démo.
Bien sûr, ce que je viens de décrire, est simultanément criant de vérité, fidèle à la réalité de nombreux contextes, et très éloigné d’une mise en œuvre canonique de Scrum.
On doit donc se demander, en toute honnêteté — il n’y a pas de mauvaise réponse possible — si l’on veut garder ce mode de fonctionnement, ou si l’on veut justement casser cette séparation forte entre pôles d’expertise pour se rapprocher d’un Scrum canonique, où l’équipe ne ferait qu’un pour atteindre son objectif de sprint, où le déploiement continu serait la règle pour tous, et où le test comme la conception deviendraient eux aussi des activités continues. Bref, se demander si on vise à n’avoir qu’une seule équipe ou si l’on est satisfait d’en avoir plusieurs.
Cela va sans dire, il ne suffit pas de se fixer une cible et de configurer Jira sur cette cible pour que magiquement cela prenne forme. Le minimum sera de partager la volonté d’aller vers cette cible, de la verbaliser, de s’aligner et de rentrer dans une démarche de changement. L’outil apportant alors un support critique aux nouvelles manières de faire — mais ne serait qu’un fardeau de plus si l’on n’a pas compris le changement qui était entrepris.
Réduire l’écart entre l’outil et la réalité
Pourquoi s’embêter avec toutes ces questions ?
Questions qui, pour l’œil néophyte, peuvent presque plus ressembler à de la philosophie ou à de la masturbation intellectuelle qu’à un vrai sujet à adresser ?
Tout d’abord, c’est en ne se posant pas ces questions et en se jetant aveuglément dans la configuration Jira qu’on construit des monstres. C’est comme cela que l’on finit avec un Jira qui frustre tout le monde et qui ressemble à une bureaucratie poussée à son paroxysme, plutôt qu’à un outil qui aide le collectif à être plus efficace, plus transparent, plus redondant — et avec des métriques pour effectuer un véritable travail d’amélioration continue, réflexif, basé sur des données concrètes sur comment on fonctionne.
Il se joue un enjeu de transparence et de congruence : l’outil doit refléter la réalité pour l’outiller avec succès, pour fluidifier le travail, et pour apporter de la donnée pour l’améliorer.
On se doit de suivre la philosophie de Kanban : tout d’abord représenter la réalité telle qu’elle est, puis ensuite voir comment l’améliorer, étape par étape. L’outil permettant d’avoir les données permettant de décider quelle est la prochaine étape, et de vérifier l’amélioration.
Manœuvre de Conway inversée
J’oserais même faire un lien avec la loi de Conway. Un outil qui ne reflète pas la structure de communication, et par extension l’organisation et ses manières de travailler, c’est la recette pour l’échec.
De même, en appliquant une manœuvre de Conway inversée2, on devrait passer par ces questions et les réponses devraient se voir directement dans la structure mise en place du coté des espaces Jira. On structure l’organisation cible, et les outils reflètent cette structure.
Cela fait directement écho à mon précédent article qui comparait la philosophie de Jira avec le principe de dictature bienveillante.
En conclusion, j’y évoquais comment cela nécessite un ou une responsable digne du célèbre mouton à 5 pattes. Mon constat est que la plupart des responsables Jira ont une expertise réelle de Jira mais assez peu d’expertise sur les mécaniques organisationnelles.
Si la loi de Conway ainsi que la manoeuvre de Conway inversée ne te parle pas, nous avions fait une mini-série Scrum Life présentant ces deux aspects ainsi que Team Topologies qui s’appuie sur ces derniers. Team Topologies est d’ailleurs une manière d’outiller ces discussions autour de l’organisation !
