Un ami me demandait mon avis sur ce post
Publier | Fil d’actualité | LinkedIn
Voici ce que j’ai répondu
Arriver à travailler en petit groupe, c’est l’idéal.
C’est pour ça que le « vrai scrum » ne peut se réaliser qu’avec une équipe autonome d’une 10aine de personnes.
De ce principe, on a les choix suivants :
Soit on accepte la limite et la productivité qui en découle.
Soit, on décide de faire grandir l’équipe et on accepte les conséquences d’un groupe trop grand
Soit, on multiplie les groupes.
Soit, on crée des fonctions support.
Les fonctions de support, c’est le plus vicieux parce qu’on pense y gagner en rationalisant les coûts et on y croit très fort parce qu’il est quasi impossible de mesurer ce qu’on y perd.
Pour ça, je conseille la lecture de reinventing organizations de Laloux.
On voit souvent les équipes de support devenir des pôles d’exigences. On leur demande au départ de faire gagner du temps
Soit en accompagnant les équipes pour les rendre autonomes, soit en les soulageant de tâches opérationnelles facilement reproductibles. Là où elle devait au départ faire gagner du temps, elles en font rapidement perdre bien plus en procédures et perte d’autonomie.
Reste le choix « d’augmenter le nombre de groupes ».
Ce qu’on appelle passer à l’échelle…
Quand on choisit ça, on commet fréquemment la même erreur : on oublie de passer à l’échelle. On se contente de multiplier les groupes. Passer à l’échelle, c’est changer de granularité. Le point dans l’illustration dont on parle devient le groupe. À ce niveau, on doit foutre la paix à chaque équipe sur son fonctionnement interne.
Si je prends le cas de SAFe , un indice du début de plantage, c’est quand un epic owner commence à parler de story.
C’est comme si dans une équipe scrum, un membre disait à un autre comme il doit s’asseoir dans son siège pour coder.