Loading...Pour terminer ma journée au ScrumDay 2011 du 31 mars 2011 au centre de conférence de Microsoft, j’ai suivi la session relative au Scrum pour un projet court. Un directeur de mission et un développeur d’Octo qui ont travaillé sur un projet IT pour un grand groupe d’assurance sont venus présenter leur retour d’expérience. Leur équipe était chargée de réaliser en mode « urgence » sur une durée prévue à 2 mois une application jugée facile (plusieurs CRUD sur une base existante).
Cette présentation bien scénarisée leur a permis d’énumérer les pièges qu’ils ont rencontrés (ne plus faire), leurs bonnes pratiques (à refaire) et leurs faiblesses (à faire).
Voici quelques-uns de cas énumérés dans cette présentation :
* [Ne plus faire] : Ne pas démarrer un projet en Décembre. Il y a 50% du temps du premier mois (ou 25% du temps de ce projet) où les acteurs ont de forte chance de ne pas être disponibles.
* [A refaire] Avoir une équipe Scrum qui se connaît et s’est déjà pratiqué. C’est normal quand on se rappelle qu’une des valeurs est l’auto-gestion. Une équation « Pas de maturité + Scrum = Echec » ne choquera pas grand monde … après.
* [A faire] Rencontrer tous les acteurs du projet IT au démarrage. Après le démarrage, un responsable opérationnel du projet IT a été surpris d’apprendre que la méthode proposée par le prestataire (et accepté par les acheteurs) était Scrum. Au final, le client n’a pas fait de Scrum, le rôle de product owner a été assuré par Octo. De plus, ils n’avaient pas rencontré l’équipe d’intégration et ils se sont pris quelques surprises en phase de déploiement.
* [A refaire] Disposer d’un kit d’intégration sur le projet IT. Quand une ou plusieurs ressources changent sur le projet. L’intégration est reproductible et cohérente. (ils se sont quand même trouvé au milieu du LEM – Loi de l’Emm… Maximum).
* [A faire] Il faut que les membres de l’équipe soient capables de communiquer. Dans ce projet, un développeur à déclarer sa rage de la situation du projet IT à une partie de l’organigramme. Les membres d’une équipe Scrum (matures, normalement) doivent être capables de communiquer professionnellement avec les autorités du client.
* …..
Au final, le projet s’est terminé fin mars, soit 4 mois au lieu de 2. Le retour d’expérience était intéressant. Je ne sais pas si on peut trouver des faits qui les ont sauvé (doublement de la charge) mais ils n’ont pas lâché le morceau. Ils sont allés jusqu’au bout. Ici l’apport de d’une méthode Agile a permis d’impliquer toute l’équipe, de rester concentré sur l’objectif (ils avaient aussi intégré du Kanban – limitation de parallélisation), d’avoir une équipe mature, …
