Les croyances et la culture…c’est dans l’air qu’on respire!

J’ai écouté une baladodiffusion récemment (Hidden Brains, de NPR avec Shankar Vedantam) fort intéressante sur la psychologie humaine. On connaît l’adage: « Mais qu’ont-ils mis dans l’eau pour donner ______(mettre ce que vous voulez ici)______? ». Or, il semble que cette affirmation soit à peu près vraie, mais beaucoup plus subtile.  Ce n’est pas dans l’eau que ça se passe, mais dans l’air…  Explications:

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

 

C’est mieux de fonctionner

(English follows)

Le développement logiciel est déjà difficile et, pourtant, face à un choix entre une solution technologique difficile ou une sécuritaire, nous choisissons souvent l’option risquée, souvent accompagnées de bénéfices supérieurs.  Les raisons d’affaires derrière ce choix sont claires, mais que se passe-t-il avec l’engagement de l’équipe face à ce défis supplémentaire?  Regardons de plus près comment, en tant que membre d’une équipe ou en tant qu’équipe dans une organisation, notre engagement change radicalement dépendamment si nous partageons cette charge avec nos gestionnaires.  Ici, l’attitude du leader Agile est clé.

Pour illustrer ceci, regardons une scène du film Moneyball où Billy Bean, le directeur général d’une équipe de baseball, a une conversation avec Peter Brand, un jeune homme avec la folle idée de choisir en utilisant seulement les mathématiques.  Dans la scène, Billy et Peter observent la première pratique de leur équipe nouvellement formée de joueurs indésirables. Peter, clairement stressé par l’ampleur du risque qu’ils prennent, regarde les joueurs, alors que Billy vient vers lui et lui dit: “C’est mieux de fonctionner!” À ce moment, l’attitude de Peter passe d’un bon stress à une peur intense avec la réalisation que Billy est prêt à lui donner le blâme en cas d’échec.  Heureusement, Billy donnait dans l’humour et Peter peut donc retourner dans son état de bon stress, mais toutefois plutôt confus par le sens de l’humour noir de son patron.

Peter, sans une organisation créant un espace sécuritaire pour faire l’essai de sa théorie, n’aurait jamais travaillé sur son idée.   Aussi, Billy aurait pu dire à Peter de mettre en place son idée, tout en le prévenant qu’il serait (Peter) responsable en cas d’échec.  Dans ce scénario, Peter aurait soit refusé l’emploi, soit fait trop de compromis pour éviter l’échec.  En réalité, dans notre histoire, Billy avait vraiment créé un espace sécuritaire dans lequel Peter pouvait prendre des risques, vivre des échecs, apprendre de ces derniers et prendre de nouveaux risques.  Bien que Peter soit responsable de la réalisation de son idée, Billy est clairement imputable d’avoir pris cette nouvelle direction. Cette collaboration, basée sur la confiance, les engage vers un but commun.

Créer un espace pour votre équipe demande un bon effort.  Se joindre à eux dans cet espace est le vrai défi.

tumblr_nhkky7aA0n1s0t6o2o1_500

Phillipe Cantin

This better work

Software development is hard enough, yet, when faced with the choice between a difficult or a safe technological path, we tend to choose the riskier one which often comes with better results.  The business reasons behind such a choice are obvious, but what about the team’s engagement toward this extra challenge?  Let’s take a particular look at how, as a team member or as a whole team inside an organisation, our commitment will change dramatically whether or not we are sharing the load with our leadership.  Here, the Agile leader’s attitude is key.

To illustrate this, let’s look at a scene from the movie Moneyball where Billy Bean, a baseball team general manager, is having a conversation with Peter Brand, a young guy with the crazy idea of selecting players using only math.  In the scene, Billy and Peter are witnessing the first practice of their newly formed team composed of unwanted players. Peter, clearly stressed by the huge risk they are taking, is observing the players as Billy Bean walks up to him and says : “This better work.”  At this moment, Peter’s mood changed from healthy stress to pure fear with the realization that Billy was ready to blame him personally if the plan fails.  Luckily, Billy was only joking and Peter could return to his healthy stress, now combined with the knowledge of his boss’s dark sense of humor.

Peter, without an organization creating a safe space to test his theory, would have never fully tried his idea.  Also, Billy could have initially told Peter to implement his idea while warning him that he (Peter) would be held responsible in case of failure.  In this scenario, Peter would have either not accepted the job or over-compromised in order to avoid failure.  In the actual story, Billy did create a safe space for Peter to take chances, fail, learn and try again.  Also, even though Peter is responsible for the implementation of his idea, Billy is clearly accountable for the decision of trying this new approach. This collaboration, based on trust, engages both of them in the same goal.

Creating a safe space for your team takes effort.  Standing in that space with them is the real challenge.

tumblr_nhkky7aA0n1s0t6o2o1_500

Phillipe Cantin

Astéroïdes – un vrai jeu Agile!

En 1979, Atari lançait le jeu Asteroids… un vrai jeu Agile!

L’utilisation des métaphores et des analogies est une technique de coaching efficace et bien connue.  Elle permet de déplacer une personne de son environnement de travail vers un environnement autre, mais familier, et de discuter de concepts tout en réduisant les « oui, mais ça marche pas comme ça ici ». En voici une qui permet d’expliquer un grand nombre de concepts Agile dans un ensemble cohérent: Lire la suite

DevOps, l’apogée de l’Agilité?

On parle beaucoup de DevOps ces temps-ci. Mais est-ce qu’on saisit bien toute sa définition et les impacts de son implantation au sein d’un organisme ou une entreprise? Commençons par bien définir le DevOps pour avoir une meilleure perspective que le simple « buzzword ».

Au premier abord, on peut penser que faire du DevOps, c’est tout simplement une histoire d’outils:

Devops_Outils

Euh, mais non. Bien que certains outils soient nécessaires pour automatiser les aspects de notre livraison en continu, il y a bien plus que cela en jeu. Le fait de choisir des outils, de les l’installer, de les configurer et de s’en servir ne veut pas nécessairement dire qu’on fait du DevOps. Donc:

Devops_pas_outils

Poursuivons notre analyse. Si les outils ne règlent pas tout, j’imagine qu’il faut y mettre un peu de collaboration. La collaboration usuelle à laquelle on pourrait facilement penser est bien sûr la suivante:

devops_dev_op

Tout à fait d’accord avec ceci! D’ailleurs, il faut faire attention si on travaille actuellement en silos (développement et opération) de ne pas répéter la même chose avec DevOps en la mettant elle aussi dans un silo. On n’a pas besoin d’une troisième équipe qui fonctionne ainsi, n’est-ce pas? On a besoin davantage d’unir les forces de l’équipe de développement et de celles des opérations (environnement, sécurité, livraisons, mise en production, etc) afin de plutôt en faire une équipe qui s’entraide mutuellement. Bref, on veut que tout le monde se préoccupe des livraisons en production.

Par contre, je vais être déplaisant et poser ma question de coach:

C’est bon, vous voulez livrer en continu, mais pourquoi? Cela donne de la valeur à qui en bout de compte?

Oups, il nous manque une partie importante dans notre équation! Donc:

devops_pas_dev_op

La partie affaires (utilisateurs, pilotage, PO, analyste d’affaires) doit aussi être incluse dans notre équation DevOps, ce qui équivaut à représenter le DevOps ainsi:

devops

Il manque ainsi une bonne partie de l’équation si on fait du DevOps sans se préoccuper du côté affaires, avec des éléments tels que:

Les affaires, le développement et les opérations ont tous à la base des objectifs différents:

  • Développement: livraison d’incrément du produit;
  • Opérations: stabilité, fiabilité et sécurité;
  • Affaires: exigences en constante évolution pour obtenir de meilleurs produits et des clients contents.

Le DevOps devrait donc permettre d’aligner ensemble les objectifs de ces trois aspects.

De plus, je vais être à nouveau déplaisant, mais sans l’aspect des tests automatisés, il est très difficile, voire impossible, de faire du DevOps convenablement.  Eh oui, il est temps de vous réveiller si vous ne faites actuellement aucuns tests automatisés sur vos systèmes ! Et idéalement, il faut les faire AVANT le code en mode TDD (Test-Driven Development).  Cela vous permettra de clarifier les intentions et diriger les efforts avant d’écrire le code de production.

Pour faire des tests automatisés correctement, des approches Agile et un paquet de pratiques d’ingénierie Agile sont aussi très utiles.

Et si on voyait le DevOps comme l’apogée de l’Agilité, soit la poursuite logique de notre transition vers l’Agilité par la maîtrise des approches Agile, qui sont sensés pour nous dans notre contexte, afin de pouvoir livrer en continu? Bref, voir le tout comme un rassemblement de forces (ou pratiques) Agile nous poussant vers le DevOps!

Eh oui, le DevOps est probablement l’objectif ultime à atteindre! Avec lui, on relève toutes sortes de points à améliorer, pas juste au niveau de l’équipe de développement. C’est comme de l’amélioration continue au niveau de l’entreprise ou organisme au complet.

Et la beauté dans tout cela, c’est qu’on a pas besoin de maîtriser toutes les nombreuses pratiques Agile, les valeurs, le Lean Software Development et le Lean Startup pour faire du DevOps. Pas non plus obligé de se développer comme les Amazon et Netflix de ce monde avec leurs méga infrastructures. On peut y aller à petits pas, comme mentionné par Kent Beck dans son XP Programming. Voici quelques exemples:

  • Passer de 2 à 4 livraisons par année est un objectif très louable;
  • Automatiser graduellement les trucs effectués manuellement pour gagner continuellement en productivité;
  • Se bâtir une suite de tests automatisés sur nos composants de logique d’affaires;
  • Etc.

En fin de compte, il vaut probablement mieux évoluer vers de petites livraisons avec peu de changement que de grosses livraisons avec beaucoup de modifications et de risques.  On peut donc y voir ici un très bon ROI potentiel si on investit dans le DevOps.

devops2

Quand on implante DevOps, il ne faut pas oublier de voir à pouvoir se remettre d’une mauvaise mise en production rapidement. Il faut ainsi permettre des erreurs dans un environnement sécuritaire pour apprendre et arrêter de faire tout le temps les mêmes choses à chaque mise en production sans se remettre en question.

Il est fort probable qu’un changement de culture soit également nécessaire dans votre entreprise. Mais rien n’est impossible, même chez vous, peu importe le contexte. On peut trouver plusieurs exemples d’entreprises qui ont mis des applications Legacy dans un mode DevOps, notamment afin de les revitaliser.

J’espère que cet article a su démystifier le « buzzword » DevOps qu’on entend régulièrement de nos jours.

Références:

Estimer, oui mais comment?

Que ce soit lors d’un sprint planning ou dans une réponse d’appel d’offre, l’estimation est essentielle. Peu importe l’unité (t-shirt size, story point, temps en heures, $$$, j/p, etc.), les experts sont appelés à estimer presque quotidiennement. Mais une question demeure: comment mesurer la fiabilité de l’estimation produite par un expert? Est-ce qu’un sénior dans un domaine en fait automatiquement un expert en estimation?

Certains diront qu’il est impossible d’obtenir une évaluation d’une précision acceptable en TI en raison de la trop grande variabilité du domaine (#NoEstimates). Contrairement à la construction, on ne peut mesurer la surface à couvrir et s’appuyer sur des chantiers similaires pour en extrapoler les coûts. Malgré tout, je ne crois pas que la tâche soit impossible.

L’estimateur est un outil de mesure

L’expert estimateur est un outil de mesure au même titre qu’un pèse-personne ou qu’un ruban à mesurer. On s’attend donc à ce qu’il soit précis et exact. Généralement, lorsqu’on demande à l’expert d’estimer, on favorise un seul de ces points puisqu’on lui demande un nombre unique. Il devient alors impossible de déterminer si l’estimé est exact (peu de risque de dépassement) ou précis (proche de l’effort réel).

Lire la suite

Agile Tour Sherbrooke 2017

L’Agile Tour Sherbrooke 2017 est maintenant derrière nous. Facilité est extrêmement fière d’avoir participé à cette première édition.

Merci aux participants et organisateurs qui ont rendu l’événement possible! Ce fût une belle journée bien remplie. Merci également à ceux qui sont venus assister à nos conférences « Architecture/Préparation Express » et « En route vers l’optimisation! Votre succès avec Kanban étape par étape » .

Si vous avez manqué nos conférences ou aimeriez en revoir le contenu, nous nous faisons un plaisir de les rendre disponibles ici.

Architecture/Préparation Express

(Version en PDF)

Si vous avez des questions ou commentaires, vous pouvez communiquer avec les auteurs Éric Lessard et Frédéric Paquet.

En route vers l’optimisation! Votre succès avec Kanban étape par étape

(Version en PDF)

Si vous avez des questions ou commentaires, vous pouvez communiquer avec les auteurs Valéry Germain et Nicolas Mercier.

Revenu Québec et l’Agilité se distinguent lors du gala ANALYZ de l’IIBA

Le 5 mai dernier, dans le cadre du gala ANALYZ de l’IIBA région de Québec, Revenu Québec s’est vu décerner le Prix Graal 2017 pour « La mise en place d’une démarche de réalisation des dossiers d’affaires en mode Agile ».  Dans le cadre de nos mandats actuels à Revenu Québec, nous sommes fiers d’avoir eu la chance de contribuer à l’élaboration et la mise en oeuvre de cette démarche innovante.

Félicitations à toute l’équipe de Revenu Québec pour cet autre beau succès lié à vos efforts de transformation Agile.