Guide de mêlée | 16. Mise à l'échelle de Scrum

L'équipe Scrum doit être composée d'un maximum de dix personnes. Mais que faire lorsqu'un plus grand groupe de spécialistes doit travailler sur un projet ? Ou si l'organisation décide de suivre un mode de gestion agile ? Pour résoudre ce problème, les développeurs Scrum ont proposé [email protected] C'est une architecture sans échelle pour organiser des équipes entières selon les principes Scrum.

Scaling Scrum – table des matières :

1. Introduction
2. [courriel protégé]
3. Le Scrum des Scrums
4. Autres problèmes de mise à l'échelle et [email protected]
5. Sommaire

Introduction

Dès qu'une organisation grandit, de nouveaux types de problèmes apparaissent. Par exemple, une baisse de l'efficacité des employés causée par une structure interne complexe, une prise de décision ou une orientation difficiles. Les entreprises opérant de manière agile au niveau d'une petite équipe de projet cherchent souvent à évoluer.

De nombreuses entreprises réussissent sans mettre à l'échelle Scrum. Même si de nombreuses équipes Scrum fonctionnent simultanément, elles n'ont pas besoin de coordination car les groupes fonctionnent indépendamment. Cependant, cela ne signifie pas qu'il s'agit d'un Scrum multi-équipes. Le besoin de mise à l'échelle ne survient que lorsque la majeure partie de l'organisation travaille sur un produit et peut synchroniser efficacement ses multiples équipes Scrum.

La plupart des organisations qui adoptent des méthodes de gestion agiles à grande échelle choisissent le modèle SAFE, ou Scaled Agile Framework. Aujourd'hui, cependant, nous ne nous concentrerons pas sur SAFE mais nous discuterons d'un modèle différent appelé [email protected] , car selon le 15e rapport State of Agile de 2021, c'est le deuxième meilleur choix parmi les entreprises qui optent pour agile.

[courriel protégé]

En 1996, les créateurs de Scrum, Jeff Sutherland et Ken Schwaber, travaillaient sur un grand projet. Pendant qu'ils le faisaient, ils avaient du mal à synchroniser les petites équipes travaillant dans Scrum. Ils ont trouvé un moyen de le mettre à l'échelle, qu'ils ont finalement appelé [email protected]

Le guide [email protected] est analogue au guide Scrum officiel, qui définit cette façon de faire évoluer le travail comme :

Un cadre dans lequel les réseaux d'équipes Scrum opèrent en suivant le guide Scrum pour résoudre des problèmes adaptatifs complexes et fournir de manière créative des produits avec autant de valeur que possible.

Le principe de base de [email protected] est la simplicité et l'efficacité. Par conséquent, son fonctionnement est basé sur une architecture sans échelle. En d'autres termes, il utilise Scrum pour faire évoluer Scrum. Ainsi, une équipe Scrum composée d'individus agissant en tant que Product Owner, Scrum Master ou Developer devient le Scrum de Scrums : une équipe composée d'équipes.

Le Scrum des Scrums

Le Scrum de Scrums est une équipe Scrum composée de personnes assumant des rôles Scrum traditionnels. Cependant, étant donné que la tâche de Scrum of Scrums est d'intégrer les résultats du travail de plusieurs équipes Scrum, il a besoin de postes supplémentaires :

• Product Owner Team – un groupe de Product Owners qui se réunissent pour convenir des priorités et créer une vision cohérente du produit
• Chief Product Owner - Product Owner de l'équipe Scrum ou une personne qui s'occupe exclusivement du Scrum de Scrums
• Scrum of Scrums Master – la personne qui supervise l'efficacité du Scrum of Scrums.

Ils se réunissent lors des mêmes événements Scrum et utilisent des artefacts similaires.

Autres problèmes de mise à l'échelle et [email protected]

L'architecture sans échelle de [email protected] signifie qu'elle permet une mise à l'échelle plus d'une fois. Si une organisation a besoin de coordonner des équipes à une échelle encore plus grande, elle peut mettre en place Scrum of Scrums.

Cependant, la mise à l'échelle de Scrum, comme toute autre méthodologie de gestion, a ses défauts, et dans ce cas, ils sont similaires à ceux des équipes Scrum de base, sauf qu'ils sont proportionnellement plus grands. C'est pourquoi nous recommandons de définir les détails de la collaboration au sein de chaque équipe Scrum avant de lancer Scrum à plus grande échelle. Nous suggérons de faire évoluer Scrum pour les équipes expérimentées qui ont une bonne connaissance et compréhension des valeurs et du fonctionnement de Scrum.

Scaling Scrum – résumé

Scaling Scrum n'est pas un jeu d'enfant. Cela nécessite que les équipes Scrum appliquent avec compétence les principes Scrum et synchronisent leurs tâches avec les autres équipes Scrum. Par conséquent, la question fondamentale à laquelle il faut répondre est la suivante : une mise à l' échelle est-elle nécessaire ? Ce n'est pas parce qu'il existe de nombreuses équipes Scrum dans une organisation que leur coordination apportera automatiquement de meilleurs résultats.

Si une organisation choisit d'augmenter Scrum, elle obtient une architecture sans échelle qui peut être encore augmentée avec succès. Cependant, chaque augmentation s'accompagne d'une augmentation du niveau de complexité auquel l'équipe Product Owner, le Chief Product Owner et le Scrum of Scrums Master doivent faire face.

Si vous aimez notre contenu, rejoignez notre communauté d'abeilles occupées sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Auteur : Caroline Becker

En tant que chef de projet, Caroline est experte dans la recherche de nouvelles méthodes pour concevoir les meilleurs flux de travail et optimiser les processus. Ses compétences organisationnelles et sa capacité à travailler sous la pression du temps font d'elle la meilleure personne pour concrétiser des projets complexes.

Afficher tous les articles

Guide de mêlée :

1. Glossaire des termes, rôles et notions de base
2. Qu'est-ce que Scrum ?
3. Valeurs Scrum
4. Comment implémenter Scrum dans votre entreprise ?
5. Scrum Team - qu'est-ce que c'est et comment ça marche ?
6. Qui est un Product Owner ?
7. Les erreurs les plus courantes du Product Owner
8. Qui est le Scrum Master ?
9. Caractéristiques d'un bon Scrum Master
10. Les erreurs les plus courantes du Scrum Master
11. Quelles statistiques et métriques le Scrum Master doit-il suivre ?
12. Coopération entre Product Owner et Scrum Master
13. Équipe de développement dans Scrum
14. Les erreurs les plus courantes des développeurs
15. Artefacts Scrum
16. Mise à l'échelle Scrum
17. Carnet de sprint
18. Qu'est-ce que le carnet de produit ?
19. Qu'est-ce qu'une User Story ?
20. Créer la meilleure User Story avec INVEST
21. Les erreurs les plus courantes de la User Story
22. Critères d'acceptation des user stories
23. Estimation et Story Points dans Scrum
24. Planification Poker
25. Jeu d'estimation d'équipe
26. Définition de l'incrément
27. Événements Scrum
28. Qu'est-ce que Sprint dans Scrum ?
29. Engagements de l'équipe Scrum - Objectif du produit, objectif du sprint et définition de l'achèvement
30. Qu'est-ce qu'un Burndown Chart ?
31. Comment créer et interpréter un burndown chart ?
32. Avantages et inconvénients du burndown chart
33. Tableaux Kanban dans Scrum et Scrumban
34. Velocity in Scrum - Vitesse de l'équipe de développement
35. Mêlée quotidienne
36. Planification des sprints
37. Revue de sprint
38. Qu'est-ce qu'une rétrospective Sprint ?
39. Erreurs courantes lors d'une rétrospective de sprint
40. Nourrir le backlog produit