Cessez de jouer à Tetris avec votre temps

La surcharge est mère de tous les vices dans la philosophie Lean (Muri). C’est une plaie qui afflige la plupart des travailleurs intellectuels que je croise. La surcharge est tellement perverse que si vous en souffrez, vous ne vous en rendrez compte que trop tard. Voici quelques exemples de ce à quoi vous vous exposez:

  • Mauvaise prise de décision au quotidien;
  • Rater des dates limites;
  • Réduction globale de la productivité;
  • Augmentation de la charge mentale;
  • Fatigue professionnelle;
  • Aucun temps pour l’innovation;
  • Aucun temps pour l’apprentissage;
  • Aucun temps pour la collaboration (vous êtes un bloquant pour les autres);
  • Perte de motivation;
  • Attitude réactive et défensive, au lieu de proactive et constructive;
  • Sensation de perte de contrôle;
  • Perte d’efficacité dans vos communications (ex: envoi d’un courriel au lieu d’une conversation face à face, répondre sèchement par manque de temps, etc.)
  • Impossible de réagir efficacement aux imprévus/changements de plan;
  • Dégradation de votre santé mentale et physique;
  • Dégradation de vos relations professionnelles;
  • Être perçu comme quelqu’un de fermé et d’insensible aux priorités de ses collègues.

Lire la suite

Prendre des décisions Agile et Lean

Au delà des méthodes et des pratiques, il y a les concepts de base. De nos jours, Agile et Lean sont devenus des buzzwords qu’on utilise à toutes les sauces. Pourtant, quand on creuse la question, on réalise souvent que notre interlocuteur n’a aucune compréhension de la philosophie derrière les mots.

Que se cache-t-il derrière ces grands concepts? Qu’est-ce qui distingue quelqu’un qui est Agile et Lean de quelqu’un qui ne l’est pas?

La réponse réside dans la façon dont les décisions sont prises. Pour déterminer si une méthode, une décision ou une pratique est Agile et Lean, on doit la peser selon un filtre décisionnel bien précis.

Lire la suite

Les 3M du Lean, une formule magique

Je ne ferai pas la description exhaustive des 3M car il y a une très belle page rédigée à ce sujet ici. J’écris ce court billet simplement pour vous partager qu’il y a plusieurs approches pour éliminer le gaspillage. La plus répandue est la chasse aux Muda puisqu’ils sont très connus et qu’il existe même des catégorisations du Muda.

J’ai fait l’expérience récemment de la simulation Okaloa Flow Labs qui m’a démontré que si au contraire nous partions à la chasse aux Muri (surcharges), le reste suit aisément jusqu’à la réduction maximale des Muda.

Attaquer la surcharge en premier (Muri)

Dans un système où les experts sont valorisés et les généralistes ignorés, on note presque systématiquement de la surcharge et des goulots d’étranglement. Une des bonnes façons de diagnostiquer la surcharge est de porter attention à la mesure d’efficience du flux (flow efficiency). On l’obtient assez simplement en divisant le temps actif passé sur une tâche (souvent disponible dans des systèmes de suivi de temps) par son délai de réalisation.

Lire la suite

Les derniers articles de Mary Poppendieck

Mary Poppendieck, une de mes auteures préférées en TI, a rédigé deux excellents articles depuis les 6 derniers mois. Je trouve que ses articles valent toujours le temps que l’on y consacre. Je vous les propose si vous avez un bon 30 minutes de libre devant vous.

Friction

Dans cet article, Mary parle de friction dans toutes sortes de domaines relatifs au TI. La deuxième moitié de l’article est principalement centrée sur la friction dans les gouvernements. J’ai fait ressortir quelques extraits et me suis permis de mettre en gras certains passages:

Uber is among the largest of a new crop of startups – investor Chris Dixon calls them full stack startups – that bypass incumbents and reinvent the entire customer experience from start to finish with the aim of making it as frictionless as possible. Full stack startups focus on creating a world that works the way it should work, given today’s technology, rather than optimizing the way it does work, given yesterday’s mental models.

Large companies have the same full stack of capabilities as startups, but these capabilities lie in different departments and there is friction at every department boundary.

Code bases created and maintained by full stack teams are much more resilient than the large and calcified code bases created by the project model precisely because people pay attention to (and change!) the internal workings of “their” code on an on-going basis.

Broadly speaking, these fiascoes are caused by the process most governments use to procure software systems – a high friction process with a very high rate of failure.

One country that does not have an IT fiasco story is Estonia, probably the most automated country in the world. A few years ago British MP Francis Maude visited Estonia to find out how they managed to implement such sophisticated automation on a small budget. He discovered that Estonia automated its government because it had such a small budget.

The UK government changed – seemingly overnight – from high friction processes orchestrated by procurement departments to small internal teams governed by simple metrics. Instead of delivering “requirements” that someone else thinks up, teams are required to track four key performance indicators and figure out how to move these metrics in the right direction over time.

It turns out that when governments move from the old mental model to the new mental model, many of the things that were considered “good” or “essential” in the past turn out to be “questionable” or “to be avoided” going forward. These are

  • Requirements generate friction.
  • Handovers generate friction.
  • Organizational boundaries generate friction.
  • Estimates generate friction.
  • Multitasking generates friction.
  • Backlogs generate friction.

Teams need only three lists: Now, Next, and Never. There is no try.

Once upon a time, governments assumed that obtaining software systems through a procurement process was essential, because it would be impossible to hire the people needed to design and develop these systems internally.  They were wrong. They assumed that having teams scattered about in various government agencies would lead to a bunch of unconnected one-of systems. They were wrong. They were afraid that without detailed requirements and people accountable for estimates, there would be no governance. They were wrong. Once they abandoned these assumptions and switched to the low friction approach pioneered by Estonia, governments got better designs, more satisfied consumers, lower cost, and far more predictable results.

Lien vers l’article complet: Friction

Five World-Changing Software Innovations: How They Happened

Dans cet article, Mary raconte les 5 innovations que nous n’avons pas suivi pendant que nous parlions d’Agilité depuis 15 ans. Celles-ci sont:

  1. The Cloud
  2. Big Data
  3. Antifragile Systems
  4. Content Platforms
  5. Mobile Apps

Voici quelques citations pour vous donner le goût de lire l’article:

Concernant le Cloud:

The idea that infrastructure is context and the rest is core helps explain why internet companies do not have IT departments. For the last two decades, technology startups have chosen to divide their businesses along core and infrastructure lines rather than along technology lines. They put differentiating capabilities in the line business units rather than relegating them to cost centers, which generally works a lot better. In fact, many IT organizations might work better if they were split into two sections, one (infrastructure) treated as a commodity and the rest moved into (or changed into) a line organization

À propos du Big Data, Mary raconte la petite histoire du Big Data depuis 2001:

Netflix, which has a good number of reliability engineers despite the fact that it has no data centers.

En ce qui a trait au Content Platforms:

Three entrepreneurs – Chad Hurley, Steve Chen, and Jawed Karim – tried out an interesting use case for video: a dating site. But they couldn’t get anyone to submit “dating videos,” so they accepted any videos clips people wanted to upload. They were surprised at the videos they got: interesting experiences, impressive skills, how-to lessons – not what they expected, but at least it was something. The YouTube founders quickly added a search capability. This time they got the use case right and the rest is history.

Video is the printing press of experience.

À propos des Mobile Apps:

 By 2014 (give or take a year, depending on whose data you look at) mobile apps had surpassed desktops as the path people take to the internet.

The nature of mobile apps changes the software development paradigm in other ways as well. As one bank manager told me, “We did our first mobile app as a project, so we thought that when the app was released, it was done. But every time there was an operating system update, we had to update the app. That was a surprise!

Lien vers l’article complet: Five World-Changing Software Innovations: How They Happened

Notes de lecture : Lean Change Management

Nous avons beau avoir de bonnes intentions, être passionnés d’Agilité et dévoués à nos clients, mais l’humain étant ce qu’il est, il est fort difficile de prévoir comment il peut changer !

Comme dans tout bon projet informatique, on ne peut donc pas tout prévoir en détails la planification de la gestion du changement. Pour surpasser les résistances et obtenir des implémentations de changement avec succès, on doit donc adapter les techniques traditionnelles de gestion du changement en y mettant un peu d’Agilité et du « lean ». On ne peut pas tout savoir ou prévoir au départ et il nous faut l’accepter. On doit donc se baser sur les principes et valeurs Agiles pour guider nos actions dans le changement.

C’est le sujet principal du livre « Lean Change Management – Innovative Practices for Managing Organizational Change » dont je vais vous parler aujourd’hui.

Son auteur, Jason Little, est un canadien, ancien développeur et maintenant conseiller en gestion du changement, il a mis à l’épreuve les différentes techniques décrites dans son livre pour une organisation publique canadienne.

Bien que ce soit un petit livre, il fait un peu moins de 200 pages, ce dernier est quand même rempli de processus, frameworks, conseils et autres outils pertinents pour une gestion du changement « lean » et Agile. Tout cela s’articule autour du cycle intitulé « Lean Change Management » que voici :

lean-change-cycle

En gros, voici ce que veut dire chaque étape traduite librement en français:

  • Aperçus (Insights): Comprendre l’état actuel des choses dans l’organisation. Pour collecter cette information, il y a plusieurs méthodes et outils tels que : sondages, entretiens, rétrospectives, etc. Une fois toutes ces informations recueillies, il faut les analyser dans sa vue globale et voir les options à essayer.
  • Options: Les options à mettre en action ont toutes un coût, une valeur et un impact. Prendre celles qui font le plus de sens dans le contexte actuel afin de valider les hypothèses émises.
  • Expérimentations: Introduire un changement via une option et voir comment il en résulte. Cette étape a aussi le sous-cycle suivant :
    • Préparation: Préparer à valider nos hypothèses et notre approche avec les personnes affectées par le changement.
    • Introduction : Le changement est introduit dans le processus.
    • Révision : On regarde les résultats après un certain temps. Selon ce qui s’est passé, on peut prévoir un autre cycle d’expérimentation.

Dans les premiers chapitres du livre, on introduit rapidement le cycle et ses origines. Pour le reste du livre, on décrit en détails chacune des étapes du cycle avec, bien entendu, les commentaires et l’expérience vécue de l’auteur. Ce qui en fait un livre captivant et intéressant à lire. Lors de sa lecture, il nous arrive de prendre note de plusieurs éléments et conseils qui pourront nous servir en tant que coach Agile. Tout ceci est valable autant pour des changements de processus que pour l’adoption de nouvelles techniques telles que le TDD. Un « must » donc à lire pour tout coach Agile impliqué dans une transformation Agile.

En résumé, voici mes trois leçons apprises suite à cette lecture:

  • Utiliser un cycle basé sur le feedback pour mesurer le changement.
  • Impliquer les gens affectés par le changement dans la conception du changement.
  • Bien mesurer nos options. Chacune d’entre elles a un coût, une valeur et des impacts.

Références :

Ce que l’on a retenu de l’Agile Tour Québec 2015

Comme chaque année, l’Agile Tour Québec est une journée spéciale. En plus de formations et conférences, c’est une belle occasion d’avoir des échanges intéressants et de renouer avec d’anciens et de nouveaux collègues. Voici donc les faits saillants que nous avons retenus de cette journée:
Conférence Principale
L’expert de l’Agilité disciplinée, Scott Ambler, était de passage en tant que conférencier principal. Il a bien sûr discuté sur son approche, DAD, surtout au niveau entreprise.
  • On ne peut se limiter qu’à Scrum. On doit s’élever davantage, notamment  au niveau de l’entreprise.
  • Afin de s’élever, il faut avoir une pensée tactique et stratégique.
  • Comment réagiriez-vous si Google essayait de prendre votre business ?
  • Chaque {personne, équipe, organisme} est unique. On ne peut donc appliquer la même recette à tous.
  • Même chose pour les « lifecycle » de nos systèmes informatiques, un format ne convient pas à tous.
  • Bon conseil: toujours faire les choses les plus risquées en premier.
  • Important: l’équipe doit être au courant de la vision d’entreprise.

[slideshare id=54900825&doc=disciplinedagileenterprise-151109100627-lva1-app6892&w=650&h=500]

Lean/Kanban/Kaizen
Le lean est toujours présent à l’Agile Tour sous une forme ou l’autre. Comme par exemple:
Kaizen ou amélioration continue:
  • Petits changements simples que l’on peut contrôler 
  • Pas une responsabilité du gestionnaire, mais plutôt celle des équipes; le gestionnaire encourage cette responsabilité et la catalyse.
  • Ludifier une initiative d’amélioration continue permet de mobiliser les gens.
  • Il faut impliquer les équipes dans la ludification en leur faisant définir les règles et le système de récompense.

 

User Expérience (UX)
Le UX avait une bonne présence cette année avec 2 conférences. Voici en gros ce que l’on a retenu:
  • Le UX, c’est une forme de mentalité dans le processus de développement
  • La recherche se veut :
    • Efficace
    • Efficiente
    • Satisfaisante
    • Compréhensible
  • Le UX est composé de plusieurs techniques qui se regroupent dans les thèmes suivants:
    • Prototypage
    • Analyse d’affaire
    • Design visuel
  • Aller voir les utilisateurs pour réaliser le bon produit afin d’obtenir une meilleure adoption
  • Important de récompenser les échecs, cela nous permet d’apprendre
  • 3 saveurs au UX: Traditionnel, Agile et Lean
  • Bref: L’expérience humaine prime avant tout !
Pratiques Techniques:
Plusieurs sujets divers parlant du coté technique tels que:
L’excellence technique:
    • Nous sommes dans l’ère de la créativité désormais. Sommes-nous prêts ?
      Pour soutenir cette créativité et rester compétitif, il faut être capable de s’adapter rapidement. Pour cela, il faut mettre la qualité du code en priorité.
    • La connaissance est maintenant partout et les choses se complexifient
    • Besoin d’avoir une main d’oeuvre passionnée et curieuse car nous tendons vers une société axée sur le logiciel
    • Les pratiques d’extrême programming sont un préalable à l’Agilité, le code doit être Agile pour être Agile. Scrum et XP sont complémentaires.
    • L’excellence ce n’est pas d’être parfait mais d’être passionné, curieux (il questionne et n’est jamais satisfait du statu quo..) et créatif.
    • Vaut mieux embaucher une personne excellente que 10 mauvaises, l’embauche est la chose la plus importante.
Processus de développement:

Innovmetric a implanté de nouvelles pratiques afin de pallier à ses problèmes qui ralentissaient le développement :

    • Implantation de l’Agilité afin de faciliter la communication dans le cadre du développement et le bon travail d’équipe
    • Des outils ont été implantés afin de :
      • Tester quotidiennement la performance en mesurant le temps d’exécution des fonctionnalités.
      • Détecter la mauvaise utilisation de pointeurs et références en C++.
      • Valider les dépendances entre les modules/projets qui ont été implantés.
      • Enregistrer la pile d’appels dans un fichier dès qu’une exception anormale a lieu.
    • Les tests unitaires automatisés et de simulation de clics, sont exécutés sur une grande variété de systèmes d’exploitation et sur des comptes utilisateurs Windows ayant des droits d’accès variés.
    • Se sont dotés d’une politique pour que 10% des tâches des sprints soient consacrées à l’amélioration continue du système, et 90% pour le développement standard de nouvelles fonctionnalités.
    • L’intégration continue permet de connaître facilement la cause d’un impact négatif sur les tests automatisés ou sur un écran utilisateur. Il suffit de voir quels fichiers ont été modifiés depuis la dernière compilation/exécution des tests et d’analyser le tout afin de connaître la cause du problème et le correctif requis.

Au final, ça rapporte d’implanter ces processus:

    • Les coûts de développement sont maintenant moins grands qu’au départ.
    • Les employés sont plus heureux compte tenu qu’ils travaillent en collaboration et dans un cadre d’amélioration continue.
    • L’embauche et la formation de ressources est plus facile, compte tenu que le système est entouré de processus clairs et fiables.

Bref, dans l’ensemble les conseillers de Facilité Informatique ont bien apprécié cette journée. On a déjà hâte d’être à l’an prochain pour découvrir de nouveaux sujets afin d’améliorer notre Agilité.