articles, méthodes, partages d'expérience et rdv du management de projets et de l'agilité
Méthodes, retours d’expérience, bonnes pratiques
Rien de sérieux et quel beau travail d’équipe Agile !
The new guide incorporates extensive feedback, making its approach highly relevant not only to the European Institutions but also to the external community.
Given the increasing adoption of Agile methods across organisations worldwide, this guide aims to support teams in becoming even more effective when delivering high-quality solutions, manage changing priorities and ultimately lead to an increase in productivity and project transparency.
This guide has been created for:
Even though PM²-Agile primarily addresses the needs of software development projects, most of the practices and tools and techniques included in this guide are applicable to non-IT projects, and this is reflected in the PM²-Agile Mindsets.
PM²-Agile both extends and enhances the PM² Methodology with Agile principles and practices and provides harmonisation between these practices and corporate governance, programme management, operations, enterprise architecture and interoperability.
Pour répondre à cette situation qui bouleverse notre monde des projets, nous sommes convaincus que l’hybridation, en tant que modèle de convergence des modes projet, est une solution majeure. Il faut dépasser les limites des approches existantes : Cycle en V, Agile, Agile à l’échelle…
À compter de septembre prochain, le PMI France propose à ses membres de rejoindre le Lab Hybrid du PMI France pour définir ensemble un cadre de travail référent sur cette thématique, en associant subtilement prédictif et itératif, en analysant les forces et faiblesses intrinsèques de chacune des méthodes et leur complémentarité.
Pour cela, PMI France va organiser des « Master Class » et des ateliers de travail sur l’hybridation, avec pour objectif final la création d’une micro-certification qui sera proposée au niveau du PMI Global.
L’hybridation est désormais ancrée dans le monde réel des projets, tant au niveau du portefeuille, des méthodes que des compétences. Enfin PMI® s’est engagé résolument dans cette voie, depuis l’acquisition de Disciplined Agile, le PMBOK Guide V6 et désormais avec la sortie du PMBOK Guide V7.
Il s’agit donc de fédérer les énergies et les compétences au sein du PMI France, afin de caractériser et définir ensemble cette nouvelle approche.
Rejoignez une initiative innovante ! Rejoignez-nous ! Contactez Stéphane Derouin (sderouin@d2x-expertise.com).
PMI is a registered mark of Project Management Institute, Inc.
Dans un monde où les modes de travail évoluent constamment, les méthodologies de gestion de projet des organisations doivent également être révolutionnées.
La gestion de projet est devenue l’un des piliers les plus importants au sein de toute entreprise car elle a été reconnue comme l’un des facteurs fondamentaux de son bon fonctionnement.
Les entreprises recherchent des technologies, des systèmes et des processus qui les aident à personnaliser et à optimiser la gestion de projet.
Les clients connaissent une croissance exponentielle et, d’une manière ou d’une autre, les entreprises doivent être capables de s’adapter.
Les méthodes Agiles sont nées pour apporter cette flexibilité manquante, dans le monde de la gestion de projet, en se détachant complètement des méthodes traditionnelles, également appelées waterfall, en cascade ou cycle en V.
J’ai remarqué que l’efficacité d’une équipe n’est pas fonction de combien de temps ses membres ont travaillé ensemble de façon agile. C’est plutôt fonction de combien de cycles ils ont réalisé ensemble. Combien de fois ils se sont regroupés, ont pris des engagements, ont réfléchi à comment les tenir et ensuite regardé rétrospectivement et adapté leur pratique. Autrement dit, pour une équipe Scrum, combien de sprints ils ont fait ensemble. En général, plus de sprints, plus d’enseignements.
Cela crée une opportunité unique que certains de mes clients veulent exploiter. Quand une équipe commence ou se regroupe, particulièrement après l’un de nos ateliers « Agile for Teams », il y a la nouvelle prise de conscience de soi-même, de l’enthousiasme et des idées à essayer. Pendant les deux semaines suivantes, vous pouvez les canaliser en un premier sprint fort… ou vous pouvez saisir l’occasion d’en faire dix.
Dix sprints de 1 jour vous permettent d’achever 10 cycles de travail et d’apprentissage ensemble, 10 fois plus rapidement qu’une équipe typique. Et cela vous force à identifier les compétences et pratiques critiques comme trouver de petites poches de valeur et collaborer ensemble sur quelque chose au lieu de juste de remettre son travail de l’un à l’autre en séquence, ignorant facilement les compétences et pratiques dans un sprint de 2 semaines.
Vous dépenserez plus de temps dans les cérémonies de sprint. Aussi, ne devriez-vous probablement pas les adopter pour toujours. Mais si vous ressemblez à mes clients, vous serez étonnés de constater combien vous aurez réalisé.
9:00-9:30 — Planifier la journée. Trouvez un, peut-être deux, incréments de valeur que vous pouvez achever ensemble aujourd’hui.
Ne vous inquiétez pas, vous pouvez tout de même faire des sprints quotidiens. Le changement clé est de mettre la revue, retro et planification en séquence le matin ou l’après-midi quand vous êtes tous là. Puis, le temps à une extrémité ou l’autre de la journée de travail devient la partie sprint. 2vitez juste de travailler des heures supplémentaires car vous voulez parvenir à une réelle compréhension de ce que votre équipe peut accomplir en un jour de focus.
#1. Mettez-vous d’accord au départ que ce sera une expérience de deux semaines et non pas votre nouveau normal.
Travailler de cette façon est un changement intense pour la plupart des équipes. Savoir de ce sera limité dans le temps donne l’espace psychologique nécessaire pour vraiment essayer.
#2. Planifiez des choses plus petites que vous ne le pensez.
En réalité finir quelque chose de significatif en un seul jour est une partie clef de cette expérience. Il vaut mieux finir quelque chose de trop petit et terminer tôt que toujours quitter sur une chose partiellement faite. Et les compétences de découpage que vous développez seront de valeur à votre équipe sur le long terme.
#3. Bien que ce soit une expérience sur comment vous travaillez, faites attention que sur quoi vous travaillez est bien réel.
Vous en avez besoin que le quoi soit représentatif de votre travail normal pour en transférer facilement les enseignements. (Si, pour une certaine raison, vous ne pouvez pas le faire avec votre travail réel, le faire en style hackathon avec une innovation ou un projet caritatif peut aussi vous apprendre quelque chose. Ce mieux que rien, mais ce ne sera pas aussi instructif que 10 sprints d’1 jour de travail réel.)
Zidane Zait, coach Agile et formateur Scrum, enseigne aux équipes l’agilité, l’Agile Framework Scrum et Agile MS Project. Son objectif est de faciliter le développement d’un esprit agile, la réalisation de solutions de valeur, la collaboration, l’auto-gestion des équipes, l’amélioration continue ainsi que l’engagement, la passion et l’enthousiasme envers ces approches.
Dans le guide Scrum 2020, on trouve le rôle de « développeurs » alors que dans les guides précédents on utilise le rôle « d’équipe de développement »
Un peu de Scrum en musique pour terminer ce billet.
Zidane Zait ajoute ces autres changements à prendre en compte
Changement, évolution et améliorations apportées au guide SCRUM 2020:
En plus, des 5 changements et améliorations repris dans cet article, on peut les compléter par ce qui suit :
• Le guide 2020 définit le mot produit, comme un produit physique, un service, ou quelque chose de plus abstrait.
• Le terme « développeur », est un terme générique, et ne concerne pas uniquement le domaine informatique, on peut le remplacer par « réalisateur » en dehors du développement logiciel.
• Suppression des trois questions de la mêlée quotidienne et laisser la liberté aux développeurs d’inspecter la progression vers l’Objectif de Sprint. Les questions supprimées sont :
1. Qu’est-ce que j’ai fait hier ?
2. Qu’est-ce que je vais faire aujourd’hui ?
3. Y a-t-il des problèmes rencontrés ?
• La version 2020 ne parle plus de vision de produit, mais plutôt d’objectif de produit.
• Le Product Owner est redevable de définir et communiquer explicitement l’objectif du produit.
• Les développeurs sont redevables envers la qualité du produit en adhérant à la définition de terminé
• Le Scrum Master est redevable pour être le facilitateur de l’équipe et garantir son efficacité.
• Plusieurs incréments peuvent être créés pendant un sprint au lieu d’un seul dans les versions précédentes.
PMI Luxembourg a ajouté une playlist #agileweek à sa chaine youtube pour votre plus grand plaisir.
Vous pouvez rattraper votre retard ou revoir ces wébinaires et en découvrir d’autres du PMI Luxembourg.
https://hennyportman.wordpress.com/2020/04/01/too-many-rules-makes-agility-impossible/ par Henny Portman
Un des principes du Manifeste Agile est “la Simplicité — l’art de maximiser le travail non fait — est essentielle”. Les études du Standish Group présentées dans l’un de leurs Chaos Report montrent que 60 % des fonctionnalités développées ne sont pas ou rarement utilisés. Si vous livrez seulement les bonnes, votre client obtiendra le produit beaucoup plus rapidement et à bien meilleur marché.
Considérer de manière critique les fonctionnalités du produit que vous développez est une façon de prendre en compte ce principe. Vous pourriez appliquer ce même principe au processus que vous utilisez pour développer votre produit. Combien de règles devez-vous suivre ?
Avez-vous jamais joué au jeu de Go ?Le Go est un jeu de société de stratégie vieux de 2500 ans pour deux joueurs, dans lequel le but est d’entourer plus de territoire que l’adversaire. Malgré ses règles relativement simples, Go est déjà très complexe. Ou pensez au « jeu de la vie » de Conway sur l’automatisation cellulaire. Juste quelques règles très simples et des résultats stupéfiants. Ajouter davantage de règles aboutira au chaos.
Ils faisaient face au problème e que certains parents venaient chercher leur enfant trop tard. Comme solution, ils ont mis en œuvre une nouvelle règle : Si vous venez chercher votre enfant en retard, vous devez payer une amende. Suite à cette règle même encore plus de parents sont venus récupérer leur enfant en retard. Ce qui était un compromis moral (je ne peux pas y aller trop tard) est maintenant devenu une transaction financière : je paie ma dette. Les règles ne sont pas nécessairement sacrées, les principes le sont.
Si vous regardez certaines structures agiles ou façons de travailler, vous pouvez vous demander si les concepteurs vous forcent à adopter une règle ou à la transgresser. Beaucoup sont pensées pour vous aider à construire des équipes d’équipes qui développent un produit ou un service, mais ici aussi, si vous pouvez réussir à ‘simplifier’ votre architecture vers des micro services vous n’aurez pas besoin de ces structures pour « monter en échelle/volume ».
Si vous comparez le nombre de règles de Scrum avec celles de SAFe, vous pourriez vous demander si vous réussissez sortir des agile release trains grâce aux règles SAFe ou malgré elles ?
| Structure agile ou façon de travailler | Règles |
| Manifeste agile | 4 valeurs, 12 principes |
| Scrum | 3 rôles, 5 cérémonies, 3 artefacts, 5 valeurs |
| Nexus | 6 rôles, 5 cérémonies (équipe), 6 événements (Nexus), 7 artefacts, 5 valeurs |
| LeSS | 5 rôles, 5 cérémonies (équipe), 3 événements (équipe d’équipes), 4 artefacts, 28 règles (LeSS), 12 règles (LeSS énorme) |
| AgilePM | 13 rôles, 6 processus, 15 produits, 8 principes |
| PRINCE2 Agile | 9 rôles, 7 processus, 7 thèmes, 7 principes, 5 comportements, 26 produits |
| Disciplined Agile Delivery | 11 rôles, 3 phases, 6 cycles de livraison, 7 principes |
| SAFe | 12 rôles, 6 cérémonies (équipe), 7 événements (programme), 2 cérémonies (grandes solutions), 7 artefacts, 4 valeurs, 10 principes |
Si vous voulez fonder un laboratoire d’innovation ou de croissance, assurez-vous de rester à distance de la bureaucratie. Pour réduire des obstacles, exemptez le laboratoire des règles d’entreprise, des procédures, des manuels, des directives, des principes et des formats. Les approches innovantes peuvent faire sans !
Jim Johnson, rêveur et président du Standish Groupe a partagé dans un interview pour un magazine de Managers de Projet des Pays-Bas : 
“L’analyse des données de projet a apporté des standards, des approches et des structures, bien que j’hésite en réalité sur les standards, parce qu’ils limitent la croissance. Toutes choses bien considérées, le réflexe de construire des structures accroit les chances d’échec d’un projet technologique. Des structures sous forme d’outils de gestion compliqués, trop de règles de gouvernance, des exigences professionnelles trop étroitement définies… Des structures construites avec les meilleures intentions rendent les projets plus lents, plus chers et plus consommateurs de temps. Des structures dans lesquelles personne n’ose prendre la moindre décision.”
Si vous recherchez l’agilité, pensez à une citation de Pablo Picasso “Apprend les règles comme un professionnel afin de pouvoir les briser comme un artiste”.
Ou avec mes propres mots : Utilisez le bon sens en appliquant des approches agiles ou façons de travailler et démontrez une mentalité agile en comprenant juste la logique plutôt qu’en suivant des règles.
https://www.axelos.com/news/blogs/april-2020/four-ways-of-working-for-project-managers-in-agile par Allan Thomson – PPM Ambassadeur de Produit
Une checklist dans PRINCE2 Agile® best practice guidance décrit les points majeurs dont il faut avoir conscience.
Un projet impliquant des méthodes agiles doit être basé sur une collaboration efficace avec une équipe auto-organisée qui résout les problèmes ensemble.
Un manager de projet devrait avoir confiance en l’équipe pour produire sans micro-management. PRINCE2 Agile souligne le besoin de permettre aux gens d’avancer pour produire les bonnes solutions exigées par le projet.
Et cela signifie que le comité de projet doit être clair sur ce que veut dire avoir d’une équipe « autonome » et être content que l’équipe projet fasse des changements si nécessaire. Si un élément de changement est majeur, PRINCE2 recommande de manager par exception (quand une situation dévie au-delà de ce que le comité de projet peut accepter).
Un manager de projet doit communiquer la vision du produit clairement et l’équipe doit croire en la vision pour contribuer et créer un changement de valeur.
Cela peut impliquer le fait de donner la priorité aux exigences de produit majeures en se basant sur une méthode comme MoSCoW (must have, should have, could have, won’t have for now). Puis, communiquer le résultat aux parties prenantes sur ce qu’elles obtiendront, devraient obtenir et n’auront pas.
Cette transparence avec les parties prenantes sur ce que sera le produit viable minimal les rassure sur le fait d’obtenir rapidement de la valeur pour leur investissement.
Si Agile est un nouveau concept dans une organisation, PRINCE2 Agile introduit un « Agilomètre« . Le but de l’Agilometer est de fournir un guide vers agile qui créera un niveau de contrôle et de prévisibilité sans devenir excessivement normatif. Cela inclut l’évaluation de l’environnement et son niveau d’acceptation de méthodes et des comportements agiles.
Et, dans cet environnement, le manager de projet doit comprendre et adopter le rôle de servant leader. Il aide l’équipe à déplacer ou éliminer les points bloquants l’avancée du projet. Pour cela, l’engagement des parties prenantes est crucial.
Si l’équipe projet est novice avec les manières de travailler dites « agiles », introduisez-les à Scrum la méthode la plus utilisée. Puis, soyez clair avec les parties prenantes sur ce processus de développement et les éléments de langage utilisés. Soyez également transparent sur ce qu’ils auront et n’auront pas. Par exemple, montrez-leur la partie du produit qui est prête, mais ne les exposez pas à ce qui n’est pas encore prêt à voir ou démontrer.
Faire suivre cette démonstration client par une rétrospective d’équipe permet à chacun de reconnaître ce qui s’est bien déroulé avec les parties prenantes et ce qui n’a pas été. Cela crée une mentalité d’amélioration continue dans l’équipe.
Prenez contact avec chaque personne impliquée dans le projet chaque jour.
Il est essentiel de savoir si l’équipe est heureuse de la façon dont ses membres travaillent dans un environnement agile et un manager de projet doit y devenir un facilitateur. Vous créez dans l’équipe la confiance que vous savez ce que vous faites !
PRINCE2 Agile est construit sur le concept « d’infléchissement » ou « de priorisation », produire pour créer la valeur maximale en premier. Cela représente un changement significatif dans comment les gens pensent et agissent en travaillant sur un projet. Le comité de projet doit le comprendre pour fournir une direction efficace au projet.
En fin de compte, PRINCE2 Agile complémente la bien établie méthode PRINCE2 mais dans un contexte agile. Ces conseils de bonne pratique prouvent maintenant pour être appropriés et applicables dans de nouveaux pays, avec de nouvelles traductions en allemand, polonais et hollandais.
Elle comprend une explication des cadences, des cérémonies et des processus de Scrum et de SAFe applicables aux équipes, aux programmes, aux grandes solutions et aux portefeuilles de projets.
Pour en savoir plus sur SAFe, consultez le site scaledagileframework.com et la formation SAFe sur scaledagile.com.
https://www.intercom.com/blog/accidentally-invented-job-stories/ par Paul Adams
Chez Intercom, nous réévaluons constamment nos processus pour construire un excellent produit, un produit que les gens trouvent de valeur et utile, un produit qu’ils aiment.
Une chose sur laquelle nous portons une énorme attention est la recherche. Nous embauchons des personnes avec de l’expérience dans la recherche directe et chacun dans l’équipe produit parle directement aux clients. Nous avons aussi embauché un Directeur de Recherche bien plus tôt que la plupart des autres startups : Sian Townsend qui a précédemment mené les équipes de recherche pour Google Maps.
Bien sûr, il est évident que vous devriez parler aux clients fréquemment pour essayer de comprendre leurs besoins, mais quel est le meilleur outil pour y répondre n’est pas évident.
Chez Intercom, nous pensons constamment aux choses à partir des premiers principes et très tôt nous avons appliqué ce focus sur comment nous parlons à nos clients. Nous étions les grands supporters de l’approche Jobs-to-be-Done (JTBD), mais la plupart de ce qu’a été écrit sur JTBD a été appliqué aux milk-shakes et barres chocolatées. Il y avait peu de recherches publiées sur la façon d’appliquer JTBD au développement de logiciel. Alors, nous avons créé notre propre processus basé sur ce que nous savions.
Pendant la majorité de ma carrière j’ai utilisé des personas et des scénarios comme des outils pour comprendre les clients.
Popularisé par Alan Cooper dans The Inmates are Running the Asylum, ils sont depuis devenus l’un des outils le plus largement utilisés dans le panel de recherche et conception de l’équipe.
Cooper a aussi écrit un livre fantastique appelé About Face que je recommande à tous les designers qui rejoignent mon équipe, mais je leur dis de sauter les chapitres sur des personas.
Quand je travaillais chez Google, j’ai créé des douzaines sinon des centaines de personas à travers beaucoup de projets. Nous suivions souvent la soigneusement méthode de Cooper et nous créions aussi souvent des itérations de notre propre fait. Universellement, j’ai constaté que leur valeur était limitée. Ils aidaient souvent à construire de l’empathie entre les employés qui étaient déconnectés de leurs utilisateurs, mais ils menaient rarement à des idées révolutionnaires ou fraîches de réfléchir à un problème.
Nous n’avons jamais utilisé de personas chez Intercom.
La première fois que j’ai vraiment commencé à mettre en doute la valeur des personas était quand j’ai quitté Google et rejoint Facebook. Une des choses saisissantes à propos des données comportementales de Facebook sur leurs utilisateurs était combien le comportement des gens était similaire. Les personas m’avaient amené à croire que les gens sont vraiment différents, avec des objectifs vraiment différents, mais les similarités sont beaucoup plus grandes que les différences et peu importe la démographie que vous pouvez imaginer : la race, l’âge, le genre, etc. Par exemple, les motivations d’une mère mariée avec trois enfants aux États-Unis postant les photos d’un barbecue familial est essentiellement la même que celle d’un adolescent coréen postant les photos de la fête à la maison le soir précédent. Les buts et attributs semblent totalement différents, mais leurs motivations sont les mêmes.
Les personas ne nous mèneraient jamais à un même produit conçu et construit pour ces deux audiences. Alors que les meilleurs personas se concentrent sur les buts (les buts dirigent le comportement des personnes) aussi bien que les attributs, la réalité est que la plupart des personas se concentrent seulement sur les attributs des personas et même des personas dirigés par leurs objectifs ségrèguent artificiellement ces audiences. Les personas limitent artificiellement la cible de votre produit parce qu’ils se concentrent sur des attributs plutôt que des motivations et des résultats. Cette observation a détruit ma foi en eux comme outil.
Concevoir pour les motivations et les résultats est bien meilleur que concevoir pour des attributs. C’est la différence clef entre les personas et JTBD. Les personas regardent des rôles et des attributs, JTBD regarde des situations et des motivations. Les personas expliquent qui sont les gens et ce que font les gens. Mais ils jamais expliquent entièrement pourquoi les gens font quelque chose. Pourquoi les gens font certaines choses est beaucoup plus important.
Ainsi à la mi-2013 chez Intercom, nous nous sommes demandé quel pourrait être un meilleur outil que des personas. Nous parlions à des douzaines de clients chaque semaine et notre équipe de support client parlait à des centaines de plus, recueillant des demandes de fonctionnalités et comprenant les problèmes et les contraintes de notre produit.
Avoir cette relation directe avec nos clients a été inestimable, mais il y avait deux défis que nous avions besoin de surmonter :
Il était donc critique que nous découvrions quel problème nos clients essayaient de résoudre et pourquoi ils avaient besoin de le résoudre.
Et une fois que nous aurions compris le problème, comment pourrions-nous faire de toute cette compréhension quelque chose d’actionnable pour l’équipe de conception ?
Les longs rapports de recherche et les packs de transparents de présentation avec des résultats de recherche sont difficiles à mémoriser et faciles à ignorer. Nous avions besoin de quelque chose de concis, de facile à communiquer et à se souvenir. Je ne peux compter chez Google le nombre de fois où nous faisions participer des gens à la recherche, à co-créer des Personas avec nous, seulement pour ensuite les ignorer parce qu’ils étaient trop difficiles à se souvenir, trop détaillés à analyser.
Se référer aux Personas n’est pas le chemin par défaut, en fait c’est le chemin de moindre résistance. Et souvent parce que les Personas ne sont pas assez concis pour des équipes développement rapide de produit.
En dehors des Personas, un autre outil très populaire est les User Stories, que le mouvement de développement de logiciel Agile avait popularisées. Nous n’avions jamais utilisé de User Stories non plus. Pour commencer, elles ne proviennent pas de recherche empirique et le format est technique plutôt que centré sur le client. Elles sont formatées pour décrire la fonctionnalité à construire, plutôt que les motivations des personnes.
Après avoir réfléchi à ce problème en repartant des premiers principes, nous avons inventé des Histoires de Travail, les Job Stories. Elles ne portaient pas ce nom en ce temps-là (Alan Klement l’a trouvé plus tard pour nous) mais le processus était là et fonctionnait bien pour nous.
Après avoir longuement considéré JTBD, nous avons créé notre propre approche centrée sur les situations, motivations et résultats :
[ Quand _____] [je veux faire _____] [pour pouvoir _____]
‘ Quand ____ ’ se concentre sur la situation, ‘ je veux faire ____ ’ se concentre sur la motivation et ‘ pour pouvoir ____ ’ se concentre sur le résultat. Si nous avons compris la situation dans laquelle les gens rencontrent un problème à résoudre, comprendre la motivation pour le résoudre et comprendre à quoi ressemble un bon résultat, nous sommes confiants que nous construirons un produit de valeur pour nos clients.
Les Histoires de Travail sont maintenant un outil clef pour nous. Elles garantissent que l’équipe est en mode recherche, que les membres de l’équipe comprennent si bien le problème qu’ils peuvent le capturer en un format concis. Et que leur résumé du problème peut être mis en action par toute l’équipe de conception et technique.
Avant que nous ne commencions un quelconque projet chez Intercom, nous créons un résumé d’une page pour le projet. C’est très simple et doit tenir sur une page d’A4 (qui est alors imprimée et collée sur les murs du bureau pour que les différentes équipes aient la visibilité du travail entrepris dans la société). Il a une section sur ses Histoires de Travail. Ces Histoires de Travail sont ce qui assure que nous comprenons le problème ou l’opportunité que nous abordons et elles nous tiennent focalisés sur celles-ci partout dans le projet.
Les personas y ont leur place. Dans des environnements politiques où les gens disent seulement ce que l’on veut entendre sur les besoins réels des clients, je les ai trouvés utiles pour gagner en acceptation; ils peuvent conduire un rapport plus fort avec les réels utilisateurs d’un produit.
https://www.scaledagileframework.com/blog/whats-new-in-safe-5-safe-for-hardware-development/ par Harry Koehnemann
Beaucoup d’entre nous travaillent dans les organisations qui essayent d’améliorer la livraison de produit dans des solutions qui comprennent du matériel. Pendant que SAFe offre aux développeurs de logiciels une myriade de bonnes pratiques pour accélérer l’exécution, nous n’avons eu que peu à dire aux développeurs de matériels. Jusqu’à présent.
Aujourd’hui, la communauté des producteurs de matériel est dans la même position que la communauté du logiciel l’était il y a deux décennies quand ils ont connu une demande business en augmentation pour des livraisons plus rapides et de qualité très élevée. La communauté du logiciel a inventé de nouvelles pratiques comme les méthodes Agiles et l’intégration continue, qui a mené à des innovations technologiques comme des micro-services, les plateformes et l’infrastructure « as-a-service » et le management d’interfaces pour les soutenir.
Aujourd’hui, le business exige la livraison toujours plus rapide de matériel de haute qualité et de systèmes et sous-systèmes mécaniques. La pression est maintenant sur le développement de matériel pour découvrir que de nouvelles pratiques LEAN et Agile favorisent une livraison plus rapide de solutions.
Nous voyons maintenant que des pratiques Agiles commencent à émerger dans l’industrie du matériel. Les organisations utilisent avec succès des jumeaux numériques, l’impression 3D, le Circuit Imprimé (PCB) en un jour, les Développements Pilotés par les Tests dans la conception CAO, l’intégration continue et d’autres pratiques et technologies qui accélèrent la livraison de produit et en améliorent la qualité.
La dernière mise à jour de SAFe 5 inclut de nouveaux conseils pour ceux qui font face à ces défis particuliers.L’article Applying SAFe to Hardware Development décrit 6 principes critiques pour aider les ingénieurs de matériels à mieux comprendre comment le développement LEAN-Agile s’applique à leur contexte.
Ces principes seront immédiatement reconnaissables pour ceux qui sont familiers de SAFeIl est grand temps que LEAN et Agile traverse le fossé pour aider le matériel et les constructeurs de systèmes cyber-physiques à répondre aux demandes de l’ère digitale. Vous pouvez lire l’article complet en anglais ici.
© Scaled Agile, Inc.
Ce SIG s’articule autour d’un espace Slack où les participants (une quarantaine à ce jour, tous membres du Chapitre PMI France) peuvent échanger librement à propos de l’agilité, et en particulier de Disciplined Agile.
La première initiative est le Cercle d’étude sur «Choose your WoW !» sur lequel une douzaine de participants ont rejoint Jean-Yves et Géry.
Ils ont proposé une relecture et une analyse du livre de référence Disciplined Agile « Choose your Wow ! », téléchargeable gratuitement sur le site du PMI (pour les adhérents).
Ces explications ont été riches de sens, et une prochaine session devrait démarrer prochainement… éventuellement dès le mois d’avril.
Des initiatives devraient voir le jour dans les prochains mois.
Alors, bientôt un « Disciplined Agile de Poche »… en français ?
Si vous souhaitez rejoindre le « Disciplined Agile Special Interest Group » (et éventuellement participer au prochain Cercle d’étude):
Vous pouvez vous inscrire en répondant au Questionnaire d’inscription au SIG Disciplined Agile PMI-France,Êtes-vous curieux ?
Jean Yves Klein et Gery Schneider : France Chapter Champions DA
Alors que les organisations réinventent l’avenir post-pandémique, elles et leurs managers de projet doivent adopter de nouvelles façons de travailler. Pourtant, toutes les organisations n’avancent pas de la même manière ni à la même vitesse.
Au cœur de ces changements massifs, la recherche Pulse of the Profession® révèle l’émergence de ce que PMI appelle les entreprises gymnastiques (ndltr j’aurais dit gymnastes) c’est-à-dire celles qui ont appris à être flexibles et à pivoter, où et quand il le faut, tout en maintenant la structure, la forme et la gouvernance. Les entreprises gymnastiques choisissent les meilleures façons de travailler à partir d’un panel de possibilités et se concentrent sur leurs employés, sachant que la performance organisationnelle est une belle chorégraphie de performances individuelles.
Qu’est-ce qui les distingue ?Comparativement aux entreprises traditionnelles, les entreprises gymnastiques sont plus susceptibles d’avoir un haut niveau d’agilité organisationnelle (48% contre 27%) et sont plus susceptibles d’utiliser fréquemment des pratiques standardisées de management du risque (68% contre 64%). Ces deux caractéristiques étaient des facteurs importants de réussite dans les projets pour l’ensemble de la base de répondants à l’enquête.
Les entreprises gymnastiques ouvrent de nouvelles voies en permettant à leurs employés de maîtriser de nouvelles façons de travailler, en mettant l’accent sur l’élément humain et en comprenant le rôle pivot que joue la culture organisationnelle pour mettre en œuvre toutes ces capacités.
Les retombées sont considérables.Les entreprises gymnastiques sont à l’avant-garde dans The Project Economy, qui met l’accent sur la valeur financière et l’impact social positif, quelque soit ce que cela nécessite.
Le nouvel écosystème du travail (Introduction)
S’adapter et avancer (Conclusion)
“PMI”, “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.
Soyez réaliste dans votre choix d’utiliser une approche Agile (ou pas) !
http://www.bonniebiafore.com/realistic-agile-selection/ par Bonnie Biafore
Avoir les bons membres techniques et business dédiés au projet est crucial. Agile produit rapidement des résultats avec une grande intensité pour ses participants. Agile exige les personnes business et techniques les plus critiques, celles qui sont essentielles à opérer votre business. Donc il est important de donner la priorité au temps qu’ils peuvent contribuer au projet. Accepter des compromis difficiles entre le travail de projet et les considérations opérationnelles est la clé.
La connaissance en profondeur des secteurs business et techniques impactés par le projet est cruciale. Les experts métier travaillant étroitement avec les experts techniques de l’équipe sont au cœur de l’approche agile. La caractéristique première qui rend les méthodologies Agile agiles est la responsivité de la méthode à des besoins qui évoluent. Des personnes techniques et business bien informés doivent constamment réévaluer les livrables du projet et les besoins du business à un niveau macro et micro et prioriser les fonctionnalités nécessaires au client final. Sans connaissance et disponibilité pour réaliser ces évaluations, la base même des méthodes agiles s’effrite.
Le sponsor doit désirer participer aux fréquentes revues du produit en développement, qui sont fondamentales dans l’approche agile. D’autre part, un sponsor qui veut un ensemble linéaire, méthodique, planifiés d’objectifs livrés sur un échéancier préétabli aura du mal avec les livrables Agile. La bonne capacité de réaction de l’approche Agile aux changements de conditions du business et environnement d’apprentissage diffèrent beaucoup des méthodes traditionnelles de management de projet. Les sponsors qui résistent à la nature évolutionnaire de l’agilité créent des difficultés qui peuvent faire couler le projet.
Agile implique un dialogue profond, interactif et parfois difficile, qui produit de meilleurs résultats. Accroitre ce dialogue exige l’environnement le plus riche que vous puissiez créer. Co-localisez les membres de l’équipe projet si possible. Si vous ne le pouvez pas, simulez cette co-localisation avec les meilleurs outils vidéo et audio que vous pouvez trouver. Essayer de faciliter un dialogue agile avec des outils de communication sous performants ressemble à essayer de remorquer une grosse caravane avec une tondeuse à moteur. Cela n’a tout simplement aucun sens.
Les méthodologies agiles exigent de dédier des experts métiers et techniques ouverts à essayer de nouvelles idées et à se supporter les uns les autres. Vous avez besoin d’un coach agile qui comprenne et puisse gérer la dynamique humaine et favoriser un environnement où les membres d’équipe partagent aisément leurs idées et soucis. Une équipe agile doit s’entendre bien pour réussir.
Les meilleures qualités d’Agile viennent de livrer des solutions par petits livrables en apprenant de chaque itération. En plus des produits logiciels, d’autres produits peuvent être construits de cette façon. Avec un peu de créativité, déménagements, mises en œuvre de nouveaux processus et même certains projets de construction peuvent utiliser des méthodes agiles. Si vous pensez à une façon dont votre produit final peut être construit en étapes itératives, le projet peut être un bon candidat pour une approche Agile.
« Un coach agile aide les organisations, les équipes et les individus à adopter des pratiques et des méthodes agiles tout en intégrant des valeurs et des mentalités agiles. L’objectif d’un coach agile est de rendre les équipes plus efficaces, transparentes et cohésives, et de permettre de meilleurs résultats, solutions et produits/services pour les clients. Les coachs Agile ne sont plus seulement responsables d’aider les équipes technologiques, ils aident également l’entreprise à adopter l’agilité comme un changement de culture. Un coach agile ne préconise pas une méthode particulière par rapport à d’autres, mais donne plutôt aux gens les moyens de travailler plus intelligemment, plus rapidement et avec moins de risques. »
Ce rapport permet de mieux comprendre d’où ils et elles viennent, quels niveaux d’étude, quelles expériences, quels types de jobs et de contrats de travail, quelles réputations elles et ils se sont forgés…
Et vous y lirez également quels services sont fournis par les coach Agiles, comment leurs performances sont évaluées, en bref qu’en espérer et pour quels impacts ?
https://watirmelon.blog/2019/10/14/now-next-later-never-improving-moscow/ par Alister Scott
Notre équipe se donne des objectifs trimestriels, que nous décomposons en exigences dans des sprints bimensuels. En tant que paradev (un paradev iest quiconque dans une équipe de développement ne fait pas que programmer) dans mon équipe, je travaille étroitement avec notre Product Owner pour écrire et déterminer la priorité de ces exigences.
Nous avons à l’origine commencé par utiliser la méthode de MoSCoW pour déterminer la priorité de nos exigences : Le terme MoSCoW est un acronyme tiré de la première lettre de chacune de 4 catégories de priorisation : Must have, Should have, Could have, et Won’t have.
Nous avons rapidement commencé à remarquer que la terminologie (Must have, Should have, Could have, et Won’t have) ne marchait pas idéalement dans notre contexte et nous pensions que cela causait beaucoup de frictions sur comment nous donnions la priorité et la communiquions à l’équipe. Il ne semblait pas naturel de classifier des choses comme, Must, Should, Could, Won’t car non corrélées à ce sur quoi nous devrions (Should) travailler.
En quelques sessions nous avons inventé nos propres groupements pour nos exigences en nous basant sur quand nous voudrions les voir dans notre produit : Maintenant, Ensuite, Plus tard, Jamais. Nous avons continué à utiliser ces quatre termes et nous avons constaté qu’ils ont été très bien adoptés par l’équipe car il est très naturel pour nous de penser avec ces groupements.
Le plus grand avantage à utiliser Maintenant, Ensuite, Plus tard, et Jamais, est qu’ils se transfèrent naturellement dans notre plan de produit et dans la planification de sprint.
J’ai fait quelques recherches en écrivant ce billet et j’ai trouvé Maintenant, Ensuite, Plus tard comme une approche de ThoughtWorks datant de 2012, mais je n’ai pas trouvé de lien qui contienne Jamais que nous avons trouvé très utile pour lister ce que nous reconnaissons que nous ne ferons pas.
| Bien plus qu’un outil de gestion de projet | |
| Découvrir l’ERP de gestion de projet | |
Il est maintenant disponible sous license Creative Commons Attribution-ShareAlike 4.0 International License. Vous pouvez imprimer les cartes vous-même, les adapter et les utiliser dans tout travail.
https://gojko.net/2019/10/15/50-qi-cards.html par Gojko Adzic
Nous mettons notre notre célèbre jeu de carte en libre impression, sous « creative commons ». Un excellent rappel de toutes les astuces du livre Fifty Quick Ideas To Improve Your User Stories
Et pour un peu de fun en ces temps si compliqués, je vous conseille cette petite chanson sur Scrum qui vous rappellera peut-être des souvenirs…
Le refrain en français donne à peu près ceci:
Hé, Scrum Master, je sais que nous sommes un désastre
Chaque sprint que nous sprintons et incréments que nous créons ne sont pas transparents
Hé, Scrum Master, je ne veux pas manquer une seule cérémonie Scrum de ce Sprint
Inspecter, inspecter et adapter, inspecter et adapter
Inspecter, inspecter et adapter, inspecter et adapter
Le nouveau Scrum Guide : Sa page de téléchargement GRATUIT dans la langue de votre choix
Bruno Margueritat avec un résumé et une analyse personnelle de cette nouvelle version du guide : http://brunomargueritat.com/2020/11/18/scrum-guide-2020/
Claude Aubry exprime son premier ressenti à la lecture de la version française (qui a été depuis améliorée) et son analyse critique des différences et des apports de cette nouvelle mouture :
Pablo Pernot nous provoque un peu et nous force à prendre du recul avec son billet au titre choc: Difficile fin de carrière pour Scrum
Documents, webcasts, articles de blog, vidéos plus succinctes et/ou plus pointues
https://apmg-international.com/article/agilepmr-passes-150000-exams-milestone
Ces dernières années et particulièrement depuis le lancement du manifeste Agile en 1994, un nombre incroyable et toujours croissant d’organisations et de professionnels des projets se sont tournés vers les approches Agiles dans l’objectif d’améliorer l’exécution et le retour sur investissement de leurs projets et autres initiatives de changement.
C’est une tendance qui ne se dément pas. Le dernier rapport ‘Pulse of the Profession’ du Project Management Institute indique que 53 % d’organisations placent une forte priorité sur la mise en place d’une culture réceptive aux changements.
Depuis son introduction en 2010, AgilePM s’est vite établie comme une certification majeure pour le management de projet agile.
Développée et publiée par le Agile Business Consortium, la guidance AgilePM offre une méthodologie pratique et répétable qui trouve un équilibre idéal entre les standards, la rigueur et la visibilité exigée pour la bonne gestion de projet et les rapides changements et l’auto-organisation Agile. Il offre une structure Agile structurée et évolutive dans l’entreprise basée sur une pratique prouvée.
AgilePM est essentiellement un sous-ensemble pour un manager de projet du framework Agile du Agile Business Consortium. La structure, établie au fil des 20 dernières années et régulièrement revue, combine la direction et la rigueur à l’agilité et la flexibilité actuellement exigées par les organisations.
AgilePM offre une approche Agile mature qui, tout en offrant agilité et flexibilité, conserve les concepts d’une livraison de projet et d’un management de projet. AgilePM va au-delà des approches de développement de produit Agiles comme Scrum.
Un des principes sous-jacents d’ AgilePM est de ne jamais compromettre la qualité. Dans AgilePM, les critères d’acceptation de projet, de haut niveau sont agréés aux diverses étapes du cycle de vie du projet, des exigences initiales à l’étape de faisabilité, des objectifs de chaque étape de développement à la livraison du produit/solution.
AgilePM fournit des idées pratiques pour manager le risque, adressant directement beaucoup de risques associés aux projets. Le Questionnaire d’Approche de Projet fournit un point de départ efficace pour créer une compréhension claire et partagée des risques de projet et de leur réduction.
Des personnes travaillant efficacement ensemble sont la base de tout projet réussi. AgilePM le reconnaît et assigne des rôles et des responsabilités clairs à chaque personne dans un projet, représentant le business/métier, la solution/technique, le management et les processus.
AgilePM incorpore et encourage une gamme de pratiques agiles populaires pour soutenir un développement de solution efficace y compris la Priorisation Moscow, le Timeboxing et le Développement Itératif.
AgilePM est une approche vraiment globale avec une certification. Les candidats de plus de 80 pays se sont embarqués pour un voyage vers la certification AgilePM. Ils représentent un large panel d’organisations, d’industries et de secteurs, de petites structures de conseil à de grandes multinationales.
L’analyse des candidats démontre l’attrait d’AgilePM dans des industries diverses.
Information et communication (15 %)
AgilePM Handbook est maintenant disponible en quatre langues (anglais, français, allemand et polonais), avec des examens disponibles dans sept langues (anglais, français, allemand, polonais, chinois, hollandais et italien).
Les formations accréditées pour AgilePM sont délivrées par le réseau global d’organisations de formation accréditées (ATOs) de APMG. cliquez ici pour en savoir davantage.
Le pourquoi, la raison d’être, les principes et l’état d’esprit Disciplined Agile y sont exposés.
N’y manquez pas les retours d’expérience, les rôles et responsabilités, les certifications, les formations et les riches cas d’usage.
ses Case Studies,“PMI,” the PMI logo and “Project Management Institute” are registered marks of Project Management Institute, Inc.
DantotsuPM.com 