Gestion de projet agile

2022-12-06

Vive les projets et l’agilité organisationnelle !

En lisant ce titre, vous vous dites « Est-on le 1er avril ? », « Encore un titre accrocheur pour démontrer son contraire » ou « Mais il est tombé sur la tête, ce Matthieu ? ».

Eh bien, non, non et non. Ce titre est le bon et je vais tenter de vous expliquer pourquoi les projets et l’agilité organisationnelle, tel le yin et le yang, sont souvent mis en opposition mais sont inséparables !

Agilité organisationnelle et projet : meilleurs ennemis ?

De nos jours, de nombreuses organisations souhaitent aller chercher les gains de l’agilité organisationnelle tout en composant avec leurs habitudes, leurs cultures, leurs croyances, le plus souvent bâties sur des modes d’organisation traditionnels faisant appel à la notion de projet. Le plus simple, me direz-vous, serait de repartir de zéro, de faire table rase des approches traditionnelles et des vieilles habitudes pour construire un tout nouveau modèle, tout beau, tout propre, tout neuf.

Oui, mais non !

Ce n’est pas si facile et en réalité, ce n’est pas si souhaitable ! Pour s’en convaincre, il faut commencer par se questionner sur la difficulté qu’ont les organisations à se transformer et, entre autres, à faire évoluer leurs pratiques de projet.

Lire la suite
2017-08-29

Prioriser par coût du retard (cost of delay)

Le coût du retard est un concept très puissant afin d’aider à la priorisation d’un élément de travail en Kanban.  Cet outil ne remplace pas les techniques de coût d’opportunités utilisées en finance, mais peut servir de guide dans la prestation de travail de notre équipe/service.

4 cas de figures

(Extrait du Essential Kanban Condensed)

archetype

Ces courbes sont des archétypes généraux souvent rencontrés en entreprise.  Même utilisées de manière simplement qualitative (uniquement en ordre de grandeur), nous pouvons rapidement discriminer les grandes familles de priorisations.

Lire la suite

2017-08-15

Ordonnancement d’un portefeuille ou d’un programme, façon SAFe – 1ère partie

L’ordonnancement d’un portefeuille ou d’un programme doit faire l’objet d’un travail d’équipe rigoureux qui visera la maximisation du bénéfice économique. Prendre une décision basée sur la valeur et l’urgence est, bien sûr, plus souhaitable que les décisions arbitraires basées sur les préférences de tous et chacun [4].

Pour mon premier article sur Excellence Agile, j’ai décidé de vous parler de l’utilisation du WSJF (Weighted Shortest Job First) tel qu’adapté par SAFe pour ordonnancer les éléments composant le carnet d’un portefeuille ou d’un programme. Je vous parlerai de mes expériences et des points à surveiller lors de de cette formule d’ordonnancement.

Pour commencer, si vous n’êtes pas familiers avec le WSJF de SAFe, je vous encourage à lire d’abord l’article de mon collègue Patrick Bocquet [1] sur ExcellenceAgile.com. Pour cette série d’articles, j’utiliserai sa traduction, soit le sigle PCTPP (Plus Court Travail Pondéré en Premier). Je tenterai de compléter cet article en donnant mon point de vue sur le sujet et en partageant mes quelques expériences avec cette méthode. Vous pouvez aussi vous référer au site de SAFe, bien sûr [2].

La formule du PCTPP, version SAFe, permet l’ordonnancement d’un portefeuille ou d’un programme en tenant compte de la valeur et de l’urgence. Le numérateur représente les éléments du coût de retard (Cost of delay) et le dénominateur utilisera la taille du travail au lieu de la durée [2][5].

Ne foncez pas tête baissée! À vous de juger si l’équipe a le niveau de préparation et de maturité nécessaire pour commencer à utiliser une telle formule. Certaines personnes ne se sentiront pas à l’aise de donner un chiffre ou un estimé en points ou autres unités qui représenterait plus une envergure qu’un engagement précis. Une simulation serait une bonne façon de familiariser l’équipe tout brisant les idées préconçues liées à leur contexte particulier.

 

À titre de rappel, voici la formule du PCTPP de SAFe [1] [2] :

PCTPP = Coût de retard / TT

ou

PCTPP = (VAU + CE + (RR ou PCOA) ) / TT

VAU   = Valeur d’affaire pour l’utilisateur
CE      = Criticité de l’échéance
RR      = Réduction de risque
PCOA = Potentiel de création d’occasion d’affaire
TT       = Taille du travail

 

ou la version du site de SAFe :   WSJF = (U-Bv + Tc + RR-Oe Value) / Job Size

U-Bv   = User-Business Value
Tc      = Time Criticality
RR      = Risk Reduction
Oe Value  = Opportunity Enablement Value

 

Support à la discussion
Une fois la liste ordonnancée obtenue, vous pourrez commencer la discussion sur le résultat. Est-il différent de celui auquel nous nous attendions? L’ordre des priorités est-il aligné sur la stratégie corporative et les objectifs de votre groupe? Devrait-on corriger une valeur de la formule? La formule nous permettra d’amorcer une discussion sur la valeur ajoutée et l’urgence réelle de travailler sur quelque chose. Tout n’est pas prioritaire et d’égale valeur!

Nous ne sommes pas les esclaves de la formule! Si, par exemple, à cause d’une question de disponibilités de ressources, nous devons commencer à travailler sur le 4e élément avant le 3e, nous pourrons bien entendu prendre la décision qui s’impose. Le but recherché est, comme mentionné précédemment, de maximiser la valeur économique de notre portefeuille ou de notre programme.

Maintenant, décortiquons la formule un peu plus en détail en commençant par la valeur d’affaires pour l’utilisateur.

 

Valeur d’affaires pour l’utilisateur (VAU)

Nous utiliserons le PCTPP pour ordonnancer le travail à faire afin de maximiser les bénéfices économiques pour l’entreprise [2]. Le concept de valeur pouvant être élastique, il faut le définir pour établir une référence commune. Nous pouvons maximiser la valeur selon les axes suivants [2][3] :

  • Augmenter les revenus ou les parts de marché ;
  • Protéger les revenus actuels ou les parts de marché ;
  • Réduire les coûts ;
  • Éviter des coûts futurs (Amendes, coût de retard, prévention des pannes, etc.) ;
  • Préférences et besoins des usagers.

L’article du site de SAFe [2] survole la question de la valeur d’affaires pour l’utilisateur de façon de façon très rapide. J’ai combiné l’approche de Black Swan Farming [3] (quatre premiers points) avec celle de SAFe (points 1, 4 et 5) afin de tenir en compte les différentes formes de valeur ajoutée pour l’organisation. Il serait bon de rappeler et d’expliquer ces points avant de lancer votre équipe dans l’évaluation de la valeur relative de chaque élément de votre liste.

Nous parlerons des autres parties de la formule dans les prochains articles de cette série. À la prochaine!

Sources :
[1] https://excellenceagile.com/2015/09/08/safebacklog/
[2] http://www.scaledagileframework.com/wsjf/
[3] http://blackswanfarming.com/understanding-value/
[4] http://blackswanfarming.com/moneydev-quantifying-value-vs-gut-feel/
[5] http://xprocess.blogspot.ca/2016/04/wsjf-should-you-divide-by-lead-time-or.html

 

2017-04-11

Attention au glissement du risque

(english follows)

En gestion de projet, atteindre la prédictibilité est un élément clé du succès et son bloquant majeur est le risque. Pour contenir ce dernier lors de la préparation d’un projet, nous prenons grand soin de gérer la quantité de risque inclue dans la portée. En ne voulant rien laisser au hasard, nous augmentons ainsi nos chances de succès en travaillant sur ce risque en début de projet. Lorsque que le risque est résolu ou sous contrôle, nous pouvons enfin tourner notre attention vers la prédictibilité.

N’est-ce pas bizarre alors de voir des ajouts volontaires de risques supplémentaires pendant le projet?

Ceci peut s’expliquer via un comportement de compensation du risque poussant les gens à faire moins attention lorsqu’ils se sentent en sécurité. Cet effet, combiné avec la pression de livrer un maximum de fonctionnalités de qualités, peut nous pousser à prendre des risques supplémentaires en remplacement de ceux qui sont résolus. J’appelle ceci “remplir sa dette de risque”, étant donné que les membres de l’équipe agissant de cette façon sont similaires aux gens qui utilisent leur crédit de façon impulsive. Au même moment, pour certains membres du projet, une baisse de pression sur le risque peut être interprétée comme un signe de perte d’opportunité. Pour résoudre ceci, on doit se concentrer à maintenir un effort constant et soutenable, alors qu’au même moment, on doit accepter une oscillation dans le niveau de risque alors que le focus fait des allers-retours entre le développement et le déploiement.

Le risque est sournois, car il fait toujours partie du développement logiciel, nous désensibilisant ainsi de sa présence et de son importance et aussi parce qu’il prend deux formes : le risque connu, qui peut faire partie de la planification, et les risques inconnus, qui nous surprendront sur le chemin. Plusieurs de ces risques inconnus seront bloquants, nous forçant ainsi à investir un temps précieux pour les résoudre alors que, et nous devrions prendre avantage de ce fait, nous avons le choix d’accepter, gérer ou, plus particulièrement, rejeter les risques connus.

Livrer la vision en résolvant les risques engagés devrait donc toujours surpasser l’ajout de risque additionnel.

Phillipe Cantin

—

Beware of Risk Creep

When managing a project, achieving predictability is a key element of success and one of its major impediments is risk. To curb this problem while preparing for a project, we take great care, managing the amount of risk accepted in the scope. Not willing to leave anything to chance, we further improve our odds by tackling this risk early in the project which, once removed or under control, clears the way for predictability.

How funny then, to see new risks being purposefully added during a project production.

One reason explaining this is the Risk Compensation behavior, when people tend to be “less careful if they feel more protected”. This effect, combined with the pressure to deliver a maximum of quality features, can drive us to take on new risks as the existing risk is removed. I call this “Maxing out the risk” since team members acting this way are similar to people feeling compelled to max out their credit. At the same moment, for some people, a drop of pressure on risk can be interpreted as a sign of lost opportunity. To resolve all this, we must concentrate on maintaining a constant and sustainable effort level while, at the same time, accepting an oscillation in the risk level as the focus goes back and forth between development and release.

Risk is a sneaky thing as it is always a part of software development, desensitising us to its presence and importance. It is also sneaky as it comes in two shapes: the known risks, which can be part of the planning, and the unknown risks, which will surprise us along the way. We don’t have a choice but to deal with the unknowns [risks] as they pop up here and there during the project, and we should take advantage of this fact. We have a choice to either accept, manage or, especially, reject known risks.

Shipping the vision while resolving the engaged risks should always trump the addition of new risk.

Phillipe Cantin

2017-03-30

Qu’est-ce que ça fait un gestionnaire de projet dans une approche Agile ?

Tout le monde le sait, le gain en popularité des approches agiles a bouleversé le rôle traditionnel du gestionnaire de projet. Ce dernier, sur qui l’imputabilité du projet reposait dans son entièreté, se retrouve maintenant dans une zone floue, où soudainement, l’agilité lui allège le fardeau de cette imputabilité du projet. Dans le cadre de mes accompagnements, comme formateur, coach agile ou gestionnaire de projet, j’entends beaucoup de questionnements sur le rôle que doit jouer le gestionnaire de projet dans un projet réalisé avec une approche agile. Les attentes envers un gestionnaire de projet sont très différentes d’une organisation à l’autre, et ce, juxtaposé au cadre méthodologique qui se développe de manière personnalisée dans chaque organisation, ajoutent du brouillard à la vision que les gens ont d’un gestionnaire de projet. Bref, depuis les deux dernières années, je me suis fait poser la question par plusieurs personnes, d’organisations différentes, qui me demandent; Martin, qu’est-ce que ça fait un gestionnaire de projet dans une approche agile ? Martin, est-ce qu’on a toujours besoin d’un gestionnaire de projet quand on réalise avec une approche agile ? Comme bien d’autres choses, je suis porté à répondre : Ça dépend !

Alors avant d’aller plus loin, et comme je ne sens pas qu’il y a une vérité à la question, j’ai plutôt le goût d’échanger sur le sujet avec vous. Selon vous, est-ce que vous avez toujours besoin d’un gestionnaire de projet lors de la réalisation de vos projets avec une approche agile ? Et pourquoi ? Utilisez la zone « commentaires » au bas de cet article pour partager vos réflexions!

2016-01-05

Planifier et suivre adéquatement un projet Agile font partie de vos objectifs en 2016?

Étant bien au fait des contraintes que vivent les grandes organisations en matière de planification et de reddition de compte, nous vous offrons cette formation pour vous aider à concilier Agilité et gestion de projet. Cette formation va au-delà des pratiques de base de planification et de suivi d’itération.  Elle analyse en profondeur la notion de planification de livraison et de projet et s’assure de faire le pont avec des pratiques et outils traditionnels, tels la structure de découpage (WBS) et le plan maître de type Gantt.

Notre formateur, certifié à la fois par la Scrum.org et par le PMI, apportera un éclairage sur des questions telles : Que faire avec les contributions externes? Et si ce n’est pas toutes mes équipes qui réalisent en mode Agile? Quelle est la place des points dans ma reddition en JP/$ ?  Quel niveau de granularité dois-je inscrire dans notre outil de feuille de temps?  Et bien d’autres.

En plus des techniques et pratiques spécifiques à la gestion de projet Agile, le cours vous permettra aussi de bien saisir la posture attendue d’un gestionnaire de projet Agile vous permettant ainsi de jouer efficacement votre rôle dans votre organisation.

En ce début d’année, offrez-vous ce cadeau et joignez-vous aux experts en gestion de projet Agile du Centre d’Excellence Agile les 12 et 13 janvier prochains pour deux jours de formation intense sur un sujet passionnant soit la gestion de projet Agile.

Pour vous inscrire et plus de détails sur le contenu  :  cliquez ici !