Tag Archives: lessons learned

connaissez-vous les 12 principes Agile qui accompagnent les 4 composantes majeures du « Agile Manifesto » ?

10 Jan

Il y a 12 principes directeurs en plus des 4 composants principaux du manifeste Agile, les connaissez-vous ?

Examining the Twelve Principles of Agile par The Clever PM

Beaucoup d’attention est portée au « Manifeste Agile » et bien qu’il soit une composante importante de Agile, ce n’en est pas toute la substance. Il y a 12 principes directeurs en plus des 4 composants principaux du manifeste. Jetons un rapide coup d’œil à chacun d’entre eux et voyons combien ils affectent comment nous percevons et implémentons les pratiques Agiles…

1. Notre priorité la plus haute est de satisfaire le client par la livraison rapide et continue de logiciel de valeur.

bonhom-serviceCeci est l’aspect le plus important d’Agile qui doit être compris et adopté comme une partie de la culture de toute organisation qui veut être « Agile » : le client et l’utilisateur final sont le focus ultime du processus tout entier, du commencement jusqu’à la fin. Le client est le juge du succès ou de l’échec d’un produit ou d’une fonctionnalité, pas la société ni ses parties prenantes. Le client est celui avec les problèmes que nous adressons et comme tel il doit être partie intégrante du processus de développement de produit du commencement à la livraison.

Ignorer vos clients jusqu’à ce que votre produit soit prêt à être expédié est l’anti-modèle Agile numéro 1 dans le monde.

2. Accueillez avec bienveillance les demandes d changement, même tard dans le développement. Les processus agiles exploitent le changement pour donner un avantage compétitif du client.

changementsLa deuxième partie la plus importante de Agile est en fait…  …de faire preuve d’agilité. N’importe quelle organisation qui investit lourdement dans la définition en amont, la conception et la définition des besoins n’est Pas Agile…et ne fait certainement pas preuve d’agilité. Tout le point de l’agilité est que vous pouvez vous accommoder d’importants changements de besoins à n’importe quel point du processus et toujours livrer quelque chose qui est utile pour le client et résout un ou plusieurs de leurs problèmes. Des processus agiles s’appuient sur la Priorisation et non par la Négociation de contrat pour atteindre le succès. Quand de nouveaux besoins surviennent, ils ne sont pas soumis à de lourds et détaillés processus de management des changements.  Ils sont plutôt ajoutés à la pile de tout le reste à faire et évalués tout simplement comme une autre tâche ou histoire utilisateur déjà dans le processus.

Ventura Asssociates est partenaire de DantotsuPM et le votre pour dénicher les ressources critiques en PM dont vous avez besoin

Ventura Asssociates est partenaire de DantotsuPM et le votre pour dénicher les ressources critiques en PM dont vous avez besoin

Penser que les choses sont totalement ou presque entièrement définies à l’avance est un autre anti-modèle Agile dont beaucoup de sociétés souffrent fréquemment.

3. Livrez souvent (entre deux semaines et deux mois) du logiciel qui fonctionne avec une préférence pour les fréquences les plus rapides.

scrumIl y a plusieurs choses dans ce principe. D’abord du logiciel qui marche est le but du processus à chaque étape, ensuite le travail devrait être itératif et s’améliorer à chaque livraison et, finalement les itérations qui sont engagées devraient être les plus courtes possible. Si vous travaillez sur un projet qui progresse pendant six mois sans vérifier les résultats intermédiaires avec le client (ou son représentant), vous n’êtes pas Agiles. Si vous travaillez sur des itérations d’une semaine, mais ne livrez pas quelque chose qui résout au moins un problème client à chaque itération, vous n’êtes pas Agiles. Les itérations agiles doivent être assez longues pour livrer un logiciel qui fonctionne et assez courtes pour vous assurer que ce que vous livrez résout bien dans les faits des problèmes clients.

CertYou est partenaire de DantotsuPM

CertYou est partenaire de DantotsuPM

Travailler itérativement ne signifie pas nécessairement que vous êtes Agiles; l’itération est importante, mais livrer un logiciel qui fonctionne l’est tout autant.

4. Les gens du métier et les développeurs doivent travailler ensemble quotidiennement pendant tout le projet.

collaborateLa collaboration et les interactions entre les gens sont critiques au succès de toute organisation Agile. Les silos et le « jeté de besoins par-dessus le mur » sont contre-productifs aux approches Agiles, comme l’est de segmenter votre organisation entre les gens « du métier/business » et les « techniciens ». Tout le monde du côté « métier/business » devrait être prêt, consentant et disponible pour fournir autant de support que possible aux équipes « techniques » et vice versa. L’idée séculaire qu’il y a une certaine différence inhérente entre la façon dont « l’activité business » devrait être exécutée et la façon dont « la technologie » devrait l’être est entièrement artificielle et contre-productive dans un âge d’innovation rapide et de livraisons encore plus rapides.

Décourager la collaboration ou encourager le « silotage » des efforts est un anti-modèle Agile qui persiste dans trop de cultures d’entreprise.

5. Construisez les projets autour de personnes motivées. Donnez-leur l’environnement et le support dont elles ont besoin et faites leur confiance pour faire le travail.

Agile valorise les personnes en tant que personnes et les équipes en tant qu’équipes. Les gens  ne sont pas des rouages interchangeables que vous pouvez aléatoirement déplacer d’un projet à un autre et vous attendre à ce qu’ils excellent continuellement. Les individus sont motivés par des choses différentes et dans une vraie approche Agile nous exploitons ce qui motive individuellement les membres de notre organisation pour créer des équipes avec ces individus motivés qui sont intrinsèquement motivés pour réussir. Agile déboute de l’idée que la récompense extrinsèque fournit des résultats exceptionnels et se concentre plutôt sur l’assurance que les individus aient la motivation, l’environnement et les outils dont ils ont besoin pour réussir tout seuls. Il n’y a aucune approche de type « la carotte et le bâton » dans Agile. Il y a des problèmes à résoudre pour les clients qui sont intéressants et fascinants et qui sont résolus par des personnes qui ont l’intérêt nécessaire et la motivation intrinsèque pour les résoudre.

NQI est Partenaire de DantotsuPM

NQI est Partenaire de DantotsuPM

Attendre des gens d’être performants simplement parce qu’ils sont membres « d’une équipe » et non pas parce que cette équipe partage la motivation intrinsèque de réussir est un anti-modèle extrêmement commun dans les grandes organisations.

6. La méthode la plus efficace et effective de transmettre des informations dans une équipe de développement est la conversation en face à face.

Business DiscussionLa méthode séculaire d’avoir un unique expert du sujet qui écrit tout qu’il veut avoir et le remet aux développeurs comme « une liste à exécuter » de besoins est hérétique aux approches Agiles. Des personnes différentes pensent et communiquent différemment et le texte écrit est l’une des pires façons d’exprimer que vous essayez de dire. Au pis-aller, c’est vague et difficile à déchiffrer pour la personne qui ne l’a pas écrit; au mieux, c’est un document clinique, stérile qui remplace le sentiment par la précision. Si le but est d’exprimer la douleur que ressent le client et motiver les équipes à exceller dans leur job parce qu’elles le veulent, alors aucune de ces approches par des besoins écrits n’aura le résultat que nous désirons. Nous utilisons plutôt des choses comme les Histoires Utilisateur, qui explicitent le problème que nous voudrions résoudre, mais qui permettent à notre équipe de développement d’utiliser sa créativité pour y répondre de la meilleure façon possible.

Même quand nous utilisons des outils pour suivre le travail et communiquer les informations les plus basiques, nous ne pouvons pas oublier que la façon la plus importante de communiquer l’un avec l’autre, indépendamment des rôles, est toujours la conversation en face à face.

7. Le logiciel qui marche est la principale mesure de progrès.

avis perso KPIsParticulièrement dans le monde des grandes sociétés, nous aimons le concept que tout peut être mesuré, évalué et KPIsé. Nous suivons les revenus, des points d’histoire, la vélocité, la consommation, les nombres d’erreurs découvertes, Ad Nauseum. Pourtant nous oublions souvent que ce que nous essayons vraiment de faire est résoudre des problèmes pour les clients. Et aucune de ces mesures n’indique combien de valeur nous apportons en réalité ni si nous résolvons vraiment des problèmes clients. Le but final de chaque itération devrait être du logiciel qui marche, qui fait quelque chose que nous pensons être de valeur. Sans cela, c’est un échec. Quoi que ce soit de plus que cela est du glaçage sur le gâteau. Les équipes Agile se mesurent elles-mêmes sur si elles apportent réellement de la valeur et si elles créent vraiment quelque chose qui marche la fin de chaque itération.

Répétons ceci : la vélocité n’est pas la mesure du progrès. La consommation n’est pas la mesure de progrès. Les points d’histoire ne sont pas la mesure de progrès. La capacité n’est pas la mesure de progrès. Les délais ne sont pas la mesure de progrès. La seule chose qui importe est combien vous créez de logiciel qui marche.

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

8. Les processus agiles font la promotion du développement durable. Les sponsors, les développeurs et les utilisateurs devraient pouvoir indéfiniment tenir une allure constante.

Voir les billets sur l'initiative ecoPMI

Voir les billets sur l’initiative #ecoPMI

Il y a cette idée fausse dans le monde, tenue tant par les développeurs que par des hommes d’affaires, que Agile signifie aucune documentation, que Agile veut dire faire quoi que vous ayez besoin de faire pour atteindre un but, que Agile signifie changer les priorités et équipes rapidement pour assurer une production maximale, que Agile rime avec imprévisibilité et manque de prédictibilité. Le fait est, l’un des buts principaux d’Agile est créer un environnement de prévisibilité, de stabilité et une allure constante et acceptable de développement de produits qui dure indéfiniment. Il n’y a rien dans les principes Agile qui écarte de créer des planning (quoique ces plans portent un peu d’incertitude !) ni d’être capable de prévoir quand quelque chose pourrait être livré. Au contraire, il n’y a rien dans les principes Agile qui s’attend à ce que des développeurs s’engagent dans des comportements de pression exagérée. En fait, de tels comportements sont de bien des façons antithétiques aux concepts Agiles : si votre équipe doit travailler beaucoup trop durement pour livrer quelque chose, vous avez manqué en amont à vos devoirs de priorisation efficace des Histoires Utilisateur.

Aucune vraie pratique Agile ne devrait aboutir à de l’épuisement, des périodes critiques, ni une incertitude constante et prolongée. Les anti-modèles aboutissent à ces comportements contradictoires.

9. L’attention continue à l’excellence technique et à la bonne conception améliore l’agilité.

good and badDes équipes vraiment agiles ne rassemblent pas à la va vite de mauvais morceaux de code pour l’appeler « bon ». Elles prennent le temps et mettent les efforts nécessaires pour comprendre ce qu’elles essayent de réaliser, comment elles pensent pouvoir résoudre les problèmes et décomposer les choses en assez petits « morceaux » de travail pour à la fois itérer sur le problème et livrer des solutions potentiellement exploitables à chaque étape du projet. La majorité de ce travail se produit avant que les équipes ne s’engagent à faire le travail. Il y a là du pré-travail pour parler approches, pour discuter architecture et s’engager dans des discussions avec des représentants du métier, des parties prenantes et les équipes techniques. Nous nous référons souvent à ceci comme à des sessions de démarrage ou de préparation d’arriéré de produit mais Agile ne devrait jamais être une excuse pour la mauvaise qualité ou une conception erronée.

La conception erronée et de faibles standards aboutissent à de pauvres solutions qui ne répondent pas vraiment aux besoins clients; c’est un facteur de ralentissement, pas un facteur d’accélération.

10. Simplicité, l’art de maximiser la quantité de travail non fait, est essentielle.

construction progressive. Chaque brique apporte de la valeur.Beaucoup trop de personnes lisent ceci de la mauvaise façon et limitent ainsi leur capacité à totalement s’engager dans des pratiques Agiles fortes. Simplifier vos buts, vos histoires, votre travail et tout le reste est un processus qui commence par l’opposé : une très large compréhension de ce que sont les buts et de comment ils pourraient être atteints. Le résultat de tels efforts n’est pas nécessairement un projet plus petit, mais des incréments plus petits et plus simples qui peuvent s’additionner en quelque chose de très grand et qui peuvent aussi indirectement réduire les buts globaux. Le plus grand obstacle est ici que le simple est plus difficile que le complexe, particulièrement quand les gens s’engagent dans des séances de remue-méninges, ce qui arrive souvent avec des équipes techniques. Résolvez le problème d’abord, itérez ensuite par petits morceaux.

« Rendez chaque détail parfait et limitez le nombre de détails à perfectionner. » Jack Dorsey

11. Les meilleures architectures, besoins et conceptions naissent d’équipes auto organisées.

teamingLe mot clé est ici « naissent ». Quand vous réunissez les bonnes personnes et que toutes sont alignées vers les mêmes buts, certaines choses se produisent. D’abord, elles se tiennent naturellement responsables, parce qu’il y a un sentiment intrinsèque de camaraderie et de but commun. Deuxièmement, Elles se supportent et en même temps se défient pour assurer que le résultat final respecte non seulement leurs attentes individuelles, mais aussi leurs attentes collectives qui sont presque toujours plus élevées. Et finalement, elles  améliorent le tout par la collaboration : la valeur de n’importe quelle équipe auto-organisée est au moins 2 fois plus importante que la somme de ses parties individuelles. Le facteur clé est ici auto-organisation, qui peut être dure à vendre dans beaucoup d’organisations, mais les meilleures équipes ne sont pas celles assemblées par un cadre intermédiaire, ce sont plutôt des groupes de personnes qui ont choisi de s’aligner vers un but commun.

Les personnes qui travaillent vers un but commun parce qu’elles le veulent seront toujours plus efficaces, plus fortes et plus fiables que des équipes travaillant ensemble parce qu’on leur a dit de le faire.

12. À intervalles réguliers, l’équipe réfléchit à comment devenir plus efficace, puis règle et ajuste son comportement en conséquence.

Get the book on Amazon

Get the book on Amazon

Dans presque chaque organisation que j’ai observée face au défi d’implémenter les pratiques Agile, la plus grande chose qu’elle loupe est l’importance de l’amélioration continuelle ou continue. Agile a ses origines dans des concepts industriels LEAN : la valeur de l’individu, la primauté du résultat sur le processus et, plus important encore, le besoin de constamment mesurer, ajuster et améliorer comment vous faites ce que vous faites. Toute équipe qui veut ne pas s’engager dans les rétrospectives et les revues d’équipe avec leurs parties prenantes après chaque itération risque la stagnation et les anti-modèles parce qu’elle ne les voit jamais arriver. Beaucoup d’équipes voient ces sessions comme contre-productives, des pertes de temps, des exercices « soft skills » qui consomment seulement de leur temps d’exécution. Mais la plupart des équipes les évitent simplement par crainte (et le rationalisent comme elles le peuvent): la crainte d’être sur la sellette, la crainte d’accepter la responsabilité, la crainte de changement. La vérité vraie est que quand elles sont exécutées correctement, elles peuvent être les réunions les plus enrichissantes dans lesquelles les équipes s’engageront. Elles sont destinées à pousser les gens à constamment s’améliorer et être plus efficaces et il n’y pas de bonne raison de ne pas s’engager dans ces discussions.

L’absence de « regarder derrière soi » profondément et honnêtement pour évaluer comment une équipe avance et où elle peut s’améliorer est un anti-modèle fatal au succès de Agile sur le long terme.

Enregistrer

Enregistrer

1 December – Basel – Learning from the best is the way to Project Excellence

21 Nov

Solutions are developed in project teams.

Image courtesy of Stuart Miles / FreeDigitalPhotos.net

Image courtesy of Stuart Miles / FreeDigitalPhotos.net

This event is organized by PMI® Switzerland.

Successful companies have changed their strategies towards providing solutions rather than selling products.

  • Products have been invented by single individuals or research departments.
  • Solutions are developed in project teams.

The sustainable success of a company does not depend on splendid inventions and on separate marketing departments but on an integrated and innovative approach towards solutions for the customers.

NQI est Partenaire de DantotsuPM

NQI est Partenaire de DantotsuPM

Project teams therefore hold a major significance in creating success for the company. They became the driver and leader of these solutions. The crucial question is, how can we prepare the ground for the continuous development of creative and better solutions and avoid routines?

Jürgen Ekert

Jürgen Ekert

Jürgen Ekert, Head of Project Office at Endress+Hauser, will explain how his office adapted the approach of Project Excellence and contributed to the success of the internationally operating company.

This session presents Project Excellence as a solution-oriented mindset for project managers. Easy applicable and effective tools as well as a modified communication leads to more adaptability and better performance of the project team.

PMI is a registered mark of Project Management Institute, Inc.

Enregistrer

Enregistrer

Enregistrer

Enregistrer

le redressement de projet nécessite des qualités et approches spécifiques chez le chef de projet

11 Oct

« Je ne crois pas que quelqu’un soit né sachant comment mener une équipe de projet vers le rétablissement et le succès », Rebecca Winston

J’avais publié ce billet il y a 6 ans et il me semble toujours autant d’actualité. Aussi me suis-je permis de le reprendre pour en améliorer la forme et clarifier certains messages clés.

Lessons from a Turn-Around PM billet de Rebecca Winston, JD, Past PMI Chair et PMI Fellow

magicCertaines des leçons que j’ai appliquées, je les ai apprises au prix d’un certain nombre de cicatrices et de l’observation d’autres de chefs de projet que j’ai rencontrés ou avec lesquels je suis en relation. Il n’y a aucune formule magique ni nec plus ultra; Seulement quelques leçons relativement simples qui démentent la difficulté avec laquelle elles sont mises en œuvre.

D’abord, je ne crois pas que quelqu’un soit né sachant comment mener une équipe de projet vers le rétablissement et le succès. Je ne suis pas ni n’ai rencontré non plus le chef de projet de redressement qui connaisse en fin de compte la réponse sur comment transformer un projet dysfonctionnel ou en échec. Cependant, j’ai appris de nombreuses leçons.

1. Croyez en vous.

business success self confidenceNotez bien que je n’ai pas dit croire que vous avez toutes les réponses parce que vous ne les avez pas. Mais vous devez croire sincèrement que vous pouvez faire le job. Si vous ne le croyez pas, qui devrait croire en vous, qui vous donnera une apparente confiance, un sens de la direction et un objectif ?

2. Ne dénigrez pas votre prédécesseur.

Vous faites face à plusieurs pièges si vous vous engagez dans la diffamation du chef de projet précédent. On ne sait jamais qui dans l’équipe peut être leur ami et peut répéter vos déclarations à l’ancien chef de projet. Certaines de ces déclarations peuvent être vraies, d’autres peuvent seulement refléter votre opinion et certaines peuvent s’avérer ne pas être correctes. Vous ne connaissez pas tous les problèmes auxquels s’est confronté le précédent chef de projet. Tout que vous avez sont vos impressions et observations, toutes deux vues par vos yeux et non pas les siens au moment où ils les exécutaient.

De plus, critiquer le chef de projet précédent devant ses pairs peut vous couper d’un précieux réseau. Vous pouvez avoir besoin des autres chefs de projet dans l’organisation pour tester vos idées, questionner la signification et la mise en œuvre de procédures internes, découvrir comment supprimer des points de blocage connus et autres sujets. Beaucoup de ces chefs de projet peuvent vivre dans la crainte d’être les prochains éliminés s’ils trébuchent sur leurs projets.

Oh et n’oubliez pas que la personne qui est votre manager peut avoir été le manager du précédent chef de projet. Il peut même l’avoir embauché. Critiquer le chef de projet précédent peut mettre en doute leur bon jugement.

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

3. Soyez focalisé sur faire avancer le projet.

ProgressLa plupart des chefs de projet n’ont pas d’yeux derrière la tête. Les yeux servent à regarder, soit vers l’avant, soit derrière soi. Regarder derrière soi ne change pas le projet et peut vous empêcher de trouver les solutions nécessaires pour résoudre les problèmes. Cela peut aussi vous condamner à revivre dans les risques du passé.

Bien sûr, il faut comprendre ce qui s’est passé et les indicateurs précédents, mais rester dans ce mode ne permet pas à l’équipe d’avancer. En matière de leadership, l’équipe de projet va suivre le chef de projet qui avance sans faire de blocage sur le passé.

4. Croyez en l’équipe.

équipe projet/businessNe commencez pas par remplacer des membres de l’équipe par des personnes avec lesquelles vous vous sentez à l’aise. Assurez-vous de bien analyser votre équipe et de lui donner du temps. Les changements causent une mise en doute de l’équipe et les membres restants peuvent devenir moins productifs qu’ils ne l’étaient ou ne pourraient l’être.

Vous, en tant que chef de projet, devez comprendre que, alors que vous vous sentez à l’aise avec de certains individus, le défi d’accroître le pool des talents avec lesquels travailler est plus important. Ils apporteront de nouvelles idées, une perspicacité de projet, la compréhension des risques tant antérieurs que futurs. Certains peuvent avoir des connexions avec des sponsors, des clients, des fournisseurs et autres personnes nécessaires au succès du projet.

Essayez Bubble Plan !

Essayez Bubble Plan !

5. Ayez un plan.

successLa leçon 5 est quelque chose de familier pour la plupart des chefs de projet : avoir un plan. Le plan devrait avoir reçu les avis de l’équipe de projet comme tout plan de projet, mais il devrait être vendu comme le plan vers le succès. Une communication positive est exigée. Le martelage du manque de réussite ou de progrès passés ne réunira pas l’équipe autour de l’esprit de succès. Tant vous-même que l’équipe devez croire que le succès peut être atteint et qu’il le sera dans les paramètres donnés pour le projet.

6. Renégociez.

Vous êtes nouveau et avez de nouveaux besoins, peut-être quelques nouveaux prérequis, ou de nouvelles parties prenantes. N’ayez pas peur de soumettre des demandes de renégociation. Elles peuvent être conduites selon des styles différents, des besoins de communication différents, et avec une compréhension des leçons qui ont été apprises jusqu’à présent sur le projet.

Méta Projets Management est partenaire de DantotsuPM

Méta Projets Management est partenaire de DantotsuPM

7. Communiquez, communiquez et communiquez encore un peu plus !

bonhom-courrierPeut-on le répéter suffisamment ?

Voici une leçon du management de projet en général, mais qui devient encore plus nécessaire dans un projet de rétablissement.  Des parties prenantes diverses, incluant les membres de l’équipe, devront être rassurées. Elles devront recevoir plus d’informations au moins pendant quelque temps, une meilleure compréhension des risques et des stratégies de management et d’autres sujet sur lesquels elles peuvent vouloir fournir des informations. De temps en temps, on peut estimer que le chef de projet sur-communique. Ce besoin de sur-communication peut diminuer avec le temps et en fonction du temps restant pour terminer le projet.

8. Soyez créatif.

Le chef de projet de redressement ne peut pas toujours compter ce qu’il a fait dans le passé. Il devra créer de nouveaux rapports, délivrer ces rapports de nouvelles manières, construire un esprit d’équipe différent, utiliser de nouveaux canaux de communication, ou stimuler l’équipe à être plus créative et innovatrice. Parfois cela peut être aussi simple que de ne pas amener des croissants pour la réunion d’équipe, mais de fournir à la place un jambon-beurre au petit-déjeuner. Le bruit créé par un changement aussi simple peut mener à une conversation qui rende le nouveau chef de projet plus réel.

inciter-l-equipe-a-etre-plus-creative-et-innovatrice9. Restez en contact avec votre réseau.

networkBien sûr, cette recommandation s’applique à tout chef de projet, mais je l’ai trouvée encore plus importante en menant un projet de redressement.  Vous aurez besoin d’une caisse de résonance. Il y aura des jours sombres et énervants; des jours où vous sentirez que vous serez le prochain chef de projet à ne pas trouver le chemin vers l’objectif. Votre réseau personnel vous écoutera, vous encouragera et vous offrira peut-être des solutions que vous pourrez vous approprier et utiliser.

10. Ne pensez pas que ce projet sera comme le précédent.

De nouveau une leçon générale de management de projet, mais qui prend une nouvelle signification sur un projet à redresser.  Certains aspects peuvent être similaires, mais ces projets n’incluaient pas cette équipe projet, les risques qui ont été rencontrés et leurs impacts, ou les parties prenantes, pour n’en citer que quelques-uns. Déclarer que ce projet est comme un autre que vous avez récemment réalisé transmet à l’équipe un manque de singularité de leur projet et les fera se questionner sur pourquoi ils ont échoué. Hors, les faire se mettre en cause personnellement plus qu’ils ne le font déjà est contre productif.

de bons outilsIl y a ici beaucoup de leçons. Nombre d’entre vous en transportent déjà d’autres dans leurs bagages de PM. J’espère que certaines de celles mentionnées ici peuvent être ajoutées à votre boîte à outils.

De même qu’un chef de projet devrait toujours être en mode apprentissage, votre boîte à outils devrait être en enrichissement permanent.

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

un mot et un seul pour démarrer vos rétrospectives #Agile…

9 Sep

One Word

post ithttp://www.funretrospectives.com/one-word/

La technique « Un Mot » est un contrôle simple dans l’activité qui permet aux participants de partager leurs sentiments avant d’entrer dans les données et détails de la réunion en elle-même. C’est une bonne ouverture pour une réunion car elle reconnaît les sentiments des personnes et les fait parler dès le début.

Get the book on Amazon

Get the book on Amazon

Déroulé de l’activité

  1. Donnez à chaque participant un marqueur et un post-it
  2. Demandez-leur de décrire leur sentiment (dans le contexte de la réunion) en un mot
  3. Groupez les notes sur une grande page
  4. Optionnellement, demandez si quelqu’un veut en dire plus sur leur mot choisi

Décrivez s’il vous plaît < le dernier sprint ou le mois passé ou vos sentiments sur XYZ > en un mot !

Cette activité est décrite comme un Activité de Checkin par Esther Derby Et Diana Larsen dans leur remarquable livre Agile Retrospectives book.

à la lecture de ce billet, quel mot écririez-vous sur votre post-it, quel sentiment vous inspire-t-il ?

Microsoft est partenaire de DantotsuPM

Microsoft est partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

Enregistrer

le redressement de projets en 10 leçons

28 Juin

« Je ne crois pas que quelqu’un soit né sachant comment mener une équipe de projet vers le rétablissement et le succès » Rebecca Winston

Lessons from a Turn-Around PM billet de Rebecca Winston, JD, Past PMI Chair et PMI Fellow

magicCertaines des leçons que j’ai appliquées, je les ai apprises au prix d’un certain nombre de cicatrices, et de l’observation d’autres de chefs de projet que j’ai rencontrés ou avec lesquels je suis en relation. Il n’y a aucune formule magique ni nec plus ultra; Seulement quelques leçons relativement simples qui démentent la difficulté avec laquelle elles sont mises en œuvre.

D’abord, je ne crois pas que quelqu’un soit né sachant comment mener une équipe de projet vers le rétablissement et le succès. Je ne suis pas ni n’ai rencontré non plus le chef de projet de redressement qui connaisse en fin de compte la réponse sur comment transformer un projet dysfonctionnel ou en échec. Cependant, j’ai appris de nombreuses leçons.

Première leçon : Croyez en vous.

yes you canNotez bien que je n’ai pas dit croire que vous avez toutes les réponses parce que vous ne les avez pas. Mais vous devez croire que vous pouvez faire le boulot. Si vous ne le croyez pas, qui devrait croire en vous, qui vous donnera une apparente confiance, un sens de la direction et un objectif ?

Seconde leçon : Ne dénigrez pas le précédent chef de projet.

Vous faites face à plusieurs pièges si vous vous engagez dans la diffamation du chef de projet précédent. On ne sait jamais qui dans l’équipe peut être leur ami et pourrait répéter vos propos à l’ancien chef de projet. Certaines de ces déclarations peuvent être vraies, d’autres peuvent seulement refléter votre opinion et certaines peuvent s’avérer erronées. Vous ne connaissez pas tous les problèmes auxquels s’est frotté le précédent chef de projet. Tout que vous avez sont vos impressions et vos observations, toutes deux perçues par vos yeux et non pas les leurs au moment où ils les exécutaient.

De plus, critiquer le chef de projet précédent devant ses pairs peut vous couper d’un précieux réseau. Vous pouvez avoir besoin des autres chefs de projet dans l’organisation pour tester vos idées, questionner la signification et la mise en œuvre de procédures internes, découvrir comment supprimer des points de blocage connus et autres sujets. Beaucoup de ces chefs de projet peuvent vivre dans la crainte d’être les prochains éliminés s’ils ont des difficultés sur leurs projets.

Oh et n’oubliez pas que la personne qui est votre manager peut avoir été le manager du précédent chef de projet. Il peut même l’avoir embauché. Critiquer le chef de projet précédent peut revenir à mettre en doute leur bon jugement.

MPM est Partenaire de DantotsuPM

MPM est Partenaire de DantotsuPM

Troisième leçon : Gardez toute votre attention sur faire avancer le projet.

La plupart des chefs de projet n’ont pas d’yeux derrière leur tête. Les yeux servent à regarder soit vers l’avant, soit derrière soi (pas les deux en même temps). Regarder derrière soi ne change pas le projet et peut en fait vous empêcher de trouver les solutions nécessaires pour résoudre les problèmes. Cela peut aussi vous condamner à revivre dans les risques du passé.

Bien sûr, il faut comprendre ce qui s’est passé et les indicateurs précédents, mais rester dans ce mode ne permet pas à l’équipe d’avancer.

En matière de leadership, l’équipe de projet doit suivre le chef de projet qui avance sans se bloquer sur le passé.

Leçon 4 : Croyez en équipe.

équipe projet/businessNe commencez pas par remplacer des membres de l’équipe avec des personnes avec lesquelles vous vous sentez plus à l’aise. Assurez-vous de faire votre analyse d’équipe et de lui donner du temps. Les changements causent une mise en doute de l’équipe et les membres restants peuvent devenir moins productifs qu’ils ne l’étaient ou ne pourraient être.

Vous, comme chef de projet, devez comprendre que, alors que vous vous sentez à l’aise avec de certains individus, le défi d’accroître la base des talents avec lesquels travailler est important. Ils apporteront de nouvelles idées, une perspicacité de projet, la compréhension des risques tant antérieurs que ceux à venir. Certains peuvent avoir des connexions avec des sponsors, des clients, des fournisseurs et d’autres personnes nécessaires au succès du projet.

Leçon 5 : Ayez un plan. (quelque chose de familier pour la plupart des chefs de projet)

suivre la bonne directionLe plan devrait avoir reçu les avis de l’équipe de projet comme tout plan de projet, mais il devrait être vendu comme le plan vers le succès.

Une communication positive est exigée. Le martelage du manque de réussite ou de progrès passés ne réunira pas l’équipe autour de l’esprit de succès. Tant vous-même que l’équipe devez croire que le succès peut être atteint et qu’il le sera dans les paramètres donnés pour le projet.

Leçon 6 : Renégociez.

négocier et renégocierVous êtes nouveau et avez de nouveaux besoins, peut-être quelques nouveaux prérequis, ou de nouvelles parties prenantes.

N’ayez pas peur d’exercer des demandes de renégociation.

Elles peuvent être conduites selon des styles différents, des besoins de communication différents, et avec une compréhension des leçons qui ont été apprises jusqu’à présent sur le projet.

Leçon 7 : Communiquez, communiquez et communiquez encore un peu plus

Une leçon du management de projet en général, mais qui devient encore plus nécessaire dans un projet de rétablissement. Communiquez, communiquez et communiquez encore un peu plus — peut-on le répéter suffisamment ?

Des parties prenantes diverses incluant les membres de l’équipe devront être rassurées, devront recevoir plus d’informations au moins pendant un peu de temps, une meilleure compréhension des risques et des stratégies de traitement et d’autres sujet sur lesquels ils peuvent vouloir fournir des données.

De temps en temps, on peut estimer qu’ils sur-communiquent. Le besoin de sur-communication peut se réduire dans le temps selon combien il reste de temps pour terminer le projet.

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

Leçon 8 : Soyez créatif.

croissant jambon beurreLe chef de projet de redressement ne peut pas toujours compter ce qu’il a fait dans le passé. Il devra créer de nouveaux rapports, délivrer ces rapports de nouvelles manières, construire un esprit d’équipe différent, utiliser de nouveaux canaux de communication, ou stimuler l’équipe à être plus créative et innovatrice. Parfois cela peut être aussi simple que de ne pas amener des croissants pour la réunion d’équipe, mais de fournir à la place un jambon-beurre au petit-déjeuner. Le bruit créé par un changement aussi simple peut mener à une conversation qui rende le nouveau chef de projet plus réel.

NQI est Partenaire de DantotsuPM

NQI est Partenaire de DantotsuPM

Leçon 9 : Restez en contact avec votre réseau.

network of peopleElle s’applique à tout chef de projet, mais je l’ai trouvé encore plus importante en menant un projet de redressement. Restez en contact avec votre réseau. Vous aurez besoin d’une caisse de résonance. Il y aura des jours sombres et irritants; des jours où vous sentirez que vous serez le prochain chef de projet à ne pas trouver le chemin.

Votre réseau personnel vous écoutera, vous encouragera et vous offrira peut-être des solutions que vous pourrez utiliser et vous approprier.

Leçon 10 : Ne pensez pas que ce projet sera comme le précédent.

De nouveau une leçon générale de management de projet, mais elle prend une nouvelle signification sur un projet de redressement. Ne pensez pas que ce projet sera comme le précédent.

Quelques aspects peuvent l’être, mais beaucoup n’incluent pas cette équipe projet, les risques qui ont été rencontrés et leurs impacts, et les parties prenantes, pour n’en nommer que quelques-uns. Déclarer que ce projet est comme un autre que vous avez récemment réalisé transmettra à l’équipe un manque de singularité de leur projet et les fera se questionner sur pourquoi ils ont échoué. Les faire se mettre en cause eux-mêmes plus qu’ils ne le faisaient déjà est non productif.

toolsVotre boîte à outils doit s’enrichir en permanence.

Il y a ici beaucoup de leçons et nombre d’entre vous en ont déjà d’autres dans leurs bagages de chefs de projets. J’espère que certaines de celles commentées ici peuvent être ajoutées à votre boîte à outils.

De même qu’un chef de projet devrait toujours être en mode apprentissage, votre boîte à outils devrait être en croissance permanente.

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

l’indice de Bonheur est un outil à connaitre pour les rétrospectives Agile

13 Juin

Happiness Index – agile retrospective tool

Book on Amazon

Book on Amazon

http://blog.oikosofy.com/happiness-index-agile-retrospective-tool/

Peu importe combien votre équipe est performante, il y a toujours une opportunité d’amélioraation. L’indice de bonheur est un outil des rétrospectives agile, qui mesure le bonheur des équipes agiles. Luis Gonçalves le partage dans le livre écrit avec Ben Linder « Getting Value out of Agile Retrospectives. »

Cet exercice est une combinaison de « Développez une chronologie » et « Sismographe émotionnel » de Normand L. Kerth.

Que pouvez-vous tirer de cette technique ?

Le but de cet exercice est d’avoir une représentation graphique des émotions des membres de l’équipe pendant un Sprint. Ce type d’informations aide l’équipe à identifier ce qui affecte sa performance pendant le Sprint. Indépendamment du problème qu’expérience l’équipe, cet exercice les aide à révéler les émotions d’équipe directement en cet endroit.

Quand utiliseriez-vous cette technique ?

C’est certainement approprié pour une équipe qui passe à travers beaucoup d’émotions différentes (positives ou négatives) pendant un sprint. Cela leur bénéficie quand ils veulent en évaluer les conséquences ou quand l’équipe a plusieurs défis dans le Sprint et voudrait comprendre comment ces problèmes sont apparus.

L’indice de bonheur est approprié pour n’importe quelle équipe. Il n’exige pas de niveau de maturité spécifique. L’exercice peut être appliqué tant aux équipes à distance qu’à celles réunies en un même lieu.

Comment le réaliser ?

Prenez une page blanche A4 et quelques post-it. Divisez le papier sur 2 parties/axe – positif et négatif. Graduez ensuite l’axe des abscisses en fonction des jours de sprint.

indice bonheurIl y a 2 façons de conduire l’exercice

équipe en face à faceOption 1 : L’exercice est fait pendant la rétrospective avec toute l’équipe

Créez de petits groupes de 2-3 personnes. Demandez-leurs de faire une session de brainstorming sur les événements ou les situations qui se sont produites pendant le dernier sprint. Ensuite, demandez aux groupes de créer une représentation graphique des niveaux émotionnels pour les situations sur lesquels ils ont fait du brainstorming. Quand tous les groupes ont terminé, compilez une représentation de tous les groupes sur un seul graphique. N’oubliez pas de mettre une explication sur chaque émotion différente.

intérêtOption 2 : L’exercice est réalisé par petits bouts pendant le sprint

Au lieu d’une équipe dessinant le graphique émotionnel, vous laissez chaque individu dessiner un graphe avec son propre niveau d’émotion à la fin de chaque journée de travail. Cette approche permet de s’assurer que tous les événements ou situations sont couverts et aucun n’est oublié.

Les deux options marchent bien!

Vous aurez une belle vue de ce qui est arrivée pendant le sprint. Ces informations aident le facilitateur de la rétrospective dans l’identification des situations qui devraient être répétées et des événements qui causent des problèmes ou le retard de l’équipe.

Microsoft est partenaire de DantotsuPM

Microsoft est partenaire de DantotsuPM

De plus, vous pouvez aussi utiliser des techniques d’analyse de cause racine pour identifier les problèmes fondamentaux.

les articles les plus lus sur DantotsuPM en Octobre 2015

30 Déc

le job et les compétences du chef de projet

PMI Talent TriangleNew PMI Talent Triangle ! Download this new resource to learn more about the PMI Talent Triangle.

Mieux se connaitre pour mieux manager les Projets !

Vous vous demandez quel impact a votre personnalité sur le management des projets ?

nouvelle référence du management des ressources dans les organisations matricielles

Microsoft Project 2016 : nouvelle référence du management des ressources dans les organisations matricielles par Campana & Schott

Microsoft est Partenaire de DantotsuPM

Microsoft est Partenaire de DantotsuPM

qu’utilisez-vous pour documenter les Rôles et Responsabilités des membres de l’équipe ?

La RAM, Responsibility Assignment Matrix, ou Matrice d’Affectation des responsabilités (dont le RACI est un exemple) sert à documenter les rôles et responsabilités de chacun dans le projet.

skills-for-lifeQue trouve-t-on dans un plan de management des ressources humaines d’un projet ou programme ?

Si l’on vous pose cette question lors d’un entretien de recrutement ou bien si vous vous la posez au lancement d’un nouveau projet, voici quelques éléments constitutifs importants.

Project Management Skills for Life® maintenant disponible en Français !

Retours d’expérience en management de projet

Pourquoi les personnes se sentent-elles si misérables et désengagées au travail ?

Trop de règles et trop peu de coopération…

animal-green-frog-mediumconnaissez-vous l’histoire de la toute petite grenouille ?

Il était une fois un groupe de grenouilles minuscules qui avaient prévu une compétition. Le but était d’atteindre le sommet d’une tour…

l’importance de la communication non verbale dans les projets !

Même si nous n’en sommes souvent pas conscients, nous l’utilisons tous les jours. Dans le domaine professionnel, elle joue un rôle très important. C’est pour cela qu’il est important d’apprendre à bien décoder les expressions du visage, les gestes, etc.

complexitéque se passe-t-il si votre nouveau projet nécessite vraiment « d’avoir fait polytechnique » ?

Félicitations – on vient de vous donner l’occasion de manager un projet très novateur – si unique, en fait, que rien de semblable n’a jamais été essayé par votre organisation !

Agilité

un marshmallow, des spaghetti, quelques cm de ruban adhésif et de ficelle pour beaucoup de créativité et de teambuilding

En fait, c’est la méthode qui importe le plus et dans le cas de cette exercice, une approche Agile basée sur des expérimentations rapides et répétées pour trouver la meilleure piste et l’exploiter pleinement.

speed boatconnaissez-vous la technique du Speed Boat pour les rétrospectives Scrum et sessions sur les leçons apprises?

Ce principe se matérialise en scrum par un cérémonial qui a lieu à chaque fin d’itération et que l’on nomme la rétrospective.

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

Vidéo

connaissez-vous la technique du Speed Boat pour les rétrospectives Scrum et sessions sur les leçons apprises?

22 Oct

Ce principe se matérialise en scrum par un cérémonial qui a lieu à chaque fin d’itération et que l’on nomme la rétrospective.

speed boat1. Dessin pour guider la session
  • Le bateau = l’équipe
  • Le vent = les éléments qui ont facilité ou facilitent la progression du projet
  • L’ile = les objectifs à atteindre
  • Les ancres = les freins qui empêchent d’atteindre l’ile et donc les objectifs
2. Remplissage de l’ile / les objectifs (de et par chaque participant sur des Post-It)
3. Les vents / ce qui a facilité le travail (de et par chaque participant sur des Post-It)
4. Les ancres / ce qui a ralenti la progression, les difficultés (de et par chaque participant sur des Post-It)
5. Regroupement par le ScrumMaster/Facilitateur
6. Sélection de quelques sujets sur lesquels engager des actions d’amélioration, rédaction des actions et affichage à la vue de tous.
7. Suivi des actions lors de la rétrospective suivante

Article complet en français sur cette méthode : http://coach-agile.com/speed-boat/

Merci à Élodie Descharmes de m’avoir parlé de cet outil 🙂

Partenaire de DantotsuPM

Partenaire de DantotsuPM

adoptez une étoile de mer pour des rétrospectives Agile plus amusantes et productives

28 Sep

Starfish – http://www.funretrospectives.com/starfish/

L’ »étoile de mer » est une excellente activité lors de la collecte de données pour favoriser la réflexion autour des pratiques et de la valeur que l’équipe en retire. Elle aide des membres de l’équipe à comprendre la valeur perçue par chacun sur ces pratiques.

L’étoile de mer divise le tableau blanc en 5 zones :

  • Continuez à Faire – quelque chose que l’équipe réussit bien et dont vous reconnaissez la valeur.
  • Moins de – quelque chose de déjà fait; vous y constatez une certaine valeur, mais vous souhaitez le réduire un peu.
  • Plus de – quelque chose de déjà fait; et dont vous pensez qu’elle apportera encore plus de valeur si davantage utilisée.
  • Arrêter de Faire – quelque chose qui n’apporte pas de valeur, ou encore pire, qui empêche de progresser.
  • Commencer à Faire – une nouvelle idée, ou quelque chose vous avez vu marcher auparavant et que vous voudriez mettre sur la table de discussion.

Ci-dessous est un exemple d’étoile de mer (billet original de Coup Kua)

etoile 1Voici un exemple de rétrospective de Sprint d’une petite d’équipe. D’abord l’équipe écrit les notes: les billets bleus.

etoile 2Puis l’équipe discute vraiment de chaque note et ajoute les mesures à prendre: les billets jaunes.

etoile 3Simple et efficace ?

à vous d’en juger… et de laisser vos retours d’expérience dans les commentaires ci-dessous pour les autres lecteurs !

Partenaire de DantotsuPM

Partenaire de DantotsuPM

améliorez vos réunions en seulement 5 minutes

21 Sep

Improve your meetings

http://www.growingagile.co.za/2015/07/improve-your-meetings/ par Sam Laing

Combien de fois prenez-vous 5 minutes après une réunion ou une session de formation pour réfléchir à ce qui s’est produit ?

WAprès chaque réunion ou atelier que nous avons avec un client, nous parlons de ce qui est arrivé et prendre du recul. Nous nous demandons quelles sont les choses qui ont bien marché et pourquoi. Nous parlons des choses qui sont allées de travers et essayons de comprendre pourquoi. Ces 5 à 10 minutes sont magiques. Nous y faisons une rétrospection sur comment nous performons comme facilitateurs, formateurs et coach et inventons des façons de nous améliorer.

Quand une session va mal, les gens ont tendance à parler de quoi changer pour la prochaine fois. Mais qu’en est-il d’une réunion moyenne ou vraiment excellente ? Combien de personnes prennent le temps de se demander pourquoi ? Je me demande ce qui pourrait arriver si nous tous le faisions systématiquement ?

Alors, voici le défi que je vous lance : Pendant une semaine, planifiez 5 à 10’ dans votre agenda APRÈS CHAQUE réunion.

réunionPensez aux questions suivantes et notez une idée ou deux sur la façon d’améliorer une telle réunion la prochaine fois.

1) Est-ce que la réunion était de valeur ? Pourquoi ou pourquoi pas ?

2) Avez-vous prêté attention tout le temps ? Pourquoi ou pourquoi pas ?

3) Tous les autres participants ont-ils prêté attention tout le temps ? Pourquoi ou pourquoi pas ?

4) Quelles parties de la session étaient les meilleures ? Pourquoi ?

5) Quelles parties paraissaient au contraire maladroites ou étranges ? Pourquoi ?

Partenaire de DantotsuPM

Partenaire de DantotsuPM

%d blogueurs aiment cette page :