Tag Archives: Lean

Avez-vous la GEMBA attitude ? par Rose-Hélène Humeau

27 Mar

Le terme japonais Gemba (現場) signifie « là où se trouve la réalité ».

On le traduit souvent par « le terrain ». Traditionnellement, les Japonais synthétisent l’attitude Gemba par les termes Genchi Genbutsu, ce qui signifie « aller voir sur le terrain par soi-même » soit le  « Go and See » en anglais. C’est une attitude préconisée dans le Lean Management particulièrement utile lors de la résolution de problème.

Elle se décline en 3 réels qui peuvent être facilement illustrés par la métaphore de l’enquête criminelle :

 

1/

 

LIEU RÉEL

(Gemba)

 

Où cela se passe-t-il?

 

Aller sur le terrain ou dans le bureau où se passe réellement le problème

 

C’est le principe de l’enquêteur qui se déplace sur le lieu du crime pour appréhender toute la situation

2/ OBJET RÉEL (Genbutsu) Montre-moi au lieu de m’expliquer Regarder le ou les éléments matériels portant ou conduisant au problème (processus, attitudes, procédures, documents) L’observation de la victime fournit les premiers indices
3/ FAITS RÉELS

(Gemjitsu)

Donne-moi des preuves, des éléments tangibles Approcher la réalité avec des données réelles quantifiées Le déroulement des faits et l’enquête de voisinage enrichit les observations de départ pour mieux comprendre et valider les hypothèses

 

Pour obtenir la meilleure solution au problème étudié, l’équipe peut s’appuyer sur les 2 points suivants:

 

4/

 

THÉORIE

(Genri)

 

“sur quelles bases peut-on s’appuyer?”

 

Se référer aux documentations de base, principes métier, procédures

 

Les analyses scientifiques donnent un nouvel éclairage et étayent les faits

5/ RÈGLES
(Gensoku)
“suit-on toujours les standards ou bonnes pratiques?” Appliquer les bonnes pratiques ou améliorer les standards/ procédures de travail Les faits doivent être vérifiés, les preuves irréfutables, les procédures suivies pour une enquête juridiquement aboutie

 

L’approche Gemba a été reprise en partie par le MBWA (Management BWalking Around) qui met en avant le fait que les managers doivent aller par eux-mêmes constater sur le terrain la réalité des choses.

passez-vous assez de temps à discuter avec les membres de votre organisation ?

Et vous, au quotidien, êtes-vous plutôt du genre « fin limier » sans supposition arbitraire, ou plus souvent « détective en fauteuil » qui ne se rend plus sur le terrain, au risque d’une enquête bâclée ou pire, d’une erreur judiciaire ?

Rose-Hélène Humeau, PMP® – humeaurh@metaprojets.com

Méta Projets Management est partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Comment reprendre en main une série de réunions récurrentes et sans date de fin bien établie ?

20 Mar

Des réunions récurrentes peuvent être parfois nécessaires, mais encore faut-il savoir les terminer !

Controlling the Runaway Meeting Par Alain Zucker

C’est un phénomène courant. Quelque chose arrive, d’habitude quelque chose de négatif. Des réunions quotidiennes sont organisées. Qui que ce soit qui ait un lien avec l’événement est là : des cadres supérieurs au personnel junior. Il y a une intensité incroyable. Puis, la question de départ est résolue. Mais les réunions continuent.

C’est arrivé à chacun d’entre nous. Les réunions commencent avec un objectif clair. Il y a une participation active. Les problèmes sont résolus. Et ensuite survient la dérive des réunions à répétition. Les participants principaux cessent de venir et des représentants sont mandatés à leurs places. Ou bien, les participants arrêtent de venir en personne et participent par téléphone. Les participants à distance font du multitâches et demande : “pourriez-vous répéter ?” si on leur pose une question.

Les crises entament leur propre vie. Elles produisent activité et excitation. Les gens veulent faire partie de la solution. Par conséquent, il est plus difficile de terminer une série de réunions que de la commencer.

Bien que ces interventions soient parfois nécessaires, elles représentent un coût élevé. Les dépenses directes sont mesurables. Une réunion quotidienne d’une heure avec 20 participants peut facilement coûter €10000 par semaine. Les dépenses indirectes de capacité productive perdue et de diversion de l’attention sont plus complexes à mesurer.

CSP est partenaire de DantotsuPM

Voici quatre recommandations sur la façon d’obtenir le contrôle de ces réunions répétitives qui n’en finissent plus

1. Posez la question : Pourquoi sommes-nous ici ?

les 5 pourquoi, les 5 whysCela peut paraître évident de demander “Pourquoi sommes-nous ici ?” mais cela nécessite du courage. C’est l’équivalent de demander au roi s’il porte des vêtements. Mais, c’est un premier pas nécessaire.

Tenez une réunion de revue bien facilitée. Demandez à ce que les leaders exécutifs y participent.

D’abord, rappelez l’objectif original de ces réunions. Utilisez des arguments spécifiques, mesurables et identifiez précisément les durées. Par exemple : le taux d’erreur a doublé de 5 % à 10 % et nous devons le ramener à 5 % d’ici un mois.

Deuxièmement, décidez si l’objectif a été atteint.

Si l’objectif a été atteint, concluez la réunion. Réduisez progressivement l’effort: compléter la documentation, rapporter et communiquer sur les leçons apprises, etc. Remerciez formellement tous les participants. Évitez l’erreur classique de punir l’innocent et féliciter les non-participants.

Si l’objectif n’a pas été atteint et que cela reste un effort à court terme, évaluez ensuite si les réunions sont efficaces. Sinon, régénérez la participation et remettez de la structure.

Si l’atteinte des objectifs exige un effort à long terme, transformez le travail à court terme en un programme dans la durée. Les exigences devraient être clairement documentées et la priorité établie par rapport aux autres besoins de l’entreprise.

2. Régénérez la liste des participants

Après quelque temps, les réunions s’embourbent. Trop de personnes sont là. Les participants exigés ne sont pas tous présents. Les rôles et attentes sont oubliés. Quand cela se produit il est temps de revisiter la liste des participants et de redéfinir les rôles de chacun.

Quand vous repensez la participation, suivez les étapes suivantes :

Une analyse minutieuse des parties prenantes aidera dans la construction d’un plan de communications efficace. L’analyse déterminera qui doit être impliqué, pourquoi et comment ils devraient être engagés. Font-ils partie du processus décisionnel ? Doivent-ils juste être informés ? Est-ce que ce sont « des personnes d’action » ? Le plan de communications aidera à garantir une participation productive.

Démontrez une cassure claire quand les réunions sont re-démarrées. Passez en revue les objectifs, les rôles et les attentes des participants, etc. Surveillez les agendas cachés et les comportements qui ne sont pas alignés sur les rôles des participants actuels ou sur les objectifs d’ensemble.

NQI est Partenaire de DantotsuPM

3. Mettez de la structure dans les réunions

Des réunions efficaces n’arrivent pas organiquement. Les réunions bien structurées sont plus productives et font des participants plus heureux.

facilitationCi-dessous sont quelques composantes critiques :

  • Posez clairement les règles du jeu et comportements attendus. Les règles du jeu posent les attentes de comportements normatifs et peuvent inclure : Participation, ponctualité, engagement et format des rencontres.
  • Établissez un processus décisionnel. Un bon processus décisionnel est documenté, transparent, avec des rôles clairement définis.
  • Utilisez un ordre du jour de réunion formel. Une réunion formelle avec un ordre du jour de rencontre structuré maintient la discipline et la productivité.
  • Documentez Risques, Actions, problèmes (« Issues ») et Décisions (le RAID). La documentation des items de RAID, les tenir dans un document facilement accessible et les passer régulièrement en revue réduira le turnover et assurera que chacun prenne ses responsabilités. Les tableaux Kanban sont efficaces et aide à assurer la transparence.
4. Passez en revue le processus

finiL’équipe devrait régulièrement poser deux questions importantes :

  • Avons-nous fini ? Continuez à passer en revue si les objectifs ont été atteints;
  • Optimisons-nous ? Optimisons-nous la réunion récurrente et ses réunions subsidiaires ? Pouvons-nous être plus efficaces ou plus productifs ? Pouvons-nous nous rencontrer moins fréquemment ou pour des durées plus courtes ?

Ces questions devraient être évaluées dans des réunions dédiées. Ces réunions devraient être conduites dans un environnement sûr où questionner le statu quo est encouragé et attendu. En passant en revue l’efficacité et la productivité des réunions :

  • Calculez le coût direct et la capacité perdue. Demandez-vous si nous en tirons toujours bénéfice ?
  • Passez en revue la structure des réunions et vérifiez que de bonnes pratiques de management sont suivies.
  • Utilisez un processus de facilitation pour déterminer ce qui marche bien et ce qui ne va pas. Identifiez les façons d’améliorer le processus.
5. Évoluez vers l’amélioration continue

Relisez ce billet sur le LEAN

Les organisations les plus efficaces pratiquent l’amélioration continue. Ce sont des processus méthodiques pour identifier et résoudre des problèmes systémiques. LEAN est une méthode largement utilisée. Quand les problèmes surviennent vraiment, les pratiques structurées sont en place pour guider vers leur résolution.

Si l’on considère les logiciels et la technologie pour supporter des efforts d’amélioration continus, ils peuvent inclure :

  • Examiner régulièrement les capacités business et leur processus de support opérationnel;
  • Maintenir et mettre à niveau l’infrastructure technique et la pile technologique d’applications;
  • Revoir le code applicatif.

Il y a des moments où une intervention est exigée pour se remettre d’un incident opérationnel ou d’un problème significatif. L’attention concentre l’organisation pour rapidement résoudre le problème. Cependant, les interventions devraient être soigneusement contrôlées et managées pour rester productives.

Que pensez-vous de ce retour d’expérience et conseils à appliquer dans vos projets ? Qu’ajouteriez-vous ?

Enregistrer

Enregistrer

Enregistrer

11 Janvier – Montréal – La gestion visuelle Lean Kanban

10 Jan

Risques et indicateurs de gestion

agile-montreal-5-ansUn événement de la communauté Agile de Montréal: Inscriptions

Daniel Doiron animera cette session

Daniel Doiron animera cette session

Est-ce que votre gestion du risque est rassembleuse, ouverte sur la discussion, qualitative, visuelle, peu coûteuse, rapide et supportant plusieurs taxonomies ?

Arrêtez les approches quantitatives en matière de gestion des risques qui sont souvent trop subjectives et non agiles.

Vos indicateurs de gestion ont-ils une valeur prédictive sur vos performances à venir? Sont-ils simples, pertinents, visuels et se génèrent automatiquement?

Si une approche basée sur la pensée scientifique des Edwards Deming (les 14 points de Deming et le leadership de projet de Qualité), Eli Goldratt, Peter Drucker vous intéresse, alors vous serez plus efficace à identifier les systèmes globalement saturés, les systèmes localement saturés et les sources de variabilité de vos processus. Et vous aurez des solutions en mains !

Votre avantage: Une fois ces concepts connus, vous n’aurez besoin d’aucun budget ou permission pour rayonner tout autrement en matière d’agilité au sein de vos équipes

Enregistrer

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

19 janvier – Le Mans – Journée Agile

27 Déc

L’agilité, c’est quoi ?

L’agilité avec l’ensemble de ses valeurs, de ses principes, de ses méthodes et pratiques, se diffuse progressivement dans nos environnements de travail et dans l’enseignement.

le-mans-agile-2017Novices ou experts, curieux ou praticiens, venez donc partager et échanger sur des thématiques agiles telles que le Management Agile, la programmation agile, le Lean IT, Lean Startup, Scrum, Kanban, eXtreme Programming … ou encore l’enseignement en mode Agile.

CertYou est partenaire de DantotsuPM

CertYou est partenaire de DantotsuPM

http://agile-mans.org/ Inscriptions gratuites

Enregistrer

Enregistrer

A quel point votre style de management de projet est-il LEAN ?

5 Déc

Il n’existe pas recette unique et universelle de manager au mieux un projet.

How Lean Is Your Project Management Style?

http://www.pmhut.com/how-lean-is-your-project-management-style par Kiron D. Bondale

Microsoft est partenaire de DantotsuPM

Microsoft est partenaire de DantotsuPM

La culture de l’organisation et de l’équipe et des facteurs environnementaux externes à l’entreprise influencent comment un projet est managé mais le style personnel et l’approche jouent aussi un rôle critique. Dans les contraintes imposées par les facteurs précédemment cités, un projet peut être managé avec succès mais le degré d’efficacité peut varier largement entre les chefs de projet.

Il n’est pas recommandé d’investir beaucoup d’efforts dans l’analyse de comment nous adaptons et exécutons chacun des 47 processus du PMBOK® Guide, mais nous pouvons identifier les sources communes de gaspillage dans le management de projet.

PMBOK Guide is a registered mark of Project Management Institute, Inc.

Attente

Image courtesy of graur razvan ionut / FreeDigitalPhotos.net

Image courtesy of graur razvan ionut / FreeDigitalPhotos.net

Nous pourrions nous plaindre fréquemment de combien de temps nous devons attendre que d’autres approuvent des livrables, prennent des décisions ou achèvent des activités dans le périmètre du projet.

Mais, combien de fois avons-nous introduit des retards inutiles en évitant un conflit avec un membre de l’équipe, en remettant à plus tard une conversation difficile avec une partie prenante ou une escalade sur une action ou problème qui gênait les progrès de notre équipe ?

Commencez-vous et finissez-vous TOUJOURS vos réunions à l’heure ?

Surproduction

paperImprimez-vous les copies de documents de référence pour tous les membres de l’équipe avant les réunions d’équipe ? Combien de ces copies sont en réalité utilisées ou même mentionnées ? Qu’en est-il de vos rapports pour les présentations aux décideurs ?

Les membres de l’équipe ont-ils à produire des rapports d’avancement différents pour vous et pour leurs propres managers fonctionnels ?

Refaire

Encouragez-vous les membres de votre équipe à s’assurer qu’ils équilibrent qualité et vitesse ou bien le message qu’ils reçoivent de vous est-il que vous êtes seulement intéressé par avoir les livrables dans les délais ?

Vous accordez-vous un temps suffisant lors de la mise à jour des prévisions budgétaires ou lors de la conception des propositions pour que le re-travail soit minimisé ?

Mouvement

visio conference

visio conference

Encouragez-vous la participation virtuelle pour éviter les voyages inutiles quand la présence physique n’est pas exigée pour atteindre les objectifs d’une réunion ?

Imprimez-vous des matériels inutiles et perdez-vous du temps en allers-retours à l’imprimante ?

(Sur) Traitement

Combien de fois êtes-vous coupable de regarder fixement un message électronique, une présentation ou un rapport et le peaufiner à maintes reprises. La communication consomme vraiment une grande partie de la journée d’un chef de projet mais sur-investissez-vous dans vos communications ?

CSP est partenaire de DantotsuPM

CSP est partenaire de DantotsuPM

Gaspillage d’intellect

Obtenez-vous le meilleur des membres de votre équipe (et de vous-même) ou les accablez-vous de tâches administratives drainant à faible valeur ajoutée ?

Stock

kanban boardVotre structure de découpage du travail est-elle suffisamment granulaire pour que le travail en cours soit minimisé ? Avez-vous utilisé de puissants outils comme les tableaux Kanban pour identifier visuellement des arriérés/stocks de tâches à faire ?

Transport

Avez-vous évalué le flux continu d’activités depuis l’expression des besoins jusqu’aux livrables finis pour garantir que le temps n’est pas perdu en déplacements inutiles ?

Insistez-vous toujours sur des signatures manuelles quand des approbations par courrier électronique pourraient suffire ?

Une vidéo pour illustrer ce sujet : « Lean : comment convaincre son patron ou son DAF ? » par Catherine Chabiron

Alors, votre approche de management de projets est-elle aussi efficace qu’elle pourrait l’être, ou êtes-vous scotchés dans vos habitudes ?

Enregistrer

6 Décembre – Lyon (Ecully) – L’AgiLean et le passage obligé du contrôle des coûts à la gestion des bénéfices de projets

22 Nov

L’AgiLean (Agile+Lean) propose une gestion de projet collaborative se focalisant sur la maximisation de bénéfices !

C’est à présent un Rendez-Vous annuel attendu par tous les dirigeants, opérationnels, étudiants et professionnels de la gestion de projets !

Claude Emond et Charlotte Goudreault, nos célèbres canadiens reviennent à Lyon avec une conférence qui portera sur le thème du Lean !

claude-et-charlotteSelon des études récentes de KPMG et TOP (Total Optimized Projects), le projet typique ne livre en moyenne qu’environ 25% des bénéfices récupérables parce que:

  • nous choisissons de réaliser des projets mal alignés avec les besoins d’affaires exprimés et/ou
  • les attentes et actions subséquentes des parties prenantes sont elles-mêmes non-alignées

L’AgiLean (Agile+Lean) propose une gestion de projet collaborative permettant d’aligner l’ensemble des parties prenantes et de les engager collectivement à récolter un maximum de bénéfices et ainsi optimiser, pour tous, la valeur des projets.

 

Focus sur les bénéfices !

Focus sur les bénéfices !

Cette conférence présentera brièvement l’AgiLean et expliquera en quoi la focalisation sur la maximisation des bénéfices, plutôt que l’acharnement sur le respect à tout prix des coûts de projet, permet de meilleurs retours individuels et collectifs sur les investissements (ROI et autres) en projets et accélère la récolte de ces bénéfices.

Informations & Inscriptions auprès de Marion Rullier

Enregistrer

Image

Free eBook: Essential Kanban Condensed by David J Anderson and Andy Carmichael

12 Nov
Get the book for free on line

Get the book for free on line

 

Enregistrer

découvrez Prince2 Agile dans cette vidéo

28 Oct


PRINCE2 Agile est une solution de management de projet qui combine les qualités de gouvernance et de management de PRINCE2 avec la flexibilité des concepts Agile.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

PRINCE2 Agile a été construit de manière collaborative avec des experts PRINCE2 et des « Agilistes ».

Partenaire de DantotsuPM

Partenaire de DantotsuPM

PRINCE2 Agile couvre les approches Scrum, Kanban, Lean Startup et Cynefin et utilise les principes de PRINCE2 avec 5 comportements clés:

  1. Transparence
  2. Collaboration
  3. Communication
  4. Auto Organisation
  5. Exploration
Partenaire de DantotsuPM

Partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

Comment gérer le ventre mou de l’IT, les demandes d’évolutions logicielles en mode #Agile ? Par Gaël Gomez

24 Oct
Gaël Gomez

Gaël Gomez

Rétrospective d’Évolutions

Tout a commencé il a environ 3 ans, début 2014, lorsque mon manager a voulu que je prenne en charge le pôle des Évolutions. Je vais tâcher de vous raconter les changements mis en place au sein de ce département qui ont contribué à améliorer la satisfaction clients tout en délivrant de la qualité. Ces évolutions, telles que l’implémentation d’indicateurs, d’un kanban ou encore d’un planning poker, ont clairement  fait progresser la perception utilisateurs et ont su faire évoluer mon mode de fonctionnement aussi côté projets.

Au sein de l’IT dans les entreprises, il y a les projets, la maintenance et le ventre mou, les évolutions. Ces demandes utilisateurs dont on ne sait que faire, pas suffisamment importantes pour les faire passer en projet et où les budgets à allouer, sont toujours plus ou moins compliqués à mettre en place.

Ces demandes ont un coût variable entre un et quarante jours. Elles sont priorisées au sein d’un comité chez LeasePlan France qui a lieu mensuellement. Un représentant de chaque direction vote pour les demandes qu’il qualifie par ordre d’importance. Une moyenne est établie et donne un ordonnancement pour les traiter. A chaque comité sont priorisées dix demandes utilisateurs qui viennent se mettre en backlog du Kanban avec une limite de dix dans le pipe à traiter.

un-seul-kanban

une limite de dix dans le pipe à traiter (colonne la plus à gauche)

En amont de ces comités, j’allais voir chaque utilisateur qui présentait une évolution qui allait être soumise au vote, pour pouvoir y attribuer un chiffrage grossier en fonction du besoin. Ici, le « je » est important car vous allez voir par la suite comment amener l’équipe à s’engager.

Deux questions se posaient, la première, comment rendre plus Lean le process, et la deuxième, comment quantifier la valeur que chaque demande apporte, ou comment apporter de la valeur le plus rapidement possible. En effet, en premier lieu, je me suis rendu compte que passer du temps avec chaque utilisateur en amont du comité était, non une perte de temps, si ce n’est pour ma connaissance personnelle, mais non nécessaire (toutes les demandes n’étant pas priorisées dû à la limite du backlog).

Pour répondre à cette première question et ne pas avoir à chiffrer et analyser des demandes non priorisées, j’ai déporté cette phase d’échange post comité.

Simultanément, j’ai mis en place deux jours avant comité, une revue de chiffrage avec l’équipe dans laquelle toutes les demandes étaient passées en revue pour pouvoir y attribuer un chiffrage moyen établi en consensus. Le tour était joué. Le simple fait de faire participer l’équipe dans l’analyse grossière les stimulait, leur avis étant pris en considération. Qu’y a-t-il de plus essentiel pour une personne que de se sentir importante et impliquée ? Vous y gagnerez en engagement.

L’utilisation du Kanban, insufflé par mon manager et connu de tous, était simple : un backlog, analyse, développement, User Acceptance Testing (UAT) et production. La première pierre était posée.


Après huit mois d’historique, de statistiques et de dérives, deux choses ressortaient. Le chiffrage réel différait du chiffrage initial lors du traitement de la demande et le résultat attendu lors de la mise en UAT amenait souvent des questions ou retours en développement. Force était de constater, on le sait malheureusement, le besoin n’est pas toujours exprimé correctement ou avec les bons mots et même si durant les phases de design nous rencontrons les métiers, nous ne parlons pas toujours le même langage.

Comment quantifier la charge sur une évolution et être sûr de comprendre la même chose que le Métier ?

Deux notions ont été intégrées, une insufflée par mon manager,

  1. les « Efforts » avec la suite de Fibonacci et
  2. la phase dite de « Validation de design » que j’ai introduite.

bonhom-calculatorLa première consiste à mettre un effort sur une demande, de prendre une évolution compréhensible par tous et d’obtenir un consensus en équipe.

Ensuite, les autres demandes qui sont passées en revue sont notées en fonction des précédentes. La note est attribuée en fonction du niveau de complexité, de la qualité rédactionnelle et de la compréhension de chacun tout en gardant à l’esprit la charge plus ou moins importante qu’elle peut représenter. Le but de ces sessions pré comité était de voir, aussi, les grands items qui se dégageaient de chaque évolution, de la pré-découper en tâches car plus les items sont petits, plus la marge d’erreur est réduite et vous pourrez être prédictible concernant la charge réelle.

La deuxième notion consiste à sélectionner une évolution et voir avec le métier, durant la phase de design, si ce qu’il a exprimé correspond réellement à son besoin (phase d’Assistance à Maîtrise d’Ouvrage, AMOA). Cela permet de définir ou redéfinir le design et d’en faire un compte rendu effectué par l’IT, synthèse non technique qui décrit ce qui va être fait lors de la livraison en UAT.

démonstrationPlusieurs objectifs :
  • Délimiter un périmètre qui doit respecter approximativement le besoin initial,
  • Déterminer ce qui ne sera pas fait de ce qui le sera,
  • Démarrer les développements une fois la validation de l’utilisateur reçue,
  • Dématérialiser la phase de design pour une question de traçabilité, de gestion et de négociation (on le sait, une fois livrée en UAT, il manque toujours le petit quelque chose auquel l’équipe projet n’avait pas pensé),
  • Découper en items/user stories, fonctionnelles et/ou techniques,
  • Chiffrer les items,
  • Être prédictible concernant la date de mise en UAT
Les bénéfices de cette phase ont été divers :
  • Faire prendre de la hauteur à certains membres de l’équipe qui ont été capables d’en tirer, profit, être totalement autonome, analyser les process métiers en omettant le technique pour trouver la meilleure solution,
  • Identifier ceux qu’il a fallu accompagner,
  • Livrer en UAT ce qui correspond à la demande utilisateur, sans surprise quelconque et de ce fait, limiter les retours en développement,
  • Développer une satisfaction métier accrue.

Comment déterminer le degré d’efficacité des phases de design et contrôler la qualité des livrables ?

bonhom-thumb-upCertes, le métier était satisfait, mais cela restait une impression, notre perception. Comment pouvait-on la mesurer ? Huit autres mois se sont écoulés et c’est à se moment là que j’ai décidé de nous mettre en risque (mesuré).

Premièrement, nous avons comptabilisé le nombre de retour d’UAT en développement en les catégorisant :
  • Les retours dit « anomalie » causés par l’IT liés aux développements et/ou environnements
  • Les retours dit « cosmétique » qui sont inférieurs à une demi-journée de développement
  • Les retours dit « évolution » qui sont supérieurs à une demi-journée car l’équipe projet (métier-IT) est passée au travers du sujet
Deuxièmement, nous avons comptabilisé le nombre de WFT (Write First Time, évolution livrée en UAT ne nécessitant pas de développement supplémentaire) et le nombre d’anomalies générées liées à nos mises en production.
Enfin, un questionnaire de satisfaction était envoyé à chaque évolution livrée avec une notation sur 10 au « key user » :
  • L’évolution livrée correspond elle à votre besoin ?
  • Êtes-vous satisfait de l’accompagnement en UAT ?
  • Des améliorations vous ont-elles été proposées durant la phase de design ? Si oui, lesquelles ?
deux-kanbansLe fait de cadrer au mieux durant les phases de design, de faire une « démo » utilisateur à la livraison en UAT et d’accompagner le métier nous ont permis d’obtenir ces résultats sur 75 demandes :
  • 85 % des demandes ont été comptabilisées en WFT
  • Plus de 90% des demandes n’ont eu aucun retour d’UAT
  • Moins de 3% des demandes ont générées un bug en production
  • Une moyenne supérieure à 9 concernant les questionnaires de satisfaction
Simultanément, nous avons introduit le planning poker lors des comités :
cards-in-your-hand

planning poker (précédent billet)

Dans les faits, chaque responsable métier attribue à une évolution une note prise sur la suite de Fibonacci et une moyenne est effectuée. En fin de séance, l’IT donne les efforts de chaque demande et le ratio valeur/effort détermine l’ordonnancement des évolutions. Le but étant ici d’apporter la plus grande valeur, le plus tôt possible. Certes, la valeur qu’apporte la livraison d’une évolution est subjective en fonction de chacun, mais cela permet néanmoins de partager les points de vue et soulève des débats.

La vie côté projets après deux années aux Évolutions

En ce début d’année, avril pour être exact, j’ai basculé côté projets et mon manager me disait : « continue à faire ce que tu as fait et ça se fera tout seul». Cela veut dire tellement de choses à la fois lorsque j’y repense.

Un bon manager essayera de vous insuffler des idées. Toutefois, la capacité de chacun à entendre, à se remettre en question, à réfléchir par soi-même ou encore à faire évoluer sa perception des choses ne sont pas donné à tout le monde. C’est ce que vous en faites qui contribuera à votre évolution si vous en avez toutefois l’envie.

J’ai appris à manager une équipe, en tirer le meilleur avec les qualités et défauts de chacun, à obtenir une émulation que je ne soupçonnais pas ou encore à gérer des personnes avec lesquelles je ne m’entendais pas. On ne nait pas fédérateur, on le devient, c’est mon avis.

sharing experienceAujourd’hui, j’ai gardé le meilleur de ces deux dernières années et en ai tiré des leçons.

Nous découpons en équipe un projet pour en obtenir des « items/users stories » les plus petits possibles, et ce, dès la phase de « define » pour engager l’équipe.

Cela permet déjà d’être plus ou moins prédictible quant aux UAT en mettant bout à bout tous les items, de voir les modules indépendants et de les livrer plus tôt, indépendamment de tout le projet.

Le but est d’obtenir des items avec un effort maximum de 5 car mes statistiques me font dire qu’en général, la charge correspond à l’effort multiplié par 1,5. Cela reste approximatif mais a fait ses preuves ces deux dernières années. Au-delà, un item avec effort 8 consommera entre 8 et 20 jours, et un item à 13 entre 20 et 40 jours. Plus l’effort est grand, plus il y a de risques, de points d’attention ou d’incompréhensions.

Chaque item fait office « d’évolution », de ce fait, il est analysé avec le métier avec une phase de validation de design, document une fois réconcilié avec les autres, qui serviront à faire un passage à la maintenance.

Ces trois dernières années m’ont permis d’appréhender des concepts de SOA, d’architecture globalisée, une gestion de fournisseurs ou encore de méthode de management. Il m’a fallu une perpétuelle remise en question et une envie démesurée pour obtenir le meilleur des gens, IT ou non d’ailleurs.

S’il fallait résumer

  • A few videos to get started on Agile, Scrum and Kanban

    A few videos to get started on Agile, Scrum and Kanban

    Le kanban est un outil très utile au management visuel,

  • Les « stand up », s’ils ne sont pas utilisés à outrance, permettent d’avoir un suivi et un partage au sein de l’équipe. Pour ma part, ils se limitent à deux par semaine, voire trois en fonction des jalons, risques et mises en production,
  • Les workshops avec l’équipe permettent d’obtenir un engagement des collaborateurs et une vision partagée pour en tirer la meilleure émulation possible,
  • Les projets doivent être découpés au niveau le plus fin, s’ils le permettent, pour une meilleure visibilité,
  • Le management est un concept difficile s’il est bien fait, car oui, le manager paternaliste est mort !

En espérant que cela puisse vous servir ou vous inspirer…

Gaël Gomez, Chef de projet informatique au sein de LeasePlan France

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

%d blogueurs aiment cette page :