Les indicateurs de flux et pourquoi ils sont importants pour les équipes et les managers.

Les indicateurs de flux sont le seul « secret » qui peut améliorer l’agilité dans n’importe quelle approche.

Flow Metrics and Why They Matter to Teams and Managers par Johanna Rothman

https://www.jrothman.com/newsletter/2024/01/flow-metrics-and-why-they-matter-to-teams-and-managers/

Je continue de travailler avec des gens qui ont de la difficulté avec leur approche agile. Ils me disent que l’estimation relative ne fonctionne pas pour eux. Ils continuent à repousser des items de l’arriéré de produit, d’un sprint à l’autre. Ils ont reconduit certains articles pendant six mois ou plus. Les gens se sentent démoralisés. Et les Scrum Masters ou les managers de projet agiles n’ont aucune idée de la façon de résoudre la situation.

C’est à ce moment-là que je leur recommande d’utiliser les métriques de flux au lieu de l’une de leurs mesures plus traditionnelles. Parce que leurs mesures actuelles ne les aident pas.

Les indicateurs de flux sont le seul « secret » qui peut améliorer l’agilité dans n’importe quelle approche. Ces indicateurs mettent en évidence les principes de l’agilité. Lorsque les équipes mesurent ces quatre indicateurs, elles peuvent voir leur réalité et décider quoi faire pour créer un meilleur environnement. Et, comme pour la plupart des principes, il y a une petite différence dans la façon dont ils comptent pour les équipes et les managers.

Tout d’abord, voyons ce que sont les métriques de flux.

Métriques de flux

Voici les quatre indicateurs de flux :

  1. Work InProgress (WIP), travail en cours. Tous les travaux en cours : commencés et pas encore terminés.
  2. Throughput, débit : Nombre d’éléments de travail qu’une équipe/un responsable peut effectuer par unité de temps.
  3. Temps de cycle : Le temps nécessaire pour libérer de la valeur, en tant que tendance.
  4. Vieillissement : Depuis combien de temps un travail est en cours.

Bien que les indicateurs de flux soient indépendants, ils créent des interactions et des dynamiques qui affectent le fonctionnement d’une équipe ou d’un manager.

Commençons par une équipe.

Comment les métriques de flux interagissent

Imaginez une équipe qui termine régulièrement un élément chaque semaine. C’est leur débit régulier. Maintenant, quelqu’un pense que l’on a besoin d’en faire « plus ». Peut-être que quelque chose a changé sur le marché ou que la direction n’est pas satisfaite du rendement de l’équipe. Ou peut-être qu’un concurrent gagne du terrain. Quoi qu’il en soit, l’organisation en veut « plus ».

Une personne bien intentionnée demande à l’équipe de commencer un autre article cette semaine et de le terminer. Cela augmente le WIP de l’équipe. Cependant, à moins que l’équipe ne change quelque chose dans sa façon de travailler, elle n’augmente pas son débit, simplement parce qu’elle a commencé un élément supplémentaire.

En fait, leur débit a diminué parce qu’ils travaillent sur deux articles en parallèle et n’ont terminé aucun des deux. Pire, leur temps de cycle augmente. Et maintenant, ils ont deux articles plus anciens, ce qui augmente l’âge moyen de tous les articles.

La demande de travail augmente, tout cela parce que l’équipe n’a pas terminé « assez » d’items.

C’est une boucle de rétroaction qui se renforce. À mesure que le WIP augmente, le temps de cycle augmente. L’équipe a un débit plus faible, ce qui conduit à des articles plus vieux. Tout cela augmente leur WIP.

Nous tournons en rond, créant un environnement de plus en plus mauvais pour l’équipe.

Si vous avez déjà vu une équipe « basculer » le travail d’un sprint à l’autre, vous avez vu cette dynamique. C’est pourquoi l’estimation relative et la vitesse n’aident pas, mais la mesure du temps de cycle fonctionne.

La bonne nouvelle, c’est que l’équipe peut intervenir à n’importe quel endroit et apporter des améliorations.

Interventions de l’équipe.

Voici les questions que l’équipe peut poser :

  • Quelle est la chose sur laquelle nous devrions travailler et terminer ? (Commencer par WIP.)
  • Quel âge a notre item le plus ancien ? A-t-il encore de la valeur ? (Commencez par le vieillissement.)
  • Que devrions-nous changer dans notre travail pour réduire notre temps de cycle ? (Focus sur le temps de cycle.)
  • Comment pouvons-nous augmenter notre débit ? (Focus sur le débit.)
boucle de renforcement positif

J’ai tendance à commencer par l’une ou l’autre des deux premières questions, car elles se concentrent sur une chose que l’équipe peut terminer. Lorsque l’équipe réduit son en-cours à un seul élément, elle doit changer sa façon de travailler. (J’ai abordé ce problème de collaboration dans le conseil 3 en Trois conseils pratiques pour commencer votre prochaine année en force.)

Ensuite, plus l’en-cours est faible, plus le débit est élevé, plus le temps de cycle est faible et plus le nombre d’anciens items est réduit. C’est la même boucle de rétroaction, mais d’une manière qui soutient l’équipe.

Est-ce que « 1 item » est toujours le bon nombre pour les travaux en cours ? Non. Dans créez votre projet Agile réussi, je recommande à l’équipe de commencer par le nombre de personnes de l’équipe divisé par deux. Si vous avez un nombre impair de personnes, arrondissez au dessous. Donc, si vous avez cinq personnes, utilisez deux comme WIP maximum.

Mais votre équipe peut vouloir commencer par des changements d’équipe pour réduire le temps de cycle et augmenter le débit. Vous pouvez commencer n’importe où car il s’agit d’une boucle de rétroaction.

Les managers travaillent différemment. Aussi, les indicateurs ne changent pas, mais les interventions de la direction changent.

Interventions de la direction

Les métriques de flux interagissent de la même manière pour les managers que pour les équipes. Cependant, les managers ne livrent pas de fonctionnalités. Au lieu de cela, ils prennent des décisions. C’est pourquoi les idées présentées dans pourquoi minimiser le temps de décision de la direction ont tellement d’importance.

Plus les managers ont des de décisions en cours de réflexion (vieillissement des décisions), plus ils ont de décisions en cours (leur WIP). Plus le WIP d’un manager est élevé, plus le temps de cycle est long et plus le débit est faible. Cela signifie que les gens ne savent pas quoi faire et décident par eux-mêmes. Les gens ne peuvent plus attendre une décision du management.

Les managers peuvent se poser des questions légèrement différentes :

  • Dois-je prendre cette décision ou puis-je la déléguer à quelqu’un ou à une autre équipe ? (Cela réduit les travaux en cours.)
  • Cette décision a-t-elle encore de la valeur ? (Réduire le vieillissement.)
  • Quelles décisions puis-je prendre aujourd’hui pour m’en débarrasser ? (Réduire le temps de cycle.)
  • De qui d’autre ai-je besoin pour prendre cette décision et comment pouvons-nous décider aujourd’hui ? (Augmenter le débit.)

Bien que les questions soient un peu différentes, les managers peuvent utiliser la boucle de rétroaction pour créer une boucle de rétroaction qui fonctionne pour eux, et non contre eux.

Les indicateurs de flux peuvent amener de meilleures décisions.

Lorsque les équipes et les managers voient le nombre de leurs travaux en cours, leur temps de cycle, leur débit et leur vieillissement, ils peuvent décider de ce qu’ils veulent changer. Est-il temps de collaborer davantage ? Peut-être commencer par la question de la valeur, comme dans « Quelle est la chose la plus précieuse que nous puissions terminer aujourd’hui ? ».

Les indicateurs de flux sont importants car ils permettent aux équipes et aux managers de voir et de gérer leur façon de travailler. Utilisez-les pour obtenir des informations sur les domaines dans lesquels vous pourriez choisir de modifier votre travail.

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Cette lettre d’information aborde les sujets abordés dans les livres :

Livre sur Amazon
Livre sur Amazon

Nouveau sur le Pragmatic Manager ?

Êtes-vous nouveau sur la newsletter Pragmatic Manager ? Consultez les numéros précédents ou visualisez et écoutez ces newsletters sur la chaîne YouTube.

Comment les équipes autonomes aident-elles tout le monde à apprendre et à s’améliorer ?

Si vous êtes manager, voyez comment vous pouvez soutenir les personnes que vous menez et les servir pour qu’elles forment une équipe autonome.

How Autonomous Teams Help Everyone Learn and Improve par Johanna Rothman

https://www.jrothman.com/newsletter/2025/05/how-autonomous-teams-help-everyone-learn-and-improve/

Avez-vous remarqué que certaines équipes semblent être plus efficaces que d’autres ?

La plupart du temps, elles gèrent leur WIP (Work in Progress). Ses membres apprennent ensemble. Souvent, ils collaborent à l’échelle de l’organisation. Mais le point majeur, c’est qu’ils ont tendance à livrer plus rapidement et plus souvent que les autres équipes moins efficaces.

Bien que la plupart de ces équipes efficaces soient interfonctionnelles, j’ai travaillé avec des équipes de composants qui ont démontré ce comportement. Chaque équipe était autonome, mais elle collaborait pour livrer quelque chose de plus grand que « son » seul composant.

Qu’est-ce qui crée ces équipes plus efficaces ?

Plusieurs caractéristiques :

  • Elles ont un objectif global clair.
  • Tout le monde collabore pour travailler vers cet objectif, et seulement vers cet objectif.
  • Les membres de l’équipe ont appris à donner et recevoir des commentaires les uns des autres. Ces commentaires aident l’équipe à apprendre et à s’améliorer.

Et comme très peu d’équipes peuvent livrer seules, elles peuvent aider les autres équipes à apprendre et à s’améliorer. Tout cela parce qu’elles créent et utilisent des plus petits réseaux. Ce sont des équipes autonomes.

Comment fonctionnent les équipes autonomes ?

Les équipes autonomes prennent leur objectif clair, se concentrent sur celui-ci et atteignent cet objectif. Elles décident comment travailler ensemble et comment manager les membres de l’équipe lorsqu’elles ne le peuvent pas. Lorsqu’elles ne peuvent pas livrer, elles vous en informent le plus tôt possible.

Si vous êtes manager, comment pouvez-vous créer ces équipes autonomes ?
  • Établissez et clarifiez l’objectif global de cette équipe.
  • Demandez à l’équipe si elle a besoin d’une certaine facilitation au début ou au fur et à mesure qu’elle persiste. Si certaines équipes autonomes n’ont pas besoin de facilitation, beaucoup en ont la nécessité. Surtout face aux exigences omniprésentes de multitâches.
  • Encouragez la création de communautés à l’échelle de l’organisation et de plus petits réseaux. Cela aide les personnes et les équipes à réfléchir à la manière dont elles peuvent apprendre à l’échelle de l’organisation. Et d’offrir des informations recueillies dans leur équipe aux personnes de l’ensemble de l’organisation.

Commençons par l’objectif global.

Définissez et clarifiez l’objectif global de l’équipe.

Les équipes de développement de produits ont souvent un objectif global axé sur le produit. C’est de la forme :

Cette version permettra au jeu de clients numéro un de résoudre les problèmes A, B et C dans cet ordre de classement. Bien que nous espérions pouvoir également résoudre les problèmes D, E et F, nous nous concentrons pour l’instant sur ce plus petit objectif spécifique. Parce que même si nous voulons accomplir D, E et F, nous pouvons également vouloir nous concentrer sur un jeu de clients différent lorsque nous terminerons A, B et C.

Vous pouvez décrire différemment l’objectif global de votre équipe. Cependant, ces objectifs sont souvent spécifiques, c’est pourquoi ils définissent un périmètre circonscrit autour du travail de l’équipe, afin que l’équipe puisse se concentrer uniquement sur son travail. Pas de multitâche. Pas d’interruptions.

Mieux encore, un périmètre circonscrit aide l’équipe à repousser ce qui est hors de celui-ci pour le moment. L’équipe ne se laisse pas distraire par un travail futur ou d’autres possibilités. Au lieu de cela, elle livre ce qu’elle doit livrer.

Si vous faites partie d’un programme, un ensemble de projets tous axés sur un livrable business global, vous avez probablement vu des équipes agir ainsi. Chaque équipe se concentre sur sa contribution pour que le produit global réussisse.

Alors que certaines équipes peuvent s’accaparer leur objectif global et le suivre, certaines équipes ont également besoin de facilitation.

Envisagez des rôles d’animation d’équipe.

Normalement, je ne considère pas le leadership de produit comme un rôle d’animation d’équipe. Mais parfois, c’est le cas. Surtout si les membres de l’équipe ont du mal à se concentrer sur le premier jeu de clients. Ou dans l’ordre de hiérarchisation des problèmes A, B et C.

Il y a longtemps, j’ai travaillé sur un programme où la direction avait décidé de reporter pour le moment plusieurs fonctionnalités intéressantes et de les considérer pour une future version. Cependant, un développeur était convaincu qu’il devait « sauver » le produit en continuant à travailler sur ces fonctionnalités intéressantes.

C’est à ce moment-là que le chef de produit a expliqué l’intérêt de reporter ces fonctionnalités intéressantes et ce que l’entreprise espérait gagner avec cette version plus limitée.

Une fois que le développeur a compris ceci, il fut heureux de se concentrer sur le travail de l’équipe, et non sur ses intérêts.

Parfois, les équipes ont besoin de liberté pour être autonomes. J’ai vu des managers bien intentionnés (et certains moins bien intentionnés) s’insérer dans le travail de l’équipe. Lorsque les managers font cela, l’équipe perd son autonomie. Au lieu de cela, un manager de projet facilitateur peut agir comme une boîte de délimitation pour l’équipe elle-même, protégeant l’équipe des personnes qui détruiraient l’autonomie de l’équipe.

Les managers de projet facilitateurs ne disent pas à l’équipe quoi faire ou comment travailler. Au lieu de cela, ils et elles créent l’environnement pour que tout le monde puisse contribuer. Parfois, cela signifie expliquer à des managers bien intentionnés que non, l’équipe ne peut pas en faire plus.

Parfois, ces animateurs et animatrices aident l’équipe à mieux travailler ensemble. Il peut s’agir de faciliter les accords de travail de l’équipe ou d’aider l’équipe à s’entraîner à donner et recevoir des commentaires. Il peut s’agir d’aider l’équipe à envisager des pratiques alternatives pour la rendre encore plus efficace.

Mais les leaders facilitateurs ne disent pas à l’équipe comment travailler. Ils et elles offrent des options. Souvent, l’une de ces options inclut les communautés de l’ensemble de l’organisation.

Construisez des communautés à l’échelle de l’organisation.

Lorsque je vois des équipes autonomes, je découvre souvent que ces équipes ont construit des réseaux à l’échelle de l’organisation. (Voir l’image en haut de cet article.) Non pas parce que quelqu’un leur a dit de le faire. Mais elles se rendent compte que Marie, là-bas, a des connaissances intéressantes. Et Fred, ici, a déjà résolu un problème comme celui-ci. Ou Suzanne, dans cette autre équipe, a déjà eu affaire à ce client.

Les équipes autonomes peuvent combler leurs lacunes en travaillant avec et auprès d’autres personnes, même si ces autres ne font pas partie de « leur » équipe.

J’aime particulièrement les groupes d’apprentissage ciblés. Envisagez les communautés de pratique formelles comme un moyen de commencer par un apprentissage ciblé. À l’époque où les entreprises avaient des cafétérias, j’apprenais beaucoup de choses de manière informelle au déjeuner. Non seulement j’ai appris à connaître les produits, mais j’ai aussi appris qui avait quels types de connaissances. Cela m’a aidé à décider par où commencer une quête sérieuse.

Bien que de nombreuses équipes autonomes n’aient pas besoin d’un leadership spécifique axé sur un projet ou une équipe, elles ont besoin du type de leadership qui peut définir l’objectif global.

Les équipes autonomes ont toujours besoin d’un leadership d’entreprise.

La grande chose dont les équipes autonomes ont besoin de la part de la direction est la suivante : L’objectif global et la durée de cet objectif.

Cela signifie que les équipes autonomes doivent comprendre le(s) objectif(s) du produit et la stratégie. Ces équipes doivent comprendre à quelle fréquence la direction de l’entreprise souhaite être en mesure de modifier ces objectifs de produit et/ou cette stratégie.

De plus, il arrive que des équipes se retrouvent en difficulté et qu’elles ne sachent pas comment s’en sortir. (Imaginez un membre de l’équipe qui cesse de venir travailler. Ce genre de problème.) C’est à ce moment-là que les managers peuvent soutenir l’équipe et les différents membres de l’équipe.

Les équipes autonomes ne fonctionnent pas en circuit ouvert. Au lieu de cela, elles montrent leur travail tôt et souvent. Elles utilisent un périmètre circonscrit pour se concentrer sur leur objectif et uniquement sur cet objectif. Et si quelqu’un demandait autre chose ? Elles ont des options, mais ces options incluent rarement le multitâche ou le fait de dire oui. Elles sont beaucoup plus susceptibles de dire non.

Si vous êtes manager, voyez comment vous pouvez soutenir les personnes que vous menez et les servir pour qu’elles forment une équipe autonome. Votre équipe apprendra et s’améliorera, et contribuera à partager cet apprentissage et cette amélioration dans toute l’organisation.

Lu dans la newsletter de Johanna Rothman pour le mois de mai 2025 de Pragmatic Manager.

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Choisir les pratiques de management de projet hybride par Alan Zucker

Les projets hybrides ne sont pas limités par une méthodologie unique ou un cadre bien défini.  Par définition, il s’agit d’un mélange de pratiques.

http://www.planningplanet.com/blog/hybrid-project-management-part-4-picking-practices

Relisez ou découvrez les articles précédents :

  1. Management de projet hybride : Qu’est-ce que l’hybride ?
  2. Management de projet hybride : Quels changements ?
  3. Choisir l’approche de management de projet hybride

Les projets hybrides ne sont pas limités par une méthodologie unique ou un cadre bien défini.  Par définition, il s’agit d’un mélange de pratiques.  Une énorme responsabilité accompagne cette liberté de choix illimitée.  Les managers de projet doivent décrire clairement comment le projet sera exécuté pour réussir.

Se dérober à cette responsabilité est fort préjudiciable. La recherche (PMI® A New Way Forward) démontre que la maturité et la cohérence améliorent les résultats des projets.  Sans aucun processus, nous suscitons le chaos.

Des centaines d’options et de points de décision doivent être pris en compte lors de la description du plan de management ou d’exécution du projet.  Le Boîte à outils Disciplined Agile Toolkit  décrit plus de 150 décisions (options) pour l’organisation et l’exécution d’un projet. Capterra répertorie plus de 1500 outils logiciels de management de projet.

Les managers de projet hybrides doivent planifier intentionnellement. Cet article identifie certaines pratiques fondamentales qui devraient être utilisées dans chaque projet.  L’instanciation de ces pratiques sera adaptée au contexte du projet.

Établissez la charte de projet (Project Charter).

La Charte de projet définit l’approche de travail.  Elle établit les attentes et les compréhensions initiales entre les parties prenantes et l’équipe de projet. Elle documente les objectifs, les exigences et les contraintes de haut niveau, le rôle du manager de projet et de nombreux autres éléments. Le niveau de formalisme et les composantes seront basés sur les exigences de l’organisation et du projet.

Il peut être difficile de créer un alignement et trouver un accord entre les parties prenantes du projet. Le processus de définition de la charte du projet crée un forum pour faire apparaître et résoudre les conflits d’intérêt et les objectifs mal alignés, en minimisant les retards et en évitant la nécessité d’avoir à refaire certains éléments plus tard.

Créez un plan de management.

Le Plan de management de projet documente la façon dont le projet sera exécuté. Il doit être adapté au contexte du projet. Un plan de management de projet bien défini est crucial pour les projets hybrides puisqu’il n’existe pas de standard opérationnel.

Le plan établit les attentes et renforce la compréhension au sein de l’équipe de projet. Il définit et décrit les rôles, les responsabilités et les processus. Le format et le niveau de détail doivent être adaptés au contexte du projet.  Un bon plan augmente les chances de réussite du projet et réduit les inefficacités et les conflits.

Définissez le périmètre et construisez l’échéancier.

Les deux éléments de planification les plus critiques sont la définition de ce qui sera livré (portée/contenu) et du moment (échéancier/délais). Sans cela, les projets pataugent comme un navire sans gouvernail.  Le type de projet et l’environnement opérationnel influencent les pratiques et les outils utilisés.

Les projets traditionnels ont des spécifications détaillées, utilisent généralement un échéancier basé sur un diagramme de Gantt, et un processus rigoureux de management du changement.

Les projets Agile ont une portée émergente. Les fonctionnalités et les user stories sont documentées et hiérarchisées dans le backlog du produit.  Les fonctionnalités sont fournies en courtes itérations, souvent de 2 semaines. Les équipes utilisent un Tableau Kanban pour gérer le flux de travail.

Les projets hybrides sont libres de définir leurs propres pratiques de planification. Ils peuvent suivre les contours généraux de l’approche traditionnelle ou agile, combiner les meilleures pratiques, telles que la Technique des jalons Kanban (Milestone-Kanban Schedule), ou suivre un processus sur mesure.

Les projets simples n’ont besoin que d’une feuille de route de haut niveau et d’une liste de contrôle pour maintenir la coordination de l’équipe et le projet sur la bonne voie.

Visualisez le travail.

Les projets sont des entreprises complexes qui génèrent une pléthore de données. Il peut être difficile de corréler, de comprendre et de prendre des décisions éclairées. Malgré nos meilleures intentions, nous négligeons ou ne remarquons souvent pas les signes avant-coureurs de problèmes.

Les gens sont visuels. Nous reconnaissons rapidement les modèles graphiques. L’utilisation d’outils visuels de management de projet améliore considérablement la capacité du manager de projet et de l’équipe à comprendre le projet, son avancement et ses challenges.  Ces outils peuvent être sophistiqués, mais souvent plus c’est simple, mieux c’est.

Les feuilles de route, les tableaux Kanban et les tableaux de bord sont faciles à utiliser et transmettent rapidement des informations précieuses. Les versions physiques de ces outils fabriquées avec du ruban adhésif et des notes autocollantes sur le mur sont faciles à construire et à ajuster. Des outils collaboratifs peuvent être utilisés pour les équipes virtuelles et promouvoir la transparence, la responsabilité et la collaboration.

Managez les risques, les actions et les problèmes.

Le management proactif des risques, des actions et des problèmes est une activité fondamentale. Le manager de projet doit régulièrement inspecter l’environnement, consigner, suivre et traiter les éléments en cours. Il doit y avoir une cadence et un processus réguliers au niveau de l’équipe et de la direction, avec une appropriation et une responsabilité claires. Cela permet à l’équipe de projet de ne pas négliger ou oublier des éléments critiques qui pourraient faire dérailler le projet.

Le détail et la profondeur de ces pratiques doivent être adaptés aux besoins du projet.  L’outil le plus basique peut être une simple feuille de calcul.  Les applications plus sophistiquées peuvent intégrer et hiérarchiser des éléments dans plusieurs flux de travail, créer des rapports de tableau de bord et fournir des alertes.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Adoptez l’amélioration continue.

Il n’y a pas une seule et unique « bonne façon » de manager tous les projets.  Les projets sont des organismes vivants.  Les processus et les pratiques doivent s’adapter et s’améliorer continuellement à mesure que l’équipe et leurs organisations mûrissent et s’adaptent aux événements business externes.

Tous les projets doivent adopter une version de la rétrospective de l’équipe Agile.  Régulièrement, l’équipe examine ses performances, identifie les améliorations et les met en œuvre.  Ensuite, l’équipe confirme que les changements ont été bénéfiques.

Évaluez le processus.

Toutes les grandes organisations ont des gaspillages.  Il y a des retards excessifs, des transferts de tâches et du travail inutile.  Si nous voulons nous améliorer, nous devons faire en sorte qu’il soit plus facile pour nos équipes de fournir plus rapidement de la valeur et des solutions.

Nos processus d’entreprise et nos normes formelles sont souvent conçus pour résoudre des problèmes du passé.  Des correctifs et des pansements ont été appliqués au hasard pour répondre à des préoccupations immédiates plutôt que d’utiliser la pensée systémique et d’envisager une meilleure façon de faire les choses.

Changez les processus !  Examinez d’un œil critique ce que vous faites.  Vos processus apportent-ils une valeur ajoutée ?  Si ce n’est pas le cas, éliminez-les.  S’ils sont nécessaires, rendez-les moins lourds.

Responsabilisez l’équipe.

Les équipes autonomes excellent dans la résolution de problèmes complexes.  Les équipes produisent de meilleurs résultats que les individus seuls.  De multiples perspectives sont prises en compte et intégrées dans la solution.  Libérer le pouvoir créatif d’équipes motivées et engagées est fantastique.

Nous créons des équipes responsabilisées en poussant la prise de décision au niveau responsable le plus bas.  Les personnes les plus proches du travail connaissent le mieux le processus et sont les plus proches de l’information.  Lorsqu’elles prennent leurs propres décisions, elles sont responsables et se sentent redevables.

L’autonomisation est plus facile à dire qu’à faire.  Cela nécessite souvent de réinitialiser la culture, les normes et les standards de l’équipe et de l’entreprise.  La micro management doit être remplacé par un état d’esprit de donner son meilleur et de coaching.  Lorsque nous punissons les erreurs, elles ne s’arrêtent pas.  Elles deviennent cachées, et l’impact s’aggrave.

Ayez des processus cohérents et reproductibles.

Ne recherchez pas la standardisation.  Les projets sont uniques.  Nous ne produisons pas des gadgets.  Efforcez-vous d’assurer cohérence et répétabilité.  Développez et affinez en permanence des pratiques de management de projet contextuelles qui permettent la personnalisation.  Élaborez des modèles de livraison qui favorisent l’efficacité, la durabilité et la répétabilité.

© 2024, Alan Zucker ; Project Management Essentials, LLC

Management de projet hybride : Quels changements ?

Vous avez apprécié le précédent billet de Alan Zucker « Qu’est-ce que l’hybride ? », découvrez la suite avec « Quels Changements ? ».

Comment les approches de management de projet Prédictive, Agile, Lean/Kanban et Hybride peuvent-elles être représentées dans les principaux domaines du management de projet.

Hybrid Project Management: Part 2, What Changes? par Alan Zucker

https://www.velociteach.com/2024/06/hybrid-project-management-part-2-what-changes/

Nous devrions considérer les approches de management de projet comme une palette d’options.  Prédictive, Agile et Lean/Kanban forment les limites.  L’hybride est le vaste espace intérieur.

Le premier article de cette série décrivait les limites et le mélange de couleurs des approches :

  • Prédictif.  L’approche traditionnelle, en cascade et très structurée.
  • Agile (Scrum).  Une approche adaptative avec des équipes autonomes et auto-organisées.
  • Lean/Kanban.  Des principes axés sur les valeurs et les flux qui peuvent être intégrés dans toutes les approches.
  • Hybride-prédictif.  Principalement des structures traditionnelles avec des pratiques agiles intégrées.
  • Hybride-Agile.  Une approche adaptative tempérée par les contraintes traditionnelles.

Cet article explique comment ces approches peuvent être reflétées dans les domaines centraux de management de projet.

Phases du projet

L’approche projet devient une caractéristique déterminante dans la description des phases du projet et de la manière dont elles sont exécutées.

Le prédictif suit une approche rigide et séquentielle. Les passages de points de contrôle marquent l’achèvement de chaque phase.

Scrum se caractérise par une série d’itérations de conception-construction-test (sprints), qui durent généralement deux semaines.

Les projets prédictifs-hybrides suivent la structure prédictive. Cependant, les phases peuvent se chevaucher.  Un modèle typique est le chevauchement de la conception avec le développement, et du développement avec les tests.  Les examens de fin de phase peuvent être informels ou ne pas être utilisés.

Les projets hybrides-agiles suivent un modèle de type Scrum mais sont soumis à des contraintes de projet plus traditionnelles. Le développement est itératif, mais les tests peuvent être réalisés en dehors des sprints.  La livraison peut se faire à la fin plutôt que progressivement.

Scrum-fall est un modèle hybride qui suit une approche séquentielle dans la planification, les exigences et la conception, mais utilise ensuite l’approche itérative pendant la phase de construction.

Kanban se concentre principalement sur le flux de travail.  Les équipes Agile utilisent un tableau Kanban pour gérer la progression des fonctionnalités et des histoires utilisateur.  Les équipes prédictives et hybrides peuvent également utiliser des tableaux Kanban.  Ils peuvent être utilisés pour gérer le flux de documentation ou suivre les activités de développement et de test.

Le domaine des problèmes

Prédictif est optimisé pour les problèmes simples et complexes avec des exigences clairement définies.

Scrum est conçu pour résoudre des problèmes complexes dont la solution n’est peut-être pas immédiatement apparente. Des informations supplémentaires, des commentaires et des améliorations sont nécessaires pour comprendre le problème et concevoir la solution.

L’approche Kanban basée sur les flux prend facilement en charge les problèmes simples et compliqués, car les étapes du processus sont définies et bien comprises.  L’objectif est de maximiser la création de valeur avec le délai de livraison le plus court.

Les préférences organisationnelles et d’autres considérations externes guident souvent la décision du choix de l’approche de projet.

Les organisations ont tendance à utiliser l’approche dominante, quel que soit le type de problème.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Portée, échéancier, coût et modification

Les projets prédictifs se caractérisent par une portée, un échéancier et un coût fixes.  La triple contrainte classique affirme qu’un changement de portée nécessite un changement correspondant de délais ou de coûts.  Par conséquent, le changement est géré au moyen d’un processus formel et structuré.

Les projets agiles renversent la triple contrainte.  La portée est émergente, et le temps et le coût peuvent être fixes.  La limite de temps du projet limite la portée. Le Product Owner et les parties prenantes examinent et redéfinissent régulièrement les priorités des fonctionnalités requises. Un processus léger peut être utilisé pour gérer le changement.

La plupart des organisations qui utilisent des approches hybrides conservent l’état d’esprit prédictif à portée fixe, ce qui crée des tensions avec la portée émergente d’Agile. Pour beaucoup, abandonner la triple contrainte s’apparente à s’ interroger sur la loi de la gravité. L’hybrid-agile a du mal à concilier le principe « embrasser le changement » du Manifeste Agile avec un état d’esprit fixe. 

Engagement des parties prenantes

Les projets prédictifs traditionnels ont un engagement limité des parties prenantes.  L’engagement est élevé lors de la collecte des exigences et pendant les phases de tests utilisateur et de mise en production.  L’engagement est léger et se limite généralement à des mises à jour de statut d’avancement pendant les phases d’exécution.

L’agilité valorise un engagement régulier et cohérent des parties prenantes. Le Manifeste prône la « collaboration client ». Le Product Owner est la voix des clients et fait partie intégrante de l’équipe de développement.

Les projets hybrides-prédictifs impliquent un engagement plus fréquent des parties prenantes, un modèle qui existe depuis l’avènement de l’approche « en cascade ». La conception conjointe d’applications (Joint Application Design / JAD) et d’autres pratiques ont été élaborées pour impliquer les parties prenantes dans la solution et fournir une rétroaction précoce.

Les projets hybrides-agiles adoptent les principes d’un engagement régulier.

Dans la pratique, plusieurs défis se posent souvent :
  • Les documents d’exigences traditionnels sont rédigés et traduits en histoires utilisateur, ce qui réduit la collaboration entre le client et le développeur sur la solution.
  • Le Product Owner n’a pas les compétences ou l’expérience nécessaires pour ce rôle critique.
  • Les clients ne sont pas suffisamment impliqués dans les démonstrations utilisateurs et effectuent des tests d’acceptation seulement à la fin.

Approche de management

L’approche traditionnelle de management descendante est associée aux projets prédictifs. Le/la manager de projet est responsable de la réussite du projet et anime l’équipe. Les managers de projet sont habilités à prendre des décisions, à attribuer des tâches et à gérer l’exécution du travail du projet.

Agile adopte une approche résolument différente de management.  Les équipes agiles s’auto-organisent.  Le/la Scrum Master est un facilitateur et un leader serviteur dont le rôle principal est d’aider l’équipe et l’organisation à mûrir.  Un principe de Scaled Agile consiste à « libérer la motivation intrinsèque des travailleurs du savoir ».

La théorie X et Y de Douglas MacGregor  incarne la dichotomie entre les approches prédictives et agiles.

  • Les managers de la théorie X caractérisent le modèle industriel traditionnel, où l’on ne peut pas faire confiance aux travailleurs. Le rôle de la direction est d’assurer la surveillance et le contrôle.
  • Les managers de la théorie Y sont l’antithèse. Les gens veulent faire du bon travail, et le rôle de la direction est de créer un environnement où les gens peuvent réussir.

L’approche de management des projets hybrides dépend souvent de facteurs externes. La phase de conception d’un projet de construction peut chercher à libérer les énergies créatives, tandis que la phase d’exécution peut se concentrer sur le respect du plan.  La culture, la structure de l’équipe et les personnalités individuelles jouent également un rôle essentiel.  J’ai observé des leaders participatifs dans des projets prédictifs et des leaders autocratiques dans des projets agiles.

Processus et documentation

Les projets prédictifs nécessitent une documentation importante et un respect strict des processus. L’approche a évolué en partant des projets de construction, où le coût du changement est élevé. Des spécifications de conception détaillées sont nécessaires et constituent le principal moyen de transmettre l’information.  Les normes réglementaires ou organisationnelles internes peuvent également être des considérations importantes.

L’agilité a évolué à partir du développement de logiciels, où le coût du changement est faible. De petites équipes pluridisciplinaires peuvent développer efficacement des solutions à des problèmes complexes. Par conséquent, le manifeste Agile a remis en question la nécessité d’une « documentation excessive » et a valorisé « les individus et les interactions plutôt que les processus et les outils ».

Agile ne rejette pas toute documentation ou processus. Il a adopté une norme « minimalement suffisante », c’est-à-dire la sélection du niveau approprié de processus et de documentation requis pour un projet. Une grande équipe géographiquement dispersée qui développe un système critique nécessite plus de contrôle qu’une petite équipe colocalisée qui développe une application non critique.

Les projets hybrides doivent établir processus et documentation pragmatiques et contextuels (empruntant à Disciplined Agile). Les principes du Lean et du Kanban peuvent guider ce processus, en éliminant le gaspillage et en apportant de la valeur dans les délais les plus courts possibles.

Les projets hybrides-agiles sont souvent confrontés à des contraintes externes, telles que des exigences contractuelles, réglementaires ou organisationnelles, par exemple, le développement de logiciels agiles sur un projet gouvernemental.  Les contraintes contractuelles peuvent nécessiter plus de documentation, des tests d’acceptation hors sprint ou un processus de management du changement plus structuré.

© 2024, Alan Zucker ; Project Management Essentials, LLC

Management de projet hybride : Qu’est-ce que l’hybride ?

Le management de projet hybride vient de connaître son heure de gloire !

Hybrid Project Management: Part 1, What is Hybrid? par Alan Zucker

https://www.velociteach.com/2024/05/hybrid-project-management-part1-what-is-hybrid/

Le management de projet hybride vient de connaître son heure de gloire !

Le Project Management Institute Pulse of the Profession® 2024 déclare que l’approche hybride (32 %) est maintenant la deuxième approche la plus couramment utilisée.  L’approche prédictive (44 %) détient toujours une avance considérable.  Et l’utilisation d’Agile (26 %) perd 2 points.

Avant de nous enthousiasmer, le rapport sur l’état de l’agilité (State of Agile Report) identifie différentes tendances.  et ses répondants préfèrent l’agilité (70 %) à l’hybride (47 %) et à l’approche prédictive Waterfall (35 %).

Derrière cette annonce

Plusieurs facteurs peuvent être à l’origine de ces tendances récentes :

Agile et Waterfall sont les angles du continuum de management de projet, et l’hybride en est le vaste milieu. La plupart des organisations ne pratiquent ni l’agilité pure ni l’approche prédictive ; L’hybride est donc une description plus exacte.

L’intérêt pour les hybrides est nouveau et augmente rapidement. Le format de l’ examen PMP a changé en janvier 2020.  Dans le nouveau test, 27 % des questions étaient hybrides et 23 % agiles. Cela a déclenché une explosion du trafic de recherche Google pour le « management de projet hybride ».

Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes

La formation agile a atteint un point de saturation. Scrum Alliance compte 1,5 million de certificié.e.s, et Scaled Agile (SAFe) plus d’un million de personnes formées. En comparaison, il y a environ 1,5 million de managers de projet certifiés (PMP).

Agile a peut-être « heurté le mur ». L’agilité est fondamentalement un état d’esprit, pas une méthodologie.  Les principaux défis de l’adoption de l’agilité sont organisationnels et culturels.  Le rapport sur l’état de la culture Agile montre que seuls 10 % des leaders font preuve des qualités souhaitées.

La palette d’approches de projet

La profession de manager de projet se décrivait historiquement en termes discrets. Waterfall avait une emprise quasi monopolistique jusqu’à l’avènement de l’agilité. La profession est alors entrée dans un monde bipolaire : agilistes contre traditionalistes.

En réalité, le management de projet est désordonné.  On peut le décrire comme « la cathédrale versus le bazar ».  Les développeurs de cadres de travail parlent dans les termes absolutistes de la cathédrale, tandis que les managers de projet mélangent les pratiques comme on le voit dans un bazar.

Hybride nous permet de donner un nom à ce mélange de la vaste palette de couleurs. Prédictif, agile et Lean/Kanban peuvent être considérés comme les pointes d’un triangle avec un éventail presque infini d’options.

Le spectre des approches peut être étiqueté comme suit :

  • Prédictif.  L’approche traditionnelle, prédictive et très structurée ;
  • Agile (Scrum).  Une approche adaptative avec des équipes autonomes et auto-organisées ;
  • Lean/Kanban.  Des principes axés sur les valeurs et les flux qui peuvent être intégrés dans toutes les approches ;
  • Hybride-prédictif.  Des structures principalement traditionnelles avec des pratiques agiles intégrées ; et
  • Hybride-agile.  Une approche adaptative tempérée par les contraintes traditionnelles.
Relisez ce billet : « Que signifie vraiment ‘en cascade’ (Waterfall) dans le management de projet ? Comment les gens utilisent-ils cette expression ? »

Prédictif

Winston Royce a décrit pour la première fois l’approche waterfall en 1971 comme une méthodologie de développement logiciel basée sur son expérience de la construction de systèmes pour les engins spatiaux.  Il a défini une série d’étapes en cascade allant de la collecte des besoins aux opérations de déploiement.

relisez ce billet sur les bénéfices de l’approche Waterfall (‘en cascade’)

L’établissement précoce des exigences et des spécifications de conception est une caractéristique essentielle des projets prédictifs.  Cette approche est utilisée dans la construction et les efforts similaires où le coût du changement est élevé.  Les projets ont souvent des passages de phase rigides pour confirmer la viabilité et l’exhaustivité avant de passer à l’étape suivante.

Les équipes de projet travaillent sur leurs composants individuels et intègrent et testent périodiquement leur travail. Le rôle principal du manager de projet est de coordonner et de superviser les efforts de ces équipes alignées sur le plan fonctionnel.  Une collaboration inter-équipes limitée est nécessaire.

L’engagement des parties prenantes est plus important au début du projet, lorsque les exigences sont collectées et analysées.  Tout au long du cycle de développement, il y aura des réunions et des revues périodiques de l’état d’avancement.  Il faut souvent des années avant que les parties prenantes ne voient le produit fini.

Agile (Scrum)

L’agilité est un état d’esprit, pas une méthodologie.  De multiples cadres de travail frameworks (Scrum, eXtreme Programming, DSDM, Scaled Agile (SAFe), Disciplined Agile, etc.) permettent aux équipes de fournir de la valeur plus rapidement et de manière plus prévisible.  Les cadres de travail ne sont pas monolithiques et représentent un éventail d’approches et de pratiques.

Scrum est la méthodologie la plus couramment utilisée et ancre cet angle du triangle. Scrum décrivait à l’origine comment développer un nouveau produit et a ensuite été adopté pour des projets logiciels complexes par Jeff Sutherland et Ken Schwaber.

Plusieurs vidéos intéressantes sur Scrum en langue anglaise

Royce s’est rendu compte que les cycles de test tardifs et les délais de livraison prolongés de l’approche prédictive waterfall posaient un risque important.  Scrum atténue ces risques grâce à son approche itérative et incrémentielle.  Les cycles de développement sont généralement limités à 2 semaines, après quoi les parties prenantes fournissent des retours. Le retour d’information est utilisé pour adapter et ajuster le produit et éviter le piège du « je le saurai quand je le verrai ».

Les équipes Scrum sont petites (moins de 10), auto-organisées et exploitent les énergies créatives des travailleurs du savoir. Le manager de projet de type « commande et contrôle » est remplacé par le scrum master serviteur, dont le rôle principal est d’aider l’équipe à mûrir.  Le Product Owner est un membre à part entière de l’équipe et représente la voix du client.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Lean/Kanban

Le Lean et le Kanban sont un ensemble de principes et de pratiques, datant des années 1950, développés à l’origine par Toyota. Le Lean se concentre sur la création de valeur et l’élimination du gaspillage.  Kanban est une sous-pratique Lean qui se concentre sur la création et la gestion de flux.

Tableau Kanban pour tâches et projets avec Christian Hohmann

Lean/Kanban est la troisième extrémité du triangle.  Bien qu’ils soient souvent associés à l’agilité, leurs pratiques sont universelles.  Ceci est fondamental pour la plupart des frameworks agiles, et les équipes agiles très matures se concentrent souvent sur le flux (Kanban).  Dans Disciplined Agile, le Lean est défini comme un cycle de vie autonome.  SAFe 6.0 sépare l’équipe Kanban de son approche Scrum.

Hybride-Prédictif

L’hybride-prédictif suit principalement la structure linéaire waterfall et intègre des pratiques de type agile.  La structure conception-construction-test-déploiement prend en charge efficacement de nombreux types de projets.  Cependant, les approches purement prédictives peuvent être rigides et reposer sur l’hypothèse forte que la solution peut être définie dès le début du projet.

Avez-vous déjà lu ce billet : Qu’est-ce que Agile Hybride en réalité ?

Les équipes logicielles ont commencé à utiliser des approches en « waterfall modifié » dans les années 1970, bien avant l’avènement de l’agilité.  Ils ont utilisé des approches itératives et progressives pour mobiliser les intervenants.  Des sessions de prototypage et de conception d’applications conjointes (JAD) ont permis aux utilisateurs et aux développeurs de collaborer sur la solution.

Même la construction, qui est le bastion de l’approche en cascade, a adopté l’hybride.  Traditionnellement, la conception et la construction sont des activités spécialisées et séparées.  Les firmes d’architecture et d’ingénierie créent des plans et des devis qui sont ensuite exécutés par les entreprises de construction.  Cependant, la conception-construction combine ces deux activités en un seul contrat exécuté par une seule entreprise.  Cette approche améliore la collaboration, la coordination et la communication.  Les avantages sont des cycles de développement plus courts, des coûts réduits, moins d’erreurs et une responsabilité claire.

L’approche prédictive-hybride peut être décrite comme penchant davantage vers la structure waterfall et intégrant des pratiques agiles.  Il existe plusieurs modes d’utilisation.  L’un est un projet structuré qui utilise des techniques agiles telles que des stand-ups quotidiens, une documentation minimale suffisante et un engagement fréquent des parties prenantes.  Un autre modèle est la conception initiale de haut niveau avec un développement itératif et/ou une livraison incrémentielle.

Hybride-Agile

De nombreuses organisations prétendant être agiles utilisent probablement une approche hybride-agile. Elles suivent un modèle de type Scrum et utilisent de nombreuses pratiques agiles. Cependant, des contraintes empêchent l’adoption de l’état d’esprit agile.  Ces limites sont souvent liées à la culture, à la structure et à la nature du travail de l’organisation.

Les grandes entreprises bureaucratiques, les agences gouvernementales et les organisations à faible maturité agile correspondent à ce modèle.  Elles peuvent suivre de nombreuses pratiques de Scrum ; Cependant, elles font face à de nombreux défis, notamment :

  • Le contenu du projet est fixe et la solution complète est livrée à la fin du projet.
  • Les parties prenantes ne participent pas activement aux démonstrations progressives du produit et des tests d’acceptation approfondis par les utilisateurs sont effectués à la fin.
  • Les équipes ne sont pas habilitées à prendre des décisions.  Les décisions sont prises par la direction ou par un comité.
  • Les équipes ne sont pas établies depuis longtemps et les membres sont affectés à plusieurs projets.
  • Le Product Owner vient de l’équipe technique et ne représente pas pleinement la voix du client.

“PMI”, the PMI logo, “PMP”, “PMBOK”, “PM Network”, “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.

Toute augmentation des travaux en cours d’exécution dans votre projet Agile augmente automatiquement les délais !

Connaissez-vous la loi de Little en management de projets Agile et en Management de Portefeuille de projets ?

La loi de Little porte le nom de son inventeur, John Little, qui a établi la théorie des files d’attente dans les années 1950s.

Au départ, la loi avait pour objectif de fournir une formule très simple pour juger de l’efficacité d’un système de gestion de file d’attente.

En 1961, Little a énoncé son théorème :

Le nombre de clients dans une file d’attente est égal au taux d’arrivée moyen des clients multiplié par le temps nécessaire pour les traiter.

Puis, cette loi fut souvent utilisée dans les approches Lean pour réduire les délais. Elle permet de calculer le temps moyen passé dans un système de production entre le début et la fin d’une tâche. L’objectif est bien sûr d’augmenter la capacité de production.

De nos jours, la loi de Little est utilisée dans les approches Agile, en particulier avec Kanban, car elle établit un lien très clair entre le WIP (Work In Progress – Travail en cours), le Lead Time LT (temps moyen pour exécuter une tâche) et le Taux de production T (le débit).

Cette formule est souvent exprimée ainsi :

WIP = T x LT

ou encore

LT = WIP / T

Toute augmentation des travaux en cours WIP augmente automatiquement les délais.

Dans les faits, certaines entreprises ont tendance à faire l’inverse. Elles augmentent les travaux en cours dans l’espoir d’augmenter la production et il en résulte souvent un total désastre en ce qui concerne le respect des délais.

De même, si une entreprise a du mal à exécuter tous les projets en cours, en lancer de nouveau a peu sinon aucune chance d’améliorer la situation. Or, c’est encore trop souvent ce qui se produit.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

La loi de Little dans le cadre du management de projet

Nous pouvons utiliser cette loi pour mieux comprendre pourquoi nous avons de meilleures chances de les mener à bien en manageant plus efficacement les projets en cours plutôt qu’en lançant d’autres projets.

Cela correspond comme je l’ai mentionné précédemment aux objectifs recherchés par le management des flux avec Kanban dans les projets Agiles.

Lancer trop de projets engorge les processus, surcharge les horaires de travail des développeurs et allonge considérablement le temps de réalisation.

Prenez un exemple :

  • Si, à ressources constantes, vous lancez en parallèle 3 projets d’une durée moyenne de 1 an, il vous faudra 3 ans pour compléter chacun d’entre eux.
  • Alors que si vous lancez les projets 1 par 1, vous aurez le premier au bout d’une année, le second au bout de 2 et le troisième de 3.

Avec l’approche « séquentielle », vous pouvez donc commencer à récolter les bénéfices de votre premier projet 2 ans plus tôt qu’avec le lancement de tous les projets en parallèle et les avantages du second une année plus tôt.

Ces bénéfices peuvent être ce qui fera ou défera le succès de votre organisation tant vos capacités d’auto-financement sont de plus en plus importantes.

Bien sûr, tout n’est pas si linéaire…

En fait, si le premier projet est délivré après 12 mois, il vous faudra supporter sa mise en production, corriger les erreurs, écouter les retours des utilisateurs, effectuer quelques ajustements impératifs…

Même avec un plan de mise en production accompagné de ressources additionnelles dédiées au support en sus des développeurs, il y aura probablement des impacts non négligeables sur leur charge de travail.

Donc, en réalité, je ne pense pas que vous terminerez systématiquement le second projet 24 mois après la date de début. Et je suis quasiment certain que le troisième projet ne sera pas fini dans la période cible de 3 ans.

Mais, en revanche, il est certain que vous obtiendrez des bénéfices des projets numéros 1 et 2 beaucoup plus tôt que si vous lancez les 3 en parallèle.

Prenez aussi en compte les dégradations de performance dues au multi-tâches permanent.

Il est clair que plus vos employés ont de projets sur lesquels ils travaillent en parallèle, plus les délais d’exécution de chacun de ces projets seront longs.

Le temps de passage d’un projet à l’autre en cours de journée ou de semaine, le switching time, est à ajouter à vos délais. En effet, cela consomme du temps que de poser votre crayon sur un sujet, vous remettre dans le contexte de votre autre tâche ou projet, puis être à nouveau pleinement productif sur celui-ci. C’est l’une des raisons pour lesquelles le multi-tâches est fortement déconseillé en approche Agile où toute l’équipe doit travailler ensemble.

En limitant le nombre de projets en cours, les ressources nécessaires sont disponibles et davantage focalisées. Le résultat est un achèvement du projet bien plus tôt.

Et pour le management de Portefeuille de Projets (PPM) ?

Project Portfolio Management dimensionsLa loi de Little est un excellent principe à suivre dans le management des portefeuilles de projets (PPM) car elle vous permet de conserver une vue d’ensemble tout en optimisant la mise en œuvre opérationnelle.

Il vous reste cependant (encore et toujours) à bien travailler les business cases pour être certains de choisir le bon ordre de séquencement des projets !

Plus spécifiquement sur les projets Agiles

Que l’approche de développement soit Agile ou prédictive, il est critique dans chaque projet sélectionné de bien travailler sur la liste des fonctionnalités souhaitées et les prioriser en fonction des bénéfices attendus de chacune d’entre elles.

C’est en Agile en grande partie la responsabilité du Product Owner.

Et c’est, selon moi, aussi là qu’un intérêt majeur des approches Agiles va se matérialiser : Savoir quand s’arrêter !

En effet, en plus de livrer au plus tôt les fonctionnalités les plus critiques, en approche Agile vous pouvez et devez décider quand dire stop.

En arrêtant votre projet dès que les bénéfices additionnels ne justifient plus de mobiliser les ressources allouées, vous allez les libérer pour le projet suivant qui apportera davantage de bénéfices à l’entreprise.

Il y a là bien sûr un fort risque de ne jamais terminer un projet à 100% par rapport à son business case originel. Mais ceci est-il réellement un problème ?

J’ai vu dans tous les projets que j’ai suivi des fonctionnalités très prometteuses sur le papier n’être que faiblement voire jamais utilisées alors qu’elles nous avaient coûté un bras. C’était rarement dû à une pauvre qualité du livrable. Il s’agissait plutôt de besoins qui avaient évolués pendant la durée de développement du projet, ou bien dus à des changements dans les processus ou les organisations qui étaient parfois encore plus « Agiles » que nos développeurs.

Quelle est votre expérience de cette Loi de Little ?

Avez-vous trouvé l’Agile que vous cherchez ?

« I Still Haven’t Found The Agile I’m Looking For » de Chad Beier

Et vous, l’avez-vous trouvé ?

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

PRINCE2 Agile et Kanban : Rendre les tâches du projet plus visibles !

L’utilisation de Kanban dans les projets est un moyen simple et direct d’aider les équipes à augmenter leur efficacité de travail en visualisant la charge de travail.

https://www.axelos.com/news/blogs/july-2020/prince2-agile-kanban-making-project-tasks-visible par Andrea Vecchi

Parmi les conseils disponibles dans PRINCE2 Agile®, Kanban un outil qui devrait être dans la boîte à outils de chaque chef de projet, en particulier dans les environnements moins complexes.

Kanban, conçu à l’origine pour améliorer l’efficacité dans la fabrication, est maintenant davantage utilisé pour visualiser les tâches d’un projet, affichées sur un tableau avec des notes autocollantes. De cette façon, il aide à rendre la planification plus facile et accessible à tous.

Cela est particulièrement vrai pour les personnes qui ne sont pas des managers de projet professionnels et qui ont du mal à utiliser un échéancier comme outil quotidien de gestion de projet. Kanban rend la planification si immédiate que les gens l’utilisent réellement !

Dans mon rôle de manager de PMO, je conseille aux chefs de projet professionnels d’utiliser Kanban comme un moyen de visualiser le plan de projet et, dans la mesure du possible, de basculer entre cela et leur vue de la planification. La vue Kanban se concentre sur ce que les gens font réellement, facilite la compréhension de la charge de travail de chacun et aide à hiérarchiser les tâches.

L’utilisation de la vue Kanban avec les nombreux petits projets moins complexes de notre entreprise nous aide à manager par exception selon le principe de PRINCE2. C’est parce que cette vue montre vraiment ce qui se passe avec une tâche et met en évidence quand il est nécessaire d’escalader au comité de projet. Cela aide également le comité à appréhender le planning, car ses membres ne participent pas au projet au jour le jour.

S’habituer au Kanban

Parfois, c’est le nom « Kanban » qui est un obstacle pour les gens. Cependant, une fois qu’ils comprennent le concept et commencent à l’utiliser, ils voient à quel point il est utile, puis Kanban devient une partie du langage et des méthodes de travail.

Par exemple, je travaillais récemment avec des membres de l’équipe dans le cadre d’opérations dans un autre pays.

Nous avions besoin d’un petit projet pilote, mais, pour quelque raison, cela n’a tout simplement pas eu lieu. Il n’y avait tout simplement pas de sentiment d’urgence dans l’équipe pour cela.

Nous avons donc créé une vue Kanban sur un tableau blanc au bureau avec des notes autocollantes et cela a fait une énorme différence. Le planning des tâches est devenu réel et le projet a pris de l’ampleur, les membres de l’équipe ont pu se suivre les uns les autres pour savoir si les tâches étaient terminées ou non et cela a augmenté l’appropriation. En effet, le tableau Kanban a rendu les tâches du projet visibles, physiques, présentes et compréhensibles et a rendu les gens plus responsables.

PRINCE2 Agile et Kanban

Livre sur Amazon

Pourquoi est-ce que je pense qu’il est important d’avoir une connaissance de Kanban et d’autres techniques Lean/agiles avec PRINCE2 Agile ?

Il est important pour les chefs de projet d’utiliser ces méthodes car les outils se rapportent aux contrôles classiques de gestion de projet. Ils aident les équipes à accroître la communication et rassemblent les gens. Les équipes extrêmement efficaces sont celles qui communiquent bien.

Livre sur Amazon

Les managers de projet ont parfois du mal à communiquer avec toute l’équipe et, au lieu de cela, ont recours au contrôle et cherchent à cocher toutes les cases du management de projet. Kanban les aide à être de meilleurs communicateurs.

En fin de compte, il s’agit pour les gens de s’organiser et d’organiser leurs activités plus efficacement afin de faire avancer les tâches en faisant les choses critiques plutôt que d’essayer de tout faire en même temps.

CertYou est partenaire de DantotsuPM

 

Tableau Kanban pour tâches et projets avec Christian Hohmann

Une mini vidéo de 3 minutes très éducative sur l’utilisation de Kanban dans les projets et pour manager une liste de tâches à réaliser.

Un tableau Kanban est un outil de management pour visualiser et gérer des tâches, leur avancement, la charge de travail, focaliser les efforts et plus généralement manager une équipe en mode projet.

Basiquement un tableau Kanban est fait de colonnes représentant le processus (le workflow) et dans lesquelles on déplace des cartes au fur et à mesure de l’avancement du travail dans le processus.

QRP est partenaire de DantotsuPM

La collaboration exige du TEMPS

La collaboration exige un espace dans le planning et l’énergie d’agir avec réciprocité envers les autres !

Collaboration requires TIME

https://tcagley.wordpress.com/2019/05/02/collaboration-requires-time/ par Tom Cagley

le rush
Courir de réunion en réunion

Le temps est la première exigence pour la collaboration. La collaboration exige un espace dans votre planning et l’énergie d’agir de manière réciproque avec d’autres (pour certaines personnes l’énergie nécessaire est plus importante que pour d’autres).  J’ai observé que beaucoup d’agendas des personnes sont si denses qu’elles courent de réunion en réunion. Même quand une ou plus de ces réunions sont structurées pour la collaboration, très souvent le manque de respect des participants l’un envers l’autre en traitant leurs emails ou tâches en retard comme ils feignent de prêter attention.  Récemment j’ai même entendu quelqu’un annoncer qu’il n’allait pas prêter attention à moins qu’il ne pense que quelque chose qui serait abordé l’impactera directement. La réunion avait pour but de réfléchir à un nouveau composant dans un produit de la prochaine génération. Pourquoi était-il là ? Entre son manque de temps et le manque de respect total envers les autres participants, il n’y avait aucune façon dont il pourrait efficacement contribuer.

4 facteurs influencent combien de temps est disponible pour la collaboration

#1 – Importance

Le travail important et porteur de grande valeur crée le temps et l’espace pour la collaboration

L’importance est la perception que le travail a de l’importance et/ou de la valeur. Le travail qui a de l’importance permet de plus facilement créer le temps et l’espace pour que la collaboration se mette en place. L’ennemie jurée de l’importance est l’urgence.  L’urgence réduit le temps disponible pour la collaboration.

#2 – Charge de travail

Le travail qui a été assigné à un individu ou à une équipe peut dramatiquement influencer s’il y aura du temps pour la collaboration. N’importe quelle équipe ou individu avec un travail chargé à 100 % (ou pire) seront immédiatement en retard si quoi que ce soit va mal et il y a toujours quelque chose qui tourne mal. Aussitôt que cela se produira, il réduira ou éliminera le temps prévu dans le processus pour la collaboration. Quand les gens sont stressés, ils prennent des décisions unilatérales parce que c’est expéditif.

#3 – Contrôle

L’entrée de travail (comment le travail entre et est pris en charge par un individu ou une équipe) a un impact énorme sur le temps disponible pour la collaboration. Des systèmes de traction, comme kanban, où les équipes prennent le travail quand elles sont prêtes, augmente le temps disponible pour la collaboration. Les situations dans lesquelles le travail est poussé sur un groupe comme il arrive diminuent le temps disponible pour la collaboration. Les équipes et les personnes ont besoin d’un certain niveau de contrôle de la quantité et du chronométrage de travail qui vient vers elles pour créer le temps et l’espace pour la collaboration.  Sans la capacité de prévoir ni contrôler le travail qu’une équipe doit livrer, il y aura un besoin de garder un amortisseur, un coussin de réserve. Cet amortisseur viendra de la collaboration parce qu’il exige plus de temps que prendre la première réponse ou idée qui apparaissent et se précipiter.

#4 – Prédictibilité

Aussi important que de contrôler l’entrée de travail, la compréhension de combien de travail peut être réalisé dans toute période de temps est également importante. Les équipes avec des délais de livraison fortement irréguliers doivent sévèrement limiter le travail qu’elles embarquent ou garder un amortisseur ou une réserve pour pouvoir respecter leurs engagements.  La collaboration est sacrifiée comme les amortisseurs et réserves sont consommés.

Le concept de collaboration est utilisé de façon presque magique.

En examinant la définition de la collaboration, nous trouvons tous les toutes sortes d’activités différentes depuis des gens travaillant ensemble sur une base transactionnelle jusqu’aux rapports relationnels profonds. Indépendamment de l’activité, toutes commencent par le temps.  Sans le temps exigé pour travailler ensemble, aucune collaboration efficace ne peut arriver.

Kanban pour les procrastinateurs : De la productivité de dernière minute à celle des toutes premières minutes

Le management de la productivité peut s’avérer très difficile, particulièrement pour les procrastinateurs (les indécis qui remettent tout au lendemain).

Kanban for Procrastinators: From Last-Minute to First-Minute Productivity

https://kanbanzone.com/2019/kanban-for-productivity-management/ par Ivana Sarandeska

En fait, autour de 20% des adultes ont été aux prises avec la procrastination au moins une fois dans leur vie. Même les plus fortement motivés et qui réussissent bien y font face. Remettre une tâche à plus tard, comme si ce comportement pouvait la faire disparaitre (ou s’auto-compléter magiquement). La douloureuse vérité est que cette temporisation nous fait perdre du temps de façon sans précédent. Faites-moi confiance, je le sais d’expérience personnelle.

Opter pour la productivité de dernière minute a cependant certains côtés positifs.

Comme les procrastinateurs ont tendance à remettre les choses à plus tard, il y a une forte chance qu’ils sachent exactement que faire et comment le faire. Et à cause de leur approche spécifique du management de la productivité « Faire les choses au moment où ils doivent absolument les faire », ils ont tendance à trouver les solutions les plus faciles et les plus rapides à la plupart des problèmes. Donc, quand ils se mettent vraiment au travail et complètent leurs tâches, ils le font dans des explosions d’énergie, de concentration intense et de brillante efficacité.

Bien que la procrastination puisse sembler inoffensive et positive, toujours choisir de remettre à plus tard au lieu de s’y mettre ici et maintenant endommage notre productivité.

Alors, pourquoi continuons-nous à remettre à plus tard ? Les raisons peuvent être diverses. Depuis être si perfectionnistes et tant magnifier l’importance des erreurs et échecs que certaines personnes évitent complètement une tâche. Jusqu’à avoir un manque  d’information et ne pas savoir où commencer. Ou encore choisir de petites tâches et avoir le sentiment d’être occupé et reporter des tâches plus grandes, plus importantes. Ou bien perdre sa concentration à cause d’appels téléphoniques et emails, ou par simple manque de motivation.

Bien que, le plus généralement, ce soit en raison d’une mauvaise gestion du temps et de sa productivité, on croit qu’il nous reste largement assez de temps pour achever la tâche. Le tout, selon mon expérience personnelle et l’expérience d’autres procrastinateurs.

Heureusement, sortir de cette boucle de productivité de dernière minute et réaliser un changement est possible.

Tout ce dont vous avez besoin est la volonté et la persévérance. Le choix et l’utilisation du bon outil en support de votre équipe sont aussi d’une grande aide. Donc plongeons dans les détails et pour commencer, considérons les bénéfices de la productivité dès les premières minutes.

Utilisez Kanban pour combattre la procrastination

Beaucoup de personnes se demandent si l’utilisation d’un outil spécifique de management de projet peut réparer leur gestion de la productivité. Eh bien, il le peut. Peu importe combien intangible cela peut sembler, utiliser une méthodologie spécifique et ses outils peuvent énormément changer la façon dont vous réfléchissez et ressentez l’achèvement de vos tâches. En outre, cela peut vous aider à être plus organisé et responsable de terminer le travail sur lequel vous vous êtes engagés.

L’une de ces méthodologies qui peut changer la façon dont vous approchez l’achèvement des tâches est Kanban. Kanban est une méthodologie qui utilise la visualisation et les limites de travail en cours, Work In Progress / WIP, comme les 2 composants principaux pour amener à la productivité. Mais laissez-moi la décomposer et vous expliquer comment utiliser Kanban pour combattre la procrastination.

CertYou est partenaire de DantotsuPM

Ayez une image claire du travail à venir

La mise en œuvre de Kanban commence par la visualisation du flux complet de travail (le workflow) sur un tableau Kanban. Prenez votre processus et créez une colonne pour chacune de ses étapes. Cela vous aidera à acquérir une meilleure vue d’ensemble de comment les tâches s’enchainent et comment elles sont connectées l’une à l’autre.

Après avoir visualisé le workflow, pour l’étape suivante, créez des cartes Kanban pour toutes les tâches.

Remplissez votre arriéré (backlog) et distribuez le travail en cours dans les colonnes respectives. Prenez les tâches les plus grandes et divisez-les en morceaux plus petits. Assignez-les alors aux bonnes personnes. Des tâches plus petites se déplacent plus rapidement dans le tableau Kanban et vous aurez le sentiment que vous accomplissez constamment quelque chose.  Et le projet ne semblera plus si gigantesque.

Voici les premiers pas vers la mise en place d’un système de gestion de productivité efficace. Une fois que vous aurez tout le travail clairement visible, il sera plus facile d’organiser le travail. Et cela vous libérera (et l’équipe) de devoir vous rappeler ce que vous devez faire ensuite.

Hexagon est partenaire de DantotsuPM

Réduisez le multitâche et limitez les interruptions

Quand vous placez le processus entier et les tâches en cours sur un tableau Kanban et l’affichez publiquement, chacun en prendra davantage conscience et se sentira plus responsable. Cependant, si vous voulez réduire efficacement le nombre de distractions et réduire au minimum le multitâches, vous devez ajouter une dimension importante à votre tableau Kanban : les limites de WIP (le travail encours).

Les limites de WIP sur votre tableau Kanban limitent le nombre de tâches que vous pouvez prendre de l’arriéré à l’instant T.
à télécharger en ligne

Elles sont cruciales pour atteindre un nombre de tâches finies, au lieu de constamment en commencer de nouvelles. De plus, l’approbation sociale et la récompense sociale liée à terminer votre travail dans les temps et contribuer à un travail bien fait vous motivent tant, qu’elles peuvent même surpasser l’importance d’une récompense financière. En conséquence, les membres d’équipe sont « forcés » de travailler sur une tâche à la fois, restant ainsi plus concentrés et devenant plus productifs.

Répartissez pour vaincre

Vous pouvez travailler excellemment bien sous la pression. Vous l’avez prouvé pendant votre période de procrastinateur. Mais, vous n’êtes pas tout-puissant. Et il n’y a aucun nécessité de faire tout par vous-même quand vous faite partie d’une équipe. Il y a toujours quelqu’un dans votre équipe qui connait la meilleure solution à votre problème. Aussi, pourquoi ne pas demander de l’aide et gagner du temps ?

La collaboration fait partie de la philosophie de Kanban, mais la délégation aussi.

Suivez soigneusement comment les tâches sont décomposées et assignées et si vous remarquez qu’il y a un déséquilibre, dites-le. Chacun devrait se voir assigné autant de travail qu’il peut en achever et des tâches pour lesquelles il est qualifié. Communiquez régulièrement avec votre équipe pour vous assurer que personne n’est surchargé, sous-chargé, ou a été assigné du travail hors de portée de ses capacités. La répartition appropriée du travail est cruciale pour établir un système de management de productivité efficace.

Le management de la productivité commence par VOUS

La vérité est qu’aucun outil ni méthodologie que vous choisissez ne changera magiquement la façon dont vous approchez votre travail à moins que vous ne vouliez vraiment l’utiliser et persévérer dans ses pratiques et principes.

Aussi difficile que cela puisse être de changer des habitudes existantes, c’est possible.

Une fois que vous y mettez votre volonté, vous pouvez changer la manière dont vous faites des choses. Donnez une vraie chance à un système de management de productivité et ayez la discipline de l’utiliser régulièrement jusqu’à ce qu’il devienne votre nouveau normal.

Même si utiliser Kanban pour visualiser le travail qui se dirige vers vous peut sembler contre-intuitif pour combattre la procrastination, faites-moi confiance, ça ne l’est pas.

Avoir la vue d’ensemble, comprendre où vous en êtes et combien votre rôle est crucial, peuvent en réalité augmenter votre volonté de vous engager.

Quand le travail de l’équipe entière est affiché sur le tableau, cela accroit la responsabilité. Les gens sont motivés pour compléter leurs tâches plus rapidement, donc la procrastination se réduit. Et vous vous déplacez lentement de la productivité de dernière minute à celle des premières-minutes.

Quelques autres billets parus précédemment sur ce sujet

Guide Kanban pour les équipes Scrum par Scrum.org

Un tout nouveau guide disponible gratuitement et traduit en français.

 

à télécharger en ligne

L’approche Kanban, orientée flux, peut améliorer et compléter le cadre de travail (Framework) Scrum ainsi que sa mise en œuvre. Les équipes peuvent ajouter des pratiques Kanban complémentaires, qu’elles débutent avec Scrum ou l’utilisent déjà.

Le Guide Kanban pour les équipes Scrum est le résultat d’une collaboration entre des membres de la communauté Scrum.org et des leaders de la communauté Kanban.

Ensemble, ils supportent Le Guide Kanban pour les équipes Scrum. Ils partagent la conviction que les professionnels du développement de produits peuvent bénéficier de l’application de Kanban couplée à celle de Scrum.

CertYou est partenaire de DantotsuPM

Comment marchent les classes de service dans #Kanban ?

Les classes ou catégories de services servent à établir l’ordre de priorité des travaux en fonction du coût des retards (CoD – Cost of Delay)

Les équipes doivent être en mesure de gérer les dépendances et d’assurer l’harmonisation avec les jalons. Kanban utilise le concept de classe de service pour aider les équipes à optimiser l’exécution de leur arriéré.

Les catégories de services aident à différencier les items de l’arriéré (product backlog) en fonction du CoD. Chaque catégorie de service a une politique d’exécution précise que l’équipe accepte de suivre.

Par exemple :

  • Standard – Représente la catégorie de service de base applicable aux travaux qui ne sont ni accélérés ni à date fixe. La plupart des éléments de l’arriéré devraient entrer dans cette catégorie. Le CoD est linéaire pour les tâches standards, ce qui signifie que la valeur ne peut être atteinte avant la livraison, mais il n’y a pas d’exigence de date fixe.

 

  • A date fixe – Décrit les travaux qui doivent être livrés à une date précise ou avant. En règle générale, le CoD de ces items est non linéaire et est très sensible aux petits changements de la date de livraison; ceux-ci doivent être managés activement pour atténuer le risque lié au planning. Par conséquent, ces éléments sont passés en développement suffisamment tôt pour être terminés dans les délais. Certains peuvent nécessiter une analyse complémentaire pour préciser la durée estimée. Certains doivent être reclassés comme accélérés si l’équipe prend du retard.

 

  • Accéléré – Un élément de l’arriéré dont le CoD est inacceptable nécessite une attention immédiate. Il peut entrer en développement, même en violation des limites actuelles des Travaux en Cours (WIP – Work In Progress). En règle générale, il ne peut y avoir qu’un seul item accéléré dans le système à la fois, et les équipes peuvent établir une approche pour que cet élément avance rapidement dans le système. Si les équipes constatent que de nombreux articles nécessitent une intervention rapide, le système est probablement surchargé. Soit la demande dépasse la capacité, soit le processus d’entrée peut nécessiter plus de discipline. Quoi qu’il en soit, le processus doit être ajusté.

© Scaled Agile, Inc.

Rappel: Le rapport 2019 des tendances Scrum Master est disponible (texte et vidéo)

Scrum Master Trends Report 2019

https://age-of-product.com/scrum-master-trends-report-2019-free-download/

Les points saillants du rapport 2019

PMGS est partenaire de DantotsuPM

81 % utilisent Scrum avec d’autres pratiques agiles : Kanban, DevOps, XP.

– Les Scrum Masters avec une formation formelle Scrum et des certifications Agile ont des salaires plus élevés que les autres.

– Les tendances d’adoption montrent que 7 % continuent à utiliser l’approche Waterfall tandis que 11 % sont matures dans leur adoption Agile; les participants restants (donc la très large majorité) commencent ou sont en croissance d’usage.

– Les salaires des femmes Scrum Masters tendent à être plus élevés que ceux de leurs contreparties masculines.

Vous pouvez vérifier par vous-même le retour sur l’investissement d’éventuelles formations et certifications en téléchargeant le Scrum Master Trend Report 2019.

Le but de ce rapport est de fournir de l’information aux Scrum Masters qui les aidera à en apprendre davantage sur le Scrum Master et les tendances des communauté Agiles. Scrum.org s’est associé avec Age of Product dans cette initiative pour fournir à la communauté des Scrum Masters des données pour partager une compréhension qui les aidera à diriger leurs carrières et continuer de s’améliorer.”

Vidéo de 1 heure en anglais qui détaille les résultats de cette enquête.

CertYou est partenaire de DantotsuPM

apprendre les basiques du management de projet à nos chères têtes blondes, brunes ou rousses : c’est possible et pas si difficile !

Je vous propose de lire ce retour d’expérience sur comment des enfants de la côte d’azur ont pu découvrir la gestion de projet.

Vous êtes chef de projet sur la Côte d’Azur ? Expérimenté ou nouvellement nommé ? Rejoignez ce groupe pour partager de bonnes pratiques, progresser dans votre profession et gagner des PDUs pour les certifiés.

CP, CE1, CE2-CM1 : Trois classes, trois écoles, trois environnements différents et trois succès !

Bravos à tous les bénévoles du PMI France Côte d’Azur et enseignantes qui s’impliquent dans cette belle initiative imaginée et testée par nos collègues transalpins.

Animer une session de remue-méninges, construire un plan d’action, établir les responsabilités et échéances, puis suivre l’exécution d’un projet : Autant d’outils pratiques et utiles que l’on peut appréhender de façons ludiques, visuelles et interactives dès les classes primaires.

Surtout avec un kit prêt à l’emploi et un tuteur bénévole…

Compte rendu sur le site PMI France.

Les articles les plus sur DantotsuPM.com au mois d’Octobre 2017

Les « guest writers » sont à l’honneur, merci à eux !

  • 3 articles de Rose-Hélène Humeau figurent parmi les plus appréciés par les lecteurs et nous t’en remercions !
  • Olivier Raguideau qui nous intrigue avec son billet sur l’impact de la distance dans les projets.
  • Louis-Marie Resseguier et ses 5 bénéfices majeurs de Kanban nous ouvrent à de nouvelles approches.
Livre sur Amazon

les 4 accords toltèques: 4 règles de vie à appliquer dans vos projets

C’est l’histoire d’un livre devenu culte, publié en 1997 par Don Miguel Ruiz (The four agreements), qui s’est écoulé à plus de 4 millions d’exemplaires dans le monde.

identifiez les parties prenantes qui comptent dans votre projet avec le modèle Salience®

Client, Sponsor/Commanditaire, équipe… voici les parties prenantes pour lesquelles nous faisons un effort de communication et d’implication dans nos projets. Est-ce suffisant ?

PAS LE TEMPS… …VOUS ÊTES PRESSÉ ?

Il n’y a pas de temps à perdre… il faut boucler le projet, respecter les échéances, lire et répondre aux mails, finir le rapport…. Le temps file entre mes doigts et je courre après… Vous aussi ? Voici trois conseils que j’ai mis en œuvre pour reprendre le contrôle.

Quelles habitudes rendent les chefs de projets plus performants et plus efficaces

Lors de l’enquête auprès des lectrices et lecteurs du blog DantotsuPM, la capacité d’organisation personnelle des chefs de projet est remontée comme le plus fort contributeur à leur réussite. En numéro 3 : c’est plus une question d’attitude que de compétences qui est ressortie.

Méta Projets Management est partenaire de DantotsuPM
Olivier Raguideau

Quels sont les impacts de la distance sur le management de projet et les acteurs nomades ?

La mondialisation de l’économie oblige les entreprises à rechercher tous les facteurs d’efficience et obtenir un avantage concurrentiel dans un marché où la chrono compétition est de rigueur.

Connaissez-vous les 5 principaux bénéfices de la planification de projet avec l’outil Kanban ?

La méthode Kanban adaptée à la planification de projet présente en effet de réels atouts

SMPP est Partenaire de DantotsuPM – Référentiel gratuit téléchargeable !
Disponible sur Amazon en Anglais et sur PMI.ORG pour les certifiés en pdf gratuit

Pourquoi les PMPs devraient lire la 6ème édition du PMBOK Guide

Le Project Management Institute (PMI) a sorti la 6ème édition du PMBOK le 6 septembre dernier.

Certains chefs de projet certifiés peuvent être tentés d’y répondre par “eh bien, je suis heureux que l’obtention de la certification soit derrière moi.”

Cependant, je pense que les PMPs et les autres chefs de projet certifiés devraient lire cette 6ème édition. Pourquoi ?

alors que nombre d’entre nous adoptent l’agilité, n’oublions pas les bénéfices du management de projet traditionnel en cascade

Aujourd’hui, beaucoup de business optent au lieu de cela pour la gestion de projet Agile. Les personnes qui utilisent cette méthode se concentrent sur la production de petites parties du projet dans chaque cycle de livraison, plutôt que la création d’un plan pour le projet entier. Cependant, l’approche en cascade traditionnelle du management de projet a toujours plusieurs bénéfices clefs.

CertYou est partenaire de DantotsuPM

La possibilité de Peter

Le Docteur Laurence Peter a compris la promesse et le danger de la bureaucratie mieux que la plupart d’entre nous. Il y a cinquante ans, il a écrit, « les managers s’élèvent jusqu’à leur niveau d’incompétence ».

“PMI,” the PMI logo, “PMP,” “PMBOK,” “PM Network,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.

Quand utiliser kanban ou bien Scrum ?

Quelles sont les principales différences entre les méthodes ?

When to use kanban vs scrum http://www.extremeuncertainty.com/when-to-use-kanban-vs-scrum/ par leontranter

Si Scrum est la méthodologie Agile la plus largement utilisée, Kanban devrait être en seconde place. Ça existe depuis longtemps, c’est élégant, c’est efficace, c’est simple et ça marche. Beaucoup de gens utilise Kanban en conjonction avec Scrum. Ils appellent parfois cette « Scrum-ban ». Quelques personnes utilisent juste quelques idées de Kanban, certaines un mélange à 50/50 des deux et d’autres uniquement Kanban. Pas de Scrum du tout. Cet article expliquera quand utiliser Kanban ou Scrum. Cela dépend vraiment de quel type de travail vous faites.

scrumban board

Cependant, beaucoup d’équipes utilise juste deux ou trois des idées de base de Kanban, plutôt que la totalité. Kanban est bien comme ça. Vous pouvez facilement ajouter, choisir les parties que vous aimez et laisser celles qui ne vous conviennent pas. Scrum ou la Programmation Extrême ne sont pas aussi flexibles. Elles n’ont pas tendance à bien fonctionner si vous n’en prenez que deux ou trois particules aléatoires. Elles sont un système logique. Kanban n’est pas vraiment un système logique, c’est juste un jeu de principes pour visualiser et améliorer le travail. Choisissez ceux que vous aimez. Ou utilisez-les tous!

D’abord, passons les différences principales entre les méthodes.

Scrum est avant tout itérations

scrum methodologie agile
Voici le diagramme du Modèle Scrum

Le focus principal dans Scrum est sur les itérations. Une itération est une courte unité fixe de temps. Scrum appelle ces itérations « des sprints ». Un sprint dure d’habitude deux, trois ou quatre semaines. Vos sprints doivent tous être de même durée. Vous ne pouvez pas avoir un sprint légèrement plus long ici et un sprint plus court là. Ce serait tricher. Le principe est d’entrer dans un modèle prévisible de livraison de travail. L’équipe exécute une planification fréquente et des revues et rétrospectives fréquentes. Cela permet à l’équipe de prévoir et planifier le travail qui sera fait sur les deux prochains sprints.

Kanban est avant tout états de travail

Dans Kanban, il n’y a aucun sprint. Il n’y a aucune itération. Il ne s’agit pas tellement de temps et de prévisibilité, il s’agit plutôt de travail. Le focus dans Kanban est dans le découpage et la visualisation de petits articles de travail. Vous dressez alors la carte des articles de travail sur des états spécifiques du travail. Essayer de placer peu d’articles de travail dans n’importe quel état particulier et aussi peu d’articles de travail possible comme bloqués. Vous pouvez aussi imposer des “limites WIP ” (nombre d’items « work in progress » donc de travail en cours) dans chaque état. Cela signifie que vous ne pouvez pas avoir plus qu’un certain nombre d’articles dans un état particulier. L’objectif est d’avoir un flux de travail lissé à travers tous ces états.

Scrum est bon pour suivre le progrès et planifier

Scrum est une bonne structure pour le travail de développement de fonctionnalités. Pour le travail où vous avez une pile de fonctionnalités à construire et vous devez planifier grossièrement combien de temps il faudra pour les construire et quand elles pourraient être finies. On utilise des sprints de durée fixe donc vous pouvez mesurer votre progrès comme vous avancez et déterminer votre vélocité. La vitesse vous aidera à projeter combien de temps il faudra pour finir tout le travail. Souvenez-vous, la vélocité est pour qu’une équipe pour fasse son propre planning, pas pour qu’un manager mesure la productivité.

Alors, en résumé, Scrum est bien adapté pour réaliser un travail de développement parce que :

  • Le travail est composé de grosses parties vagues qui peuvent alors être décomposées en item de fonctionnalité spécifiques plus petits
  • Le travail fait généralement partie d’une série encore plus grande de buts à long terme (« des releases » ou « des horizons »)
  • Les délais fixes et limités, les timeboxes, vous laissent mesurer votre taux de progression
  • Les délais fixes et limités et un taux de progression signifient que vous pouvez planifier vers les objectifs à long terme.

Kanban est bon pour le flux et la quantité livrée

Get the book for free on line

Kanban est bien adapté à un travail où il n’y a pas de gros arriéré de fonctionnalités à développer. L’attention est plutôt sur livrer rapidement de petits items de travail comme ils arrivent. Un exemple usuel est celui d’une équipe assignée à résoudre des incidents de production. Kanban fonctionne vraiment bien ici parce que :

  • Le travail surgit devant l’équipe (c’est-à-dire poussé vers elle, basé sur la fourniture) plutôt que tiré par l’équipe (c’est-à-dire basé sur la demande)
  • Le travail est composé de petits composants distincts qui ne sont pas d’habitude connectés à d’autres composants de travail
  • Il n’y a aucun objectif à long terme ou but à atteindre
  • La planification est sans importance ou sans rapport.

Et si vous voulez utiliser les deux ?

Eh bien, bonne nouvelle, vous pouvez. En fait, la plupart des personnes le font. Les équipes de développement de logiciel les plus agiles utilisent Scrum et beaucoup d’entre elles utilisent au moins certaines (mais pas toutes) les idées de Kanban. La plus commune est celle des colonnes sur le tableau de visualisation Kanban. Elles sont si fréquemment utilisées que je les prends pour acquises et oublie souvent qu’elles ne sont mentionnés nulle part où dans Scrum ! C’est aussi une pratique commune que d’utiliser quelques autres idées des tableaux de visualisation Kanban comme des avatars et de marquer les histoires bloquées.

Alors, quand utiliser Kanban ou Scrum ?

En résumé, vous devriez :

  • Utiliser Scrum (ou quelque chose de similaire) pour le travail de développement de fonctionnalités avec des gros objectifs de livraison ou des jalons importants
  • Utiliser Kanban (ou similaire) pour les petites items de travail entrant dans l’équipe comme la réparation de bugs ou de petites demandes d’améliorations
  • Mais ne pas hésiter à les combiner, en particulier en adoptant Scrum, mais en appliquant certaines grandes idées Kanban comme les tableaux de visualisation.

J’espère que cela aide à éclaircir les choses!

CertYou est partenaire de DantotsuPM

Une petite vidéo de 6 minutes en anglais pour exposer comment appliquer certains des principes de Kanban à Scrum.

Connaissez-vous les 5 principaux bénéfices de la planification de projet avec l’outil Kanban ? par Louis Marie Resseguier

La méthode Kanban adaptée à la planification de projet présente en effet de réels atouts

Louis Marie RESSEGUIER, PMO consultant au sein du cabinet expert IQar dans l’accompagnement et le conseil de la gouvernance des portefeuilles projets, vous partage ses convictions sur un volet clé de la gestion de projets : la planification de projet !

Quand on évoque la gestion de projet et particulièrement quand on s’intéresse à la phase de planification des projets plusieurs mots clefs peuvent revenir : PERT, Gantt, Kanban…

Ces mots font référence à des méthodes de planification ou de représentation de la planification du projet. Si la démarche de planification consistant à déterminer le chemin critique en passant par la méthode PERT puis à représenter de manière visuelle la planification via l’outil diagramme de Gantt est classique, elle n’en présente pas moins une certaine forme de complexité.

Nombreux sont nos clients qui nous reçoivent avec leurs visages déformés par la douleur au moment d’aborder ce sujet et de leur niveau actuel de leur art en la matière !

Pas de panique ! Pour y remédier dans le cadre des organisations qui débutent en gestion de projet ou qui ne sont confrontées qu’à des projets peu complexes, planifier à l’aide d’une adaptation de la méthode Kanban peut apporter de nombreux avantages.

On vous donne aujourd’hui les 5 principaux !

1/ Simple : Cette méthode est compréhensible et accessible pour le plus grand nombre. Elle se résume à déplacer des post-it (virtuels) dans un tableau en phase de réalisation et à exprimer la feuille de route du projet sur des post-it (virtuels) dans un tableau en phase de planification.

Le Drag and Drop de la planification, on adore !

2/ Visuel : C’est en effet une méthode très visuelle. On repère en un seul un coup d’œil l’avancement du projet, le nombre d’actions à réaliser. En cela, le KANBAN se révèle être un formidable outil de communication complémentaire du Gantt !

Utilisez-le à volonté, ne nuit pas à la santé…de votre Projet !

3/ Universel : Cette méthode est très utilisée et connue dans de nombreux secteurs d’activité et ne demande pas, pour être mise en œuvre, une conduite du changement drastique.

Kanban, une planification à portée de mains…de clics !

4/ Agile : Cette méthode est nativement compatible avec les méthodes agiles comme « scrum » et permet de les outiller avec succès puisqu’elle permet d’illustrer à merveille la gestion d’un « sprint ». En phase de planification un « planning poker » sera facile à réaliser grâce à ce support.

Le Kanban c’est SMART non ?

5/ Compatible : Cette méthode n’empêche pas de la coupler avec le diagramme de Gantt pour l’aspect visuel des délais en planification puisqu’un outil PPM comme SuiteProG, application SaaS développée par IQar, permet déjà de passer pour le plan d’action d’un projet de la vue Kanban à la vue Gantt (en fonction des dates des actions du Kanban) automatiquement.

Agile et docile le Kanban… demandez une démonstration de SuiteProG !

Pour conclure, la mise en œuvre d’une méthode Kanban pour la planification de vos projets, peut être un véritable vecteur de simplification de cette phase incontournable de la vie du projet qu’est la Planification.

Cette méthode peut également s’avérer être un formidable levier d’aide à la conduite du changement dans certaines organisations : notamment celles désireuses de bénéficier des avantages du mode projet tout en adaptant par étapes les modes de travail de ses collaborateurs pour faciliter l’adhésion et le succès de la mise en place de la démarche.

CertYou est partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

Avez-vous entendu parler du Personal Kanban ? L’utilisez-vous déjà ?

Livre en Français sur Amazon

Bonjour, je serais intéressé de connaitre vos retours d’expériences sur cette approche de productivité personnelle.

Merci de les poster en commentaires à ce billet d’introduction sur cette approche et méthode.

Pour ceux qui ne connaitraient pas encore bien le Personal Kanban voici 2 vidéos explicatives.

La première en anglais ne dure que 6 minutes et a été réalisée par le créateur de la méthode, Jim Benson, co-auteur du livre « Personal Kanban: Mapping Work, Navigating Life. »

https://www.youtube.com/watch?v=ZYzRHH-fdf8

La seconde en Français dure une cinquantaine de minutes et est illustrée de retours d’expérience personnels de Guillaume LOURS, Coach Agile et Expert Java EE, co-fondateur du Normandy Agile User Group et l’un des organisateurs de l’AgileTour à Rouen.

N’oubliez pas de poster vos commentaires et retours d’expérience !

Microsoft est partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

Connaissez-vous le nouveau Agile Practice Guide (en anglais) ?

PMI et Agile Alliance se sont mis au travail ensemble pour produire le Agile Practice Guide dans l’intention de forger une meilleure compréhension des pratiques agiles pour les chefs de projet.

Vidéo mise en ligne par le PMI:

Voici un aperçu de ce que vous pourrez lire dans ce guide.

Qu’est-ce que l’état d’esprit Agile?

Le guide sur Amazon

Pour partir du bon pied, un rappel est fait du  Agile Manifesto, des valeurs, et des 12 principes Agile. Cette entrée en matière couvre aussi les concepts de travail à faire bien défini ou à fortes incertitudes avec les corrélations entre Lean, Kanban et Agile.

Une analyse approfondie du choix de l’approche en fonction des cycles de vie de projet

L’un des aspects les plus saillants des approches Agile pour les chefs de projet est le cycle de vie du projet et les livraisons de produits. Plusieurs cycles sont développés dans le guide avec des critères de choix, guides d’adaptation et combinaisons fréquentes des approches. L’objectif est mieux mettre en évidence ce qui est ou pas Agile et comment choisir en connaissance de causes.

CertYou est partenaire de DantotsuPM

Autres suggestions et recommandations

  • Composition des équipes et “servant leadership” détaillés
  • Organisation d’équipe pour livraison fréquente de valeur et métrique efficace.
  • Facteurs favorisant le travail en équipe Agile : organisation, culture, PMO…
  • Tableau de références croisées entre les concepts Agiles et les groupes de processus et domaines de connaissance du PMBOK® Guide, 6ème édition.

PMI and PMBOK Guide are registered mark of Project Management Institute, Inc.

Microsoft est partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer