Sabrina Ferlisi Dans cette deuxième partie, l’article met en avant l’autonomie d’une équipe Scrum, divisée en deux catégories : l’autogestion et les fonctionnalités transverses. L’autogestion permet à l’équipe de prendre des décisions et de s’auto-organiser, tandis que les fonctionnalités transverses favorisent l’indépendance, la montée en compétence, l’entraide et la délégation. Ces piliers contribuent à l’efficacité et à la résilience de l’équipe Scrum. L’article présente une équipe Scrum réelle et les différents éléments qu’elle a mis en œuvre pour renforcer son autonomie.
Selon une étude scientifique, des axes précis font qu’une équipe Scrum excelle. Dans la première partie de cette série d’articles, je vous ai partagé l’histoire de cette équipe Scrum que j’accompagne en tant que Scrum Master et qui est en quête d’efficacité. Nous avons vu comment l’axe de l’amélioration continue est présent au sein de l’équipe, quelles sont nos règles et pratiques et comment cela nous permet de faire des essais et d’avancer dans notre quête.
Derrière ce premier axe se distingue un autre pilier, tout aussi important : l’autonomie de l’équipe. Ce pilier est divisé en deux catégories : l’autogestion et les fonctionnalités transverses (cross functionality).
Afin de faciliter la lecture de cet article, j’ai ajouté à chaque section un tableau résumant les pratiques, techniques, ateliers que nous avons mis en place, en espérant que cela vous inspire.
L’autogestion
L’autogestion est le pouvoir donné à l’équipe pour gérer son propre destin, sans attendre les directives d’une autorité supérieure. C’est la capacité de s’auto-organiser et de prendre des décisions. Pour cela, au sein de l’équipe, nous sommes convaincus que nous devons faire preuve d’une grande proactivité pour proposer des nouvelles manières de faire et sortir des sentiers battus. Je vais vous présenter quelques aspects qui nous semblent importants.
Composition de l’équipe
L’équipe est au cœur des décisions qui la concernent du point de vue de sa composition. Qu’il s’agisse d’intégrer quelqu’un de nouveau ou de décider de la sortie de quelqu’un. Nous ne sommes pas une somme d’individus. Nous partageons des valeurs communes et c’est grâce à cela que nous sommes une équipe efficace. Il nous semble donc important de prendre part aux décisions concernant la composition de notre équipe.
Par exemple, il y a eu le cas d’un membre de l’équipe qui ne s’était pas intégré correctement (d’un point de vue compétence et attitude). Son départ de l’équipe a été une décision collective au sein de la Scrum Team. Le management n’a pas remis en cause notre choix. Le fait qu’il ait été externe à l’entreprise a certes facilité le processus, mais c’était une preuve indéniable de notre pouvoir décisionnel. Il me semble important de préciser ici qu’avant d’en arriver à ce choix, nous avons donné du feedback très transparent à cette personne en vue d’améliorer son intégration et sa posture vis-à-vis de l’équipe.
Inversement, quand il s’agit d’intégrer une nouvelle personne, nous ne laissons pas cette responsabilité à la seule direction. Une partie de l’équipe participe activement aux entretiens, évalue l’alignement des valeurs et prend la décision d’engager cette personne ou non.
Contrairement à ce qui nous a été suggéré, nous tâchons de minimiser les changements de composition dans l’équipe. Nous sommes conscients que chaque modification dans la structure de l’équipe demande un réalignement des valeurs qui n’est pas trivial. Nous voulons préserver au maximum cette alchimie.
Organisation de l’équipe
Nous n’avons pas de “Technical Leader”, de “Product Owner Manager” ou de “Scrum Master Chef de Projet”. Certes, l’expérience, l’ancienneté et le caractère de chacun amènent des expertises différentes avec parfois des avis tranchés. Nous avons aussi parfois tendance à demander trop facilement l’avis du plus expérimenté.
Cependant, personne ne dicte son travail à un autre, personne ne micro-manage le reste de l’équipe et personne ne décide de l’orientation technique pour tout le monde.
Les Developers s’auto-organisent sur leur manière de s’attribuer le travail, de collaborer et de travailler.
Même si nous cherchons à être les plus autonomes possibles, l’équipe travaille en bonne entente avec d’autres équipes et collabore activement en particulier avec une équipe qui travaille sur la même plateforme technique. Des accords et bonnes pratiques doivent être trouvés et, par exemple, nous avons défini une Definition of Done commune pour harmoniser notre travail.
Liberté opérationnelle
Côté opérationnel, notre équipe jouit d’une grande liberté. Techniquement, nous avons presque carte blanche pour choisir les technologies qui nous semblent les plus appropriées. Cette autonomie nous permet d’être plus réactifs, innovants et en phase avec les défis actuels.
De même, nous pouvons organiser nos processus de travail de manière très libre. Par exemple, nous avons pu mettre en place des pratiques Kanban au sein de notre implémentation de Scrum sans devoir en référer à quelqu’un.
Pour les développeurs qui sont soumis à une évaluation annuelle, nous avons décidé de les faire en équipe, plutôt que de laisser cette responsabilité au seul management. C’était un choix fort, illustrant notre solidarité et notre envie de progresser ensemble, sans dictat extérieur.
Malheureusement, nous ne pouvons dire de même sur notre liberté stratégique. J’y reviendrai dans un prochain article.
Cross Functionality
La cross functionality est une manière de travailler qui nous distingue, elle fait partie de notre culture. Voici comment elle se manifeste au quotidien.
Montée en compétence
Notre force réside dans la diversité de nos compétences et expertises. Nous sommes vigilants aux éventuels points faibles de l’équipe, et lorsque nous en identifions, nous mettons tout en œuvre pour y remédier. Cela peut passer par un partage de connaissances, une formation ou tout autre moyen permettant d’accroître nos compétences.
Indépendance renforcée
Notre équipe se caractérise par une grande indépendance. Dotés de toutes les compétences nécessaires à notre travail, nous ne dépendons presque pas des autres pour progresser. Lorsqu’un obstacle se présente, nous prenons les devants en résolvant le problème nous-même ou nous demandons activement aux équipes concernées de débloquer la situation au lieu d’attendre une résolution passive.
Entraide et polyvalence
Notre équipe ne se limite pas aux définitions de rôles. Les Developers s’intéressent profondément au métier et vont au-delà du travail technique. L’exemple de notre Business Analyst qui a dû s’absenter pendant plusieurs semaines en est une illustration : face à son absence, les Developers et le Product Owner n’ont pas hésité à reprendre une partie de son travail, qu’il s’agisse de tests ou d’analyse.
Délégation
Notre Product Owner sait reconnaître quand déléguer certaines tâches est bénéfique. Les tests fonctionnels, par exemple, peuvent être réalisés par l’équipe elle-même. De plus, en cas de discussions techniques, un membre plus apte prend le relais. Cette capacité à déléguer repose sur une confiance mutuelle forte, comme celle observée entre le Business Analyst et le Product Owner. Ils échangent même leurs rôles au besoin, une preuve de la flexibilité et de la confiance qui règnent au sein de notre équipe.
Cette cross functionality nous confère une agilité et une résilience exceptionnelles. Elle assure que, quels que soient les défis que nous rencontrons, nous sommes équipés pour les surmonter ensemble.
Concluant cette seconde partie, l’autonomie de l’équipe est bien plus qu’un simple concept. C’est une réalité vécue au quotidien, une responsabilité partagée, et un signe indéniable de la maturité de notre équipe. Elle reflète notre capacité à prendre notre destin en main, à faire des choix, parfois difficiles, pour le bien commun.
Rappelons-nous que chaque équipe a sa propre dynamique, ses propres défis, et il n’y a pas de formule magique. Cependant, une équipe qui est investie de ce pouvoir de décision, qui peut façonner son avenir, a toutes les cartes en main pour exceller et se dépasser.
Nous explorerons dans la prochaine partie l’aspect du Support du management, qui est un aspect plus compliqué pour notre équipe et un axe d’amélioration possible.
