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.
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
partagez ce billet avec vos amis, collègues et relations professionnelles
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
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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
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
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
partagez ce billet avec vos amis, collègues et relations professionnelles
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é (productbacklog) 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é.
– 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.
“Le but de ce rapport est defournir 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
partagez ce billet avec vos amis, collègues et relations professionnelles
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…
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.
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 ?
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.
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.
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
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.”
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.
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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
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 Scrumet 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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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
partagez ce billet avec vos amis, collègues et relations professionnelles
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
partagez ce billet avec vos amis, collègues et relations professionnelles
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
partagez ce billet avec vos amis, collègues et relations professionnelles
Récemment, j’ai beaucoup réfléchi à comment augmenter l’agilité personnelle. Non, je ne parle d’exécuter des sauts périlleux ou autres folles poses de yoga. Je parle de la capacité à me concentrer sur la valeur et à être adaptable dans ce que je fais chaque jour. L’agilité telle que mentionnée dans les valeurs et principes du Manifeste pour le Développement Logiciel Agile. Quand le manifeste a été répondu en 2001, il y avait des représentants de Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming et autres. Aussi, quand je dis Agile, je ne veux pas nécessairement dire Scrum.
Scrum de Un ?
Dans ce billet, je veux mettre le focus sur les personnes et pas les organisations. Étant un coach Agile et un consultant, j’ai appris beaucoup de stratégies qui m’ont aidé à manager des clients. En travaillant avec de grandes organisations complexes, j’ai vu des améliorations de productivité au niveau organisationnel en appliquant Lean et Kanban et au niveau de l’équipe avec Scrum et Kanban. Mais qu’en est-il de toutes les personnes qui travaillent pour ces organisations ou dans ces équipes Scrum ? Qu’en est-il des gens qui n’ont aucune idée de ce qu’est Scrum et ne s’en soucient pas ? Comment peuvent-ils améliorer leur productivité ?
Dans le billet Lifehack « Scrum for One« , Dustin Wax décrit combien des éléments de Scrum pourraient être adaptés à la productivité individuelle. En lisant l’article, je n’ai pas acheté l’idée. Scrum est une approche géniale pour des équipes mais c’est comme vouloir faire passer une pièce ronde dans un trou carré que de vouloir utiliser Scrum pour votre productivité quotidienne.
Dans Scrum, vous démontrez la valeur à votre client toutes les 2 à 4 semaines dans le cadre d’un sprint. Cela a-t-il du sens pour manager votre travail personnel ? Non.
Dans Scrum, vous avez les 3 rôles : ScrumMaster, Propriétaire de Produit et Équipe. À moins que vous n’ayez une double personnalité, il n’y a que vous !
La plupart des choses auxquelles je pense pour atteindre mes objectifs : l’alignement des activités sur les livrables, la décomposition du travail en morceaux exécutables, réitérer sur ce qui est créé pour pouvoir l’améliorer au fil du temps… la liste est longue.
Et ces composants ne sont pas des éléments exclusifs à Scrum. Alors, pourquoi vous limiter à Scrum ?
Manifeste d’Agilité Personnelle
Je crois que la productivité personnelle doit être repensée.
La productivité personnelle est-elle d’être tout le temps occupé ou de réaliser des choses ?
Pour être productif, cela signifie que vous devez produire. Sinon, vous êtes actifs. Il y a une différence! Pour aider à structurer mes pensées, j’ai écrit un Manifeste d’agilité personnelle.
Vous remarquerez que c’est proche du Manifeste Agile. Mais, il y a des différences clés.
D’abord, (tous) les résultats obtenus sont des mesures primaires de progrès. Ceci n’est pas du tout le cas pour le développement logiciel.
Deuxièmement, je me suis concentré sur des minutes, heures et jours pour réaliser des choses. Les équipes continueront à se concentrer sur des jours, semaines et mois pour obtenir le travail escompté et le livrer.
Je cherche à produire quelque chose que tout un chacun puisse utiliser. Quand vous entendez « Agile » c’est en réalité un groupe de niche de personnes concernées. Mais, quand vous parlez de productivité personnelle, la taille de l’audience explose. Comme avec Agile, je ne pense pas qu’il y ait une unique et meilleure voie. Alors, je regarde pour expérimenter et continue d’essayer pour améliorer.
Comme j’écris sur Personnel Kanban depuis 2010, vous pourriez penser que je devrais avoir tout compris à ce jour. Eh bien non, ce n’est pas encore le cas…
Aussi, si vous avez d’autres trucs, astuces et suggestions, j’aimerais les entendre/lire.
CertYou est partenaire de DantotsuPM
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Récemment, j’ai beaucoup réfléchi à comment augmenter l’agilité personnelle. Non, je ne parle d’exécuter des sauts périlleux ou autres folles poses de yoga. Je parle de la capacité à me concentrer sur la valeur et à être adaptable dans ce que je fais chaque jour. L’agilité telle que mentionnée dans les valeurs et principes du Manifeste pour le Développement Logiciel Agile. Quand le manifeste a été répondu en 2001, il y avait des représentants de Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming et autres. Aussi, quand je dis Agile, je ne veux pas nécessairement dire Scrum.
Scrum de Un ?
Scrum de un ?
Dans ce billet, je veux mettre le focus sur les personnes et pas les organisations. Étant un coach Agile et un consultant, j’ai appris beaucoup de stratégies qui m’ont aidé à manager des clients. En travaillant avec de grandes organisations complexes, j’ai vu des améliorations de productivité au niveau organisationnel en appliquant Lean et Kanban et au niveau de l’équipe avec Scrum et Kanban. Mais qu’en est-il de toutes les personnes qui travaillent pour ces organisations ou dans ces équipes Scrum ? Qu’en est-il des gens qui n’ont aucune idée de ce qu’est Scrum et ne s’en soucient pas ? Comment peuvent-ils améliorer leur productivité ?
Dans le billet Lifehack « Scrum for One« , Dustin Wax décrit combien des éléments de Scrum pourraient être adaptés à la productivité individuelle. En lisant l’article, je n’ai pas acheté l’idée. Scrum est une approche géniale pour des équipes mais c’est comme vouloir faire passer une pièce ronde dans un trou carré que de vouloir utiliser Scrum pour votre productivité quotidienne.
Dans Scrum, vous démontrez la valeur à votre client toutes les 2 à 4 semaines dans le cadre d’un sprint. Cela a-t-il du sens pour manager votre travail personnel ? Non.
Dans Scrum, vous avez les 3 rôles : ScrumMaster, Propriétaire de Produit et Équipe. À moins que vous n’ayez une double personnalité, il n’y a que vous !
La plupart des choses auxquelles je pense pour atteindre mes objectifs : l’alignement des activités sur les livrables, la décomposition du travail en morceaux exécutables, réitérer sur ce qui est créé pour pouvoir l’améliorer au fil du temps… la liste est longue.
Et ces composants ne sont pas des éléments exclusifs de Scrum. Alors, pourquoi vous limiter à Scrum ?
Manifeste d’Agilité Personnelle
Je crois que la productivité personnelle doit être repensée.
La productivité personnelle est-elle d’être tout le temps occupé ou de réaliser des choses ?
Pour être productif, cela signifie que vous devez produire. Sinon, vous êtes actifs. Il y a une différence! Pour aider à structurer mes pensées, j’ai écrit un Manifeste d’agilité personnelle.
Vous remarquerez que c’est proche du Manifeste Agile. Mais, il y a des différences clés.
D’abord, (tous) les résultats obtenus sont des mesures primaires de progrès. Ceci n’est pas du tout le cas pour le développement logiciel.
Deuxièmement, je me suis concentré sur des minutes, heures et jours pour réaliser des choses. Les équipes continueront à se concentrer sur des jours, semaines et mois pour obtenir le travail escompté et le livrer.
Je cherche à produire quelque chose que tout un chacun puisse utiliser. Quand vous entendez « Agile » c’est en réalité un groupe de niche de personnes concernées. Mais, quand vous parlez de productivité personnelle, la taille de l’audience explose. Comme avec Agile, je ne pense pas qu’il y ait une unique et meilleure voie. Alors, je regarde pour expérimenter et continue d’essayer pour améliorer.
Comme j’écris sur Personnel Kanban depuis 2010, vous pourriez penser que je devrais avoir tout compris à ce jour. Eh bien non, ce n’est pas encore le cas…
Aussi, si vous avez des trucs et astuces, j’aimerais les entendre.
CertYou est partenaire de DantotsuPM
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Personne n’est plus surpris que tant d’organisations explorent les méthodes Agile pour manager leur flux de travail. Kanban est l’une des méthodes Agile. Une fois comprise, adoptée et déployée avec succès, elle apporte des bénéfices très significatifs à la gestion de votre équipe et du flux de tâches à réaliser par celle-ci.
Le principe de Kanban est de manager et décroître le nombre de goulets d’étranglement qui peuvent entraver la progression de toute l’équipe. C’est un choix bénéfique pour les équipes qui délivrent souvent et pour les équipes de développement en général. C’est une méthode de management très visuelle et participative qui tourne généralement autour d’un tableau blanc, des post-it colorés et des marqueurs. Travailler ainsi permet à toute l’équipe de voir la progression de l’ensemble des tâches en cours. Les zones sujettes à futur problème deviennent visibles à l’avance.
Ce mois de novembre fut l’occasion de découvrir de nouveaux livres, MOOCs et blogs sur MS Project et Kanban, et aussi comment améliorer son management de projet et ses capacités à le vendre.
Que vous soyez déjà chef de projet ou souhaitiez le devenir, ou que vous vouliez simplement améliorer vos compétences en leadership, Agile, management, projets, soft skills, … : Voici quelques livres qui sauront vous être utiles !
PRINCE2 Agile est une solution de management de projet qui combine les qualités de gouvernance et de management de PRINCE2 avec la flexibilité des concepts Agile.
Partenaire de DantotsuPM
PRINCE2 Agile a été construit de manière collaborative avec des experts PRINCE2 et des « Agilistes ».
Partenaire de DantotsuPM
PRINCE2 Agile couvre les approches Scrum, Kanban, Lean Startup et Cynefin et utilise les principes de PRINCE2 avec 5 comportements clés:
Transparence
Collaboration
Communication
Auto Organisation
Exploration
Partenaire de DantotsuPM
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Tout a commencé il a environ 3 ans, début 2014, lorsque mon manager a voulu que je prenne en charge le pôle des Évolutions. Je vais tâcher de vous raconter les changements mis en place au sein de ce département qui ont contribué à améliorer la satisfaction clients tout en délivrant de la qualité. Ces évolutions, telles que l’implémentation d’indicateurs, d’un kanban ou encore d’un planning poker, ont clairement fait progresser la perception utilisateurs et ont su faire évoluer mon mode de fonctionnement aussi côté projets.
Au sein de l’IT dans les entreprises, il y a les projets, la maintenance et le ventre mou, les évolutions. Ces demandes utilisateurs dont on ne sait que faire, pas suffisamment importantes pour les faire passer en projet et où les budgets à allouer, sont toujours plus ou moins compliqués à mettre en place.
Ces demandes ont un coût variable entre un et quarante jours. Elles sont priorisées au sein d’un comité chez LeasePlan France qui a lieu mensuellement. Un représentant de chaque direction vote pour les demandes qu’il qualifie par ordre d’importance. Une moyenne est établie et donne un ordonnancement pour les traiter. A chaque comité sont priorisées dix demandes utilisateurs qui viennent se mettre en backlog du Kanbanavec une limite de dix dans le pipe à traiter.
une limite de dix dans le pipe à traiter (colonne la plus à gauche)
En amont de ces comités, j’allais voir chaque utilisateur qui présentait une évolution qui allait être soumise au vote, pour pouvoir y attribuer un chiffrage grossier en fonction du besoin. Ici, le « je » est important car vous allez voir par la suite comment amener l’équipe à s’engager.
Deux questions se posaient, la première, comment rendre plus Lean le process, et la deuxième, comment quantifier la valeur que chaque demande apporte, ou comment apporter de la valeur le plus rapidement possible. En effet, en premier lieu, je me suis rendu compte que passer du temps avec chaque utilisateur en amont du comité était, non une perte de temps, si ce n’est pour ma connaissance personnelle, mais non nécessaire (toutes les demandes n’étant pas priorisées dû à la limite du backlog).
Pour répondre à cette première question et ne pas avoir à chiffrer et analyser des demandes non priorisées, j’ai déporté cette phase d’échange post comité.
Simultanément, j’ai mis en place deux jours avant comité, une revue de chiffrage avec l’équipe dans laquelle toutes les demandes étaient passées en revue pour pouvoir y attribuer un chiffrage moyen établi en consensus. Le tour était joué. Le simple fait de faire participer l’équipe dans l’analyse grossière les stimulait, leur avis étant pris en considération. Qu’y a-t-il de plus essentiel pour une personne que de se sentir importante et impliquée ? Vous y gagnerez en engagement.
L’utilisation du Kanban, insufflé par mon manager et connu de tous, était simple : un backlog, analyse, développement, User Acceptance Testing (UAT) et production. La première pierre était posée.
Après huit mois d’historique, de statistiques et de dérives, deux choses ressortaient. Le chiffrage réel différait du chiffrage initial lors du traitement de la demande et le résultat attendu lors de la mise en UAT amenait souvent des questions ou retours en développement. Force était de constater, on le sait malheureusement, le besoin n’est pas toujours exprimé correctement ou avec les bons mots et même si durant les phases de design nous rencontrons les métiers, nous ne parlons pas toujours le même langage.
Comment quantifier la charge sur une évolution et être sûr de comprendre la même chose que le Métier ?
Deux notions ont été intégrées, une insufflée par mon manager,
les « Efforts » avec la suite de Fibonacci et
la phase dite de « Validation de design » que j’ai introduite.
La première consiste à mettre un effort sur une demande, de prendre une évolution compréhensible par tous et d’obtenir un consensus en équipe.
Ensuite, les autres demandes qui sont passées en revue sont notées en fonction des précédentes. La note est attribuée en fonction du niveau de complexité, de la qualité rédactionnelle et de la compréhension de chacun tout en gardant à l’esprit la charge plus ou moins importante qu’elle peut représenter. Le but de ces sessions pré comité était de voir, aussi, les grands items qui se dégageaient de chaque évolution, de la pré-découper en tâches car plus les items sont petits, plus la marge d’erreur est réduite et vous pourrez être prédictible concernant la charge réelle.
La deuxième notion consiste à sélectionner une évolution et voir avec le métier, durant la phase de design, si ce qu’il a exprimé correspond réellement à son besoin (phase d’Assistance à Maîtrise d’Ouvrage, AMOA). Cela permet de définir ou redéfinir le design et d’en faire un compte rendu effectué par l’IT, synthèse non technique qui décrit ce qui va être fait lors de la livraison en UAT.
Plusieurs objectifs :
Délimiter un périmètre qui doit respecter approximativement le besoin initial,
Déterminer ce qui ne sera pas fait de ce qui le sera,
Démarrer les développements une fois la validation de l’utilisateur reçue,
Dématérialiser la phase de design pour une question de traçabilité, de gestion et de négociation (on le sait, une fois livrée en UAT, il manque toujours le petit quelque chose auquel l’équipe projet n’avait pas pensé),
Découper en items/user stories, fonctionnelles et/ou techniques,
Chiffrer les items,
Être prédictible concernant la date de mise en UAT
Les bénéfices de cette phase ont été divers :
Faire prendre de la hauteur à certains membres de l’équipe qui ont été capables d’en tirer, profit, être totalement autonome, analyser les process métiers en omettant le technique pour trouver la meilleure solution,
Identifier ceux qu’il a fallu accompagner,
Livrer en UAT ce qui correspond à la demande utilisateur, sans surprise quelconque et de ce fait, limiter les retours en développement,
Développer une satisfaction métier accrue.
Comment déterminer le degré d’efficacité des phases de design et contrôler la qualité des livrables ?
Certes, le métier était satisfait, mais cela restait une impression, notre perception. Comment pouvait-on la mesurer ? Huit autres mois se sont écoulés et c’est à se moment là que j’ai décidé de nous mettre en risque (mesuré).
Premièrement, nous avons comptabilisé le nombre de retour d’UAT en développement en les catégorisant :
Les retours dit « anomalie » causés par l’IT liés aux développements et/ou environnements
Les retours dit « cosmétique » qui sont inférieurs à une demi-journée de développement
Les retours dit « évolution » qui sont supérieurs à une demi-journée car l’équipe projet (métier-IT) est passée au travers du sujet
Deuxièmement, nous avons comptabilisé le nombre de WFT (Write First Time, évolution livrée en UAT ne nécessitant pas de développement supplémentaire) et le nombre d’anomalies générées liées à nos mises en production.
Enfin, un questionnaire de satisfaction était envoyé à chaque évolution livrée avec une notation sur 10 au « key user » :
L’évolution livrée correspond elle à votre besoin ?
Êtes-vous satisfait de l’accompagnement en UAT ?
Des améliorations vous ont-elles été proposées durant la phase de design ? Si oui, lesquelles ?
Le fait de cadrer au mieux durant les phases de design, de faire une « démo » utilisateur à la livraison en UAT et d’accompagner le métier nous ont permis d’obtenir ces résultats sur 75 demandes :
85 % des demandes ont été comptabilisées en WFT
Plus de 90% des demandes n’ont eu aucun retour d’UAT
Moins de 3% des demandes ont générées un bug en production
Une moyenne supérieure à 9 concernant les questionnaires de satisfaction
Dans les faits, chaque responsable métier attribue à une évolution une note prise sur la suite de Fibonacci et une moyenne est effectuée. En fin de séance, l’IT donne les efforts de chaque demande et le ratio valeur/effort détermine l’ordonnancement des évolutions. Le but étant ici d’apporter la plus grande valeur, le plus tôt possible. Certes, la valeur qu’apporte la livraison d’une évolution est subjective en fonction de chacun, mais cela permet néanmoins de partager les points de vue et soulève des débats.
La vie côté projets après deux années aux Évolutions
En ce début d’année, avril pour être exact, j’ai basculé côté projets et mon manager me disait : « continue à faire ce que tu as fait et ça se fera tout seul». Cela veut dire tellement de choses à la fois lorsque j’y repense.
Un bon manager essayera de vous insuffler des idées. Toutefois, la capacité de chacun à entendre, à se remettre en question, à réfléchir par soi-même ou encore à faire évoluer sa perception des choses ne sont pas donné à tout le monde. C’est ce que vous en faites qui contribuera à votre évolution si vous en avez toutefois l’envie.
J’ai appris à manager une équipe, en tirer le meilleur avec les qualités et défauts de chacun, à obtenir une émulation que je ne soupçonnais pas ou encore à gérer des personnes avec lesquelles je ne m’entendais pas. On ne nait pas fédérateur, on le devient, c’est mon avis.
Aujourd’hui, j’ai gardé le meilleur de ces deux dernières années et en ai tiré des leçons.
Nous découpons en équipe un projet pour en obtenir des « items/users stories » les plus petits possibles, et ce, dès la phase de « define » pour engager l’équipe.
Cela permet déjà d’être plus ou moins prédictible quant aux UAT en mettant bout à bout tous les items, de voir les modules indépendants et de les livrer plus tôt, indépendamment de tout le projet.
Le but est d’obtenir des items avec un effort maximum de 5 car mes statistiques me font dire qu’en général, la charge correspond à l’effort multiplié par 1,5. Cela reste approximatif mais a fait ses preuves ces deux dernières années. Au-delà, un item avec effort 8 consommera entre 8 et 20 jours, et un item à 13 entre 20 et 40 jours. Plus l’effort est grand, plus il y a de risques, de points d’attention ou d’incompréhensions.
Chaque item fait office « d’évolution », de ce fait, il est analysé avec le métier avec une phase de validation de design, document une fois réconcilié avec les autres, qui serviront à faire un passage à la maintenance.
Ces trois dernières années m’ont permis d’appréhender des concepts de SOA, d’architecture globalisée, une gestion de fournisseurs ou encore de méthode de management. Il m’a fallu une perpétuelle remise en question et une envie démesurée pour obtenir le meilleur des gens, IT ou non d’ailleurs.
S’il fallait résumer
A few videos to get started on Agile, Scrum and Kanban
Le kanban est un outil très utile au management visuel,
Les « stand up », s’ils ne sont pas utilisés à outrance, permettent d’avoir un suivi et un partage au sein de l’équipe. Pour ma part, ils se limitent à deux par semaine, voire trois en fonction des jalons, risques et mises en production,
Les workshops avec l’équipe permettent d’obtenir un engagement des collaborateurs et une vision partagée pour en tirer la meilleure émulation possible,
Les projets doivent être découpés au niveau le plus fin, s’ils le permettent, pour une meilleure visibilité,
Le management est un concept difficile s’il est bien fait, car oui, le manager paternaliste est mort !
En espérant que cela puisse vous servir ou vous inspirer…
Gaël Gomez, Chef de projet informatique au sein de LeasePlan France
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles