Ouh les gros mots "outils" et "processus", surtout depuis que l'agilité est devenue populaire dans notre industrie. Parler de cela n'est pas simple. C'est un sujet sensible, voire polémique, et à mon sens, surtout en raison de certaines pratiques managériales "déviantes" associées (amalgamées?) aux outils et aux processus.
Je propose dans cet article de mettre au clair mon ressenti sur tout cela. Merci de ne pas prendre tout cela de manière péremptoire ou catégorique de ma part. Le style est volontairement un peu provocateur pour susciter une réaction (positive). On verra pourquoi je parle de "schizophrénie".
Les processus et les outils
Revenons sur quelques vieux (ou pas) démons liés aux outils et aux processus. Le manifeste agile donne plus de valeur aux interactions des individus qu'aux outils et aux processus, mais je rappelle que pour autant le manifeste ne réfute pas l'utilité de ces derniers. On peut se demander pourquoi les auteurs du manifeste ont tenu à mettre l'accent sur ce point...très probablement qu'ils ont croisés bon nombre de projets ayant trop insisté sur les outils et les processus? C'est mon interprétation, liée à mon expérience en tout cas.
En effet, durant mes premières années d'expérience (de 2004 à 2008/2009), avant même d'avoir connaissance du manifeste agile, j'ai vécu (et on m'a reporté) des expériences où les outils et les processus étaient "la clé". A partir de ces expériences, je rejoins complètement les auteurs du manifeste agile: une trop forte orientation autour des outils et des processus ne garantit en rien la réussite des projets. L'image d'Epinal selon laquelle un projet IT serait équivalent à une production à la chaîne de voitures est manifestement fausse. Et pourtant cette croyance persiste.
Les processus et les outils laissent croire qu'une industrialisation de l'IT est possible. A mon avis, l'industrialisation de l'IT n'a de sens que dans l'automatisation d'un certain nombre de tâches répétitives "basiques" (build, certains tests, déploiement...). La réalité que je constate encore aujourd'hui est pourtant bien différente : les outils et les processus sont utilisés de manière dévoyée, principalement imposés pour plus de contrôle des managers. Cette déviance est bien ancrée aujourd'hui dans les moeurs.
Et pourtant, je pense qu'on pourrait utiliser les outils et les processus de manière constructive, au service de chacun dans l'équipe. Mais avant d'aborder cela, je voudrais revenir sur l'impact de l'agilité.
"L'avènement" de l'agilité avec Scrum
Armé du manifeste agile, certains se sont rapidement mis au sport national de vilipender les outils et les processus classiques. Et pourtant, l'agilité s'est répandu principalement avec Scrum, en mode "by the book", c'est-à-dire en appliquant religieusement les processus décrits dans un livre Scrum. C'est un peu un comble et en même temps, à mon sens, une raison de l'adoption rapide de Scrum. En effet, Scrum rentrait bien dans le cadre antérieur du "tout processus" (et outils). A contrario, XP parlait probablement trop de pratiques techniques. A noter que Scrum ou XP sont loin de supprimer tout processus, contrairement à ce qu'on entend de quelques agilo-sceptiques qui tentent de faire passer l'agilité pour une démarche "à l'arrache".
Au niveau des outils, l'agilité a plébiscité le management visuel, notamment en mettant l'emphase sur la visibilité et la kinestésie (le fait de manipuler physiquement des post-its par exemple). Les avantages sont que cela permet de se resaisir de la notion d'outil et d'offir un support pour suivre le processus défini. Le travers à mon sens est d'avoir passé aux oubliettes les outils électroniques car moins "visibles" et sans kinestésie.
Une autre mode s'est répandue : jeter des cartes sur un tableau Trello, cela peut vite devenir proche de l'arrache. C'est néanmoins atténué quand les personnes l'utilisant ont atteint une maturité leur permettant d'y voir plus clair. Mais je remarque tout de même que le travers est de faire un peu trop d'incantations sur sa capacité d'amélioration, sur son avancement...très largement dominé par le ressenti plus que le factuel, ce qui n'est pas très transparent à mon sens.
Avec Kanban, la schizophrénie pointe son nez
Depuis quelques années, le Kanban prend de l'ampleur. Cette démarche met fortement l'accent sur la mesure de son activité pour faire évoluer son processus. En effet, les cartes de contrôle et les diagrammes de flux cumulés (CFD = Cumulative Flow Diagram) permettent de suivre son activité et de mesurer l'amélioration ou la dégradation de la situation (cf. articles de Pablo Pernot).
Cependant, mesurer reste associé au contrôle, à l'usage dévié des mesures que certains managers pourraient faire. Alors comment mesurer tout en évitant les déviances connues par le passé? Comment se sortir du piège "moins d'outils" versus "plus de mesures"? Et ce sont ces questionnements qu'on peut qualifier de comportements schizophrènes.
Pour contrer simplement cela, il faut accepter notre schizophrénie, ce qui peut être compliqué vu qu'un schizophrène n'a pas conscience de sa maladie. Acceptons donc tous cette part de schizophrénie, pour dépasser les clivages idéologiques et être plus en phase avec le manifeste agile.
Les outils et les processus à bon escient
Ma vision des processus est qu'ils doivent permettre de ne pas faire les choses à l'arrache et de se poser les bonnes questions pour faire le bon produit et le faire bien.
Dans ce cadre, les outils doivent nous faciliter l'adoption et le suivi des processus de l'équipe (par l'équipe et non par les managers), ainsi que permettre l'automatisation d'un certain nombre de tâches répétives des processus définis.
L'utilisation des outils permet alors à l'équipe de mieux se mesurer sur ses processus et le produit réalisé, ainsi que de clarifier ce qu'est le bon produit. Ce dernier point est la pierre angulaire pour se concentrer sur la création de valeur, plutôt que de faire de l'IT pour l'IT.
Management visuel ou outils électroniques ?
A mon sens, ni l'outil du management visuel ni les outils électroniques ne sont la solution parfaite (comme souvent?!) : le premier souffre d'un manque de capacité d'automatisation, les seconds manquent de kinestésie.
Ces outils restent par contre une source de défiance par crainte de détournements des données contenues (comparaison de vélocité, calcul de "vélocité individuelle"...). Ils doivent ABSOLUMENT rester en premier lieu utile à l'équipe et ne pas être détournés pour le management.
Pour faciliter l'acceptation de cette contrainte par le management et le client, le maître mot est la transparence. Ne manipulez pas les données exposées au management et au client. Ils doivent s'approprier les données exposées pour partager une vision commune et non demander des adaptations de l'outil pour des reportings spécifiques. Une autre solution est que tout reporting spécifique soit fait en dehors des outils de l'équipe, même si cela peut créer des effets de bord qui font perdre le partage d'une vision commune.
A noter que si le management ou le client ne sont pas prêts à accepter ces préconisations, alors il y a peu de chances qu'une démarche constructive voit le jour, l'opposition management/équipes/client sera la norme, chacun dans son silo avec des projets probablement pas très réussis.
Voilà, je tenais à écrire cette clarification, pour mettre dans la balance les extrémismes du tout contrôle et du tout "agile".