Agile mais pas toujours facile!

Ça fait maintenant plusieurs mois que notre agence travaille avec la méthodologie agile Scrum et en ce qui me concerne, je considère que nous avons fait un grand pas en avant. Implanter un tel changement au sein d’une entreprise n’est pas une mince affaire. Non seulement les employés doivent modifier leur façon de travailler, mais il faut aussi que les clients s’adaptent.

Après quelques mois, on peut constater que nous avons grandement amélioré notre vitesse de production. Un projet qui nous prenait 3 mois à réaliser peut nous prendre maintenant la moitié du temps mais à certaines conditions.

Agile mais pas facile : Argent vs Temps

Dans un précédent billet, j’ai expliqué en quoi consistaient les grandes lignes de Scrum. On travaille par périodes de 2 semaines (sprint) et au début de celle-ci, on planifie toutes les tâches qui seront effectuées pendant cette période. On communique ensuite aux clients ce que nous nous engageons à leur livrer après ces 2 semaines.

En théorie, ça peut sembler simple mais ce n’est pas toujours le cas. Nous rencontrons quelques fois des embûches qui ne sont pas faciles à surmonter. Lorsqu’on planifie les tâches à faire pendant un sprint, on se garde une marge de manœuvre pour les urgences et les petites demandes de nos clients. Ces travaux sont plus difficiles à planifier car on ne peut pas toujours prévoir le temps nécessaire pour régler un problème ou un bogue. Si une urgence survient, nous devons évidemment travailler dessus le plus vite possible. Sans compter que la notion d’urgence est une notion plutôt abstraite en web ! Un site transactionnel sur lequel on ne peut plus acheter en raison d’un problème technique doit être considéré comme une urgence, mais un lien brisé vers la page Le mot du président est loin d’être dramatique!

Ceux qui travaillent dans une agence le savent, il y a des semaines où le nombre de petites demandes qui entrent est complètement fou. On tente de régler ces demandes le plus vite possible mais ça peut causer des problèmes au niveau de la planification.  Quand ces demandes s’accumulent et que nous ne pouvons pas y travailler au cours d’un sprint de 2 semaines, nous devons les planifier pour le prochain. Le problème, c’est que si le calendrier de production est très chargé  pour plusieurs sprints, nous risquons de ne pas arriver dans les délais qui ont été fixés pour les mandats en cours.

Il arrive souvent qu’une urgence requiert le temps d’une seule personne et dans notre cas, c’est souvent le programmeur. Si celui-ci a déjà des tâches de planifiées pour un ou des projets en cours, il faut éviter à tout prix que le temps qu’il passe à régler un problème nuise au développement des projets en cours et surtout, que cela bloque les autres membres de l’équipe.

Avec certains clients, il est plus difficile de travailler en Scrum car cette méthodologie nécessite une certaine rapidité au niveau de la prise de décision des clients. Par exemple, si nous remettons une maquette de la page d’accueil que le client doit approuver, nous avons besoin du feed back de ce dernier pour continuer. S’il prend plusieurs jours à nous revenir à chaque fois que nous devons lui faire approuver un truc, il devient difficile de planifier les travaux de façon précise. Dans les grandes entreprises, les délais d’approbation sont souvent plus longs car plusieurs personnes sont impliquées dans un projet et une certaine hiérarchie doit être respectée. En fait, le problème n’est pas relié aux délais d’approbation mais plutôt au fait que nous ignorons quand nous aurons cette fameuse approbation. Si on sait que le client va nous revenir dans 3 semaines, ça ne nous cause pas de problème car on peut planifier notre temps en conséquence. Par contre, si nous ne savons pas quand le client va nous revenir (souvent parce que même le client l’ignore), nous sommes alors dans l’impossibilité de planifier la production du projet.

Cela dit, je crois que les obstacles que nous rencontrons sont surmontables et qu’il est tout à fait normal que nous ayons à faire des ajustements en cours de route. D’ailleurs, à chaque fin de sprint, nous avons une rencontre d’équipe pour faire une revue et une rétrospective des points positifs et négatifs. Cela nous permet d’apporter des ajustements quand on constate que certaines choses ne se sont pas aussi bien déroulées que prévu. Mais après 10 mois, on peut déjà affirmer que la méthodologie agile Scrum est bénéfique pour notre agence et surtout, pour nos clients.

2 réponses à Agile mais pas toujours facile!
  1. Benoit David Répondre

    Très intéressant… Pouvez-vous décrire la composition de vos équipes?

    • Josée Legault Répondre

      Merci pour le commentaire. Notre équipe est constituée d’un PO, d’un designer, d’un intégrateur et de deux programmeurs. Nous avons également un Scrum Master qui travaille avec les 2 équipes de notre agence.

Laisser un commentaire

Votre adresse courriel ne sera pas publiée. Entrez votre nom, courriel et votre commentaire.

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">