Ici archive

2020 a été une année riche en apprentissages. Elle a mis en emphase la nécessité pour les organisations de se concentrer sur le cœur de leurs activités, l’impact et la résilience à long terme. Elle a aussi surligné un manque de réactivité et de flexibilité organisationnelles dans des contextes de plus en plus imprévisibles, se traduisant souvent par un manque d’alignement entre l’offre et le besoin réel des utilisateurs (clients, partenaires ou collaborateurs internes).

Ainsi, aujourd’hui plus que jamais, les modèles et tactiques agiles sont au cœur des problématiques de l’entreprise : le recrutement, l’onboarding, la collaboration entre équipes, la co-création de nouveaux services, les offres, l’adoption par les utilisateurs finaux…

Nous nous entretenons aujourd’hui avec Hadi Hissa, Senior Manager chez Saegus, sur la place et l’importance de l’agilité en 2021.

Qu’entend-on par agilité ?

Je définirais l’agilité comme la capacité structurelle d’anticiper les changements présents à court, moyen et long terme, tant d’un point de vue organisationnel qu’humain.

Autrement dit, l’agilité ne se résume pas à un manifeste ou à un cadre de travail limité au développement des produits. D’ailleurs, il est important de noter que l’agilité trouve son origine dans le domaine de l’industrie, pour se démocratiser au début de l’ère digitale. Elle était alors, et est toujours, définie comme la capacité à prendre en compte des changements rapides et peu anticipables.

Quelle est la place de l’agile aujourd’hui ?

En Europe, l’agilité a quitté le berceau de l’IT, où elle est née au début des années 2000.

Aujourd’hui, elle s’étend aux fonctions qui en étaient initialement éloignées. De plus en plus, nous vivons des expériences qui visent à faire évoluer des équipes travaillant dans des domaines comme les ressources humaines, le marketing, la recherche, le développement ou la supply chain. Ces équipes souhaitent raccourcir leur délai de réaction et augmenter leur capacité à livrer des résultats rapides liés à leur fonction, comme une livraison accélérée d’un service ou une fluidification des processus d’onboarding. Elles doivent adopter ces pratiques, mais surtout se les approprier pour en tirer la meilleure valeur, celle qui les concerne.

Quels sont les avantages de l’agile dans un contexte incertain ?

Comme nous l’avons vu, l’agilité est née pour répondre à l’incertitude, en donnant la capacité aux équipes de raccourcir les circuits de livraison pour qu’un service, un processus ou un produit rencontre plus vite son public cible.

La problématique de l’agilité est donc de fournir des éléments tangibles récoltés sur le terrain remplaçant ainsi des projections théoriques, pour réduire les incertitudes.

Prenons un exemple, celui de la gestion d’une chaîne d’approvisionnement : dans un contexte d’un marché aux demandes de plus en plus volatile, l’agilité peut proposer un cadre de travail collaboratif permettant aux parties prenantes de se partager plus simplement des données. Cela permet de mieux anticiper les demandes, avérées ou potentielles, du consommateur final. Récemment, un grand acteur cosmétique avec lequel nous travaillons a par exemple divisé par deux le temps de mise sur le marché de ses produits en utilisant cette approche.

L’agile et le télétravail, une bonne combinaison ?

Bien que la crise ait accélérée la digitalisation des pratiques agiles, l’adéquation entre l’agilité et le télétravail n’est pas une problématique récente. En effet, les groupes du CAC40, dont les équipes pluridisciplinaires sont présentes dans plusieurs pays et qui ont entamé la diffusion de l’agilité à l’échelle, ont dû déjà faire face à la problématique de l’outillage agile. L’expansion et la maturité des usages de ses outils ont néanmoins été accélérées par la crise.

Aujourd’hui, de plus en plus d’équipes combinent les réunions physiques et les outils de gestion de projets (ex : Jira, Trello, Microsoft Azure, Teams…) pour délivrer leur projet aux côtés d’équipes réparties à travers le monde. De même, l’utilisation accélérée des boards interactifs (Klaxoon, Miro) participent à la digitalisation des cérémonies agiles.

L’évolution et la démocratisation des pratiques digitales est donc en pleine adéquation avec l’agile et le télétravail.

Quels conseils donneriez-vous à une entreprise qui souhaiterait mettre en place une approche agile ?

Plutôt que d’imposer des modes opératoires génériques aux équipes, pensez à les impliquer dans la définition des processus et des cadres de travail qui les concernent.

La co-création, la collaboration et l’intelligence collective font parties des clés de réussite et doivent être au centre de la définition du cadre de travail agile cible de chaque entreprise. Chaque organisation, et chaque équipe, a ses propres manières de travailler, ses contraintes et ses objectifs. Il est donc presque impossible de répliquer le même cadre de travail agile à deux organisations différentes.

Par ailleurs, adopter une démarche itérative d’amélioration continue dans le déploiement de l’agilité à l’échelle d’une entreprise est aussi essentiel. Ceci peut être réalisé en identifiant des processus ou des équipes prioritaires pour tester et valider l’adéquation du cadre de travail avant d’élargir par itérations successives ces pratiques aux autres équipes, petit à petit, jusqu’au niveau global de l’entreprise.

Comment Saegus accompagne une entreprise dans la mise en place de l’agilité ?

Chez Saegus, nous avons la conviction que l’agilité n’est pas une fin en soi mais plutôt un levier indispensable permettant la transformation des entreprises pour leur donner les moyens structurels d’accepter le changement et donc, de réagir rapidement aux incertitudes du marché.

De ce fait, nous pensons que l’agilité ne peut pas être dissocié des approches innovantes centrées sur l’utilisateur, comme le Design Thinking ou le Lean Startup par exemple. Grâce à AIM (Acceleration Impact Model), notre modèle tactique pionnier développé par nos équipes, nous combinons l’ensemble de ces approches dans une offre unique qui permet à nos clients de :

  • construire leur cadre de travail unique et d’accélérer durablement l’impact de leurs projets ;
  • avancer de manière pragmatique ;
  • apporter des réponses rapides, adaptées à leurs problématiques et ambitions ;
  • mesurer l’impact de leurs projets et rectifier le tir en temps réel.

Si vous souhaitez être accompagné par nos équipes et agiliser vos équipes, contactez-nous !

Rédigé par Hadi Issa, Senior Manager Acceleration Tactics

Avis aux adeptes de Scrum : la version du Scrum Guide 2020 vient de paraître. Notre experte Roxane Meyer se penche ici sur les impacts opérationnels et stratégiques de ces modifications – et vous partage ses convictions.  

Pour rappel, Scrum est un est un des cadres de travail Agile des plus utilisés au sein des organisations. Sa promesse : organiser les projets de façon simple, transparente et pragmatique. 

Il offre à ce titre de nombreux avantages en permettant une gestion, plus intelligente du travail, en améliorant l’efficacité des équipes et en garantissant une meilleure visibilité du projet et de son évolution.  

En définitive, si votre projet est : 

  • Innovant : Une conception laissant place à la créativité 
  • Porteur de paramètres inconnus : Besoins, technologie ou délais 
  • Complexe : Articulation de plusieurs équipes, métiers, domaines 

Alors le cadre de travail Scrum est fait pour vous.  

Initialement utilisé pour le développement Software, Scrum abandonne dans sa nouvelle version les termes dédiés à l’informatique pour laisser place à un vocabulaire à destination de toutes les équipes adressant des problématiques complexes (développer une application, développer un nouvel objet connecté, porter un projet de réorganisation, redéfinir son offre de service, mener la campagne d’adoption d’un outil…)  

Cette simplification promet une approche plus inclusive et de nouvelles opportunités quels que soient les secteurs ou industries  et ouvre la porte à de nouveaux métiers : équipes RH, équipes Innovation, équipes de soins….  

Nouvelle version 2020 : qu’est ce qui change ?  

La définition du Framework Scrum 

Si les valeurs et les piliers de du Framework n’ont pas changé, la définition a néanmoins été mise à jour. Elle se veut plus opérationnelle, concrète, en plaçant le Scrum Master et ses objectifs au centre du cadre de travail :  

« Scrum est un Framework léger qui aide les personnes, les équipes et les organisations à générer de la valeur grâce à des solutions adaptatives pour des problèmes complexes. En bref, Scrum a besoin d’un Scrum Master pour favoriser un environnement où : 

  1. Un Product Owner ordonne le travail pour un problème complexe dans le Product Backlog. 
  2. La Scrum Team transforme une sélection de travail en un Increment de valeur lors d’un Sprint. 
  3. La Scrum Team et ses parties prenantes inspectent les résultats et s’adaptent pour le prochain Sprint. 
  4. Répéter 

Le langage est également simplifié, pour faciliter la prise en main du cadre de travail et permettre à des équipes non spécialisées dans le développement Software de se lancer dans l’aventure.  

Au fur et à mesure des versions, le Scrum Guide se veut de moins en moins prescriptif et élimine certaines pratiques qui ne sont pas considérées comme toujours efficaces ; par exemple, les trois questions à poser pendant le Daily sont supprimées, et l’intégration de solutions d’améliorations dans le Sprint Backlog suite à la Sprint Retrospective n’est plus imposé.  

L’allègement des pratiques renforce l’ouverture du Framework ; ce qui pourrait marcher pour une équipe de développement en logiciel peut ne pas être adapté pour une équipe de recherche scientifique ou de ré-organisation.  

Point de vue de l’expert  Dans quelle mesure cette nouvelle version du Scrum Guide rend-t-il le cadre de travail plus accessible ?  

C’est l’évolution observée depuis quelques années : cette mise à jour vient appuyer les tendances de fond de simplification du cadre de travail. Dès la définition, les rôles sont introduits, les objectifs de chacun définis et on s’aperçoit qu’elle s’adresse à une population plus large que précédemment. Cette mise à niveau s’aligne parfaitement avec les souhaits de Jeff Sutherland et Ken Schwaber de simplifier leur Framework et le rendre accessible à tous.    

Roxane Meyer, experte Scrum chez Saegus

Une simplification et clarification des rôles 

Les arcanes de la méthode Scrum repartissent les membres de l’équipe dans des rôles précis. Chaque rôle porte des prérogatives et des responsabilités particulières qui se connectent mais ne s’échangent pas. Cette organisation se veut bénéfique pour la conservation des objectifs du projet face aux impératifs su projet, qu’ils soient techniques, fonctionnels ou clients. Les membres de l’équipe, jouant leur rôle, maintiennent un équilibre des forces. 

La création du Product Goal comme engagement majeur renforce la place de la vision produit dans le processus du projet, et est placé au centre.   

Les fondateurs ont également choisi d’accentuer la cohésion dans la Scrum Team en supprimant la notion de « sous-équipe ». Par conséquent, l’équipe de développement fait peau neuve et devient Developers 

L’ensemble des membres du projet appartient donc à la Scrum Team, concentrée sur un seul objectif : celui du Produit. On entend par produit – tout service, objet, concept, ou éléments organisationnels créé par la Scrum Team.  

 Ils ne sont plus auto-organisés mais auto-managés ; ils décident en autonomie de qui fait quoi, quand, et comment.  

Le Scrum Master, expert du cadre de travail Scrum, veille à sa bonne application, anime l’équipe, et facilite le quotidien de l’équipe en éliminant les obstacles. Cependant, la responsabilité de ce rôle manquait de clarté pour certaines organisations. Il est maintenant clairement énoncé que le Scrum Master est imputable d’une part de la méthodologie, mais également de l’efficacité de l’équipe. La valeur livrée est donc sa responsabilité – et l’indicateur de performance du rôle devient plus concrète.  

Point de vue de l’expert – ces nouveaux éléments n’induisent-ils pas un nouveau niveau de complexité ?   

Au contraire, cette modification permet vraiment de supprimer la séparation entre la gestion du produit et sa réalisation. Finalement c’est toute l’équipe qui est responsable du produit et de l’ensemble des activités pour le réaliser.  De plus, aucune relation hiérarchique n’existe entre le Product Owner et les Developers (anciennement Équipe de développement), la suppression de cette sous équipe accentue cette notion. Cela permet de se concentrer sur ce qui est important – la création de valeur par la Scrum Team.    

 La nouvelle version de Scrum porte une différence majeure dans la désignation des « rôles », qui deviennent des « responsabilités ». Ce changement vient en réaction à la démocratisation des rôles de Product Owner et de Scrum Master, qui apparaissent aujourd’hui partout sur LinkedIn et les fiches de postes. La responsabilité réelle de chaque rôle est ainsi revalorisée.  Un élément dont ils ne parlent que brièvement et qui a son importance est que les Developers sont composés de tout spécialiste qui réalise le travail : développeurs, chercheurs, analystes, scientifiques, etc. 

Cette notion est en phase avec la démocratisation du cadre de travail au-delà du développement Software.  Pour démocratiser, le nom aurait d’ailleurs pu être réellement revu pour se détacher de développeurs, qui restent encore très connoté IT… peut être une évolution prévue pour la prochaine version ?  

Roxane Meyer, experte Scrum chez Saegus

Une revue des évènements agiles 

Bien qu’induit lors de sa version précédente, dans sa nouvelle version le Scrum Guide affiche clairement que le sprint contient l’ensemble du travail nécessaire pour atteindre le Product Goal tels que le Sprint PlanningDaily ScrumsSprint Review, ou encore la Sprint Retrospective. Cette formulation induit donc que les réalisations du Sprint Backlog ne sont plus les seules activités servant à l’atteinte du Product Goal, bien que représentant l’activité principale des Developpers.  

Le Sprint Planning, qui est l’évènement de planification du Sprint, se voit légèrement restructuré et son déroulé affiné en 3 sujets :  

  • Sujet 1 : Pourquoi ce Sprint a-t-il de la valeur ? 
  • Sujet 2 : Que peut-on faire pour ce sprint ? 
  • Sujet 3 : Comment le travail choisi sera-t-il effectué ? 

En plus du « Quoi » et « Comment » connu dans la version 2017, le sujet 1 vient ajouter une notion de « Pourquoi ». Ce « Pourquoi » fait directement référence au Sprint Goal, et vient formaliser ce sujet qui était uniquement induit dans les versions précédentes. 

Là où le Sprint Planning s’est vu restructuré, le Daily est devenu un évènement libre et ses 3 questions historiques ne sont plus proposées. Les Developpers choisissent maintenant 

Comment dérouler cet évènement tant qu’il reste concentré sur l’avancement vers le Sprint Goal.  

Dans la version 2020, si le Product Owner ou le Scrum Master travaillent activement sur des éléments du Sprint Backlog, ils participent en tant que Developers. 

Le Sprint Review ne voit aucun changement lui être attribué mais une précision importante : cet évènement n’est pas une simple présentation mais une réelle session de travail. Cet évènement doit être l’occasion de collaborer et identifier de nouvelles opportunités autour du produit. 

Le Sprint Retrospective, quant à lui, ne voit aucune modification majeure lui être attribuée mise à part une simplification de sa description.  

Point de vue de l’expert – quels sont les risques induits par les modifications des événements ?  

Il est vrai que lorsqu’on parlait de Sprint on avait tendance à penser uniquement aux US à réaliser. Or, en le pratiquant, on se rend bien compte qu’un sprint est composé de toute activité autour du produit peu importe sa nature (alignement des process métiers pour alimenter le backlog, tests utilisateurs, réalisation des items du backlog…) 

La participation potentielle du Product Owner et Scrum Master montre bien l’ouverture du Framework à d’autres domaines que le domaine IT.  Attention tout de même à ne pas perdre de vue que c’est la réalisation des items du Sprint Backlog qui reste la principale activité autour du Produit.  Bien que ravi de l’ajout de la notion « Pourquoi » dans le Sprint Planning, la suppression des questions du Daily dans le Guide peut laisser place à l’incertitude pour les jeunes équipes Scrum, qui pourraient ne pas dérouler correctement cet évènement et en perdre les bénéfices.  

Globalement, bien qu’en phase avec les modifications apportées qui recentrent sur l’essentiel de chaque évènement, la simplification du contenu et du déroulé de chaque instance – c’est-à-dire moins de détails pour les utilisateurs de Scrum – peut rendre son bénéfice et adoption complexe pour les équipes non-rompues à l’exercice.  Le Scrum Master prend alors tout son sens.  

Roxane Meyer, experte Scrum chez Saegus

Trois engagements supplémentaires pour renforcer l’empirisme de l’approche 

Le risque principal du Framework Scrum réside dans le manque d’engagements de la part de la Scrum Team. Ne pas se focaliser sur un objectif précis, tout en suivant à la lettre les processus – les rôles, les artéfacts, les évènements – c’est passer à côté de la raison d’être même de Scrum : créer de la valeur ajoutée pour sa cible.  

Les artéfacts représentent la valeur ou le travail livré.  Ils ont pour but d’assurer la transparence autour du produit.  

A partir de 2020, chaque artéfact contient un engagement (commitment) pour veiller à ce qu’il fournisse des informations qui renforcent la transparence et aide dans la mesure du progrès : 

  • Pour le Product Backlog, c’est le Product Goal :  
    • Le Product Owner porte le Product Goalet le partage avec la Scrum Team (et toute autre personne intéressée par le résultat du produit) qui guidera le travail et les décisions pendant toute la durée du développement produit. Cette nouvelle vision implique des changements dans l’appréhension des projets par les différents membres de l’équipe : le Product Owner est désormais plus orienté succès du produit que succès du projet. L’objectif final est bien de livrer un excellent produit, et non plus d’exécuter le processus projet avec excellence. Chaque Sprint doit dont se rapprocher de l’objectif Produit final (Product Goal) – et le Product Backlog répond aux attentes du Product Goal.  
  • Pour le Sprint Backlog, c’est le Sprint Goal:  
    • La Scrum Team s’accorde sur un Sprint Goal, associé à chaque Sprint Backlog: ce Sprint Goal permet désormais, au début de chaque Sprint, de guider les décisions qui seront prises tout au long de ce Sprint, et également de donner du sens aux tâches à réaliser, et d’améliorer la compréhension des objectifs par l’équipe.  Les Developers s’engagent ensemble à respecter cet objectif. Le Sprint Backlog est ainsi adapté au fur et à mesure pour répondre au Sprint Goal. 
  • Pour l’Increment, c’est la Definition of Done :  
    • La Scrum Team s’accorde sur une Definition of Done, qui pour chaque incrément livré décrit la qualité attendue par les parties prenantes du projet. Les Developers s’engagent à respecter cette qualité de livrable adaptée au fur et à mesure pour répondre au Sprint Goal. 

Ces engagements existent pour renforcer l’empirisme et les valeurs Scrum pour la Scrum Team et ses parties prenantes. 

Le point de vue de l’expert – Quel est l’impact concret de l’introduction de ces nouveaux engagements ?  

Finalement si on pratique le Scrum avant sa version 2020, la Definition de Done et le Sprint Goal ne nous sont pas inconnus.  Ces deux éléments étaient déjà présents dans les versions précédentes sans pour autant être un évènement, un rôle ou encore un artéfact. En les définissant à présent comme engagement de leurs artéfacts respectifs, l’importance de ces éléments est redéfinie pour les placer au centre de la gestion du produit.  

Le Product Goal est un nouvel ajout au Framework, qui a pris le pas sur la vision produit (Product Vision). Je reçois cette évolution de façon positive car l’objectif permet réellement de concrétiser la vision produit. Là où la vision était finalement plutôt utopique, le Product Goal permet de concrétiser en se donnant des objectifs mesurables, tangibles, déclinables dans le temps et surtout compréhensibles de tous.  Nous le savons, lorsque nous comprenons pourquoi nous effectuons un travail, nous sommes plus engagés, et ce Product Goal vient servir la compréhension du produit sur lequel on travaille. 

Ce qui pourrait encore manquer au cadre de travail, pour le rendre encore plus généraliste, est finalement la définition d’un produit. Nombreuses sont les personnes qui vont identifier un produit comme un livrable software, là où dans la définition même du mot, un produit est tout objet, bien ou encore service proposé par une entreprise sur le marché.  

Pour conclure, l’engagement étant l’une des valeurs du Scrum et un gage de réussite d’un projet, cette nouvelle notion d’engagement (commitment) est une évolution nécessaire du Framework.  

Roxane Meyer, experte Scrum chez Saegus

Conclusion 

Ces modifications résultent finalement en un Scrum Guide beaucoup plus simple à lire et à comprendre. L’ambition affichée des deux fondateurs était bien d’ouvrir le Framework à tous les domaines et équipes au sein d’une organisation – et cette nouvelle version avance clairement dans ce sens.  

Cependant, ces modifications laissent plus de place à l’interprétation. En étant moins prescriptif, le guide laisse potentiellement la place à des implémentations plus ou moins cadrées du Framework.  

Ce que l’on peut retenir en priorité, c’est l’attachement de plus en plus fort à l’objectif produit, et aux objectifs communs qui servent la valeur ajoutée créée pour l’utilisateur final.  

Le Scrum Guide 2020 introduit également la responsabilité du Scrum Master – ou du moins rend cette responsabilité plus visible et explicite. Cette nouvelle notion peut avoir un impact bénéfique au sein des organisations qui craignent parfois la dilution des responsabilités.  

Il est maintenant temps de tester ces nouveautés au sein de vos équipes Agile – et de mesurer l’impact opérationnel de ce nouveau Scrum Guide 2020.  

N’hésitez pas à nous partager vos avis en commentaires !  

Rédigé par Sara del Rio avec l’expertise de Roxane Meyer, Consultantes Acceleration Tactics chez Saegus.

On m’a posé il y a quelques semaines la question suivante : comment mesurer le niveau d’agilité d’une équipe Scrum ?

Cette question m’a d’abord laissée perplexe. Il n’existe pas de « méthode officielle » concernant le Scrum qui ait pu être approuvée globalement par la communauté Agile. Mais je me suis vite questionnée sur la possibilité de mesurer correctement ce niveau d’agilité. 

On m’a donné quelques heures pour me renseigner auprès des managers, du Scrum master et de l’équipe dans son ensemble – tous pratiquent déjà l’agilité au quotidien : le «  Daily  » est fait tous les matins, ils maîtrisent l’utilisation de l’outil Jira et d’après mes observations, les User Stories étaient complètes. Néanmoins, je n’avais toujours pas de réponse à ma question  : comment mesurer leur niveau de «  maturité agile »  ?   

Une chose était sûre  : la perfection n’existe pas, ni dans la réalité, ni dans la méthode Agile. Il faut constamment s’améliorer, se motiver pour atteindre l’inaccessible et ce, TOUJOURS en équipe. C’est la seule chose que je suis sûre de pouvoir affirmer de par mes diverses expériences dans le monde de l’IT  : sans travail d’équipe, il n’y a pas de réussite.

En gardant cela à l’esprit, j’ai pu y voir plus clair et je me suis demandée  : quels sont pour moi les quatre piliers de l’Agile  ? Quels sont les quatre fondamentaux de cette nouvelle méthode de travail  ? Pour moi, il s’agit de  :  

  • Communiquer  
  • Être régulier  
  • Documenter la démarche 
  • Obtenir et analyser les résultats  

#1 Communiquer

C’est la plus difficile à obtenir ! Il faut que l’équipe soit bienveillante pour que tout le monde puisse communiquer sereinement, sans hésiter à poser des questions, en pouvant partager ses doutes, et en se connaissant un minimum.

Les résultats d’une étude Wisembly/IFOP concernant la communication dans une équipe pendant une réunion sont stupéfiants  :

  • 20% des travailleurs pensent que leurs collègues monopolisent le temps de parole
  • 17% n’osent pas participer pour éviter les conflits
  • 16% ne se sentent pas assez libres de dire ce qu’ils veulent   
  • 10% ont le sentiment que leur opinion ne sera pas prise en compte

Ces chiffres ont été publiés avant la pandémie et la mise en place massive du télétravail. Aujourd’hui et avec la généralisation des réunions en ligne, les chiffres sont probablement plus élevés…

Outre les interactions personnelles, peut-on considérer que l’environnement de travail au sens plus large est un facilitateur dans la méthode Agile  ? Nous sommes conscients qu’il est plus que jamais difficile de réunir physiquement l’ensemble d’une équipe. Il est quand même généralement demandé aux collaborateurs d’être présents une ou deux fois par semaine. Pour autant, ces mêmes collaborateurs s’assoient-ils dans les mêmes espaces  ? Leur est-il facile de discuter  ? Les Product Owners sont-ils aussi disponibles  ?

#2 Être régulier

La ponctualité des réunions et leur durée sont des facteurs clés de la réussite de la méthode Agile. Ses deux principaux avantages sont que toutes les réunions sont limitées dans le temps et se déroulent au même moment et au même endroit. Si les règles sont respectées, aucun doute quant à son efficacité pour l’entreprise.

Selon Altassian, 91 % des employés ont déjà rêvassé pendant une réunion, 39 % déclarent même s’être endormis tandis que 45 % d’entre eux se sont déjà sentis dépassés par le nombre de réunions auxquelles ils ont dû assister. Si 73 % ont déjà effectué d’autres tâches pendant une réunion, 47 % des employés se sont plaints que les réunions sont ce qui leur fait perdre le plus de temps au travail.

Pour éviter tout cela, il est important de :

  • définir un ordre du jour clair pour chaque réunion
  • n’inviter que les collaborateurs essentiels à la bonne tenue de la réunion
  • définir clairement l’objectif pour que chacun accepte d’y participer

Nous avons parfois tendance à oublier que les réunions doivent être préparées à l’avance  : «  plus la préparation est difficile, plus l’exécution est simple et à l’inverse, plus la préparation est simple, plus l’exécution est compliquée  » ! Dans la méthode Agile, les réunions sont limitées dans le temps, préparées en avance et l’équipe sait toujours pourquoi elle se doit d’être présente et quel sera l’ordre du jour. Comme ces réunions sont périodiques, elles se répètent lors de chaque sprint permettant ainsi de clarifier l’objectif.

#3 Documenter la démarche

Même si le travail en Agile privilégie les logiciels opérationnels par rapport à des documents physiques, il n’en reste pas moins qu’un dossier complet avec toutes les données nécessaires, les explications, les rapports et les conseils sont plus utiles que vous ne pouvez l’imaginer. Non seulement pour les nouveaux employés mais aussi pour l’équipe dans sa globalité puisque beaucoup de tâches se répètent. Si dans ces dossiers tout est clair, bien expliqué et facilement accessible (il est essentiel que chacun puisse les trouver), ces documents représentent le meilleur moyen pour partager les connaissances acquises par l’ensemble des collaborateursConfluenceTeams ou Sharepoint sont de bons outils qui permettent de partager non seulement des documents mais aussi des compte-rendu de réunions, afin de toujours garder à l’esprit les décisions clés prises dans le passé.

Un point fondamental est d’utiliser correctement les outils Agiles qui sont mis à disposition, quel que soit le cadre utilisé par l’équipe (ScrumKanbanSafe…) et que toutes les informations y soient réunies.

Une autre erreur courante qu’il faut éviter dans le Scrum est la création d’User Stories incomplètes. Si décrire les tâches prend beaucoup de temps, il faut toujours garder à l’esprit que c’est un réel investissement pour l’avenir. Pour pallier à ce problème, il est bon de proposer des «  Backlog refinement meeting » avant la planification du sprint. Pendant cette réunion, les développeurs et Product Owners ont l’occasion de décrire en détails toutes les tâches à effectuer lors du sprint suivant.

Petit conseil  : si le Scrum master crée des graphiques personnalisés pour montrer la progression du sprint, c’est encore plus motivant ! JIRA, ou peu importe l’outil choisi, doit en plus être mis à jour quotidiennement, par tous les membres de l’équipe.

#4 Obtenir et analyser les résultats

Ainsi, la meilleure façon de mesurer l’Agilité est par les résultats obtenus. C’est le seul point “mesurable” des quatre piliers puisqu’il est le seul qui est quantitatif.  L’équipe a-t-elle terminé le sprint à temps ? Les tests sont-ils validés ? Le temps estimé était-il égal, inférieur ou supérieur au temps réel ? La définition de “done” (DoD) est-elle atteinte ? Selon KMPG, seulement 19% des entreprises livrent des projets réussis – du moins la plupart du temps. En tant que Scrum Master, j’ai vécu la frustration des équipes lorsque personne ne valide le test. Assurez-vous donc de trouver quelqu’un qui sera capable de le faire, même si cette personne fait partie de l’équipe, cela permettra de maintenir la motivation générale !

Pour conclure, je recommande – et ce dans un environnement de travail Agile ou non – de garder à l’esprit ce que j’ai évoqué plus haut  : sans travail d’équipe, il ne peut y avoir de réussite  ! Nous apprenons constamment des autres et tout se construit en équipe.

Enfin, je tiens à préciser que la méthode d’Agile n’est pas faite pour toutes les équipes. De nombreuses entreprises essayent de la mettre en place – en forçant – sans raison valable et simplement parce qu’elle apparaît comme un remède miracle. Ces entreprises tendent à oublier que la méthode Agile est conçue pour être personnalisable. Elle se doit d’être adaptée à chaque équipe, à chaque projet et à la culture de chaque entreprise. Par contre, la méthode Agile est destinée à beaucoup plus de secteurs d’activité que vous ne le pensez  : elle peut avoir de l’impact dans des départements non-IT comme les RH, le marketing, les finances et pour beaucoup d’autres projets…

N’hésitez pas à me faire savoir ce que vous pensez de cet article  ! Et si vous êtes curieux et voulez découvrir la méthode Agile, son organisation ou ses outils, n’hésitez pas à contacter l’équipe Saegus ou moi-même en me rejoignant sur LinkedIn.

Rédigé par Blanca Espinós Ayuela, Consultante Acceleration Tactics chez Saegus.

Saegus se mobilise afin de contribuer à l’effort National, en lien avec les dernières annonces du gouvernement concernant la pandémie COVID-19. 

 

En ces temps exceptionnels, outre nos inquiétudes sanitaires, nombreux sont les questionnements sur l’impact du télétravail sur les projets en cours, sur l’organisation des équipes et leur collaboration, sur la qualité du delivery

La question du comment est partout : 

  • Comment piloter et suivre les projets à distance ? 
  • Comment continuer d’animer des ateliers Design Thinking, des cérémonies Agile, des hackathons… ? 
  • Comment mener des observations terrain ou encore des tests utilisateurs sans présence physique mais avec la même qualité d’inputs ? 

C’est pour cela que nous lançons une série de webinars publics pour partager largement nos expertises sur ces sujets d’animation, facilitation et collaboration. Nous vous proposons des sessions dédiées si vous souhaitez approfondir les sujets évoqués. 

Liste des webinars solidaires Saegus :

Dernière mise à jour le 19/03/2020 à 12:00 heures 

WEBINAR #1 : Cadrage digitalisé 
Mardi 24 mars de 11h à 12h 
 

Comment digitaliser le cadrage de mon projet, produit ou service, de l’idée jusqu’à la vision et au backlog associé ? 

#stayathome #staysafe #stayconnected


WEBINAR #2 : Pilotage Digitalisé 
Jeudi 26 Mars de 11h à 12h 
 

Comment suivre et piloter mes projets, produits et services, à distance ?  


WEBINAR #3 : Animation d’ateliers distanciels 
Mardi 31 mars de 11h à 12h 
 

Comment animer les ateliers Design Thinking à distance, de bout-en-bout (idéation, co-création, priorisation, prototypage, tests…) ? 


WEBINAR #4 : Les cérémonies Agile à distance 
Jeudi 2 avril de 11h à 12h 
 

Comment animer l’ensemble des cérémonies Agile à distance (gestion du backlog, Sprint Planning, Daily, Sprint Review, Retrospective…) ? 


WEBINARS SUR DEMANDE 

Nous vous proposons des sessions sur demande sur les thématiques suivantes :  

  • Comment animer mon comité projet à distance,  
  • Comment animer mon comité de direction à distance,  
  • Comment maintenir le contact entre les membres de mon équipe en contexte de travail à distance… 

#stayathome #staysafe #stayconnected