Est-il possible d'accompagner à l'agilité un bureau d'études de 15 personnes ?
Pourriez-vous faire le lien avec ce qu'on a fait pendant l'atelier et un vrai développement de process ?
Ce que nous avons expérimenté sur un temps très court (90 minutes), ce sont quelques postures, techniques et outils qui font partie de l’approche agile.
Il en existe bien d’autres, pour satisfaire à une démarche agile, dont l’objectif est de s’auto-organiser, pour livrer le plus tôt possible puis régulièrement un produit de plus en plus adapté aux besoins de celles et ceux qui doivent l’utiliser.
Faut-il adapter la démarche agile en fonction de la culture d'entreprise ?
Oui ! L’agilité est un état d’esprit (Test & learn), qu’on peut mettre en œuvre en adaptant différentes démarches potentielles (Scrum, Kanban, SAFe…).
Ces différentes démarches permettent de tenir compte, entre autres, des spécificités de nos cultures d’entreprise, mais aussi des types de produits à livrer, des individus qui vont fabriquer ces produits, des utilisateurs pour lesquels ils vont réaliser ces produits et du contexte notamment économique, technique, légaux… dans lequel s’inscrivent nos réalisations.
Les rôles agiles : comment les identifier et quel est leur mission ?
Comment gère-t-on les indisponibilités des acteurs ?
L’agenda du projet étant connu très en avance (cérémonies récurrentes, enchainées dans des Sprints de même durée), il est assez aisé d’anticiper les vacances de chacun, d’en déduire les impacts sur la vélocité (capacité de production de l’équipe) et de prévoir des remplacements temporaires éventuels. Les indisponibilités imprévues sont prises en compte quotidiennement à la suite du daily meeting, en se réallouant et/ou adaptant les tâches entre membres de l’équipe.
Comment gère-t-on une personne de l'équipe non productive ?
L’auto-organisation des équipes Agiles produit en général une implication plus forte et un positionnement positif des membres de l’équipe. Mais de nombreux facteurs peuvent induire des intérêts divergents de la part de membres de l’équipe. Le temps important accordé très régulièrement aux rétrospectives permet de lever précocement les problèmes d’implication de membres de l’équipe, de les creuser au moyen d’activités identifiées et documentées et de tester des actions correctives dès le Sprint suivant .
A quoi s'applique (ou ne s'applique pas) l'Agilité ?
L’agilité est avant tout un cadre et des bonnes pratiques pour gérer
efficacement tout type de projets. C’est donc comme si on demandait à
quoi s’applique ou non les techniques de gestion de projet classiques.
Cependant, l’agilité se révèlera particulièrement efficace dans un
contexte VUCA (Volatil, Uncertain, Complex & Ambiguous), notamment pour :
- explorer de nouveaux objectifs ou besoins
- utiliser de technologies émergentes encore mal maîtrisées
- fournir très rapidement les premiers prototypes d’un produit minimum viable (MVP)
- amener à être très vite confronté avec son marché
Quels livrables peuvent être envisagés sur un produit non IT ?
A chaque itération, l’équipe livre un prototype plus évolué, mais des
fonctions peuvent être simulées ou incomplètes au départ, pour faire réagir l’utilisateur sans encore offrir tous les usages visés. Beaucoup d’autres exemples (efficaces) existent dans bien des domaines hors IT : les livrables peuvent être une maquette, une présentation, un dessin, une procédure, une vidéo, …
A vous de décider en fonction de votre contexte.
A quoi s'applique moins l'agilité ?
Deux grands cas de figure s’appliquent moins à l’agilité :
1) On peut identifier une limite aux approches agiles pour réaliser des
objectifs dont les parties prenantes seront éloignés, indifférents, voire hostiles.
2) L’agilité ne sera par ailleurs pas forcément d’un grand secours dans des contextes très stables et aux contours fonctionnels et techniques très maîtrisés depuis longtemps.
Comment se lancer dans l'agilité ?
2 idées pour commencer à expérimenter l’agilité :
- sur un projet sans trop d’enjeux, mais dont les conditions de réalisation et les objectifs sont mal connus : cela permettra de maximiser les résultats.
-
sur l’animation d’ateliers et réunion, en mettant en oeuvre les techniques utilisées en atelier.
Quels sont les « downsides » des méthodes agiles ?
Une fois le cadre agile mis en place, les difficultés que l’on rencontrera seront bien souvent d’ordre humain. Les changements induits par l’agilité doivent être accompagnés pour que les parties prenantes (équipe projet, clients, direction,
sous-traitants, …) comprennent la démarche et les objectifs, y adhérent et tirent effectivement tout le bénéfice de ces approches.
Quels sont les risques psycho-sociaux susceptibles d'être provoqués indirectement par l'agilité ?
L’agilité, dont la mise en place crée l’adhésion et la motivation, risque, si elle est imposée de manière inappropriée de créer un stress humain et de dégoûter les participants de ces approches. De même, la “fausse agilité”, qui peut se manifester par des injonctions à l’adaptation permanente et à une vitesse accrue sans autonomie ni alignement, engendre burn-out et surmenages.
Comment impliquer la hiérarchie ?
Il n’y a pas de chef dans une équipe Agile, mais il est important d’impliquer la hiérarchie, notamment dans l’évolution et la priorisation des besoins du Product backlog. Il est recommandé de l’inviter régulièrement aux review démontrant l’état d’avancement du produit, le retour des utilisateurs et l’avancée de leurs demandes. Les impédiments peuvent également être remontés, ainsi que les constats et actions issus des rétrospectives. Elle peut être destinataire d’indicateurs de vélocité, de la vision du planning macroscopique à date et de l’évolution des critères de qualité.
Que faire des "tâches" non finies à la fin d'un sprint ?
Les User Stories non terminées (voire non commencées) sont réintégrées dans le Product Backlog.
Ceci permet d’éviter d’accumuler des User Stories « à terminer », qui obèreraient la capacité de l’équipe à sélectionner à chaque itération les User Stories les plus prioritaires à réaliser.
Ces User Stories non terminées pourront évidemment être à nouveau sélectionnées pour l’itération suivante, lors du Sprint planning. Mais ce n’est pas une obligation et il est possible que ces Users Stories à moitié réalisées demeurent longtemps encore dans le Product Backlog, voire ne soient finalement jamais sélectionnées à nouveau dans un Sprint.
Comment prioriser au mieux ?
Diverses techniques sont à la disposition du Product Owner pour prioriser les User Stories du Product backlog.
Les techniques de priorisation utilisées par les projets classiques (non agiles ou dits « planifiés ») restent globalement valables en agilité. Mais si on souhaite rester fidèle à l’esprit radical de l’agilité, on peut recourir à la qualification du risque à ne pas faire, c’est à dire mesurer les conséquences de la non réalisation d’un besoin. Ce risque pourra être identifié et quantifié selon différents axes : financier, temps perdu, image, respect de contraintes légales, …
Il est assez aisé de les présenter aux décideurs pour les faire trancher sur la priorité relative entre plusieurs
Comment s'assurer de l'adhésion de chacun aux règles de l'équipe ?
C’est une question qui revient souvent au sein des groupes. Et la réponse est simple (sur le papier) :
Que l’équipe crée, gère et adapte ses propres règles !
Et c’est justement ce que prône l’agilité (Inspect & Adapt, Test&Learn et autres rétrospectives).
Le PO peut-il demander aux dev. d'assister systématiquement aux réunions avec le client ?
Il n’est pas nécessaire (voire carrément trop lourd) que ce soit systématique, mais le/la Product Owner doit s’appuyer sur l’expertise des développeurs pour rédiger les User stories ou toiletter le Backlog.
Les laisser échanger avec les utilisateurs est donc une bonne idée.
Qu'est ce que les designers peuvent donner comme livrables toutes les 3 semaines ?
On peut imaginer de livrer un “banc de démonstration”, qui simule ce que fera le produit, puis le miniaturiser, ajouter des fonctions, une architecture plus solide, des éléments techniques réels…
Quid de la relation contractuelle dans une démarche Agile ?
Un contrat agile fixe en général une durée (en nombre de Sprint) et le prix qui en découle (sur la base du coût d’un Sprint). Il peut également fixer des conditions de réalisation (Definition of Done, rôles, backlog…).
Il précise parfois des conditions d’arret précoce et/ou de prolongement (Sprint supplémentaire).
A quel moment et sous quelle forme on se dit « on arrête, on a fini » ?
Un projet Agile prévoit la plupart du temps une date de fin de projet correspondant au nombre de Sprints prévus et donc au budget engagé.
A cette date, il restera des besoins dans le Product backlog, jamais considérés assez prioritaire pour avoir été sélectionnés dans un Sprint. On peut décider (ou pas) d’allouer un nouveau budget pour en réaliser certains au travers de Sprints supplémentaires.
On peut aussi décider de stopper un projet plus tôt à la fin d’un Sprint, si on estime que ce qui est livré est suffisant.
Comment s'assurer que le périmètre n'évolue pas ?
Une évolution du périmètre n’est pas ingérable !
Si le périmètre du produit à réaliser change (nouveaux acteurs/cas d’utilisation par exemple), le backlog est complété en conséquence et les priorités évolueront en fonction.
Cela entraînera une modifications des incréments livrés et nécessitera éventuellement de recalibrer l’enveloppe (délai/coût) du projet.
Pas de chef en agilité, mais peut-on avoir un leader ?
Il n’y a pas de chef(fe) dans une équipe Agile, personne n’impose à un membre de l’équipe de travailler sur un sujet ou un autre. Les décisions sont prises ” par consensus “et des techniques existent pour parvenir à ce consensus sans recourir à une autorité interne ou externe.
Les rôles de Product Owner et Scrum Master guident l’équipe, mais ont davantage de responsabilités que de prérogatives.
Enfin, il n’y a pas de sous-équipes ni de rôles de leader parmi les développers, même si leurs domaines d’expertise respectifs peuvent donner à leurs propositions davantage de poids.
Que dire à un Product Owner qui n'arrive pas à prioriser les US ?
Traduire les priorités n’est pas une tâche aisée et le/la Product Owner ne doit pas simplement céder à la dernière ou la plus forte demande d’un utilisateur pour prioriser ses besoins.
Pour se forger un avis éclairé, il/elle aura parfois besoin de l’expertise de membres de l’équipe, voire d’avis extérieurs.
Un•e Scrum Master ou un coach Agile pourra apporter son aide en proposant des techniques et en aidant à leur mise en œuvre si les priorités ne sont pas suffisamment traduites dans le Product backlog au moment de sélectionner les User Stories pour planifier la réalisation d’une itération.
Quand et comment aborder les problèmes lorsqu'un sprint n'a pas marché ?
La rétrospective, qui a lieu à la toute fin d’un Sprint, est consacrée à l’étude, par l’équipe agile, de ce qui fonctionne et de ce qui doit être amélioré.
L’équipe pourra aborder les problèmes techniques rencontrés, mais surtout la manière dont ils ont été identifiés -ou non – lors des daily meetings, la manière dont l’équipe a pris en compte ces difficultés et la capacité d’entraide entre les membres de l’équipe.
Comment estime-t-on le contenu d'un sprint ?
L’équipe réalise une estimation collaborative des User Stories, par exemple avec la technique du Planning Poker, qui permet la compréhension et l’expression de chacun.
La complexité relative des User Stories est confrontée à la vélocité de l’équipe (mesurée sur les Sprints précédents), afin de permettre la sélection d’un nombre de User Stories raisonnablement livrables à la fin du Sprint.
La répétition des Sprints dans les mêmes conditions (durée, équipe, ) permet d’affiner progressivement la précision de ces estimations.
Faut-il obligatoirement lier ces estimations à des jours/homme ?
L’approche agile déconseille d’estimer la réalisation des User stories en jours/hommes.
Cette approche présente en effet l’inconvénient de nécessiter la définition préalable des tâches par les membres de l’équipe, donc de figer la réalisation et l’assignation des tâches.
Et si on fige la réalisation, on doit décrire les fonctionnalités en amont, donc fixer une sorte de cahier des charges.
Quelle valeur faut-il sélectionner pour estimer un projet informatique (T-shirt / Points) ?
Les agilistes utilisent traditionnellement un nombre de points dont la liste correspond à la suite de Fibonacci : 1, 2, 3, 5, 8, 13, 20, 50 et 100. Cette notation s’est révélée efficace, mais assez abstraite à manipuler et on préfère généralement aujourd’hui recourir à une estimation basée sur les tailles de tee-shirt courantes, à savoir XXS, XS, S, M, L, XL et XXL.
La notation en taille de tee-shirts s’est rapidement imposée pour sa simplicité de compréhension et elle est largement préférée aujourd’hui, ce qui n’exclut pour autant pas l’utilisation des points si l’équipe le décide ou si elle y est davantage habituée.
Quel outil peut-on utiliser pour notre gestion de projet agile ?
On peut pratiquer l’Agilité sans outil numérique, avec des PostIt et c’
est d’ailleurs comme ça qu’il est souvent le plus efficace de commencer un projet Agile. On peut rapidement recourir à des outils numériques simplistes pour gérer un Product Backlog ou l’avancée des tâches d’un Sprint, comme
un simple fichier Excel ou des outils en ligne gratuits comme Trello.
Le mot d’ordre est donc (comme toujours en Agilité) Test & Learn. Commencez par exemple par partager l’information en toute transparence “sur le mur” d’un bureau, puis transférer le contenu dans des outils qui s’adapteront à l’usage du projet en même temps que celui-ci grandira.
Est-il systématique de fixer la Definition of Ready pourles User Story ?
La Définition of Ready (DoR ou Définition de prêt) fixe les conditions nécessaires pour pouvoir considérer qu’une User Story est prête à être sélectionnée par l’équipe pour être réalisée lors du prochain Sprint.
Une DoR peut par exemple exiger que la User Story soit rédigée sous une forme spécifique, que ses critères de test soient définis, que sa priorité soit établie et que sa complexité soit estimée par l’équipe.
Nombre d’agilistes recommandent que la DoR soit établie et qu’une User Story s’y conforme pour pouvoir être sélectionnée dans un Sprint. D’autres voix estiment qu’il suffit que l’équipe s’engage sur sa compréhension pour permettre qu’elle la sélectionne.
Comme souvent, on conseille de recourir à cette pratique jusqu’à ce que l’équipe soit suffisamment aguerrie dans ses pratiques pour se permettre de s’en passer.
Comment bien organiser la démo (Sprint Review) et le sprint planning suivant ?
La démo fait souvent apparaître de nouveaux besoins ou des besoins modifiés. De son côté, le Sprint Planning commence par sélectionner dans le Product backlog des User Stories prêtes à être réalisées dans le Sprint (et donc censément être « Ready »)
C’est pourquoi la 1ère partie du Sprint Planning prévoit suffisamment de temps (4 heures, en principe), pour permettre à l’équipe de rendre Ready celles parmi ces nouvelles User Stories qui seraient considérées comme suffisamment prioritaires pour être susceptibles d’être immédiatement intégrées au Sprint suivant.