Transformation agile agile : process & tools

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.

Publicités

A propos pierrefauvel

Project Leader and/or Agile Coach. Pragmatic. Hard core Zen inspired.
Cet article a été publié dans Agile, Entreprise. Ajoutez ce permalien à vos favoris.

Un commentaire pour Transformation agile agile : process & tools

  1. Pierre Neis dit :

    Salut Pierre,

    Excellente lettre. Je comprends tout à fait cette réflexion.

    1. Mise en place de Scrum:
    Il s’agit autant un objectif que d’une mesure de la capacité à l’organisation a être agile. Scrum a besoin de place et de latitude dont la transparence et une équipe dédiée. Ceci est déjà un plan de Changement à lui tout seul et les métriques de transition que j’utilise souvent sont:
    a. mise en place d’un mode projet: permettant de dédier des équipes, de constituer un portefeuille de projet
    b. mise en place de l’agilité a minima: transparence et inspect&adapt
    c. démarrage de Scrum
    d. mesure des resultats

    2. Agilité et gestion de process
    Là on touche un point sensible de l’origanisation. En effet, en terme de gouvernance, la maturité d’une organisation se mesure par la qualité de ses process. D’un point de vue développeur, parler de process est une contre culture. Cependant, ceux-ci sont cruciaux dans les projets d’envergure. Par ex., je travaille avec la BPMO pour intégrer les process initiés par BPMN. Ces process ont été créés à partir d’une collecte des besoins et par un value stream mapping. Ces données sont remises au PO et soumise à l’épreuve du Sprint: càd, le process sera les entêtes des colonnes du Kanban et la Development Team devra la tester tout au long du Sprint. En sortie de Sprint, lors de la Rétrospective, la Dev. Team donne le résultat inspecté et adapté qui sera validé par la BPMO.

    En conclusion, la mise en place de l’agilité est un changement de paradigme, une façon plus éfficace pour atteindre l’objectif que l’on s’est fixé.
    La réduction des risques par la standardisation peut engendrer une baisse de la créativité. De ce fait, un coach sera toujours primordial pour gérer l’équilibre. Le coach est le manager de demain.

    Bravo encore!

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s