Récemment, une revue de rôle avec plus d’un millier d’agilistes œuvrant dans 60 pays a permis de mettre à jour la description des pratiquant des méthodes Agiles. L’examen pour la certification PMI-ACP® est en cours d’adaptation très Agile.
En quoi le PMI-ACP® change-t-il?
Un nouveau domaine apparait: Les principes et l’état d’esprit Agile (Agile Principles and Mindset). Ses concepts existaient bien sûr déjà dans les 6 domaines de bonnes pratiques (qui deviennent 7) mais était disséminé sur ceux-ci.
62 tâches ont été validées dans de contexte de ces 7 domaines:
Check this past article and Video
Agile Principles and MindsetDomain (NOUVEAU)
Value-driven DeliveryDomain
Stakeholder EngagementDomain
Team PerformanceDomain
Adaptive PlanningDomain
Problem Detection and ResolutionDomain
Continuous Improvement (Product, Process, People)
Partenaire de DantotsuPM
Dates
Un pilote est en place du 15 Juillet au 15 Octobre pendant lequel vous pouvez obtenir 20% de réduction sur votre inscriptionTous les détails sur le site du PMI, ici.
partagez ce billet avec vos amis, collègues et relations professionnelles
Le nombre de Dunbar représente une limite théorique au nombre de personnes dans un groupe qui peuvent entretenir des relations sociales stables. Des relations sociales stables sont nécessaires pour supporter l’application des valeurs, principes et techniques Agile. Le nombre de Dunbar est souvent cité comme étant de 150 personnes. Cependant, la limite pour n’importe quel groupe est non seulement le reflet d’une limite comme le nombre de Dunbar, mais aussi dépendante du contexte. Si nous acceptons qu’il y a une certaine limite théorique que nous ne pouvons pas dépasser comme le nombre de Dunbar, nous devons nous demander comment d’autres projets ou facteurs exogènes contraignent encore davantage le nombre maximum de personnes travaillant sur un problème. Pourquoi se donner tant de mal pour augmenter le nombre de personnes travaillant sur un problème ? Beaucoup d’Agilistes suggéreraient qu’une unique petite équipe est optimale. Cependant, beaucoup de problèmes exigeront une plus grande collation d’équipes pour délivrer la valeur et la fonctionnalité.
Les éléments contextuels supplémentaires qui modifient le nombre maximum théorique de personnes dans un groupe ou une équipe d’équipes incluent au moins quatre facteurs:
1. Cohésion
Ou dans quelle mesure les gens restent ensemble. Il y a beaucoup d’attributs qui peuvent produire la cohésion.
Les exemples incluent : grandes idées, objectifs, nationalités, religions et même identité d’entreprise.
La cohésion favorise une relation commune qui entraine les groupes à investir volontairement davantage d’efforts pour atteindre un but. Par exemple, il est souvent difficile de réaliser un groupe cohésif quand les membres viennent de multiples et externes entités de conseil. Chaque organisation impliquée dans le groupe a un jeu différent de buts organisationnels qui réduisent la cohésion à moins qu’ils ne soient subjugués par l’objectif du projet. La réduction du nombre de personnes en-dessous du nombre de Dunbar rend plus facile l’utilisation de techniques comme la pression entre pairs pour institutionnaliser une vision de projet qui augmente la cohésion.
Est une mesure du nombre de propriétés d’un projet qui sortent de la norme.
La complexité d’un problème réduit le nombre maximum optimal de personnes qui peuvent être impliquées parce que la complexité exige généralement plus de contrôle et de coordination ou des équipes plus petites pour assurer la collaboration.
3. Incertitude
Survient quand les équipes cherchent une réponse à un problème business ou technique.
Quand une équipe doit aborder un problème métier inconnu ou une nouvelle technologie, de la recherche est souvent nécessaire. La recherche est généralement contrainte à de petites équipes avec des compétences spécialisées ce qui réduit la taille de groupe maximale optimale pour ce type d’effort bien en dessous du nombre de Dunbar.
Comme on découvre des concepts et des idées, certains peuvent être déployés plus largement pour être étoffés, prototypés et implémentés en augmentant le groupe travaillant sur le projet en direction du nombre de Dunbar.
4. Dépendances
Quand elles existent entre des composants, cela signifie souvent que le travail doit être concentré (ou du moins s’étendre moins largement).
Les dépendances réduisent le nombre de personnes et d’équipes qui peuvent être efficacement utilisées.
L’idée d’augmenter le nombre de personnes et d’équipes travaillant sur un projet semble souvent être un mécanisme pour délivrer de la valeur plus rapidement. En ajoutant des personnes, il est suggéré de se souvenir que le nombre de personnes travaillant sur un problème est une contrainte qui ne peut pas être traitée en augmentant linéairement le nombre de personnes impliquées sur un problème jusqu’à atteindre une limite comme le nombre de Dunbar.
Le contexte a un impact direct sur la taille que tout groupe peut atteindre avant que l’administration et autres contraintes en réduisent l’efficacité. Il est souvent dit que neuf femmes ne peuvent pas faire un bébé en un mois. En plus du nombre de Dunbar, le contexte joue un rôle important dans la définition de la taille totale de l’équipe.
En déterminant de quelle taille un programme Agile pourrait être, un des « faits » souvent cité est que le nombre de personnes impliqué dans un programme Agile est soumis au nombre de Dunbar. Le nombre de Dunbar est la limite du nombre de personnes dans un groupe qui peuvent entretenir des relations sociales stables. Le terme, relation sociale est le reflet d’interactions régulières, la capacité de reconnaître un autre membre dans le cadre du groupe ou d’être engagés sur un but commun. Ces attributs sont importants pour tout projet et sont peut-être plus importants dans les projets Agile parce que ceux-ci comptent sur la cohésion d’équipe pour minimiser les mécanismes de contrôle et la bureaucratie.
Le concept du nombre de Dunbar est basé sur de la recherche à l’origine exécutée par les observations de primates et étendue ensuite aux humains au début des années 1990. En juin 1992, Robin Dunbar publié « La taille du néocortex comme contrainte de la taille de groupe chez les primates » dans le Journal of Human Evolution (Volume 22, Edition 6, juin 1992, pages 469-493). Dans ce papier, Dunbar a mis en évidence une corrélation entre la taille du cerveau d’un primate et la taille moyenne de groupe social.
En résumé, Dunbar a écrit :
La taille de groupe se révèle être une fonction de volume néocortical relatif, mais les variables écologiques ne le sont pas. Ceci est interprété comme l’évidence en faveur de la théorie d’intellect social et à l’encontre des théories écologiques. Il est suggéré que le nombre de neurones du néocortex limite la capacité de traitement de l’information de l’organisme et que ceci limite alors le nombre de relations qu’un individu peut contrôler simultanément. Quand la taille d’un groupe excède cette limite, le groupe devient instable et commence à se fragmenter. Ceci situe alors une limite supérieure pour la taille des groupes que n’importe quelle espèce donnée peut entretenir comme des unités sociales cohésives dans la durée.
Bien que la taille de groupe de 150 soit souvent citée comme le nombre de Dunbar, 150 est une approximation.
Comme indiqué dans le « Les limites d’Amitié » (Limits of Friendship) par Maria Konnikova (7 octobre 2014) le nombre de Dunbar peut aller de 100 à 200 personnes selon des facteurs comme le fait d’être sociable. D’autres limites de taille de groupe ont aussi été publiées par d’autres docteurs comme Peter Killworth et Russell Bernard qui indiquent plus de 200 personnes.
Selon le nombre de Dunbar, le Scaled Agile Framework Enterprise (SAFe) suggère que les plus grandes Releases Agile (ART) pourraient inclure environ 150 personnes. L’ART est supporté par un cadre (le framework SAFe), une hiérarchie ( des ingénieurs de Release et des ScrumMasters) et une bureaucratie (un management de produit et des propriétaires de produits). Quand Agile est pratiqué par une équipe de 5 à 9 personnes cette « surcharge administrative » ne serait pas nécessaire pour assurer la coordination.
La mise à l’échelle d’Agile est un numéro d’équilibriste entre efficacité des techniques Agiles au niveau de l’équipe et les concessions faites pour contrôler quand Agile est utilisé sur de plus grands efforts.
Historiquement, les très grands projets ont tendance à être moins efficaces. Capers Jones dans Applied Software Measurement, Third Edition (P295) indique que la productivité chute pour tous les types de projets lorsqu’ils excèdent 1000 points de fonction. Les points de fonction sont une méthode du standard ISO pour mesurer la taille du logiciel basée sur un ensemble de règles standard. Tout simplement, plus un projet est grand en points de fonction et plus grande sera l’équipe (ou l’équipe d’équipes) qui devra livrer le projet. D’où le besoin de plus de contrôle toutes choses égales par ailleurs. Il met en exergue (p 307) le fait que comme la taille de projet augmente, la probabilité d’annulation croit pareillement.
Le livre référence
La montée en volume d’Agile nécessite beaucoup de techniques utilisées au niveau d’une équipe Agile, comme la petite taille d’équipe, le travail par petits lots de fonctionnalités et Scrum. Ces techniques sont très « Lean », mais limitées par la quantité de valeur qui peut être délivrée dans une période spécifique de temps. Comme les projets Agiles grandissent en taille, des techniques supplémentaires sont nécessaires pour maintenir le contrôle. Le nombre de Dunbar (ou des idées similaires) fournit une limite pour essayer d’éviter de laisser un travail devenir trop important pour être gérable. Le nombre agit comme une limite au nombre de personnes impliquées dans un travail. L’application de contraintes supplémentaires, comme des releases ou des incréments de programme SAFe, ajoutent la dimension de temporalité comme contrainte. La combinaison des contraintes sur le nombre de personnes et combien de temps ces personnes travailleront fournit une contrainte explicite de combien de travail peut être livré.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
This FREE download follows on from Melanie Franklin’s last one on how to explain Agile to your organisation.
Here Melanie talks about how Big Design Up Front can be replaced, the value of Feedback Loops, how agile delegation works and the importance of networking.
Scrum est une méthode Agile pour la réalisation de projets complexes. A l’origine, la méthodologie Scrum a été élaborée pour le développement de projets IT, mais la méthode s’avère aussi très efficace pour régir tout environnement de travail complexe et innovant. Les possibilités sont donc sans fin. La structure simple de Scrum peut être appliquée à tout type de projet ou développement produit. Scrum peut ainsi fournir une base et une méthode collaborative, saine et agréable pour atteindre les objectifs de l’entreprise.
Scrum est la première méthodologie de développement Agile, utilisée par les Fortune 500 entreprises mondiales. C’est une structure de travail solide et agile qui a déjà prouvé son application à une grande variété de projet et d’équipe. Ainsi la raison d’être de la Scrum Alliance est d’apporter de nouvelles solutions en matière de gestion de projets complexes, et d’ouvrir la méthodologie Scrum et les principes agile au-delà du secteur IT, vers tous les secteurs d’activités.
LES AVANTAGES DE SCRUM
Scrum est une approche basée sur l’équipe, comme un moyen pour créer de la valeur pour l’entreprise. Les membres de l’équipe travaillent ensemble pour atteindre un but commun. La méthodologie Scrum vise à encourager les échanges entre les membres de l’équipe pour qu’elle puisse apporter de la valeur à l’entreprise.
Scrum exige une avancée du travail de conception du produit fini au début de chaque « Sprint ». Peu importe les activités engagées pendant le « sprint », l’attention est portée la réalisation du produit.
Scrum est une méthodologie élaborée de manière à promouvoir et faciliter la collaboration. Les membres de l’équipe collaborent entre eux pour trouver la meilleure solution pour construire et livrer le logiciel, ou autres sortes de livrable, à l’entreprise.
Les équipes Scrum font des plans fréquents. Ces plans aident les équipes et l’entreprise à prendre des décisions. Cependant, le but n’est pas que l’équipe suive le plan aveuglément mais de permettre la création de valeur et l’adoption des changements dans l’organisation.
LES FAITS MARQUANTS SCRUM
Plus de 368 000 certifiés Scrum Alliance
Utilisé dans plus de 175 pays à travers le monde
La Scrum Alliance possède approximativement 275 groupes d’utilisateurs à travers le monde.
Utiliser dans de nombreuses industries à travers le monde : développement de logiciel, enseignement, marketing, opération, militaire, automobile et plus encore.
LE ROLE DE SCRUM
cliquez sur l’image pour télécharger ce guide gratuit en français
Une équipe Scrum à trois rôles :
Le Scrum Master – Soutient l’équipe pour utiliser au mieux Scrum dans l’élaboration du produit.
Le Propriétaire du produit (Product Owner) – Maintient la vision du produit.
Le Développeur (Development Team) – Construit/élabore le produit.
PARCOURS DE QUALIFICATION SCRUM
La formation et la certification Scrum remplissent la vision du manifeste Agile en favorisant de meilleures collaborations, productivité et succès parmi les membres de l’équipe.
La formation Certified Scrum Master® est sur les fondamentaux et s’adresse aux membres de l’équipe Scrum ou les professionnels Scrum Master.
La formation Certified Scrum Product owner® expose aux participants les fondamentaux de la méthodologie mais cette fois du point de vue du Product Owner.
La formation Certified product Developer® forme les membres de l’équipe Scrum avec des techniques avancées d’ingénierie Agile et d’autres techniques Agile, qu’il est nécessaire de posséder pour la création de logiciels, en complément des fondamentaux Scrum developer.
La reconnaissance ultime pour tous les praticiens Scrum, est l’obtention de l’accréditation Certified Scrum Professional® qui permet de prouver sa véritable connaissance et son expérience Scrum.
Bien faire ou faire vite? Il y a parfois un prix à payer quand on “fait vite”. C’est ce qu’on appelle la Dette Technique.
MS-DOS est probablement l’exemple le plus connu de Dette Technique. En 1981, IBM demanda à Bill Gates de développer un système opératif pour son nouveau PC. Pour respecter les délais, il prit le QDOS (Quick and Dirty Operating System, Système Opératif Vite fait Mal fait) et le renomma MS-DOS. Bâclé et grossier, MS-DOS a été alourdi par une dette dès sa conception, il était doté d’un ensemble de commandes qui laissaient à désirer et de caractéristiques limitées.
Dans le monde de la gestion de projet, le respect des délais est un point clé pour mesurer la réussite de la plupart des projets. En vous pressant pour respecter les délais, il se peut que vous accumuliez une dette sans vous en rendre compte, silencieusement… mais de manière constante.
La Dette Technique peut prendre les formes suivantes:
Documentation ou manuel d’utilisation inexistants
Programmation de mauvaise qualité (non structurée, avec peu de commentaires, codage en dur)
Bases de données mal structurées (données redondantes, erreurs de données)
Mauvaise conception (mauvaise architecture, non modulable)
Mauvais processus (inefficaces, entraînant une perte de temps, sujets à erreurs)
Habituellement, on parle de dette pour des projets de développement de logiciels, mais elle ne s’applique pas uniquement au software – toutes sortes de projets peuvent générer une dette.
Souvent, la Dette Technique est issue de la pression exercée pour respecter les délais, mais ce n’est pas seulement une question de précipitation.
Plusieurs facteurs peuvent être source de dette :
Image courtesy of ambro / FreeDigitalPhotos.net
La vitesse: la précipitation est probablement la première cause de Dette Technique
Vision à court terme: rapiéçage et raccommodage. Solutions dénuées d’architectures
Contre-la-montre: efforts concentrés sur le retard accumulé (au lieu de penser au futur)
Innovation de pointe : apprentissage sur le tas
Manque de compétences: assignation de personnel n’ayant pas les bonnes compétences (ou pas de compétences du tout) à des tâches complexes.
Pourquoi s’en inquiéter?
La Dette Technique est comme la dette financière… vous pouvez l’ignorer pendant un temps, mais l’accumulation de dette reviendra vous hanter. En présence de dette, le résultat final sera chaotique – un patchwork ou un sac de nœuds difficile à comprendre ou à changer.
Partenaire de DantotsuPM
Ce sera une surcharge potentielle pour tout ce qui sera entrepris par la suite – la Dette Technique peut ralentir et compliquer des projets futurs. Elle peut aussi engendrer un vieillissement prématuré – l’accumulation de dette peut raccourcir la durée de vie de votre solution.
Ne vous précipitez pas sur la dette.
le livre de Chris Sterling
La principale source de dette est la précipitation. Certaines méthodes de gestion de projet se basent sur la rapidité ; c’est le cas de la plupart des variantes légères d’Agile. Ces dernières, comme Scrum, généreront nécessairement une dette si l’on se focalise trop sur la rapidité. Les délais seront peut-être respectés, mais si c’est au prix d’autres facteurs de bonnes pratiques, tels que le design, la planification ou la qualité, alors il se peut que vous accumuliez une dette.
Il existe deux façons de contourner ce problème pour les projets Agile : essayer de rendre cette méthode légère plus robuste (comme décrit dans le livre « Managing Software Debt » de Chris Sterling) ou utiliser une solution Agile.
Pourquoi utiliserAgile?
Les méthodes Agile telles que DSDM Atern (parfois appelée AgilePM) permettent de combiner agilité avec architecture et design. Atern possède également un ensemble d’outils assurant une approche à long terme (plans, étude de rentabilité, etc.) – qui aident aussi à établir le compromis entre rapidité et dette (et par conséquent à éliminer ou réduire la dette).
Quelle que soit la solution que vous choisissiez, que vous utilisiez Agile ou non, vous devez garder cette notion de dette à l’esprit.
Jeff Ball
Vous ne pourrez probablement pas vous en débarrasser totalement, mais vous devez appliquer ces trois règles d’or :
Commencez dès aujourd’hui à rembourser les anciennes dettes (chaque nouveau projet rectifie des erreurs et confusions passées)
Évitez de nouvelles dettes (bien faire les choses à l’avenir, équilibrer rapidité et qualité)
Si, pour un projet, vous n’avez pas d’autre choix que de générer une dette, éliminez-la le plus vite possible
In order to stay competitive, product development organizations must deliver more valuable products to the market faster.
The failure of some organizations to get the right product fast enough has sparked (a much needed and long lasting) debate to find a « perfect » innovation process that could develop any product faster and better than anyone else. New project management methods such as the lean startup, SCRUM, lean product development and so fourth make fairly similar promises to fix very difficult challenges.
The truth is rather that there is no quick fix to deliver great products in such a short time. Instead, successful companies use pragmatic approaches where the solution varies greatly depending on their specific context. One trend places the backlog in the center. It has been proven that, if properly adapted to the context, lean backlog management together with actionable metrics can make a major impact on project success.
The presentation Lean Projects start with Lean Backlog will have three parts:
a summary of some theory behind a great backlog, a walkthrough of two cases from very different organizations with similar lessons learned and finally our suggestions on how to get started with lean backlog management and actionable metrics.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
«Le contexte conditionne le comportement.» Charles Pellerin
L’agilité organisationnelle, peu importe son application en projet ou ailleurs dans une entreprise, nécessite un changement de culture.
Une entreprise agile est basée sur une culture :
collaborative, par opposition à directive et contrôlante;
qui aime, accueille activement et s’adapte facilement au changement;
qui est centrée sur l’humain et le respect mutuel;
dont la raison d’être est la production de valeur optimale pour l’ensemble de ses parties prenantes (fournisseurs, partenaires, employés, clients, actionnaires, la société).
Ces quatre «valeurs» lui permettent de mieux fonctionner que d’autres types de cultures dans un environnement turbulent, tel que celui qui caractérise ce début de 21e siècle.
L’organisation agile utilise des approches et des pratiques spécifiques qui visent à vivre et matérialiser ces valeurs :
nourrissez l’agilité
elle a une vision et une mission claires, partagées par l’ensemble de ses employés et partenaires;
elle tient compte des intérêts de chacun et en favorise l’alignement;
elle favorise l’engagement de tous pour la réussite autant collective qu’individuelle;
elle favorise le réseautage entre les silos spécialisés et le travail transversal;
elle favorise la décentralisation dans la prise de décision et l’autonomie d’action des individus et des équipes;
elle favorise la responsabilisation individuelle et l’imputabilité collective;
elle favorise la collaboration et l’entraide entre ses employés plutôt que la compétition;
elle favorise la transparence, ainsi que la communication et le partage d’information en continu;
elle valorise et favorise la proactivité, la créativité et la réactivité autant individuelles que collectives.
Elle appuie ces approches et pratiques en mettant en place des structures, des processus et des outils de support réactifs, flexibles et adaptables ET en fournissant les ressources suffisantes pour leur bon fonctionnement.
Enfin, l’organisation agile utilise un système de reconnaissances (incitatifs et autres) qui renforce le maintien et l’amélioration de l’ensemble de ses attributs agiles :
Serez-vous les premiers à adopter une culture agile dans votre industrie?
Winston Churchill
«Mieux vaut prendre le changement par la main avant qu’il ne nous prenne par la gorge.»
WinstonChurchill
La gestion de projet agile est encore très peu répandue dans les secteurs autres que le développement logiciel. Elle progresse de plus en plus vite dans d’autres domaines, comme le développement de nouveaux produits, en réponse aux pressions de plus en plus grandes de maximiser les bénéfices dans un monde où les ressources naturelles, humaines et autres se font de plus en plus rares.
La marche, sinon la course vers l’agilité organisationnelle s’accélère et ceux qui suivront ce chemin assureront plus que tous les autres leur viabilité et leur pérennité à plus ou moins moyen terme[i].
«Rien n’est permanent, sauf le changement.» Héraclite
La firme TOP (Totally Optimised Projects), un des leaders mondiaux en réalisation des bénéfices, a évalué le pourcentage de bénéfices réalisés pour chacun des 7 niveaux de livraison en mode projet, résultats très souvent confirmés dans les faits. La figure suivante présente cette évaluation sous forme graphique[i].
Pourcentage de bénéfices possibles réalisés selon le niveau de livraison d’un projet
Nous pouvons voir qu’un projet qui livre «dans les temps et dans les coûts», comme unique préoccupation, ne livre pas plus que 30% des bénéfices possibles. Si les «spécifications ‘initiales’ sont respectées», ces spécifications n’étant pas ajustées en cours de réalisation de projet pour tenir compte de l’évolution des besoins, un tel projet peut livrer entre 30 et 50 % des bénéfices possibles… ce en ne respectant pas nécessairement les délais et coûts initialement prévus.
Atteindre les niveaux 6 et 7 passe obligatoirement par une gestion de projet épousant les valeurs et appliquant les principes et ayant les caractéristiques d’une organisation agile de haut niveau.
La figure suivante présente un cadre conceptuel adaptant les éléments de l’agilité à la réalisation des projets.
Cadre conceptuel de la gestion de projet en mode «agile»
Cadre conceptuel de la gestion de projet en mode «agile»
Ce cadre résume en 4 valeurs, 4 pratiques et 10 principes , l’état d’esprit et les pratiques spécifiques observés dans les applications de l’agilité en projet, notamment :
la gestion «agile» des projets d’innovation et de développement de nouveaux produits (informatiques et autres), et
la gestion «LEAN» utilisée par les spécialistes du Lean Construction Management.
En intégrant ces éléments avec ceux d’une «organisation agile», nous obtenons l’équation suivante, qui présente l’ensemble des caractéristiques de la gestion de projet agile.
PRODUCTIVITÉ = A1 + A2 + V = PERFORMANCE OPTIMALE
Une organisation AGILE c’est, dans un contexte d’affaires turbulent, (très complexe, hautement compétitif, incertain, en changement constant, exigeant une grande vélocité et un haut niveau de créativité afin d’innover et s’adapter sans cesse) où nous avons :
A1 / Alignement du QUI
Un ensemble de personnes COLLECTIVEMENT ENGAGÉES où toutes les parties prenantes sont alignées, parce qu’elles ont:
des valeurs partagées (même culture)
une vision partagée
des intérêts convergents
une mesure commune du succès
les connaissances requises
des comportements collaboratifs
et sont engagées à réussir ensemble
A2/ Agilité du Comment, Quand, Combien
AVEC PROACTIVITÉ, CRÉATIVITÉ, GRANDE RÉACTIVITÉ, FLEXIBILITÉ ET ADAPTABILITÉ
Ces personnes font très bien, en utilisant des approches et outils AGILES (COMMENT, QUAND, COMBIEN), notamment:
une ouverture et une capacité de s’adapter au changement
une structure, une organisation, des technologies flexibles et adaptables
des ressources SUFFISANTES flexibles et adaptables
l’apprentissage et la capitalisation des leçons apprises en continu
des pratiques de veille et d’innovation (créativité) axées sur la création optimale de valeur (bénéfices)
des pratiques valorisant les RH et encourageant la collaboration
V/ Valeur Optimale
BÉNÉFICES «QUOI, POURQUOI», POUR TOUS
Ces personnes font LES bonnes choses, CELLES OPTIMISANT LA VALEUR POUR TOUS
LES bonnes choses, soit la raison d’être de l’organisation et des parties prenantes
En quelques mots, la gestion de projet en mode «agile» c’est, dans un environnement d’affaires turbulent:
l’ensemble des parties prenantes d’un projet, COLLECTIVEMENT ENGAGÉES,
qui réalisent très bien, en respectant les attentes quotidiennes de chacun, AVEC PROACTIVITÉ, CRÉATIVITÉ, GRANDE RÉACTIVITÉ, FLEXIBILITÉ ET ADAPTABILITÉ
LES bonnes choses, soit LES LIVRABLES OPTIMISANT LA VALEUR POUR TOUS
Et c’est de cette façon qu’on atteint une performance exceptionnelle et qu’on réalise des projets donnant les meilleurs résultats possible[ii].
Cet article est le second d’une courte série de 3 billets produite par Claude :
Voici le premier d’une série de 3 articles qui nous mèneront de la gestion de projet « traditionnelle » à l’Agilité !
«Aucun problème ne peut être résolu sans changer le niveau de conscience qui l’a engendré.»
Albert Einstein
La gestion de projet «traditionnelle» n’est pas nécessairement celle documentée dans le PMBoK, le Project Management Body of Knowledge, du PMI (Project Management Institute). Bien que ce document ne soit pas parfait, il est en évolution constante et inclut maintenant dans sa dernière édition plusieurs des principes de l’agilité.
Le guide en français
Dans les faits, tout ce qui est documenté dans le PMBoK est utilisable en gestion de projet «agile».
Il suffit d’utiliser ces pratiques et outils dans un état d’esprit collaboratif «gagnant-gagnant», plutôt que dans un état d’esprit conflictuel, contrôlant et compétitif «gagnant-perdant».
De plus, très peu d’organisations prétendant appliquer le PMBoK, ont vraiment des processus et des pratiques couvrant l’ensemble des volets de la gestion de projet (parties- prenantes, contenu, qualité, bénéfices, changements, risques, communications, intégration, etc.).
La plupart ne se préoccupent que du triangle «contenu-délais-coûts», en considérant les délais et les coûts comme des livrables, plutôt que comme des contraintes à respecter OU À REDÉFINIR AU BESOIN SELON L’ÉVOLUTION DU PROJET, en réponse à des événements imprévus, des ajouts de contenu ou tout simplement pour saisir de nouvelles opportunités. Pour ces organisations, le coût d’un projet est plus important que le retour sur l’investissement (les bénéfices qu’on retirera de l’utilisation des livrables). Et, pour ces organisations, le tout se réalise dans un état d’esprit de compétition et à travers de nombreux conflits et litiges qui perdureront longtemps après l’achèvement des livrables des projets et leur transfert contractuel aux «clients».
En quelques mots, la gestion de projet en mode «traditionnel», celle qui est encore pratiquée par la majorité des entreprises réalisant des projets et «subie» par leurs clients, leurs partenaires, employés et fournisseurs, c’est, dans un environnement d’affaires turbulent :
un ensemble limité de personnes,
qui font de façon conflictuelle, plus souvent en s’affrontant qu’en collaborant,des choses (activités ou tâches, souvent pas les bonnes),
devant respecter à tout prix un délai et un budget pas toujours réalistes.
En termes de bénéfices réalisés, les résultats sont alors très variables, sinon décevants.
La figure suivante [i] résume les 7 types de résultats qu’un projet peut livrer «en termes de bénéfices»
La firme TOP (Totally Optimised Projects), un des leaders mondiaux en réalisation des bénéfices, a évalué le pourcentage de bénéfices réalisés pour chacun des 7 niveaux de livraison, résultats très souvent confirmés dans les faits. La figure suivante présente cette évaluation sous forme graphique.
Pourcentage de bénéfices possibles réalisés selon le niveau de livraison d’un projet.
Nous pouvons voir qu’un projet qui livre «dans les temps et dans les coûts», comme unique préoccupation, ne livre pas plus que 30% des bénéfices possibles.
Si les «spécifications ‘initiales’ sont respectées», ces spécifications n’étant pas ajustées en cours de réalisation de projet pour tenir compte de l’évolution des besoins, un tel projet peut livrer entre 30 et 50 % des bénéfices possibles… ce en ne respectant pas nécessairement les délais et coûts initialement prévus.
The Choice
Comme nous le verrons dans un prochain article[ii], l’objectif de la mise en place d’un nouveau processus de gestion de projet est de faire mieux que cela, et même, à moyenne échéance, de permettre à l’entreprise adoptant ce nouveau processus et à ses clients d’atteindre des résultats de niveaux 6 ou 7 le plus souvent possible.
[i]THE CHOICE, Jed Simms et Alex Chapman, 2011, maintenant disponible sur Kindle.
Invités par l’école ENSIMAG du groupe Grenoble-INP et la Branche Rhône-Alpes du PMI France, Agnès LAVILLE fondatrice de Méta Projets Management et Frédéric RODRIGUEZ, Consultant, Coach et Formateur Indépendant, ont animé avec une grande agilité le 27 Novembre, pour un public de plus de 120 industriels, enseignants et étudiants, une conférence et des ateliers pour expérimenter comment améliorer la performance des projets par l’agilité organisationnelle.
Agnès Lavigne
La philosophie Agile utilise des modèles organisationnels basés sur les personnes, la collaboration et des valeurs partagées. Elle met en œuvre une planification récurrente, des livraisons itératives et progressives, la réponse rapide et flexible aux changements et une communication ouverte entre équipes, parties prenantes et clients. L’utilisation d’Agile comme une approche de management de projets a augmenté radicalement dans les dernières années. Mais:
Comment se définit l’Agilité organisationnelle ?
Quelles pratiques mènent à plus d’Agilité ?
L’Agilité permet-elle aux organisations d’augmenter le taux de réussite de leurs projets ?
Plutôt que de réaliser un exposé formel, la dynamique équipe de Méta Projets Management invite les participants à se regrouper en ateliers de 9 ou 10 personnes autour de plaques disposées dans l’amphi.
A chaque atelier est proposé un scénario de plusieurs projets à réaliser par une entreprise en fonction des demandes de plusieurs clients tout en en tenant compte des tâches successives à réaliser, de leurs coûts de réalisation, des ressources limitées de la production, des gains escomptés, de la facturation à fourniture du produit demandé et bien entendu de la satisfaction des clients.
Les cartes posées sur la table correspondent aux différentes « user stories » mises en production par les participants afin de satisfaire les demandes clients.
Rapidement chaque atelier au moyen des cartes descriptives de tous les besoins s’attelle à prioriser l’enchainement des travaux à faire afin de satisfaire au mieux l’ensemble des exigences naturellement contradictoires.
Comme dans la vraie vie, au fil du temps, des changements arrivent à travers de nouveaux besoins clients ou de nouveaux clients. Agnès au micro cadence plusieurs itérations invitant chaque groupe à découvrir les changements distribués dans de nouvelles enveloppes. La petite équipe de Méta Projets Managements passe d’ateliers en ateliers pour prodiguer les conseils et récompenser chaque mise en production par un paquet de bonbons au chocolat.
Au bout d’une heure et de trois itérations, Agnès en conclusion de la soirée invite les rapporteurs de chacun des groupes d’annoncer leurs résultats en terme de nombre de mises en production (satisfaction client) et de facturation (bénéfices pour l’entreprise) puis de faire un bilan sur comment le groupe a vécu cette expérience d’agilité.
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 nouveau domaine apparait: Les principes et l’état d’esprit Agile (Agile Principles and Mindset). Ses concepts existaient bien sûr déjà dans les 6 domaines de bonnes pratiques (qui deviennent 7) mais était disséminé sur ceux-ci.
Les éléments contextuels supplémentaires qui modifient le nombre maximum théorique de personnes dans un groupe ou une équipe d’équipes incluent au moins quatre facteurs:
Les exemples incluent : grandes idées, objectifs, nationalités, religions et même identité d’entreprise.
La complexité d’un problème réduit le nombre maximum optimal de personnes qui peuvent être impliquées parce que la complexité exige généralement plus de contrôle et de coordination ou des équipes plus petites pour assurer la collaboration.
Quand une équipe doit aborder un problème métier inconnu ou une nouvelle technologie, de la recherche est souvent nécessaire. La recherche est généralement contrainte à de petites équipes avec des compétences spécialisées ce qui réduit la taille de groupe maximale optimale pour ce type d’effort bien en dessous du nombre de Dunbar.
Les dépendances réduisent le nombre de personnes et d’équipes qui peuvent être efficacement utilisées.
La mise à l’échelle d’Agile est un numéro d’équilibriste entre efficacité des techniques Agiles au niveau de l’équipe et les concessions faites pour contrôler quand Agile est utilisé sur de plus grands efforts.
Plus de 368 000 certifiés Scrum Alliance
DantotsuPM.com 