Augmentez la satisfaction de vos clients en leur délivrant plus de valeur plus rapidement
Dans cette vidéo, je présente un sujet de discussion régulier dans les formations de la série Professional Scrum. Comment une équipe Scrum peut fonctionner sans chef ?
Le secret reside dans la compréhension des responsabilités de chaque rôle :
Scrum requiert une équipe auto-organisée pour délivrer des increments « done » à la fin de chaque Sprint. Cette particularité soulève parfois des critiques et questions quand elle est abordée en formation ou en entreprise : comment cela peut marcher, une équipe sans chef ? Comment allons-nous faire, si personne nous dis quoi ou comment faire notre travail ?
Dans cet article, je traite les responsabilités de chaque rôle dans une équipe Scrum et je décris certains dysfonctionnements qui empêchent l’auto-organisation d’une Scrum Team.
Le Scrum Guide indique que:
Les équipes Scrum sont auto-organisées et pluridisciplinaires. Les équipes auto-organisées choisissent la meilleure façon d’accomplir leur travail, au lieu d’être dirigées par des personnes externes à l’équipe.”
L’auto-organisation rendra la Scrum Team performante; le Scrum Master s’assure que le principe d’auto-organisation est compris et correctement appliqué. Il aide chaque personne à contribuer à cet objectif.
Je suis convaincu que pour permettre à une Scrum Team de s’auto-organiser nous devons faire preuve de foi, confiance et courage:
Pendant des années de travail en équipe, j’ai observé les responsabilités non équilibrées suivantes. Cette liste n’est pas exhaustive ni dans un ordre particulier. Je suis intéressé de savoir si quelqu’un a vécu la même situation ou des situations similaires.
Le Product Owner dicte la loi, sans transiger avec l’équipe de développement et en contraignant à fournir des incréments avec un contenu fixe à chaque sprint.
La position de force tenue par le Product Owner, pousse la DevTeam à délivrer de la quantité, la qualité est un sujet peu discuté.
Il y a de fortes chances pour que l’équipe Scrum crée de la dette technique et, sans aucune amélioration définie (au moins) en Sprint Retrospective, que l’équipe de développement souffre d’une faible motivation et d’un fort turnover.
Dans ce cas, il est difficile de s’auto-organiser. Le Product Owner va au-delà de sa responsabilité d’optimisation de la valeur. L’équipe de développement et le Scrum Master n’ont pas assez de « force » pour contrebalancer la situation.
Dans les environnements hautement techniques, où les architectes logiciels et systèmes ont beaucoup de pouvoir et où le business collabore peu avec le département informatique, j’ai vu des équipes de développement travailler sur de beaux produits techniques, mais créent-elles de la valeur ?
Le Product Owner est souvent un architecte logiciels ou systèmes, très concentré sur la mise au point du produit et la rédaction des spécifications techniques pour l’équipe de développement. Le Product Owner est davantage le chef de l’équipe de développement que l’optimiseur de valeur.
Dans cette configuration, l’équilibre se trouve du côté de l’équipe de développement, ce qui empêche la création d’une équipe Scrum auto-organisée.
Cela m’est particulièrement familier, car j’ai été dans cette situation lors de mes premières expériences, je suis désolé pour l’équipe (si vous lisez)!
La responsabilité d’un chef de projet est de respecter les délais, le budget et le contenu du projet. Une attitude command & control est très courante et, par-dessus tout, toutes les décisions sont prises ou validées par une seule personne, le Scrum Master / Project Manager.
Dans cette situation, si le Scrum Master / Project Manager est absent, peu de décisions sont prises et souvent on attend sa presence pour s’engager!
Dans ce cas, l’équipe ne s’auto-organise pas en raison de l’incompréhension du rôle du Scrum Master en temps que Servant Leader.
Peut-être l’une des pires situations. L’équipe Scrum est victime de la fragmentation des responsabilités au sein de l’Organisation et de la complexité de la chaîne de commandement hiérarchique.
En conséquence, le Product Owner n’a ni autorité ni légitimité à propos du produit et les décisions sont souvent annulées ou modifiées par quelqu’un d’autre.
L’auto-organisation de l’équipe de développement est minée par une multitude de silos. La complexité est telle que personne ne peut rien décider avant les validations des responsables fonctionnels.
Dans ce cas, la culture de l’entreprise et l’incompréhension de Scrum peuvent constituer des obstacles à l’auto-organisation des équipes.
L’auto-organisation fonctionne si chaque individu comprend ses responsabilités, s’engage à les respecter et exige la même chose de ses collègues.
Le guide Scrum définit avec elegance et précision trois responsabilités simples, pour chaque rôle:
Personnellement, j’ai du d’abord bien comprendre ce que signifiait les responsabilités du Scrum Master. Je vous suggère de prendre le temps de réfléchir à la signification profonde de chaque responsabilité.
Je recommande la lecture de quelque livre, qui m’ont aidés dans le parcours :
L’incertitude et la complexité sont omniprésentes dans nos vies, personnelles et professionnelles. Cela nécessite plus de collaboration et de liberté pour expérimenter de nouvelles solutions.
L’auto-organisation est la façon plus efficace de travailler dans des environnements complexes. Vous aurez plus de chances de vous auto-organiser en équipe si:
Bonne route avec Scrum !