Comment gérer les sprints dans une équipe tech : les conseils de Jira
Nous avons interrogé une experte des sprints tech : Suzie Prince, chef de produit DevOps qui travaille pour Atlassian, l’éditeur du logiciel Jira.
				
			
			
				
				Suzie Prince, chef de produit DevOps chez Atlassian
Suzie gère les équipes chez Atlassian qui élaborent des produits pour des logiciels comme Jira destinés aux développeurs du monde entier. Suzie se passionne pour la création de produits conciliant les besoins des utilisateurs, des clients et des entreprises. Suzie est un leader expérimenté avec 15 ans d’expérience dans la création d’outils agiles et DevOps. Elle est captivée par le potentiel que le DevOps apporte aux entreprises et aime donner aux équipes les moyens d’apporter de la valeur rapidement, fréquemment et de manière rationnelle.
En quoi le sprint est-il un élément central pour les équipes tech ?
Un sprint est une période courte, délimitée dans le temps, au cours de laquelle une équipe scrum se consacre à la réalisation d’une quantité de travail déterminée. Ils sont au cœur même des méthodologies scrum et agiles, et une bonne gestion de ces dernières aidera toute équipe agile à livrer de meilleurs logiciels avec moins de maux de tête. C’est pourquoi, un planning de sprint est une étape indispensable dans l’exécution d’un projet, afin de minimiser les imprévus et de garantir une meilleure qualité des résultats obtenus.
Le sprint est un élément important du cycle de vie d’une équipe technique, car il s’agit d’une période pendant laquelle l’équipe peut se fixer un objectif spécifique et se diriger vers un résultat précis, tout en ayant la possibilité de fournir un retour d’information sur la manière dont le processus s’est déroulé, dans le but de réfléchir et de s’améliorer pour le prochain sprint.
En pratique, il faut compter, une heure par semaine d’itération, ce qui représente environ deux heures pour un sprint de deux semaines. L’idéal est donc de le faire en début de semaine, afin que l’équipe ne soit pas perturbée par le week-end.
Quel est selon vous le moment, l’étape, le rituel le plus incontournable d’un sprint ? Pourquoi ?
Il y a deux moments importants dans le sprint.
Tout d’abord, il faut impérativement définir l’intention et l’objectif du sprint. En d’autres termes, l’équipe doit se demander “qu’essayons-nous de réaliser” ? Ainsi, tous les sprints doivent commencer par une définition précise de l’ordre du jour et de l’objectif. Grâce à cela, l’équipe va alors évoluer dans un climat où elle se sent motivée, stimulée et capable de réussir. En revanche, un plan de sprint mal adapté ou mal préparé est susceptible de compromettre le bon fonctionnement de l’équipe du fait d’objectifs irréalisables.
La deuxième partie importante est la phase de démonstration des réalisations du sprint précédent et le bilan qui en est fait. Celui-ci a pour but d’aider l’équipe à déterminer si les résultats et les objectifs escomptés ont été atteints. L’objectif de cette phase est de créer des boucles de rétroaction rapides de sorte que les équipes puissent itérer et s’améliorer au cours des prochains sprints.
Quelles bonnes pratiques adopter pour une planification et un suivi efficace du sprint au quotidien ?
Chaque équipe a sa façon de faire, mais voici ce que nous pouvons proposer comme pratiques hebdomadaires :
- Faites une démonstration de tout ce qui a été développé la semaine précédente, afin que l’équipe reste informée et connectée.
 - Passez en revue les objectifs et les buts du sprint que vous avez fixés la semaine précédente, et vérifiez s’ils ont été atteints.
 - Déterminez vos objectifs pour les prochains sprints. Chez Atlassian, un objectif de sprint est différent d’un ticket Jira. Un objectif de sprint est une unité de travail qui doit pouvoir être présentée à l’équipe ou livrée en production en fin de sprint.
 
Ces méthodes permettent d’établir de nouveaux objectifs. Nos développeurs peuvent alors passer en revue les problématiques de notre backlog et sélectionner celles qui nous aideront à atteindre les objectifs du sprint. Grâce à cette organisation, on obtient une adhésion totale de l’équipe. Chacun est pleinement impliqué dans la définition des objectifs, de la manière dont nous allons les atteindre et de la répartition du travail.
De plus, ce temps de réflexion est un moyen naturel et collaboratif de mesurer notre vélocité et de rester concentrés sur nos priorités. Si un objectif particulier prend trop de temps ou ne semble pas apporter la valeur que nous espérions à l’origine, nous pouvons convenir en équipe de le déprioriser ou de l’annuler complètement.
Parmi les autres bonnes pratiques, citons : faites des propositions très tôt et très souvent, divisez les grands changements en petits projets et encouragez la responsabilisation.
En d’autres termes, “You build it, you run it” (« Vous le construisez, vous le gérez ») le mantra DevOps, qui signifie que l’équipe responsable de l’écriture d’une fonctionnalité devient également l’équipe responsable de son déploiement et de la maintenance continue une fois qu’elle est en ligne.
À quelles difficultés les équipes de développement peuvent-elles être confrontées durant un sprint et comment y faire face ?
Les équipes sont généralement confrontées à des problèmes techniques ou de traitement, notamment des erreurs de conception ou des échecs de déploiement. Il est important que l’équipe se concentre sur la résolution de ces problèmes et s’assure que son travail traverse l’ensemble du processus, de l’idée à la livraison, de la manière la plus fluide possible. Pour ce faire, les équipes peuvent être attentives à la durée du cycle et s’assurer qu’elles passent suffisamment de temps à améliorer leurs pratiques techniques tout en se concentrant sur les buts et les objectifs de l’entreprise.
Quels conseils pourriez-vous donner à une organisation en croissance qui cherche à synchroniser, optimiser les sprints de plusieurs équipes de développement ?
Nous avons conscience que les équipes qui jouissent d’une certaine autonomie sont plus performantes. Il est donc important de leur donner la liberté de choisir leur mode de travail, les outils qu’elles utilisent et les processus qui leur correspondent le mieux. Ceci étant dit, nous reconnaissons également que la visibilité au niveau de la direction en ce qui concerne les livraisons versus les blocages est également un enjeu majeur.
Il est important qu’une entreprise décide avec détermination quels sont ses besoins et où elle se situe sur l’échelle entre l’autonomie et la coordination. Toutes les grandes entreprises n’ont pas nécessairement besoin de sprints synchrones.
Chez Atlassian, nous utilisons des boucles de livraison hebdomadaires, mensuelles et trimestrielles pour informer nos équipes dirigeantes.
Quelles actions peuvent être mises en place par les équipes de développement pour expliquer leur fonctionnement au reste de l’entreprise ou aux clients ?
Il est important que les développeurs maintiennent une proximité transversale, ce qui signifie qu’ils doivent bien comprendre les décisions prises par les équipes techniques, produits et design. Les développeurs ne doivent pas écrire une ligne de code avant d’avoir posé un certain nombre de questions sur le produit qu’ils sont en train de développer, son but et ses objectifs.
Il nous paraît également important de rappeler aux développeurs qu’ils ont eux aussi, leur mot à dire dans le processus de planification des logiciels.
N’importe quel développeur peut écrire du code et rentrer chez lui, mais pour les meilleurs d’entre eux, il s’agit d’aller au fond des choses pour comprendre l’objectif final, ce qui permet d’obtenir un logiciel encore meilleur.
Chez Atlassian, nous avons une culture interne forte en matière de blogs et nous utilisons nos propres produits tels que Confluence pour documenter le travail en cours, les résultats et les victoires. Et étant donné que nos équipes de développement produisent des logiciels pour d’autres équipes de développement, nous sommes en mesure de trouver des solutions aux problèmes avant que nos clients ne les rencontrent. Nous sommes très attachés au partage de nos meilleures pratiques et de nos expériences dans ce que nous appelons des « pièces » que nous partageons avec l’extérieur.
L’IA générative est au cœur de l’actualité. De quelle manière peut-elle impacter la gestion de projet des équipes tech ?
L’IA générative n’en est qu’à ses débuts. Mais il s’agit tout de même d’un bouleversement technologique comparable à l’invention de l’Internet ou à la révolution du téléphone portable. Bien entendu, nous sommes partisans de l’utilisation de nos propres outils. Par exemple, notre agent virtuel Jira Service Management a déjà permis à notre équipe de service desk d’économiser 2 400 heures, soit 100 jours, en trouvant des informations et des réponses répétitives aux tickets. Nos développeurs peuvent également utiliser notre IA pour faire des choses comme convertir des requêtes en langage naturel en JQL (comme SQL) directement dans Jira.
Sur le long terme, nous pensons que l’IA permettra aux développeurs d’élargir leur champ d’action comme jamais auparavant, ce qui rendra leur rôle encore plus important. Cette évolution favorisera à l’avenir des logiciels plus performants, l’IA jouant le rôle de coéquipier dans le processus de planification des logiciels.
Imaginez que l’IA puisse générer un modèle de plan pour vous en recommandant des responsables pour chaque section en fonction du contexte de l’entreprise ou en mettant en évidence les points de blocage du travail dans votre processus afin que vous puissiez fournir de la valeur plus rapidement.
Dans un sens, la programmation logicielle se rapproche de la cuisine. En effet, ce n’est pas le fait de préparer les ingrédients qui est amusant, mais le fait de les assembler pour former un seul et même plat. Et c’est comme si, dans cette même cuisine, vous bénéficiez maintenant de l’aide d’un sous-chef. C’est ce parallèle qui nous fait dire que nous voyons l’IA comme un coéquipier utile dans le processus de planification des logiciels. Et une grande partie de ce travail est déjà en cours dans nos propres outils tels que Confluence et Jira Software.