Agile / Scrum : l'importance de l'Audit, de la Charte et du Bilan

Toute organisation - si elle souhaite mettre en œuvre l’Agilité - se doit de réaliser un audit de sa réelle capacité d’en accepter les contraintes. Ensuite viendra le temps des changements organisationnels et de la formation des ressources humaines aux techniques Agiles.

Le plus important dans ces étapes préliminaires au succès d'un engagement Agile sera comme toujours l’élimination des multiples craintes des acteurs confrontés à un changement radical de leur cadre de travail. Les consultants en « scrumisation » ne font jamais état de ces détails. Mais bon, il faut les comprendre, il est plus aisé de vendre du rêve que du cauchemar.

Les problèmes organisationnels

L’organisation faisant le choix de la méthode Scrum et qui éprouve ensuite des difficultés à la mettre en œuvre  – pour des raisons toujours purement organisationnelles le plus souvent liées à la peur du changement et / ou à la perte de responsabilité (lorsque ce n’est pas d’emploi) des acteurs concernés –  se trouve généralement devant quatre voies possibles :

Voie 1 – Mettre réellement en œuvre Scrum en formant les équipes à la notion « d’autonomie » et en leur garantissant l’environnement adéquat, en co-localisant les PO et en les formant à la spécification directe des besoins détaillés et des tests fonctionnels, en éduquant les acteurs du projet à leurs nouveaux rôles et responsabilités. Choisir cette voie implique la redéfinition des emplois et le redéploiement des ressources actuelles. À ce stade, se contenter de modifier le titre d’une activité ou d’un rôle ne suffit pas. Un vrai changement nécessite de promouvoir sur le sujet une communication intensive et rassurante sur son intérêt. Il faut engager un mode « gagnant-gagnant » entre métier et IT.

Voie 2 – Reconnaître que Scrum et ses techniques extrêmes et révolutionnaires ne peuvent pas être mis en œuvre dans leurs aspects organisationnels les plus durs (disparition de la notion de « projet » et donc du rôle de Chef de Projet et apparition de la notion de « produit » et du rôle de PMO. Il faudra aussi intégrer de nombreux autres changements d’habitudes et d’outils. Dans ces cas, il sera nécessaire de définir rapidement, formellement et officiellement, une autre approche acceptable (généralement un mixte de Scrum, d’autres méthodes et de pratiques existantes). Comme pour la première voie, il faudra ensuite accompagner le changement d’une intense communication sur les raisons de ces choix et de leurs avantages pour toutes les parties.

Voie 3 – Former ceux que cela intéresse et proposer régulièrement des formations aux autres, sans intervenir directement et autoritairement. En résumé : laisser les choses évoluer d’elles-mêmes. Cela représente une voie moins violente, donc au final mieux acceptée. Dans cette voie, les acteurs se rassurent en maintenant leurs principales habitudes et en acceptant occasionnellement d’en adopter de différentes (généralement par le biais de l’exemple d’une autre équipe). De toute façon, cela ne dispensera pas l’organisation d’accompagner cette transition lente par une explication appropriée portant sur les intérêts conjoints de l’ensemble des parties. Sans cet exercice de communication, l’évolution Agile, pourtant indispensable, n’est généralement ni souhaitée ni acceptée sans réticence, freinage et ralentissement de tout type.

Voie 4 – Abandonner tout simplement la tentative de révolution Agile et alléger simplement sa conduite de projet classique.

Le choix d’une de ces possibilités est uniquement une affaire de culture d’entreprise, de nécessité reconnue ou de style et de volonté exprimée des dirigeants. Étudions maintenant trois aspects techniques, pourtant concrètement indispensables, mais très souvent oubliés : l’audit, la charte et le bilan.

Audit, Charte et Bilan

1 - La notion d’audit de situation

Dans le cas où l’organisation décide de poursuivre dans la voie agile, sa première obligation est raisonnablement d’accepter un audit, général ou non, mais devant au minimum – sur les points majeurs indispensable au mode agile – précéder le lancement de ce « mode projet ». C’est à partir des freins et des obstacles ainsi mis en évidence, que la partie « méthode » de la charte d’engagement de chaque projet devra être rédigée.

2 - La notion de charte projet

Au-delà de l’engagement Agile de principe, suite à l’audit, une charte spécifique d’adaptation de l’environnement du projet aux obligations Agiles  devra être acceptée et signée par l’ensemble des acteurs. Sans ces prérequis, aucun projet ne peut se réaliser  aisément en mode réellement Agile et le risque de rejet ou d’échec ira croissant avec l’incertitude qui s’installera lorsque l’équipe sera confrontée lors du développement aux divergences organisationnelles ou techniques non résolues.

La charte projet doit expliciter un certain nombre de normes et de standards. Plus l’organisation sera importante ou complexe et ses projets nombreux, et plus le cadre d’autonomie concrète des équipes devra être formellement précisé. Comme exemple on s’attachera à obtenir des équipes un reporting standardisé concernant aussi bien la performance du projet que la qualité de l’application. La charte basique considérera alors – par exemple - comme « indispensables » les documents suivants :   Le BurnUp Chart accompagné de la liste des freins et obstacles, le graphique d’évolution des anomalies fonctionnelles et techniques issues des sprints précédents avec la courbe de leur résolution.

Afin d’être immédiatement compréhensibles par tous les intervenants, ces documents seront idéalement standardisés à l’échelle de l’organisation (ce point à fait l’objet d’un article JDN précédent).

3 - La notion de bilan et de maturité

Le projet est en cours ou terminé, il est temps de réaliser un bilan des convergences agiles réalisées depuis l’audit initial. Les mises en conformité « cruciales » auront généralement été mises en œuvre préalablement au projet (convergences immédiates), d’autres ont fait l’objet d’un traitement progressif (en amélioration continue), initié et contrôlé lors des rétrospectives de début et de fin de Sprint. 



Avec ces trois étapes, le processus de mise en conformité Agile est alors bouclé. 

Ces problématiques d’avant-projet semblent anodines, mais elles posent dans la réalité des organisations et de leurs développements pas mal de problèmes se révélant parfois catastrophiques. Il y avait bien « avant » des méthodes détaillant ces points et proposant des solutions éprouvées lors de trois phases nommées : Initialisation de l’organisation, Cadrage du projet et Design de son architecture, « mais ça, c’était avant ». Heureusement le progrès « fait rage », et Scrum nous dispense maintenant de ces détails insignifiants que l’on pousse discrètement du pied pour les cacher sous le tapis du Sprint 0.

Estimation de charge, Sprint et reporting

Au sujet de l’estimation de la charge de développement qui précède immanquablement la décision de faire le projet, je vais devoir revenir, une fois de plus, sur l’escroquerie intellectuelle, morale autant que méthodologique des Points de complexité. Il n’est plus question pour moi d’aborder ce sujet avec des personnes bornées par leur deux journées de formation à Scrum et n’ayant très certainement jamais participé à un vrai projet en mode Agile. En effet, cela revient toujours à discuter de politique ou de religion avec des convaincus d’avance. Donc, je n’utilise plus la persuasion logique, à laquelle ils me répondent toujours par du baratin illogique, mais je pose deux questions très simples. Lorsqu’une personne refuse d’y répondre concrètement, je cesse la discussion :

Si le planning poker est réalisé en point de complexité (lequel peut valoir une journée comme deux, trois, quatre, sept et demi, etc.) ou encore plus drôle en taille de t-shirt posons-nous alors les questions suivantes : 

  1. Quel est le budget du projet (qui déterminera le « go » ou le « nogo » avant son lancement)?
  2. L’argent n’est pas votre problème ? Bien, alors quel est le délai de livraison ? Cela ne vous intéresse toujours pas ? Parfait, alors :
  3. Combien de  développeurs dans l’équipe, de quelle durée les Sprint et  combien de sprint? 

J’attends évidement en réponse un principe formel et pas la vision d’un petit doigt levé pour estimer le vent.  Bien évidemment,  nos amateurs ne peuvent pas donner de réponse logique. La suite de la réflexion est encore pire car elle interdit le principe même du découpage en Sprint et le reporting Agile exprimé généralement par son graphe d’avancement  (BurnUp ou BurnDown).

Les apprentis débutants sorciers tenteront alors le dernier grigri : Utilisons quand même nos points de complexité sans aucun rapport avec une journée idéale ou non… Ensuite, c’est à partir du deuxième ou troisième sprint qu’il sera éventuellement possible  de commencer à extrapoler la durée du projet et son coût. Soyons sérieux : si un boss  accepte confier un budget sur ces bases, merci de nous en faire part.

Voilà, tout cela allait certainement « sans dire », mais cela ira certainement beaucoup mieux après l’avoir compris. On ne s’étonnera donc pas que ce ne soit plus « au pied du mur que l’on voit le maçon », ni comme disait le proverbe chinois de Bigard « au pied du mur que l’on voit le mieux le mur ». Il semblerait que désormais, il faille systématiquement « emplafonner le mur, pour bien sentir qu’il y avait un mur ». 

Faille / Avancement