Le paradoxe de l’efficacité

Dans la vie, quand on travaille dur, on atteint ses objectifs.

Je suis certain que plusieurs ont entendu cette phrase à maintes reprises. C’est pourquoi il est de bonne pratique de s’assurer dans notre entreprise que tous les employés travaillent dur. Après tout, ils ne sont pas payés pour ne rien faire, n’est-ce pas?

Vous devriez donc vous assurer de maximiser leur occupation. Un employé qui est disponible est un employé qui ne travaille pas.

Chaque employé devrait travailler sur plusieurs choses à la fois. Comme ça, quand un item bloque, il peut faire autre chose sans attendre.

On devrait utiliser seulement des spécialistes compétents pour accomplir les tâches afin de réduire les coûts.

Il devrait y avoir une pile de travail à faire sur chaque bureau afin que personne ne soit en attente de travail.

Les objectifs individuels devraient être liés au fait d’être constamment en train de travailler. Le salaire et les bonus devraient être proportionnels à la quantité de travail accompli.

Est-ce que tout cela fait du sens pour vous?

Si vous n’avez pas de clients, c’est probablement la bonne approche.

WAIT-WHAT-meme-289

Ici réside le paradoxe de l’efficacité. Malheureusement, à favoriser l’efficacité de l’utilisation de vos individus, vous heurtez de façon considérable votre prestation de service et par la même occasion, la satisfaction de vos clients.

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

 

State of Agile 2016

Depuis maintenant 10 ans, la compagnie américaine VersionOne publie son sondage State of Agile.

Voici quelques points que nous avons retenus de la version 2016.

Adoption dans les grandes organisations

Le sondage montre bien la progression des approches Agiles dans les grandes organisations.

In 2006, nearly two-thirds of the survey respondents said they worked in software organizations with fewer than 100 people. By 2015, nearly two-thirds of the respondents said they worked for software organizations with more than 100 people, and 31% said they worked for software organizations with more than 1,000 people. The number of large enterprises that are embracing agile continues to increase each year. More than 24% of the respondents worked for organizations with over 20,000 employees, compared to 21% last year

Freins à l’Agilité

La culture semble encore être le frein à l’Agilité dans les organisations :

The key barriers to further adoption usually hinge around culture, including the ability to change, general resistance to change, and management support. Interestingly, the majority of respondents pointed toward company culture as the reason for failed agile projects as well. Once these barriers are overcome, the limiting factor most often cited has been availability of personnel with the necessary agile experience.

Raisons d’adopter l’Agilité

Accélérer la livraison, réagir aux priorités et améliorer la qualité restent les raisons d’adopter l’Agilité:

RaisonDeFaireAgile.PNG

Quelles méthodes Agiles sont les plus populaires?

Scrum et XP figurent (encore) en tête de peloton. Scrumban et Kanban sont au même pourcentage que l’année passée.

ApprochesAgileEmployees.PNG

Scaling Agile

On voit qu’en deuxième position, SAFe se positionne bien comparativement aux autres frameworks sur le marché (LeSS et DAD). Nexus de Scrum.org, est inexistant ici.

ScalingAgile 2015.PNG

Source: VersionOne.com

Auteurs:

On le livre quand en Kanban?

Avec la publication du guide Kanban condensé à la fin 2015, cela a permis de comparer cette méthode émergente face à Scrum, l’approche largement employée dans l’industrie des TI. Bien que Scrum soit très présent comme façon de mettre en place l’Agilité dans les équipes TI, elle rencontre tout de même ses limites, surtout dans des équipes où le changement doit se faire de façon incrémentale et évolutive. Cela me laisse croire que la méthode Kanban a un potentiel d’aider des équipes TI.  Dans cet article, je compare la façon dont on prévoit la date de livraison ainsi que les métriques utilisés entre Scrum et Kanban pour arriver à cette fin. Grâce à l’apparition du guide Kanban condensé, il est intéressant de comparer ces deux points plus concrètement. Plus particulièrement, on présentera les outils Scrum basés sur l’estimation tandis que la méthode Kanban apporte le concept de prévision probabilistique pour prévoir la date de livraison.

À la page 14 du guide Kanban condensé, les auteurs mentionnent qu’il existe deux façons de prévoir la date de livraison : l’estimation ou la prévision probabilistique. Selon mon expérience, l’estimation, par la technique du poker planning, est fortement employée dans des projets Scrum. Il existe même la pratique de la session murale pour estimer rapidement et au complet un carnet de produit dès le départ. Grâce à ces outils, il est possible de donner des dates de livraison, dates qui étaient constamment révisées après chaque itération. Sur l’image suivante, on peut voir le résultat d’un tel exercice.

photo1

Cependant, on a pu voir dans les dernières années un certain rejet de cette estimation avec le mouvement #noestimates. Je ne sais pas si cela est relié, mais les experts Kanban semblent aller dans cette direction. Par contre, ils offrent une alternative pour prédire la date de livraison d’un projet au lieu de ne fournir aucun estimé. Leur façon de faire se nomme la prévision probabilistique. En gros, elle est constituée de deux éléments : une date et un taux de confiance (ou probabilité de succès). À l’aide de la méthode de Monte Carlo, on génère des probabilités de livraison en fonction des données historiques du projet. Cette façon permet donc de générer des probabilités du futur en se servant du passé. Par exemple, les simulations de Monte Carlo suivantes ont été générées à l’aide de la version démo de l’outil Actionable Agile de Daniel Vacanti.

photo2

On peut y lire sur l’axe des X les différentes dates de livraison possibles pour les 100 prochains items. Chaque barre représente une probabilité de livraison. Sur l’image, la barre sélectionnée montre qu’il y a 49,7% de chance (ou confiance) que les 100 prochains items seront complétés pour le 2 mai 2016. Plus on se déplace vers la droite sur ce graphique, plus le taux de confiance (ou probabilité) augmente. Pour les partisans Excel, les outils de Troy Magennis sur Github offrent aussi la possibilité de faire des prévisions probabilistiques.

Il est vrai que Scrum se base sur l’empirisme pour produire des dates de livraison. On utilise les vélocités antérieures comme façon de prédire les dates de livraison. Dans mes expériences Scrum, j’ai souvent identifié trois droites pour outiller les équipes à prédire une date de livraison. Ces droites représentaient le pire, bon et meilleur scénario pour produire une date de livraison. On les collait à un graphique Sunset pour rassurer la gestion sur les possibles dates de livraison.

photo 3

Il est intéressant de voir comment les experts Kanban apportent une façon différente de prévoir la date de livraison d’un projet. Elle est beaucoup plus assise sur de la donnée historique contrairement à l’approche Scrum qui continue à utiliser l’estimation comme façon de prévoir une date de livraison. Au fil des prochaines années, il sera intéressant d’observer l’adoption de cette approche probabilistique dans l’industrie. Les outils Kanban ne sont pas encore matures et pourtant, on peut déjà voir le potentiel d’une telle approche dans de futurs projets.

Dans le cadre de sa série de formations Signature, Facilité Informatique est fier d’organiser la première formation sur la méthode Kanban à Québec. Les 5 et 6 mai prochains à Québec, Daniel Vacanti, pionnier de la méthode, sera à Québec pour expliquer comment mettre en application celle-ci. Profitez de cette occasion exceptionnelle pour apprendre des meilleurs et ainsi être meilleur à satisfaire votre clientèle!

Ma revue du livre Actionable Agile

J’ai eu l’occasion cet hiver de lire le livre de Daniel Vacanti, Actionable Agile – Metrics for Predictability. Je cherchais à pousser ma compréhension de la méthode Kanban tout en ayant des outils pour la mettre en application. Un contact dans mon réseau LinkedIn (merci Andrea Ross) m’avait recommandé l’auteur.

LivreActionableAgile

Quelle excellente recommandation! J’ai tout simplement adoré le livre de Daniel Vacanti. L’auteur reste juste assez théorique pour ne pas ennuyer le lecteur où il parsème ses textes d’analogie pour comprendre facilement la théorie supportant la méthode Kanban. Le style d’écriture de Vacanti permet aussi une lecture simple avec des mots faciles à comprendre. Cela peut sembler stupide comme énoncé mais il ne nous perd pas dans ses explications. Au contraire, il nous amène à vouloir aller de l’avant avec notre mise en place de la méthode Kanban.

Ce livre est pour vous si vous avez un tableau avec des cartes, des icônes, quelques données mais vous ne savez plus trop quoi faire pour améliorer votre organisation du travail. Ce livre est pour vous si vous essayez d’employer vos techniques Agiles traditionnelles telles que les points d’efforts, le découpage en tâches et que vous avez ce drôle de sentiment que ça ne fonctionne plus vraiment dans la méthode Kanban. Ce livre est moins pour vous si vous cherchez une explication de la théorie des contraintes ou la Loi de Little. Comme le dit le titre du livre, on parle d’Agilité actionnable. Vous avez donc ici un livre pragmatique où l’auteur vous offre plusieurs outils pour bonifier votre mise en place de la méthode Kanban.

Si ce billet vous a donné le goût de lire son livre, je vous invite à l’acheter depuis la plate-forme Leanpub.com si vous en voulez une version électronique. Sur ce site, vous aurez l’occasion de donner le montant que vous voulez à Vacanti. Au lieu de passer par une plate-forme intermédiaire comme Amazon.com où cette dernière y conserve un bon montant, Leanpub retourne énormément d’argent à l’auteur.

Après avoir regardé quelques vidéos YouTube de Vacanti, je l’ai invité à Québec dans le cadre de nos formations Signature. En effet, Facilité Informatique est fier d’organiser la première formation sur la méthode Kanban à Québec. Les 5 et 6 mai prochains à Québec, Daniel Vacanti sera à Québec pour expliquer comment mettre en application cette méthode. Je vous invite chaleureusement à profiter de cette occasion exceptionnelle pour apprendre des meilleurs et ainsi être meilleur à satisfaire votre clientèle!

Biographie de Daniel Vacanti

Vétéran de l’industrie du logiciel, Daniel Vacanti cumule plus de 20 ans d’expérience. Depuis ses débuts comme développeur/architecte Java, il a investi les 20 dernières années dans l’approfondissement des pratiques Agiles et Lean.  En 2007, il a contribué à la conception d’une mouture Kanban destinée aux travailleurs du savoir.  La même année, comme gestionnaire, il chapeaute la première initiative Kanban dans le domaine du logiciel.  Depuis, il œuvre comme consultant, coach et formateur dans le domaine.  En 2011, il fonde ActionableAgile TM, fournisseur d’outils et services aux entreprises utilisant les méthodes Lean-Agile.  En 2015, il publie « Actionable Agile Metrics for Predictability », une référence pour la reddition de compte des travaux réalisés en flux-continu (flow-based processes).  Daniel détient une Maîtrise en administration des affaires et donne des cours sur la gestion Lean à l’University of California, Berkley.

L’Agilité sans tout casser

La transition vers l’Agilité est souvent perçue comme l’annonce d’une grande vague de changement.  Ça peut être le cas, mais ce n’est pas la seule option.  Même si les Scrum Masters sont souvent vus comme les porte-étendards des valeurs Agiles, ils ne sont pas nécessairement les seuls à pouvoir amener l’organisation à un autre niveau.  Si Scrum s’est présenté comme une révolution dans le monde des TI, Kanban se présente comme l’évolution.

Évolution vs dérangement

Ceux qui ont déjà entrepris une transformation Agile basée sur Scrum se rappelleront sûrement à quel point la structure initiale de l’organisation peut-être distante des ingrédients essentiels de la méthode.  Des termes comme Sprint, Carnet (Backlog), Scrum Master, Responsable de produit (Product Owner) se sont ajoutés au vocabulaire.  Le contrat implicite de protection de l’itération, la notion d’incrément livrable, récit utilisateur etc… Passer à Scrum résulte très souvent en un grand dérangement dont l’objectif est de dynamiser l’organisation vers une philosophie orientée sur la version de produit fini.

Dans un autre ordre d’idée, Kanban quant à lui nous invite à un démarrage plus progressif. La maxime « Start with what you do now » (Commencez avec ce que vous faites aujourd’hui) donne le ton.  La mise en place Kanban débute par l’identification de différents aspects de la situation actuelle, se doter d’un outil de suivi et d’une démarche d’amélioration.  Les équipes peuvent assimiler les changements initiaux et le reste de la transformation n’est qu’évolution.

Partenaires non-Agiles dans l’organisation ou hors organisation

Un autre défi, lors de transitions Agiles, réside dans le fait qu’une organisation ne peut changer en totalité en un instant.  Le changement se fait de façon progressive.  De nombreux départements non-Agiles, des clients ou des fournisseurs continuent d’alimenter les équipes et consommer leurs livrables.

Les notions d’itérations protégées créent de l’irritation à certains des contributeurs, donneurs d’ouvrages ou collaborateurs.  Il en va de même pour l’engagement.  Les calendriers de ces groupes ne sont pas nécessairement calqués sur les dates de début/fin de sprints.  Les contributions externes peuvent parfois faire la différence entre le succès ou l’échec d’un objectif de sprint.  Un glissement de quelques jours peut suffire à faire échouer ladite itération…

Dépendances non-cadencées

Au delà de la méthode de travail des partenaires, certaines contributions ne peuvent pas toutes être cadencées.  Si l’équipe dépend d’une pièce de matériel développée par une organisation ou même dans un autre pays.  Si un expert est difficilement disponible et que nous devions réagir dès qu’il a du temps pour soutenir l’équipe… Toutes ces réalités emprisonnent les équipes Scrum entre l’arbre et l’écorce.

Kanban offre une flexibilité qu’on ne retrouve pas dans les itérations de Scrum.  Le travail en flux continu devient très avantageux si des changements de priorités peuvent survenir dans la réalité quotidienne des équipes.  Si une tâche est bloquée par un expert ou un fournisseur qui a pris du retard de son côté, le reste du travail continue à couler de façon fluide dans le système et l’équipe continue de livrer.

Et la suite?

Kanban ou Scrum.  2 excellents outils.  Comme un marteau ou un tournevis.  Dans le bon contexte et avec la bonne connaissance de ce qu’ils peuvent offrir, une organisation peut à la fois avoir des équipes Scrum et Kanban sous le même toit, dans le même écosystème Agile.

Une belle façon d’élargir vos horizons serait de vous procurer les incontournables suivants:

guide-cover-sm

Titre: Essential Kanban – The Condensed Guide

LivreActionableAgile

Titre: Actionable Agile – Metrics for predictability

51deom263vl

Titre: Kanban

Une équipe peut apprendre Kanban de manière autodidacte grâce aux livres les plus connus ou encore faire appel à des experts.  Il se trouve d’ailleurs que dans le cadre de sa série de Formations Signature, Facilité Informatique organise la première formation sur la méthode Kanban à Québec, les 5 et 6 mai prochains. Daniel Vacanti, pionnier de la méthode, sera en ville pour expliquer comment mettre en application celle-ci. Profitez de cette occasion exceptionnelle pour apprendre des meilleurs et ainsi être meilleur à satisfaire votre clientèle!

Monte Carlo, le CH et Kanban

Dans l’édition du 19 février du journal La Presse, on y publiait un article à propos des chances du Canadiens de Montréal de faire le tournoi printanier. On pouvait y lire qu’Alain Bonnier, physicien consulté par le journal, donnait très peu de chances aux Canadiens à se rendre en série.

Alain Bonnier estime à 3,9 % les chances du Tricolore de participer au prochain tournoi printanier.

Il s’agit de la 94e prédiction de la part de ce physicien, qui a effectué sa première prédiction pour La Presse en janvier 1989. Or, 92 de ses 93 premières prédictions se sont avérées !

Pour arriver à cette prédiction, M. Bonnier s’est servi d’un outil mathématique qui se nomme les simulations de Monte Carlo:

C’est un calcul de probabilités par la méthode de Monte-Carlo, explique M. Bonnier au téléphone. On part des résultats de tous les matchs depuis le début de la saison. À partir de ça, on simule le reste de la saison. J’ai donc simulé 30 000 fois le reste de la saison. À la fin des 30 000 simulations, on compile les résultats pour voir le pourcentage de chances de participer aux séries.

Les simulations de Monte Carlo sont utilisées dans une multitude de domaines pour aider à prendre une décision. Dans son excellent livre Actionable Agile- Metrics for predictability, Daniel Vacanti mentionne cela:

It has proved a useful tool in all kinds of fields like nuclear physics, oil and gas exploration, finance, insurance, etc. Given the uncertainty in knowledge work it seems strange that our industry has been rather late to the Monte Carlo game.

Sachant que la méthode Kanban utilise le diagramme de flux cumulatifs pour visualiser l’historique de notre système Kanban, les experts Kanban se tournent vers les simulations de Monte Carlo pour prévoir avec un pourcentage, comme pour les Canadiens, les probabilités de date de livraison d’un item de travail. Grâce aux outils de Focus Objectives, on peut exécuter ces simulations de Monte Carlo.

Dans le cadre de sa série de formations Signature, Facilité Informatique est fier d’organiser la première formation sur la méthode Kanban à Québec. Les 5 et 6 mai prochains à Québec, Daniel Vacanti, pionnier de la méthode, sera à Québec pour expliquer comment mettre en application celle-ci. Profitez de cette occasion exceptionnelle pour apprendre des meilleurs et ainsi être meilleur à satisfaire votre clientèle!

Lecture d’un cumulative flow diagram

Ce billet a comme objectif d’expliquer mon interprétation du cumulative flow diagram (CFD), un graphique fortement utilisé par les gens qui appliquent la méthode Kanban.

Table des matières

  • Introduction
  • Lire le travail en cours (WIP)
  • Identifier les goulots d’étranglement
  • Lire le lead time
  • Lire le cycle time (temps de cycle)
  • Prédire la fin du projet avec un CFD
    • Option 1 – Utiliser la pente pour la barre Terminé
    • Option 2 – Utiliser le graphique des temps de cycle (Cycle time scatterplot)
    • Option 3 – Générer des probabilités de complétion
  • Ressources

Lire la suite