La faute à Scrum

Plusieurs grandes figures de la communauté agile se sont récemment exprimées sur Scrum, l’agile, et ses premiers gros projets en déroute (James Shore, Alistair Cockburn, Alan Shalloway, Ron Jeffries et Martin Fowler). La lecture de ces articles (que je vous conseille vivement) et mes dernières expériences de coaching m’ont donné envie de partager mes réflexions via le blog.

Les méthodes agiles entrent dans la douloureuse période de l’adolescence.

A cet âge, on est convaincu d’avoir compris pourquoi le monde du développement logiciel tourne à l’envers et trouvé ce qu’il faut faire pour tout changer.

L’énergie est là, la rage au ventre de changer la donne. Cependant la vie s’apprête à nous donner quelques claques nous rappelant à l’ordre pour nous montrer du doigt ce qui était devant nous depuis le début : « Tout n’est pas si simple…Une seule méthode ne peut pas changer le monde ».

Nous faisons aujourd’hui la promotion de méthodes telles Scrum ou autres programmations extrêmes en y associant de beaux espoirs de réussites projet. Bien heureusement, nos espoirs se concrétisent souvent. Ces méthodes ne sont cependant que des cadres de travail, des propositions. Les considérer pour plus qu’elles ne sont peut s’avérer dangereux.

Scrum n’est pas une baguette magique.

Scrum propose plusieurs outils pour planifier, estimer, prioriser. Les grandes lignes sont simples à comprendre, quiconque voudrait s’improviser « Scrum Master » pourrait le faire en quelques jours de lecture bien sentis. Pourtant il est malheureusement de plus en plus fréquent de rencontrer autour de nous des projets Scrum en difficulté. Le backlog n’est pas correctement priorisé, le product owner n’a pas été correctement identifié, les rétrospectives sont baclées. Est-ce à dire que Scrum n’est pas une bonne méthode ? Je ne le pense pas.
Bien entendu, on peut penser que tous ces problèmes sont dus à des carences de Scrum. Ou encore, que cela ne serait pas arrivé si l’on démarrait les projets sur de « bonnes » bases agiles. Mais autant se le dire, ces occasions sont rares et difficiles. Le contexte culturel d’une entreprise n’est pas à prendre à la légère. La mise en œuvre d’une méthode agile « by the book » est un projet d’amélioration drastique (kaikaku en Lean) très risqué. Insuffler progressivement les pratiques agiles me semble l’approche la moins douloureuse et promise à plus de succès (kaizen en Lean).

Scrum est un catalyseur.

Scrum possède cet avantage ironique de n’être qu’un squelette méthodologique presque vide de pratiques : c’est une discipline. Commencer par un backlog et la mise en œuvre d’un processus de développement itératif est un bon début. L’équipe fera probablement « comme avant » à l’intérieur de chaque itération, mais aura un retour extrêmement rapide sur la pertinence de ses pratiques. Là même où en mode cascade il fallait attendre plusieurs mois pour difficilement prendre le temps du regard dans le rétroviseur.

Scrum est en ce sens un catalyseur. Il nous donne les moyens de réaliser nos erreurs rapidement (aka « fail fast ») et d’amorcer en conséquence une réelle démarche d’amélioration continue. Il ne faudra pour cela ne pas baisser les bras trop tôt et se faire aider d’un coach expérimenté. Le coach aidera l’équipe à prendre les décisions les plus adéquates quant à l’adoption de nouvelles pratiques agiles. Il aidera l’équipe, en fonction de son niveau de maturité, à adapter ces pratiques au contexte de l’entreprise.
Pourquoi les adapter ? Simplement parce que chaque contexte culturel d’entreprise induit un existant qui ne peut être balayé par un « magical Scrum » ou un « astonishing XP ». Le TPS ne s’est pas créé en une fois ! Toyota l’a continuellement remis en cause et adapté pour devenir ce qu’il est aujourd’hui.

Ne tirons pas sur le pianiste !

Si un projet rencontre des problèmes avec Scrum, ce n’est probablement pas « la faute à Scrum ». L’équipe est simplement en train de toucher quelques-unes des limites de cette méthode dans son contexte. Fort de ce constat, on pourra choisir d’être de ceux qui montrent du doigt la méthode comme on l’a fait avec RUP il y a maintenant 10 ans. On pourra aussi choisir d’affronter nos difficultés pour saisir humblement l’opportunité de s’améliorer qui s’offre à nous.

3 commentaires sur “La faute à Scrum”

  • Merci hervé pour cet article intéressant et qui remet les choses à leur place notamment sur les effets négatifs qui découlent de l'adoption de plus en plus importante de Scrum sans forcément avoir l'expérience nécessaire pour la mettre correctement en pratique. Tu fais bien de souligner que Scrum est une discipline. Comme on dit souvent, il y a ceux qui font de l'agile et il y a ceux qui sont agiles. Autrement dit, il y a ceux qui applique une recette sans l'avoir comprise/maîtrisée et ceux qui se remette continuellement en question pour toujours s'améliorer.
  • James Shore vient de publier un article développant le même type d'idée de façon très convaincante je trouve. Bonne lecture : http://jamesshore.com/Blog/Kaizen-and-Kaikaku.html
  • Hello Hervé, La question posée par les méthodes agiles est celle de l'évolution ou de la révolution. Est-il possible de réformer en douceur en suivant tes préconisations ? Ou bien faut-il comme James Shore poser des pré requis ("I work with people who want to be great.")? Parce que l'Agile c'est plein de choses mais pas "une autre méthode" JF
    1. Laisser un commentaire

      Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha