Scrum structure les équipes

Product Owner et Backlog sont les mamelles d'une équipe.

Si une équipe clairement identifiée développe un produit, il ne reste plus qu'à trouver un bon Product Owner, ce qui n'est pas toujours facile, et hop avec un backlog pour ce produit, Scrum est appliqué avec la structure de projet standard : un PO, un backlog, une équipe

Malheureusement ce n'est pas toujours aussi simple. Parfois le produit nécessite plus qu'une équipe. Une solution possible est d'avoir un PO pour 2 ou 3 équipes, avec un seul backlog. un PO, un backlog, 2 équipes

Mais la semaine dernière, lors de ma formation Scrum à Antibes, le problème qui était posé n'était pas celui d'un produit avec plusieurs équipes. La notion d'équipe avait bien l'air d'exister, constituée avec les participants à la formation. Seulement ils ne s'occupaient pas d'un seul produit. Il semblait y avoir plusieurs produits sur lesquels l'équipe travaillait en même temps.

Scrum avait été utilisé pour développer un produit, et son application avait souffert de la difficulté à rester concentré sur un sprint. L'équipe était soumise à des changements de priorité entre les différents produits. Ces perturbations affectent la réussite des objectifs d'un sprint.

Un objectif de l'organisation est d'étendre Scrum aux développements des autres produits, mais en trouvant une solution limitant le manque de stabilité des ressources pendant un sprint.

Comme l'équipe est d'une taille raisonnable pour une équipe Scrum et dans l'idée de résoudre ce problème de sprint perturbé, nous avons envisagé de faire un seul backlog pour tous les produits. Cela aurait donné : une équipe, un backlog, n produits ?

Mais il s'est vite avéré impossible d'avoir un seul PO pour définir les priorités entre tous les produits. De plus cela allait à l'encontre du principe de Scrum pour le backlog : un produit, un backlog de produit

Nous avons alors étudié ce qu'était un produit dans leur contexte. Après réflexion, nous sommes arrivés à la notion de plateforme comportant des applications. Plutôt que d'avoir un backlog par application, l'idée est d'avoir un backlog par plateforme.

Dans le service il y a 2 plateformes (ou 3, il y a débat). C'est plus simple mais si on reste à une équipe, cela fait une équipe pour 2 backlogs. Après de nouvelles discussions, il s'est avéré que l'équipe pourrait être scindée en 2 équipes, une par plateforme. Une plateforme, un backlog, une équipe

La majorité des personnes travaillent pour une seule plateforme et quelques unes travaillent sur les 2. Certains feront donc partie de 2 équipes en même temps et d'autres pourront changer d'équipe. Cela reste acceptable mais il est préférable de synchroniser les 2 projets, en gardant le même rythme, c'est à dire avec des sprints de même durée.

Mais comment bien synchroniser et quid des PO ? Nous verrons les possibilités dans un prochain billet.

La chanson du jour, c'est Framboise. Antibes, ça m'a tout de suite fait penser à Boby Lapointe.


Découvrez Boby Lapointe!

Commentaires

1. Le lundi 27 avril 2009, 08:10 par m. jojo

Très très intéressant. J'attends la suite avec impatience !

merci, ça me motive pour écrire une suite.
2. Le dimanche 03 mai 2009, 20:25 par florent

Moi aussi je veux la suite, surtout que nous avons à peu près la même problématique du multi projet au sein de notre entreprise.
A une différence près nous n'appliquons pas Scrum ... ;-(

C'est prévu cette semaine, s'il n'y a pas trop d'impondérables.