Comme beaucoup d’entre nous, j’ai commencé mon cheminement Agile en consultant le Manifeste pour le développement Agile de logiciels. Mon équipe et moi avions décidé de tenter d’utiliser Scrum. Le guide nous apparaissait plutôt clair et sensé, et il semblait en plus être concis par rapport à nos méthodes de gestion de projet habituelles.

Puisque notre gestionnaire de projet passait beaucoup de temps avec notre client, il nous semblait évident qu’il deviendrait notre Product Owner. Au cours des mois précédents, j’avais commencé à me distancer du code et j’étais plus intéressé et curieux de participer à unir les gens afin de régler certains problèmes. J’ai donc décidé de devenir le Scrum Master de l’équipe.

En fait, a posteriori, le terme pouvait d’abord sembler apeurant puisque j’avais aussi peu d’expérience avec Scrum et l’Agilité que le reste de l’équipe. Alors, comment pouvais-je être considéré comme étant quelqu’un qui maîtrise Scrum ?

Au fil du temps, nous sommes devenus plus confiants dans notre travail collectif en tant qu’équipe Scrum. Le guide nous a beaucoup appris, et c’était notre référence dès que nous nous interrogions sur notre façon de travailler. Les règles de Scrum sont plutôt claires, ce qui nous a beaucoup aidés.

Mais vous n’avez rien compris !

Cependant, nous avions l’impression d’être passés à côté de quelque chose. Certaines choses ne semblaient pas aller, mais je n’arrivais pas à mettre le doigt dessus.

Les rencontres de planification de sprint étaient plutôt ennuyantes et l’équipe ne semblait pas se soucier de ce qui était accepté pour le sprint à venir. Puisque l’équipe ne se responsabilisait pas, je me sentais obligé de demander : « Pensez-vous vraiment que nous pouvons nous engager à faire ça ? »

Durant nos rencontres quotidiennes, personne ne semblait véritablement intéressé par ce que les autres faisaient. Les gens faisaient simplement ce qu’ils avaient planifié de faire. De plus, bien que les graphiques d’avancement aient été visibles, il n’y avait pas de véritable intérêt à s’assurer que les objectifs de sprint soient atteints. Bien sûr, les gens faisaient ce qu’ils devaient faire, mais nous ne ressentions pas l’atmosphère des grandes équipes Agiles.

Nos séances de revue semblaient plutôt viciées alors que le Product Owner énumérait les tâches « terminées » sans réelle implication de l’équipe. Et nos rétrospectives ? Elles étaient correctes, j’imagine… J’avais lu qu’il était important de tenir des rétrospectives et j’avais découvert quelques formats avec lesquels expérimenter.

Néanmoins, nous continuions de rencontrer des problèmes qui allaient au-delà de notre champ de compétence, ce qui nous donnait l’impression d’être impuissants.

Je suis certain que plusieurs d’entre vous auront décelé des choses

que nous aurions pu améliorer. À ce moment-là, j’en étais incapable. En fait, j’ai eu une révélation en regardant le film : La vie de Brian (Monthy Python’s Life of Brian). Pour ceux qui ne l’auraient pas vu, on y suit le personnage de Brian qui est né en même temps que Jésus et que l’on prend pour le Messie.

Une scène en particulier m’a frappé. À un moment durant le film, une grande foule se rassemble sous la fenêtre de Brian et attend qu’il lui dise quoi faire. Et tout d’un coup, en écoutant son discours devant cette masse de gens, ça m’a frappé.

Nous avions commencé notre cheminement Agile avec Scrum et nous nous attendions à ce que le guide nous dise quoi faire dans toutes les situations. Et même, à certains égards qu’il règle tous nos problèmes !

Ces idées se bousculaient dans ma tête pendant que le discours continuait :

Brian : « Vous n’avez pas besoin de me suivre, vous n’avez pas besoin de suivre qui que ce soit ! Vous devez penser par vous-même, vous êtes tous des individus uniques ! »

Foule : « Oui, nous sommes tous uniques ! »

Brian : « Vous êtes tous différents ! »

Foule : « Oui, nous sommes tous différents ! »

Brian : « Vous devez tous penser par vous-même ! Ne laissez personne vous dire quoi faire ! »

Soudainement, je ne savais plus si je devais rire ou pleurer. En nous concentrant sur la recherche de réponses dans les écrits, nous avions oublié les principes fondamentaux de l’Agilité. Vous voyez, une des premières valeurs du Manifeste pour le développement Agile de logiciels, c’est de mettre de l’avant les individus et leurs interactions plutôt que les processus et les outils. Nous nous étions concentrés sur le processus Scrum, sans penser à l’essence de l’Agilité.

Inspecter et s’adapter, au-delà de Scrum…

Alors, j’ai changé. Plutôt que de chercher des réponses, j’ai commencé à chercher de l’inspiration. J’ai commencé à participer à des rencontres et à des conférences, à rencontrer des gens et à discuter de nos difficultés. Et soudainement, plutôt que de voir plein de choses que nous ne faisions pas bien, j’ai vu une multitude de chances de grandir et de nous améliorer. J’ai commencé à lire à propos de la pensée systémique, sur comment les réponses devraient être propres au contexte (et c’est comme cela que j’ai compris le modèle Cynefin de Dave Snowden).

En fonction de ça, nous avons changé notre façon de tenir nos rétrospectives. Grâce à d’excellentes références qu’on m’avait suggérées (Agile Retrospectives par Esther Derby et Diana Larsen ainsi que l’outil Retromat), j’ai été en mesure d’essayer de nouveaux formats de rétro et, au bout d’un moment, certains membres de l’équipe se sont même proposés pour en être les facilitateurs.

À propos de la responsabilisation d’équipe, j’avais lu Responsibility Process de Christopher Avery. Après avoir participé à un atelier de deux jours avec lui et avoir appris comment appliquer ses principes à moi-même, je suis revenu vers l’équipe et nous avons commencé par déterminer notre niveau de responsabilité. Nous avons remarqué que nous étions habituellement dans un mélange d’obligation, de justification et de blâme. À partir du moment où nous avons découvert cela, nous avons commencé à nous demander si cela nous convenait ou si nous souhaitions changer. Il s’avère que cela nous a donné un nouveau point de vue sur des difficultés que nous pensions être en dehors de notre champ de compétence.

L’équipe s’est alors mise à tellement s’approprier ses sprints qu’il est devenu plus difficile pour la Product Owner de changer la portée de ceux-ci en cours d’itération. Lors d’une discussion avec la PO, elle a accepté de faire passer les sprints de deux semaines à une semaine. Cela a apporté une nouvelle vague de défis : comment pourrions-nous nous attendre à livrer chaque semaine s’il faut trois heures pour la mise en production ?

En fait, alors que l’équipe aurait dit que c’était impossible quelques mois auparavant, elle travaillait maintenant collectivement pour faire de cette nouvelle vision une réalité. Elle a commencé à automatiser plusieurs des actions nécessaires au déploiement et elle a développé un script qui sélectionnait tous les paquets approuvés durant la revue de sprint. Nous utilisions des centres de données externes alors, plutôt que ce soit nous qui livrions un incrément accompagné d’un document d’installation, nos partenaires recevaient soudainement un incrément auto-exécuté et ils étaient en mesure de déployer les paquets sans problèmes.

A posteriori, je pense que nous avons beaucoup appris durant cette première expérience avec Scrum. Étant habitués à travailler avec des méthodologies prescriptives, c’était difficile pour nous de laisser tomber nos habitudes. Démarrer sur la route d’une plus grande Agilité peut être effrayant au début parce que personne n’est là pour « nous dire quoi faire ». Le cheminement vers l’Agilité en est un d’éducation. C’est l’occasion d’arrêter de penser qu’il y a une réponse à toutes les questions et de commencer un cheminement d’expérimentation et d’apprentissage.

Appropriez-vous ces expériences, laissez l’équipe se les approprier également et assurez-vous de réfléchir au résultat de vos expérimentations. Je comprends que cela peut sembler intimidant au début, alors si vous désirez tout de même commencer, il pourrait être utile de vous référer aux cercles d’influence et de préoccupation de Stephen Covey (The 7 habits of highly effective people).

Planifiez ce que vous souhaitez essayer et commencez par ce qui se trouve dans votre cercle d’influence (je suggérerais même d’ajouter le cercle de contrôle). Avoir du succès avec ceux-ci vous donnera, ainsi qu’à votre équipe, plus de confiance pour tenter de nouvelles expériences afin de réussir !

 

J’ai amorcé ce cheminement il y a déjà quelques années et je ne l’ai jamais regretté.

 

 

Billet précédent

Lancement officiel des opérations du Tiers Lieu et inauguration des nouveaux locaux de Pyxis Technologies à Laval

Billet suivant

Y a-t-il un PO dans la salle?

Charles-Louis de Maere

En tant que coach Agile, Charles-Louis s'éclate lorsqu'il a l'occasion d'accompagner des équipes sur leur chemin de l'Agilité. Pragmatique avant tout, il évite les dogmatismes et préfère trouver des solutions adaptées à l'environnement. Curieux de nature, il adore voyager et faire de nouvelles rencontres, que ce soit lors d'événements de la communauté, en donnant des cours de formation ou simplement lors de voyages en famille.

1 Commentaire

  1. evan@boissonnot.fr'
    16/09/2017 at 03:28 — Répondre

    Bonjour Charles-Louis

    Un article très intéressant, je vous en remercie.

    La vision du dogmatisme d’un guide, quelqu’il soit est très parlante.
    Le problème survient souvent quand on a l’habitude de suivre des méthodologies.
    Or Scrum n’est pas une méthodologie, c’est un framework.
    Donc, on doit s’en aspirer pour l’adapter suivant le contexte, qui nous sommes.

    En fait, quand je lis votre article, je ressens un parcours qui mène vers la foi : au début, on suit un livre, puis on doute, et enfin, on en est convaincu sans plus jamais revenir en arrière.

    Au plaisir
    Evan, coach agile et responsable du blog Réussir son entreprise informatique

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *