Agile est né en 2001 en réaction aux méthodes en cascade de gestion de projet. Le mode de gestion basé sur les seules planifications et spécifications affichait ses limites, les approches Agiles apportent donc de nouvelles réponses. Aujourd’hui, Agile est devenu populaire et de nombreuses organisations s’intéressent à son utilisation comme approche standard pour la gestion de projet. Elles ont besoin d’une force durable telle qu’Agile Project Management. Cela constitue un vrai défi puisqu’ Agile se posait comme un contre modèle aux méthodes business établies.
Le programme Agile de 2001 exprimait des préférences pour :
LCG
LCD
Personnes et Interactions
Plutôt que
Outils et Processus
Logiciel qui fonctionne
Plutôt que
Documentation Exhaustive
Collaboration avec le client
Plutôt que
Négociation Contractuelle
Réactif aux changements
Plutôt que
Suivre un Plan
Partenaire de DantotsuPM
Appelons donc ces préférences le LCG (la colonne gauche) et LCD (la colonne droite). Agile préfère le LCG au LCD.
Ces 10 dernières années, les préférences (LCG) ontpermis à Agile de se développer sous diverses formes. De nombreuses équipes business ont adhéré avec enthousiasme aux versions légères d’Agile (comme SCRUM ou XP) fondées sur les préférences LCG.
Mais d’autres équipes business ressentent toujours un besoin fort ou une forte affinité pour le LCD (la colonne de droite)
·Les Processus et les Outils – les entreprises ont besoin de méthodes de travail bien définies, soutenues par des outils ;
·Une Documentation Complète – les équipes opérationnelles ont besoin de comprendre les livrables du projet ;
·Négociation de Contrat – l’approche « prix fixe, délai fixe » reste un concept business fondamental ;
·Suivre un Plan – les entreprises utilisent les plans pour gérer les dépendances de ressources comme de livraison.
Comment réconcilier le LCG et le LCD ? Une variante d’Agile, l’approche Atern du consortium DSDM réduit cet écart.
Comment Atern peut-il réduire l’écart tout en restant Agile?
Premièrement, Atern reste fidèle au programme en exécutant le LCD, les préférences fondamentales du Programme.
LCG
Solution Atern
Personnes et Interactions
Equipe autogérée
Logiciel qui fonctionne
Livraison progressive
Collaboration avec le Client
Voix forte du client dans les équipes
Répondre au Changement
Approche itérative avec une prise de décision tardive
Atern se compose de 9 principes fondamentaux qui servent eux aussi à réduire l’écart entre le LCG et le LCD.
Voici le diagramme du Modèle Scrum
De plus, 4 des principes d’Atern sont liés au programme (au LCG) :
1. Collaborer,
2. Construire progressivement,
3. Développer de manière itérative,
4. Communiquer continuellement et clairement.
Alors que les 5 autres principes d’Atern sont liés aux besoins de l’Entreprise (au LCD) :
1. Focalisation sur les besoins business,
2. Livrer dans les délais,
3. Ne jamais compromettre la qualité,
4. Construire des fondations solides,
5. Faire preuve de contrôle.
Pour créer une variante durable et forte d’Agile, Atern se fixe alors sur les impératifs du business – dans les délais et les contraintes de budget :
·Une solution avec une architecture (Atern appelle ceci EDUF = Enough Design Up Front (suffisamment de conception en aval) ;
·la Rentabilité ;
·Suffisamment de planning pour assurer le contrôle ;
·Une remise planifiée aux opérations.
Tout cela est basé sur les 9 principes, qui traitent donc du double besoin du LCG et du LCD.
Enfin, le paquet est emballé pour une utilisation générique :
·Atern est une approche générale (pas spécifique à l’informatique ou aux projets logiciel) ;
·La documentation d’Atern consiste en un manuel publiée (disponible sur Amazon, etc) ;
·la formation Atern est disponible internationalement, par des organismes de formation confirmés comme QRP International ;
·la certification d’Atern est assurée par les agences de certification confirmées comme l’APMG.
Donc dix ans après le programme Agile, Atern est ouvert aux entreprises. Il n’abandonne pas Agile, il épouse toujours l’essence du programme. Il s’est adapté aux besoins du business sans retourner aux méthodes en cascade. Atern est la véritable force durable d’Agile.
The Agile Project Management (AgilePM) certification aims to address the needs of those working in a project-focused environment who want to be Agile.
Based on the proven fundamentals within DSDM Atern, the certification provides the ability to deliver Agile Projects in organizations requiring standards, rigour and visibility around Project Management, while at the same time enabling the fast pace, change and empowerment provided by Agile. Agile Project Management Training Courses – To book an Agile Project Management course and exam, contact any of APMG-International’s Accredited Training Organizations.
Partenaire de DantotsuPM
The course will:
Explain how to lay the foundations for successful agile projects
Explain how an agile project is managed
Clarify the different management styles needed for successful agile projects (compared to « traditional » projects)
Provide integration with PRINCE2®
Benefits for Individuals
Develop a more advanced, applied level of knowledge to gain an understanding of agile and the ability to apply relevant project management methods, leading to successful agile projects.
Clarify different management styles needed for successful agile projects compared to traditional projects and be able to tailor these to the situation.
Actively promote trust and close co-operation between the business and developers and gives the business ongoing visibility into what is happening.
Combine knowledge of more traditional management methodologies with agile to better adapt to a changing business environment.
Improve time-to-market and project success rates while simultaneously accelerating results by encouraging stakeholder involvement, feedback and effective controls.
Benefits for Organizations
Deliver change faster, at a lower cost and with lower risk by continually validating project milestones against business objectives.
Complements and works with existing corporate processes such as PRINCE2®, quality and audit processes which improves rigour and visibility around project management, leading to a proven track record of successful delivery in a corporate environment.
Simply adopt a tried and tested approach rather than developing and integrating a company-specific agile management process.
Achieve better communication and control over projects and adapt project plans without disrupting the project budget, timescale and scope.
Develop professionalism in employees and include agile certification in employee professional development schemes.
Foundation Level
Partenaire de DantotsuPM
The foundation AgilePM certification lives up to its name by providing the users of the method with the core principles needed to facilitate a successful project, while allowing a degree of scope and agility that not many other methodologies provide. With a clear, concise and detailed perspective on project productivity, the AgilePM certification is useful to all candidates and competency levels ranging from highly experienced project managers to those new to the industry.
Exam Format: Multiple choice, 60 questions per paper, 30 marks required to pass, 60 minutes,Closed-book.
Practitioner Level
The practitioner level empowers, encourages and equips you with an in-depth knowledge of not just the certification, but also how to apply and implement these principles into the life of a project manager on a daily basis. Pre-requisites accepted to be eligible to take the Practitioner examination:
AgilePM Foundation Certificate, or
DSDM Atern Foundation Certificate, or
DSDM Advanced Practitioner Certificate.
The practitioner examination is in the « Objective Testing » format of scenario, question and answer booklet.
Exam Format: Objective-testing, 4 questions per paper, 15 marks available per question, 30 marks required to pass, Two hours, Open-book (restricted to the manual only) examination.
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.
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
Christine RIEU, christine.rieu@univ-savoie.fr Maître de Conférences en Informatique, Laboratoire LISTIC, Université de Savoie, Annecy, Membre fondateurs du PMI Pôle des Pays de Savoie,
Marc BURLEREAUX, marc.burlereaux@pmi-fr.org, Release Manager Européen auprès d’une banque suisse, certifications PMP, PMI-RMP, PgMP, ITIL V3, Membre fondateurs du PMI Pôle des Pays de Savoie,
L’approche Agile dans les projets de développement de nouveaux produits permet d’assurer plus de souplesse dans la conception itérative, plus de légèreté dans la documentation et dans la formalisation, plus d’interactivité et d’efficacité dans la conduite de réunions, et surtout plus d’implication du client tout au long du projet (Pichler, 2010). Si on couple une approche Lean à ces méthodes Agiles, nous supprimons en plus toutes les étapes inutiles sans valeur ajoutée pour limiter les gaspillages et maximiser ainsi la valeur attendue du produit (Larman & Vodde, 2010). Cela semble donc être la panacée !
Mais ce n’est pas simple à réaliser et le chef de projet se posera de nombreuses questions :
Comment intégrer ces approches de manière réussie dans des contextes de gestion de projet mature qui sont plus traditionnels avec du développement logiciel en V ou en cascade ?
Comment est orchestrée la livraison en production de ces produits développés avec agilité et approche Lean dans un processus de gestion des livraisons pour la mise en production qui lui apparaît souvent très rigide, et qui se doit de minimiser les risques liés au changement ?
Comment ces livraisons s’intègrent-elles dans la gestion des versions (release management), et notamment les procédures de tests (unitaire, intégration et réception des applications), la production de la documentation technique d’exploitation, de la documentation destinée aux utilisateurs et enfin la création des procédures d’installation et de déploiement ?
Comment éviter que ces méthodes soient un alibi à des comportements laxistes et inefficaces, par exemple en supprimant toute documentation?
La réussite de tels projets passe par un compromis d’usage entre l’agilité de l’approche globale de développement et la rigueur à conserver dans le processus de livraison. D’où le titre de notre communication: « une main de fer dans un gant de velours ».
Cette présentation s’appuie sur un retour d’expériences de projets combinant Agilité et Lean Management dans des domaines variés de l’industrie et de l’informatique bancaire. Nous expliquons notre vision des prérequis pour qu’un projet soit éligible aux méthodes Agiles. Le fil rouge de la présentation est ensuite d’illustrer nos expériences en mettant l’accent sur les meilleures pratiques Agile que nous avons identifiées comme point clés pour la pleine réussite de ces projets. Nous avons réparti ces points clés à travers les différentes phases de développement de projet, en insistant particulièrement sur les phases initiales de cadrage et d’élaboration, puis sur les phases finales de réception – homologation et transition vers la production.
L’anecdote suivante illustre bien que la rigidité n’est pas l’apanage des méthodes de gestion de projet traditionnelles
Jack Duggal, ayant une expérience de plus de 30 ans en gestion de projets, disait lors d’une conférence organisée par l’institution PMI (Project Management Institute), à Genève en 2012: « On peut parfois reprocher une certaine rigidité dans l’application de l’agilité. Lors d’un SCRUM meeting, qui suppose que vous soyez debout, notamment pour garantir une durée de réunion courte, une personne un peu fatiguée avait exprimé le besoin de s’asseoir: cela lui a été refusé, principe oblige. »
Quelle que soit la méthodologie choisie, elle doit pouvoir s’inspirer des avantages des autres méthodes existantes.
Citons l’exemple de l’institut PMI qui est l’autorité en matière de gestion de projets « traditionnelle » ; cet organisme s’est naturellement ouvert aux principes d’Agilité en créant récemment une nouvelle certification PMI-ACP (Agile Certification Practitioner) et en intégrant l’Agilité et le Lean Management dans la gestion de projet plus traditionnelle. Par exemple, le PMBOK 5ème édition qui est encore en cours de rédaction prend en compte les méthodes Agiles “Adaptive Life Cycles”, section 2.4.2.4: méthodes itératives et incrémentales avec des itérations courtes de 2 à 4 semaines et avec un temps et des ressources fixes.
Un aspect important à ajouter dans les méthodologies Agile est la gestion du risque: c’est un exemple de bonnes pratiques dérivant des méthodes traditionnelles qui doit être intégrée dans les approches agiles.
Nous terminons sur un rappel des quatre principes fondateurs du Manifeste pour le développement Agile de logiciels rédigé par Kent Beck et 16 autres signataires qui peuvent être suivis quelle que soit la méthodologie de management de projet employée.
« Ces expériences nous ont amenés à valoriser:
1. Les individus et leurs interactions plus que les processus et les outils,
2. Des logiciels opérationnels plus qu’une documentation exhaustive,
3. La collaboration avec les clients plus que la négociation contractuelle,
4. L’adaptation au changement plus que le suivi d’un plan.
Nous reconnaissons la valeur des seconds éléments mais privilégions les premiers ».
La démarche Agile doit être envisagée plutôt comme une véritable philosophie de développement
Nous avons voulu dans cette présentation donner des conseils très pratiques pour dérouler les étapes d’un projet de façon Agile, en nous inspirant de nos expériences sur des contextes projets très variés. Mais nous insistons sur l’importance de comprendre qu’une démarche, quelle qu’elle soit, n’est pas la panacée, si on se contente de l’utiliser comme une « boîte à outils avec check-list intégrée ». La démarche Agile doit être envisagée plutôt comme une véritable philosophie de développement, qui mise sur l’engagement des employés et leur participation. Il faut savoir prendre dans chaque méthode ce qui est « bon pour l’entreprise », sachant que chaque entreprise est unique et a ses propres spécificités de fonctionnement qui en font sa richesse. Face aux méthodes traditionnelles, les méthodes Agiles sont une révolution, mais elles peuvent aussi apporter leur part de lourdeur et de contrainte, selon l’usage que l’on en fait.
L’Agilité c’est bien mais la contrôler c’est mieux …
– L’approche SCRUM n’est pas la panacée, notamment si elle n’est pas accompagnée par le Management et la Maîtrise d’Ouvrage (MOA)
– L’approche Lean de l’industrie ne peut être transposée dans tous les contextes
– L’esprit AGILE est avant tout le moteur qui garantira le succès, du Senior Management aux gens de terrain
– Il faut bien sélectionner les outils AGILES convenant le mieux à l’entreprise
– Un coaching pragmatique est un facteur clé de réussite
– Le dogmatisme doit être jeté aux oubliettes
– Et il faut contextualiser la démarche qui ne peut être standard pour tous les domaines (de l’industrie spatiale à Google, en passant par l’aéronautique, l’industrie automobile, le secteur bancaire…).
Et l’Agilité mal comprise et mal appliquée pourra causer encore plus de dommage que les méthodes traditionnelles.
Soyons WAGILE ! Contraction de WATERFALL (méthodes de développement traditionnelles) et AGILE … d’où Agilité une main de fer dans un gant de velours !
En bonus une petite vidéo « Agile: An Introduction »
partagez ce billet avec vos amis, collègues et relations professionnelles
Équipes Agiles Distribuées : Réalisation des bénéfices, de ProjectsAtWork, recherches écrites et réalisées par Elizabeth!
J’ai travaillé avec ProjectsAtWork cette année sur des recherches et une analyse des bonnes pratiques pour réussir Agile avec des équipes distribuées. Agile n’est pas la première approche à laquelle vous penseriez pour manager un projet avec des membres de l’équipe géographiquement distribués dans le monde entier, mais en réalité c’est une approche vraiment courante.
Pourquoi utilisez-vous Agile avec une équipe distribuée ?
Les gens utilisent Agile avec des équipes distribuées parce que cela revient moins cher. Cela donne aux équipes projet plus de flexibilité. Cela augmente la productivité. La recherche a regardé un certain nombre de bénéfices, en voici les 3 premiers.
Utiliser des ressources offshores est souvent avancé comme l’une des raisons pourquoi lesquelles les équipes distribuées rendent les projets plus flexibles. Mais certaines personnes questionnées ont dit qu’avoir des équipes distribuées signifie qu’elles pourraient choisir la meilleure personne pour le travail, pas seulement celle qui travaille dans le même bâtiment. Cela donne aux chefs de projet une chance de choisir depuis un plus grand réservoir de ressources et ainsi en augmenter la qualité.
L’inconvénient d’avoir des gens partout est que les équipes souffrent souvent des décalages horaires. Presque 25 % des personnes mentionnent des différences de temps de plus de 9 heures. Pas étonnant que la grande majorité d’entre eux dise que travailler avec une équipe distribuée est plus difficile que le travail avec une équipe co-localisée.
Comment faites-vous du travail Agile avec une équipe distribuée ?
Il y a des tas de trucs dans le rapport, mais voici 5 de mes favoris.
Ne supposez pas que ce qui a marché sur un projet fonctionnera sur un autre. Adaptez votre environnement Agile pour convenir à chaque équipe. Encore mieux, laissez l’équipe l’adapter.
Utilisez les mêmes outils que vos partenaires si vous « offshorez » ou externalisez un travail.
N’externalisez pas des disciplines individuelles. Gardez une équipe multifonctionnelle dans tous les endroits.
Faites un « daily stand up » quotidien en utilisant la conférence à plusieurs sur le Web.
Communiquez plus que vous ne le pensez nécessaire, particulièrement pour vous assurer que les gens comprennent l’objectif, la finalité. Ceci est aussi important si vous avez de multiples langues dans votre l’équipe. Passez du temps à vous assurer que les gens comprennent ce qui a été discuté.
À quoi ressemble un professionnel Agile?
Une des choses que j’ai faites dans cette recherche est de rassembler le profil d’un professionnel Agiliste expérimenté, basé sur l’enquête auprès d’environ 340 personnes.
Un Professionnel Expérimenté Agile:
Est âgé de 35 à 44 ans
Est un homme
Utilise Scrum
A travaillé sur plus de 10 projets, mais la plupart d’entre eux n’ont pas été avec des équipes distribuées
Travaille dans l’informatique
Travaille dans les plus grandes comme les plus petites sociétés
Se considère comme un praticien Agile, mais n’a pas de qualification reconnue
Croit que le plus grand défi pour des équipes distribuées est la faiblesse de communication
Travaille dans une société où moins de 20 % des chefs de projet sont des chefs de projet Agiles.
Je pensais que plus de répondants seraient des femmes, mais il ne semble pas y avoir beaucoup de professionnels expérimentés Agiles qui soient des femmes. Sauriez-vous pourquoi ?
La méthodologie « waterfall » a été présente depuis si longtemps que les organisations de développement logiciel qui la pratiquent – et leurs clients – sont complètement en accord avec le processus. Récemment notre gourou résidant Agile l’a indiqué en commentant qu’avec Agile, clients ou propriétaires de produit (« product owners ») ne peuvent pas décharger leurs pensées sur l’engineering. Autrement dit, ils ne peuvent pas donner à l’ingénierie d’un seul coup tous leurs besoins au démarrage, parce que Agile demande une constante collaboration dans laquelle les besoins sont alignés à la fois sur l’équipe et sur le business.
Cela m’a sonné à réfléchir : Intérieurement, dans une organisation de développement de produits qui utilise Agile, coûte que coûte les propriétaires de produit doivent s’aligner. Ils apprendront le concept d’arriéré de produit et de besoins qui s’empilent; ils accepteront les tâches que les experts Agile attendent d’eux. Cependant, dans une organisation pilotée par les projet où les clients sont les gardiens du besoin, est-ce que ces clients sont prêts pour Agile ?
Je me rappelle de plusieurs occasions pendant mes missions de conseil où trois à quatre mois ont été dédiés « à la découverte » des processus clients, l’esquisse des besoins, l’obtention de la signature d’un document de contenu de projet. Le tout avant que nous ne puissions commencer le projet. Les calculs d’allocation de ressources et d’échéanciers, étaient basés sur ces « besoins ». C’est que la communauté informatique communauté a appris à ses clients sur quoi attendre d’un projet.
Aujourd’hui, comme la communauté IT adopte et s’adapte aux pratiques Agile, en faisons-nous assez pour instruire et informer notre écosystème – nos clients ?
Ce qui suit sont mes opinions sur certains des processus ou des engagements auxquels ces clients ont besoin de s’adapter dans le monde Agile.
Vider son esprit par rapport à construire les besoins de manière itérative
Dans la méthodologie « waterfall » les besoins sont le début des projets, avec des clients les exposant et des consultants les documentant. Les besoins n’étaient jamais revisités de nouveau avec le client, puisque le client les avait déjà formellement signés. Les projets commençaient seulement après que la collecte de besoins soit finie.
Dans Agile, cependant, les besoins, depuis le début même, peuvent être définis comme des « épopées » et doivent régulièrement être décomposées en histoires. À chaque planification de sprint, toutes les parties prenantes (incluant le client) conviennent d’histoires (autrement dit de fonctionnalités et de besoins) qui doivent être développées et testées dans le prochain sprint. Cela devrait être utilisé comme un facteur « WOW » par l’équipe projet, pour aider des clients à comprendre qu’ils peuvent être complètement en accord avec ce qui est développé et ils peuvent aussi prioriser les fonctionnalités selon leurs besoins business.
Cependant, là se trouvent les défis :
Participation : les Clients doivent s’engager sur la démonstration et la planification de sprint. Si éviter celles-ci est la norme et les propriétaires de produit deviennent régulièrement des mandataires pour le client, les bénéfices d’Agile ne peuvent jamais être expérimentés ni implémentés.
Alignement des équipes : le fonctionnel, le développement et des équipes QA doivent sortir de leurs mentalités « waterfall » et travailler vraiment en tandem dans chaque sprint, recherchant des démonstrations de sprint réussies sans balayer les problèmes sous le tapis.
Les estimations du management par rapport aux évaluations de point d’histoire d’équipe Scrum
En « waterfall », des échéanciers de projet partent du « go ». On s’attend à quelques semaines de collecte des besoins pour permettre au projet et aux managers de dessiner un parfait plan de projet, avec allocation des ressources, test d’acceptation utilisateur et date de livraison bien définie. Un chef de projet méritant son salaire intégrera toujours une marge de 20 à 30 pour cent.
Agile tourne ce processus sur sa tête. Il implique que l’équipe de Scrum (pas le management) devrait calculer les point d’histoire (« Story Points ») et s’engager à atteindre ces points d’histoire en fonction de la vélocité de l’équipe.
Ici, les défis sont :
Planification de projet : je crois qu’un échéancier est le plus grand défi du projet. L’idée de toujours avoir une date finale de projet (qui, selon diverses études, n’est pas respectée dans 80% des cas en « Waterfall ») sont si innés dans les organisations IT et chez leurs clients qu’atteindre la date finale possible de projet basée sur des points d’histoire va demander beaucoup de désapprentissage avant que cela ne puisse arriver.
Évaluations récurrentes : les propriétaires de produit, ainsi que les clients, doivent participer à la planification de Sprint en aidant ‘équipe, à nettoyer et calculer les points d’histoire de l’arriéré de produit. Ils peuvent alors voir ce qui peut être accompli dans le sprint à venir et ce quels sont les reliquats du sprint précédent.
Vélocité d’équipe : la méthodologie Agile implique que l’équipe soit assez mâture pour connaître sa vélocité, a suffisamment d’expérience pour estimer les besoins et a assez d’autorité pour s’engager sur les échéances.
Fin de développement par rapport à démonstration de sprint
Les démonstrations de sprint exigent que l’équipe Scrum ait un morceau de code qui marche, digne d’être montré, mais elles exigent aussi l’engagement de la partie prenante clé : le client.
Les défis de cette approche :
Revue constante : si l’ingénierie et l’assurance qualité (QA) doivent s’adapter à des cycles de trois à quatre semaines pour créer un morceau de code fonctionnel et digne d’être montré, le client et le propriétaire de produit doivent aussi s’adapter au processus de constante revue. Le succès ou l’échec d’une histoire ramènent finalement à combien l’équipe Scrum a bien compris l’histoire, appelant ainsi à une revue de l’histoire elle-même. Fini sont les jours « Mais je pensais que vous aviez compris ce que je vous avais alors dit ». Si la planification de sprint et même les réunions « stad up » quotidiennes ont abouti à un écart de communication, l’équipe entière doit revisiter beaucoup de terrain, les besoins n’en étant qu’une partie.
Les projets au temps passé et dépenses contre coût fixe
La méthode « waterfall » permet aux organisations de négocier des contrats comme des offres à coût fixe ou bien en fonction du temps passé et des dépenses en matériel. Le type d’offre est dirigé par les offres des concurrents, la longueur possible du projet et le budget et la force de négociation du client.
Cependant, dans le monde Agile, cela n’aurait pas de sens d’avoir des contrats de type temps + coûts en matériels.
article précédent sur assistons-nous à la fin des contrats « classiques »?
Voici Pourquoi:
Des pratiques de sprint itératives donnent à toutes les parties prenantes la capacité d’arrêter le projet après n’importe quel sprint. (Assomption : à la fin de n’importe quel sprint, l’équipe a un code qui marche.)
La planification de sprint permet à toutes les parties prenantes d’avoir accès et d’analyser ce qui peut être réalisé dans des sprints futurs en fonction de la vitesse de l’équipe.
Le soin porté à l’arriéré de produit permet aux besoins d’être alignés sur les besoins business avant chaque sprint, ce qui permet aux clients de prioriser selon ses objectifs business. Par exemple, donner à l’intégration du site Web à PayPal pour les achats en lige la priorité sur un tableau de bord pour les partenaires, atteignant ainsi une présence en ligne avant que la campagne publicitaire « achetez en ligne » ne devienne virale.
Voici quelques-uns des aspects d’Agile auxquels je crois que les organisations doivent s’adapter. Mais un point important est que les clients doivent aussi changer la façon dont ils engagent dans un Monde Agile.
Voici une petite vidéo de Vincent McGevna sur comment « Agiliser » l’approche « Waterfall ».
partagez ce billet avec vos amis, collègues et relations professionnelles
Le 27 mars 2012 a eu lieu le Scrum Day 2012, l’événement annuel organisé par le French Scrum User Group et rendez-vous incontournable pour tous les acteurs de l’Agilité. Il s’agit d’un rassemblement majeur pour la communauté SCRUM : il permet de réunir chaque année sur une journée un grand nombre de membres, ainsi que les personnes impliquées dans l’Agilité en général. Résolument interactif, l’événement revêt différents formats, comme des keynotes, des conférences, des ateliers, des open spaces et des retours d’expériences… retrouvez en suivant le lien ci-dessous les présentations de la journée 2012.
Vous apprécierez par exemple certainement le retour d’expérience de Pierre Neis sur les User Stories:
Cette session reprend un retour d’expérience sur la collecte des user stories sur un programme d’envergure impliquant un grand nombre de participants, un grand nombre de personæ.
Comment procéder ? qui impliquer ? à quelle cadence ?
Grâce à l’aide des équipes d’ergonomes, de Product Owners et de Business Analysts, nous avons testé une approche agile de la collecte des besoins.
Ce retour d’expérience mis l’accent sur:
– le rôle et les actions des ergonomes
– les Business Analysts et les Product Owners
– l’utilisation dynamique de Serious Games pour animer un benchmark de plus de 50 participants
– les forces et les faiblesses de cette approche
– les leçons apprises
partagez ce billet avec vos amis, collègues et relations professionnelles
On y trouve entre autre la table ci-dessous, ainsi que :
une définition, « Une équipe distribuée est une équipe où le chef de projet, le product owner , les développeurs, les testeurs et les utilisateurs ou tout autre membre de l’équipe, consultants et vendeurs externes, travaillent sur plus d’un emplacement. »
Et des statistiques intéressantes:
20% des projets Agile sont distribués sur 2 ou 3 emplacements géographiques
seulement 20% des projets sont conduits sous méthode Agile.
partagez ce billet avec vos amis, collègues et relations professionnelles
Avez-vous jamais entendu ou prononcé l’une de ces expressions ?
Nous allons implémenter la méthodologie Scrum.
Nous appliquons un Scrum modifié.
Nos développeurs utilisent un processus Scrum.
Ces déclarations peuvent sembler inoffensives mais elles sont les indicateurs d’interprétation erronée potentielle de comment Scrum est le mieux utilisé. Scrum n’est pas un processus de développement complet (bien que presque quoi que ce soit qui a des étapes puisse être considéré comme un processus) et ce n’est pas une méthodologie. Scrum ne vous dit pas comment implémenter le logiciel. C’est une structure simple qui aidera un groupe qui développe des produits à comprendre ce qui ne fonctionne pas bien et comment y remédier.
Voici le diagramme du Modèle Scrum
La Structure de Scrum
Au début, les personnes et équipes implémentant Scrum se concentrent sur le processus sans comprendre pourquoi et comment réaliser chaque partie efficacement. Nous croyons que nous « ferons du Scrum » et en gagnerons tous les bénéfices, simplement :
En maintenant d’une liste de travail à faire (l’Arriéré de Produit)
En l’assignant à l’équipe pendant une réunion de Planification de Sprint
En réalisant ce travail pendant la durée du Sprint
Ce focus sur comment passer à travers les étapes peut être dangereux et irritant pour les individus, équipes et managers. Scrum n’est pas UNE SOLUTION MIRACLE! Aucun processus, pratiques, ou des techniques ne le sont. Au lieu de vous concentrer sur le processus, les pratiques et les techniques de Scrum, je suggère aux personnes, équipes et au management de se concentrer sur les enseignements qui peuvent être produits par une équipe faisant du Scrum et agir sur ceux-ci.
Scrum est un processus empirique de contrôle. L’idée est que vous planifiez et réalisez ensuite quelque chose, inspectez ce que vous avez fait et adaptez ensuite votre comportement pour vous améliorer. C’est une structure apprenante pour des équipes de développement de produits. On se réfère à ce cycle d’étude comme « inspecter et s’adapter ». Les 3 rôles de Scrum sont impliqués dans cet apprentissage : le Propriétaire de Produit, le ScrumMaster et les Développeurs (quand je dis Développeurs je veux dire toute personne dont on a besoin pour construire le produit, pas seulement des programmeurs).
Dans Scrum, Il y a 3 cycles spécifiques « Inspecter et Adapter » :
La rencontre Scrum Quotidienne (Daily Scrum) permet à l’équipe de se concentrer sur ses engagements pour le Sprint actuel et vérifier s’ils sont toujours en piste pour livrer par rapport à cet engagement. S’ils ne peuvent pas respecter l’engagement, alors on leur demande d’ajuster le Sprint, s’adaptant ainsi à la situation.
La réunion de Revue de Sprint (Sprint Review) permet aux clients de voir un incrément de produit potentiellement utilisable créé par l’Équipe et de leur fournir un retour d’information qui ajuste le contenu de l’Arriéré de Produit et les priorités. Nous inspectons le produit et nous nous adaptons à une nouvelle compréhension du produit.
La Rétrospective de Sprint permet à l’Équipe d’améliorer le processus qu’ils utilisent pour délivrer du logiciel à chaque Sprint. On s’attend à ce que l’équipe inspecte son processus honnêtement et à fond pour comprendre comment ils peuvent s’adapter pour que leur capacité collective de livraison soit améliorée dans le prochain Sprint.
Si vous lisez souvent mon blog, vous pourriez reconnaître ici un billet précédent appelé « Kaizen Mentalité » qui contient de bonnes informations sur la façon d’utiliser les leçons apprises et gérez les obstacles autour de celles-ci.
Partenaire de DantotsuPM
Scrum est plus un outil qu’une méthodologie.
Scrum rendra visible ce qui ne va pas aussi bien qu’il pourrait être. C’est alors aux personnes dans l’équipe et l’organisation e faire des changements pour s’améliorer. Avec chaque amélioration progressive, l’équipe de développement accomplira beaucoup plus efficacement son travail. Plutôt que de vous concentrer sur atteindre la perfection sur chaque étape dans la structure de Scrum, découvrez ce qui peut être amélioré dans votre processus de livraison et adaptez-le en conséquence. Si une partie de la structure de Scrum est difficile à faire ou semble être une perte de temps alors, au lieu d’éliminer cette partie, découvrez pourquoi c’est difficile ou gaspilleur dans son adoption. Il y a d’habitude un obstacle caché derrière ces difficultés et perceptions qui si il est éliminé permettra à l’équipe de développement de produits d’être plus efficace.
Scrum n’est pas une destination.
C’est plutôt un outil qu’une équipe de développement de produits utilise pour continuellement inspecter et adapter leur façon de délivrer pour la rendre plus effective. La destination devrait être votre business et vos objectifs d’efficacité d’équipe de développement. Comment pouvons-nous livrer davantage ? Comment pouvons-nous réduire le temps entre le commencement et la livraison du projet? Comment pouvons-nous délivrer plus souvent à plus bas coût pour stabiliser les sorties de produits ? Comment pouvons-nous réduire le risque dans notre processus de livraison de projet et dans notre portefeuille de projets ?
La destination devrait être substantielle et attractive. Scrum est seulement le véhicule pour vous aider à vous y rendre.
partagez ce billet avec vos amis, collègues et relations professionnelles
La méthode de gestion de projets PRINCE2 grandit en popularité dans le monde entier. Cependant, un nouveau challenger, Agile, est apparu. Nous commençons à entendre ici et là le débat « PRINCE2 ou Agile » ? C’est une question intéressante, mais souvent c’est une façon erronée de poser le problème.
En effet, lorsque vous commencez un projet de décoration d’intérieur, vous ne vous demandez pas si vous allez utiliser le marteau ou le tournevis ? Il est probable que vous aurez besoin des deux. Ce qui importe est de savoir quand utiliser quel outil et de savoir utiliser chaque outil correctement.
La même chose s’applique à PRINCE2 et Agile. Une organisation mature dispose des deux méthodes dans sa boîte à outils, et de manière habile utilisera l’outil approprié au bon moment.
Donc si nous avons besoin de PRINCE2 et Agile, comment comparer les deux outils ?
Tout d’abord comparons ce qui est comparable, le point de départ est donc de trouver l’Agile qui convient. En effet, Il y a beaucoup de variantes d’Agile, comme ces variantes légères que sont SCRUM et XP. Ces variantes légères ne sont pas des méthodes de gestion de projets de grande envergure, elles sont utilisées par les équipes afin de gérer des parties de projets, surtout la partie informatique. Un concurrent de poids à PRINCE2 est ATERN Agile (aussi connu sous le nom DSDM).
Partenaire de DantotsuPM
PRINCE2 et Agile-ATERN sont des méthodes de gestion de projets à part entière. Les deux sont des méthodes globales. Les deux sont des méthodes « clé en main » axées sur la rentabilité, le contrôle, la qualité, et ainsi de suite.
Laquelle choisir ?
PRINCE2 est le choix le plus approprié pour les projets basés sur les spécifications
ATERN Agile est le meilleur choix pour les projets de découverte
ATERN Agile est fantastique pour les projets avec des dates butoir serrées
Le type de projet va influencer le choix de votre méthode :
Basés sur les spécifications signifie que vous commencez avec un document écrit (et probablement avec un contrat) ;
Les projets de découverte eux ont seulement besoin des éléments essentiels pour démarrer ;
Les projets avec des fortes contraintes de délai doivent absolument être livrés à temps.
Mais il n’est pas toujours nécessaire de choisir entre l’une ou l’autre des méthodes. Puisqu’ATERN a intégré des idées de PRINCE2, alors vous pouvez aussi rendre PRINCE2 plus Agile.
Voici quelques façons de rendre un projet PRINCE2 plus Agile :
Utiliser votre première séquence pour construire un prototype avec des fonctionnalités limitées afin de simuler la vraie solution ;
Utiliser ensuite une séquence pilote avec un déploiement limité qui vise à développer quelque chose qui marche et est utilisable dans l’usage quotidien ;
Utiliser les « timebox » (zéro tolérance de temps pour une séquence, mais une haute tolérance de périmètre – si vous êtes en retard, réduisez le périmètre) ;
Débuter votre journée par des réunions debout (chef de projet plus les chefs d’équipe) ;
Utiliser le concept de « suffisamment de conception en amont » (EDUF : Enough Design Up Front) et non pas le concept de « Massive Conception en Amont » (BDUF : Big Design Up Front) en finalisant vos descriptions de produit à la limite de séquence (au lieu du DIP) ;
Pour un lot de travaux où vous avez besoin d’une approche de découverte, utilisez une méthode Agile légère comme XP ou SCRUM.
Tout comme la question n’est pas de savoir s’il faut utiliser le marteau ou le tournevis pour vos projets domestiques, le même raisonnement s’applique lorsqu’il s’agit de PRINCE2 ou d’Agile pour votre entreprise.
CONCLUSION
Tout comme vous avez besoin d’un marteau et d’un tournevis à la maison, vous pouvez avoir besoin de PRINCE2 et d’Agile au travail. Le mieux c’est donc d’avoir les deux outils. Si vous utilisez PRINCE2 aujourd’hui, vous devriez d’ores et déjà commencer à vous intéresser à ATERN.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Une de mes idées préférées dans la nouvelle vague de programmation est la notion de produit viable minimal. L’idée est que vous devriez spécifier et construire le plus petit noyau de votre idée principale, le livrer au monde et voir comment les gens lui réagissent, puis l’améliorer à partir de là.
Pour des outils de forage et autres, c’est parfaitement clair. Livrez-les, faites-les utiliser, améliorez-les. La définition « de minimal » est évidente.
Souvent, pour le logiciel que nous utilisons dans le grand public, cette définition mène à l’échec. Pourquoi ? Deux raisons :
1. Le marketing joue avec des règles différentes de l’ingénierie. Beaucoup de produits dépendent de la communauté, de l’adoption par une tribu, de la rumeur. Ces produits ne sont pas viables quand ils sont initialement lancés, précisément parce qu’ils n’ont pas encore été adoptés. « Est utilisé par mes alter ego » est un élément clé de ce qui fait qu’une chose comme un télécopieur soit considéré comme un produit viable et bien sûr, votre nouvel outil ne l’est pas.
Avec suffisamment de patience, de continuité et un enthousiasme cohérent, ces produits vont passer ce seuil. Mais si la mentalité est « voir ce qui marche et en faire davantage », vous vous retrouverez souvent à renoncer bien avant que cela ne se produise.
2. Il y a un pic d’énergie et d’attention et d’effort qui accompagne un lancement, même minimalement viable. S’il y a un délai dans l’adoption par la communauté, il serait facile de passer à la chose suivante (voir #1), au lancement suivant, à la vague suivante, par opposition à faire le travail terriblement difficile de poursuivre avec cette chose que vous avez déjà lancée.
Inhérent au processus de produit viable minimal est la grande et large base de personnes qui vous font confiance et qui seront impatients de vous écouter, d’essayer votre nouveau livrable et vous feront part de ce qu’elles pensent.
Et vous n’avez pas l’option de construire cette base une fois que le produit est prêt : c’est trop tard.
Pour en apprendre davantage sur le concept MVP Minimum Viable Product, regardez et écoutez Eric Vries, auteur du blog Startup Lessons Learned
partagez ce billet avec vos amis, collègues et relations professionnelles
Comment rédigez-vous un contrat au forfait sur une proposition Agile embryonnaire ? Ce n’est pas aussi difficile que certains le font paraître mais cela implique un vrai changement de mentalité et un exercice d’apprentissage pour tout un chacun. Clairement définir « fait » (« done »), évaluer des histoires et comprendre la vélocité sont clés à la réussite.
Ne limitez pas Agile
Si toute l’idée d’Agile est que vous ne pouvez pas prévoir l’avenir, alors comment pouvez-vous l’utiliser dans un Environnement de contrat de forfait où il est essentiel de préciser vos coûts, votre temps et votre contenu de projet ? Peut-être que la réponse est de regarder au-delà de relier Agile à des modèles de contrat mal adaptés et de proposer une nouvelle structure.
OK, donc la chose fondamentale que nous pouvons affirmer de tout ce que nous lisons sur Agile est le fait que les besoins ont vraiment tendance à être très brumeux. Au contraire, le modèle de contrat fixe exige d’un jeu détaillé, stable et précis de besoins, définissant clairement des limites et des pénalités si quelqu’un pose le pied à l’extérieur de celles-ci.
Le faire de façon professionnelle
article précédent sur assistons-nous à la fin des contrats « classiques »?
Comment diable deux animaux si différents peuvent-ils coexister dans le même environnement ? Il y a tant de débat sur comment ceci peut être fait que couvrir chaque idée, pensée ou sentiment nécessiterait des dizaines d’articles. Je pense que ma meilleure approche est de décrire mon expérience et comment je configure un Contrat Agile.
Au tout début d’aborder la question d’Agile et forfait, il était impératif de partir d’une structure logique et professionnelle pour le processus. Je voyais si souvent des présentations où la société a offert une approche de toute évidence biaisée et il n’y avait absolument aucune chance que le projet puisse commencer, encore moins être complété. Mon conseil à toute société travaillant dans le marché de contrat au forfait Agile est de passer du temps à définir votre évaluation, cadencement et l’approche de définition du contenu. Un travail bâclé se sent à un kilomètre.
Alors, comment approchons-nous une proposition de contrat au forfait ? La première chose que nous avons faite a été de regarder le processus Agile que nous avions entrepris et le découper en trois domaines distincts. Sur chacun de ces domaines, nous avons alors passé beaucoup de temps à définir et documenter clairement et précisément le quoi et le comment. Pour nous, cela nous a ouvert une structure complètement différente de notre organisation et a potentiellement ajouté de nouvelles sources de revenu.
Le temps et les coûts dans un contrat au forfait sont raisonnablement faciles à définir et pour Agile l’approche itérative a durée contrainte est très facile à définir. Ceci nous laisse donc seulement avec le problème du contenu/portée/périmètre. Comment pourrions-nous fixer les livrables sans étrangler la méthodologie Agile que nous suivons si fièrement ? Le problème était de changer le concept de contenu en un budget.
Définition de l’élément « contenu » du Contrat
La toute première étape était de collecter les besoins des utilisateurs sous forme d’un arriéré de produit en utilisant des histoires utilisateur pour détailler les attentes des clients. Nous utilisons alors cet arriéré de produit pour prioriser puis évaluer les fonctionnalités en utilisant des techniques d’estimation de groupe comme le « Planning Poker » et donner des valeurs sous forme de points d’histoire « Story Points ».
En allant plus loin dans ce processus nous passons 1 à 2 jours à définir :
« L’histoire utilisateur est une façon d’exprimer des besoins qui sont compréhensibles pour les deux clients et nous-mêmes. Les histoires utilisateur sont rapides à écrire et impliqueront tous les niveaux de la structure d’organisation concernée. Elles sont, plus important encore, orientées fonctionnalité, donc elles peuvent fournir une bonne vue du contenu réel d’un projet et nous pouvons les comparer l’une à l’autre en termes de taille, d’effort « , etc [1]
Pour l’estimation, nous avons tendance à utiliser des points d’histoire par opposition aux jours idéaux ( Je discute de ceux-ci dans mon article sur les Burndown Charts). Il est très important de vous assurer que vous avez une vue très claire de « fait » (« done ») et que vous avez une définition explicite et concrète qui forme le point de contrôle critique du projet agile. Sans une compréhension cohérente de « fait » il sera impossible d’évaluer précisément la vélocité. « C’est aussi une façon de construire la confiance avec le client en ayant un consensus commun quant au processus de projet et sur le critère d’acceptation de haut niveau. « [1]
Ici, nous pouvons maintenant inventer une valeur définissant notre budget de contenu avec des points d’histoire. C’est cette valeur qui est fixée dans le contrat et non Pas les histoires.
Alors, combien cela coûtera-t-il et combien de temps sera nécessaire ?
Avec notre contenu défini nous pouvons maintenant concentrer à établir le prix et la durée. Et, pour ce faire, nous devons regarder la Vélocité de l’Équipe, combien de points une équipe peut-elle réaliser pendant une itération ?
La vélocité de l’équipe est basée sur beaucoup de facteurs, pas seulement combien de travail qu’ils peuvent réaliser. Nos pratiques de travail définissent déjà notre stratégie de communication et nous savons donc combien de temps est passé en réunions planifiées avec l’équipe et le client. Il y a d’autres facteurs à considérer comme les vacances, le volume des tâches, etc. En bout de ligne la vélocité journalière sera un nombre qui est en partie basé sur l’expérience, mais contient pas mal de suppositions (par exemple : si nous sommes en l’hiver, nous pouvons être sûrs que quelqu’un aura la grippe).
Disons par exemple que nous avons calculé que l’équipe peut livrer 30 points d’histoire par itération de 2 semaines et a 240 points d’histoire à livrer (tel que défini dans le contrat). Nous avons maintenant une durée de livraison de 8 itérations nécessitant 16 semaines en tout. Avec 70 heures allouées à chaque itération, une équipe de 5 personnes et un taux horaire de 100 € par membre de l’équipe nous pouvons facilement calculer le prix à 280,000 €.
Donc, maintenant nous avons nos valeurs de contrat fixes :
Prix 280,000 €
Temps 16 Semaines
Contenu 200 points d’histoire
Ces valeurs font tout simplement partie de la procédure tarifaire du contrat et ils ont vraiment tendance à être les chiffres les plus difficiles à atteindre avec un niveau de confiance acceptable.
Ce que nous essayions de montrer ici est que la façon dont nous travaillons sur les projets Agile peut aussi se refléter dans l’environnement des négociations de contrat.
Qu’advient-il si..
… Le propriétaire de produit « product owner » (le client) veut ajouter une autre fonctionnalité ? Nous avons déjà travaillé étroitement avec le client, à définir l’arriéré de produit, évaluer les points d’histoire, donc il connaît la situation actuelle. En cas de demande de travail supplémentaire nous évaluons l’ajout, disons 10 points d’histoire dans ce cas et nous négocions pour soit supprimer 10 points de valeur d’histoire de fonctionnalités agréée soit ajouter une itération de plus. Maintenant que nous avons fixé les points pour le contenu nous pouvons permettre à des changements de se produire, en termes de points. Cela nous permet d’interchanger des besoins en chemin dans la limite de contenu définie. Si nous pouvons rester dans cette limite, nous pouvons aussi rester dans des prix et durée fixes.
… Le client se plaint du prix ? Nous clarifions avec nos équipes de vente que la seule négociation possible dans cette situation est le tarif horaire. Nous ne mettrons pas en péril le projet en essayant d’augmenter la vélocité. Vous ne pouvez pas changer les membres de votre équipe en super-héros en changeant des valeurs sur une feuille de papier.
Et Finalement
Une fois que vous faites signer le contrat et que le travail est en cours, il est impératif que vous managiez vos coûts. Dans mon article sur les Burndown Charts, je discute de comment ceux-ci peuvent être utilisés pour contrôler la vélocité de l’équip. Ils peuvent aussi être utilisés pour contrôler le changement de contenu et les coûts.
Un de mes secteurs de spécialisation est les Contrats au Forfait Agiles, et j’écris et présente sur le sujet régulièrement.
Maurice Saunier nous propose une brève enquête pour sa thèse dont le sujet est de montrer que l’agilité et la gestion de projet classique peuvent cohabiter et que cette cohabitation pourrait faire émerger un management de projet hybride et différent.
accéder au questionnaire
Qui peut répondre ?
==> ceux et celles qui ont pratiqué Agile sur leur vision de l’agilité et sur ce qui en fait la réussite ==> ceux et celles qui n’ont pas pratiqué Agile sur leur vision du management de projet actuel.
Maurice recoupera les réponses des deux communautés et analysera les liens potentiels entre ces deux communautés.
Une fois le sondage fini, il s’en servira pour sa thèse et produira un document annexe pour en commenter les résultats qu’il partagera avec les personnes qui auront répondu et laissé leurs coordonnées de courrier électronique.
Merci à Mahfoud Amiour , Directeur de projet indépendant, Expert Agile chez SOFTENIA Solutions, qui a récemment traduit en français la dernière version du guide Scrum de Ken Schwaber et Jeff Sutherland (Version Juillet 2011).
(Note de Michel: Je vous l’accorde, la traduction du titre n’est pas littérale, mais tellement plus valorisante et plus française ! )
Derek est heureux d’annoncer le lancement du projet de Guide Communautaire PMI-ACP. Chaque jour, il voit que du nouveau contenu y est ajouté. Il se demande si c’est ainsi que Jimmy Wales s’est senti dans les premiers jours de Wikipedia. La première mesure de succès est d’atteindre un contenu pour chaque page du Guide qui soit proche de la vision du Comité de pilotage ACP et ceci aussi rapidement que possible. La deuxième mesure de succès est d’atteindre le point de basculement, à partir duquel la communauté (et non plus l’équipe de support) maintient le guide. Souvenez-vous, les versions futures de l’examen ACP seront basées sur ce Guide.
Dirigée par Joseph Flahiff de Whitewater Projets et Derek Huether, l’équipe de Support d’ACP a démarré le processus de création du Guide Communautaire. Ils sont décidés et 100 % auto-organisés.
L’Arriéré
Pour livrer quelque chose de valeur à la communauté, Joseph et Derek se sont servis du wiki sur le site Web du PMI pour créer un Arriéré de Produit. Ils ont voulu la transparence pour que chacun sache ce sur quoi ils sont concentrés. Chaque domaine majeur de l’examen ACP a une page en attente d’édition. Si vous aviez un arriéré de produit traditionnel, les 10 domaines majeurs qui comprennent les « Tools & Techniques » de l’examen pourraient facilement être considérés comme des « Epics ». Chaque page de notre wiki pourrait être comparée à une Histoire d’Utilisateur. Nous n’estimons pas notre temps de travail. Nous le faisons tout simplement.
Itération 1
Ils ont fini l’Itération #1 le 10 mai 2012. Ils ont demandé à leur équipe de 15 membres des volontaires pour s’engager à travailler sur les 7 premières pages du premier domaine de contenu. À la fin de chaque itération, ils peuvent demander aux membres du comité de pilotage ACP de passer en revue ce qui a été fait. Il est important de rester concentrés, d’avoir des boucles de retour d’information courtes et de livrer quelque chose de valeur sur une base régulière.
Boire son propre champagne
Quand vous pensez à PMI, vous pensez probablement aux plans de projet, aux échéanciers et autres choses de ce genre. En tant qu’équipe auto-organisée et autogérée, ils ont décidé de ce qui est important pour accroître leurs chances de réussite. Bien qu’il doive y avoir une date prévisible d’achèvement, basée sur les éléments à délivrer actuellement définis et la longueur des itérations, ils sont prêts pour des changements. Ils pourraient avoir à retravailler certaines pages. Ils pourraient avoir des départs et arrivées dans l’équipe. Quoiqu’il en soit, ils peuvent garantir qu’ils livreront de la valeur sur une base régulière. Ils peuvent aussi garantir qu’il y a de la collaboration avec la communauté.
Rejoindre l’Équipe
Si vous êtes intéressés par la création ou la maintenance d’articles pour le Guide Communautaire, Adhérez à cette équipe! Si vous voulez travailler de manière indépendante, ils accueilleront vos contributions de valeur.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Il y a trois raisons. Deux font explicitement partie de Scrum. L’autre n’est pas mentionnée, mais est une des fondations de Scrum. Les explicites sont le retour d’information rapide et le renforcement de la vue réaliste. La troisième est la suppression des retards.
Retour d’information rapide
Vous voulez un retour d’information rapide. Attendre plus de 30 jours pour ce retour d’information ne vous donne pas assez rapidement ce retour d’information.
Quel genre de retour d’information ? Un retour d’information qui vous permette d’apprendre rapidement. Le retour d’information vient sous bien des formes. Il y a le temps entre la réception d’une demande jusqu’à sa livraison et le temps de commencer une histoire jusqu’à ce qu’elle soit complète. Mais vous n’avez pas à écrire tout le code pour découvrir que le client n’en veut pas. Au lieu de cela, vous voulez écrire un peu de code sur les histoires dont le client a une compréhension claire. Montrer une partie de la fonctionnalité à un client nous permet d’en apprendre davantage sur le reste de ce qu’ils veulent.
J’entends souvent « échouez vite » comme raison. Je préférerais personnellement apprenez vite. Si je dois échouer, je voudrais le faire rapidement. Mais mon objectif est d’apprendre pas d’échouer.
Renforcement de la vue réaliste
Avec « renforcement de la vue réaliste », je veux dire que seule la fin d’un sprint nous dira où nous en sommes de manière objective, non subjective. Si le test n’est pas fini, sprint n’est pas fini. La raison est probablement un obstacle dans notre processus. Sans dates rigides, fixes, il est facile de rationaliser pourquoi nous n’avons pas accompli ce que nous voulions. Des obstacles usuels sont que les clients peuvent ne pas vouloir vous parler, que les processus de développement sont peut-être inefficaces, que les évaluations et le développement du code sont trop éloignés. En ayant une période déterminée de temps dans laquelle votre travail doit être achevé avec le timeboxing du sprint, ces choses qui travaillent à votre encontre deviendront plus visibles et douloureuses. Ce sont dans les faits des obstacles à votre travail et au lieu de les éviter en rallongeant le sprint, vous devez en réalité raccourcir le sprint pour les mettre encore plus en évidence. Il sera aussi plus difficile de les ignorer : si vous n’avez pas testé votre code à la fin du sprint, ce sera évident et irréfutable.
Ces deux raisons ont en réalité tendance à inciter à des sprints encore plus courts que 30 jours. La plupart des équipes Scrum qui réussissent et que je connaisse utilisent des sprints d’une ou deux semaines. En fait, j’irais jusqu’à dire que des équipes avec des sprints de trois ou quatre semaines indiquent une tendance à ne pas être pas suffisamment engagées dans la résolution de leurs problèmes. Ceci n’est pas toujours vrai, mais c’est assez souvent le cas.
suppression des retards
La troisième raison, qui par beaucoup d’aspects est la plus grande, est d’éliminer les retards.
Depuis 2004, j’ai clamé que Scrum est une faible mise en œuvre des principes Lean. Je dis « faible » parce que Scrum ne se préoccupe pas de l’optimisation de la totalité du processus, Scrum se concentre sur l’équipe de développement et délaisse une grande partie de l’éducation et du management Lean. Mais un des principes clés de Lean est d’éliminer les retards afin que la valeur puisse peut être délivrée rapidement. Ceci est critique parce que chaque délai entre étapes de travail crée littéralement plus de travail.
Le timeboxing dans Scrum exige que les équipes complètent leur travail rapidement, et encourage aussi à élaguer. Ceci réduit les retards et évite donc de faire un travail qui ne devrait pas être nécessaire.
La combinaison du retour d’information rapide, du renforcement de la vue réaliste et de la suppression des retards nous permet d’avoir des boucles de retour d’information de plus en plus brèves jusqu’à ce que tous les frais généraux du sprint, les « overhead », dépassent la valeur qu’ils sont censés apporter. Pour la plupart des équipes ce sera une ou deux semaines. Quelques équipes découvriront qu’elles n’ont pas besoin de la discipline du timeboxing et l’abandonneront complètement et pour passer sur Kanban.
partagez ce billet avec vos amis, collègues et relations professionnelles
Scrum est une technique de » management de projet » de plus en plus populaire sur les projets de développement logiciels (et de temps en temps sur d’autres types de projets). L’article Wikipedia http://fr.wikipedia.org/wiki/Scrum_(méthode) peut être un bon point de départ pour en apprendre davantage sur ce sujet.
Le « Microsoft Project 2010 Scrum Solution Starter » est conçu pour fournir des conseils d’utilisation de Microsoft Project 2010 pour manager des projets Scrum, aspirant à aider les équipes Scrum à commencer à utiliser MS Project pour :
Manager un Arriéré de Produit
Manager un Arriéré de « Sprint »
Suivre la progression et générer des « Burndown charts »
Ce kit de démarrage se concentre sur le poste MS Project 2010 et sur l’expérience de l’équipe Scrum.
Scrum est une méthodologie itérative et incrémentale pour la conduite de projet souvent vue dans le développement logiciel agile. Bien que Scrum ait été destinée au management de projets de développement logiciels, il peut être utilisé pour des équipes de maintenance logicielles, ou comme une approche générale de management de projets/programmes.
Il y a 3 artefacts principaux dans Scrum :
Arriéré de produit : Un arriéré de produit est dynamique : des items peuvent être supprimés ou ajoutés à tout moment pendant le projet. Ce sont les items avec la priorité la plus forte qui sont complétés d’abord. Ces articles prioritaires sont progressivement raffinés alors que ceux de priorité inférieure sont intentionnellement laissés à une granularité plus élevée.
Arriéré de sprint : Un arriéré de sprint est un jeu négocié d’articles de l’arriéré de produit qu’une équipe s’engage à compléter pendant la durée fixée pour un sprint. Les articles de l’arriéré de sprint sont décomposés en tâches détaillées pour que les membres de l’équipe les réalisent. L’équipe travaille de manière collaborative pour compléter les items de l’arriéré de sprint, se rencontrant chaque jour (pendant un « Daily Scrum ») pour partager les problèmes et avancées et mettre à jour l’arriéré de sprint et le « Burn Down chart » en conséquence.
« Burn Down » : Le graphique « Burn Down » du sprint est affiché publiquement et montre le reste-à-faire dans l’arriéré de sprint. Mis à jour quotidiennement, il fournit une vue simplifiée du progrès du sprint. Cela fournit aussi une visualisation rapide pour référence.
Scénarios Supportés:
Un Scrum Master veut utiliser MS Project pour les basiques de l’exécution d’un sprint, y compris :
Collecter et suivre le progrès
Gérer l’Arriéré de Produit
Gérer l’Arriéré de Sprint (et planifier l’itération initiale)
Générer un « Burn Down Chart »
Exporter facilement des données de Scrum poules r envoyer par courrier électronique ou autre moyen
partagez ce billet avec vos amis, collègues et relations professionnelles
Vous n’aimez pas le mot « Exigences » ? Ce n’est pas si clair, n’est-ce pas ? NON ! Avez-vous avez jamais entendu votre client dire « Je vous ai déjà donné mes exigence » et l’équipe répond alors « Nous n’avons pas reçu de besoins clairs ou détaillés ». L’autre face de ceci est quand l’équipe dit au client « Vous nous donnez trop de détails, ne nous dites pas où le bouton doit être placé sur l’écran, dites-nous seulement ce que vous voulez ». Pas étonnant nous ayons tant de problèmes liés aux exigences sur nos projets!
Pendant l’un de mes webinars PMI précédent, nous avons parlé de Agile Requirements – Breaking Down EPICs and Prioritizing. Je ferai un essai dans ce billet à récapituler les niveaux d’exigences Agile (et non Agile pour être honnête) et comment vous pouvez utiliser un processus à quatre étapes pour les rassembler.
D’abord, commençons par l’image ci-dessous. L’image montre 4 niveaux d’exigences et aussi sur la gauche les 4 étapes du processus pour réunir les exigences.
Visioning: C’est l’étape initiale de collecte des exigences. Le but est d’aider à identifier tous les Thèmes et quelques fonctionnalités désirées. Cet exercice commence à définir le périmètre de ce qui est attendu.
Brainstorm: Le but de cette étape est d’identifier toutes les fonctionnalités et histoires (« stories ») désirées. La clé est ici la Couverture d’abord, la Profondeur plus tard. Ainsi, au lieu de discuter les détails de chaque fonctionnalité et histoire, notre but principal est de TROUVER toutes les fonctionnalités et histoires.
Breakdown: Le But de cette étape est de décomposer et découper les histoires qui sont encore trop longues (des ÉPOPÉES) en de plus petits morceaux. Vous avez probablement déjà fait beaucoup de découpage pendant le brainstorming, mais comme vous revisitez votre arriéré, l’équipe se rendra compte que quelques histoires sont encore trop longues pour être complétées en une itération (d’habitude 1 à 4 semaines). Le découpage des histoires est un art et j’y dédierais un blog entier!
Deep Dive: C’est l’étape à laquelle veut sauter tout de suite! Oui, finalement parlons des détails. Ce qui sera sur l’écran, quelles sont les règles de gestion exactes et comment nous ferons pour les tester, ce à quoi ressemblera le processus détaillé, quelles sont les tâches que nous devons réaliser pour achever cette histoire. Sauter dans ce niveau de détail en amont pendant les phases initiales est une des raisons principales contribuant à la dérive de contenu plus tard pendant le projet.
Supposons que nous développons un système pour un site d’offre d’emploi en ligne OnStopJobs.com. Voici à un exemple de ce à quoi les exigences pourraient ressembler en se basant sur les niveaux ci-dessus :
1. Domaine Employeur- Thème
a. Gérez des Emplois- Fonctionnalité
1. En tant qu’employeur je veux afficher un job afin que d’autres puissent le trouver. Histoire
2. En tant qu’employeur je veux modifier une offre d’emploi pour la corriger. Histoire
3. En tant qu’employeur je veux une liste de mes offres d’emploi ouvertes pour les analyser. Histoire
4. En tant qu’employeur je veux pouvoir faire expirer une offre d’emploi pour que personne ne puisse y appliquer. Histoire
b. Gérez les Candidats
1. En tant qu’employeur je veux voir la liste de candidats récents pour pouvoir leur répondre.
2. En tant qu’employeur je veux voir la liste de candidats d’une offre d’emploi spécifique pour pouvoir les qualifier.
3. En tant qu’employeur je veux choisir les meilleurs candidats pour pouvoir les interviewer.
Vous devriez rassembler les niveaux ci-dessus (Thèmes, Fonctionnalités, Histoires) en amont quand vous planifiez de votre « Release », particulièrement si vous avez des projets traditionnels avec des dates de début et de fin. Nous passons d’habitude plus d’effort sur les histoires qui arrivent dans les quelques itérations suivantes ou la Release suivante.
Le Deep Dive est là où se trouve la différence principale entre Agile et En Cascade. Des équipes traditionnelles rassembleraient des informations très détaillées en amont pour TOUTES les histoires de l’arriéré, Alors qu’en Agile , les équipes rassembleront ces détails Juste à temps pour les histoires suivantes, soit une ou deux itérations avant que cette histoire soit à faire.
Voici à un exemple de ce à quoi les détails pourraient ressembler pour cette histoire choisie : « En tant qu’employeur je veux job afin que d’autres puissent le trouver «
Critères/tests d’acceptation (Comment saurons-nous quand nous aurons fini):
1. UAT1 – Vérifier que seul un utilisateur autorisé avec un compte d’employeur valable peut poster un travail pour le compte de cet employeur.
2. UAT2 – Vérifier qu’une offre d’emploi dupliquée ne peut pas être entrée.
3. UAT3 – Vérifier que la date de publication est plus tard que la date du jour.
4. UAT4 – Vérifier que la date d’expiration est en principe dans 90 jours.
5. UAT5 – Vérifier que les champs sur l’écran passent nos règles standards de format.
6. UAT6 – Vérifier que tous les champs requis sont saisis.
Les critères d’acceptation sont ‘les détails’ de l’histoire et on les considère comme des exigences primaires dans Agile. Nous les réunissons avant de débuter tout développement.
Exemples de Tâches (Le travail à faire pour avoir fini):
1.Créez des tables de base de données pour stocker les détails d’offre d’emploi.
2.Concevez et construisez l’écran pour l’offre d’emploi.
3.Développez la logique pour passer UAT1.
4.Documentez/enregistrez l’aide vidéo insérée dans la page d’offre d’emploi.
5.Exécutez le test d’acceptation utilisateur.
6.Déployez le code dans l’environnement de test.
7.…..autres.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
J’étais à une conférence il y a peu de temps parlant et partageant sur divers sujets agiles. Comme il arrive souvent, un jeune homme m’a arrêté afin de me poser quelques questions après ma présentation. Nous avons entamé une conversation agréable qui a finalement débordé jusqu’au corridor de l’hôtel.
Nous avons commencé à parler de la dynamique de sprint dans des équipes Scrum et je suis arrivé de mentionner que je coache souvent des équipes vers la déclaration de leurs sprints en tant que succès ou… (pause pour plus d’effet) échec. Que nous faisons ceci comme partie intégrante de la revue de Sprint avec les équipes, le Propriétaire de Produit étant le décisionnaire final en se basant sur selon que l’équipe a atteint les Objectifs de Sprint ou pas.
Il a été visiblement énervé par mon avis. Il a dit qu’ils (il travaillait dans une société bien connue d’Atlanta) n’avaient jamais échoué de sprint. Jamais! Ils ne pouvaient pas, ni n’utilisaient ce MOT dans leur culture. Je lui ai demandé catégoriquement : n’avez-vous jamais échoué un sprint ? Il a dit bien sûr qu’ils l’avaient. Plusieurs fois. Mais au lieu d’utiliser le terme échec, ils ont utilisé le terme ‘challenge’. De cette façon, les parties prenantes ne se feraient pas de fausse idée et ne mettraient pas en doute les compétences ou la motivation de l’équipe.
Nous avons tourné en rond pendant 10 à 15 minutes de plus dans notre discussion, mais nous n’avons jamais vraiment réglé nos différences. Nous avons simplement consenti à être en désaccord. Bien que ce ne soit pas un terriblement large abîme entre nous, je me rappelle distinctement revenir vers ma chambre en secouant la tête. Je n’avais tout simplement pas compris le grand cas fait de l’échec. De l’utilisation du mot. D’une équipe disant…nous avons échoué. Dans mon job de coach et dans mes « tâches journalières », j’ai pu diriger et développer nos idées pour que l’échec ne soit pas un gros mot. C’est-à-dire l’échec est bon. L’échec est ok. L’échec mène à l’amélioration. L’échec fait partie de la vie.
Aussi, dans ce billet, je veux discuter de l’échec depuis quelques perspectives différentes. La discussion n’est pas destinée à être complète. Au lieu de cela, je veux juste partager quelques pensées avec vous et vous faire réfléchir sur l’échec… sur comment vous le percevez dans votre organisation, quelle est votre tolérance à l’échec et reconsidérer vos réactions normales face à lui. Je pense que cela vous mènera aussi à considérer votre management de risque, parce que je pense que les deux sont inextricablement liés.
Coacher pour éviter l’échec
Dans son blog du 20 juin 2011, s’intitulant Coaching is Not Letting Your Teams Fail (Coacher c’est ne pas laisser vos équipes échouer), Giora Morein justifie que des coach agiles devraient amener ou guider leurs équipes loin de l’échec. Il donne l’analogie d’un Sherpa guidant des alpinistes. Et oui, dans l’exemple de l’alpinisme en montagne, je dois reconnaître que l’échec n’est probablement pas le résultat que nous voulons.
Cependant, dans les environnements qui ne mettent pas la vie en danger, je pense que je ne suis pas d’accord avec Giora. Je crois de tout cœur que l’échec peut en réalité être bon pour une équipe. Je pense aussi que le rôle du coach est d’aider une équipe à regarder sa performance de deux perspectives. La plus facile des deux est la perspective de succès. C’est la perspective où vous donnez un retour d’information positif à l’équipe; où vous leur dites qu’ils ont besoin de répéter les pratiques qui marchent pour eux. En fait, quelles pratiques ils doivent amplifier et faire « davantage » afin d’atteindre des résultats de plus en plus importants.
Ces conversations sont clairement plus faciles.
Mais en ce qui concerne la perspective d’échec ? Comme coach, fournissez-vous une critique constructive ? Montrez-vous à une équipe où ils ont trébuché ? Tant individuellement que comme une équipe ? Je pense que vous le devez. Mais certainement pas de façon malveillante ou maladroite. Je pense si vous coachez efficacement une équipe vous devez explorer leurs erreurs et faux pas avec la même passion et énergie que quand vous traitez leurs succès.
Et je ne pense pas que vous le faites tranquillement, en vous cachant derrière des portes et sans reconnaître de leurs challenges. Non. Je pense que vous l’approchez de façon totalement transparente et pratique. En établissant au départ que l’échec est apprécié et bien accueilli. Que depuis l’échec, vos équipes cherchent des possibilités d’amélioration et avancent rapidement vers l’atteinte de meilleurs résultats.
Exposition Agile
Dans des équipes agiles, il y a deux cérémonies clés qui sont concentrées sur les résultats réussis ou pas de l’équipe. Dans Scrum, c’est la Revue de Sprint (la démonstration) et la Rétrospective de Sprint (les leçons apprises). Typiquement la revue de sprint est exposée au monde, donc vous pourriez vouloir être prudents sur comment vous énoncez vos échecs – pour que les parties prenantes n’interprètent pas mal l’impact ou l’effort consenti par l’équipe. Néanmoins, je crois que vous devriez déclarer des sprints succès ou échecs pendant l’introduction à la revue d’équipes.
Dans Scrum, c’est le rôle des Propriétaires de Produit de déterminer cela. Et c’est relatif aux objectifs sur lesquels l’équipe s’est engagée au début du sprint. On espère que ces objectifs étaient assez flexibles pour permettre à l’équipe d’ajuster leur travail pour les atteindre avec créativité.
Par exemple, je pense qu’un très mauvais objectif de sprint est quelque chose autour de l’équipe livrant un nombre d’histoires utilisateur – ou autres indicateurs d’exécution par cœur. Je pense que cela mène à un en-sablage potentiel de la part de l’équipe pour atteindre un but numérique plutôt que de penser au vrai problème qu’ils essayent de résoudre. Au lieu de cela, je pense que de meilleurs buts tournent autour de la réalisation d’une sorte de démonstration d’un comportement qui résout un jeu spécifique de problèmes clients. Donc le succès est mesuré sur comment l’équipe a respecté l’esprit de l’objectif et combien ils ont appliqué les principes agiles dans leur exécution.
Par exemple, j’ai vu des équipes qui s’engagent sur 10 histoires utilisateur, mais qui avaient 3 jours de temps mort à la fin de leur sprint, rater leur sprint. Pour sûr, ils ont bien livré par rapport à leur engagement, mais leur engagement était faussé. Ils s’étaient protégés et avait surestimé. De plus, ils n’ont pas fait part de leur capacité supplémentaire disponible à leur Propriétaire de Produit ni demandé davantage de travail dans leur sprint. Au lieu de cela ils ont planifié d’avance ou « plaqué or » leurs produits.
J’ai aussi vu des équipes qui s’engagent sur 10 histoires, mais en livrent 7 et ont un sprint très réussi. En cela qu’ils travaillent dur dans la complexité et l’adversité. Ils sont incroyablement transparents et engagent leur Propriétaire de Produit à faire des ajustements quotidiens sur les priorités en fonction de leur actuelle compréhension de leur capacité. Et en tant qu’équipe, bien qu’ils n’aient pas livré la quantité prévue à l’origine, ce qu’ils ont vraiment livré est aligné sur leurs objectifs et respecte l’esprit et l’intention du Propriétaire de Produit.
Ces deux cas devraient être discutés pendant la rétrospective des équipes et les façons de s’améliorer discutées. Pas de petite façon et sans ignorer les premiers troubles du comportement de l’équipe. Non. Tout cela, le bon, le mauvais (erreurs et échecs) et idées d’amélioration significatives, sera discuté pour que l’équipe décide de quels points sont dignes de leur attention pour amélioration dans le sprint suivant.
Mais l’échec est-il apprécié ?
En continuant sur mon exemple de coaching précédent, je me souviens qu’il n’y a pas longtemps je parlais à un groupe de nos Scrum Masters dans mon « travail de jour » chez iContact. Si vous ne connaissez pas Scrum, le Scrum Master est le coach et le guide principal et la voix du leadership agile dans l’équipe Scrum agile. Il est aussi responsable d’entretenir des valeurs agiles clés dans l’équipe et e la performance générale des équipes. Ce que j’entends par cela est qu’il guide les équipes vers une performance qui s’améliore dans la durée. Posant continuellement des questions comme : son équipe s’améliore-t-elle dans sa performance globale ? Sa vitesse s’améliore-t-elle ? Sa qualité de travail s’améliore-t-elle ? La collaboration et le travail en équipe s’améliorent-ils ? Et, leur focus est-il sur l’amélioration de la valeur livrée pour le client ?
Donc mon point auprès des Scrum Masters était que j’estimais que nous n’avions pas échoué depuis quelque temps. J’ai défini l’échec dans ce cas comme un échec de sprint ou un incident dans lequel une équipe s’est essentiellement heurtée à un obstacle et a eu besoin de re-planifier ou revoir l’alignement son sprint.
Ils ont tous été d’accord avec moi que les choses s’étaient déroulées sans à-coups. Et j’ai reçu plus que quelques regards interrogateurs fixes quant à pourquoi c’était un problème. J’ai essayé d’être prudent dans ma réponse, mais ma préoccupation était qu’il se pourrait que nous la jouions un peu trop sûrs. Que nous devenions complaisants dans nos pratiques agiles et que nous ne nous challengions pas assez. Que nous ne tentions rien. Et ne courrions pas de risques.
J’ai expliqué que ces caractéristiques sont fondamentales pour la croissance et la progression d’équipes agiles. Et le fait que nous ne rencontrions pas d’échecs indique que nous avons atteint un plateau dans notre croissance et notre performance. J’ai estimé que c’était un problème…et pour lequel j’ai demandé s’ils pourraient obtenir davantage d’échecs des équipes.
Pouvez-vous imaginer le reste de cette discussion ?
Me voilà le Directeur de R&D dans une société qui réussit en train de parler à mon équipe de Scrum Masters et leur demander d’amener plus d’échecs, pour inciter leurs équipes à davantage de prise de risques et inspirer des objectifs plus agressifs. Le point que j’essaye de faire passer est que j’apprécie vraiment l’échec. Que j’ai appris à le voir comme un critère critique de succès et que son absence est un problème pour moi. Je me demande combien d’organisations et de leaders ont la même position.
La notion de « Chuter en avant »
Un de mes auteurs préférés est John C. Maxwell. Il est relativement bien connu comme un coach en leadership et un prolifique auteur avec plus de 50 livres sur divers sujets de leadership. Il a un fort contexte Chrétien dans sa vie et dans son écriture, mais si vous n’êtes pas aussi enclins, ne laissez pas cela vous rebuter. Il maîtrise pleinement l’art du leadership.
Il y a quelques années il a publié un livre : Failing Forward—Turning Mistakes Into Stepping Stones to Success. Dans celui-ci, il souligne l’échec comme un facteur de réelle transformation dans nos vies personnelles, professionnelles et en équipes. Mais il place soigneusement l’échec dans une position d’avancée. Au lieu de voir l’échec comme un état final négatif et nous en plaindre, nous devrions l’embrasser comme une expérience à portée pédagogique positive. Que nous nous « penchions en avant » en démultipliant les leçons apprises pour nous améliorer.
Je ne pense pas que Maxwell souffle simplement un nuage de fumée positive dans notre direction. L’histoire est clairement encombrée d’exemples de succès qui ont été inspirés, forgés et durcis par le feu de l’échec. Thomas Edison en est un exemple célèbre quand il a persévéré pour inventer l’ampoule électrique.
Dans mon coaching agile j’utilise de manière consistante la terminologie « chuter en avant » quand je discute des échecs d’équipes. Oui, je veux qu’une équipe soit honnête avec elle-même et reconnaisse qu’elle a échoué. Mais je veux aussi que ses membres embrassent leurs erreurs au lieu de devenir défensifs, blâmer d’autres personnes ou être dans le plein déni. Et je veux que leur position les fasse se « pencher vers l’avant ». Désireux d’essayer quelque chose de nouveau qui amènera des résultats différents. Sans avoir peur de l’échec.
Je constate qu’en utilisant cette terminologie, j’aide des équipes à comprendre la nature de l’échec et à se comporter convenablement. Mais au-delà de la terminologie, les leaderships de projet et fonctionnel doivent aussi pleinement supporter l’idée. CE qui signifie que l’équipe de direction toute entière doit supporter l’échec. Voilà…je l’ai dit.
En conclusion – Mais, je suis un peu étrange …
Tout ceci étant dit, je me demande si j’ai une vue étrange et largement minoritaire envers l’échec ? Je me demande si la bonne réponse doit en effet de le craindre, de nier son existence, de passer d’innombrables heures à essayer de le prévoir, de ne jamais le mentionner en public. Est-ce que de telles actions sont les bonnes réponses ?
À cette fin, je ferme ce billet avec une requête auprès de tous les lecteurs. J’ai préparé une brève enquête, que je voudrais vous proposer. Je sais, je sais, vous êtes occupés. Mais je pense vraiment que vos idées seront ici utiles. L’enquête est centrée sur la construction d’une vue sur l’acceptation organisationnelle, de groupe/équipe et individuelle de l’échec et du risque. J’essaye d’obtenir à une compréhension profonde de cette acceptation et aussi de ses causes racines. Même si je suis particulièrement intéressé par les équipes agiles, ne laissez pas votre manque d’expérience agile vous empêcher de répondre.
Suite au retour d’informations reçu par le programme pilote et le Comité de pilotage PMI-ACP, le Conseil de Gouvernance de Certification a approuvé 3 mises à jour aux critères d’éligibilité pour la certification Agile Certified Practitioner de PMI (PMI-ACP). Cette certification reconnaît la connaissance d’un praticien des principes agiles, des pratiques, des outils et des techniques à travers les méthodologies agiles.
Le tableau suivant détaille les mises à jour qui sont entrées en vigueur le 26 mars 2012. Les candidats à la certification PMI-ACP devront respecter les critères d’éligibilité suivants :
Expérience Générale en Management de Projet
2,000 Heures Travail Sur des Équipes Projet
Ces heures doivent être cumulées sur les 5 dernières années
Tout PMP® et PgMP® actif satisfera ce pré-requis
Expérience en Management de Projet Agile
1,500 heures de travail sur équipes projet agiles ou avec méthodologies agiles
Ces heures viennent en supplément des 2,000 heures exigées dans « Expérience Générale en Management de Projet »
Ces heures doivent être cumulées sur les derniers 2 3 ans
Formation de Management de projet AgileFormation aux Pratiques Agiles
21 Heures
Les heures doivent être gagnées dans des pratiques agiles de chef de projet
Partenaire de DantotsuPM
Le changement « de l’expérience en management de projet » pour « expérience projet » clarifie le type d’expérience exigée. Alors que la description déclare que la certification n’est pas limitée aux chefs de projet, « l’expérience en management de projet » créait un peu de confusion en impliquant que nous exigions de l’expérience à manager des projets plutôt qu’à travailler sur des équipes projet.
La recherche PMI Pulse of the Profession indique que beaucoup d’organisations n’ont pas encore implémenté largement les pratiques agiles. Donc, pour encourager autant ‘d’adopteurs précoces’ que possible à atteindre l’expérience exigée, PMI met à jour le critère d’éligibilité aux 3 dernières années au lieu de 2.
Pour commencer à répondre à toute question et commentaire sur la mise à jour des critères d’éligibilité, nous avons préparé une Foire aux Questions en Anglais FAQ qui peut être trouvée sur la page PMI-ACP de PMI.ORG.
Si vous avez des questions supplémentaires, envoyez les s’il vous plaît par courrier électronique à Customercare@pmi.org.
Et voici un rappel en vidéo de ce qu’est Scrum en seulement 7 minutes.
partagez ce billet avec vos amis, collègues et relations professionnelles
DantotsuPM.com 