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 !

Cinq questions pour un Sprint Goal !

English version published on Scrum.org website.

Qu’est-ce qu’un Sprint Goal ?

« Un Sprint Goal est un but fixé pour le Sprint et peut être réalisé par l’implémentation d’une partie du Product Backlog » (cit. Scrum Guide).

Le Sprint Goal est un phrase qui peut être utilisée de plusieurs façons :

  • La Development Team l’utilise chaque jour au Daily Scrum, pour inspecter le travail fait et adapter le travail restant. Le résultat de cette inspection et adaptation est transparente dans le Sprint Backlog.
  • Le Product Owner l’utilise pour communiquer avec les Stakeholders et comme outil d’aide à la prise de décision, au moment de la négociation du contenu du Sprint avec la Development Team ou quand il / elle doit décider de continuer ou d’annuler un Sprint.
  • Le Scrum Master peut s’assurer qu’un Sprint Goal a bien été défini à la fin du Sprint Planning, d’une manière claire et transparente pour tous et qu’il est fréquemment utilisé pour l’inspection et l’adaptation pendant un Sprint.

Avez-vous clairement défini un Sprint Goal à la fin du Sprint Planning ? Le Sprint Goal est-il clairement compréhensible et transparent pour tout le monde ? Est-il défini d’une manière à fournir une direction et de la flexibilité à la Development Team ?

Le but de cet article est de vous sensibiliser à l’importance de définir un Sprint Goal et de formuler des suggestions pour en créer un efficace.

Savez vous combien de fois le terme “Sprint Goal” est mentionné dans le Scrum Guide ? 27 fois !

Pourquoi avons-nous besoin d’un Sprint Goal ?

Un Scrum Team a besoin d’un Sprint Goal parce qu’il fournit :

  • Un but pour la Scrum Team, parce que cela répond à la question : « Pourquoi construisons-nous cet Incrément ? ».
  • Une direction à la Development Team, car ils peuvent l’inspecter fréquemment pendant un Sprint, de sorte que les écarts indésirables puissent être détectés plus tôt.
  • Une référence pour la prise de décision, à l’attention du Product Owner, car il / elle peut décider d’annuler un Sprint si le Sprint Goal devient obsolète.

Quand le Sprint Goal est-il défini ?

Le Sprint Goal est défini pendant le Sprint Planning par la Scrum Team. Il reste valide pour toute la durée du Sprint sinon le Sprint est annulé par le Product Owner.

Comment le Sprint Goal est-il défini ?

Un Sprint Goal est défini grâce à la collaboration entre Product Owner et Development Team.

Dans la première partie du Sprint Planning (la partie du « quoi »), « le Product Owner discute de l’objectif que le Sprint devrait atteindre et des items du Backlog Produit qui, s’ils seront complétés durant le Sprint, atteindraient Sprint Goal » (cit. Scrum Guide).

Avec le but défini, la Development Team collabore et négocie avec le Product Owner le travail à faire pendant le Sprint et, ensemble, ils définissent et ils se mettent d’accord sur le Sprint Goal.

Définir un Sprint Goal ne sera pas naturel lors des premiers Sprints, un peu d’aide et direction peut être trouvée dans le modèle de Sprint Goal de Roman Pichler.

Quels sont des exemples de Sprint Goal ?

Sprint Goal
Bon exemples Mauvais exemples
Implémenter la fonctionnalité de recherche Comprendre si nous pouvons intégrer la solution Open Source XY au Produit Expérimenter l’utilisation d’une nouvelle technologie pour le rebranding de la fonctionnalité XY Corriger les anomalies #1234 and #3488 Implémenter la fonctionnalité de recherche et, si vous avez le temps, corriger les anomalies#3335 et#777 plus répondre à la question posée par le PDG lors de la dernière Sprint Review Réécrire la classe Java ShopProcess

Conseils de lecture

  • The Professional Product Owner, Don McGreal and Ralph Jocham
  • Agile Product Management With Scrum, Roman Pichler

Références

Le Scrum Guide fait référence au Sprint Goal 27 fois en 17 pages. Il est si important que chaque rôle, événement et artefact est, en quelque sorte, impacté par le Sprint Goal.

Le tableau suivant résume combien de fois le Sprint Goal est mentionné dans le Scrum Guide, dans quel paragraphe et dans quel but.

Nb. de fois que le est mentionné Paragraphe dans le Scrum Guide Citations dans le Scrum Guide
1 Théorie de Scrum « Les utilisateurs de Scrum doivent fréquemment inspecter les artefacts Scrum et l’état d’avancement par rapport à un Sprint Goal afin de détecter les écarts indésirables. »
3 Le Sprint « Pendant le Sprint le Sprint Goal est fixe ; les changements qui le remettent en cause ne sont donc pas permis » « Les Sprints permettent la prédictibilité tout en assurant l’inspection et l’adaptation de la progression vers un Sprint Goal » « Un Sprint serait annulé si le Sprint Goal devient obsolète »
11 Sprint Planning « Le Product Owner discute de l’objectif que le Sprint devrait atteindre et des items du Product Backlog qui, s’ils seront complétés durant le Sprint, atteindraient le Sprint Goal. » « L’équipe Scrum détermine aussi le Sprint Goal. » « [Le Sprint Goal], à travers l’implémentation des items du Backlog Produit choisis, sera atteint durant le Sprint » « Une fois le Sprint Goal fixé et les items du Backlog Produit choisis, l’équipe de développement planifie le travail pour transformer cette fonctionnalité en un incrément « Fini » du produit durant le Sprint. » « La Development Team devrait être en mesure d’expliquer au Product Owner et au Scrum Master comment elle entend s’organiser pour réaliser le Sprint Goal et créer l’incrément prévu. »
« Le Sprint Goal est un but fixé pour le Sprint et peut être réalisé par l’implémentation d’une partie du Product Backlog. » « Le Sprint Goal fournit à l’équipe de développement une certaine flexibilité quant à la fonctionnalité implémentée durant le Sprint. » « Les items du Product Backlog sélectionnés offrent un fonctionnement cohérent, ce qui peut faire office de Sprint Goal. » « Le Sprint Goal peut être une autre source de cohérence poussant la Development Team à travailler ensemble au lieu d’entreprendre des initiatives distinctes. » « Tout en effectuant son travail, la Development Team garde à l’esprit l’objectif du Sprint. » « Afin d’atteindre le Sprint Goal, ils [la Development Team] implémente les fonctionnalités et les technologies nécessaires. »
7 Daily Scrum « La Development Team utilise le Daily Scrum pour inspecter sa progression vers le Sprint Goal. »
« Le Daily Scrum augmente les chances que la Development Team atteindra le Sprint Goal. »
« [Daily Scrum] se concentre sur la progression vers le Sprint Goal. » « Qu’est-ce que j’ai fait hier qui a aidé la Development Team à atteindre le Sprint Goal ? » « Que ferai-je aujourd’hui pour aider la Development Team à atteindre le Sprint Goal ? » « Est-ce que je vois tout obstacle qui m’empêche ou empêche la Development Team à respecter le Sprint Goal ?»
4 Sprint Backlog « Le Sprint Backlog est l’ensemble des items sélectionnés pour le Sprint plus un plan pour livrer l’Incrément du Produit et réaliser le Sprint Goal. » « Le Sprint Backlog rend visible tout le travail que la Development Team identifie comme nécessaire pour atteindre le Sprint Goal. » « …le Sprint Backlog émerge durant le Sprint. Cette émergence a lieu alors même que la Development Team exécute le plan et découvre le travail nécessaire pour atteindre le Sprint Goal. » « La Development Team fait le suivi de cette somme de travail restant au moins à chaque Daily Scrum pour évaluer la probabilité d’atteindre le Sprint Goal. »

DONE (DoD) : une définition incomplète ou un manque de confiance ?

rawpixel-1187642-unsplash_small

English version published on Scrum.org website.

Il y a quelques jours, j’observais une Sprint Rétrospective. L’équipe Scrum a décidé de travailler sur la définition de “Done” (DoD), identifiée comme le sujet le plus important à adapter pour le prochain sprint. Les discussions étaient ouvertes et animées. Puis, une conversation inattendue a émergé au cours de la session.

Deux nouveaux développeurs ont récemment rejoint la DevTeam, composée de cinq personnes. La croissance de l’équipe a changé la dynamique, ajoutant de la complexité et la nécessité d’une révision de la définition de “Done”.

Le Scrum Master a invité le Product Owner et la DevTeam à générer des idées pour la DoD. Après quelques minutes, de nombreux post-its ont été proposés et partagés dont certains plus détaillés et d’autres moins.  La discussion s’est ensuite figée au niveau la documentation, notamment à des fins de test.

La question qui s’est posée : à quel point la DoD devrait-elle être précise et détaillée ? Devrions-nous être spécifiques, par exemple: “tests de non-régression documentés, validés par un paire, exécutés et le résultat stocké dans le dossier XY”. Devrions-nous simplement nous contenter d’une phrase comme: “tests de non-régression” ?

La réponse à cette question ?  La décision prise par le Product Owner et la DevTeam ensemble est acceptable, améliorée continuellement par l’inspection et l’adaptation.

C’est à ce moment-là qu’une nouvelle discussion s’entame entre les membres de la DevTeam : l’un d’eux arguant que le seul fait d’écrire des “tests de non régression” ne garantirait pas que le collègue effectuait des tests “de qualité” et “assez” significatifs. Il aurait simplement pu faire quelque chose pour se débarrasser du test et passer au suivant.

Un son de cloche sonne alors dans ma tête. Un néon rouge avec les lettres “C O N F I A N C E” commence à clignoter aussi… (oui, des choses étranges se passent, parfois, dans mon cerveau :-))

daria-nepriakhina-474036-unsplash_small

Partant de l’hypothèse que la DevTeam est un groupe de professionnels qui s’auto-organise pour créer un incrément “Done” à la fin de chaque sprint, s’ils ne parviennent pas à s’entendre sur un DoD et utilisent des expressions du type “comment puis-je savoir si vous avez réellement fait un bon test ?”, le souci repose fort probablement sur la confiance accordée au travail des autres.

J’ai validé mon hypothèse en posant quelques questions ouvertes. Maintenant, je sais que je dois aider la DevTeam à rétablir la confiance pour qu’elle redevienne efficace. Ce qui a commencé comme une simple discussion sur la définition de « Done » a finalement révélé un autre problème : le manque de confiance entre les membres de la DevTeam.

Je suis convaincu que cette équipe surmontera ses difficultés et redeviendra rapidement une DevTeam très performante !

À retenir

  • Vérifiez le niveau de confiance, à tout moment. C’est souvent LE problème. Vous pouvez consulter mon article “Un atelier pour découvrir les valeurs Scrum” pour vous donner des idées.
  • Les changements dans la composition des équipes peuvent en affecter la productivité, lisez les étapes de développement du groupe de Tuckmanpour en savoir plus.
  • Apprenez à cerner le problème, en vérifiant le sujet en question, le comportement des personnes, leur formulation et leur langage corporel.
  • Tenez-vous en au Guide Scrumet aux règles du jeu (surtout si vous êtes moins expérimenté) à maintes reprises, c’est le point de départ de mes explications.