Optimisation globale des équipes SCRUM (V2)

 

Suite à une réorganisation interne et au départ d'un collègue pour de nouvelles aventures, deux de nos équipes SCRUM ont vu leurs effectifs réduit d'une personne :

Équipe G:

• 3 développeurs
  
• 2 représentants utilisateurs --> 1 représentant utilisateurs
  
• 1 ScrumMaster
  
• 1 ProductOwner
  

--> Avant le changement, les deux représentants utilisateurs n'étaient pas pleinement occupés sur les projets de leur équipe. Cependant le passage à 1 représentant utilisateurs a inversé les contraintes. Maintenant, les développeurs doivent parfois ralentir leur flux de développement.

Équipe D:

• 3 développeurs --> 2 développeurs
  
• 1 représentant utilisateurs
  
• 1 ScrumMaster
  
• 1 ProductOwner

--> Avant le changement, il y avait un certain équilibre de charge de travail entre les développeurs et le représentant utilisateurs. Le passage à deux développeurs laisserait très probablement du temps libre au représentant utilisateurs.

Les équipes ont les contraintes suivantes:

• Le projet D devra être terminé avant l'été, bien qu'il y ait un développeur en moins
  
• Le projet D devra être maintenu et nous devrons être réactif aux demandes de nos clients; et ce, même pendant les congés annuels de cet été.
  
• L'équipe G doit produire une release du projet G pour mi-mai.
  
• L'équipe G doit maintenir d'autres projets : S, P, etc.
  
• L'équipe D devra aider l'équipe G une fois le projet D terminé.
  

Un brainstorming nous a permis d'imaginer les solutions suivantes:

1. On ne fait rien, et nous ferrons face aux retards possibles sur Projet D et G
   
2. Un développeur de l'équipe G rejoint l'équipe D pour terminer le projet D avant l'été aux frais de l'équipe G et de la release du projet G.
   
3. Nous fusionnons le deux équipes pour finir le projet D, terminer la release du projet G et faire au mieux sur les autres projets.
   

Toutes ces solutions ont leurs avantages et inconvénients:

• La première solution à pour avantage de ne pas trop perturber les équipes qui ont un bon équilibre et qui sont devenues performantes mais on comprend bien que l'objectif de date du projet D sera difficile à tenir car le "product backlog" a déjà été sérieusement raffiné. De plus, dans l'objectif de maintenir le produit, concentrer la connaissance sur trois personnes parait une option assez risquée.

• La deuxième solution serait valable pour terminer le projet D mais ça serait déshabiller l'équipe G déjà réduite pour habiller l'équipe D. D'un point de vu maintenance, cette option est guère mieux que la précédente. De plus, terminer la release du projet G pour mi-mai serait difficile.

• La dernière solution, quant à elle, a pour inconvénient de bouleverser complètement les deux équipes dont les pratiques au quotidien sont différentes, et dans lesquelles une complicité c'est formée. Cependant, la connaissance de tous les projets se diffuserait vers plus de personnes et le projet D pourrait être privilégié afin d'être terminé avant l'été. Le projet G pourra aussi bénéficier de tous les membres de la nouvelle équipe pour valider la release d'ici à mi-mai. 
  

Auriez-vous d'autres idées? Quelle option choisiriez-vous?

Avec une approche Lean, il faut rechercher une optimisation globale plutôt qu'une optimisation locale. Les deux premières options où rien n'est changé et où un développeur change d'équipe sont des optimisations locales avec au mieux le projet D pouvant être terminé dans les temps. Dans ces options, on refuse de changer radicalement pour ne pas casser les dynamiques des deux équipes. Cependant, on conserve de gros risques sur tous les projets que ce soit sur les dates ou la connaissance commune pour la maintenance. La fusion des deux équipes, aux delà du changement complet des équipes parait une solution plus pérenne dans le temps alors s'il faut changer, autant y aller franchement!

Nous avons donc choisi la fusion avec une certaine appréhension face à ce changement mais nous sommes convaincus que c'est la meilleure solution.

Voyons donc maintenant les changements que nous devons mener:

• Reconstruire une équipe : Cela va prendre du temps car pour arriver à la performance nous devrons passer par une certain nombre d'étapes (http://blog.octo.com/stades-de-developpement-dune-equipe/)
  
• Nous allons devoir travailler avec deux ProductOwner tant que le projet D n'est pas terminé
  
• L'un des product owner est aux Etats-Unis avec 6 heures de décalage. Les cérémoniesSCRUM vont donc devoir être adaptées en conséquence
  
• L'équipe D perd son ScrumMaster
  
• Nous devrons faire des choix de pratiques
  
• Nous allons devoir fusionner les "product backlogs" (en gardant des sous-projets) pour avoir une meilleure visibilité
  
• Chacun va devoir apprendre à travailler sur tous les sous-projets.
  
• Nous allons très probablement centraliser les sources des différents projets et fusionner les plates-formes d'intégration continue pour une maintenance plus facile.
  

Dans un prochain billet, j'essayerai d'approfondir la théorie des contraintes sur ces deux équipes afin d'expliquer le choix qui a été fait de façon plus analytique. Je ne manquerai pas aussi de vous faire un retour sur ce choix avec les succès et difficultés rencontrés avant l'été ...