La philosophie de Jira
Note : dans cet article, quand je vais parler de “Jira”, c’est un raccourci pour parler de “Jira delivery”, c’est à dire le Jira historique, qui permet de gérer le quotidien d’une équipe avec son backlog, ses work-items, ses workflows, ses sprints, ses releases (versions), ses tableaux, ses rapports et métriques.
Dans Jira, si vous voulez faire évoluer l’espace Jira de votre équipe, vous devez soit trouver un administrateur, soit être administrateur vous-même.
Pourquoi ?
La plupart des espaces Jira delivery sont dits “company managed” ce qui veut dire que les work-items et workflows sont partagés avec l’ensemble de l’instance Jira, et donc, pour les faire évoluer, il faut être administrateur au niveau global de l’instance Jira.
En théorie, il y a une solution à cela : faire des espaces Jira dits “team managed” dans lesquels un administrateur de l’espace peut modifier directement, en toute autonomie, les éléments de son espace. Sauf que ça ne marche pas en pratique, à moins que le travail à gérer soit quelque chose de simple — oserais-je même dire plutôt : quelque chose de simpliste ! 1
Les limitations des espaces “team managed”
❌ Pas d’hybridation possible, c’est tout ou rien. On ne peut pas avoir, par exemple, un modèle standard d’Epic ou d’Initiative pour l’ensemble des espaces Jira (dans une perspective de pilotage à l’échelle, même très léger) tout en gardant l’autonomie des équipes sur le reste de leur espace. Dès lors qu’on a un minimum d’enjeux d’harmonisation, d’agrégation ou de pilotage à l’échelle, le modèle “team managed” ne marche pas.
❌ Les outils mis à disposition des espaces “team managed” sont simplifiés au point de les rendre inefficaces. Voici par exemple le genre de choses que l’on peut faire en “company managed” et que l’on ne peut pas faire en “team managed” :
On ne peut pas appliquer les pratiques Kanban en complément de Scrum. En “team managed” on doit choisir de manière exclusive entre “Scrum” et “Kanban”. Par exemple si on choisit “Scrum”, on a des sprints mais on n’a pas accès aux éléments du mode “Kanban”. Ces éléments sont pourtant cruciaux pour une bonne animation du quotidien de l’équipe, y compris une équipe Scrum, comme la visualisation du Work Item Age. (dans Jira, ce sont les petits points gris puis rouges qui sont ajoutés à côté de chaque carte)
En “team managed”, la majorité des rapports Jira sont absents et ceux qui restent sont simplifiés : pas de CFD si vous avez choisi l’option “Scrum”, impossible d’avoir une vélocité basée sur le nombre d’éléments terminés…
En “team managed” toujours on ne peut pas appliquer des filtres JQL arbitraires pour colorier des cartes du tableau ; une fonctionnalité un peu obscure mais extrêmement puissante pour implémenter du management visuel
Bref, les espaces “team managed” sont nerfés par rapport aux espaces “company managed”, tant et si bien qu’en “team managed” on est obligé de rester à de la gestion d’équipe pour bébé.
Une équipe a besoin de :
Management visuel puissant
Métriques et indicateurs pour piloter son quotidien
Métriques et indicateurs pour piloter son amélioration continue
Choisir l’option “team managed” c’est s’interdire tout cela et donc rester dans la pataugeoire de la gestion d’équipe.
Seule issue : le “company managed”
… et donc, dépendre de l’administration centrale pour les changements les plus structurants aux espaces d’équipe Jira. 😭
Pourquoi ne pas distribuer le rôle d’administrateur ?
Justement parce qu’on parle ici d’administration de l’ensemble de l’instance Jira !
Ce modèle peut marcher mais devient une posture de plus en plus difficile à tenir à mesure que l’organisation est grande :
Enjeu de ne rien casser : être administrateur de l’instance, cela veut dire pouvoir toucher à tout. Il faudrait donc former tous ces administrateurs ainsi que mettre en place les mécanismes de contrôle ou vérifications pour s’assurer qu’ils ne cassent rien. En soi, ce n’est pas impossible, mais on voit bien que ce n’est pas anodin de prendre cette posture.
Surtout, rien n’est fait dans Jira pour faciliter la mise en place de ce type de gouvernance : ce n’est pas l’état d’esprit de Jira.Segmentation de l’information et des périmètres de responsabilité : un administrateur d’instance a accès à tout. Dans de nombreuses organisations on va vouloir éviter de donner accès à tout à tout le monde. On préfère plutôt segmenter l’accès à l’information ainsi que les périmètres de responsabilité.
Parfois, c’est même une obligation par rapport à des contraintes d’audit et de traçabilité, sans même parler des projets confidentiels.
Ce n’est pas juste une question de philosophie ou de culture d’entreprise, c’est une réalité.
Et les administrateurs d’espace ? Une autre voie sans issue
Techniquement, il existe aussi le rôle d’administrateur d’espace. On peut envisager donner ainsi une forme de liberté à une personne sur son propre espace sans lui donner les accès d’administration sur l’ensemble de l’instance.
Cette option vient avec son lot de contraintes. On reste sur du “company managed”, tant et si bien que ces droits d’administration d’espace apportent un bénéfice très limité et on se retrouve vite à devoir en référer aux administrateurs de l’instance Jira.
Voici un exemple de ces limites : on peut donner les droits à un administrateur d’espace de rajouter des champs à l’espace qu’il administre… À la condition que le champ existe déjà au global dans l’instance. Impossible de créer un champ complètement nouveau. 🤷
Pourquoi ce modèle a du sens (et ça me fait mal de l’admettre)
À date, je n’ai pas la recette magique pour permettre aux équipes d’expérimenter librement avec leurs processus dans Jira. Cela me fait mal au cœur et je sais à quel point cela peut rajouter de la friction à l’amélioration continue d’une équipe.
Je pourrais en conclure que Jira est le diable. 2
💡 Au contraire, j’ai découvert de la vertu à ce modèle !
Ce modèle vise à répondre aux enjeux suivants :
Harmonisation et standardisation du delivery
Pilotage collectif à l’échelle, nécessitant d’agréger des données et d’avoir des artefacts collectifs
À l’échelle on veut remonter des informations, certaines pas si évidentes que cela à calculer comme les DORA Metrics. Sans un minimum de standardisation, on se retrouve à devoir calculer ce genre de métriques de manière différente pour chaque équipe, projet ou solution… C’est coûteux, peu fiable, et surtout la mise en place est une charge supplémentaire qu’on impose aux équipes plutôt que leur donner les bénéfices de manière transparente, pour ainsi dire gratuitement. 3
Un compromis entre deux dimensions
On voudrait avoir :
Un cadre qui permet l’autonomie des équipes pour expérimenter avec leurs processus et les adapter à leur contexte et enjeux
Mais aussi un cadre qui permet le pilotage à l’échelle, une visualisation transverse, une standardisation d’un certain nombre de métriques, une capitalisation sur les intégrations avec d’autres outils, etc.
Idéalement, on voudrait avoir les deux.
En pratique, on voit bien la difficulté à les concilier. Et c’est là que se joue tout le parti pris des outils. Focus plutôt sur l’autonomie des équipes ou sur la capitalisation à l’échelle ?
Au-delà du focus, la question est plutôt : lequel favoriser en cas de conflit entre les deux ?
Le parti pris de Jira
Jira a pris le parti d’assurer sur la dimension capitalisation à l’échelle. Et honnêtement, difficile de les blâmer :
Le pilotage à l’échelle est un enjeu qui touche le top management. En pratique, si on se retrouve dans une situation où l’on doit faire pencher la balance d’un côté ou de l’autre, les personnes qui ont le plus d’influence dans l’organisation iront toujours du côté du pilotage à l’échelle plutôt que du côté de l’autonomie des équipes.
Au-delà de qui influencerait la décision, j’ai ce sentiment qu’il y a effectivement plus d’enjeux collectifs dans le pilotage à l’échelle que dans l’autonomie des équipes. Par exemple, un bon pilotage à l’échelle va éviter de construire la mauvaise chose ou d’accumuler des retards et des délais pendant des mois et de continuer sans s’en rendre compte.
Pour tirer les bénéfices, l’outil ne suffit pas. Il faut aussi des personnes compétentes derrière. Plus facile de s’assurer qu’on a quelques personnes clés compétentes pour tirer les bénéfices du pilotage à l’échelle, que de se dire qu’on a des personnes compétentes dans toutes les équipes pour qu’elles tirent les bénéfices de l’autonomie. Je me rends bien compte en écrivant cela comment ce constat à l’échelle doit être frustrant pour les équipes très matures et compétentes à leur niveau.
Plus globalement, l’autonomie des équipes est négociable, il existe de nombreux contournements et modes dégradés, alors que mal piloter à l’échelle n’est pas une option.
Une fois que j’ai dit tout cela, j’ai du mal à ne pas me ranger du côté de la philosophie de Jira.
Je n’ai pas envie de tout centraliser, mais je reconnais que cette approche répond aux bons enjeux.
L’élément clé : qui a été mis aux commandes
On va pouvoir reboucler avec le titre de cet article et la notion de dictature bienveillante.
Si le concept de dictature est généralement considéré comme négatif, notamment en l’opposant à la démocratie, sensée en théorie donner le pouvoir aux citoyens, le concept de dictature bienveillante nuance cette interprétation. 4
Dans une dictature, il y a un chef qui a tous les pouvoirs et qui décide de tout.
En effet, c’est souvent synonyme de tous les excès, et notamment l’oubli de la population, de l’économie, et globalement de tout le pays au profit du dictateur ou de la dictatrice et de sa famille. Les exemples de ce genre sont malheureusement légion.
C’est dans ce type de contexte qu’on oppose la dictature à la démocratie, qui en particulier consiste à mettre en place et soutenir des contre-pouvoirs. Pour autant, la démocratie est loin d’être parfaite, avec trop souvent des intérêts personnels qui viennent s’entre-mêler dans la politique, apportant des dynamiques d’immobilisme face à des changements essentiels à mener, en se focalisant sur le court terme des individus au détriment du long terme du collectif.
Le concept de dictature bienveillante, c’est une dictature où on aurait la bonne personne aux commandes, une personnes qui se focaliserait sur le développement du pays et l’intérêt de son peuple.
En théorie, en suivant cette logique, une telle dictature bienveillante apporterait de meilleurs résultats que la démocratie — plus efficace, avec moins de barrières à la mise en place de la vision bienveillante.
Le modèle canonique de gouvernance de Jira, c’est cette dictature bienveillante.
L’administration Jira entre les mauvaises mains
Le risque principal d’une dictature bienveillante, c’est bien sûr que si on a mis la mauvaise personne au pouvoir, si elle n’est justement pas bienveillante, auquel cas on subit le pire :
Une administration Jira qui se focalise sur ses propres objectifs plutôt que sur les bénéfices pour l’ensemble de l’organisation et des équipes
Une administration Jira qui veut tout uniformiser et ne laisser aucune marge de manœuvre aux équipes dans le but de se simplifier la vie
Une administration Jira qui ne va pas voir sur le terrain la réalité des équipes
Une administration Jira qui verrouille l’outil et suit des choix de conception qui rendent l’équipe d’administration indispensable pour la suite des événements
Il n’y a pas vraiment d’alternative à ces conséquences : les contraintes structurelles de Jira forcent une centralisation, et on est à la merci de la personne ou de l’entité au contrôle.
L’administration Jira en mode dictature bienveillante
Justement, ça donnerait quoi si, cette fois, on est dans une dictature bienveillante, avec la bonne personne au pouvoir ?
Une administration Jira qui propose un standard pour accélérer le lancement de nouvelles initiatives et avec des partis-pris forts pour éviter les débats stériles avec les personnes non expertes qui veulent juste avoir un truc qui marche — tout en acceptant les spécificités des initiatives existantes
Une administration Jira qui donne de l’autonomie aux équipes en s’appuyant au maximum sur du standard de Jira, plutôt qu’en mettant en place des modèles maison
Une administration Jira qui va sur le terrain pour sentir les douleurs des équipes vis-à-vis de l’utilisation de Jira, qui fait preuve d’empathie avec ses utilisateurs, qui met un point d’honneur à les aider et à résoudre leurs problèmes
Une administration Jira qui n’aborde pas les enjeux autour de Jira comme l’administration d’un outil mais avant comme des enjeux méthodologiques, Jira venant en soutien pour refléter et outiller la méthodologie mise en place
Evidemment, on trouve l’élément clé d’être user-centric, tourné vers ses utilisateurs et à leur service.
C’est une posture difficile car on demande d’être expert tout en gardant l’utilisateur en tête !
Qu’est-ce que cela implique côté choix du dictateur bienveillant ?
Réussir à suivre ce chemin de crête, cela n’est pas donné à tout le monde.
Pris dans l’autre sens, cela veut dire qu’il nous faut un de ces fameux moutons à cinq pattes pour structurer cette équipe d’administration, qui cumulerait de nombreux traits. Je pense par exemple à :
Maîtrise de Jira — a minima ses concepts, et bien entouré par des experts pertinents
Capacité à accepter les feedbacks et les remises en question : Jira permet tellement de choses qu’il faut pouvoir accepter les suggestions des experts
Maîtrise de la gestion de projet, et des différentes approches, waterfall comme agile : comme dit plus haut, l’enjeu n’est pas directement au niveau de l’outil, mais au niveau de la méthodologie et de comment l’outil l’accompagne et la facilite
Maîtrise de la gestion de portefeuille : même histoire, cette fois pour la dimension pilotage à l’échelle
Véritable maîtrise de Scrum et de Kanban : pour aller au-delà de “un sprint c’est un ensemble de trucs à faire” et “Kanban c’est un tableau de suivi”
Expérience du management visuel en contextes variés : pour réussir à se projeter sur comment en mettre en place dans le cadre très contraint de Jira
Orientation métriques : un bénéfice essentiel d’un outil comme Jira est d’apporter des métriques à ses utilisateurs, il faut donc connaître les métriques principales, comprendre leur intérêt, comment les utiliser, et savoir former à leur utilisation
Connaître la réalité des équipes, certainement en ayant travaillé soi-même dans ce genre d’équipe
Avoir une bonne compréhension de ce qui fait la performance d’une équipe, de sorte à pouvoir avoir des discussions d’outillage qui tournent plus autour de la structuration organisationnelle qu’on veut accompagner que de Jira lui-même ; la structure dans Jira reflétant simplement et directement la cible organisationnelle
Comprendre les dynamiques humaines autour des processus : comment les personnes reçoivent le changement, le jugent, se l’approprient — la conduite du changement !
Être user-centric, savoir se projeter sur l’utilisation d’une application ou d’un système mais également oser aller voir les utilisateurs et accepter leurs retours
. . .
Bien sûr, comme dans une offre d’emploi, il n’est pas nécessaire de tout maîtriser et à 100%. Néanmoins, on va quand même vouloir un panel significatif, ainsi que la capacité à acquérir ceux qui manquent.
C’est peut-être là où le bat blesse, et la raison pour laquelle on voit si souvent des implémentation de Jira qui traumatisent leurs utilisateurs :
Qui peut se targuer avoir toutes ces qualités pour pouvoir être ce dictateur bienveillant que nécessite Jira ?
Sans dire que c’est impossible, cela va sans aucun doute être rare, trop rare. 🫣
Connectons-nous !
En ce qui me concerne, je n’ai pas la prétention d’avoir toutes ces qualités, mais j’essaie.
Si tu es ou a été dans une position en capacité de mener une initiative Jira de grande envergure, j’aimerais échanger avec toi.
Pour savoir comment tu t’y es pris, ce que tu as mis en place et quels résultats tu as eu !
Connaître tes convictions, comment elles se sont concrétisées et ce que tu en as appris.
Oui, j’en ai gros après le modèle “team managed” de Jira, une super idée sur le papier mais sans intérêt en pratique de par les contraintes imposées, que j’expose justement dans la suite de l’article.
Cette formulation est bien entendu un clin d’œil à mon précédent article “Jira ne serait pas démoniaque ?” où je philosophais sur le rôles des outils par rapport aux individus et leurs interactions :
Jira ne serait pas démoniaque ? 😱
Les individus et leurs interactions plus que les processus et les outils
J’en parlais dans ce précédent article sur la difficulté de mesurer les DORA Metrics en pratique, et pourquoi elles sont donc souvent bidouillées plus que réellement mesurées :
On peut aussi considérer la dictature bienveillante comme un retour au sens d’origine : le Dictator de la république romaine était nommé avec tous pouvoirs certes, mais pour une durée limitée et afin de résoudre une crise bien spécifique.
C’était imaginé comme un outil au service de la république romaine plus qu’un fonctionnement différent qui lui aurait été opposé.
Bien sûr, on sait tous que cet outil a fini par être détourné de sa fonction initiale (et donc de cet aspect “bienveillant” de la dictature) notamment avec Jules César nommé dictateur à vie…
