Scrum, pour les Startups (ou pour n'importe quel projet d'ailleurs)

Article original : Scrum, for Startups (or For Any Project for that Matter)

Scrum est un framework léger conçu pour aider les petites équipes soudées à développer des produits complexes.

Bien sûr, Scrum n'est pas applicable uniquement aux projets logiciels, car vous pouvez l'utiliser pour construire un meilleur piège à souris ou vraiment n'importe quoi d'autre. Je l'ai vu utilisé dans chaque partie d'une organisation, même dans les services juridiques et financiers.

Typiquement, une équipe Scrum compte environ 7 personnes, plus ou moins 2. Ainsi, le maximum serait de 9 et les plus petites équipes comptent environ 5 membres. Bien sûr, cela ne fonctionne pas vraiment pour les startups en phase précoce où l'équipe fondatrice peut être composée de seulement 2 ou 3 personnes. Après tout, il peut même s'agir uniquement de vous.

Il existe 3 rôles :

1. Product Owner
2. Scrum Master
3. Membre de l'équipe

Le Product Owner représente l'entreprise et gère la relation entre le produit et l'investissement en temps, ressources et énergie que l'entreprise engage. Le PO veille à ce que le retour sur investissement (ROI) soit maximisé.

Sur le plan tactique, il aide l'équipe à comprendre ce qui est prioritaire et ce qui l'est moins, ce qui peut être plus ou moins précieux à travailler. Son rôle est d'aider à réorienter les ressources, le temps et l'attention. Parfois, mais pas toujours, il peut prioriser les éléments du backlog, mais il est le seul à pouvoir demander à l'équipe de travailler et à pouvoir changer l'ordre du backlog.

Enfin, il aide l'équipe à comprendre les exigences afin de maximiser le temps et les ressources pour produire une efficacité et une efficacité accrues (augmentant ainsi le ROI). Il le fait en créant des user stories qui ressemblent généralement à ceci :

En tant que <type d'utilisateur>, je veux , afin que .

Un Product Owner :

• Développe et maintient la vision du produit
• Représente les intérêts de l'entreprise
• Représente le(s) client(s)
• Possède le backlog
• Ordonne et priorise le backlog du produit
• Crée les critères d'acceptation pour les éléments du backlog
• Est disponible pour aider et répondre aux questions de l'équipe

Le Scrum Master joue le rôle de coach et aide à guider l'équipe vers une meilleure auto-organisation, performance et prise de décision. Pendant que l'équipe se concentre sur la construction du meilleur produit, le SM se concentre sur la construction d'une équipe haute performance.

Les bons SM sont à la fois coach, champion, gardien, facilitateur et, bien sûr, experts en mécanique Scrum. Ils défendent également le produit, l'équipe et les individus au sein de l'équipe.

Ils ne sont pas le patron de qui que ce soit, mais plutôt un pair au sein de l'équipe avec un rôle très distinct. En résumé, ils :

• Sont l'expert et le conseiller Scrum résident
• Sont un coach pour l'équipe
• Éliminent les blocages et les obstacles, et aident l'équipe à continuer d'avancer
• Facilitent le backlog et les autres parties de Scrum

Un Membre de l'équipe a le plus d'autorité dans le système Scrum, car il fait partie d'un groupe auto-organisé de personnes engagées à construire des produits exceptionnels. Il a l'autorité de décider comment le travail doit être fait, quels outils utiliser, quelles techniques déployer et les coûts associés à ces décisions.

La sagesse dominante est que les personnes qui font le travail sont également les meilleures autorités pour savoir comment le faire au mieux.

Une équipe Scrum pleinement fonctionnelle devrait avoir toutes les compétences nécessaires pour construire le produit, ce qui signifie que la plupart, sinon tous les membres de l'équipe, sont des spécialistes à part entière. Mais cela ne signifie pas qu'ils cloisonnent leurs efforts, car l'objectif commun est de livrer un produit fonctionnel à l'entreprise et au client. Cela signifie que les membres de l'équipe travailleront souvent dans d'autres domaines qui peuvent être en dehors de leur spécialité pour accomplir la tâche.

Les équipes haute performance partagent toujours la charge.

Les Membres de l'équipe :

• Sont responsables de la réalisation des user stories pour augmenter progressivement la valeur du produit
• S'auto-organisent pour accomplir tout le travail
• Possèdent et créent les estimations pour le travail
• Possèdent les décisions sur "comment faire le travail"
• Évitent la pensée de spécialiste à l'esprit étroit et considèrent plutôt la performance de l'équipe dans son ensemble au-dessus de la leur

Les Artifacts Scrum sont essentiellement les outils que les praticiens de Scrum utilisent pour créer de grands produits et pour augmenter la visibilité et l'efficacité de la communication.

Le Product Backlog est la liste principale de tous les livrables planifiés et souhaités pour le produit. Cela peut (et devrait) inclure des fonctionnalités, des bugs, de la documentation, de l'assurance qualité, et plus encore, incluant essentiellement tout ce qui est significatif et important à créer pour le produit dans son ensemble.

Certains appellent les éléments du backlog simplement "éléments du backlog" tandis que d'autres équipes peuvent les appeler user stories. Cela dépend des préférences et l'équipe peut décider des termes spécifiques qu'elle souhaite utiliser.

La liste des éléments du backlog ou des user stories est priorisée et ordonnée du plus important au moins important. Les éléments en haut sont également spécifiques, bien compris et peuvent être exécutés rapidement et efficacement. Cela signifie qu'ils sont généralement des petites tâches. Les éléments plus bas dans la liste sont plus ambigus, moins définis et plus larges en portée et en échelle.

Chaque élément du backlog devrait généralement avoir les éléments suivants :

• Quels utilisateurs bénéficieront de l'histoire (pour qui c'est)
• Une brève description de la fonctionnalité souhaitée (ce qui doit être construit)
• La raison pour laquelle cette histoire est précieuse (pourquoi nous devrions le faire)
• Une estimation de la quantité de travail nécessaire pour implémenter l'histoire
• Des critères d'acceptation qui aideront l'équipe à savoir quand elle a été correctement implémentée

Le Sprint Backlog est la liste des tâches à faire pour le sprint de l'équipe. Contrairement au Product Backlog, il a une durée de vie finie : la longueur du sprint convenu. Il inclut toutes les stories auxquelles l'équipe s'est engagée à livrer pendant le sprint et les tâches associées. Les stories sont des livrables et peuvent être considérées comme des unités de valeur.

Les Burn Charts aident l'équipe à comprendre la relation entre le temps et la portée. Les points sont sur l'axe des y tandis que les sprints sont sur l'axe des x. Au fil du temps, on peut voir combien de points restent dans le produit global et la vitesse et le rythme relatifs auxquels l'équipe travaille à travers les points et les sprints. Un graphique Burn Down montre ce qui reste à faire tandis qu'un graphique Burn Up montre combien de portée l'équipe a accomplie sur une période sélectionnée.

Lorsque plus d'éléments sont ajoutés au backlog, on peut voir le nombre de points augmenter par une ligne verticale vers le haut et lorsque des choses sont supprimées, c'est une ligne verticale vers le bas.

Le Task Board représente toutes les tâches de l'équipe de manière visible afin que tout le monde sache ce qui est en cours de travail et par qui. Les tableaux de tâches les plus simples ont trois colonnes :

• À faire
• En cours
• Terminé

Les tâches sont simplement déplacées de gauche à droite à mesure qu'elles sont travaillées et que des progrès sont réalisés. Le Task Board est un rappel visible de la dynamique et des mécaniques de l'équipe en jeu : nous sommes tous dans le même bateau et nous coulerons ou nagerons en tant qu'équipe. Il permet à l'équipe d'inspecter le travail et de s'adapter si nécessaire. D'autres parties prenantes peuvent également voir les progrès et apporter de la valeur.

La manière dont l'équipe définit "Terminé" est également très importante car elle sera différente pour différentes équipes. De plus, si elle n'est pas clairement définie, elle créera de la confusion parmi les différents membres de l'équipe et les parties prenantes, car ils auront leur propre interprétation de ce que "terminé" signifie vraiment.

Par exemple, un développeur de logiciels peut considérer "terminé" lorsqu'il a fini d'écrire son code, tandis qu'une personne de l'entreprise peut considérer la tâche "terminée" lorsqu'elle est prête à être vendue aux clients. Clairement, ce sont deux interprétations très différentes de "terminé" !

Les équipes Scrum efficaces définissent ce que "terminé" signifie et l'appliquent ensuite à leur Task Board et à leurs user stories. C'est ce qui est souvent décrit comme la "Définition de Terminé" et peut être de nature unique ou une combinaison d'éléments. Imprimer la définition et la placer à côté du Task Board est une tactique souvent utilisée pour rappeler à l'équipe ce que cela signifie vraiment.

Le Sprint Cycle se compose de plusieurs réunions, souvent appelées "cérémonies" :

• Sprint Planning
• Daily Scrum
• Story Time
• Sprint Review
• Retrospective

Le Sprint Cycle (ou "Sprint" ou "Itération") est la manière dont vous obtenez du travail accompli : une période fixe de temps où vous travaillez sur de petites parties du produit plus large. L'objectif après chaque sprint est le même : une pièce de logiciel fonctionnelle et démontrable.

Plus une équipe complète efficacement ses sprints, plus le produit est construit rapidement et plus l'entreprise réalise un retour sur investissement élevé. L'équipe décidera, après chaque sprint, si le produit est livrable (c'est-à-dire peut être vendu aux clients).

En général, plus le cycle de sprint est court, plus ils peuvent obtenir de feedback rapidement, ce qui aide à rendre les sprints suivants encore plus efficaces. Cet effet cumulatif ne doit pas être pris à la légère, par l'équipe ou l'entreprise plus large.

Il est très courant pour les équipes d'avoir des cycles de sprint d'une durée de 2 semaines, bien que dans les entreprises en phase précoce, les temps de cycle peuvent être aussi courts qu'une semaine. Lorsque Scrum a été introduit pour la première fois, les cycles étaient d'environ 4 semaines ou un mois.

Pour un sprint d'une semaine, vous aurez généralement les éléments suivants avec une répartition du temps :

• Lundi : Sprint Planning (1-2 heures)
• Mardi : Daily Standup (15 minutes)
• Mercredi : Daily Standup (15 minutes), Story Time (1 heure)
• Jeudi : Daily Standup (15 minutes)
• Vendredi : Daily Standup (15 minutes), Sprint Review (30 minutes), Retrospective (1-2 heures)

Pour le Sprint Planning, l'objectif est que l'équipe s'engage sur un ensemble de livrables pour le sprint et identifie également les tâches nécessaires pour livrer les user stories ou éléments du backlog convenus. Avec l'équipe, le Product Owner présente les stories suggérées à prioriser et l'équipe discute, parfois vigoureusement, de leur position et de leur priorité.

Il est utile de noter la délimitation des rôles, responsabilités et autorités entre le PO et le TM : le Product Owner décide quelles stories seront considérées pour le sprint, tandis que les membres de l'équipe qui font le travail sont ceux qui décident de la quantité de travail qu'ils peuvent raisonnablement prendre en charge.

Dans la deuxième partie de la réunion, l'équipe décide ensuite de la manière dont le travail sera fait, en décomposant les stories convenues en tâches. À mesure que les tâches sont définies, les stories résultantes dans le backlog peuvent changer à mesure que plus d'informations deviennent apparentes et utilisables. Il n'est pas rare qu'une équipe s'engage trop sur le nombre de user stories au début et doive ensuite en retirer certaines à mesure que plus de détails émergent.

Le résultat de cette session de planification est le Sprint Backlog, qui se compose des user stories mentionnées précédemment et des tâches associées résultantes. Le Product Owner peut donner plus de user stories si l'équipe les demande ou a de la place, mais doit être prudent quant à la surcharge de l'équipe.

Le Daily Scrum, ou Daily Standup, est le moment où la plupart des équipes tiennent une réunion rapide près du début de la journée pour partager les éléments suivants :

• Quelles tâches ont été accomplies depuis le dernier Daily Scrum
• Quelles tâches doivent être accomplies d'ici le prochain Daily Scrum
• Quels obstacles ralentissent l'équipe

Chaque membre de l'équipe participe et la réunion doit être précise, spécifique et brève. L'objectif est que tout le monde ait une idée de la progression globale et identifie les problèmes avant qu'ils ne deviennent plus importants. Cela permet à l'équipe d'inspecter activement et de s'adapter aux changements en temps quasi réel. L'objectif est de faire remonter les problèmes, mais pas de créer des solutions pendant le Daily Scrum.

Story Time a lieu en milieu de semaine ou en milieu de Sprint pour discuter de la manière dont l'équipe peut améliorer les stories dans le backlog du produit, qui sont des user stories pour les futurs sprints. Il ne s'agit pas des user stories du sprint actuel.

Le Product Owner définit et affine les critères d'acceptation pour les user stories dans le backlog et également les valeurs de points pour les stories qui n'ont pas encore d'estimation. Cela représente essentiellement une opportunité pour l'équipe de deviner la quantité de travail nécessaire pour réaliser la story.

Toutes les équipes Scrum n'ont pas un Story Time officiel et de nombreuses équipes le font à volonté quotidiennement. Cela dépend simplement de la taille de l'équipe et de leur culture interne de prise de décision.

Le Sprint Review est une déclaration publique que le sprint ou le cycle actuel est terminé et qu'il est temps de montrer le travail qui a été accompli. Les parties prenantes de l'entreprise sont souvent invitées à examiner les progrès également.

Il arrive souvent que toutes les user stories n'aient pas été terminées, donc l'audience doit être clairement informée de ces détails avant la présentation. Les parties prenantes, après examen, auront sans doute des commentaires et des suggestions, et c'est principalement le travail du PO de capturer ces éléments pour examen ultérieur.

Aucune décision ne doit être prise pendant la revue, car celles-ci sont déjà prises lors du Sprint Planning.

La Retrospective est la dernière réunion pour l'équipe afin qu'elle puisse inspecter, adapter et optimiser sa performance toujours améliorée en tant qu'équipe. Contrairement au Sprint Review qui incluait des parties prenantes externes en plus de l'équipe Scrum, cette réunion est uniquement pour l'équipe elle-même.

Les conversations doivent tourner autour de ce qu'ils ont appris pendant le sprint et de la manière dont cet apprentissage peut être appliqué efficacement au prochain sprint afin que le travail puisse être fait plus efficacement et plus efficacement. Et, contrairement aux plus grandes "post-mortems", l'idée ici est de se concentrer sur seulement une poignée de grands changements stratégiques au lieu de créer une liste principale de toutes les choses qui se sont bien ou mal passées.

Inspectez et adaptez toutes les choses ! L'objectif des sprints ou cycles courts est que l'amélioration continue se produise plus rapidement et que tout apprentissage important ne soit pas perdu dans l'éther. Le processus Scrum est conçu spécifiquement pour capturer ces nouveaux apprentissages importants et les appliquer immédiatement dans le système pour amélioration.

Enfin, il est utile de noter que les valeurs et principes du Manifeste Agile ne font pas directement partie du Framework Scrum, mais ont définitivement été utilisés pour informer le Processus Scrum dans son ensemble. Il vaut la peine de les examiner ici.

Histoire aléatoire : J'ai en fait écrit cela pour une startup beaucoup plus ancienne... il y a 6 ans ! Cela est resté dans mes brouillons pendant tout ce temps.

J'ai finalement pris le temps de le parcourir et de le publier. Je suppose que cela prouve, dans une certaine mesure, l'utilité de ce type de framework ou de système à travers plusieurs projets — c'est relativement intemporel ! J'espère qu'il sera utile pour vous aussi !

À propos de moi : Je dirige actuellement le Produit et l'Ingénierie chez YEN, une plateforme d'échange de cryptomonnaies Meta et une plateforme sociale, où nous appliquons encore libéralement ces idées.