Scrum est un cadre méthodologique ouvert. Leurs créateurs ont su rester à l'écoute des praticiens experts du monde entier pour faire évoluer Scrum en fonction des retours d'expérience de ces derniers. Aujourd'hui, il existe même un formulaire pour soumettre des propositions de modification du guide Scrum. S'intéresser à ces évolutions de Scrum permet de mieux comprendre certains de ses aspects, certaines de ses subtilités et ce qui fait son identité actuelle.
Les évolutions de 2011
La fin des poulets et des cochons
On a longtemps utilisé la métaphore des poulets et des cochons pour distinguer les niveaux d'engagement des acteurs et les règles du jeu associées. Pour rappel ou précision, cette métaphore partait de l'histoire du poulet qui propose au cochon d'ouvrir un restaurant et de l'appeler "jambon et œufs" et le cochon de répondre "non merci, je serai engagé alors que tu seras seulement impliqué (le poulet à juste des œufs à donner alors que le cochon...)". Cette métaphore servait à illustrer le fait que l'équipe Scrum ayant un niveau d'engagement plus fort que des parties prenantes, elle doit avoir un pouvoir de décision et d'auto-organisation plus important.
Seulement voilà, le recours à cette métaphore pouvait fonctionner à l'époque où Scrum était peu connu. Mais entre temps, l'utilisation de Scrum s'est étendu aux grandes entreprises "sérieuses". Difficile donc de parler de poulets et de cochons dans ces conditions. D'autre part, Scrum cherche à favoriser la collaboration de toutes les parties prenantes et catégoriser ainsi les individus ne va forcément dans ce sens.
D'où la disparition des poulets et des cochons du guide officiel Scrum.
Ordonnancer le Product Backlog plutôt que le prioriser
Trier les éléments du Product Backlog par priorité est une technique parmi d'autres. Je me souviens qu'une de mes premières mise en pratique à ce sujet avait consisté à calculer le coefficient "valeur ajoutée/coût-complexité" et à trier les éléments dans un tableur du plus grand au plus petit coefficient. Je me suis vite rendu compte des limites de cette technique. Au mieux, elle permet de dégrossir le travail. Le Product Owner a donc un travail d'analyse (de dépendance par exemple) et de décisions à faire pour ordonner correctement le Product Backlog. D'où le changement de vocabulaire.
Le nouveau Sprint Backlog
L'ancienne version du guide officiel Scrum avait tendance à trop "normer" le Sprint Backlog, laissant peu de souplesse et peu de place à la créativité. La nouvelle définition du Sprint Backlog y remédie en permettant de mieux s'adapter au contexte de chacun.
Disparition de la planification de release (ou version) et du release burndown chart
Cette évolution peu surprendre voire choquer, mais vous allez voir que l'explication tient la route (selon moi en tout cas). Si on se replonge dans le manifeste Agile, le premier principe nous dit "Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.". Or l'utilisation de release va plutôt dans le sens d'une livraison tardive du produit (après plusieurs sprints). Alors qu'une bonne utilisation des pratiques de développement peut permettre une livraison à chaque sprint. Je pense même que le succès grandissant des approches Kanban et de livraison continue ne sont pas sans lien avec ce changement. Avec de telles approches, la notion même d'itération/sprint est remise en question.
Quoiqu'il en soit, la planification de release ou version et l'utilisation du release burndow chart ne sont pas de mauvaises pratiques pour autant et prennent tout leur sens dans certains contextes. Notamment, lorsque le rythme de livraison aux utilisateurs doit rester raisonnable.
Disparition de la notion d'engagement
Voilà une évolution qui a fait et fait encore débat.
Voici mon point de vue sur la question. L’équipe de développement ne peut porter seule l’engagement de terminer les éléments du sprint backlog d’ici la fin de ce dernier. En raison notamment de la part d’inconnus fonctionnels, techniques ou autres (ex : indisponibilité du Product Owner, interruptions, absence imprévue d’un membre de l’équipe) qui persiste. Il ne s’agit donc pas de prendre un engagement sans être sûr de pouvoir le tenir. D’autre part, prendre un engagement implique des effets négatifs en cas d’échec, en particulier sur la qualité, la motivation, la fiabilité des estimations et la capacité de l’organisation toute entière à tirer des leçons de cet échec. Si engagement il y a, il doit donc être collectif impliquant non seulement l’équipe de développement mais également le Product Owner, le métier et le management. L’équipe de développement seule, prend toutefois un engagement : se focaliser sur l’objectif du sprint (qui répond au “Pourquoi” on fait cette itération), prévenir au plus tôt le Product Owner si la tenue de cet objectif est en péril, livrer des fonctionnalités utilisables en fin d’itération et s’améliorer sans cesse.
Les évolutions de 2013
Renforcement de la notion de transparence
La notion de transparence a été particulièrement renforcée dans le guide avec un paragraphe dédié. L'objectif étant de favoriser la transparence en soulignant le fait que sans transparence, de mauvaises décisions peuvent être prises.
Les artefacts (Product Backlog, Sprint Backlog et Incrément notamment) doivent donc être visibles et compris de tous de la même façon.
La planification monobloc et l'objectif de sprint
Cette évolution met fin à la séparation en deux phases de la planification de sprint laissant ainsi plus de liberté et de créativité aux praticiens de Scrum. Cette séparation avait peu d’intérêt et qui sait, pouvait même être néfaste dans certains contextes. Par exemple dans le cas d'une collaboration pleine et entière entre le Product Owner et l'équipe de développement. En effet, dans ce cas là, pourquoi séparer les "quoi" du "comment" dans le temps et les acteurs avec ?
L'objectif de sprint quant à lui est clarifié et favorise ainsi la canalisation du travail de l'équipe de développement et le travail (esprit) d'équipe. Cet objectif peu consister à réaliser une fonction donnant une cohérence d'ensemble du sprint ou tout autre cohérence invitant l'équipe de développement à travailler ensemble plutôt que sur la base d'initiatives personnelles. Pour rappel, l'objectif de sprint donne une certaine flexibilité à l'équipe de développement sur la façon d'implémenter la fonctionnalité au cours du sprint (sur le "comment" donc).
"Affinage" du Product Backlog et notion de "prêt"
En anglais le terme "Grooming" (qui ne convenait pas aux anglais et était peut être un peu trop argotique) est remplacé par le terme plus heureux de "Refinement" (affinage). Le tout pour décrire l'activité d'affinage du Product Backlog permettant de rendre se dernier "prêt" pour la planification de sprint. C'est donc également l'occasion d'insister sur cette notion de "prêt" consistant a avoir en entrée de planification de sprint suffisamment d'éléments clairs (avec peu d'inconnus), fins (réalisables dans le sprint) et correctement estimés.
Assouplissement des timebox des événements
Le guide continue à donner une durée maximale pour les événements Scrum. Comme par exemple les 8 heures pour la planification d'un sprint de 4 semaines. Il normalise cependant moins ces durées pour les sprints plus courts. L'ancienne version nous orientait sur des durées maximales inférieurement proportionnelle (ex : 4 heures pour des sprints de 2 semaines).
L'intérêt est de cet assouplissement est de laisser libre court à des initiatives visant par exemple à réduire davantage la durée maximale d'une planification de sprint en s'obligeant à affiner davantage le Product Backlog en amont. Il est clair qu'une planification de sprint est beaucoup moins laborieuse lorsque qu'on se pose peu de questions. Et celle ci se termine lorsque les questions ont trouvé leurs réponses et que l'objectif du sprint est clair. On favorise ainsi une bonne pratique tout en offrant davantage de souplesse afin de s'adapter au contexte de chacun.
Modification des questions de la mêlée quotidienne
Les questions de la mêlée quotidienne sont passé de :
- Qu'est que j'ai réalisé (ou terminé) depuis la dernière mêlée ?
- Qu'est ce que je compte réaliser (ou terminer) d'ici la prochaine mêlée ?
- Quels obstacles je rencontre ?
à :
- Qu'est ce que j'ai fait hier qui a aidé l'équipe de développement à atteindre l'objectif du sprint ?
- Qu'est ce que je vais faire aujourd'hui qui va aider l'équipe de développement à atteindre l'objectif du sprint ?
- Est ce que je vois un obstacle qui risque de m'empêcher ou d'empêcher l'équipe de développement d'atteindre l'objectif du sprint ?
Ce changement permet de renforcer la concentration de l'équipe sur l'objectif (commun) du sprint et de mettre l'accent sur le travail d'équipe. Il vise donc à modifier positivement la dynamique de groupe.
Renforcement de la notion de valeur
La notion d'apport de valeur a été renforcé un peu partout dans le guide.
Principale source
Voici ci dessous la vidéo (en anglais) dans laquelle Jeff Sutherland et Ken Schwaber (les créateurs de Scrum) expliquent les évolutions apportées en 2013. Ils commencent par un bilan de l'évolution de Scrum et rappellent deux événements majeurs en faveur de l'agilité. A savoir, le Gartner qui exhorte les organisations à abandonner le cycle en V au profit de l'agilité et même discours du Standish Group dont les dernières statistiques sont sans appel : seulement 14% des projets réalisés en Cycle en V réussissent (délais respecté, budget respecté et utilisateurs satisfaits) contre 42% (soit 3 fois plus) pour les projets menés en approche Agile.
D'après moi, ce second chiffre est amené à augmenter avec la maîtrise grandissante des principes et pratiques agile et l'évolution culturelle. Scrum est simple mais difficile 😉
Merci pour ce résumé très intéressant. J’aime beaucoup la notion de « pret » pour la User story. Ne faudrait-il pas l’étendre aux Features également?
Concernant le daily orienté équipe, nous avons essayé de faire le daily user story par user story au lieu de personne par personne et ça marche assez bien, ça permet à l’équipe d’avoir une bonne vision de l’avancement des stories. Sincèrement je le conseille
Bonjour et merci pour ce partage de recette.
Effectivement, c’est une bonne idée de mener la mêlée par les user stories. C’est une autre bonne façon de favoriser le travail d’équipe et la canalisation de ce travail (« une brique après l’autre »).
En effet, on peut étendre la définition de « prêt » aux features. Ça permet de renforcer la cohérence d’ensemble. En général un bon objectif de sprint garantit cette cohérence, autrement dit, on est censé prendre dans le sprint une ou des features prêtes et éventuellement quelques User Stories supplémentaires de « remplissage ».