MVP (Produit Minimum Viable), si simple et si confus à la fois !

En équipe, vous êtes en train de faire votre plan de livraison durant la phase de préparation d’un projet X. Celui-ci est basé sur vos cas d’utilisation ou encore de vos histoires, et lorsqu’est venu le temps de déterminer votre MVP, votre PO vous indique que son produit minimum viable (MVP) constitue la livraison de l’ensemble des fonctionnalités.

Vous lui faites alors remarquer que l’essence même de l’Agilité est de piloter par la valeur, et non par le plan. Ceci implique de rendre l’investissement et le temps de développement fixe, tout en laissant la latitude d’estimer la portée qui nous permettra possiblement de faire émerger le produit minimum viable.

Votre PO vous mentionne alors que le demandeur a émis des objectifs (sur lesquels la portée a été basée) et que, pour être viable, il doit tous les rencontrer, donc il doit tout livrer!

Lire la suite

Ordonnancement d’un portefeuille ou d’un programme, façon SAFe – 3ème (et dernière) partie

Lectures préalables:

Prioriser son carnet de produit de façon sécuritaire!
Ordonnancement d’un portefeuille ou d’un programme, façon SAFe – 1ère partie
Ordonnancement d’un portefeuille ou d’un programme, façon SAFe – 2ème partie

C’est bientôt la fin! Concluons cette série d’articles sur l’ordonnancement d’un portefeuille ou d’un programme par des explications sur la taille du travail, les rôles et, pour terminer, deux exemples pour nous aider à digérer tout cela.

Taille du travail (TT)

Dans certains contextes, le manque de données et l’incertitude quant au travail à accomplir rend les équipes peu enclines à estimer la taille du travail en point relatif. C’est comme si les membres de l’équipe avaient à signer avec leur sang! Pour remédier à cela, vous pouvez ordonnancer vos portefeuilles et programmes sans la taille du travail, soit à l’aide du seul coût de retard (cost of delay)  [1][2]. Pour cela, vous n’avez qu’à mettre « 1 » partout dans cette colonne. Pour en savoir plus sur le sujet, lisez l’article de mon collègue Éric Lessard sur la priorisation par coût de retard.

Je vous conseille de ne faire cela qu’en dernier recours. La taille du travail est importante pour permettre de prioriser des petites demandes, même avec un degré d’urgence moindre ou un coût de retard faible. Les petites demandes permettant un gain rapide sont très intéressantes pour l’organisation !

Lire la suite

Les 7 flexibilités du backlog Agile

(English follows)

Comment un backlog Agile peut-il survivre à la tempête d’un projet tout en livrant une solution cohésive? En grande partie, ceci vient de ses multiples niveaux de flexibilité. La vision d’un projet, décrite dans un tel backlog, devient adaptable à plusieurs, ou même à la majeure partie, des changements auxquels un projet fait face. Regardons ces options de flexibilité par ordre d’impact croissant sur la portée et la qualité.

Lire la suite

Ordonnancement d’un portefeuille ou d’un programme, façon SAFe – 2ème partie

Lectures préalables :
Prioriser son carnet de produit de façon sécuritaire!
Ordonnancement d’un portefeuille ou d’un programme, façon SAFe – 1ère partie

Dans l’article précédent [6], nous avons exposé brièvement certains principes sous-jacents à l’ordonnancement d’un portefeuille ou d’un programme comme suggéré par SAFe [1]. Continuons à décortiquer la formule, mais tout d’abord, penchons-nous sur la relation entre la valeur et le temps.

Lire la suite

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

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

 

Tout est un livrable

(English follows)

En 2009, je lisais l’excellent billet “The Duct Tape Programmer” par Joel Spolsky qui souligne l’importance de livrer plutôt que d’atteindre la perfection. Il résume bien sa pensée en disant “Livrer est une fonctionnalité” (Shipping is a feature). Ceci a eu un impact sur moi, car j’applique depuis cette philosophie sur plusieurs choses, poussant à maximiser la qualité tout en assurant systématiquement la livraison.  Je crois aussi qu’à l’intérieur de chaque équipe livrant du logiciel fonctionnel, il y a une personne qui se bat pour la livraison. Autrement, l’équipe resterait piégée infiniment dans un état à 90% complété.

Lorsque que j’approche chaque événement Scrum, chaque sprint, chaque période d’un projet et chaque réunion, je divise les buts en 2 groupes;  le Vital (Must) qui ne peut être atteint que par l’effort collaboratif du groupe et l’Essentiel (Should) qui gagnerait en efficience si il était complété par le groupe.  Par la suite, je recentre les efforts et surveille le temps pour assurer minimalement la livraison du Vital. L’objectif est d’éviter de pousser vers l’avant des tâches non-terminées qui, inévitablement, créeront un effet de cascade dans le flux de travail.

Voici une autre façon de voir la situation. Alors qu’un projet avance, nous créons des moments où nous réservons la capacité d’un groupe de personnes ayant la bonne combinaison de talent pour exécuter un travail précis.  Ce groupe fournit la connaissance et le pouvoir décisionnel unique pour faire avancer un gros bloc de travail. Les membres de l’équipe étant tous réunis, la boucle de communication est alors très efficiente.  Une fois que ce moment est passé, cette boucle de collaboration sera dramatiquement ralentie alors que le focus et la capacité des gens seront submergés par d’autres tâches.  Au début de chacun de ces ‘moments en groupe’, il est donc impératif d’identifier le travail Vital.

Livrer quelque chose, peu importe ce que c’est, est toujours une petite victoire qui vient donner de l’énergie aux membres de l’équipe. Nous voulons donc toutes les victoires possibles afin de garder le moral lorsqu’on traverse les haut et les bas du développement logiciel.  Livrer tout, à tous les moments, m’aide à guider mes équipes dans les périodes difficiles. Ceci me permet de célébrer le fait que nous avons eu une bonne planification de sprint, et que nous pourrons compter sur celle-ci jusqu’à la fin du sprint sans avoir d’autre réunion de clarification.  Livrer tout, c’est savoir que chaque histoire terminée est un avancement concret qui, malgré les embûches, à pu être réalisé à l’intérieur du sprint. Ceci aide à se sentir comme un héros à la fin d’un sprint dans lequel on a livré notre engagement et entrer dans le sprint suivant avec un sentiment de nouveau départ qui n’est pas entaché.

Livrer tout permet de parsemer notre travail de petites victoires.

Phillipe Cantin

Ship Everything

Back in 2009, I was reading a great blog post by Joel Spolsky called “The Duct Tape Programmer” in which he underlined the importance of delivery over perfection. Summing it up in this great motto: “Shipping is a feature”.  This must have had some impact on me since I now apply this philosophy to so many things, pushing to maximize quality while always ensuring delivery.  I also believe that every team delivering working software has at least one person who fights for shipping or they would endlessly remain caught in the “90% done” purgatory.

When approaching every Scrum event, every sprint, every project period and every meeting, I divide the goals in two groups;  the Must which can only be done by the collaborative effort of the group and the Should which would be more effective if done by this group.  I then focus the efforts and monitor the time to, minimally, ensure the resolution of the Must.  The objective is to avoid pushing unfinished work forward which will inevitably create a cascading effect down the workflow.

Look at it this way: as a project moves forward, we create moments where we secure the capacity of the right mix of people to execute a specific task.  This group provides the unique knowledge and the decision power necessary to move forward a large block for work and, by all being present, the collaboration loop is very efficient.  Once this moment is passed, this collaboration loop will slow down dramatically as people`s focus and capacity are swept up by other tasks.  At the beginning of each ‘group moment’, it is then imperative to identify the Must work.

Shipping something, anything, is also a small win adding fuel to the tank of the team members.  We want all the wins we can get to protect the morale through the ups and downs of software development.  Shipping everything, every moment, is how I get my teams through thick and thin.  Celebrating the fact that we had an awesome sprint planning on which we can count to get us to the end of the sprint without a string of meetings.  Knowing that every story done is a concrete step forward which, even with the unexpected,  was able to fit within the sprint.  Feeling like heroes at the end of a sprint where we shipped all the committed work while entering the next sprint with an untainted feeling of a fresh start.

Shipping everything is a way to punctuate our work with small wins.

Phillipe Cantin