Premier post d’une série sur la question : « la transformation agile de l’entreprise est-elle elle-même agile ? »

Dans le manifeste agile: « Les individus et leurs interactions plutôt que les processus et outils ». Pourtant, sur une transformation d’un grand compte :

plutôt que les outils
Nous déployons Jira + Greenhopper, comme unique alternative autorisée à l’utilisation d’Excel, avec 2 variantes : Seulement les user stories dans Greenhopper (qui contient donc le Product Backlog), ou bien les user stories ET les tâches (notamment pour les projets distribués). Donc tous les projets vont avoir le même outil, imposé. Est-ce que la perte de cette latitude de choisir l’outil est un drame ? Il y a des avantages : mutualiser le support sur l’outil, d’éventuels plugins développés une fois pour toute. On change de dimension. Ce n’est plus le projet, mais la DSI qui adopte un outil. Il est indéfendable d’expliquer au management de la DSI que l’on va prendre des outils différents pour différents projets, que chaque projet va concevoir un choix d’outil.

Encore faut-il que cette mutalisation se nourrisse vraiment des remontées et besoin du terrain. Que périodiquement les représentants (le Scrum Master) de chaque projet rencontre le coach responsable de cet outil, une sorte de « scrum de scrum », bref des interactions. On a bien un projet jira avec les demandes d’évolutions de l’outil mais ça ne remplace pas les échanges.

plutôt que les processus

L’entreprise bénéficie d’un réseau d’ingénieurs qualité, qui effectuent des revues de qualité des projets à certains moments de leur déroulement. Ils vont le faire notamment pour les projets agiles. Dans le cadre de la transformation, un travail a été fait avec eux sur les questions à se poser, et nous a amené à formaliser un référentiel agile. Il ne s’agit pas vraiment d’un processus figé, mais d’une description du framework Scrum, des pratiques d’ingéniérie tirées d’Extreme Programming et des spécificités de l’entreprise. L’approche est très proche de Scrum en tant que framework. C’est ce qui nous sauve : il y a largement place à interprétation.

Pourquoi ne pas utiliser directement le Scrum Guide ? ou le bouquin de Claude Aubry ? Cela vient des objectifs de ce référentiel. Les ingénieurs qualité sont supposés être compétents pour évaluer la bonne adéquation d’un projet à l’agilité. Ils sont supposés être formés, et avoir le même regard qu’un coach qui auditerait le projet. Le but est pour eux d’avoir une référence. Le référentiel est là à but normatif, pour poser des règles à respecter, pas pour enseigner expliquer comment faire. Nous nous sommes efforcés d’avoir un ensemble de règles cohérent & souple, avec juste ce qu’il faut de contrainte pour indiquer la direction aux projets.

L’ingénieur qualité collecte des preuves (fut-ce lors d’entretien) du respect des règles. Le référentiel ne dit pas comment s’y prendre. La réelle difficulté, et c’est comme pour CMMI, réside dans le fait qu’un ingénieur qualité fonctionne sur la base soit de preuve, soit d’entretiens très brefs, et que ni l’un ni l’autre ne se substituent au retour que peut faire un coach par exemple. Du coup nous (coach) participons aux revues. Que se passera-t-il quand la transformation sera finie ? quand l’entreprise décidera de réduire le coaching qui sert actuellement à déployer l’agilité ? Est-ce que les revues ne se baseront plus sur les traces d’exécution d’un processus (les livrables) et moins sur une évaluation fine du fonctionnement de l’équipe ? Et où iront les responsables qualité chercher leur connaissance de l’agilité ?

Quand je regarde ce que j’ai pu apporter aux projets que j’ai coachés, c’est 20% de forme, de respect des règles du processus Scrum, et 80% de fond, d’état d’esprit. Difficile de résumer l’état d’esprit agile dans une checklist destinée à être appliquée par des personnes qui n’ont jamais participé à un projet agile ni été Scrum Master. C’est peut-être au fond une limitation de l’agilité, plus difficile à généraliser dans une entreprise qu’un processus lourd comme UP.