Une équipe d'ingénierie en bonne santé doit s'organiser elle-même ! Elle doit être capable de définir des rôles et des responsabilités clairs et de s'engager à livrer ses projets selon un plan bien pensé.
L'année dernière, nous avons formé une nouvelle équipe appelée Micros Scale. Sa tâche ? Créer l'infrastructure Platform as a Service (PaaS)interne d'Atlassian, notre plateforme dédiée à l'expérience des développeurs. Comme notre travail respecte un périmètre fixe et des délais clairs, nous tenions à réaliser un travail incrémentiel, à nous concentrer davantage, et à être plus orientés objectifs et proactifs.
Auparavant, notre équipe était chargée de nombreuses tâches opérationnelles ad hoc qui nous empêchaient de planifier correctement les sprints. Au moins 55 % de la capacité de l'équipe étaient alloués aux rotations de poursuite des activités. À l'époque, Kanban était donc la méthodologie la mieux adaptée à nos besoins.
Il convient de noter que selon le modèle de Tuckman, l'équipe Micros Scale en était à sa phase de formation et que certains points restaient à améliorer, notamment la planification des capacités et des sprints, la définition des objectifs, la réflexion de l'équipe, la préparation de stories, l'estimation, la répartition des projets, et bien plus encore.
Quelle méthodologie Agile nous convenait le mieux ?
Micros Scale gérait deux projets majeurs très complexes dont la date d'échéance avait été annoncée publiquement à nos clients. Il était donc essentiel d'accélérer la livraison. Nous devions optimiser notre approche en la matière et souhaitions travailler sur notre planification comme des pros Agile. Nous voulions que notre équipe soit auto-organisée, atteigne des objectifs partagés et tire des enseignements de ses expériences.
Nous avons réévalué notre approche Agile en nous posant les questions suivantes :
- Est-il possible de se fixer un objectif pour chaque itération afin d'atteindre un objectif avec un thème unique ?
- Pouvons-nous nous engager sur le périmètre des livrables pendant une ou deux semaines ?
- Pouvons-nous préciser et définir les exigences sur lesquelles nous devons travailler ?
- La fréquence des demandes ad hoc réduira-t-elle la priorité de nos tâches, et sommes-nous moins susceptibles de connaître des changements radicaux ?
- Notre équipe est-elle nouvelle dans Agile et manque-t-elle de maturité dans ses processus Agile ?
Étant donné que les réponses à ces questions étaient toutes « Oui », nous avons compris que Scrum était la méthodologie Agile idéale pour notre équipe. Voici les autres informations sur lesquelles nous nous sommes appuyés pour prendre notre décision :
| | | | |
|---|---|---|---|
| Méthodologie Agile | De quoi s'agit-il ? | Cela nous aide-t-il ? | Pourquoi ? |
| Scrum | Scrum consiste à établir une feuille de route claire et à prioriser les tâches, tandis que Kanban permet de visualiser votre travail planifié pour l'équipe sur une base ad hoc. | Oui | Nous avons un backlog clairement prédéfini qui doit être affiné et priorisé. Notre travail est prévisible, contrairement à celui de notre équipe précédente, plein de surprises et de demandes hautement prioritaires. |
| Les stories ne doivent pas être modifiées au cours d'un sprint. | Oui | Nous pouvons adopter une approche plus flexible, en l'occurrence Scrumban (une méthodologie hybride à cheval entre Scrum et Kanban). | |
| Scrum est plus facile à adopter pour les équipes Agile qui continuent d'apprendre à utiliser les fonctionnalités de pointe. Scrum est plus prescriptif et propose des rituels et des fenêtres temporelles qui constituent des garde-fous. | Oui | Notre nouvelle équipe comprend de nouveaux membres. Elle est encore en phase de Formation-Tension. En conséquence, Scrum nous aide à gagner en maturité. Découvrez le modèle de Tuckman. | |
| Kanban | Limiter le travail en cours et se concentrer sur la réduction de la durée de cycle des projets. Cas d'usage : quand votre équipe n'a ni limite de temps, ni calendrier fixe pour son travail. La demande est transmise à l'équipe et traitée le plus rapidement possible (comme le SLA des équipes du centre de services). | Non | D'autres équipes dépendent de nous. Nous avons donc besoin de délais estimés pour aider les autres à planifier en conséquence. Certains de nos engagements sont annoncés publiquement aux clients d'Atlassian. Nous devons donc être attentifs et planifier en fonction. Nous n'avons pas beaucoup de demandes d'intervention, comme un centre de services. |
| Idéal pour les équipes qui reçoivent de nombreuses demandes opérationnelles dont la priorité et la taille varient. | Oui | Nous ne sommes pas surchargés par les tâches de poursuite des activités, et le flux de travail est géré par un rôle qu'occupent en rotation les différentes personnes de l'équipe. Si nous le souhaitons, nous pouvons nous appuyer sur Kanban pour ce rôle. |
Nous avons adopté Scrum
Je suis parfaitement consciente que les Engineering Managers sont à la fois des chefs d'orchestre, des connecteurs, des boussoles et des coachs. J'ai donc dû développer toutes ces compétences équitablement. Voici comment je m'y suis prise :
En savoir plus sur les pratiques Agile
Les ressources de formation internes d'Atlassian m'ont aidée à améliorer mes compétences en matière de pratiques Agile. J'ai suivi des cours intensifs sur la méthodologie Agile et j'ai consulté un coach Agile. J'ai interviewé plusieurs Engineering Managers pour en savoir plus sur leur expérience dans d'autres organisations et équipes.
Utiliser DACI
Le framework décisionnel DACI (qui signifie « Driver (meneur), approbateur, contributeurs, intervenants informés ») pour prendre des décisions de groupe efficaces et efficientes. J'ai expliqué à mon équipe la proposition d'adoption du framework DACI pour recueillir leurs commentaires, leur accord et leur soutien.
Utiliser un modèle de sprint
J'ai élaboré un processus pour gérer nos sprints et j'ai créé un modèle pour chaque sprint afin de faciliter une planification plus raisonnable. Ce modèle de planification des sprints comprenait plusieurs points :
- Comment passer en revue le sprint précédent pour nous assurer de ce que nous avions accompli et pour le célébrer.
- Comment réfléchir rétrospectivement au sprint précédent et appliquer les enseignements tirés au sprint suivant.
- Quels sont la cadence, le nom et les objectifs du sprint ?
- Combien de stories nous engageons-nous à livrer ? Quel est le périmètre du sprint ?
- Comment planifier la capacité en fonction de la disponibilité des personnes.
- De quelles activités avons-nous besoin en cours de sprint pour être parfaitement préparés pour le prochain sprint ?
- Comment écrire des stories, définir les exigences et trouver une solution pour y répondre.
- Comment suivre l'état des stories sur lesquelles nous nous sommes engagés et que faire des stories inachevées.
Nous avons également un excellent tutoriel expliquant comment utiliser des sprints dans Jira Software.
Passer à Scrum en valait la peine
Nous avons obtenu les améliorations suivantes suite à l'adoption de Scrum :
Amélioration de la vélocité
Dans la méthodologie Agile, la vélocité est l'un des facteurs qui permet de mesurer la productivité d'une équipe. Il s'agit de la quantité moyenne de travail accomplie par une équipe Scrum au cours d'un sprint. Nous utilisons un graphique de vélocité pour suivre le travail que notre équipe s'est engagée à terminer et ce qui a déjà été réalisé. Dans le graphique de vélocité ci-dessous, la colonne grise indique le nombre de story points que l'équipe s'est engagée à terminer en fonction de sa capacité. Nous le comparons à la colonne bleue, qui indique le nombre de story points qu'elle a réellement livrés. L'équipe pourra ensuite utiliser ces informations pour ajuster ses prévisions pour les prochains sprints.
Identification rapide des risques
Être capable d'identifier les risques à un stade précoce et de proposer une solution est la clé de la réussite des projets.
Lors de la définition des objectifs et des thèmes du sprint, nous sélectionnions des stories cohérentes pour atteindre les objectifs. Pendant les sessions en cours de sprint, notre équipe préparait le backlog, affinait les stories et fournissait plus d'informations à leur sujet. Pour cette dernière étape, nous nous demandions :
- Qu'y a-t-il à faire ?
- Pourquoi faisons-nous cela ?
- Quelle valeur métier cette tâche apporterait-elle ?
Cela a permis à nos ingénieurs d'identifier les dépendances et de prioriser les tickets dont l'impact était le plus important afin d'éliminer les obstacles. Cela nous a également permis de modifier notre méthode de travail et d'améliorer la concentration de notre équipe sur chaque projet.
Célébrez votre réussite, vous avez livré !
La planification des capacités et la définition d'objectifs nous ont apporté de la motivation en donnant du sens à notre travail, et nous ont poussés à faire preuve de transparence quant à nos engagements. Nous avons lancé avec succès une phase critique du partitionnement de comptes Atlassian PaaS. Nous sommes également sur le point de lancer la première phase de notre projet de résidence des données afin de couvrir un plus grand nombre de régions AWS à des fins de fiabilité, de résilience et de conformité.
De la formation à la normalisation
Comme je l'ai mentionné plus haut, l'équipe Micros Scale est relativement nouvelle et est encore dans sa phase Formation, selon le modèle de Tuckman.
La définition d'un objectif unifié pour l'équipe a incité tout le monde à s'aligner et à se soutenir mutuellement pour atteindre les objectifs de l'équipe et renforcer sa motivation. Nous avons échoué, réfléchi, appris, et nous nous sommes améliorés. Au bout de trois mois et demi, nous avons doublé les effectifs de l'équipe Micros Scale, et je suis toujours fière de la considérer comme une équipe Normalisation.
Amélioration de la communication
Le fait d'élaborer un plan et d'être dévoué lors de chaque sprint a amélioré la visibilité de nos prévisions pour l'ensemble de l'équipe et nous a permis de mieux nous comprendre. Les Engineering Managers et les parties prenantes peuvent ainsi suivre plus facilement les obstacles et l'avancement du projet.
Comment choisir votre méthodologie Agile
- N'hésitez pas à revoir vos processus lorsque vous identifiez un problème. Pensez Agile : personnes, processus et outils.
- Évaluez le projet et les responsabilités de votre équipe afin de déterminer les méthodes Agile les plus adaptées pour elle. Consultez notre page Kanban et Scrum pour en savoir plus sur ces méthodes.
- Si vous décidez d'adopter Scrum, je vous suggère d'utiliser un tableau Scrum Jira ou de créer un modèle sur Confluence ou votre outil préféré.
Pour chaque sprint, créez une page de planification de sprint pour passer en revue le dernier sprint et planifier le sprint suivant en fonction des capacités de votre équipe et de l'objectif du sprint. Voici mon modèle Confluence personnel :
Voici mon modèle de planification des capacités qui est inclus dans mon modèle Scrum général :
Voici également mon modèle d'objectifs et de périmètre de sprint :
En cours de sprint, il est utile de disposer d'une autre page pour suivre les performances de l'équipe pendant la semaine écoulée, les stories à aborder durant le sprint suivant en tenant compte de l'avancement actuel du sprint (ce que l'on appelle la préparation du backlog) et fournir plus d'informations sur les stories préparées (affinage des stories). Voici mon modèle de préparation et d'affinement du backlog en cours de sprint :
Chaque équipe est différente, et ce qui a fonctionné pour nous ne fonctionnera peut-être pas pour les autres équipes. Scrum, Kanban, ou une combinaison des deux, comme Scrumban et Kanplan, serait peut-être une meilleure méthodologie pour vous. Il est essentiel d'évaluer les besoins spécifiques de votre équipe et de comprendre la méthodologie qui répond le mieux à ses besoins.
