Lorsque l’on effectue un passage à l’échelle, des question se posent :
- Faut-il faire des équipes ‘composants’ ou des équipes ‘features’ ou des éuipes ‘produits’
- Comment organiser les équipes qui travaillent sur plusieurs produits ? Faut-il les séparer, les laisser ensemble, etc
Ici, un comparatif est proposé pour aider à faire un choix.
| 1 grandes équipes | Equipes par produit | Equipe composant | Equipe Feature | Mix composant / Feature | Mix Produit / Composant | |
|---|---|---|---|---|---|---|
| Concept / Idée | L’équipe vit au quotidien ensemble et travaille à partir d’un backlog produit unique. Toute l’équipe suit les mêmes règles. | Plusieurs équipes travaillent sur des lignes de produit distinctes. Les équipes ont des rythmes, des règles différentes, ainsi qu’un backlog de produit séparé. | Des équipes sont responsables d’un ou plusieurs composants techniques. Chaque équipe à son backlog contenant des story technique avec un système de suivi ‘macro’ pour suivre les besoins ‘fonctionnelles’. C’est l’ensemble des développements des équipes composant qui apportent de la valeur au produit. | Ici, on suppose que les équipes travaillent sur un même produit et même base de code. Le backlog est métier et chaque équipe décide des story qu’elle va traiter dans son sprint. La feature team est capable de livrer une fonctionnalité de A à Z. | Il est possible d’avoir un mix d’équipe feature /component dans l’organisation. L’équipe feature est autonome pour produire une valeur d’ une story fonctionnelle. L’équipe composant, elle, est experte sur son composant. | C’est une déclinaison du mix composant / Feature où l’équipe feature est splitté par produit (si l’équipe gère des produits différents) |
| Exemple de fonctionnement | L’équipe est considérée comme l’équipe Scrum. La planification, les daily, les revues et rétros sont réalisées tous ensemble. Il y a un backlog produit qui comporte une majorité de story ‘fonctionnelles’. | Des lignes de produits sont explicites. Les produits ont des backlog séparés. Les backlog produit comporte une majorité de story ‘fonctionnelles’. Les 2 équipes ont leur propre rythme mais avec la possibilité d’avoir une planification et une revue de sprint communes. | Des équipes composants sont définies. Ces équipes sont réalisées en précisant les composants dont les équipes sont responsables. C’est l’équipe en charge du composant qui le maintien et le fait évoluer. Les backlogs sont techniques. Un planning en forme de roadmap permet de suivre les travaux de chaque équipe et de les synchroniser pour libérer la valeur utilisateur. Les événements sont séparés. Certains événements peuvent être communs (comme la planification) En fonction des tailles d’équipe, il peut y avoir autant de Product Owner que d’équipe composant. | Les équipes sont pluridisciplinaires et créés avec des compétences ‘symétriques’. Il y a un backlog produit qui comporte une majorité de story ‘fonctionnelles’. Les équipes décident des story qu’elles embarquent dans leur sprint. Des communautés de pratiques sont créés pour partager les bonnes pratiques. En effet, les équipes vont coder de façon indépendante dans la même base de code. Les planifications sont communes, les daily et les rétro sont séparés. Les revues sont communes. De temps en temps, une rétro commune peut être réalisée. | Une équipe est orienté ‘feature’ et une équipe se concentre sur un composant précis. Il existe 2 backlog distincts. L’équipe ‘feature’ sous traite les évolutions liés à un composant. Les planifications et revue de sprint sont communes, les daily et les rétros sont séparés. Des rétro avec tout le monde sont réalisés de temps en temps. | Il existe plusieurs backlog : Un par produit et un pour le composant. |
| + / – | Les événements ayant de nombreux participants, ils ne sont pas fluides Difficulté pour synchroniser les personnes Le consensus difficile à avoir | Les produits peuvent évoluer de façon indépendante et de façon homogène Les priorités de l’organisation ne sont pas traitées par ordre de priorité mais par produit Synchronisation entre les produits lors de feature impactant la même base de code | Le composant aura moins de dette technique dû à une Expertise plus grande sur un composant technique, langage, etc Synchronisation compliquée pour une fonctionnalité Les délais de livraison sont allongés pour une fonctionnalité car traverse plusieurs équipes Le suivi de l’avancement d’une feature | Le backlog Produit est dépilé dans le sens des priorités du système Demande des compétences doublées dans les deux équipes pour terminer une story fonctionnelle. Demande des communautés de bonnes pratiques entre les développeurs d’équipe différente codant dans les mêmes composants. | On peut traiter les élements du backlog dans l’ordre de priorité du système. Une expertise ponctuelle sur une partie de composant est créée. Synchronisation en cas de feature traversante un des composants de l’équipe composant. Latence de livraison si l’équipe composant ne peut pas traiter la demande de l’équipe feature L’équipe composant ne travaille pas forcément sur les priorités de l’organisation | Même avantages / inconvénients que le mix composant / Feature |
| Efficacité pour produire de la valeur | = | = | — | + | = | + |
| Facilité de mise en oeuvre | + | – | – | – | = | = |
Crédits : Photo by Stillness InMotion on Unsplash
scrumontherocks.wordpress.com 