J'ai commencé à me familiariser avec les méthodologies agiles de développement de logiciels en 2013, au moment où la méthodologie Scrum atteignait son plus haut niveau de popularité. J'ai été instantanément enthousiasmé et j'ai plongé profondément dans tout le matériel que je pouvais trouver. J'ai lu des livres sur Scrum, j'ai suivi le courant jusqu'au Manifeste Agile, et plus loin encore jusqu'à la méthodologie Lean, le grand-père de Scrum. C'est devenu le fondement de ma capacité à diriger une équipe. J'ai vu comment cela améliorerait les choses pour mes équipes, mes employeurs et moi-même. L'amélioration continue, la réduction du gaspillage et l'augmentation de l'efficacité. J'ai adopté les valeurs, les principes et la méthodologie et j'ai fait tout ce qui était en mon pouvoir pour les mettre en œuvre sur le lieu de travail. J'ai rencontré toutes sortes de résistances. Ce fut un processus d'apprentissage extraordinaire.

Le terme "Agile" était sans équivoque un grand slogan à la mode. De nombreuses organisations prétendaient adopter les principes agiles à des fins de vente ou de prestige. Parfois, tout ce que cela signifiait, c'était qu'elles pouvaient montrer la quantité d'Agile qu'elles avaient achetée tout en ajoutant des couches à leur hiérarchie. "Nous avons acheté pour 200 000 dollars d'Agile cette année ! Regardez comme nous sommes agiles ! Et aussi le cloud ! (Le cloud est agile, n'est-ce pas ?)".  En règle générale, l'organisation adhère à l'idée de l'agilité pour "accroître l'efficacité", mais les dirigeants n'ont jamais eu l'intention de s'engager dans un changement en profondeur.

D'autres organisations ont mis en avant leur approche "hybride", mélange de Waterfall et d'Agile (c.-à-d. Scrumfall ou Scrumfail). Ces organisations assimilent souvent l'Agile au tableau Kanban : "C'est un projet Agile : nous utilisons JIRA. (JIRA est Agile, n'est-ce pas ?)". Elles utilisaient un tableau Kanban pour rédiger des listes d'exigences ingérables avec des fils de commentaires infinis où toutes les informations disparaissaient dans le bruit. Les Sprints duraient éternellement. Les anti-modèles Agiles fleurissaient ; le plus étonnant dont j'ai été témoin était l'utilisation de story points pour brouiller les estimations. Le client voyait les estimations en story points, recevait des explications absurdes sur ce nouveau concept agile en vogue et était ainsi privé d'informations concernant le coût de chaque fonctionnalité.

Parce que tout le monde et leurs chiens voulaient se vanter d'être Agile, il y eut soudain une énorme demande de Scrum Masters formés (ou au moins certifiés). Ces personnes se sont plus ou moins transformées en tristes martyrs de la cause. On leur a confié une mission impossible. Ils ont été engagés pour faire quelque chose que ceux qui les ont engagés ne voulaient pas qu'ils fassent.. Ils ont dû travailler avec des équipes qui étaient à juste titre cyniques. L'équipe a vu de nombreuses réunions s'ajouter à son agenda et cela signifiait pour elle que son travail serait retardé et qu'elle devrait travailler plus longtemps. Ces Scrum Masters se trouvaient dans une situation difficile. Ils voulaient être des agents de changement, mais ils avaient des factures à payer, et ils ont donc essayé de ne pas faire de vagues et de ne pas se faire renvoyer. En fait, ils étaient inefficaces.

Ma situation était quelque peu différente dans ce type d'organisations, et probablement plus agréable, car j'ai toujours eu un double rôle dans une équipe. Lorsque je jouais le rôle de Scrum Master ou d'Agile Leader, j'étais également un contributeur au code ou je fournissais un leadership technique à l'équipe. Le canon Scrum ne recommande pas ce double rôle, et ce pour de bonnes raisons, mais cela m'a quelque peu protégé des épreuves que les martyrs Scrum Masters doivent endurer. Cela s'est avéré être un grand avantage. Les hiérarchies organisationnelles m'ont fait confiance et ont toléré mes tentatives de changement parce que j'étais un contributeur important aux projets, un atout apportant une valeur tangible. L'équipe m'a fait confiance et a respecté mon expérience en tant que développeur chevronné. Nous nous sommes beaucoup amusés et avons livré des produits extraordinaires. Nous avons fait de notre mieux pour incarner les principes agiles et mettre en œuvre les pratiques agiles. Mais en réalité, Scrum a toujours été une quête jamais accomplie. La direction remaniait les équipes, certains propriétaires de produits se montraient très réticents à l'égard de la collaboration sur le backlog, des changements majeurs s'opéraient au sein des équipes, des projets et des organisations sans aucune consultation. Mais quelle éducation !

Aujourd'hui, chez Monarq, nous utilisons la méthodologie Scrum. Nous incarnons les principes Agiles et mettons en œuvre les pratiques Agiles. Notre approche est inspirée d'un article de David Marquis que j'ai lu en 2014 "Small team, multiple projects : an Agile approach to planning" (Petite équipe, projets multiples : une approche Agile de la planification).

https://davidmarquis.wordpress.com/2011/12/03/small-team-multiple-projects-agile-planning/
La prochaine fois, je vous expliquerai comment nous appliquons ces idées.