Tag Archives: lessons learned

Les 3 petits cochons et les rétrospectives #Agiles amusantes

21 Août

Three Little Pigs

http://www.funretrospectives.com/three-little-pigs/ par Steve Wells

Les trois petits cochons sont une activité de rétrospective amusante qui utilise l’histoire des 3 petits cochons pour favoriser une conversation sur les améliorations pour obtenir de plus solides structures.

Animation de l’activité

1. Dessiner et expliquer aux participants les 3 colonnes :
  • La maison de paille – que faisons-nous qui tient à peu près debout, mais pourrait se renverser à tout moment ? (Par exemple « notre script de déploiement est très manuel et prône à l’erreur : nous pourrions très facilement casser la plateforme de production « )

 

  • La maison de bois – que faisons-nous qui est assez robuste, mais pourrait être amélioré ? (Par exemple « nos tests automatisés sont assez bons, mais parfois ils échouent sans raison et nous devons les exécuter à nouveau, ce qui est source de douleur »)

 

  • La maison de briques – que faisons-nous qui est solide comme un roc ? (Par exemple « notre déploiement automatisé et mise en production n’ont jamais échoué. Ça roule. « )
2. Demander aux participants de partager leur idées sur des post-it et de les placer dans l’une des trois colonnes

 

3. Filtrer et discuter en groupe sur les mesures à prendre.

Cette activité a été partagée par Steve Wells. C’est une activité géniale et amusante, particulièrement quand elle met en scène un bon dessin des trois cochons avec leurs maisons.

Microsoft est partenaire de DantotsuPM

Enregistrer

Enregistrer

3 choses que vous devriez faire avant que (ou quand) quelqu’un ne quitte votre projet

17 Août

Il y a trois choses que vous devriez faire avant que n’importe quel membre de l’équipe ne parte.

There are three things which you should do before any team member departs.

https://kbondale.wordpress.com/2016/05/15/three-things-you-should-do-when-a-team-member-leaves-your-project/ par Kiron Bondale

Kiron D. Bondale

Kiron D. Bondale

Nous commençons nos projets avec une petite équipe principale, la « core team », mais comme nous nous enfonçons de plus en plus dans le projet, nous ajoutons des membres à l’équipe pour supporter des activités de planification et de livraison. Alors comme des pans de travail sont complétés, la taille d’équipe se réduit jusqu’à ce que nous atteignions la clôture de projet et revenions à l’équipe principale de départ. Sur de grands projets, à phases multiples, l’expansion et la contraction d’équipe arrivent fréquemment, mais même avec des projets beaucoup plus petits, il est commun que des membres de l’équipe partent avant que le projet lui-même ne soit complété. Parfois, ceci pourrait être le résultat de la complétude des activités leur étant assignées, mais ce peut aussi être causé par des facteurs externes comme leur réquisition par un projet plus prioritaire ou une décision financière de déplacer leur tâches vers une ressource moins onéreuse.

1. Reconnaissez-les publiquement

J’espère que ce n’est pas la première fois que vous aurez l’occasion de le faire, mais il est particulièrement critique que vous les remerciez publiquement en vous référant à leurs accomplissements spécifiques avant qu’ils ne quittent le projet. Ceci garantira qu’ils partiront sur une note positive et manifestera aussi à l’équipe que vous êtes conscients du travail acharné qu’ils fournissent.

Si les budgets et la politique de l’organisation le permette, remettez une carte cadeau au membre de l’équipe sur le départ ou un autre petit témoignage de remerciement avec une carte de félicitations signée par l’équipe entière. Vous pourriez aussi envisager d’envoyer un mot de remerciement à leur manager pour renforcer la relation positive que vous voudriez construire avec cette partie prenante et fournir des éléments pour l’évaluation de performance du membre de l’équipe.

2. Sollicitez leur retour d’information

Ma première remarque sur les leçons de projet est que dans beaucoup d’organisations nous attendons jusqu’à la fin d’un projet pour acquérir cette connaissance. Ce jalon pourrait arriver des mois après qu’un membre de l’équipe soit parti avec des leçons potentiellement de grande valeur dans leurs bagages!

Prenez le temps de demander au membre de l’équipe quelle a été leur expérience pour entrer sur le projet, ce qu’ils ont aimé ou pas dans leurs tâches et s’il y avait une chose qu’ils voudraient voir changer dans les pratiques de travail de l’équipe quelle serait-elle. En sollicitant ces informations pendant que le projet est en cours vous avez l’occasion d’éliminer des obstacles qui pourraient être irritants pour d’autres membres de l’équipe.

3. Facilitez le transfert de connaissance

Combien de fois avez-vous quitté un projet en cours seulement pour vous retrouver rappelé pour fournir des jours ou même des semaines de support par la suite ? Ceci est le plus souvent causé par une pauvre planification et exécution de la transition.

Nous avons tendance à penser à la planification de la transition quand un membre de l’équipe part avant que son travail assigné n’ait été complété, mais même quand quelqu’un part après que son périmètre ait été délivré, il y a toujours besoin de passer ses connaissances à un autre membre de l’équipe ou à l’équipe dans son ensemble. Ceci pourrait inclure la connaissance d’où leurs produits et autres livrables sont stockés, le transfert des contrôles d’accès à leurs  documents à d’autres et les listes de contact de toutes les parties prenantes ou experts du sujet à l’extérieur de l’équipe projet avec lesquels ils avaient été fréquemment en relation.

La clôture d’une phase ou du projet entier implique d’habitude une certaine formalité lorsqu’il s’agit de faire passer à l’équipe la dernière phase de l’échelle de Tuckman.

Mais quand les membres de l’équipe quittent nos projets en milieu de phase, nous devrions exécuter les trois tâches de transition ci-dessus afin d’éviter les conséquences du risque mentionné par Dave Mustaine

 » Passer à autre chose est une chose simple, ce qui reste derrière est difficile. « 

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

Enregistrer

Enregistrer

Enregistrer

Enregistrer

vos préférés de Mai 2017 parmi les articles publiés sur DantotsuPM

7 Août

les articles les plus lus sur DantotsuPM de Mai 2017

Ce mois-ci furent plébiscités les trucs permettant d’être les plus productifs possible en tant que chefs de projets.

3 questions anti-gaspi de notre temps !

Le test « ceci mérite-t-il mon temps ? »

3 techniques pour éviter que des retardataires ne viennent mettre à mal l’efficacité de votre réunion

Peu importe à quel point vous avez travaillé pour bien préparer votre réunion, certaines choses peuvent mal tourner.

Une des perturbations plus communes concerne l’arrivée en retard de certains participants.

CSP est partenaire de DantotsuPM

quelles sont les 6 étapes pour réussir une bonne transmission de projet à son successeur ?

Une transmission de projet réussie exige bien plus que de remettre les clés et les informations de connexion au nouveau chef de projet. Un chef de projet devrait suivre ces six étapes pour compléter avec succès la transmission de son projet.

13 règles simples pour devenir un super vendeur de votre projet ou de votre initiative

Cet article, au départ écrit pour des entrepreneurs, recèle quelques conseils tout aussi utiles pour les chefs de projet.

Le livre sur Amazon

En effet, nous sommes souvent confrontés à la nécessité de « vendre » notre projet aux membres de nos équipes, à nos diverses parties prenantes et au management. En particulier lors de la justification et du lancement du projet mais également lors de changements organisationnels, à l’arrivée de nouvelles parties prenantes, pour accueillir de nouveaux clients…

Utilisez les marques de voitures pour vos rétrospectives Agile

L’exercice « la marque de voiture »  est une excellente façon de commencer une rétrospective efficace.

17 July – Webinar #PMI® – The Final Step to Agility for Your Project

6 Juil

What do you do once your project comes to an end?

When projects end in success, we often high-five and move on to the next project or task.

This may be successful in the short run, but long-term, it is critical to pause after every one of your projects for a Debrief.

In Flawless Execution, the Debrief is where the root causes of success and failure are identified.

We will teach you how to conduct a structured Debrief to assure your team can scale successes and eliminate the failures that may have occurred during the project.

Online registration

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

Méta Projets Management est partenaire de DantotsuPM

Enregistrer

Enregistrer

Retour d’expérience de Jorge Vanegas sur le leadership « accidentel » au format Pecha-Kucha : Are you an accidental leader ?

28 Juin

Pour rappel, une présentation Pecha-kucha consiste en 20 diapositives x 20 secondes par diapositive: seulement 6 minutes 40 secondes

Jorge Vanegas, Doyen du Texas A&M’s College of Architecture, discute des choses qu’il a apprises au fil du temps.

Visionnez ce Pecha-Kucha

Lien: http://www.pechakucha.org/presentations/simple-life-lessons-of-an-accidental-leader

Utilisez les marques de voitures pour vos rétrospectives #Agile

26 Mai

Car Brand for agile retrospective

http://blog.oikosofy.com/car-brand-agile-retrospective/ de Luis Goncalves

Book on Amazon

L’exercice « la marque de voiture »  est une excellente façon de commencer une rétrospective efficace. Cet exercice est tiré du livre « Getting Value out of Agile Retrospectives » de Luis Goncalves et Ben Linders.

Une des parties les plus importantes d’une rétrospective réussie est son « lancement ». Le facilitateur doit créer un environnement dans lequel l’équipe se sente à l’aise pour parler devant les autres de n’importe quel sujet. C’est le moment où l’exercice « la marque de voiture »  pourrait vous aider.

Que pouvez-vous espérer de cet exercice ?

C’est une bonne entrée en matière pour permettre aux membres de l’équipe de partager leurs sentiments sur comment est allé le sprint. Ils peuvent montrer leurs ressentis sans avoir besoin d’exprimer ouvertement leur avis. Quand les membres de l’équipe sont nouveaux, peut-être hésitent-ils à parler franchement, c’est pourquoi ceci est un excellent exercice à utiliser dans cette situation.

Quand utiliserez-vous cet exercice ?

Comme expliqué ci-dessus, l’exercice devrait être utilisé au début pour préparer le terrain pour que l’équipe puisse commencer la rétrospective. Ceci est un bon moyen de révéler l’avis des personnes, permettant à tout le monde d’avoir une compréhension partagée de ce que pensent les autres.

Comment l’exécutez-vous ?

Au début de la rétrospective, assurez-vous que tout le monde se sent confortable, posez-leur après cela une question simple : « si vous pensez à ce sprint comme à une marque d’une voiture, quelle voiture choisissez-vous ? ».

Par exemple, je choisis une Ferrari ou une Maserati si le sprint est allé très bien. Si le sprint avait des hauts et des bas, je choisirais une Fiat ou une Skoda. Donnez à une équipe 2-3 minutes pour réfléchir à leur marque.

Ensuite, demandez à chaque membre de l’équipe de révéler « sa voiture ». Laissez-les dessiner sur un flipchart ou l’écrire sur un post-it. À ce moment-là, ne leur demandez pas de justifier leurs choix. Permettez aux membres de l’équipe de voir quel est le choix de chacun. Ceci crée un sentiment global sur où en est l’équipe. Puis, demandez-leur de penser à la voiture de leurs rêves et donnez-leur 10 minutes pour réfléchir à ce qu’ils changeraient dans le sprint passé pour avoir « la voiture de leur rêve ».

Normalement, les équipes trouvent beaucoup d’idées différentes, mais ces idées sont d’habitude liées à des problèmes partagés. Demandez alors à l’équipe de voter pour choisir le problème le plus critique et important auquel l’équipe s’attaquera dans le prochain sprint.

Cet exercice utilise une marque de voiture, mais vous pouvez utiliser d’autres objets significatifs pour vous. L’équipe n’a pas besoin d’être co-localisée pour exécuter cet exercice. Il est applicable aux équipes géographiquement distribuées en utilisant divers outils de partage virtuel.

Enregistrer

Enregistrer

Enregistrer

si vous êtes un chef de projet débutant qui souhaite améliorer ses compétences, voici 5 choses à faire

17 Fév

de nombreux jeunes chefs de projet s’interrogent

bonhom-questionMel Bost, PMO Expert nous fait remarquer dans son billet « Five Tangible Things Aspiring Young Project Managers Can Do to Enhance Their Capabilities » que de nombreux jeunes chefs de projet interrogent leurs ainés plus expérimentés et leaders de PMO sur comment améliorer leurs compétences en management de projet.

Il leur conseille les 5 choses suivantes :

1. Portez-vous volontaire pour prendre les minutes d’une réunion importante

notebook-and-penAssurez-vous de trouver ou créer un modèle qui capture la liste des participants, la date et la durée de la réunion, l’ordre du jour, les actions qui ont été agréées, les tâches assignées à chaque participant et leurs dates de fin, les problèmes  non résolus ainsi que la date et heure de la prochaine réunion. En vous portant volontaire pour cette mission, vous fournirez un document clé à l’équipe de projet sur lequel ses membres peuvent se baser pendant tout le projet.

2. Vérifiez la bonne compréhension

A la conclusion et documentation du contenu du projet, questionnez le sponsor et les parties prenantes pour vous assurer qu’ils comprennent vraiment pour quels contenus ils signent et « l’engagement » nécessaire pour réaliser le projet. Ceci vous donnera un aperçu des “Changements de Contenu (/périmètre)” qui risquent de surgir avant que ces demandes de modifications ne surviennent. Cela augmentera aussi votre compréhension du processus de projet et votre stature par rapport aux autres chefs de projet.

NQI est Partenaire de DantotsuPM

NQI est Partenaire de DantotsuPM

3. Faites le forcing sur les leçons apprises

Dès la fin de la première phase majeure du projet, insistez pour que l’équipe de projet tienne une session sur “les leçons apprises”. Ils vous remercieront plus tard même si vous devez les traîner à la réunion à leur corps défendant.

4. Prenez en charge un problème majeur
Image courtesy of artur84 at FreeDigitalPhotos.net

Image courtesy of artur84 at FreeDigitalPhotos.net

Identifiez un problème qui semble diviser les membres de l’équipe de projet ou les parties prenantes et managez-le en enregistrant les actions majeures et décisions prises par l’équipe et les parties prenantes. Au moment approprié dans le projet, quand il apparaît que l’équipe projet ou les parties prenantes (ou les deux) se trouvent dans une impasse ou ont atteint un point délicat, sortez votre résumé des actions agréées et décisions prises et passez-les en revue avec ce groupe combiné. Certains peuvent ne pas apprécier d’être confrontés avec les faits, d’autres peuvent ne pas être d’accord avec vos « faits » ou votre interprétation, mais personne ne pourra dénier l’harmonie qui en résultera quand chacun commencera à voir les perspectives et points de vue des autres. Personne ne critiquera le fait qu’un observateur « raisonnable et réaliste » ait porté ces points de vue à leur attention.

5. Pratiquez ces 4 mécanismes de communication
Méta Projets Management est partenaire de DantotsuPM

Méta Projets Management est partenaire de DantotsuPM

Enregistrer

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

%d blogueurs aiment cette page :