Responsabilités équilibrées

Quatre responsabilités non équilibrées pouvant nuire à votre équipe Scrum

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:

  • Foi en Scrum: grâce à la fréquence élevée d’inspection et adaptation, les personnes s’engagerons à améliorer leur manière de collaborer
  • Confiance envers les autres: en leur bonne foi ! Parce que tout être humain ayant un objectif clair veut faire de son mieux pour le réaliser
  • Courage de laisser faire: donner le temps aux individus d’experimenter et comprendre. Etre disponibles les uns envers les autres pour s’aider, faire remarquer tout comportement ne favorisant pas l’auto-organisation

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.

Responsabilité non équilibrée n ° 1 – Le Product owner est le roi

Le Product Owner est le Roi
Le Product Owner est le Roi

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.

Responsabilité non équilibrée n ° 2 – La dictature de l’équipe de développement

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 ?

La dictature de l'équipe de développement
La dictature de l’équipe de développement

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.

responsabilité non équilibrée # 3 – Le Scrum Master est le chef de projet

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)!

Le Scrum Master - Project Manager
Le Scrum Master – Project Manager

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.

responsabilité non équilibrée # 4 – L’organisation est le patron, personne ne décide

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.

L'organisation est le chef
L’organisation est le chef

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.

Comment surmonter les responsabilités non équilibrées?

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:

  • Product Owner: optimise la valeur du produit
  • Development Team: fournit des incréments «Done» à chaque sprint
  • Scrum Master: élimine les obstacles
Responsabilités équilibrées
Responsabilités équilibrées

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 :

Conclusions

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:

  • Les rôles sont clairement et simplement définis, Scrum aide beaucoup à cet égard.
  • Les rôles sont compris et respectés par tous les membres de l’équipe et par l’organisation
  • Les personnes sont tenues responsables de leurs rôles et tiennent les autres responsables pour le leur
  • Les valeurs Scrum sont compris et aident à créer un environnement de confiance idéal pour apprendre rapidement
  • L’inspection et l’adaptation de la Scrum Team sont effectuées à haute fréquence (Sprint Retrospectives)

Bonne route avec Scrum !

Scrum change l’entreprise !

English version available on scrum.org website.

Lorsque je délivre une formation Professional Scrum Master ou que j’aide mes clients à créer des produits géniaux avec Scrum, on me demande comment adapter (rétrograder) Scrum pour le faire fonctionner dans leurs entreprises.

Ma réponse est toujours la même: Scrum change l’entreprise ! Laissez-moi vous expliquer pourquoi ce n’est pas le contraire.

1 – Les hiérarchies ont été prouvées utiles pour le travail répétitif. Le Génie Collectif est nécessaire pour résoudre des problèmes complexes et apporter de la valeur; il est obtenu grâce à des réseaux intelligents d’équipes auto-organisées et pluridisciplinaires, reliées entre elles par des valeurs et des responsabilités.

Arrêtez de contrôler les personnes, commencez à contrôler la valeur délivrée!

2 – Les cadres intermédiaires, ou d’autres postes de management peuvent grandement contribuer au changement. Toutes ces personnes ont l’opportunité de faire la transition vers l’un des trois rôles proposés par Scrum : Product Owner pour ceux qui aiment le développement de produits, rejoindre l’Equipe de Développement pour les plus « techniques » (développement, marketing, vente, sécurité, qualité, etc. .) et enfin Scrum Master pour ceux qui aiment former, enseigner et aider les individus à comprendre et à mettre en œuvre le cadre Scrum tel que décrit dans le Guide Scrum.

3 – Passer du temps à trouver comment réduire les risques, prédire les résultats futurs, comment contrôler les gens ne crée pas de la valeur. Au lieu de faire des plans, commencez à crée votre premier incrément, à inspecter et à adapter pour améliorer la prévisibilité et réduire les risques. Scrum c’est de l’action utile… pour délivrer de la valeur.

Scrum est un cadre simple pour livrer des produits complexes. Il aide les organisations dans leur transformation, pas le contraire.

Photo by Ross Findon on Unsplash

Changer Scrum ne vous aidera pas à : réagir rapidement aux changements du marché, réduire votre temps de mise sur le marché, augmenter l’efficacité de votre entreprise, avoir des employés plus sains et plus heureux et, en fin de compte, gagner des parts de marché !

Nous avons tous un rôle à jouer, oublions les hiérarchies et pensons que vous pouvez contribuer à la création de valeur pour vos clients grâce à vos produits.

Comme le co-créateur de Scrum, Ken Schwaber, a écrit sur son blog: « Scrum est comme les échecs. Vous pouvez jouer selon les règles, ou pas. Scrum et les échecs n’échouent pas et ne réussissent pas. Ils sont joués ou non. « 

Profitez de Scrum!

S’adapter et évoluer vers Scrum

English version available on scrum.org website.

L’être humain, à travers les siècles, a réussi à s’adapter à beaucoup de situations et évoluer pour devenir ce que nous sommes aujourd’hui. L’histoire montre que nous avons une capacité innée de s’adapter et évoluer.

Scrum

Cela reste valable dans le cadre d’un changement en entreprise, comme l’adoption de Scrum.

Par le passé, j’ai pu remarquer que les changements réussis concernant l’adoption de Scrum ont suivi les trois principes suivants. Cela ne veut pas dire que ces principes sont universellement applicables.

Donner un sens au changement

Pourquoi faut-il changer ? Aujourd’hui je suis souvent appelé par des organisations qui n’arrivent plus à concurrencer les start-ups et perdent des parts de marché. Pour la plupart de mes clients, la mise sur le marché de nouveaux produits prend souvent des mois ou des années. Ils doivent évoluer pour rester compétitifs dans ce monde complexe et changeant. Adopter Scrum est un bon moyen de réduire les délais de mise sur le marché.

Connaître les règles du jeu (le cadre Scrum)

Comment travailler différemment ? Une fois convaincus et motivés par le changement, ou plus souvent pour s’en convaincre, il est nécessaire d’apprendre les règles du jeu. Pour cela, Scrum a des règles très simples et une formation est une excellente opportunité pour consolider son expérience ou apprendre à mettre en pratique Scrum. Mon expérience en formation, me permet aujourd’hui d’affirmer que nous devons réapprendre à collaborer (à tous les niveaux) et que la différence entre un changement rapide et un plus lent réside dans notre capacité à ne plus contrôler les personnes mais les résultats fournis par une équipe.

Jouer !

A ce stade il ne reste plus qu’a pratiquer, en gardant l’esprit ouvert, en étant conscients qu’il est peu probable (impossible ?) d’être parfaits du premier coup et que, parfois, il faudra aller relire la notice du jeu, ou demander l’aide de quelqu’un qui a déjà joué par le Scrumpassé. Finalement, pensez à la première fois que vous avez joué à votre jeu de société préféré, c’est la même chose ! Jouer à Scrum, surtout les premières fois, n’est pas facile : engagement, courage, ouverture, attention et respect sont les Valeurs Scrum qui vous permettrons d’inspecter votre manière de jouer et l’adapter pour jouer toujours mieux, comme des pro !

Conclusions

J’ai pu constater que ces trois principes ont permis, dans certains contextes, de réussir la transition vers une utilisation de Scrum. J’ai aussi observé le contraire, ce qui n’a pas fonctionné et fait revenir les équipes aux anciens reflexes.

Je suis convaincu que, dans un premier temps, il faut se forcer à s’adapter au changement en appliquant les règles du jeu. Avec le temps, grâce à la répétition des mêmes « gestes » vous évoluerez vers une adoption de Scrum qui ne sera que la première étape d’un parcours qui vous permettra de délivrer des produits de qualité dans un contexte complexe, tel qu’il est notre monde aujourd’hui !

J’adore jouer à Scrum en respectant les règles du Scrum Guide et vous ?