Lume :

Cette organisation multiplie les blocages, favorise la déresponsabilisation (c’est pas ma faute c’est les autres qui étaient en retard, y’a toujours un autre en retard avec 7 ou 8 équipes spécialisées) mais il faudrait réorganiser toute la structure du développement sans visibilité sur ce qui en sortirait…

Je ne peux que vous encourager pour affronter le défi de la réorganisation. Effectivement, vous n’aurez pas de visibilité sur ce qui en sortira, mais en aviez vous lorsque vous avez mis en place Scrum?
N’hésitez pas à me contacter si vous avez besoin d’aide (tbalbous – at – pyxis-tech point com)

Je vous fais un premier retour à la fin de notre second “Sprint Kanban”, j’utilise ce terme car nous avons gardé un certain nombre d’habitude Scrum (planning poker, sprint pour rythmer les rétrospectives et le bilan à destination de notre direction) nous avons dû en abandonner certaines (backlog sprint fixe, product owner, démonstration).

Pour l’heure notre colonne “bloquée” persiste, dans notre process de gestion des tâches nous avons ajouté deux conditions pour qu’une tâche entre dans cet état : un mail de l’intervenant externe dont dépend ce blocage, une date de résolution donnée par cet intervenant externe.

Pourquoi ces tâches sont en état bloquée ?
En première idée j’ai pensé que ces tâches n’auraient pas dû quitter le backlog produit et entrer dans la colonne “En attente” du tableau Kanban tant que toutes les conditions nécessaires à leur réalisation n’étaient pas réunies. Difficile cependant pour le scrum master (moi en l’occurence, juge et partie , qui aujourdh’ui décide des priorités à défaut d’un product owner, de faire une analyse systématique avant de mettre la tâche dans le tableau. Dans le cas d’une correction de bug le temps de cette analyse et le temps de résolution du bug sont très proche (au delta près du process de mise en production).
Par ailleurs pour une fonctionnalité données qui doit fait l’objet d’un développement dans deux équipes une des tâches va obligatoirement être bloquée dans sa phase d’intégration (et potentiellement dans la phase de développement) car l’autre équipe n’aura pas finit son travail. Soit l’équipe A doit attendre l’équipe B pour valider son développement, soit l’équipe B doit attendre l’équipe A pour utiliser la nouvelle fonction.
Pour des questions de délais on ne peut pas pour autant attendre que la première équipe ait finit avant de commencer le développement dans l’équipe B.

Donc pour l’instant nous conservons cette colonne bloquée qui a cependant l’avantage, avec ces jolis postit orange fluo, de mettre en avant les blocages. Il y a certainement des optimisations à faire dans l’organisation du travail mais ce découpage en équipe spécialisée est en place depuis deux ans pour palier aux problèmes de qualités qui étaient apparus lorsque les mêmes développeurs travaillaient sur toutes les couches de la plateforme.
Cette organisation multiplie les blocages, favorise la déresponsabilisation (c’est pas ma faute c’est les autres qui étaient en retard, y’a toujours un autre en retard avec 7 ou 8 équipes spécialisées) mais il faudrait réorganiser toute la structure du développement sans visibilité sur ce qui en sortirait…

Je te recommande également de prendre le temps de comprendre pourquoi ce problème est arrivé :
“Cette carte est bloquée car il nous manque un contenu, un fichier sans lequel le site ne peut être mis en ligne.”
- Pourquoi il manque un fichier => c’est une conséquence d’un autre problème à identifier
- Pourquoi le site ne peux être mise en ligne => est-ce vraiment le cas ? Si oui alors le problème précédent est encore plus important.

Julien

Si vos tâches sont bloquées du fait de dépendances, comment faire pour les réduire?
La question peut être abordée selon différentes perspectives : l’organisation des équipes, les compétences des équipes, le découpage ou la répartition des tâches… et beaucoup d’autre encore. L’idée est de repenser la façon dont on travaille une fois que le Kanban a rendu visible les faiblesses du processus.

Je serai curieux de d’apprendre comment vous avez réussi à faire face à ces défis

Après quelques mois de scrum nous sommes passé à Kanban et le premier problème qui se présente à nous c’est justement ce problème de blocage des tâches. Dépendant de plusieurs équipes (nous sommes une équipe spécialisée non une équipe multidisciplinaire à la sauce scrum) de notre spécialisation dépends ce principe de dépendance de l’achèvement de nos tâches en fonction de livraison d’autres équipes internes ou externes.

Nous en sommes venu à ajouter une quatrième colonne à notre tableau Kanban (En attente, BLOQUEE, En cours, A livrer) avec comme principe qu’une tâche bloquée ou à livrer bloquée bascule dans la colonne bloquée, avant de débuter une nouvelle tâche de la colonne “En attente” on vérifie que la condition de blocage d’une tâche de la colonne bloquée n’est pas résolue.