Récemment, j’ai été impliqué dans un nouveau projet excitant dont vous avez peut-être entendu parler. Je suis certain que ça va vous intéresser… Tout a commencé quand on m’a demandé de gérer le développement d’un nouvel ensemble de logiciel et de matériel qu’on croyait être un complément utile à notre offre actuelle.
Cette demande a été suivie d’une séance de brainstorming très drôle sur les solutions de TI de notre entreprise, entre moi et ma patronne. Euh désolé, ma partenaire (OK, ne lui dites pas mais elle est les deux.) Bien sûr, elle était destinée à devenir la Product Owner de cette merveilleuse aventure.
Quoi qu’il en soit, on m’a demandé de gérer cette merveilleuse aventure que nous appelions tendrement notre « Bébé 2.0 » (oui, oui, je sais que c’est mignon.) J’étais donc le chef de projet et en tant que tel, j’ai reçu des instructions strictes de ma merveilleuse patronne. Il s’agissait de quelques contraintes communes dont je me souviens comme quelque chose de la sorte : « bla, bla, bla… Développement à date et prix fixes… Bla, bla, bla… Tout doit être prêt dans environ 40 semaines… Bla, bla, bla… La solution doit correspondre à notre gamme de produits, vous devez suivre notre charte graphique! », etc.
Tout semblait être connu et contrôlé avant que nous ne commencions à agir. C’était comme si l’analyse fonctionnelle était déjà produite, vérifiée, validée et disponible pour la phase de développement. Mais je suis influencé par Scrum vous savez (avec plusieurs certifications, je ne peux pas cacher mon intérêt) et il est assez difficile de connaître la bonne façon de faire et de la jeter à la poubelle quand le contexte n’est pas « ouvert d’esprit ».
Alors j’ai dit à ma patronne que nous ne pouvions pas tout connaître à l’avance et que le travail émergerait tout au long du développement car il était presque impossible de tout savoir sur la solution dont nous avions besoin au fur et à mesure que notre entreprise évoluait. Je lui ai donc donné quelques bases de Scrum et j’étais content de la convaincre d’adopter ce merveilleux cadre pour gérer tous les processus dont nous avions besoin. Elle ne connaissait pas l’Agilité ou Scrum avant cela, mais la méthodologie semblait être aussi drôle que le brainstorming l’avait été (je pense que c’était le cas, peut-être que je devrais lui demander…)
Nous avons donc décidé d’utiliser Scrum pour ce projet! Quelle bonne idée, n’est-ce pas? Mais avant d’envisager d’appliquer Scrum au développement de notre solution, nous devions réfléchir davantage au projet lui-même, parce que nos idées étaient un peu floues et tous les aspects devaient être pris en compte.
Tout ce que nous savions à ce moment était ce dont nous avions besoin et quand… Nous avons donc défini certains éléments de base du carnet de produit comme les premières caractéristiques de la solution et nous avons discuté d’autres aspects tels que l’utilité, les aspects juridiques, etc. Après ça, nous avons été en mesure de planifier la première (et la dernière) version. Nous étions certains de la solution à mettre en place, nous avions une limite de temps et nous savions exactement ce que nous devions faire. En fin de compte, nous avions neuf mois pour terminer le projet, nous avons donc prévu une livraison dans neuf mois avec neuf sprints d’une durée d’un mois.
Avec ces bases, nous avions une meilleure idée de l’aventure et pouvions enfin penser à l’équipe Scrum (je dois avouer qu’en fait l’équipe a été « bâtie » longtemps avant la séance de brainstorming et ce projet était juste une bonne raison pour moi d’appliquer Scrum en dehors d’un projet de TI.)
Ainsi, nous avions besoin d’un Product Owner, d’une équipe de développement et enfin d’un Scrum Master. Le rôle de Product Owner avait déjà été assigné à ma partenaire, car elle savait tout ce que nous avions à savoir sur la solution et ses idées étaient très claires sur ce qu’elle voulait y voir (et vous savez, c’est elle qui mène, alors…)
Comme la Product Owner en savait beaucoup sur la solution à construire, la meilleure chose à faire était de la laisser mener le bateau (c’est le rôle du PO : mener le bateau et donner à l’équipe les meilleures chances de livrer des incréments de grande valeur). Alors je l’ai laissée mener le bateau. Après tout, cette aventure était une réalité grâce à elle. Elle a dû trouver de bons développeurs, conscients des technologies que nous devions utiliser et de l’objet du projet. Je n’avais qu’à l’accompagner pour faire les meilleurs choix. Très intéressant : elle avait déjà une équipe formidable (qu’elle appelait « Mon Équipe »), prête à prendre le projet en main. Nous n’avions plus qu’à trouver un Scrum Master.
Le rôle de Scrum Master devait maintenant être attribué et beaucoup de choses étaient en ma faveur. D’abord j’étais le chef de projet. Attention, beaucoup de gens comprennent mal le rôle du Scrum Master et le confondent avec celui du chef de projet. Parfois, ils le font aussi avec le rôle de PO. C’est une grave erreur, mais on rencontre cette situation si souvent que vous pourriez penser que c’est vrai. Deuxièmement, j’étais présent lors du brainstorming (en fait, une sorte de fête de lancement). Troisièmement, j’ai plusieurs certifications Scrum! Merde, je mérite cette position de Scrum Master, vous ne pensez pas? Eh bien, c’est ce que je pensais mais, vous savez, parfois les choses ne vont pas comme on le voudrait. Je pensais vraiment que je devais être le Scrum Master et j’ai choisi d’embrasser ce rôle mais ensuite, j’ai rencontré l’obstétricienne!
Oui, peut-être que ce n’était pas encore tout à fait clair pour vous mais notre objectif était de construire un véritable Bébé 2.0, un ajout à notre famille de logiciel et de matériel, conçue pour être mis à jour plus d’une fois. Le client était impatient d’obtenir une nouvelle mise à jour, et parfois, même lorsque vous avez une excellente entreprise avec de bons employés, vous devez faire appel à des experts et embaucher des consultants. C’est ce que nous avons fait (également parce que dans ce cas, il est obligatoire d’y avoir recours, sauf si vous êtes vous-même obstétricien.)
Elle était géniale! Elle a veillé à ce que les réunions quotidiennes aient lieu. Chaque mois, elle était là pour nous aider avec la revue de sprint (vous savez, cet événement où vous pouvez observer les progrès et le travail effectué), nous tenant la main pendant que l’équipe présentait le dernier incrément de la solution. Elle nous aidait en facilitant l’événement (dans notre cas, l’échographie révélait les incréments et l’état de l’ensemble du projet. C’est assez cool, vous pouvez presque tout voir.)
Elle nous a aidés avec la rétrospective de sprint et elle était là pour aider la Product Owner et l’équipe de développement à surmonter les obstacles (« Chère future mère, vous avez pris trop de poids ce mois-ci, essayons ceci pour éviter que cela ne survienne de nouveau »), nous aidant à comprendre les processus présents jusqu’à version finale.
Je me suis retrouvé avec une seule chose à faire : attendre la dernière livraison (parce que chaque sprint était de bonne qualité et que nous n’avons jamais ajouté aucun élément au carnet.) Comme vous pouvez le voir, mon rôle dans le projet était extrêmement important! Je pensais que j’étais là pour offrir toutes mes connaissances sur les processus, la gestion de projet et bien sûr, Scrum, mais en fait, j’étais juste… une partie prenante!
Malgré tout, c’était un beau projet, une belle aventure avec de beaux moments, vécue avec beaucoup de plaisir et de joie et… vraiment exceptionnelle. Nous avons même terminé le projet à l’avance!!! Pouvez-vous en dire autant de vos projets en cascade?
La chose la plus importante à retenir de cette histoire est que même si l’on sent que l’on possède toutes les connaissances requises, il est important de savoir quelle place on devrait occuper. Naturellement, vous pouvez utiliser vos connaissances et les partager avec ceux qui le désirent, mais il y a une place pour tout et il est extrêmement important de laisser les équipes travailler à tirer le meilleur d’elles-mêmes.
Pas de commentaire