Pour le meilleur et pour le pire : Scrum et la planification
À la fois la plus grande force et la plus grande faiblesse de Scrum
This article is also available in English.
La planification est au cœur de Scrum. En Scrum on planifie tout ou presque. Et quand on ne peut pas planifier correctement, alors bien sûr on ne se force pas à faire des plans sur la comète mais par contre on met à jour le plan aussi souvent que nécessaire.
Je suis prêt à parier qu’on peut décrire tout ce qui touche à Scrum en parlant de planification.
- Backlog produit : planifier ce à quoi ressemblera le produit
- Burn-up produit : planifier quand le produit sera prêt
- Planification d’itération : planifier ce qu’on pense voir à la fin de l’itération, mais également planifier comment on va s’y prendre pour y arriver
- Stand-up quotidien : planifier la journée et mettre à jour les plans définis en planification d’itération
- Burn-down d’itération : jauger de la précision des plans définis en planification d’itération, et si nécessaire ajuster aussi bien ces plans que ceux de la journée
- Revue d’itération : passer en revue et mettre à jour les plans concernant aussi bien le périmètre que la date de sortie du produit
- Rétrospective : planifier comment l’équipe pourrait s’améliorer
Admettons que tout dans Scrum tourne autour de la planification. C’est quoi le problème ?
Avant toute chose je tiens à préciser ma pensée : je ne dis pas que c’est une mauvaise chose en soi. Je tiens juste à vous alerter sur le fait que cela puisse être une mauvaise chose.
Scrum commence à se faire vieux. Pour beaucoup de personnes, Scrum a été le point d’entrée dans le monde de l’Agilité. Par ailleurs, l’application de Scrum by the book reste une excellente manière de démarrer une transformation Agile.
Je précise “by the book” parce que bien trop souvent Scrum n’est pas mis en place correctement. Ce qui donne des résultats décevant ainsi que l’idée que Scrum c’est juste comme avant mais avec des noms à la mode. Cette constatation, je l’ai déjà exposée dans le détail dans un précédent article.
En pratique, Scrum est la méthode de gestion de projet Agile la plus populaire, et de loin.
Comment expliquer une telle popularité de Scrum ? Et bien, justement parce que Scrum repose sur la planification.
Un Scrum correctement pratiqué n’a pas grand chose à voir avec le Cycle en V. Cependant, Scrum reste très compatible avec “l’ancienne manière de travailler.”
Par exemple plutôt que de donner une seule date fixe et inamovible pour indiquer la fin du projet, avec Scrum nous allons indiquer une fenêtre de dates plausibles et nous mettrons à jour cette fenêtre lors de chaque revue d’itération. Néanmoins l’idée de base reste la même, à savoir essayer de répondre à la question suivante : “Quand est-ce que ce sera prêt ?”
En quoi cela me dérange-t-il ? Si on y réfléchit un peu, on se rend compte qu’il y a en fait tout un tas d’autres questions intéressantes. Par exemple, pourquoi ne pas plutôt essayer de répondre à cette question : “Comment allons-nous satisfaire le client ?”
La réponse à cette autre question ne se situe pas dans le contenu du backlog produit. Car le plus difficile sera de d’abord trouver comment satisfaire le client. On ne sait tout simplement pas quoi mettre dans le backlog produit, il faut plutôt mettre en place les stratégies qui nous permettront de trouver. Nous sommes dans le domaine du Lean Startup et de Getting Real.
Gardez bien à l’esprit que vous récoltez ce que vous semez. Alors prêtez attention à ce que vous désirez réellement.
Je serais très étonné que la livraison d’un produit arbitraire avant une deadline précise soit réellement ce que vous recherchez.
Scrum est à propos de l’empirisme…
Théorie de Scrum
Scrum se base sur la théorie du contrôle empirique de processus, ou l’empirisme. L’empirisme soutient que les connaissances proviennent de l’expérience et d’une prise de décision basée sur des faits connus. Scrum utilise une approche itérative et incrémentale pour optimiser la prédictibilité et pour contrôler le risque.
Scrum améliore nettement les choses par rapport au Cycle en V parce que tout est fait pour réduire le délai entre feedback et réaction, et parce qu’il embrasse la nature empirique et imprévisible des projets de développement logiciel.
Quoique, est-ce bien le cas ? Est-ce bien embrasser l’imprévisible que de faire tout un tas de planifications pour essayer de prévoir l’imprévisible ?
Hum, la rédaction de cette dernière phrase me fait relire l’extrait du Scrum Guide quelques paragraphes plus haut. Effectivement, Scrum n’a jamais prétendu embrasser l’imprévisible. Ça, je l’ai inventé. Scrum prétend seulement rendre plus gérable l’imprévisible.
Scrum améliore les choses par rapport au Cycle en V grâce au développement itératif. Mais l’état d’esprit fondamental, le mindset, n’est pas si différent.
En fait le but de cet article c’est juste de descendre Scrum, pas vrai ?
Oh que non ! Descendre Scrum n’a jamais été mon but.
Ce que j’essaie de démontrer, c’est que même si Scrum est vraiment super pour démarrer, à un moment donné vous devez prendre du recul et vous demander si Scrum continue de vous aider ou bien si au contraire il vous empêcher de passer au niveau supérieur de maturité.
Par ailleurs, et contrairement aux qualités que semblent lui prêter l’industrie, Scrum n’a jamais été conçu comme une solution universelle, pour toutes les équipes et tous les contextes. Jetons un œil au Scrum Guide à propos des pré-requis de Scrum. Ces pré-requis sont souvent ignorés :
L’Équipe Scrum
L’Équipe Scrum comprend un propriétaire de produit (Product Owner), une Équipe de Développement (Development Team) et un Scrum Master. Les Équipes Scrum (Scrum Teams) sont auto-organisées et pluridisciplinaires. Les équipes auto-organisées choisissent la meilleure façon d’accomplir leur travail, au lieu d’être dirigées par des personnes externes à l’équipe. Les équipes pluridisciplinaires ont toutes les compétences nécessaires pour effectuer le travail sans dépendre de personnes n’appartenant pas à l’équipe. Scrum définit un modèle d’équipe optimisant la flexibilité, la créativité et la productivité.
Autrement dit, les équipes Scrum ont pour vocation d’être des Feature Teams, des équipes qui peuvent gérer complètement des projets de bout en bout, par eux-mêmes et sans aucune dépendance. Énormément de mises en place de “Scrum” ne remplissent purement et simplement pas ce pré-requis de Scrum.
Supposons que vous ne remplissiez pas cette définition canonique d’une Équipe Scrum. Je n’ai rien à redire sur l’utilisation de Scrum comme un outil d’apprentissage. Mais dans ce cas, n’oubliez pas de bien garder en tête que pour vous Scrum n’est qu’un outil d’apprentissage.
L’organisation autour de l’équipe
C’est de là qu’arrivent les vrais difficultés : de l’organisation qui entoure l’équipe, qui interagit avec l’équipe, qui fait des demandes à l’équipe.
À nouveau, Scrum fonctionne très bien au premier abord car le contrat de base entre l’équipe et l’organisation ne change pas significativement. Bien sûr, le Scrum Master et le Product Owner vont éduquer les parties prenantes, les partenaires et les clients. Mais le contrat reste fondamentalement le même : “Quand est-ce que ce sera prêt ?”
Je vous l’accorde, poser cette question et y répondre se feront de manière beaucoup plus saine et transparente avec Scrum. Mais il s’agira toujours de la même question.
En restant avec Scrum, il n’y a pas vraiment d’incitation à changer ce contrat fondamental de “Quand est-ce que ce sera prêt ?” Il n’y a aucune raison d’y toucher.
Voici Kanban : bienvenue dans le monde du pull
Les experts en process aiment bien décrire et comparer Scrum et Kanban en utilisant les termes push et pull.
En Scrum les choses à faire sont poussées à l’équipe et dans ses itérations afin d’obtenir un produit à la fin. On parle de push.
En Kanban l’équipe tire les choses à faire à son propre rythme, résultant en un produit lorsque l’équipe a terminé. On parle de pull.
Une telle différence fondamentale dans l’état d’esprit inverse complètement les comportements et attitudes, aussi bien à l’intérieur qu’à l’extérieur de l’équipe.
En push (Scrum), l’équipe galère à trouver son rythme, en faisant en permanence le grand écart à essayer d’être aussi rapide que possible tout en ne négligeant pas d’autres éléments cruciaux comme la qualité, l’amélioration des outils, la veille. Par contre ce fonctionnement est très commode pour l’organisation.
Plus on pousse de travail à l’équipe et plus de choses en sortent. Quelle différence avec du management à l’ancienne ?
En pull (Kanban), l’équipe trouve très facilement son rythme, puisque le principe même est de dériver le process de fonctionnement à partir de ce rythme.Une organisation habituée à pousser les équipes avec des deadlines aura plus de mal à s’adapter à ce mode de fonctionnement.
Travailler en pull nécessite un changement d’état d’esprit, de mindset, de la part de l’équipe mais aussi de l’organisation.
Comment vous situez-vous par rapport à Scrum ?
Que pensez-vous de la planification en Scrum ? Est-ce une bonne ou une mauvaise chose ? Quelle est votre expérience ?
J’attends vos réponses ! N’hésitez pas à commenter.
Cet article vous a plu ?
Abonnez-vous à mon profil via le bouton Follow pour être notifié des autres articles !
Et n’oubliez pas de cliquer sur le cœur 💗 pour m’encourager, et de partager l’article autour de vous : ce sont ces like qui me font mettre autant de cœur à l’ouvrage.
Merci 😄