Blog

2016-06-14

Facilité Informatique, une référence en transformation Agile d’envergure

Lauréat2016

 

C’est jeudi le 2 juin dernier, lors du concours des Octas, que Facilité Informatique apprenait avec une joie peu contenue que nous remportions les honneurs dans la catégorie Transformation des processus organisationnels – GRANDE ENTREPRISE pour notre intervention auprès de Revenu Québec en collaboration avec Pyxis.

Ce prix, remis entre les mains du directeur principal des solutions d’affaires de Revenu Québec, M. Guy Rochette, devenait une preuve incontestable de notre impact en tant qu’acteur de premier niveau dans une transformation Agile d’une envergure jamais vue pour notre gouvernement québécois.

Les résultats générés peuvent en inspirer plusieurs et ce succès confirme maintenant Facilité Informatique en tant que référence dans son domaine. En moins de 3 ans, chapeautée par 20 accompagnateurs maîtrisant la matière et des spécialistes internes, cette réorganisation du travail et des processus, jumelée à l’intégration des meilleures pratiques de génie logiciel, de conception et de communications, a permis le rayonnement d’une nouvelle culture pour l’ensemble de l’organisation.

Plus en détails, pour atteindre le but visé, nous avons entre autres participé à :

  • La création d’un bureau de transformation Agile
  • Soutenir l’agilité en possédant l’expertise nécessaire tant sur le plan du génie logiciel et de l’organisation du travail que de la gouvernance
  • Déployer une démarche méthodologique Agile et disciplinée s’appuyant sur les approches Disciplined Agile Delivery (DAD) et Scrum
  • Réorganiser le travail des équipes d’entretien et de service à l’aide de l’approche Scrumban
  • L’adoption de nouvelles techniques de génie logiciel modernes provenant des méthodologies XP et Agile Modeling et de l’approche de conception pilotée par le domaine (domain-driven design)
  • La tenue d’ateliers techniques de type ‘’dojo’’ pour accompagner les développeurs dans l’acquisition de nouvelles techniques de génie logiciel
  • L’innovation des tableaux de bord de suivi de projet
  • L’invention d’outils de mesure servant à aider les équipes et les directions à mesurer leur niveau d’agilité et à établir les cibles d’amélioration continue (QIX)
  • L’élaboration de la stratégie DevOps

 

Revenu Québec, c’est une clientèle qui compte plus de 8 millions de citoyens et d’entreprises. Vous et moi pouvons désormais bénéficier d’un gain d’efficience de l’agence, d’une hausse de la qualité de ses produits, d’un temps de réponse plus rapide et d’une amélioration du service à la clientèle…et c’est un peu grâce à nous.

On est prêts à recommencer ! Communiquez avec nous au 418-780-3950 pour nous parler de vos besoins en transformation Agile.

 

Facilité Informatique – fière de faire la preuve, qu’au gouvernement, ON PEUT FAIRE LES CHOSES AUTREMENT.

2016-05-17

Planifiez vos formations Agiles de cet été !

quelle-formation-pour-cet-c3a9tc3a9

Les experts de Facilité Informatique vous offrent une panoplie de moyens pour vous outiller durant la belle saison. Un  excellent moyen de vous ressourcer !

Professional  Scrum Master BONIFIÉ

-Montréal 6 au 8 juin 2016

-Gatineau 6 au 8 juillet 2016

-Québec 18 au 20 juillet 2016

Gestion des exigences Agiles

-Québec 20 au 21 juin 2016

-Montréal 7 au 8 juillet 2016

Le développement piloté par les tests (TDD)

-Québec 27 juin 2016

-Montréal 8 août 2016

Professionnal Scrum Developer

-Québec 8 au 10 juin 2016

-Montréal 29 au 31 août 2016

Architecture Agile et ouverte

-Québec 6 au 7 juin 2016

Introduction aux approches de développement Lean et Agile

-Québec 16 juin 2016

Mise en place d’une équipe Scrumban

-Québec 10 juin 2016

Planification est Suivi de projet Agile

-Québec 21 au 22 juin 2016

 

2016-04-18

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!

2016-04-13

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.

2016-04-04

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!

2016-03-29

Le Manifeste du BDD

BDD Manifesto

On voit des manifestes un peu partout ces jours-ci. Étant un passionné de BDD (Behavior-Driven Development), je me disais que cela serait pertinent d’en faire un à ce sujet.

L’objectif, pour moi, est de pouvoir résumer rapidement la technique avec des exemples, et surtout de faire prendre conscience que le BDD n’est pas une histoire d’outils avant tout. En fait, l’outil peut même s’avérer facultatif et arriver dans un deuxième temps.

Bref, afin de comprendre rapidement ce qu’est le BDD, voici mon manifeste :

Combler le fossé de communication entre le domaine d’affaires et le développement
plus que
Développer sans connaitre les objectifs et la vision affaires

L’équipe de développement est responsable de la qualité
plus que
C’est la responsabilité du testeur

Se valider fréquemment à l’aide d’exemples et d’explorations
plus que
Découvrir les bogues plus tard dans le processus de développement

Obtenir une documentation vivante des spécifications de notre système
plus que
Avoir une documentation lourde et coûteuse  à mettre à jour

Avoir des communications efficaces, rapides et avec des perspectives différentes
plus que
Travailler de manière hiérarchique et en silos

Établir des scénarios et des exemples concrets, accessibles et abstraits
plus que
Établir des scripts de tests détaillés et complexes

Automatiser l’exécution des tests fonctionnels
plus que
Réaliser manuellement tous les tests fonctionnels

Qu’en pensez-vous ?

Vos commentaires et critiques sont très appréciés afin d’améliorer ce manifeste.

Vous voulez en savoir davantage ? Il y aura une formation pour le côté fonctionnel et technique « Introduction au BDD » bientôt chez notre partenaire AFI.

Autres manifestes:

Références BDD:

2016-03-17

Rétrospective sur la collaboration

Récemment, je devais tenir une rétrospective dont le sujet principal était la collaboration entre trois équipes. On parle régulièrement de la collaboration au sein d’une équipe, mais force est de constater que la collaboration inter-équipes est un sujet qu’on aborde moins souvent.

J’ai donc parcouru internet à la recherche d’idées dans l’espoir que la rétrospective que j’allais tenir porte ses fruits.

Je suis tombé sur un article de blog publié par Renzo Venini sur le site de Scrum Alliance. Dans son article, M. Venini présentait une méthode basée sur des souhaits et des offres pour finalement converger vers des actions. Je vous laisse lire l’article original si vous souhaitez  en savoir un peu plus sur sa technique.

Très intéressé par sa technique, j’ai tenté une approche afin que les équipes identifient leurs souhaits en considérant d’autres axes que ceux qu’ils emploient habituellement.

AtelierCollaboration

En me basant sur le Team Trust Canvas élaboré par Alexey Pikulev, j’ai créé un canvas identifiant les axes de collaboration inter-équipes.

CanvasCollaboration

J’ai détaillé ma version de la technique de rétrospective dans la section outils du site. Je vous invite à consulter la page correspondante par ici.

2016-03-15

L’engagement en Kanban vs Scrum

Je lis actuellement l’excellent excellent excellent livre de Daniel Vacanti, Actionable Agile, Metrics for Predictability, que vous pouvez acheter sur Leanpub.com.

J’ai adoré cette citation à propos de l’engagement de la méthode Kanban versus Scrum.

Kanban approach to commitments is very different than, say, Scrum. Scrum commitments are made at the sprint level. At the beginning of a sprint, a team commits to getting some number of stories finished by the end of the sprint. That commitment is based on more upfront estimation and planning.

In a flow-based approach, teams commit at the individual work item level. Once an item is pulled into the process a commitment is made as to when that item should be done. That commitment is based more on measurement and observation rather than planning and estimation.

Ce que j’aime de plus en plus dans la méthode Kanban, c’est l’effort mis pour comprendre son système à l’aide d’observations et de mesures pour le rendre prévisible.

Et voici un exemple d’un engagement selon Vacanti pour un item de travail qui passe dans un système Kanban:

We expect this item to flow all the way through the process and exit in 14 days or less with an 85% probability of success.

Pour ceux et celles qui se demandent comment je fais pour prédire cet engagement en Kanban, je vous réfère à l’ensemble d’outils de Focused Objectives sur GitHub dont le fichier Excel Single Feature Forecaster.xlsx qui nous génère un tableau:

MonteCarloSimulation

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 cette méthode. Profitez de cette occasion exceptionnelle pour apprendre des meilleurs et ainsi être meilleur à satisfaire votre clientèle.

2016-03-09

Un Scrum Master en position d’autorité: une option à ne pas écarter

J’ai trouvé le dernier billet de Mike Cohn fort intéressant car il adresse un enjeu avec lequel je suis constamment confronté sur le terrain.  Que faire si le Scrum Master est aussi en lien d’autorité avec son équipe ?

common advice in the Scrum community is that a team should never, ever report to their Scrum Master

Le piège le plus souvent cité est la possibilité que l’équipe ne soit pas très transparente envers son manager. De plus, en situation de stress, le manager se sentant imputable des résultats de l’équipe pourrait être tenté par le micromanagement. Ceci étant dit, qu’enseigne-t-on aux gestionnaires Agiles?  Quelle est la principale qualité du manager Agile?

Mener votre organisation comme si vous n’aviez aucune autorité » (Kan Higashi)

Une équipe a-t-elle  avantage à cacher de l’information à son manager?  Comment peut-il aider et soutenir l’équipe s’il n’a pas accès à la bonne information?

With the right manager in place as ScrumMaster, this programmer should be extremely willing to say he’s behind because he knows that manager-slash-ScrumMaster is going to be doubly incentivized to and capable of resolving that issue

If the right person is doing double duty as both ScrumMaster and a personnel manager, I have no problem with it.

Le rôle de Scrum Master aurait-il été créé pour camoufler une dysfonction de notre système de gestion traditionnel?  Est-ce qu’on a « tassé » les gestionnaires dans les transformations Agiles, ou est-ce qu’on les accompagne individuellement dans la transformation de leur style de leadership?  je crois qu’il faut faire la même chose avec les chefs d’équipe et chargés de projet, les aider à ajuster leurs postures pour supporter des équipes auto-organisées, les aider à devenir des leaders 3.0, les aider à devenir des Scrum Masters.

With the right person in the dual role of ScrumMaster and manager, it can work well. In an ideal world, I’d love to separate ScrumMastering from personnel management. But I rarely get to live in that ideal world.

And this is a compromise that works fine. Rather than banning everyone from being both ScrumMaster and manager, I’d rather allow it. And then only fill the position with the right people.

Après tout, ne valorisons-nous pas les individus davantage que le processus (et les descriptions de rôles qui viennent avec) ?

Blog original

When I first started doing Scrum, I was what we’d call today the team’s ScrumMaster and product owner. But we didn’t have those terms back then. And without terms or any clarity on the roles, it was easy for me to make the mistake of being both. I also did some programming. Oh, and I was also the vice president of the software department, so my team reported to me.

I want to address that last role because common advice in the Scrum community is that a team should never, ever report to their ScrumMaster. That is, I could have been the ScrumMaster or the VP — but I should not have been both at the same time to the same team. (And to be clear, everything I’ll write here is going to apply to any personnel manager, whether that’s a manager, director, vice president or even CEO.)

While I don’t think it’s desirable to have team members also have a reporting relationship to their ScrumMaster, I don’t think it is always horrible. Much depends on the person who is filling both roles. One of the common arguments against a manager as the team’s ScrumMaster is that team members will become reluctant to raise issues. For example, a programmer who is behind on a task will not be willing to say so in the daily scrum if his or her manager is also the ScrumMaster. That’s simply not true. With the right manager in place as ScrumMaster, this programmer should be extremely willing to say he’s behind because he knows that manager-slash-ScrumMaster is going to be doubly incentivized to and capable of resolving that issue. If the right person is doing double duty as both ScrumMaster and a personnel manager, I have no problem with it. If the wrong person is in place, there are lots of problems.

But it’s time to stop defining processes to prevent problems and create workarounds for the troublesome people in the organization. Instead, assume the right people are in place and then work to create a culture that puts the right people in place. With the right person in the dual role of ScrumMaster and manager, it can work well. In an ideal world, I’d love to separate ScrumMastering from personnel management. But I rarely get to live in that ideal world. And this is a compromise that works fine. Rather than banning everyone from being both ScrumMaster and manager, I’d rather allow it. And then only fill the position with the right people.Doing that will help your team succeed with agile.

Mike Cohn

2016-03-02

The Tyranny of the timebox

Le titre révèle tout. Dans sa présentation en 2014 intitulée « 10 years of Kanban – What have we learned », David J. Anderson rappelle le concept du « Tyranny of the timebox » proposé à Agile 2009.

KanbanTyrannyTimebox

Plus loin dans sa présentation, Anderson mentionne que la méthode Kanban a passé le chasm en 2012.

KanbanCrossingTheChasm

Pour ceux qui connaissent le livre Crossing the chasm, ce terme veut dire qu’une technologie est passée du stade d’adoption à celui d’être mise en place par la majorité de la population.

Et vous, où êtes-vous par rapport à votre adoption de la méthode Kanban dans vos équipes?

Dans le cadre de ses 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 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.