Agile-IT

Agilité et Lean-IT: penser l'informatique au plus juste

"Scrum c'est pas sérieux"

février 17
by Greg 17. février 2011 16:10

Nous vous proposons une série de billets, issus d'ateliers menés auprès de collègues et d'amis, et dont le but est de proposer des réponses simples à un certain nombre de critiques et lieux communs que vous pouvez régulièrement entendre ou avoir vécu lorsque vous souhaitez parler de Scrum.

Voici le premier de cette série de billets. Il vous propose quelques réponses à apporter à quelqu'un qui vous dit : "Scrum c'est pas sérieux". Les éléments de réponse ci-dessus ne constituent en rien une liste exhaustive et ne sont pas nécessairement purement objectives.

 

Vous qui pratiquez le Scrum, n'avez vous jamais eu affaire à une personne quelque peu critique voire moqueuse sur la méthode?

  • Tout d'abord en réponse à une remarque du type "Scrum c'est pas sérieux" il est important de savoir si la personne en face de vous a déjà eu l'occasion de pratiquer Scrum et/ou si elle s'est déjà renseignée un minimum. Nous partirons du postulat de base que notre interlocuteur connait un minimum la méthode.
  • Une de ces premières objections pourrait être : "Je ne comprends pas pourquoi vous faites du Scrum, personne n'en fait" insinuant que le Scrum est une méthode ou une pseudo-méthode applicable sur certains types de projets bien particuliers et qu'elle ne peut être appliquée partout et à tous. Votre réponse peut se résumer en citant quelques références dans le monde informatique: Google, Microsoft, Yahoo, Adobe, Nokia... (n'hésitez pas à en rajouter si vous en avez sous la main). De grands noms de l'informatique ont effectué une transition vers l'agilité et utilisent Scrum.
  • Face au Scrum board et à tous ses post-its multicolores, ses cases et le burn down chart, il n'est pas rare d'en voir certain se poser des questions ou encore de vous faire remarquer que "vous avez un peu trop de rose et pas assez de bleu". Pourquoi des post-it? Parce que c'est visuel et clair et que le côté physique du tableau et du papier humanise la méthode.

    De même le fait que les membres de l'équipe déplacent les tâches à la vue de tous, offre plus de transparence, un suivi clair et partagé par l'équipe à tout moment et donc une meilleure communication.
    Par expérience, nous nous sommes aperçu que le daily meeting derrière un écran n'offrait pas la même visibilité qu'un grand tableau.

    De plus cela rend la méthode ludique. Qui a dit que l'on devait forcément s'ennuyer au travail ?
  • "Ce sont les développeurs qui chiffrent? Pas la MOA ou le commercial?" ou bien "Vous laissez les développeurs chiffrer? Mais ils vont vous multiplier par trois ou quatre les coûts!" Ce type d'affirmation sera d'ailleurs bien souvent prononcé par la MOA ou le commercial ou encore le client.
    Le développeur reste tout de même la personne la plus apte à estimer le coût de son propre travail.

    De plus, il n'y a pas que les développeurs qui chiffrent, tout le monde peut participer à la réunion de planning permettant ainsi un consensus et de la discussion autour d'une tâche. L'estimation n'en sortira que plus réaliste et transparente pour tout le monde.

    Le planning effectué par les développeurs peut créer un cercle vertueux entre les notions de responsabilisation de l'équipe, d'engagement et de prises de responsabilité sur les tâches à effectuer.

 

Merci à toutes les personnes qui ont permis de constituer cet ensemble de réponses

Tags: , , , , , , , , ,

Echange