L’importance d’une vision pour l’équipe Scrum
Le fondement de la cross-functional team
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à
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 !)
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 :
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 :
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.
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 collaborateursmedium.com
Distribuer le rôle d’architecte au sein des Feature Teams
Notre expérience similaire aux Chapters de Spotifymedium.com
Mais admettons que vous soyez convaincus. Vous voulez tenter une ré-organisation en Feature Teams.
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.