Archive d’étiquettes pour : Management

L’approche Agile est dépassée !

Cette fois-ci on y est, l’approche Agile est définitivement dépassée. Il faudra faire évoluer le manifeste Agile, ou compléter cette approche avec d’autres méthodes qui apporteront plus de sens à nos projets et à nos sociétés !

innovation

L’heure du bilan est encore trop hâtive, mais, regardons la réalité bien en face, l’appel systématique à l’Agile pour les projets informatiques nous a tous rendus un peu idiots, et il va falloir la dépasser, et aller au-delà de celle-ci. En fait, c’est aussi l’appel systématique aux frameworks de type Scrum, quel que soit le contexte du projet, qui doit être aussi remis en cause. En effet nous nous étions tranquillement réfugiés derrière nos beaux tableaux Kanban avec nos jolis Post-its, et on se rend compte qu’un petit virus provoque une belle pandémie qui stoppe en quelques jours toute l’économie mondiale ! On a l’air malin avec nos belles applications Agiles, pleines d’innovations, nous permettant de réserver un logement avec Airbnb pour notre prochain séjour à Venise, nous permettant de réserver un Uber, nous permettant d’acheter un billet d’avion dernière minute… Alors que nous sommes tous confinés chez nous et que le besoin réel, c’est juste des masques, des lits d’hôpitaux, du gel hydroalcoolique, des aide-soignantes pour s’occuper des malades du virus, des paysans pour nous nourrir, des éboueurs pour vider nos poubelles ! Nos Sprints, nos user story, nos Epic n’ont rien prévu de tout cela.

Et je vois encore sur Internet, des consultants nous dire, grâce à l’agilité, nous traversons la crise et sommes efficace… Mais on les arrêtera jamais ! Regardez la réalité en face !

L’Agilité nous permet de vivre au mieux la crise

Beaucoup vont me dire que c’est l’agilité qui nous permet de réagir au mieux face à la situation inédite de la pandémie du Covid-19. Et ils ont bien raison. Les organisations les plus « Agiles » sont celles qui vivent le mieux cette période, en ayant des équipes qui savent s’auto-organiser grâce à leurs interactions, et leur capacité d’adaptation au changement.

Oui, très bien, mais après… Il va falloir sortir de cette crise, et sans plan, on risque de nouveau d’être dans une nouvelle crise, financière cette fois-ci. Et l’agilité, qui privilégie l’adaptation au changement, plus que le suivi d’un plan, risque de nous amener petit à petit, dans une crise profonde. Nous avons survalorisé la flexibilité et l’agilité, sans imaginer que l’économie et la société tout entière pouvaient se figer brutalement, faute d’avoir un véritable plan en cas de pandémie.

Il faut et il est urgent de dépasser l’agilité

Il faut donc dépasser l’agilité désormais. C’est-à-dire, être Agile, dans les phases de management qui le nécessite et avoir un plan, être prédictif sur le moyen long terme. Il faut enfin comprendre que l’Agilité, n’est pas une approche de management et d’organisation de projets qui répond à tous les besoins. Et l’agilité a de vraies faiblesses, dans le moyen long terme !

Le monde est plus complexe que ce que veut nous résumer l’approche Agile. Il faut affronter cette complexité, et celle-ci ne fait pas appel uniquement à de l’agilité. Dans l’agilité, un product Owner doit se dire, « qu’elle est l’opportunité de faire ceci ? ». Existait-il un product Owner se disant il y a quelques mois, il y a une belle opportunité à fabriquer des masques et des respirateurs pour les hôpitaux ? Non, car il n’y avait aucune valeur à le faire il y a quelques mois. Les seuls qui ont pu avoir cette approche, c’est ceux qui avaient une approche par le risque, et non une approche 100% agile. Des approches projets plus en mode prédictive nous auraient mieux préparées à une pandémie que l’agilité !

La réalité, c’est que de nos jours, nos organisations, nos sociétés, sont en interaction avec d’autres systèmes et sont devenues très complexes. Cela crée de l’imprévu, et rapidement, un changement à de grandes répercussions. L’agilité a pour force d’être une approche adaptative. D’où l’importance du contexte ! L’agilité doit continuer à vivre, s’il faut une approche adaptative. Mais si le contexte change, si le sens du projet le nécessite, il faudra dépasser la simple méthode Agile. Il faudra se dépasser, ne plus se réfugier derrière des sprints, des Kanban et des post-its. Il faudra prendre plus de recul, donner plus de sens à nos projets.

Pourquoi en sommes-nous là ?

Je crois un peu par fainéantise. Les méthodes Agiles, comme SCRUM ou SAFe (SAFe : Scaled Agile Framewok), ont été très bien commercialisées par des consultants, qui avaient plus l’air de pro du marketing, que de pros en conduite de projet (cela reste mon avis). Et ce qu’ils avaient à nous vendre avait du sens et des valeurs. Le manifeste Agile a et aura toujours ce sens et ces valeurs. Toutes les équipes ont donc adopté en masse ces approches, en faisant bien souvent, du pseudo Agile, en faisant perdre du sens aux valeurs de ces approches. En fait, les équipes ont suivi les prescriptions, au lieu de se focaliser sur les valeurs de ces approches : il faut faire comme ceci, comme cela. On parle d’ailleurs malheureusement, plus souvent de SCRUM que du manifeste Agile (je vous conseille de relire les quatre valeurs et les douze principes fondateurs).

Que devons-nous faire maintenant ?

Partir du pourquoi et voir loin. Donner plus de sens au pourquoi du projet, au sens de nos organisations et sociétés, pour mener des projets avec les outils que vous avez à votre disposition. Cela est très différent de dérouler le processus SCRUM à chacun de vos projets sans vous poser les vraies questions sur le sens. Il va nous falloir faire plus d’efforts et être plus intelligents dans nos projets !

Qu’est-ce que l’intelligence dans le pilotage de projet ?

L’intelligence dans le pilotage de projet, c’est de savoir sortir des méthodologies, des processus, pour se focaliser sur le sens du projet, sa finalité. La seule vraie approche projet qui fonctionne, c’est celle qui s’adapte à votre projet. Ce n’est pas l’inverse, votre projet qui doit s’adapter à l’Agilité !

La méthode et l’intelligence ne servent à rien si l’on ne se sert pas des informations que l’on peut traiter pour préparer nos décisions de conduite de projet. Or, ces décisions de conduite de projets ne peuvent pas rester les mêmes s’il s’agit de gérer l’équipe de développement sur site ou en télétravail, gérer les délais, gérer les aspects financiers, gérer un événement externe de type épidémie. Plus vous allez arriver à vous projeter loin dans le temps, plus vous allez être capable de gérer beaucoup d’inconnues, d’éléments soumis à des conditions internes et externes, plus vous serez à même de mener à bien vos projets.

J’ai essayé de schématiser cette vision projet et les exigences associées :

Exigences pour la gestion de projet

L’intelligence dans la conduite de projets c’est :

  1. savoir récupérer des informations dans son environnement et pas que dans ses outils ;
  2. pour déceler ce qui les relient pour comprendre la situation ;
  3. afin de s’en servir pour prendre les meilleures décisions.

L’inconvénient de ce que je vous dis là, c’est que c’est plus complexe, et plus difficile à vendre pour tous ces consultants qui se sont collé une belle étiquette d’expert en agilité, spécialiste SCRUM ou SAFe !

Les méthodes efficaces sont celles qui sollicitent notre intelligence

Plus vous suivez une méthode de projet à la lettre, en suivant par exemple les processus SCRUM, moins vous sollicitez vos modes supérieurs de décisions dits intelligents.

Il y a d’ailleurs des chercheurs qui ont démontré que la compétence était inversement proportionnelle au degré de procédure de l’activité (réf. Guy Le Boterf). Bref, plus on vous mâche le travail avec de la méthode, type application de SCRUM à la lettre, moins vous réfléchissez, et plus ce sera difficile de donner du sens au projet. Donc, moins il y a de procédures, plus on est intelligent et plus c’est « procéduralisé » plus … non, je ne le dirais pas quand même !

Adoptons des démarches projets pour réfléchir bien, vite, en se projetant dans le temps

Il nous faut nous focaliser sur des démarches projets et mental nécessaire à une gestion « proactive » et qui donnent du sens.

Oui, car nous devons prendre en compte la complexité du monde et de nos sociétés. Regardons bien l’impact du Covid-19 sur nos sociétés et projets. Il nous faut absolument dépasser l’agilité, elle nous a permis de grandir encore en pilotage de projet. Cette fin du tout agile va nous permettre de mieux nous adapter au sens que l’on va donner à nos projets désormais. Il nous faut aller sur des méthodes et des comportements qui sollicitent notre intelligence, ce qui nous permettra de mieux affronter les défis de l’après Covid-19, d’affronter les défis de demain et la complexité de notre monde.

Il est vraiment temps et urgent d’aller au-delà de l’agilité.

Vous avez aimé cet article ? Alors partagez-le avec vos relations en cliquant sur les boutons ci-dessous :

 

Vous devez participer à l’un de vos premiers projets avec une méthodologie de type Agile ! Bienvenue dans ces approches de projets qui donnent de l’importance aux individus et à leurs interactions.

Vous allez vous sentir proche de l’équipe de réalisation, avec beaucoup d’interactions avec chaque membre de l’équipe. C’est ce qui fait la force de ces approches projets Agile.

En effet, parmi les quatre grandes valeurs de l’approche Agile, on retrouve la notion d’équipe – « Les individus et leurs interactions plus que les processus et les outils » et la collaboration – « La collaboration avec les clients plus que la négociation contractuelle ».

Mais quelle déception dès les premiers échanges avec l’équipe informatique pour un francophone ! Dès le départ, on se retrouve avec un jargon abscons pour un non-anglophone. N’est-il pas possible en informatique de se mettre à la portée des individus, et de prendre en compte leur langue ! L’approche d’un projet avec l’agilité, c’est d’être plus humain, et donc d’éviter de perdre du monde en route avec un anglicisme abscons !

Alors, ci-dessous, je liste tous les mots, sigles, acronymes et expressions que j’entends et que j’essaye de rendre compréhensibles par tous.

Expression AgileTraduction
Product Owner Responsable du projet côté équipe métier, commanditaire du projet, celui qui représente l’équipe ou les utilisateurs qui vont utiliser au final l’outil
Stakeholders Partie prenante, utilisateurs qui vont utiliser ou dont le travail va être impacté par l’outil
User storyCas d’usage de l’outil, ou récit utilisateur… Cela s’exprime simplement en français avec des phrases de types : En tant que [personne / fonction / rôle], je souhaite [souhait] afin de [but / résultat]
SprintSprint, itération, lot, ou un cycle de réalisation avec un résultat visualisable pour l’équipe, ou une itération de réalisation de l’outil final
Backlog Liste de fonctionnalités ou des besoins du projet
Scrum Mêlée : méthode d’organisation du projet pour sa réalisation
Sprint review Retour et révision en équipe sur les derniers livrables avec une critique objective et constructive pour s’améliorer
KanbanFlux de travail, tableau de travail
EpicRegroupement de besoins utilisateur en ensemble logique
Story points Estimation de charge de travail pour la réalisation du prochain cycle, pour évaluer si c’est réalisable ou non

Cette liste n’est pas exhaustive. Si vous avez des propositions de corrections ou d’ajouts, je suis preneur. Le but étant que tous, nous puissions nous sentir bien, et impliqués dans nos projets…

Vous avez aimé cet article ? Alors partagez-le avec vos relations en cliquant sur les boutons ci-dessous :

 

Interrogé dernièrement dans le cadre de la mise à jour d’un schéma directeur informatique, il nous a été demandé d’arbitrer entre différents projets informatique pour décider de les lancer ou non. Le « Go ? No go ? » est peut-être la question la plus fréquente et la plus importante qu’un responsable de projet (avec l’aide de ses collègues) va se poser avant de prendre en charge un projet, qu’il soit en approche projet « prédictive » ou agile. Est-ce la bonne formulation pour décider ou non de lancer un projet et quelles sont les autres variantes.

De nombreuses approches de gestion de portefeuille de projets estiment que le « Go ? No go ? » est un processus de prise de décision trop binaire, ce que l’on peut donc considérer comme une erreur. Quelques exemples de décision d’y aller pour un projet :

  • Nous avons réalisé une bonne année, nous avons le budget, c’est le moment de nous lancer dans ce nouveau projet.
  • Parmi la concurrence, il va y avoir une nouvelle offre plus performante que la notre. Et si on avançait notre lancement de projet de quelques mois ? Cela nous permettrait d’aborder cette concurrence dans de bonnes conditions.
  • Avec de la marge supplémentaire ajoutée au planning, j’accepte d’embarquer dans mon projet les futures demandes du marketing non exprimées à ce jour, et je lance mon projet en l’état.
  • Et si on découpait le projet en s’arrêtant à mi-parcours pour faire un petit état des lieux sur les nouveaux besoins, avant d’entamer la deuxième phase et limiter les risques ? On lance de suite le projet et on laisse ainsi les idées se mettre en place et se préciser et on continue après avec de bonnes visibilités sur les fonctionnalités à offrir et à ajouter à notre projet.
  • Les conditions du projet sont proches de mes limites en gestion de projet et des connaissances techniques de l’équipe. Je décide de partir avec un consultant plus expérimenté, qui en plus connaît bien cette nouvelle technologie. Je l’engage contractuellement jusqu’à la fin estimée de mon projet.

Du point de vue gestion de projet, le « Go ? No go ? » est souvent une erreur, voire un danger. En effet, si au vue des conditions internes et externes au projet, un décideur ou un chef de projet choisit la réponse « Go », il part et lance son projet avec le sentiment que le déroulement pourra se réaliser dans son intégralité suivant le plan initial. En clair, il se met des œillères, et aura du mal à changer de plan de projet si les conditions sont différentes des prévisions.

Les nouvelles approches de gestion de projet, et en particulier l’agilité, proposent donc une variante : « Start / Continue ». L’expérience sur les nombreux projets nous a fait comprendre à quel point il est important de toujours rester méfiant vis-à-vis des prévisions initiales d’un projet et d’avoir un plan B, voir C, D…

Avant le lancement, le chef de projet doit analyser tous ses paramètres projet et conclue que le lancement du projet est possible. La prochaine réflexion se fera une fois le projet lancé, à savoir si celui-ci peut se poursuivre jusqu’à destination suivant le plan projet initial, ou s’il y a nécessité de se dérouter, c’est à dire, modifier le périmètre, les délais, le budget, l’équipe… Ainsi, le chef de projet n’arrête pas le processus de prise de décision une fois le projet lancé. Il sait que les conditions lui permettent dans un premier temps de démarrer son projet, et il affinera l’analyse une fois lancé afin de répondre à la seconde interrogation : « Continue ? ».

Conclusion

Ces stratégies de conduite de projet, basées ou non sur les approches agiles, demandent un peu d’expérience (avant de se lancer dans des prises de décisions complexes), de jugement et bien sûr nécessite de la préparation en amont. Elles n’excusent en rien les mauvaises prises de décisions ou les comportements du genre « On va voir ce que ça donne une fois le projet lancé ou les premières livraisons effectuées ». Un projet ce n’est pas binaire, il faut savoir ajuster son pilotage et ses décisions tout le long de son déroulement, et jusqu’à la fin, pour bien le finaliser.

Vous avez aimé cet article ? Alors partagez-le avec vos relations en cliquant sur les boutons ci-dessous :

 

Méthode Agile, agilité en entreprise, agilité en gouvernance… ce mode de management de projets est à la mode depuis maintenant quelques années. Ce management « agile » est inspiré d’une approche dans le développement d’applications informatiques. Cette approche a été conçue pour remédier aux écarts constatés entre les attentes des utilisateurs et les outils informatiques livrés suite aux développements. Pour cela, on applique un manifeste qui conseille l’adaptation aux changements, plutôt que le suivi d’un plan, on livre fréquemment le logiciel informatique fonctionnalité par fonctionnalité, on privilégie le dialogue en face à face via des points quotidiens.

Cette approche projet et de management d’équipe a eu un tel succès dans l’informatique qu’elle a rapidement été appliquée au niveau des autres entités de l’entreprise, RH, marketing, production.

Le succès a été tel que l’approche agile est arrivée à l’Elysée et le terme est fréquemment employé par le président français lui-même, Emmanuel Macron.

Mais désormais, Emmanuel Macron doit rire jaune avec l’approche agile et les gilets (il fallait bien que je place quelque part ce jeu de mots un peu tordu … bon, ça c’est fait 😉 ).

En effet, avec la crise des « gilets jaunes », on constate une nouvelle fois, l’importance de la bonne prise en compte des parties prenantes, de la conduite du changement, de la gestion des risques… dans tout projet, qu’il soit agile ou non. On ne peut que constater en France, que l’approche agile du nouveau gouvernement et la rapidité de la mise en place des nouvelles réformes n’ont pas obtenu l’adhésion de toutes les parties prenantes, c’est à dire, de tous les Français.

Moralité, au 21e siècle, et malgré l’approche agile, on peut aller droit à l’échec d’un projet, qu’il soit informatique, d’un autre secteur de l’entreprise ou politique.

Donc, un conseil à notre président et aux managers, oui à l’agilité, mais pas au détriment des parties prenantes de vos projets, sinon, vous allez vous prendre une veste, qu’elle soit jaune ou pas ! Avant de vous lancer un peu trop vite dans vos « sprints » projets, analysez bien les impacts sur les parties prenantes, essayer de répondre à leurs attentes et prenez en compte l’ensemble des acteurs impliqués ou pouvant influencer votre projet. Ce n’est pas simple, mais c’est tout le charme du management et des facteurs humains !

Vous avez aimé cet article ? Alors partagez-le avec vos relations en cliquant sur les boutons ci-dessous :

 

Cette citation, « quand il y a un doute, c’est qu’il n’y a pas de doute !« , entendue lors de mes débuts de jeune pilote de planeur, s’adapte parfaitement à la gestion de projet (informatique ou non). En effet, quand on est jeune pilote, on apprend à ne pas s’engager dans une situation que l’on ne sera pas gérer, et qui pourrait nous amener au drame.

Planeur en vol

En gestion de projet, notre vie humaine est rarement mise en jeux, mais les dégâts d’un projet mal embarqué peuvent être importants. C’est pourquoi, si vous ressentez un doute, c’est qu’il n’y a pas de doute ! Il faut dans ces moments, prendre du recul, lever le nez du guidon, et analyser la situation. Comment ?

Revenez à vos domaines de connaissances de base de la gestion de projet, et réalisez votre « circuit visuel » de chef de projet pour reprendre le contrôle :

  • Suis-je toujours en train de réaliser le travail attendu, et seulement ce travail requis, pour mener à bien ce projet ?
  • La gestion des délais est-elle toujours sous contrôle ?
  • La gestion du budget est-elle maîtrisée ?
  • Ai-je toujours des indicateurs me permettant de savoir si je réponds bien aux besoins et attentes pour lesquels le projet a été entrepris ?
  • Les intervenants sur le projet sont-ils bien identifiés, disponibles, informés, organisés et suivis pour réaliser les activités du projet ?
  • La communication autour du projet est-elle bien planifiée, réalisée et sous contrôle ?
  • Lidentification des risques, leurs qualifications et les actions associées sont-elles bien réalisées, et ceci, à intervalle de temps régulier ?
  • Les biens et services nécessaires au projet sont-ils planifiés, suivis et contrôlés ?
  • Les différentes personnes concernées, impactées par le projet et pouvant influencer sur le déroulement du projet sont-elles identifiées, suivi et accompagnées ?

Si je ne prends pas en compte mon doute et que je ne réalise pas assez vite cette révision de mes paramètres de mon projet, que va-t-il se passer ?

Petit à petit, dans votre progression de votre projet, sournoisement, un déphasage va s’installer entre ce que vous voyez sur le déroulement de votre projet (délai, objectifs, budget) et ce que vous ressentez.

Une situation d’inconfort va grandir dans votre tête. Il va vous falloir faire un effort de raisonnement pour lire vos indicateurs de la situation de votre projet et pour décider des actions à mener et à ordonner à votre équipe. Vous allez devenir un chef de projet qui manage mécaniquement, à partir de ce qui a été planifié. Et à un moment, vous allez ne plus contrôler votre projet, et votre comportement et votre management va devenir brutal. Vous allez peut-être bien vous sortir de cette situation, mais bien souvent, avec des dommages collatéraux !

Bref, évitez de rentrer dans cette zone d’inconfort et de non-contrôle du projet. Anticipez !

Et sachez écouter vos ressentis… et s’il y a un doute, c’est qu’il n’y a pas de doute !