Scrum est un FrameWork de gestion d’un projet agile, utlisé par les équipes pour developer, livrer et gérer des produits complexes.
Souvent des gens parlent indistinctement de Scrum et d’Agilité mais comme nous l’avons indiqué dans notre page Agilité Vs FrameWorks, il s’agit de deux choses distinctes. Scrum permet de réaliser des taches et d’apporter une valeur aux clients, alors que l’Agilité est un état d’esprit et des principes de gestion des projets.
l’Agilité est une émancipation culturelle de l’aspect conventionnel de la conduite du projet. Devenir Agile est plus complexe qu’il n’y parait. C’est une nouvelle manière de penser et de projeter la conduite d’un projet. Ceci entant dit vous pouvez utiliser Scrum pour vous aider dans la réalisation d’un projet (monétisation Atlassian_😂) mais aussi pour mener une réflexion sur l’Agilité; comment intégrer les principes de l’Agilité à vos méthodes de travail, de communication.
Scrum peut être utilisé dans plein de domaines, même si on le retrouve généralement dans le domaine du développement et de l’ingénieurie informatique. Des gens du RH, marketing, Design, Recherche Médicale, commencent à comprendre son utilité pour devenir plus efficients (faire le moins d’efforts et erreurs pour aboutir à un résultat).
Il a été le frameworks préféré des équipes de développement pour diverses raisons :
- c’est un complex et une entité vivante.
- il permet de faire évoluer ses objectifs et les moyens d’application
- il accompagne ses changements pour tendre vers l’excellence
Les Artefacts Scrum
Les itérations (séquences) de scrum s’appellent « Sprints » et tous les grands projets sont divisés en plusieurs séquences plus ou moins nombreuses. Attention la taille (longueur de sprint) est très importante pour assurer la réussite des OPÉ !!!!
Les chinois disent : « Chaque grand voyage commence avec un petit pas. » Eh bien les petits pas de chaque voyage chez Scrum s’appellent —Sprint—. En géfrant avec brio chaque petit pas on arrive à mieux circonscrire les projets et ce, quelque soit la taille. On parle de livraison du minimum requis. On ne demande pas à la voiture électrique d’être luxueuse, on veut d’abord savoir si elle roule, et selon l’ordonnancement des besoins on sait ce qui est important ou pas :
- Il faut d’abord qu’elle puisse rouler
- qu’elle a une bonne autonomie
- qu’elle dispose d’une tv en couleurs
- et un frigo
- une liaison satellite.
Vous voyez, dans cette liste, il s’agissait des besoins de notre client au départ, mais dans l’ordonnancement on peut déjà livrer un produit qui roule et si entre temps il n’est pas necessaire d’avoir une TV couleur parce que tout le monde regarde la tv sur le smartphone, alors on évolue dans notre approche et du coup le changement est facile a faire puisque la flexibilité des sprints permet ceci. Comme on fait des petits sprints (itérations, séquences) on peut facilement modifier et adapter les besoins.
Petites sequences, petits risques, modulation et adaptation permanente pour les besoins du client final. En plus le feedback des gens qui testent le produit est une aubaine pour l’équipe (quelque soit le domaine) pour adapter le produit suivant les besoin et accélérer la mise sur le marché du produit. Peu importe de quoi on parle : logiciel, voiture, livre de recettes.
Les réunions régulières de fin de sprint permettent aux équipes d’ajuster en permanence ses objectifs avec les besoin du client et se sentir motivés par les retour positifs des « testeurs » qui rendent le processus de fabrication vivant et surtout gratifiant. Y’a rien de pire que de de travailler en cascade (waterfall) et se rendre compte que tout le travail réalisé ne sert à rien parce que les besoins au départ n’ont rien à voir avec les besoins constatés après 2 ans de travail.
Vous comprenez pourquoi SCRUM s’est imposé comme le framework de prédilection pour de nombreuses équipes de développement produit. Et ce, quelque soit le produit.
[Copyright – M. Cook]
Cérémonies Scrum
Evidement les ayatollahs de l’IT vont vous bombarder avec des jargons pour créer une distance condescendante avec vous et justifier des TJM (jargon😂- si tu trouve pas demande à Perplexity) parfois totalement démesurés. Du coup on va essayer de démystifier les cérémonies (étapes) du frameworks (cadre de travail) Scrum.
- La réunion de sprint // décryptage : déterminer ce que l’équipe sera en mesure de livrer dans le sprint ainsi que la façon dont elle va y parvenir. À la fin de la réunion on doit savoir qui fait quoi. [ on fait une bringue : donc on doit savoir qui ramène la picole, la bouffe, les feux d’artifices etc etc]. Pour être sûr que tout le monde est en accord on organise ca avec les équipes de développement, le Scrum Master et enfin le Product Owner (celui qui a besoin du produit – peu importe le domaine d’activité). | Attention faites demander aux équipe de mimer, esquiver le travail du sprint, genre Patrouille de France, quand ils miment les figures en air de leur exhibitions : « la on fait un back flip et on balance la fumé rouge pendant 18 secondes etc etc. » J’dis ca au cas ou y’a des malins qui viennent après la réunion vous dire que c’est pas possible parce que WIP est trop chargé.