Scrum à plus grande échelle Scrum à l’échelle:Scrum à plus grande échelle

Dans certains cas, l’organisation peut être amenée à considérer que même avec trois équipes, le produit n’est pas délivré suffisamment rapidement. Pourtant, en ajouter une quatrième (+33 %) n’accroît généralement la vélocité globale que de 15 %. La valeur ajoutée de l’équipe supplémentaire est alors très faible. Le rendement n’est que d’environ 50 %.

De prime abord, il semblerait plus simple de découper un gros produit en sous-produits indépendants et moins complexes. Cela permettrait d’assigner plusieurs Product Owners à plusieurs produits et d’avoir un rendement optimal sur les ressources investies. L’inconvénient, c’est que cette approche complexifie la maintenance globale du SI, qui la plupart du temps est déjà très difficile à cartographier.

Face aux nouveaux et nombreux problèmes que le Product Owner aura à gérer, il ne faut passer à plus grande échelle que s’il n’existe pas d’alternative. Si le Product Owner mesure que la performance baisse tandis qu’une équipe a été ajoutée, alors il faut immédiatement revenir en arrière et chercher une autre solution.

En effet, passer à plus grande...

Pour consulter la suite, découvrez le livre suivant :
couv_CEPROWN.png
60-signet.svg
En version papier
20-ecran_lettre.svg
En version numérique
41-logo_abonnement.svg
En illimité avec l'abonnement ENI
130-boutique.svg
Sur la boutique officielle ENI
Précédent
Scrum avec deux ou trois équipes
Suivant
Organisation du Backlog de produit