Réflexion sur Scrum et la transition vers celui-ci (Part 1)


silicon_valley_scrum

Scrum

Ceci fait déjà un bon moment que je voulais faire cet article, mais il est très difficile de bien décrire Scrum sans tomber sur des Scrums Master pur et dur qui viendrons tout détruire ton article. Il ne suffit que de regarder la page Wikipédia sur Scrum avec la quantité d’itération de l’article. Tous ne sont pas d’accord sur la méthode exacte à propos de Scrum. Je tiens à préciser que vous n’aurez pas une démarche à suivre pour apprendre Scrum ici. Allez plutôt lire Wikipédia ou sinon, écouter cet extrait de l’émission Silicon Valley qui décrit assez brièvement comment fonctionne réellement Scrum (attention, le début a un passage un peu cru, mais qui montre bien ce qui arrive souvent en entreprise) https://youtu.be/YGftcWDbVeY.

La réflexion que je vais faire est sur une adaptation personnelle de Scrum en entreprise et comment passer d’une gestion de projet traditionnel vers une méthodologie Agile. Si vous voulez lire à propos de Scrum, il y a énormément d’articles sur le sujet, sans compter des forums complets gérés par des personnes spécialisées là dessus. Moi, c’est une adaptation pour être en mesure de ne pas trop déstabiliser les dirigeants lors d’un passage d’une méthode de gestion dite standard à Scrum.

Quelles sont les grosses différences entre les 2 méthodes (Standart VS Scrum) et comment faire la transition

L’implication du client est beaucoup plus poussée.

Souvent les dirigeants vont trouver qu’on en dévoile trop au client, puisqu’il doit-être au courrant de tous les avancements, mais aussi des ralentissements. Techniquement Scrum va jusqu’à demander à ce que le client travaille dans les locaux des programmeurs … ou les programmeurs travaillent chez le client. Bon pour être franc, c’est très rare que ça se produise et très peu de dirigeants vont aussi l’accepter, puisque ça met le client en contact avec les outils internes à l’entreprise. Moi personnellement j’opte plutôt pour une réunion ou même une vidéoconférence à toute la semaine, et ceci après une mini-réunion interne. Oui, on ne dévoile pas tout, mais si on veut rester agile, tout ce qui touche à une décision du client doit-être discuter, autant les bons que les mauvais coups. Habituellement, réussir à faire comprendre aux dirigeants qu’on discute de ce qu’on va dévoilé au client avant la réunion avec lui, ceci le rassure de beaucoup et permet de mieux faire accepter Scrum. Ensuite avec le temps, on peut diminuer la durée de cette réunion et si possible complètement le retirer.

Les mêlées quotidiennes sont aussi une source de questionnement pour les dirigeants et même les employés.
Ils peuvent trouver que ceci finit par devenir une perte de temps. Pour rappel, Scrum favorise une réunion express chaque matin pour que chacun indique 3 points:

  • Ce qui a été fait la veille
  • Ce que l’employé devrait faire aujourd’hui
  • Les défis rencontrés

Techniquement ceci ne devrait pas dépasser 2 minutes par personne et peut très bien être accompli par vidéoconférence ou même par courriel. Mais comment faire accepter ceci ? Habituellement il faut le faire comprendre comme étant un plan de match. Mais la réponse que j’ai déjà reçue: « Oui, mais ce n’est pas à toi à le faire ? ».  En fait, ceci est la magie de Scrum, chacun fait un peu ce qu’il veut, tant qu’il respecte la ligne directrice demandée. Donc ceci peut paraître non optimisé, sauf en fait ce n’est pas le cas. Donner un projet à un employé qui ne veut pas le faire et regarder sa vitesse de travail, elle sera loin d’être optimal. Par contre, si l’employé décide par lui même de faire ce même ticket pour s’en débarrasser, étrangement le travail sera mieux accompli et sera fait aussi plus rapidement. Donc au final, la perte de temps occasionnée par la non-optimisation de l’ordre des tickets est corrigée par une amélioration de l’attitude des employés. Donc, faire comprendre que des employés heureux travaille plus et demande souvent moins d’augmentation, ceci fait passer beaucoup mieux passer la pilule.

Par contre, vous pouvez séparer cette réunion par secteur d’employé. Mettre un employé de logiciel entouré de personne de matériel et il va vite finir par trouver que c’est une perte de temps, puisque jamais personne ne pourra venir discuter avec lui des problèmes qu’il a rencontrés et de possibilité pour faire ses tâches de la journée. Avoir vécue à mainte reprise cette situation, la mêlée quotidienne finie par ne devenir plus rentable et des commentaires de perte de temps vont se faire sentir. Mais si vous subdivisez cette réunion, pensez à discuter de la progressession chaque semaine entre les départements ou apporter les points marquants des autres secteurs lors des mêlées. Comme ça, la communication entre les divers secteurs sera conservée.

Le diagramme de Gant VS le Burndown Diagram

Je ne sais pas pourquoi, mais les dirigeants aiment beaucoup les diagrammes de Gant, mais tout bon Scrum Master sait très bien que diagramme de Gant est l’antithèse de Scrum. En fait, Scrum favorise plutôt un diagramme qui indique une date approximée de la relâche alpha du programme selon les performances des employés au lieu d’estimée ceci en ce basant sur l’expérience du gestionnaire de projet qui doit tout estimé dès l’analyse en espérant de ne pas se tromper. Mais personnellement et l’ayant à mainte fois vécue, aucun des 2 systèmes n’est parfait. Est-ce qu’il vaut mieux se baser sur l’expérience du gestionnaire et l’historique des anciens projets ou adapter la date de livraison selon la progression actuelle de développement?

image004

Diagramme de Gant

En fait, le diagramme de Gant fonctionne très bien tant que les changements n’arrivent pas trop souvent. Un employé malade durant quelques jours peut donner un mal de tête immense au gestionnaire de projet qui sera pris à tout recommencer. Vouloir ajouter une amélioration durant un développement ou ajouter du personnel peut demander une refonte du diagramme. Par contre, les outils sont rendus très efficaces, mais on est loin de pouvoir faire ceci avec un papier et un crayon.

 

burndown-chart-trend

Burndown diagramme

Je dois avouer, que j’ai un petit faible pour le Burndown diagramme qui ne demande presque aucune maintenance. En fait, c’est un simple diagramme à bande où on dessine une ligne des tâches restante chaque jour. Techniquement si on dessine un trait qui fait la moyenne, on peut facilement estimer que les jours restants vont ressembler aux jours précédents. Si une personne manque à l’appel, alors dès le lendemain, la moyenne sera influencée, ce qui corrigera la date estimée de livraison. Si on ajoute du personnel, alors même principale, le nombre de tâches diminuera plus rapidement, ce qui influencera à la baisse la date de livraison. Aucun mal de tête pour la gestion, le système ne s’adapte à tous les changements demandés. Le plus beau, techniquement tout ceci peut-être fait avec un tableau blanc et des post-its. Ceci ne demande aucune licence coûteuse sur des logiciels qui au final sont très souvent sous-utilisés. Par contre, il existe aussi des logiciels qui essaient de se dédier à Scrum. Personnellement, je n’ai utilisé que OnTime de la compagnie Axosoft. Il fonctionne très bien, il fait les Burndown Diagram en temps réel et possède le tableau des tâches intégré et accessible par tous, même s’ils ne sont pas présents physiquement. Puisque la méthode tableau banc et post-it fonctionne bien … tant que tous sont réunis. Oubliez le travail à la maison, ceci ne fonctionnera pas très bien, alors il faut passer par un logiciel comme OnTime.

Gestionnaire de projet ou Scrum Master

À première vue, la personne sert un peu à la même chose. Les 2 doivent orchestrer le travail. Mais d’après là théorie de Scrum, le Scrum Master n’est présent que pour faire respecter l’idéologie de Scrum et s’assurer que tous comprennent bien leur rôle. C’est un genre de police et de professeur. Mais dans la réalité, le client ne veut pas créer des stories (tâches). Il veut qu’une personne le fasse pour lui d’après ses demandes et il veut qu’une personne fasse un suivi avec lui. Aussi les dirigeants vont vouloir des comptes rendus, des rapports pour aller chercher des subventions, une personne qui va traduire ce qui se passe dans le département en langage clair pour lui. Mais tout ceci dépasse la notion de Scrum Master. Bien que la théorie de scrum indique l’inverse, il est très difficile que le scrum master ne possède pas les 2 chapeaux. Mais le côté éducation et police du Scrum Master doit toujours être présent. L’objectif est que tranquillement retirer le chapeau de gestionnaire de projet ou du moins le limite au maximum, mais ceci peut-être fait sous plusieurs mois, voir des années.

Pour conclure cette partie 1

Ceci n’est qu’un début, des trucs pour faire la transition. Il y en a des tonnes. Mais, ça fait presque un mois que j’écris des ébauches pour cet article, j’ai donc décidé de le scinder en plusieurs. Ceci sera moins lourd à lire pour vous et ça me permettra de lire vos commentaires pour adapter les parties suivantes.

Maxime Savard

Liste des différentes méthodologies

Advertisements

3 réflexions sur “Réflexion sur Scrum et la transition vers celui-ci (Part 1)

  1. Ping : Réflexion sur l’embauche de gestionnaire à l’interne/externe | Réflexion sur la gestion de projet

  2. Ping : Réflexion sur le risque maximum | Réflexion sur la gestion de projet

  3. Ping : Réflexion sur la gestion des artistes | Réflexion sur la gestion de projet

Laisser un commentaire

Entrer les renseignements ci-dessous ou cliquer sur une icône pour ouvrir une session :

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l’aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s