Press "Enter" to skip to content

L’importance d’une vision pour l’équipe Scrum

Le fondement de la cross-functional team

TL;DR

Il est facile de détecter qu’une équipe a du mal à savoir où elle va. La solution, cependant, ne consiste pas en la création d’une roadmap mais de simplement définir et expliciter une vision. C’est un élément essentiel au bon fonctionnement de l’équipe.

Le fonctionnement en Feature Teams qui peut sembler compliqué de prime abord, est en fait très naturel dès lors qu’on a cette vision.

On ne sait pas pourquoi on est là

Le thème “Mission/Produit” du Squad Health Check de Spotify, traduction en français par Nicolas Lisle.

Laissez-moi vous raconter l’histoire d’équipes qui font un Squad Health Check. Un des thème du Squad Health Check est intitulé Mission/Produit.

Les équipes remontent un ressenti mitigé sur ce thème : jaune.

Point intéressant, les différentes équipes du projet s’accordent sur ce point, et notent toutes ce thème en jaune. La cause n’est probablement pas spécifique à chaque équipe.

S’ensuit en toute logique un plan d’action pour y remédier.

Rétro : Squad Health Check

Construire la Rétrospective autour d’un modèle de maturité

medium.com

Pour essayer d’améliorer ce point, les actions avaient semblé évidentes :

  • Construire une roadmap, la tenir à jour et la communiquer aux équipes de développement lors de chaque revue d’itération
  • Donner de la visibilité aux équipes de développement sur le contenu des itérations à venir, non pas sur la prochaine itération, mais sur au moins deux ou trois

L’air de rien, mettre en place et tenir à jour ces éléments c’est beaucoup de temps et d’efforts dépensés par le PO.

En effet dès lors qu’on essaie de planifier l’avenir, on a toutes les chances de se tromper et il faudra ajuster la planification par la suite. Refaire en permanence le même travail de planification.

Pourtant, malgré tous ces efforts côté PO, cela n’a pas suffi à améliorer la situation côté ressenti des équipes. Surprenant non ?

Donner une vision

La solution est en fait beaucoup plus simple, mais surtout beaucoup plus holistique. Ne pas se focaliser sur les choses à faire mais réellement donner une vision. Se focaliser sur les objectifs macro que l’on se donne, sur ce qui sera différent d’ici un an, deux ans… Et expliciter nos missions. Par contre, le détail du quoi et du quand, n’aidera nullement l’équipe à connaître sa mission et à s’en sentir investi.

Prendre de la hauteur, ce n’est pas construire une roadmap des fonctionnalités à venir. C’est expliciter la mission et donner une vision.

C’est ce que nous avons découvert lorsqu’un jour notre PO Richard est revenu de vacances et a eu une illumination. Il avait réussi à construire dans sa tête une vision pour le projet. Nous avons immédiatement couché cela par écrit, et avons essayé de le compléter de KPI. (notre premier essai de KPI, on essaie de s’améliorer depuis)

Voilà ce que ça a donné : (j’en suis hyper fier, et vraiment bravo à Richard !)

Ne jamais oublier l’argent. Même quand on n’est pas là pour faire du profit, ça reste ce qui fait tourner la boutique.
La vision devient un peu floue à 3 ans. D’un autre côté, c’est loin 3 ans ! Tout aura changé d’ici là. Donc bon, pas la peine de se prendre la tête plus que ça.

L’afficher en tellement gros que personne ne pourra l’ignorer

Quelques semaines plus tard, un projet fou a germé dans la tête de Richard : résumer ces objectifs à celui qui sera le plus déterminant et l’afficher en gros. En très, très gros.

L’idée m’emballe immédiatement et nous nous lançons dans l’impression et l’affichage d’une bannière géante. Voilà le résultat de notre vendredi soir :

La bannière fait toute la largeur de l’open-space.

Je ne sais pas si vous vous rendez bien compte de la taille de cette bannière. Elle se voit depuis l’autre bout de l’open space :

La bannière se voit depuis l’entrée de l’open space !

Y-a-t-il meilleur moyen de partager la Mission d’une équipe ou d’un projet ? Plus personne ne peut dire l’ignorer. On sait pourquoi on est là et quel est notre enjeu le plus fort.

Evolution du Squad Health Check d’une des équipes. On peut noter l’amélioration du thème “Mission/Produit”. Le passage au vert coincide avec le travail de notre PO sur la Mission, la Vision et les Objectifs du projet.

Maintenant, les équipes notent en vert le thème Mission/Produit en Squad Health Check. Cela n’a pas pris beaucoup de temps au PO. Par contre, cela lui a demandé un gros effort intellectuel pour formuler la réponse à la question fondamentale :

Pourquoi sommes-nous là ?

Le rôle clef de Product Owner

N’est-ce d’ailleurs pas là le véritable travail du Product Owner ?

Le véritable travail du Product Owner : expliquer pourquoi on est là, et s’assurer que l’équipe n’en perde jamais vue.

C’est pour cela que le rôle de Product Owner est bien identifié et spécifique dans Scrum. Il doit prendre de la hauteur et ne pas se focaliser uniquement sur le backlog d’itération.

Au-delà de la santé de l’équipe, la vision impacte son organisation

Ca vous parle le principe de Feature Team ? Une équipe multi-disciplinaire, organisée pour atteindre un but fonctionnel commun en le prenant en charge de bout en bout. On l’oppose en général au principe de Component Team, une équipe en charge d’un composant au périmètre technique clairement défini mais qui ne peut du coup pas implanter une solution de bout en bout, toute seule. Et c’est aussi, normalement, un des pré-requis de Scrum :

The Scrum Team

[…] Scrum Teams are self-organizing and cross-functional. […] Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. […]

Le débat Component Teams vs. Feature Teams est un classique, et pour cause : ce n’est pas simple. J’en ai déjà parlé dans des précédents articles.

L’équipe s’agrandit : comment s’organiser ?

Comment mettre en place des feature teams quand le projet gagne en ampleur et nécessite plus de collaborateurs

medium.com

Distribuer le rôle d’architecte au sein des Feature Teams

Notre expérience similaire aux Chapters de Spotify

medium.com

Mais admettons que vous soyez convaincus. Vous voulez tenter une ré-organisation en Feature Teams.

C’est bon, on part en Feature Teams ? Bravo !

Déjà, bravo ! Par contre, vous ne savez pas par où commencer. Quoi de plus naturel…

Vous vous posez plein de questions. Dont celle qui va sembler la plus insoluble :

Comment faire travailler ensemble tous les membres d’une même équipe qui ne partagent pas les mêmes compétences et intérêts ?

Oh là là ! Je crois que vous vous posez trop de questions. Vous vous compliquez inutilement la vie. Si vous avez un objectif clair, une vision, les réponses devraient être évidentes.

Dès lors que vous avez une vision claire pour le projet, la mise en place de Feature Teams est facile.

Comment faire travailler ensemble des personnes qui n’ont pas les mêmes compétences ? En se focalisant sur le fonctionnel, sur la vision commune. Ils n’auront pas tous les mêmes compétences, mais ils vont construire le même produit. Ce produit, c’est ce qui va unifier les discussions. Et c’est exactement ce que l’on veut avec une Feature Team : que l’on se concentre sur le fonctionnel et sur les problèmes à résoudre. Pas sur les solutions techniques !

L’essentiel des échanges de l’équipe seront liés au fonctionnel du produit, pas aux technos et méthodes qu’ils utilisent. Ils seront bilingues et parleront couramment la langue du produit à construire en plus de la langue de leur spécialité. C’est ça qui rend les Feature Teams aussi géniales !

OK évidemment le chemin sera quand même semé d’embûches…

En effet, vous aurez des soucis avec le fait que vos spécialistes ne seront maintenant plus ensemble dans la même équipe pour garantir la bonne tenue de leurs modules et de leurs architectures. C’est pourquoi vous aurez besoin d’entités transverses comme par exemple les Chapters ou les Guilds à la Spotify. C’est aussi pourquoi des architectures comme les micro-services deviennent pertinentes : parce qu’elles consistent à séparer le fonctionnel dans des composants distincts, limitant ainsi les impacts techniques des modifications entre Feature Teams.

Mais par contre… Par contre, vos soucis ne seront aucunement dû au fonctionnement de la Feature Team à proprement parler. Vous arriverez à les faire travailler ensemble sans problème dès lors que vous aurez ce fameux purpose, le but, la raison d’être, qui guide tout à chacun. Ayez un but et une raison d’être clairs et vous verrez que tout en découle.

Car au final, comme souvent, c’est très simple :

Le plus dur c’est d’essayer.

Vous avez aimé cet article ? Cliquez sur le cœur pour m’encourager !

Et abonnez-vous à moi via le bouton Follow pour être notifié de mes nouveaux articles. J’en rédige au moins un par semaine.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Top