En savoir un peu plus sur le framework Agile Scrum

Scrum est le framework de référence en Agile, car il est un peu la concrétisation de plusieurs pratiques Agile réunies dans un seul framework. D’autant plus que c’est le premier Framework à se démocratiser. Il a longtemps été utilisé en startup avant de gagner ses lettres de noblesse. En effet, il a fallu quelques années avant qu’il ne soit adopté en entreprise, jusque- là essentiellement exploité par la fintech. 

Bien souvent, lorsqu’une entreprise qui est en recherche d’innovation ou de gain de visibilité sur ses projets, Scrum s’inscrit naturellement comme le choix à faire, puisqu’il a une longue expérience et pratique. Aujourd’hui encore, il reste l’un des frameworks Agile parmi  les plus populaires, car il se concentre sur une seule et même équipe, parfois multidisciplinaire (cf. Lean Startup), d’environ 10 personnes. Il existe plusieurs frameworks Agile à l’échelle qui s’inspire de Scrum, dont le fameux Safe. Mais, penchons nous d’abord sur le Framework.

Pour en savoir un peu plus sur l’histoire de Scrum, je vous invite à aller voir sur Wikipedia.

La raison de ce succès?

Il existe plusieurs raison à cela

• Visibilité de l’avancement du projet,
  • Des cycles cours de 1 à 4 semaines (Sprint),
    • Généralement, on recommande 2 semaines,
      • Donc à définir ensemble.
• Des tâches orienté Business,
  • Défini par le Product Owner (le client),
  • Estimé par les développeurs et validé par l’équipe de développement.
• Le client, le Product Owner, est impliqué dans le projet,
  • Il a donc la visibilité du produit,
  • Il connaît donc le produit!!!
    • Donc pas de surprise d’un tiers qui pense avoir compris le besoin du client et qui nous fait faire autre chose, comme construire des immeubles sur la lune.
  • Idéalement, c’est lui qui présente le produit à la fin du sprint,
• Des réunions régulières,
  • Un point en journée pour avoir la visibilité sur les tâches et les difficultés (Daily Scrum),
    • Généralement le matin, à un moment où toute l’équipe est au complet.
• L’équipe, incluant le Product Owner, est impliqué et responsable du produit,
  • Donc, plus patate chaude à s’envoyer les uns sur les autres,
    • Car l’équipe inclut le client.
• Autonomie de l’équipe,
• Le scrum Master fait office de pare feu,
  • Laissant les équipes se concentrer sur leur sprint.
• DOR (Definition of Ready) et DOD (Definition of Done),
  • DOR : Des règles du jeu qui clarifie d’entrée de jeu avant la mise à disposition de la tâche,
  • DOD : Des règles de sortie pour valider une tâche qualifiée comme fini.
• Il n’y a pas de hiérarchie,
  • C’est agréable de travailler sans que quelqu’un nous courre derrière,
  • L’équipe est autonome !

Le framework Scrum est d’une souplesse incroyable, il a un temps de réaction bien meilleur que le vieux croulant cycle en V qui est long à mettre en marche et qu’au moindre changement, il faut redéfinir un nouveau cahier des charges, qui est déjà très lourd et qui s’alourdit encore plus, mais aussi, sans oublier de renégocier les contrats commerciaux, les impacts financier et risque de projet. Scrum permet facilement d’intégrer de nouvelles tâches dans son Backlog Produit. Mais, attention à ne pas charger la mule non plus et de garder surtout en tête l’objectif final. Être Agile, c’est avant tout une attitude et un esprit. Lorsqu’on ajoute une tâche dans le Backlog du Sprint, on sort une tâche équivalente de même poids, sans quoi le projet risque de prendre feu.

Scrum se compose souvent de dix personnes, dont:

• Un Scrum Master (Obligatoire),
  • Facilitateur,
  • Son rôle est de protéger l’équipe et s’assurer que le cadre Scrum est respecté.
• Le Product Owner (Obligatoire),
  • C’est celui qui connait le produit.
• Les développeurs (Obligatoire),
  • Front (html, css, ajax, …),
  • Back (Php, ruby, java, …),
  • Lead tech or architecte.
• Les designers (Fortement conseillé),
  • UX (L’expérience utilisateur),
  • UI (L’expérience graphique).
• Autres (Bonus)

Dans un projet réel:

• Il arrive très souvent que le le Product Owner ne connaît pas du tout le framework Agile,
  • C’est aussi le cas des jeunes équipes en Agile,
  • N’hésitez pas à faire un atelier pour amorcer le projet,
    • Cela évitera de perdre beaucoup de temps après.
  • Accompagner le Product Owner sur les épics et les premières User Stories
• Par expérience, les sprint de 2 semaines sont les plus intéressants.

Concrètement, Scrum en quelques mots:

• Le product Owner produit en continue un Backlog Produit,
  • Il sélectionne des tâches à faire,
  • L’équipe ou au moins 2 membres de l’équipe (Lead technique + Product Owner) prépare le Backlog Refinement (La séance avant le Poker planning) et les valide avant de présenter le Backlog du sprint,
  • L’équipe estime l’effort des tâches du Backlog du sprint (Poker Planning)
    • Souvent, il y a des négociations et des défis sur certaines tâches,
    • Donc des tâches entrantes ou sortantes.
• Le Sprint se déroule sur 2 semaines par exemples,
  • Avec des mêlés quotidiennement de suivi(Le daily Scrum),
  • Livraison d’un livrable,
    • Présentation du livrable par le Product Owner au stakeholder qui est bien souvent le chef ou la direction du Product Owner.
  • L’équipe fait un feedback,
    • C’est l’occasion de sortir les serious game pour cette séance,
      • Pour discuter des problème,
      • Comprendre et trouver des solutions pour s’améliorer.
    • À la fin de la séance, l’objectif est d’avoir des actions à prendre.

Quand on débute en tant que jeune Scrum Master, on est souvent vite débordé ; on manque d’expérience et personne n’est là pour nous soutenir. Je vous fais donc une petite liste non exhaustive des pièges à éviter ou des conseils à prendre :

• Une ligne directrice doit être défini pour le projet ou le sprint:
  • Partez avec une base solide d’un but bien défini en définissant un MVP (Minimum Viable Product),
    • Sans quoi c’est la porte ouverte à toutes les idées et on perd le but principal.
  • Des épics clairs et concises,
    • Prenez le temps nécessaire pour aborder ce travail avec le Product Owner et un Leadtech.

• Attention à ne pas mettre une personne lambda en tant que Product Owner,
  • Demander une personne qui connaît bien le produit, sans quoi vous risquez d’avoir une girouette,
    • Ce qui aura des conséquences et impacts sur le projet et l’équipe.
• Ne pensez pas que tout le monde maîtrise Scrum,
  • Rappeler le framework Scrum, évite d’avoir des surprises, même si la personne a une certification Scrum,
    • La certification n’est qu’un papier que n’importe qui peut obtenir en suivant une formation sur 2 jours.
• Prenez régulièrement la température de l’équipe et du projet,
  • Cela évite d’avoir d’éventuelle tension,
  • De remotiver l’équipe si nécessaire,
  • De voir si le projet est en phase avec le besoin du client, …
• Ne pas laisser le Product s’emballer;
  • Souvent, un client va vouloir tout faire tout de suite.
• Ne pas laisser la place au laisser aller,
  • Souvent les gens oublie de mettre à jour leurs tâches, invoquant le manque de temps,
    • La conséquence c’est que l’on n’a pas de visibilité.
  • Le Product Owner est souvent déborder, particulièrement s’il n’est pas habituer à travailler en Agile,
    • Ne pas hésiter à discuter avec lui, que ce soit Développeur ou Scrum Master.
• Ne surtout pas laisser les tensions prendre,
  • Au moindre problème, il vaut mieux en discuter que laisser le problème exploser dans le futur,
    • Il est plus facile de désamorcer une mine qu’une dispute mineure.
• Que le projet est cohérent,
  • Sans quoi ca sera toujours le feu dans la forêt,
  • Ne jamais surcharger la mule,
    • On épuise vite les équipes,
    • On se laisse déborder par les demandes du Product Owner,
    • Le Scrum Master doit être là pour recadrer les choses et si besoin en discuter avec le stakeholder.
• Une tâche trop grosse,
  • C’est le début de l’effet tunnel,
    • Penser tout de suite à la découper en plusieurs tâches.
• Les briques techniques
  • Souvent quand on démarre un projet from scratch, aucune brique technique n’est construite,
  • La pire des situations c’est de n’avoir aucune validation du côté client,
    • C’est l’échec assuré si les décisions ne sont pas prises en amont
      • ex: définition du langage de programmation, du framework, des API, des outils tiers (CRM, …).
    • Si malgré cela vous engager le projet,
      • Alors il faut parler du risque, communiquer et négocier le temps nécessaire pour mettre en place les briques techniques,
        • Surtout dans le cas de projet avec le Service public ou les décisions peuvent prendre des mois.
• S’assurer que l’équipe est homogène,
  • Un manque d’expérience dans l’équipe peut être la source d’un échec,
  • Avoir un bon lead technique ou un Architecte, voir les 2,
  • Ca évitera des surprises lorsque vous allez vous trouver dans une impasse.
• Ne jamais laisser le Product Owner changer le Backlog Produit quand il a été validé,
  • Sous réserve de se retrouver à multiplier le travail,
  • Des problèmes d’incohérence,
  • Perturbation de l’ensemble de l’équipe.
• Comprendre qu’un sprint = une livraison
  • Mais pas forcément l’ensemble du backlog du sprint,
    • Il arrive qu’il y ait des soucis techniques, un manque d’information côté client, des incertitudes, …
    • Dans ce cas, il faut en parler et négocier avec le Product Owner qui devra communiquer auprès du stakeholder.

Aujourd’hui, les équipes Scrum sont de plus en plus pluridisciplinaires. Auparavant, on ne parlait que d’équipe technique, mais aujourd’hui on parle de plus en plus Squad, lorsqu’il y a plusieurs équipes Agile. Lean startup est l’un des premiers à mettre en avant l’équipe pluridisciplinaire. C’est pourquoi, on implante de plus en plus la Digital Factory dans l’entreprise.