Image courtesy of stockimages at FreeDigitalPhotos.net
Afin de mieux réussir nos projets, il est donc clairement inutile d’essayer de chercher une « potion magique » dans cette myriade d’articles !
Par contre cette profusion pourrait nous inciter à remettre en question les attitudes « monochromes » qui ne jurent en l’occurrence que par le « tout agile » ou au contraire les « l’agile ? Je n’y crois pas du tout ! », comme méthodologie pour réussir (ou pas) les projets.
Mettons-nous du coup dans l’attitude d’un chef cuisinier qui veut avant tout réussir* sa recette, et qui naturellement a ample connaissance de tous les ingrédients mis à sa disposition, ingrédients qu’il utilisera ou pas dans sa recette…
Dans son article « Sécurité et développement agile : le duo gagnant », Jérôme Saiz semble avoir adopté des « ingrédients » dits « agiles » tel que les « personæ » et les « scénarios d’utilisation » dans le but de mieux adresser la problématique des projets de type sécurité informatique…
Sans être Agile, n’observons nous pas aujourd’hui dans nombreuses entreprises des pratiques telles les courtes réunions d’équipe quotidiennes où chaque participant expose brièvement son travail de la veille, son plan de la journée et les éventuels obstacles rencontrés ?… Ce type de réunion dit « stand-up meeting » a été formalisé dans plusieurs méthodologies agiles, devenant ainsi un « ingrédient » (outil) dit Agile…
Ces quelques exemples sont à priori basiques et loin d’être exhaustifs : démystifions l’Agile, car chacun de nous le pratique quelque part et surtout les « ingrédients » de l’Agile peuvent nous servir à tous.
Transgressons les étiquettes « gestion de projet traditionnelle vs. gestion de projet agile » qui insinuent faussement un antagonisme et restons portés vers l’essentiel en gardant la lucidité et l’attitude pour potentiellement profiter de tous les ingrédients (outils) qui pourraient nous servir pour réussir notre recette (projet) !
*On peut argumenter que dans l’esprit de ce cuisinier « réussir » implique la satisfaction de son client, la satisfaction de sa propre équipe et la rentabilité de son métier.
Michel G. PhD – Certifié PMP® du PMI® – Prince 2 – Agile (PMI-ACP®) – Spécialiste Release Management et Chaine de Production
Pour plus d’informations n’hésitez pas à contacter l’équipe PMGS au 0156810850
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Vous pouvez entendre ici et là que Kanban s’adapte plutôt bien aux grandes tailles. En réalité, un des problèmes de Scrum auquel je pense on ne s’est pas soigneusement attaqué, est que faire dans les projets qui nécessitent davantage de personnes qu’une unique équipe Scrum puisse rassembler. L’un des problèmes qui émerge très rapidement quand l’équipe Scrum grandit est la réunion « standup ».
Comme vous passez à travers l’équipe qui grossit avec vos trois questions standards cela nécessite naturellement de plus en plus de temps. Bientôt cela peut devenir un problème que de tenir dans le bref temps imparti pour de telles réunions.
Quand l’équipe adopte Kanban, elle commence d’habitude avec un standup inchangé. Cependant cela signifie que, à un certain point, ils font face au même problème que les équipes Scrum : 15 minutes ne sont désormais plus suffisantes.
Partenaire de DantotsuPM
Récemment, Jorn Hunskaar a partagé une telle histoire sur son blog. Il m’a incité à combiner une suite d’idées en une seule réponse qui peut servir de un guide sur comment améliorer les standups autour du tableau Kanban.
Au lieu d’exécuter le typique tour de table avec des réponses sur ce qui s’est produit hier, ce qui va être réalisé aujourd’hui et quels sont les problèmes, vous pouvez essayer de reconcevoir le modèle que vous suivez pour le standup.
comment améliorer les standups autour du tableau Kanban
D’abord, passez à travers tous les points bloquants (s’il y en a). Ceux-ci sont certainement vos points de douleur actuels. Cela signifie que vous voulez certainement investir une partie du précieux temps de standup sur ces points bloquants. Cela est évident.
Deuxièmement, discutez des items urgents ou à expédier (de nouveau, s’il y en a). C’est le travail prioritaire du point de vue de l’équipe toute entière. C’est quelque chose que vous devez vraiment faire sous peine de retarder d’autres taches. De nouveau, ceci est une chose dans laquelle cela vaut la peine d’investir de rares ressources.
Troisièmement, passez en revue les items qui n’ont pas progressé depuis le dernier standup. Ceux-ci sont les points qui peuvent être à risque. Peut-être ne devaient-ils pas progresser mais dans ce cas ce serait revu rapidement, peu de discussion nécessaire. Autrement, cela vaut la peine d’avoir une brève analyse ce qui a empêché ces points d’avancer. À propos, cela signifie que vous devriez avoir un mécanisme pour marquer visuellement les fiches qui ne se déplacent pas, ce qui est souvent délicat.
Quatrièmement, passez à travers tout le reste. Encore un conseil : Vous pouvez avoir discuté les sujets selon leur classe de service par priorités. Autrement dit, vous commencez par la classe la plus hautement prioritaire de service (des bogues, des fonctionnalités critiques ou autre) et discutez tous les items de cette classe de service. Puis vous vous déplacez sur une autre. Bien, au moins cela peut fonctionner tant est que vous puissiez dire quelle classe de service est plus importante qu’une autre.
Encore une règle raisonnable : dans chacun de ces groupes, utilisez le tableau Kanban de la droite vers la gauche. Cela indique que plus un article est proche d’être fini plus vous voulez en discuter pour le compléter, apportant ainsi de la valeur à vos utilisateurs, clients et parties prenantes.
OK, jusqu’à ce point il y a en fait peu de différences : vous passez toujours en revue chaque item de travail qui est sur le tableau. Il y a un focus différent sur les problèmes et vous pouvez passer sur les items évidents de travail complété, mais tout de même, toujours beaucoup de contenu à revoir.
Cependant, étant donné que vous venez de trier les sujets à discuter selon leur priorité, vous pouvez utiliser un truc simple et stopper la discussion quand le temps de la réunion s’est écoulé, peu importe si vous avez pu ou pas couvrir toutes les choses. Cela signifie que vous avez probablement couvert tous les items des trois premiers groupes et certainement tous ceux des deux premiers, indépendamment du reste qui exige une moindre part de discussion ou aucune discussion du tout.
Cela signifie aussi que, dans un bon jour, vous pouvez couvrir tous les points, ou davantage de choses, et c’est parfait. Ce dont vous avez essentiellement besoin est de vous assurer que la substance la plus importante ne va pas passer inaperçue.
Un pas de plus serait de sauter une discussion sur un groupe ou sous-groupe spécifique d’items, comme par exemple une classe spécifique de service, quand vous voyez que cela n’ajoute pas vraiment de valeur. Si vous n’êtes pas certain, essayez de les couvrir pendant les standups et voyez quel résultat vous obtenez. Vous pourrez alors commencer à essayer d’autres choses avec l’agenda de la réunion.
Idéalement, après quelque temps, vous finirez par discuter seulement des choses importantes, disons, les points bloquants, les items à expédier et bloqués, et peut-être d’autres qui sont amenés par n’importe quel membre de l’équipe pour une raison importante et sortent du travail habituel qui n’a pas besoin de plus d’attention qu’une confirmation silencieuse que tout est parfaitement en ordre.
partagez ce billet avec vos amis, collègues et relations professionnelles
Cet article est proposé par Vincent Coustillac, consultant Net’sFive – réseau d’experts en Management de Projets.
A propos du défi causé par l’intégration d’une méthode Agile dans le cadre du Management de Portefeuille de Projet (PPM), et de comment donner la visibilité nécessaire à la Direction d’entreprise sans perturber la culture et les pratiques des équipes Agile.
Cet article présente un ‘White Paper’ publié par Daptiv, – société américaine spécialisée dans les systèmes de management de portefeuille de projets (http://www.daptiv.com) qui peut être téléchargé dans son intégralité (en version originale anglaise) depuis ce lien.
Partenaire de DantotsuPM
Ce ‘White Paper’ a particulièrement attiré notre attention car il montre comment, malgré les idées fausses associées aux méthodes Agile, les projets exécutés dans ce mode peuvent très bien être intégrés dans un management de portefeuille de projets. Cela bien-sûr en tenant compte des caractéristiques propres à la culture et aux pratiques des équipes Agile, et des exigences générées par leur intégration dans un portefeuille de projets.
Le ‘White Paper’ commence par une introduction du modèle Agile et ce qui le distingue du modèle de gestion de projet traditionnel, pour ensuite aborder le cœur du sujet.
Le défi : Intégrer les processus PPM et Agile
De nombreux portefeuilles de projets comprennent maintenant un mélange de types et de méthodologies projet, tels que les projets traditionnels en cascade, des projets en mode Agile, des projets Six Sigma et des projets «Stage-Gate» au cycle de vie déterminé pour le développement de nouveaux produits.
Cependant, même avec cette volonté d’adopter une méthode Agile, l’intégration de projets Agile dans un cadre PPM s’est avérée difficile pour de nombreuses organisations.
Les 3 Idées Fausses sur l’association PPM et Agile
Le mouvement Agile a eu une influence significative sur les bonnes pratiques en gestion de projet. Cependant, quelques principes Agile tels que l’acceptation du changement, la planification « juste-à-temps », et la suppression de la prise de décision hiérarchique ont conduit à des idées fausses sur la compatibilité des projets en mode Agile avec les processus PPM.
Voici trois idées fausses communes (et pourquoi elles sont fausses) sur les principes Agile qui ont compromis l’intégration des projets Agile dans un portefeuille de projets.
Idée Fausse #1 : Les Projets Agile ne Donnent pas une Visibilité Suffisante à la Direction
Une grande partie de la popularité de la méthode Agile réside dans la croyance que les équipes doivent être habilitées à prendre des décisions business plutôt que de compter sur les parties prenantes dirigeantes pour approbation. Responsabiliser une équipe, cependant, ne signifie pas que des rapports d’avancement ne doivent pas être fournis en temps opportun à l’équipe dirigeante. La difficulté à laquelle les équipes sont confrontées est la nécessité de fournir des rapports d’avancement dont les dirigeants ont besoin, mais qui sont peu compatibles avec les pratiques Agile. Les dirigeants doivent apprendre à interpréter le statut de projet d’une équipe Agile plutôt que d’imposer des exigences de rapports d’avancement qui ne sont pas compatibles avec les pratiques Agile.
Idée Fausse #2 : Les Projets Agile n’ont pas de «Dates de Fin Prévues» Fiables
Bien que les équipes Agile évitent de fournir des dates de livraison garanties (étant donné le cône d’incertitude autour d’un projet), c’est une erreur de penser qu’un projet Agile ne puisse pas donner une date de fin prévue. Il est vrai que les équipes Agile fournissent des estimations «juste-à-temps» pour chacune des itérations et se concentrent sur la fourniture progressive de la valeur commerciale, cependant un plan de réalisation et de livraison global doit pouvoir faire l’objet d’une estimation de haut niveau. L’utilisation d’«epics» (grandes «stories ») et «themes» (groupes de «stories») permet d’estimer le travail dont il convient de détailler le contenu.
Idée Fausse #3 : Les Pratiques Agile et Traditionnelles ne sont pas Compatibles
Certaines pratiques Agile ont des différences fondamentales avec des pratiques traditionnelles de gestion de projet. Cependant, il n’est pas vrai que les deux types de pratiques ne peuvent pas être combinés pour créer un cadre de gestion de projet efficace. Par exemple, les pratiques Agile ne couvrent généralement pas la consommation du projet ou le processus d’initiation du projet, et les pratiques traditionnelles concernant les coûts du projet, la communication et la gestion des risques sont souvent plus matures que les pratiques Agile correspondantes.
Intégration d’une méthodologie Agile dans un cadre PPM
L’intégration d’une méthodologie de projet Agile dans un cadre PPM n’est pas différente de l’intégration d’une méthodologie de projet plus traditionnel, à quatre exceptions près:
1. Les équipes Agile fonctionnent manifestement mieux lorsque les dirigeants et les chefs de projet n’étouffent pas les processus Agile. Imposer des revues inutiles des parties prenantes, des points de contrôle et des exigences de saisie de données sur un projet Agile réduira considérablement l’efficacité de l’équipe. Bien sûr, si des décisions importantes doivent être prises avec la participation de la Direction ou si un projet Agile a des dépendances avec d’autres projets, des réunions avec les parties prenantes seront nécessaires, mais celles-ci doivent être l’exception et non la règle.
2. Les projets Agile mesurent la progression des «story points» terminés et la valeur commerciale livrée. C’est un moyen fondamentalement différent de suivre les progrès réalisés plutôt que d’utiliser un plan des tâches et la mesure des heures consommées sur les tâches accomplies. En outre, le chef de projet assigne des responsables de tâches dans un projet traditionnel, tandis que les équipes Agile s’auto-organisent, de sorte que les tâches sont réaffectées à tout moment par l’équipe pour assurer une livraison optimale du projet. Cette différence exige que les mesures de « la santé de projet » et du « pourcentage d’avancement » soient établies différemment des projets traditionnellement basés sur les temps passés par tâche.
3. Du fait que les affectations de tâches au sein d’une équipe Agile sont dynamiques, il n’est pas recommandé d’attribuer des ressources à temps partiel dans une équipe Agile, car cela brise le modèle d’auto-organisation. Au lieu de cela, il est préférable de traiter les équipes Agile comme un tout et affecter des ressources à plein temps (à l’exception des ressources telles que les architectes, les administrateurs de bases de données, qui sont généralement réparties sur plusieurs projets).
4. Enfin, les revues régulières des projets Agile sont plus orientées sur «l’état du produit» plutôt que sur l’atteinte de jalons prédéterminés ou la livraison de la documentation du projet. Les revues doivent être adaptées au type de projet afin de s’assurer qu’elles apportent une valeur pour l’équipe.
Des mesures communes aux différents types de projets
Afin de les intégrer dans un cadre PPM, les cinq paramètres communs qui permettront aux dirigeants d’obtenir une visibilité de l’état des projets, quel que soit le mode d’exécution, sont les suivants :
La date de fin prévue : « La date de fin planifiée » est l’estimation faite lors de la création du projet pour la date de livraison prévue, alors que « la date de fin prévue » est l’estimation de la date de fin du projet réactualisée en fonction des données actuelles. Pour un projet traditionnel, ces dates sont basées sur le planning des tâches et le chemin critique du projet. Pour un projet Agile, elles sont basées sur le plan de livraison. Étant donné qu’un «cône d’incertitude» existe indépendamment de la méthodologie de projet, l’exactitude des dates de fin prévues devrait être comparable pour les deux types de projets traditionnels et Agile.
Le pourcentage d’avancement : Pour un projet traditionnel il est calculé en additionnant les heures des tâches accomplies et en divisant par le nombre d’heures total des tâches du projet. En revanche, le progrès d’un projet Agile est mesuré par les «story points» livrés, le pourcentage d’avancement est alors mesuré par rapport au nombre total de «story points» prévu du projet.
Les modifications du contenu : Pour les projets traditionnels, cela est représenté par le nombre de demandes de changement. Pour un projet Agile, cela est mesuré par la variation en «story points» totaux au fil du temps.
Coûts réels et budgétés : Ces mesures doivent être rapportées pour les deux types de projets traditionnels et Agile. Alors que sur les projets traditionnels ces mesures peuvent se faire sur la base des tâches et des temps passés, il n’est pas approprié de demander à une équipe Agile de suivre les temps au niveau des tâches pour calculer les coûts des ressources. Au lieu de cela, les ressources doivent être dédiées à une équipe Agile et les coûts calculés en conséquence.
Le statut du projet : Le statut du projet est une mesure qui résume si un projet est «sur la bonne voie », « a besoin d’attention » ou est « en difficulté ». Son évaluation varie selon l’organisation et est calculée en utilisant la logique conditionnelle basée sur les quatre mesures ci-dessus, ainsi que d’autres données telles que les questions en suspens.
La fourniture de ces mesures dans un tableau de bord d’un système PPM permet aux dirigeants d’identifier rapidement les projets qui nécessitent une attention particulière ou une intervention, quelle que soit la méthodologie utilisée pour son exécution.
Le ‘White Paper’ se termine par deux points essentiels
La calibration des mesures des différents types de projets dans les programmes et les portefeuilles, ainsi que la nécessité de créer une source unique de référence – single source of truth – pour la Direction.
-=-=-=-=-=-
Net’sFive accompagne les entreprises pour favoriser leur développement par la maîtrise des projets à tous les niveaux de l’entreprise : depuis la conduite des projets individuellement, le contrôle global des projets de l’entreprise, l’optimisation des ressources et jusqu’au management du portefeuille des projets pour une gestion priorisée des projets alignés avec la stratégie de l’entreprise.
partagez ce billet avec vos amis, collègues et relations professionnelles
Nous sommes tout familiers des sorties de logiciel majeures. Prenez votre machine à remonter le temps et pensez à l’environnement Windows. Il y a eu Windows 3.0, Windows 95, Windows 98, Windows 2000, Windows XP, Windows Vista et Windows 8.
Chacune de ces sorties majeures a été conçue avec de nouvelles fonctionnalités et des améliorations technologiques par rapport aux précédentes.
Une sortie de version majeure est la super nouvelle version d’un produit logiciel ou d’une application Web qui contient tout ce que tout le monde a demandé depuis la dernière grande version. C’est la solution à tous les problèmes et c’est la litanie qui est répétée quand on pose la question de pourquoi le logiciel ne fonctionne pas actuellement d’une certaine façon. La réponse est une longue répétition de « dans la prochaine version 9.0…9.0 ….9.0 … ».
Ceci peut être bel et bon, mais il y a des problèmes associés à cette Approche de sortie de version majeure qui essaie de tout mettre dans la prochaine version. Nous discuterons certains de ces défis avec la méthode de Conduite de projet agile, comme le développement Scrum, qui peut rendre ces sorties plus itératives, plus petites et plus fréquentes.
Les Défis avec les Versions Majeures
Il y a un certain nombre de défis qui existent avec cette méthode de développement logiciel qui suit le chemin de méthodologies de développement plus rigides comme la méthode dites en Cascade.
Ci-dessous sont quelques-uns de ces défis :
Les versions sont éloignées l’une de l’autre
Des versions majeures sortent typiquement éloignées l’une de l’autre. Bien sûr, il peut y avoir des versions mineures en chemin (comme 9.1 ou 9.05 selon la taille de la version), mais celles-ci sont d’habitude reléguées aux corrections de bogue et corrections de fonctionnalité existante.
Le contenu vraiment nouveau et passionnant nécessite d’habitude 4 à 6 mois et dans ce monde exigeant de satisfactions instantanées, ceci peut sembler une éternité. De plus, ceci nous mène aux conversations répétées avec des clients et des utilisateurs finaux que ce qu’ils veulent vraiment que le logiciel fasse se trouve à un certain point dans un avenir éloigné.
De surcroît, comme les dates approchent, il y a typiquement un certain type de débordement de périmètre qui a été introduit en chemin et la fonction ne marche pas comme prévue, ce qui repousse la date de livraison encore plus loin.
Tout est entassé dans la prochaine version
Des idées feront surface pendant le développement de la version majeure. Elles sont de si excellentes idées et feraient une si grande différence pour l’utilisateur final qu’il serait déraisonnable d’attendre la version majeure suivante qui pourrait être 8 à 12 mois plus tard.
Que se passe-t-il ?
Ces grandes idées forcent leur passage dans un espace qui est déjà encombré de fonctionnalités. De plus, il n’y a d’habitude pas assez de personnes disponibles pour implémenter le premier cercle de fonctionnalités sans parler du périmètre supplémentaire qui a été introduit. Ceci contribue en partie aux raisons des retards potentiels mentionnés ci-dessus.
Devient plus grande que l’océan et peu aisée à manœuvrer
Maintenant il y a ce poids lourd de la version majeure qui hante couloirs et bureaux. Elle prend sur une vie à part et commence à bousculer les gens quand ses besoins ne sont pas respectés.
Ses besoins se sont étendus pour inclure des tests supplémentaires, davantage de documentation et la conduite de plus de groupes de discussion pour voir si la nouvelle fonctionnalité est facile de comprendre et utiliser. Ceci exige beaucoup de management pour mener cette version monstrueuse à l’achèvement et éviter qu’elle ne nous échappe.
Grand changement dans l’interface utilisateur (UI)
Un changement substantiel à l’UI est typiquement associé à une version majeure. Ceci exige une courbe d’apprentissage de la part de l’utilisateur final comme tout le monde appréhende la nouvelle interface.
Rappelez-vous des changements dans la navigation que Microsoft a pas fait il n’y a pas si longtemps dans la navigation basée sur le Menu que tout le monde connaissait depuis des années vers l’approche de Ruban qui a agrégé des fonctions liées en un même endroit. Nous y sommes habitués maintenant mais cela a pris du temps de s’adapter à la nouvelle façon de faire les choses.
Les problèmes sont plus difficiles à cerner
Puisqu’il y a tant de personnes impliquées dans une sortie de version majeure de dimensions Herculéennes, il devient dur d’identifier précisément et de résoudre les problèmes. Les problèmes pourraient apparaître dans une zone qui impacte négativement une autre zone.
Par exemple, une application Web peut prendre excessivement longtemps à se charger. Rien de changé côté code et tout le monde dans les autres services jure que rien n’a changé non plus.
« Attendez, euh…, » dit timidement le service informatique « nous avons vraiment récemment fait un changement mineur dans le réseau qui pourrait limiter le débit ».
Bien sûr, ce dont on pensait que cela n’avait aucun rapport avec la cause du problème finit par être le coupable.
Les avantages de la méthodologie Scrum
Il y a eu un changement vers des méthodologies de conduite de projet plus agiles ces dernières années. Ceci a ouvert la porte pour des versions logicielles plus itératives et a réduit la durée entre chaque sortie majeure suivante. Voici certains des avantages de la méthodologie Scrum.
De plus fréquentes versions
Voici le diagramme du Modèle Scrum
Les phases de la méthodologie Scrum se concentrent sur des sorties fréquentes avec moins de fonctionnalités. Initialement, ceci peut donner l’impression d’être négatif. Qui voudrait moins de fonctionnalité ? Eh bien, plutôt qu’attendre 4 à 6 mois pour avoir toute la fonctionnalité, la méthodologie Scrum permet aux versions d’être accélérées. Dans la plupart des cas, une version peut être sortie toutes les 4 à 6 semaines! Le cycle de développement est appelé un Sprint, qui en dit long sur la nature abrégée de la méthodologie Scrum.
Focus sur un Jeu limité de Fonctionnalités, Facilité d’utilisation et Valeur pour l’Utilisateur final
La nature itérative de la méthodologie Scrum se prête à une concentration au laser sur quelques fonctionnalités, la facilité d’utilisation et la valeur pour l’utilisateur final. Chaque version doit donner de la valeur à l’utilisateur final. À un certain niveau, cela pourrait être vu comme une approche par phase de versions majeures. Plutôt que d’attendre que tout soit fait en même temps, les fonctionnalités sortent comme elles sont produites et mises en ligne.
L’approche Itérative permet changements et améliorations
Des méthodologies de conduite de projet agiles comme la méthodologie Scrum embrassent le changement. La méthode en cascade qui est si commune pour des versions majeures est typiquement résistante au changement. Il y a des formulaires, des réunions, des approbations et autres contrôles mis en place dans le but d’empêcher le changement avec les méthodologies conventionnelles. La nature itérative de la méthodologie Scrum cherche un retour d’information continu et ajuste ensuite le plan et les jeux de fonctionnalités en conséquence.
Se prête au Software as a Service (SaaS)
Plus de demandes se déplacent vers le Modèle du Logiciel comme un Service (SaaS). Ceci est quand l’application en ligne est vivante, une entité qui respire et à laquelle les gens adhèrent selon leurs besoins. Une partie des attentes autour du modèle SaaS est qu’il y aura des changements et des améliorations continus au logiciel. Ceci encourage des abonnés à la demande à continuer à renouveler mois après mois. La méthodologie Scrum facilite ceci.
Le temps où attendre 4-6 mois entre des versions majeures est révolu. Les gens n’ont plus ce type de patience et il y a des alternatives pour ne pas avoir à attendre si longtemps. Même si vous n’adoptez pas la méthodologie Scrum en entier, il y a de certains principes que vous pouvez utiliser qui permettront à vos projets d’avancer plus rapidement.
ProjectManager.com croit en la livraison fréquente de super fonctionnalités à ses utilisateurs finaux.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Tirez le meilleur des « daily scrum » en vous refocalisant sur leur raison d’être.
Agile et Scrum ont révolutionné le paysage de l’industrie informatique. La plupart des sociétés ont déjà adopté Agile ou se rapprochent de ces méthodes. Cependant, la réalité est que la plupart considèrent encore Agile comme une forme de développement en cascade itératif plutôt que d’accepter ses pratiques radicalement différentes.
L’une des pratiques Agile les plus intéressantes et les plus utiles est la réunion debout de Scrum (Daily stand-up) tenue par l’équipe Agile. Le ScrumMaster y supporte la collaboration entre les membres de l’équipe. Pourtant, il existe quelques pièges typiques dans lesquels tombent les équipes Agiles.
En voici quelques-uns à éviter :
1. Entrer en mode réunion classique.
En réunion classique, l’équipe s’éloigne du format du stand-up et commence à discuter des choses dans le désordre. La réunion devient un état des lieux plutôt qu’un rapport d’avancement. Ceci peut tuer la concentration de toute l’équipe qui se focalise sur une ou deux activités importantes plutôt que l’objectif à atteindre. Il est extrêmement important que toute l’équipe soit concentrée ce que chacun réalise dans l’équipe pour comprendre la dynamique et prendre conscience de ce vers quoi se dirige le groupe en entier.
2. Tout discuter maintenant.
Souvent une personne mentionne un point et cela devient une discussion entre deux ou trois personnes. Il est important de terminer cette conversation, mais il est encore plus important que cette session se tienne hors réunion pour permettre un échange correct. Même si le point impacte toute l’équipe, une discussion séparée pour débattre de ce point est nécessaire. Le Daily Stand-up ne devraient pas être utilisés pour débattre de tels sujets, se focaliser sur l’avancement des tâches est de la plus haute importance.
3. Annuler la réunion comme si elle n’était pas nécessaire.
Une autre chose qui arrive souvent dans les périodes où l’équipe est trop chargée ou pas assez, est que certaines équipes décident d’annuler la réunion. Ou bien, ils tombent dans ce piège si le ScrumMaster est absent. N’annulez jamais cette réunion. Si il y a peu à discuter, terminez la plus tôt. La réunion n’est pas faite pour présenter un rapport à qui que ce soit (même au ScrumMaster) mais pour maintenir l’auto-organisation de l’équipe et son focus. La discipline et la pratique sont les clés de l’Agilité.
4. « Ils n’ont pas besoin de savoir »
Souvent le ScrumMaster assume que l’équipe est concentrée sur le boulot en cours et garde donc par devers lui les discussions sur de nouveaux développements discutés avec le client ou autres détails. Ceci est fatal. Il est important que cette information soit partagée avec l’équipe pour que tous soient au courant. Rester proche du client et de son monde contribue largement au succès de l’équipe Scrum.
5. « Laissez-moi juste en parler au client »
Un autre mythe ou mauvaise compréhension est mis en évidence lorsque le ScrumMaster ou le chef de projet essaie d’apporter des choses qui proviennent de l’équipe au client sans impliquer l’équipe. Il est primordial que l’équipe soit rapprochée du client. Ceci est l’un des attributs les plus importants et uniques de l’équipe Agile en termes de collaboration et d’ouverture. Ceci aide de multiples façons que d’engager avec le client et toute tendance à l’éviter devrait être bannie.
Having studied Agile Project Management™ using the manual, the thing that I noticed immediately was that there was no useful Agile Glossary. As I researched and started writing my new book Agile Change Management, I figured this was a big draw-back for anyone wanting to study a new subject so I have pulled together what I consider to be 47 of the most useful terms. With short descriptions intended to give the reader enough information from which to move onto the next step, I hope you find this us use when understanding this exciting new topic.
Click on this link Agile Glossary to download the pdf version.
partagez ce billet avec vos amis, collègues et relations professionnelles
Marc Burlereaux has presented an article written by Christine Rieu, Sylvain Gautier and himself about the pitfalls when introducing Agility at the Project Zone Congress 18,19 March 2013 in Frankfurt.
The Agile approach used for projects, or new product development, ensures a greater flexibility with iterative design, lighter documentation and formalization, more interactivity and efficiency in the conduct of meetings, and especially more customer involvement throughout the project (Pichler, 2010). By coupling a Lean approach to these Agile methods; we remove all unnecessary and ‘non-value added’ steps to minimize waste and to maximize the expected value of the product (Larman & Vodde, 2010). This seems to be the panacea!
But it is not straightforward to implement this type of approach and the Project Manager may be asked many questions:
o How will these approaches be integrated successfully in mature Project Management organizations that are more familiar with traditional software V-Model (software development) or Waterfall Model?
o How will the Release Manager be in a position to facilitate the delivery of products developed with Agile and Lean approaches? This is particularly relevant given his/her role is to keep adherence to rigid processes for minimizing the risks associated with change, which is often seen by the Agile Project Manager as an awful slowdown in the delivery process.
o How will these deliveries fit in the whole Release Management process, including testing procedures (unit, integration and acceptance testing of applications), the production of operating technical documentation, user guides, and the creation of installation and deployment procedures?
o How will you avoid Agile being used as an excuse for lax and ineffective behaviours, such as removing documentation?
The success of such projects imposes a balance between a comprehensive Agile approach and a discipline warranty by the Release Management process. Hence the title of our paper, « An Iron Fist in a Velvet Glove. »
This presentation is based on lessons learned gathered during project experiences combining Agility and Lean Management in various fields of industry and banking organizations. We explain our vision of the prerequisites for a project to be eligible for Agile methods. The thread of the presentation is to then illustrate our experiences with emphasis on Agile best practices that we have identified as key success factors. We have divided these keys points throughout the various phases of project development, with a particular emphasis on the early stages of scoping and preparation, and then the final stages of acceptance (technical and business) and finally the transition to production.
The following anecdote illustrates that sometimes agile’s team are surprisingly facing rigidity:
Jack Duggal, a seasoned Program Manager with over 30 years of experience in project management, said at a conference organized by PMI (Project Management Institute) in Geneva in 2012: « You can sometimes blame rigidity in the application of agility. In a Scrum meeting, which assumes that you are standing, a person a little tired had expressed the need to sit down: this was refused, as matter of principle! »
Whatever method is chosen, we should be able to get inspired by other approaches and benefit from best practices:
As an example, PMI, which is the authority in the management of « traditional » projects, has naturally opened the door to the principles of Agility by recently creating a new credential PMI-ACP (Agile Certified Practitioner) and integrating Agile and Lean Management into traditional project management. For example, the PMBOK 5th edition now takes into account Agile « Adaptive Life Cycles » with section 2.4.2.4 covering iterative and incremental methods. These methods involve short iterations of 2 to 4 weeks with fixed time and resources (i.e. time boxing).An important aspect to add is the risk management: this is an example of good practice derived from traditional methods integrated into agile approaches.
Finally, we conclude by reminding the four principles issued by the Manifesto for Agile software development written by Kent Beck and 16 other signatories (K. Beck et al, 2001) which by the way could be followed regardless of the chosen project management methodology:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we place more value to the items on the left.
The Agile approach should be considered rather as a philosophy of development
In this presentation, we wanted to give very practical advice to implement a successful agile approach, especially in organizations which will combine it with more traditional models. It is inspired by our experiences in various project contexts and emphasizes the importance of deeply understanding the benefits and implementation impacts of this new way (i.e. not just use it as a « tool box with an integrated checklist »). The Agile approach should be considered rather as a philosophy of development, which focuses on employee involvement and commitment. One has to take in each method that is « good for business », knowing that every business is unique and has its own specific operational characteristics. Opposed to traditional methods, Agile methods are a revolution, but they can also bring their share of the burden and stress, depending on the implementation and the use.
The Agility is good but to control it is even better …
– The Scrum approach is not a panacea, especially if it is not understood and supported by the Management and Business Analyst (MOA)
– The Lean Approach coming from the industry may not be implemented in all contexts
– The AGILE mindset is primarily the key success factor that will ensure a smooth Agile implementation
– We must select the right AGILE tools best suited to the company
– A pragmatic coaching is a key success factor
– The dogmatism must be forgotten
– And we must contextualize the process that could not be standard for all areas (from the space industry to Google, through aerospace, automotive, banking …).
Last but not least, misunderstood and badly launched / implemented Agility may cause more damage than traditional methods.
Let’s Be WAGILE! Contraction of WATERFALL (traditional methods of development) and AGILE … hence Agility: An Iron Fist in a Velvet Glove!
Christine RIEU, works as an Associate Professor in the Listic laboratory and has carried out research on Knowledge Management for the past 15 years. Christine teaches Project Management at the IUT of Annecy where she also holds the position of Head of International Relationships. . Christine is also a founding member of “PMI Pôle des Pays de Savoie”, France Chapter.
Marc BURLEREAUX, has more than 27 years of expertise in Project, Program and Portfolio Management with a proven track record in the field of Swiss Private Banking. Marc is a Senior Volunteer at PMI, Director of “Pôle des Pays de Savoie” (part of the France Chapter) and also a member of the PgMP® & PMI-RMP® Credentials PRC (Panel Review Committee). Marc has been applying agile technics for the past 10 years, and more recently has spent two years as Head of European Release Management in a Swiss Private Bank.
Sylvain GAUTIER, has more than 27 years of expertise in IT and started his career working as a consultant, and then as an architect, within the Software Industry (Computer Associates, Sybase). Sylvain focused mainly on data design, DBA, and project management methodologies for major European projects before becoming Head of IT Operations for an important private bank in Geneva. Sylvain is now a freelance consultant applying Agile, ITIL, Archimate and Service Design best practice to companies within the Banking and Insurance sector.
Bonus video : « Agile: An Introduction »
partagez ce billet avec vos amis, collègues et relations professionnelles
Un des buts atteints par Eric Ries’ Lean Startup’ et porteur du plus de valeur est de populariser le terme de « Minimal Viable Product » (MVP), ou Produit Minimum Viable en français. Bien sûr le concept n’est pas nouveau. Nous utilisions l’idée de « Minimal Marketable Feature » (MMF) depuis les tous premiers jours de Kanban et elle était basée sur la même façon de penser. Il y a aussi davantage de concepts similaires.
La prémisse de base est que nous devrions construire la chose la plus petite possible ou faire fonctionner l’expérimentation la plus petite possible qui reste raisonnable et ajoute de la valeur. Selon le contexte la valeur peut être quelque chose qui aide des utilisateurs, mais peut aussi être simplement la découverte de nouvelles connaissances ou la vérification d’une hypothèse.
Une chose que j’ai réalisée récemment est à quel point j’applique largement cette pensée. Initialement, c’était simplement la façon de décomposer le contenu. J’ai voulu que mes équipes construisent des morceaux de logiciel probablement petits, mais toujours de valeur, et qu’un client puisse donc vérifier et nous donner un retour avec des informations utiles. Alors, après Lean Startup, il s’agissait de faire fonctionner un produit. Ce que nous voulons construire est quelque chose de nouveau qui frappe les esprits. Quelle est la fonctionnalité la plus petite qui peut prouver ou réfuter l’hypothèse que cela puisse fonctionner ?
D’une façon ou d’une autre j’utilise maintenant la même façon de penser, la pensée MVP si vous voulez, pour discuter des idées de marketing, définir des plans d’action pendant des rétrospectives, etc. Souvent il est difficile de définir un produit en soi, mais il y a toujours une idée des résultats attendus et un effort minimal définissable permettant d’obtenir ce résultat.
Ainsi comment définirais-je la pensée MVP ?
1. Définir le plus petit prochain objectif de valeur que vous voulez réaliser.
2. Définir l’effort minimal qui vous permettra d’atteindre ce but.
3. Exécuter.
4. Analyser les résultats et apprendre.
5. Itérer.
Une partie potentiellement délicate est la définition de l’objectif parce que c’est totalement contextuel. C’est aussi quelque chose qui me plaît vraiment car je n’aime pas les recettes toutes prêtes. En fait, s’il y a quoi que ce soit de nouveau ici, c’est essentiellement l’application extrêmement large du modèle car l’idée elle-même n’est pas nouvelle. Je veux dire, nous limitons d’habitude notre contexte de travail au périmètre d’un projet, au management d’un produit, à faire tourner une affaire, etc. Alors, nous inventons un nouveau terme et s’il marche nous en faisons nos carrières de consultants excessivement bien payés.
Ce n’est pas du tout mon but. J’essaye juste d’élargir un contexte applicable d’idées que nous connaissons déjà et que j’ai personnellement trouvées utiles.
résolution de problème
Donc si mon problème est une fuite sous le toit près d’une lucarne, mon objectif minimal suivant peut être de vérifier si la fuite a un rapport avec un volet externe. Un tel objectif est acceptable parce que l’effort minimal peut être simplement d’attendre l’averse suivante avec le volet ouvert ou fermé. Je ne me précipite certainement pas pour réparer le toit.
marketing
Si nous parlons de marketing ? Donnons un objectif général, disons: TechCrunch parlera de nous. Quelle serait l’expérimentation de valeur la plus petite qui pourrait nous rapprocher de la réalisation de cette sorte d’objectif ? Je suppose qu’étendre et manager son réseau peut être une première étape très raisonnable. Cela n’exige même pas d’avoir une idée, sans parler d’un produit, que nous voudrions voir couvert.
développement de produit
Que diriez-vous d’un produit ? Eh bien, celui-ci a été couvert pratiquement partout. Construire la fonction minimale, probablement même une simulation, qui permet de vérifier que l’idée pour le produit a du sens.
leçons apprises
Rétrospectives ? Quel est le simple, plus petit possible, changement qui aura un impact positif sur l’équipe ? Essayez-le. Vérifiez-le. Répétez.
achats
Zut, j’achète même mon équipement de marin de cette façon. Quel est le plus petit jeu d’équipements possible qui donne une chance de survie raisonnable ? Puis, j’utilise le résultat et je réitère, par exemple la prochaine fois j’aurai besoin de nouveaux gants, de caleçons longs et de protection imperméable pour un téléphone.
Quand vous y pensez c’est essentiellement du Kaizen – faire systématiquement de petites expériences d’amélioration partout. Alors oui, il n’y a rien de nouveau. C’est seulement l’idée spécifique de Produit Viable Minimal qui me parle personnellement et m’a donné une contrainte agréable qui peut être utilisée dans les différents domaines de ma vie.
À propos, malgré sa définition très ouverte je trouve aussi que Kaizen est d’habitude appliqué dans un contexte très limité. Aussi, peu importe quelle idée marche pour vous, souvenez-vous juste que vous pouvez l’utiliser dans un contexte beaucoup plus large.
partagez ce billet avec vos amis, collègues et relations professionnelles
Bien que la célèbre Porsche 911 ait été présentée en septembre 1963 au salon de Francfort (alors appelée la 901), cela ne dénote pas de son grand âge !
C’est un classique absolu parmi des voitures de sport et sa conception éternelle ne se dépare jamais de style. Dans le monde du management de projet, la Porsche 911 est certainement un projet vedette. Selon magazine allemand « MotorKlassik« , seulement 10 prototypes ont été construits avant sa sortie officielle en septembre 1963. Ce simple fait est presque incroyable, comparé aux constructeurs d’automobiles de série d’aujourd’hui qui peuvent passer par des centaines de prototypes avant un lancement de produit.
À l’occasion de son 40ème anniversaire, il y a maintenant 10 ans, trois messieurs, qui ont joué un rôle central dans le succès de la Porsche 911, ont raconté leur histoire vue de l’intérieur à « MotorKlassik ». Ce que j’ai retenu de leur histoire est que dans de nombreux cas des équipes projet plus petites menées par des ressources douées portant de multiples casquettes peuvent donner une meilleure visibilité et des résultats plus efficaces dans les projets. L’ancien pilote de voiture de course et ingénieur développement chez Porsche, Hans Mezger a dit à MotorKlassik qu’il était non seulement responsable de la conception du moteur, mais aussi des essais sur route. Peter Falk, un des principaux ingénieurs, a expliqué que le temps de mise au point était court en raison du fait que les décisions pourraient être prises rapidement et mises en pratique immédiatement (car il n’y avait aucune paperasserie dont on devait se préoccuper en ce temps-là).
Un autre avantage que l’équipe projet avait à ce moment-là était leur petite taille et la proche proximité les rendant agiles et flexibles. Peter Falk a mentionné qu’il était possible d’être assis à son bureau tout en regardant l’atelier conduire le test du véhicule. Dans l’environnement de projet d’aujourd’hui, ce serait très difficile de manager un projet de cette façon. Bien que les gens de nos jours chez Porsche soient toujours de grands innovateurs, la réalité est qu’ils n’ont pas la même liberté de mouvement pour partager leur vision et leur créativité et sont souvent étouffées par des normes et des règlements. La vérité est, il n’y a probablement aucune autre industrie dans le monde qui a des niveaux rigoureux de réglementation juridique et de contraintes similaire à l’industrie automobile. En conséquence, la capacité de livrer des résultats réussis est devenue un énorme défi.
De la R&D à la fabrication en série de véhicules, les constructeurs automobiles doivent strictement adhérer aux réalités de la conformité réglementaire. De plus, des équipes projet font face de nos jours à l’obstacle d’être plus grandes et dans des nombreux cas fonctionnant avec des équipes dispersées à l’échelle planétaire qui doivent collaborer avec une interaction physique minimale.
partagez ce billet avec vos amis, collègues et relations professionnelles
Agile Project Management, basée sur DSDM Atern, est une approche novatrice pour le management de projet, qui aide les acteurs à travailler ensemble
efficacement, pour atteindre les objectifs de l’organisation. Contrairement à une approche traditionnelle, Atern fixe les délais, les coûts et la qualité dès les premières phases d’un projet.
Agile Project Management procure :
• Une approche qui offre l’agilité mais qui retient les concepts d’un projet, de la livraison et de la gestion de projets ;
• Une approche agile qui est compatible avec des approches plus formalisées de gestion de projet comme PRINCE2.
2 niveaux de certifications
Agile Foundation
Le niveau Foundation vise à mesurer si le candidat a les connaissances et une compréhension suffisantes du management de projet Agile pour pouvoir reconnaître et distinguer les éléments clés de l’approche. A cette fin, ils ont besoin de démontrer qu’ils comprennent la philosophie de Management de Projet Agile, les principes, les processus, les personnes, les produits, les techniques et conseils.
Le niveau Practitioner vise à mesurer si le candidat a les connaissances et la compréhension suffisantes du management de projet Agile pour l’appliquer et l’adapter à une situation de scénario donnée. Le scénario est conçu pour permettre au candidat de démontrer sa compétence à initier un travail en tant que chef de projet Agile sur un projet non-complexe.
Agile project management methodologies (such as Scrum, Extreme Programming and others) are based on process-centric and iterative development rather than a traditional waterfall approach. Some of the key characteristics of an agile project include a backlog, burn-down charts, frequent communication, and short-cycle delivery of project outputs that don’t typically lend themselves to traditional MS Project scheduling techniques. But in this informative webinar, we’ll show you techniques and tips on how to use MS Project to effectively manage projects in the new frontier of Agile Project Management!
This session is presented by Matt Davis, PMP, MCITP, President of the Microsoft Project Users Group (MPUG) Boston Chapter.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Comme beaucoup de choses dans cette liste, la première des 10 choses est facile à dire et très difficile à faire. C’est un mantra majeur de la pensée LEAN – « Faites-en Moins ».
Il y a des surcoûts et donc de la perte, dans la commutation de tâche (relisez « le multitâche vous ralentit »). Et il y a aussi plus de valeur à livrer quelque chose plus tôt, plutôt que de progresser de multiples choses et les avoir toutes partiellement achever et prendre plus de temps pour finir.
Voici un exemple délibérément simpliste de pourquoi Cela *paye* d’en faire moins…
Disons que vous avez 3 projets. Chaque projet demande un effort de 3 mois pour être achevé. Chaque projet ne délivre qu’une valeur de $10,000 le premier mois, augmentant de $10,000 chaque mois jusqu’à atteindre un plateau de $50,000 par mois.
Le scénario 1 est que les 3 projets sont menés en parallèle, qui est ce qui se produit d’habitude, particulièrement dans les plus grandes organisations. Aucune valeur ne sera réalisée avant la fin des 9 mois. En réalité cela pourrait aussi prendre plus longtemps, en raison de l’inefficacité de la commutation de tâche.
Le scénario 2 est que vous complétez chacun des projets à son tour, vous concentrant entièrement sur chaque projet jusqu’à ce qu’il soit fini. Après le mois 3, le projet 1 commence à accumuler de la valeur. Après le 6ème mois, le projet 2 commence à accumuler lui aussi de la valeur. Après le 9ème mois, le projet 3 est lui aussi livré, pas plus tard que dans le scénario 1.
Dans cet exemple simple, cumulativement nous avons réussi à réaliser beaucoup plus de valeur dans le scénario 2 où chaque projet est complété à son tour. Nous avons aussi le bénéfice d’une vitesse plus rapide pour commercialiser les 2 premiers projets, qui pourraient potentiellement nous donner un avantage sur nos concurrents et nous permettre d’établir notre position en premier sur le marché.
Maintenant regardons les chiffres pendant l’année 1 :
Scénario 1 : accumule une valeur de $180,000
Scénario 2 : accumule une valeur de $610,000
C’est une différence massive selon tout standard! 330 % de plus de valeur.
C’est un concept si simple.
Et du point de vue de la logique, il est vraiment indiscutable. Mais nous tous semblons tomber dans le même piège commun. Le piège de devoir montrer à tous du progrès, donc nous finissons par en faire trop tout de suite, même si cela délivre moins de valeur au final pour notre organisation.
Peut-être cette explication vous aidera-t-elle à en convaincre d’autres, parce que je suis certain que dans de plus grandes organisations vous pouvez ajouter un ou deux zéro aux chiffres ci-dessus !
Et imaginez tous les maux de tête en problèmes d’approvisionnement et de priorisation qui s’envolent quand on permet à l’équipe de se concentrer sur un projet à la fois. Quel bonheur!
S’il y a une chose qu’un cadre exécutif peut faire pour davantage aider ses équipes, c’est leur fournir l’opportunité de se concentrer.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Agile methods and frameworks are increasing in popularity as organizations and individuals seek increased flexibility when managing change initiatives.
Agile approached are often seen as rivals to waterfall methods including PRINCE2, when in reality they complement each other.
This webinar shows how the speed of delivery from Agile and the quality of project definition from PRINCE2 satisfies those seeking excellence and flexibility in project delivery, whilst maintaining strong project governance.
The session:
Defines what agile working means and how this has been captured in the APMG Agile Project Management qualification scheme
Uses the PRINCE2 process model to explain how agile project management can govern development, with PRINCE2 governing the overall project.
Comme la valeur des pratiques Agile est mieux comprise, de courageux chefs de projet commencent à défier les pratiques normales de l’organisation et demandent l’opportunité d’adopter une approche plus agile.
Dans les films animés “I want to run an agile project” (par Carson Holmes et Julian Holmes (Julian) ), nous suivons les expériences de Luke, un tel chef de projet courageux, et nombre de ses différentes rencontres partout dans l’entreprise, comme il travaille pour mettre en place et livrer son projet Agile.
Après avoir observé son voyage tristement distrayant, dans cet article nous expliquons ce qui se passe vraiment, et commençons à mettre en évidence les raisons qui se cachent derrière ses ennuis et comment une organisation peut les surmonter.
Scène 1 – la Partie prenante
Établir qu’il y ait un besoin business d’investir dans un projet est seulement le début de travail avec la partie prenante. Ils peuvent penser qu’ils savent de quoi ils ont besoin, ils pensent probablement qu’ils savent à quoi ressemble la solution, mais quoi qu’ils pensent savoir, ils doivent travailler avec l’équipe projet pour faire du projet un succès.
Ceci est où tant de projets s’engluent. Ils supposent qu’ils peuvent définir et communiquer clairement leurs besoins à l’équipe projet via un document sur leurs perceptions de ce que fera le système: « un seau de « doit faire ceci » »! Ceci réussit rarement.
Cependant, établir une Vision commune et une relation de travail proche avec la partie prenante et leurs utilisateurs métier permettra au projet de commencer rapidement, de collaborer avec les parties prenantes pour identifier des besoins critiques et de travailler pour livrer rapidement un retour sur investissement pour le business.
Sans cette collaboration, les « doit faire ceci » tourneront rapidement en suppositions, les spécifications en spéculations et nous aurons une forte probabilité que tout effort investi ne livrera pas ce que la partie prenante considère vraiment nécessaire.
Scène 2 – Approvisionnement
L’établissement d’un besoin business et avoir des parties prenantes désirant s’engager sur le projet est un bon début, mais ceci nous amène typiquement au besoin de compléter des procédures de financement, que ce soit à travers des équipes d’acheteurs externes, ou des PMOs internes.
Ces équipes veulent savoir ce qu’elles financent et ce qu’elles obtiendront pour leur argent.
Malheureusement, ils fonctionnent typiquement sur des suppositions simplistes telles que le business connait tous les détails de ce dont ils ont vraiment besoin à l’avance et que les besoins business ne changeront pas pendant la vie du projet.
Faire évoluer leur mentalité vers un engagement sur seulement de petits investissements et observer les retours sur investissement avant d’investir de nouveau peut sembler facile. Mais, quand les organisations n’ont jamais expérimenté d’un rapide ROI auparavant, elles s’attendent à ce que chaque projet traîne dans le temps et livre tard des résultats décevants.
Les gens des approvisionnements/achats doivent être courageux et poser quelques questions difficiles aux projets à livrer :
Et si nous avions à couper le financement au milieu du projet ?
Pouvons-nous confirmer de premiers revenus business qui financeront le reste du projet ?
Pouvons-nous financer progressivement votre projet sur la base de résultats démontrés ?
Notre chef de projet Agile serait heureux de répondre à ces questions.
Partenaire de DantotsuPM
Scène 3 – Gouvernance et conformité
Il y a de bonnes raisons pour lesquelles les organisations ont fondé cette gouvernance et ces équipes de conformité. Les règles de conformité réglementaire de l’industrie doivent être respectées et bien des organisations se sont brulées les doigts avec des projets, typiquement avec la méthode dite « en cascade », aussi, des filets de sécurité ont été exigés pour protéger le business de projets dévoyés et dangereux.
Cependant, ces règles de gouvernance peuvent aussi empêcher le projet d’utiliser des pratiques fructueuses et de mettre en application certaines des pratiques que les règles de gouvernance essayent d’éviter!
Des améliorations progressives du succès de livraison peuvent être réalisées en mettant en application des mesures draconiennes sur les projets. Mais faire une évolution radicale dans le succès des projets exige un changement plus significatif : une livraison progressive et agile.
Comprenez-nous bien, il n’y a rien de mal à poser des questions au projet comme :
« pouvez-vous prouver que vous comprenez nos besoins ? »
« pouvez-vous démontrer que vous avez une solution saine qui répondra à ces besoins ? »
« comprenez-vous les risques impliqués et pouvez-vous montrer comment vous les surmonterez ? »
« pouvez-vous démontrer que votre solution respecte les attentes des parties prenantes ? »
etc.
Cependant, le plus souvent, l’équipe de gouvernance a demandé sur ce sujet de la documentation pour supporter les réponses à ces questions par opposition à la preuve, à l’évidence concrète que l’équipe délivre ces résultats.
Revenir sur l’objectif du « point de contrôle » permettra typiquement à une équipe agile d’établir quelles mesures de progrès elle doit présenter pour fournir de meilleures mesures du réel progrès qu’une preuve écrite typique ne pourra jamais fournir.
Scène 4 – Architecture d’entreprise
Il y a beaucoup de valeur dont n’importe quel projet peut tirer profit à travailler avec l’Architecture d’Entreprise (EA) : Compréhension des technologies stratégiques de l’organisation; Établissement des besoins non-fonctionnels et techniques du projet; Alignement sur les autres systèmes de l’entreprise; Retours sur la vision technique du projet; pour en citer seulement quelques-uns.
Cependant, l’EA ne devrait pas chercher à définir le détail de la solution que l’équipe doit déterminer et livrer. Elle devrait ressembler à une partie prenante; aider à définir des besoins, à valider la valeur business et collaborer régulièrement avec l’équipe.
De cette façon, l’EA fournit une source de valeur de gouvernance technique stratégique et d’alignement sur la stratégie d’affaires.
Livrer un gros design d’entrée de jeu mène seulement à la spéculation et à la preuve par la documentation qu’une solution technique fonctionnera. Il vaut mieux démontrer une architecture exécutable et les équipes EA seront d’accord quand elles commencent à se rendre compte qu’il est possible de travailler de cette façon.
Scène 5 – équipe de développement
Non, tout sur le projet ne sera pas techniquement facile. Beaucoup de choses demandées à l’équipe projet seront nouvelles pour elle. Les développeurs auront des expériences différentes et la meilleure manière de surmonter les défis pour l’équipe sera de les encourager à collaborer.
Malheureusement beaucoup de membres d’équipes de développement ont eu des carrières où ils ont été encouragés à agir comme des héros. Ils ont été mesurés par leur performance individuelle et non par le succès de leur équipe projet.
Quand la livraison régulière de réussite démontrable devient importante, l’équipe a besoin à reconnaître ceci et chaque fois que des défis techniques surgissent, de travailler collaborativement pour trouver une solution. Ceci sera d’autant plus efficace que cela permettra de construire un sentiment d’équipe.
Le « Pairing » est une approche pour réaliser ceci, mais ce n’est pas exigé tout le temps, seulement quand quelqu’un sur l’équipe éprouve une difficulté et demande de l’aide. Alors un membre de l’équipe offrira son aide, aussi longtemps que durera le défi.
Scène 6 – Déploiement
Il n’est pas étonnant que les équipes de déploiement considèrent les équipes de développement avec prudence. Ils ont si souvent été en réception de solutions exécutables qui ont été précipitées dans le déploiement, mal évaluées, et pas conçues pour supporter efficacement un environnement de production. Cependant, si elles sont traitées comme une autre partie prenante du projet, on peut facilement répondre à leurs besoins et ainsi apaiser leurs craintes.
On s’attend aussi à ce qu’ils protègent le business et quand les projets ont rarement répondu aux attentes, ils se méfient beaucoup des nouvelles solutions qui sont fréquemment livrées et s’attendent à un déploiement fréquent. L’engagement régulier de l’équipe de déploiement dans le projet, leur permettre de voir les tests de pré-déploiement réussis et leur démontrer un plan de déploiement qui marche, aidera l’équipe à gagner leur confiance pour prévoir les déploiements fréquents de l’équipe Agile.
Scène 7 – Acceptation de la Partie Prenante
Au moment où l’équipe projet Agile est prête à déployer une solution qui ajoute de la valeur au business, il ne devrait y avoir aucune surprise pour le business sur ce qui va arriver. Leur participation continue en tant que membres de l’équipe projet et/ou leur présence aux démonstrations régulières, devraient leur fournir de suffisantes opportunités de s’assurer que le projet livre ce dont ils ont besoin, même si leur besoin a changé ou s’ils étaient incertains de ce qu’ils voulaient avant de l’avoir vu pour la première fois.
Cependant, même dans le scénario catastrophe où les parties prenantes voient seulement la solution à l’instant où une première solution de base pourrait être déployée, ils peuvent tout de même changer le cours du projet beaucoup plus tôt que ce ne serait possible avec un cycle de vie plus traditionnel.
Épilogue
Notre courageux chef de projet, Luke, a vraiment réussi à faire adopter son projet Agile par l’organisation, et même si ce fut un voyage pénible, ça en valait la peine. Le client a vraiment reçu de la valeur très tôt et Luke a établi un précédent avec beaucoup d’autres fonctions de l’organisation.
Au fil du temps il trouvera que le reste de l’organisation commence à reconnaître la valeur de l’approche Agile et des barrières tomberont ou seront ajustées pour apprécier la livraison de valeur au plus tôt.
Cependant, ce processus prendra du temps et cela nécessitera plus que les seuls efforts de Luke pour réaliser ce changement.
partagez ce billet avec vos amis, collègues et relations professionnelles
Après la préface en langue anglaise de Richard Pharro, PDG de APMG-International, vous y découvrirez un positionnement des méthodes Agiles (schéma ci-dessous) et comment les combiner au mieux pour en tirer le maximum d’efficacité.
Merci pour ce bel effort Lenny.
APMG International est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
On associe très souvent méthodes Agile et projets informatiques. Si l’on regarde les conditions de réussite de ces méthodes, on se rend assez vite compte qu’elles peuvent être utilisées de façon universelle.
De même ce n’est pas parce que les méthodes agiles sont très efficaces en développement informatique, qu’il faut rejeter en bloc les méthodes dites « classiques ». Les méthodes agiles sont des outils de la « boite à outils » de gestion de projet, il faut connaître les méthodes classiques (cascade (70’s), V, W, spirale (90’s)) pour bien utiliser « l’Agile ».
Quels sont les contextes propices à la mise en place de méthodes Agile ?
Quels critères « d’éligibilité » pour un projet pour être traité en « agile » ?
Besoin d’une aide à l’expression des besoins ?
Besoin d’une aide à l’acceptation du changement ?
Si ces critères sont présents, les méthodes agiles seront pertinentes.
Le courage est une valeur que doit posséder :
le chef de projet agile qui va s’exposer en continu, qui va devoir faire des choix
le client qui donne un « chèque en blanc » au Chef de projet.
Qu’est ce qui différencie les méthodes agile des autres méthodes ?
La position du Client : au centre de l’équipe
Les besoins du Client c’est comme une « liste de mariage », on a un budget, il y a des choses qu’on gardera, des choses qu’on changera peut être….
« Dis-moi quel délai et quel budget tu as, je te dirais ce que je peux faire »
Le client est « encapsulé » dans l’équipe et on ne parle plus de contrat, on bannit la notion MOA/MOE.
Agile évite l’effet tunnel avec un feed back aux utilisateurs réguliers (ce qui entretient leur motivation)
L’équipe :
L’agilité ne marche qu’en petit groupe autonome, les équipes autonomes voire autogérées.
Un bon chef de projet Agile (qui cumule souvent avec le rôle d’équipier) s’efface petit à petit au cours du projet par un bon transfert aux équipes.
L’agilité fait confiance à l’humain, il y a peu de règles (parfois même pas de chef de projet , pas de manager)
La posture des équipiers agile : « Comment puis-je t’aider ? »
Quelles sont les conditions de réussite des équipes agile?
L’agilité est empirique, ce n’est pas inné, ca s’apprend et donc il faut former les équipes: à faire des choix, à faire confiance, …..
Faire simple : L’outil privilégié des méthodes agile = le post-it pour partager et excel (équipiers réunis sur un seul lieu), si équipe à distance, on est obligé d’utiliser des outils collaboratifs pour compenser (sharepoint…). MS project ne sert qu’à faire du reporting.
Une communication en face à face et tous les métiers se mélangent (on a besoin d’être ensemble), par exemple des « stand up meeting » quotidiennes.
Faire la guerre aux mails, c’est difficile avec des équipes à distance/multi-sites mais dans ce cas chacune doit être autonome, responsable et doit réaliser ses propres livrables pour que ça marche.
Les stakeholders ont en permanence, la vision de l’avancement du projet.
Rythme durable : on ne s’épuise pas si on veut tenir la distance.
Pilotage par les enjeux et par les risques en continu
Peu d’indicateurs : le meilleur c’est le « Waouh » de l’utilisateur, mais être ferme sur le reporting
Réajustement en permanence (nécessite transparence, confiance et absence de sanctions)
Célébration des victoires rapides
En conclusion :
On parle de « méthode » Agile, mais il s’agit surtout de relations humaines plus que de méthodes. Que ce soit la position du Client, la confiance donnée aux équipiers, l’implication des parties prenantes, ce qui fait que ces méthodes marchent c’est une prise en compte différente des individus et de leurs besoins.
Frédéric Marchal, CSP Formations, Consultant qualité Certifié PMP et IPMA
cliquez sur l’image pour télécharger ce guide gratuit en français
Il y a beaucoup de descriptions concises de Scrum disponibles en ligne, et cet ouvrage d’initiation a pour objectif de fournir un niveau additionnel de détail sur les pratiques. Il n’a pas pour objectif de constituer l’étape finale de l’apprentissage de Scrum; il est conseillé aux équipes souhaitant adopter Scrum de se doter de l’ouvrage de Ken Schwaber Agile Project Management with Scrum ou Agile Software Development with Scrum, et de profiter des excellentes possibilités de formation ou de coaching Scrum qui sont offertes; tous les détails sont disponibles sur http://scrumalliance.org
Partenaire de DantotsuPM
.
partagez ce billet avec vos amis, collègues et relations professionnelles
DantotsuPM.com 