t+1 an : Etat des lieux concernant la mise en place de l’agilité dans notre agence

De Fabien Gaujous dans Méthodes et Organisation

17 juin 2013

Depuis le début de la mise en place de cette organisation en mode agile (Voir notre article précédent sur sa mise en place au sein de notre entreprise) , l’amélioration continue a été un point clé afin d’améliorer le processus qui était nouveau pour nous.

Ainsi, la mise en place des rétrospectives tous les 15j, incluant l’ensemble de l’équipe (PO/développeurs) nous a permis  de remonter les problèmes du sprint passé, et de les traiter en continu.

Ces rétrospectives, d’une durée assez importante au départ (environ 2h), ont permis de changer notre organisation définie au départ pour mieux correspondre à notre travail.

Voici une liste non exhaustive des problèmes rencontrés lors des premiers mois :

  • Des critères d’acceptation inexistants ou trop flous dans  les User Stories (US), ce qui engendre des incompréhensions et trop de retours à la fin du sprint.
  • Trop de projets dans un même Sprint : En effet, chaque Pos voulant faire avancer son projet, un même développeur peut changer plusieurs fois de projets dans un Sprint.
  • Des démos non préparées et sans environnement de déploiement : De nombreuses fois, les démos doivent se dérouler sur le poste d’un développeur. De plus, de nombreux problèmes apparaissent lors de la démo car les US, développées unitairement par chacun des membres de l’équipe peut engendrer des incohérences d’un point de vue global de l’application.
  • la journée de  planification est jugé trop longue. A la fin de la journée, les développeurs ont dû assimiler trop d’informations  d’un coup. De plus, toutes les US préparées par le PO pour un projet sont prises en compte. Or, certaines US ne seront pas développées dans ce sprint en fonction des priorités décidées. Cela veut dire, qu’ il faudra  re-présenter toutes les US afin de replonger sur le sujet.
  • Daily Scrum : Toute l’équipe ne travaillant pas sur les mêmes projets et les mêmes technologies, des personnes s’ennuyaient au Daily Scrum, ne se sentant pas forcément concernées par les discussions en cours.
  • Le système de maintenance mis en place n’a pas fonctionné : En effet, chaque personne de l’équipe n’a pas la connaissance technique ou fonctionnelle de toutes les applications que nous maintenons, même si les technologies sont la plupart homogènes sur nos projets. Au départ, nous pensions que cette organisation permettrait de faire monter les personnes de l’équipe en compétence sur des projets qu’ils ne connaissent pas et ainsi éviter les ressources critiques.
    Cependant, lors du sprint, la personne en charge de la maintenance, dérangeait chacun des membres de l’équipe à tour de rôle si un problème subvenait sur un projet qu’il ne connaissait pas. Au début, il n’y avait aucun problème à cela puisque notre but était la montée en compétence de chacun des membres de l’équipe. Cependant, le système de « pompier tournant » impliquait qu’une personne revenait  faire de la maintenance tous les 2 mois… la compétence technique ou fonctionnelle acquise sur un projet était donc souvent oubliée.

Le Scrum a tout de même apporté un réel dynamisme de la part de l’équipe car chacun se sentait bien plus impliqué dans la construction de cette nouvelle organisation.

 

Les solutions apportées

Afin de pallier aux nombreuses difficultés rencontrées, nous avons dû changer l’organisation initiale mais en le prenant avec le sourire, c’est ça l’amélioration continue !

Reprenons point par point les différentes modifications apportées :

  • Le Daily Scrum : Afin de pallier à ce problème d’ennui, l’équipe, divisée principalement autour de 2 technologies, a donc décidé de faire 2 Daily Scrums différents le matin afin de focaliser les discussions sur les intérêts en cours de chacun.
  • La plannification du sprint: Les POs ont découpé leurs projets en lots plus concis et priorisé tout ceci avant le Sprint planning. Lors de son déroulement, quand la charge allouée au sprint est atteint (+ 20 pts par exemple), le sprint planning est stoppé et le Sprint peut commencer.
  • D’un point de vue global, les POs ont essayé de faire rentrer moins de projets dans le sprint pour éviter les switchs et accordé plus d’importance aux critères d’acceptation.
  • En ce qui concerne la maintenance, l’idée du « pompier délégué » a été oubliée, au profit d’une liste de référents (minimum 2) sur chaque projet. Les bugs bloquants étaient  gérés par les référents pour chaque projet (une charge de 1j/h dans le sprint était enlevée à l’équipe pour ce traitement).
    Les bugs  non bloquants ou la maintenance évolutive étaient planifiés dans le sprint.

 

Conclusion : stagnation

Les modifications apportées ont nettement amélioré l’organisation, cependant, au bout de quelques mois, l’équipe s’est essoufflée.  En effet, des problèmes revenaient souvent, et nous ne parvenions plus à déterminer nos axes d’amélioration.

Nous avons estimé qu’un regard externe pouvait nous aider à prendre du recul et nous poser les bonnes questions. Pour ce faire, nous avons sollicité l’aide d’un coach externe à notre organisation.

 

 

Commentaire

× 3 = neuf

iMDEO recrute !

REJOIGNEZ-NOUS

A la recherche de nouveaux talents (développeurs web et mobile, chefs de projet,...)

Voir les annonces