L'Agilitateur Création de logiciels : de l'agilité à l'artisanat

De temps à autre, j'aime bien me balader en ligne dans les endroits où les gens parlent de méthodes agiles. Ca permet de garder un certain contact avec les préoccupations actuelles de ces personnes.
Ce soir, sur le groupe linkedin consacré au French Scrum User Group, je suis tombé sur une discussion qui m'a donné l'impression de débarquer sur une autre planète. Si c'est ça les méthodes agiles aujourd'hui, il serait grand temps pour moi d'aller voir ce qui se passe ailleurs. Un ailleurs où on serait plus attaché à faire de bons logiciels qu'aux organisations d'entreprises où on fait entrer de "l'agilité" au marteau piqueur (voire au bulldozer ?)

Ou devrais-je me consoler en me disant que ces gens là ne parlent pas vraiment de méthodes agiles car, en fin de compte, ils ne parlent que de Scrum ?

Pour ceux qui n'auraient pas l'immense privilège d'être inscrits sur linkedin et d'avoir accès à ce groupe, voici la discussion en question:

Intervenant A
Dans les grosses organisations, des Responsables qualité et PMO interviennent en soutien des Chefs de projet. Dans un monde agile, que deviennent-ils ?

Intervenant B
Agile (Scrum) nécessite aussi une structure (légère) de support qualité (définition du "done", mise en place des outils de test, structure d'automatic-testing, regression test, ...). De même l'autorisation de lancement d'un produit (projet) et de l'affectation du budget et ressources est de la compétence du PMO. De plus le PMO peut avoir à gérer un "mix" de produits agiles et de projets plus traditionnels (ERP par ex.). Par contre une adaptation de ces structures est nécessaire. Le Scrum Master est le point de contact des ces structures pour amener à l'équipe les solutions, ou pour transmettre les besoins de l'équipe (impediment).
Nous sommes en train de réfléchir à quels indicateurs les équipes Scrum doivent fournir pour alimenter le PMO et lui permettre de gérer le "mix" projets/produits.
Quels sont vos expèriences en la matière?

Intervenant C
Cela dépend de ce qu'on appelle PMO. Dans certaines entreprises, le PMO intervient de façon opérationnelle dans la conduite de projet; dans d'autres, il collecte des indicateurs; ailleurs, il est le gestionnaire d'un pool de ressources (= personnes) qu'il affecte au fil de l'eau sur les projets...
Mais, si on considère le PMO comme un un support opérationnel pour l'organisation du projet, pour moi, son rôle évolue naturellement vers un rôle de Scrum Master.

Intervenant D
Excellent question.
Dans les grosses entreprises agiles, il y a des .... Agile PMO ou des Scrum Centers internes (ex. SAP, Allianz, Belgacom...).
Les Agile PMO interviennent dans la mise en place du mode projet agile:
- Meta Scrum
- Scrum of Scrum
- Portefeuille Agile: AgileEVM / Lean
- utilisation d'une gestion agile des programmes: KanBan, Scrum, FDD, ADD, AMD
Les PMO ont une existance plus conséquente dans un environement agile en support à la transition et coordination méthodo.
Les Q/A peuvent être soit intégrés dans les programmes ou interviennent en qualité de TechLead ou Consultants internes (donc membre de la BU PMO).
Cette approche est volontairement synthétique car ne tenant pas compte du Change de chaque organisation.
La "légèreté" agile (cf. intervenant B) est moyennement applicable au stade "meta" où l'intertie est plus importante. La "pirouette" est opérée par la mise en place d'une organisation en mode projet comme Portfolio/Program/Project. Dans ce cas, l'organisation doit être repensée en tant que système "organique".

Intervenant E
Une des caractéristiques marquantes de l'Agilité est l'exigence de qualité. La qualité en Agile est un fondement non pas un luxe. Sans qualité, l'absorption et le contrôle du changement n'est pas possible.
Afin de simplifier le dispositif, on peut dire que le SCRUM Master est un garant de qualité, car il doit veiller et accompagner l'équipe de développement à l'application des bonnes pratiques.
Dans certaines structures, la mise en place de ces bonnes pratiques est faite avec l'aide d'un "XP coach", (accompagnement sur le TDD, parmi autres).
Par contre, Agile étant, par définition une approche adaptative, appliquer des standards me semble un anti-pattern.

Intervenant F
Il faut préciser le terme de qualité à mon avis.
Dans d'autres métier, la qualité du produit est à la base des compétences des responsables qualité, quand j'étais dans la mécanique, les responsables qualité venaient avec moi sur le terrain, il savaient lire les radios des soudures, vérifier l'étanchéité des calorifuges..etc
Dans le SI ce que j'ai vu est un peu différent. En mode projet traditionnel on parle surtout d'Assurance Qualité (dont la base est le PAQ - Plan d'Assurance Qualité).
Il s'agit d'assurer la qualité du produit de façon indirecte à travers une qualité du process. Au passage la recette utilisateur souvent mise en avant comme étape qualité n'en fait partie de mon point de vue. C'est une vérification dont la logique est l'acceptation du produit pas la remontée de défauts.
En Scrum le PAQ (donc l'assurance process) c'est ...Scrum.
Ce dont les équipes Agiles on besoin c'est de mettre en place le Contrôle Qualité sur le produit. Cela tire de la bonne pratique (dont le détail ne fait pas partie du cadre Scrum) tel que Intégration continue, tests automatisés etc. Pour autant cela reste une prérogative de l'équipe de déterminer et mettre en place ce qui convient.
Pour se conformer au fonctionnement Agile des équipes, la cellule qualité doit passer en mode "tiré" à l'inverse de son fonctionnement précedent (ou elle "poussait" ses recommandations) . Elle doit devenir un centre de compétence qualité dans lequel les équipes iront puiser pour améliorer leur performance.
Ouvrir un espace de discussion, mettre à disposition une cellule de veille et un haut niveau d'expertise, du support sur les pratiques et outils, favoriser des communautés de pratique, les animer....
Moi je verrais bien ça comme ça

Intervenant D (bis)
@ Intervenant F
Value Stream Mapping + Release Flow
La complexité de la mise en place d'une telle organisation reside principalement dans son apparence "organique".
En effet, contrairement aux orga traditionnelles avec ses silos, l'orga agile est transverse et les équipes gèrent de manière autonomes la qualité. Cependant, là je rejoins JF, cette qualité dispose de son propre "projet" avec Vision, DOD, LOD; de sorte que l'on puisse mesurer à grande échelle les différentes interactions pour mieux les intégrer ou les commuter.
Cependant, une structure agile se doit de supprimer les "étranglements" en réduisant l'impact du Back Office et en misant sur le Front Office (eg Beyond Budgeting Matrix). Si tout ce joue sur le Front, dans ce cas, la qualité est géré au niveau le plus bas et la gouvernance ne gère plus que 3 paramètres:
- Time to Market
- Valeur aquise (EV) --> Value Stream
- Process (Lean ou Scrum ou X) --> Release Flow, Risk and Issue Management
Dans certaines entreprises dont je ne citerai pas le nom, des Q/A Managers ont été intégrés dans la PMO lors de la mise en place de processus CMMI. L'effet a été désastreux car les Q/A créaint des contraintes supplémentaires sur les équipes de dev. amenant des blocages important dans la créativité.
@ Intervenant E
Le coaching est un outil puissant et nécessaire. Cependant, j'emets un doute sérieux sur la capacité d'XP à répondre aux attentes organisationnelles des grandes structures. XP est un outil puissant d'ingénierie qui traite avec perfection le bas niveau. Mais, dans une démarche qualité orientée "ALL AT FRONT" cela fait tout à fait sens.

Intervenant A
Réponses intéressantes mais ma question était un peu flou je pense. Les rôles que je souhaitais adresser sont ceux de Chef de projet (il n'y en a pas dans Scrum), de PMO dans le sens support à l'organisation et au suivi de projet, et Responsable qualité affecté à un projet pour vérifier l'application des dispositions du même nom.
Pour tenter de répondre à la question de intervenant B concernant les indicateurs agiles, nous utilisons principalement la prédictibilité, la vélocité, la productivité de l'équipe et les indicateurs qualité que sont le taux de couverture de ligne ce code, le taux d'anomalie, le taux de couverture du product backlog.
Je retiens surtout les idées intéressantes suivantes :
1) "appliquer des standards me semble un anti-pattern" de Intervenant E
2) "l'orga agile est transverse et les équipes gèrent de manière autonomes la qualité" de Intervenant D
3) "si on considère le PMO comme un un support opérationnel pour l'organisation du projet, pour moi, son rôle évolue naturellement vers un rôle de Scrum Master" de Intervenant C
4) "centre de compétence qualité dans lequel les équipes iront puiser pour améliorer leur performance" de Intervenant F
5) "le Scrum Master est le point de contact des ces structures pour amener à l'équipe les solutions, ou pour transmettre les besoins de l'équipe (impediment). " de Intervenant B
Le problème majeur selon moi est que les grosses organisations conservent en général leur structure en place et leur standards car trop d'investissement et trop de contraintes et d'exigences seraient à revoir dans le cas contraire (référentiel qualité à revoir, certification DO178B par exemple difficile voire impossible du fait des auditeurs incompétents en agile, problème de la responsabilisation de l'équipe devant la Direction de projet, plutôt qu'un Chef de projet ...)
Résultats constatés : les Chefs de projet restent en place et jouent le rôle de Scrum master, les responsables qualité restent en place, mais sont moins efficaces qu'auparavent, l'équipe mettant en oeuvre ses propres améliorations, et les PMO perdurent pour assister les Chefs de projet sur les aspects planning, outil ...
Dans l'idéal pourtant, je préfère dissocier le rôle de Coach agile de celui de Chef de projet. Le premier est un vrai leader technique côté fournisseur tandis que le second est rigoureux dans ses reportings et dans le suivi de l'avancement du projet et surtout des changements dans un contexte forfait DUR (il peut également être côté client). Enfin, le responsable qualité devient responsable qualité, méthode et outil, et fait partie d'un centre de compétence transverse à qui les Scrum Masters s'adressent pour aider à la mises en oeuvre des amélioration décidées par l'équipe lors des rétrospectives et pour faire remonter les bonnes pratiques projet. Que pensez-vous de ce modèle ?
Ma question initiale concernant donc bien le devenir des rôles d'avant SCRUM dans une nouvelle démarche agile.
Concernant les référentiels si cher au CMMI, à l'ISO9001 ou à tout autre standard ou norme applicable, c'est un sujet à part entière. Les anciens plans projet devraient à mon avis fixer les objectifs des dispositions et nons plus les décrire. Les records et artefacts pourraient à la fois décrire les dispositions et fournir les preuves attendues par respect à ces référentiels. Il est en effet assez rare de changer de preuve sans changer de processus ou d'outil.

Intervenant D (ter)
Cela est applicable dans un modèle de base traditionnel au titre d'une transition.
L'impact organisationnel d'une démarche agile affecte l'ensemble de la structure de l'organisation. Contrairement au modèle que nous connaissons encore, l'agilité tend à supprimer les intervalles entre les participants et, plus pragmatiquement, les intérêts économiques.
Statoil en Norvège utilise Scrum dans sa partie IT et Beyond Budgeting pour sa gouvernance: ici les métriques de gouvernance sont consolidés avec BSC. Cette solution n'est pas la panacée, mais elle a l'avantage de promouvoir la fléxibilité et la réaction au changement de l'organisme.
"Pour les rôles d'avant Scrum dans une nouvelle démarche agile", ceux ci n'ont plus de raisons d'être et il faut les faire évoluer, les intégrer, les digérer et recréer de nouveaux rôles.
Une des étapes de maturité dans une démarche agile est celle de dépasser le stade de projet adressée par Scrum et d'organiser l'organisation en mode projet.
Pour rebondir sur un point: il n'y a plus de chef de projet dans Scrum, je souhaite corriger en indiquant qu'il y a des gestionnaires de projet (Project Manager) dans Scrum. Pour le terme "chef", je dirai que le "commitment" génère l'engagement, donc la responsabilisation.
Cette responsabilisation étant improductive pour l'équipe (cela crée des freins dans le processus créatif), celle-ci repose principalement sur le SM et le SPO.
En conclusion, en terme d'organisation et d'alignement, les standards sont nécessaires pour faciliter la communication et créer rapidement une culture "entreprise" dans un système dynamique.

Intervenant G
Historiquement, il me semble que le "Project Office" élabore, vérifie l'application et fait évoluer les standard méthodologiques d'une organisation (cf PMBOK). Dans la pratique majoritaire actuelle, parlons vrai, les PMO sont parfois des "assistants" de chefs de projet en surcharge ou des collecteurs d'indicateurs pour les directions.
Concernant la seconde définition, on est dans de la gestion de délégation. Cela pose juste la question de la "scalabilité" des projets basés sur méthodes agile. Pour résumer, un très gros projet peut-il être géré de manière agile ? (Personnellement, ma réponse est mille fois "oui", et cela aurait sans doute évité de grosses souffrances lors des projet Internet bancaire, an2000 et autres)
Si on se concentre sur la première définition, il s'agit purement et simplement d'une escouade chargée de la surveillance des projets et de l'amélioration des pratiques. Pour moi cela correspond parfaitement au 12ème principe du manifeste Agile (http://agilemanifesto.org/iso/fr/principles.html) : "À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence."
En synthèse, ma réponse est que ce rôle a été prévu dès l'origine, mais que d'autres principes agiles ont davantage retenu l'attention que celui-ci.