Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

What's next ... pour Agile?

Publié par Louis-Philippe Carignan le jeudi 16 janvier 2014 à 17:06

Cela fait maintenant près de 13 ans que le manifeste Agile a été rédigé et signé. Au tout début, et un peu avant même, XP, Crystal, DSDM et Scrum étaient les approches les plus souvent empruntées pour faire du développement « léger ». Pendant la décennie qui a suivi la signature du manifeste, XP, Scrum et Lean Software Development se sont distinguées du peloton. Depuis les dernières années, les sondages annuels de VersionOne ont toujours montré que Scrum et XP étaient les deux approches les plus employées sur le terrain. 

Mais les promoteurs de ces approches vieillissent. Ils sont pour la plupart dans la soixantaine. Certains ont pris leur retraite ou travaillent sur de nouveaux projets. 

Alors que se passe-t-il du côté de la relève? Qui sont les nouveaux joueurs et quelles sont les nouvelles approches qui prennent la relève? Bien que tous s’entendent dans notre communauté pour dire que la manifeste Agile survivra, avons-nous fait le tour avec l'Agilité et sommes-nous simplement rendus à répéter le message?

Voici un tour d’horizon des approches qui, à mon avis, semblent être en émergence.

Lean Startup

Piloté par Eric Ries qui a publié son livre « The Lean Startup » en 2011, ce créneau s’oriente beaucoup plus vers le côté Affaires du développement. Bien qu’il soit le seul homme au front, plusieurs livres ont été écrit en lien avec le sujet dont « The Lean Entrepreneur » et « UX for Lean Startups ». Une conférence a aussi lieu à chaque année et point important à mon avis, il a un logo pour représenter ce qu’il vend (Oups, s’cusé, promouvoit). Âgé de seulement 33 ans, nous n’avons sûrement pas fini d’entendre parler de Lean Startup. Je trouve que c’est une bonne chose que Lean Startup rayonne puisque les 10 premières années de l’Agilité étaient très orientées vers le développement. Lean Startup nous aidera à améliorer nos relations avec les utilisateurs.   

La méthode Kanban

David J. Anderson est à la tête de cette méthode qui, malheureusement, continue de s’accrocher avec Scrum. Probablement à cause des égos dans chaque camp à mon avis. Tout comme Lean Startup, les gens derrière la méthode Kanban tiennent plusieurs conférences annuelles. D’autres joueurs comme Jim Benson, Karl Scotland et Yuval Yeret viennent supporter David dans ses efforts de promotion. Des organismes comme le Lean-Kanban University (LKU) et la Limited WIP Society tentent de pousser cette approche sur plusieurs fronts. La LKU a la responsabilité de former des gens avec l’approche tandis que la Limited WIP Society tente d’être le point d’entrée de la communauté vers des ressources, blogues et outils pour soutenir la méthode Kanban.

Management 3.0

Puisque la majorité des signataires du manifeste Agile étaient fortement encrés dans le côté technique, certaines carences sont apparues avec le temps pour que l’Agilité s’établisse dans des organisations. L’une d’elle était la gouvernance ou plutôt, comment les gestionnaires (directeurs/vp/coordonnateur) doivent s’adapter pour comprendre et garder Agile vivante dans leur organisation. Publié en décembre 2010 par Jurgen Appelo, « Management 3.0 » est un livre orienté pour le gestionnaire Agile et comment ils doivent adopter leur posture lorsque l’Agilité s'enracine dans leur organisation. Par exemple, les auteurs précédant Management 3.0 donnaient peu d’explications lorsqu’ils abordaient le concept d’auto-organisation. Ils mentionnaient tout simplement que la meilleure structure d’une équipe était l’auto-organisation. Jurgen consacre plusieurs chapitres sur ce sujet pour mieux informer le gestionnaire de son rôle dans cette nouvelle structure. 

Agile Coaching Institute

Et pendant ce temps, Lyssa Adkins publie son livre « Coaching Agile Teams » en 2010. Tout comme Jurgen, Lyssa est venu répondre a un besoin manquant mais cette fois-ci, c’est au niveau des Scrum Master et des coach Agile. Encore une fois, les fondateurs de l’Agilité avaient mis l’accent sur l’équipe, le code, les bonnes pratiques (user stories, planning poker, tableau visuel) et la mécanique itérative et incrémentale. Il existait peu de livres pour parler en long et en large du Scrum Master, pourtant un rôle important dans tout ça. Lyssa a d’ailleurs fondé le Agile Coaching Institute avec Michael Spayd en 2010.  L’objectif de cet institut est de faire grandir les coach Agile qui sont des agents de transformation dans les organisation. Pour avoir suivi leur cours « Coaching Agile Teams (CAT) » et « The Coaching Stance », j’ai été très satisfait du contenu ainsi que de l’approche.

Expansion organisationnelle

Pendant que les personnes ci-haut poussent de nouvelles approches en lien avec l’Agilité, des personnes qui sont dans le domaine depuis plusieurs décennies reviennent à l’avant-front avec une façon pour élargir l’Agilité à toute l’organisation.

  • Scaled Agile Framework (SAFe) : Dean Leffingwell, un ancien vp de Rally Software et Rational Software, offre un cadre de développement Agile qui s’étend à toute l’organisation. Intitulé « Scaled Agile Framework », il divise l’organisation en trois couches pour qu’elle livre de la valeur au client : Portfolio, programme et équipe. Le site web de SAFe est particulièrement bien fait avec un schéma global détaillé qui permettre au lecteur d’approfondir les sections qu’il désire.
  • Path to Agility (PtA) : Peut-être par opportunisme, Ken Schwaber vient de lancer un modèle pour Scrum au niveau organisationnel. Nommé « Path to Agility », il n’est pas encore détaillé au grand publique. Bien qu’il ait écrit le livre « The Enterprise and Scrum » en 2007 expliquant comment l’organisation s’adapte à Scrum, Schwaber semble avoir modifié son approche pour inclure une boucle d’amélioration continue.
  • Disciplined Agile Delivery (DAD) : J’ai très peu d’information à propos de « Disciplied Agile Delivery », maintenu par Scott Ambler et Mark Lines. Contrairement à SAFe et Path to Agility, DAD semble est ouvert à toute personne qui désire s'implique dans la conception de DAD. Ils ont écrit un livre en 2012 mais je ne peux pas m'avancer plus à ce sujet.

J'ai aussi omis les approches de développement comme la livraison continue (Continuous Delivery) de Jez Humble et l'intérêt remarqué pour le BDD par des gens comme Matt Wynne. L'unique raison est que mes compétences techniques fondent à vu d'oeil à cause de l'évolution de ma carrière. Je me sens donc hésitant de bien commenter ces approches techniques, mais je les considèrent toujours aussi importantes dans le grand cadre de l'Agilité.

Il est encore trop tôt pour savoir ce qui va arriver avec SAFe, Path to Agility et DAD. Avec l’apparition de nouvelles plateformes telles que les mobiles, les tablettes et l’infonuagique, il sera intéressant de voir si ces techniques viendront modifier les habitudes de réalisation logicielle.

Une chose est certaine à mon avis, l’Agilité semble encore pertinente après une première décennie. Mary Poppendieck semble donc s’être trompée lorsqu’elle annonçait en 2011 que notre industrie se renouvèle à chaque décennie. En regardant de plus près les thèmes mentionnés dans ce billet, on s’aperçoit que ceux-ci sont en place pour continuer à supporter la manifeste Agile.

Mots-Clés :

L'inventaire, c'est du gaspillage

Publié par Louis-Philippe Carignan le lundi 13 janvier 2014 à 16:18

« In manufacturing, inventory is waste. »

Première phrase à la page 24
« Implementing Lean Software Development »
Mary et Tom Poppendick

Un peu plus bas dans cette page, les auteurs transposent ce concept en développement logiciel.

« The inventory of software development is partially done work. » 

Ok. Facile. En Agile/Lean, l’une des façons de minimiser le gaspillage est de compléter ce que l’on a commencé. Plus loin, aux pages 74 et 75 du même livre, les auteurs énumèrent ce qu’est le travail incomplet :

  • Documentation/requis qui n’est pas codé
  • Code désynchronisé
  • Code non testé
  • Code non documenté
  • Code non déployé

Pour moi, je transpose encore davantage ce concept dans ma liste de tâches professionnelles (ma todo liste). Je tiens donc ma liste de choses à faire très courte. Tout comme on ne veut pas avoir une longue liste de requis auquel on ne réussira jamais à faire au grand complet, je ne garderai jamais une longue liste de choses à faire puisque je sais très bien que je ne réussirai jamais à tout faire et que, d’ailleurs, de nouvelles tâches s’ajouteront à ma liste.

Ceci étant dit, j’étais quand même curieux d’avoir une deuxième opinion sur la question pour voir si ma réflexion était la bonne. Après tout, si je prône les valeurs Agile/Lean, je préfère prêcher par l'exemple.

Personal Kanban

Jim Benson a lancé le site personalkanban.com en 2009 où il explique comment il a transféré les principes industriels du Kanban pour visualiser et contrôler son travail personnel.

Dans son billet « Building your first personal Kanban », Jim explique comment monter son système Kanban :

  • Établir sa carte de valeur (value-stream)
  • Établir son backlog
  • Établir la limite du travail en cours (TEC)
  • Commencer à tirer sur les items du backlog

Puisque ma liste de tâches professionnelles s’exécute sous ce même principe, je lui ai donc écrit sur Twitter pour avoir son opinion à propos de la taille du backlog que l'on monte à l'étape 2.

Voici donc les réponses qu’il m’a données :

Conversation Jim Benson 

J’ai aimé ses réponses.  Lorsqu’il mentionne dans sa réponse du haut qu’un gros backlog est un signe que j’ai plus de « Work In Progress (WIP) » que je ne le croyais, c’est un signe de réviser ma limite WIP. Si ma limite WIP est très élevée, je me retrouve avec beaucoup de travail incomplet. Et puisque du travail incomplet est du gaspillage, je dois m’efforcer d’identifier ce qui ne sera jamais fait et m'en débarasser. 

Plus particulièrement, les questions suivantes dans la conversation Twitter m’ont aidé à identifier la taille du backlog :

  • What is your personal kanban goal?
  • What work is valuable there?

Dans le cas de la première question, l’objectif de mon Kanban professionnel est de réaliser les tâches avec le plus de valeur en premier.

Pour répondre à sa deuxième question, je valorise seulement le travail auquel je crois pouvoir m’attaquer rapidement (disons moins de 2 semaines). Le travail que je ne crois pas réaliser dans ce laps de temps est périssable. Quelque chose de nouveau sera plus important. 

Et votre liste de tâches professionnels?

Et qu'en est-il de votre liste de tâches? Si vous faîtes la promotion des valeurs Agile/Lean dans votre milieu de travail, est-ce que l'organisation de votre travail professionnel est elle aussi Lean?  

 

Mots-Clés :

33 modèles organisationnels sous Scrum

Publié par Louis-Philippe Carignan le mardi 4 juin 2013 à 12:00

J’adore les auteurs qui font des ouvrages de référence en informatique. Je trouve ces gens courageux de répertorier de façon exhaustive un volet de notre profession. À ma connaissance, ils le font par altruisme puisque les nombreuses heures passées à documenter et réviser ces ouvrages ne sont probablement pas les plus palpitantes d’une vie. J’aime aussi lire le dédicace que les auteurs en informatique offrent au début de leur livre. Les avez-vous déjà lu? Habituellement, ils remercient leur femme (ou mari) pour le support moral lors de ces nombreuses soirées où l’auteur devait travailler seul.

Mes deux ouvrages de référence préférés sont Design Patterns et xUnit Test Patterns. Lorsque ma candidature pour devenir un Certified Scrum Coach (CSC) à la Scrum Alliance a été refusé la première fois, on m’a référé le livre Organizational Patterns of Agile Software Development de James O. Coplien et Neil B. Harrison.

Ce petit bijou de 400 pages a été une révélation pour moi. Ces auteurs avaient documenté les modèles organisationnels Agile et ce, bien au-delà des fameuses techniques/pratiques que je connaissais déjà (TDD, BDD, refactoring, intégration continue). Il faut faire attention au terme « modèle organisationnel ». On ne parle pas de modèle pour structurer une organisation. Puisqu’un « design pattern » en programmation est traduit par « modèle de conception », j’étais tenté de traduire « organizational pattern » par « modèle organisationnel ». Il faut bien s’entendre donc qu’un modèle organisationnel dans ce billet représente, à mes yeux, une façon de faire dans le but de rendre l’organisation plus agile à la fin de la journée.

Coté 5 étoiles sur 5 chez Amazon.com, le livre de Coplien et Harrison répertorie les modèles que l’on peut mettre en place pour qu’une organisation de développement logiciel livre de la valeur. N’oubliez pas que modèle organisationnel n’est pas synonyme de bonne pratique. Pour les lecteurs proches du PMBOK, garder en tête qu’une organisation Agile comprend qu’elle est dans un environnement complexe et que la mise en place de bonnes pratiques n’est pas suffisante pour s’adapter à l’environnement complexe du XXIième siècle. Les modèles dans le livre permettent d’avoir une organisation vivante qui est en mesure de s’adapter aux problèmes qu’elle fait face dans un environnement en constante évolution.

33 modèles dans Scrum

J’avais lu dernièrement un billet sur le blogue de Jeff Sutherland (Scrum Inc.) où l’on avançait que Scrum comportait 33 modèles organisationnels :

Recent work by Jim Coplien shows that Scrum is deceptively simply while compressing a complex array of organizational patterns in his book, "Organizational Patterns in Agile Software Development." Jim was surprised when he found that Scrum compresses at least 33 patterns from his book into a concept that can be explained in 2 minutes.

Un lien vers la présentation de Coplien permet de voir cette décomposition. Entre les diapositives 20 et 23, on peut voir plusieurs modèles répertoriés par catégorie. À la diapositive 24, on peut finalement voir les 33 modèles dans une seule hiérarchie.

Scrum Organizational Patterns

À la gauche complètement de cette image, le premier modèle est « Community of Trust ». On prend ensuite différent chemin, c’est-à-dire qu’on ajoute de nouveaux modèles au précédent. Finalement, tous les chemins menant à Rome, c’est-à-dire que le dernier modèle qu’apporte Scrum a une organisation est le « Team Pride ».

Si vous comptez les bulles bleues, vous devriez arriver à 33.

De la théorie à la pratique

J’entends déjà les lecteurs pragmatiques quitter ce billet puisque tout ce volet est beaucoup trop théorique. J’aimerais illustrer comment ces modèles se conjuguent à votre réalité.

Prenons le chemin dans le haut de l’image précédente, c’est-à-dire les bulles suivantes où les parenthèses réfèrent aux modèles dans le livre de Coplien: 

  • Community of Trust (p. 34)
  • Work Queue (p. 62)
  • Informal Labor Plan (p. 64)
  • Developer Controls Process (p. 70)
  • Group Validation (p. 174)
  • Team Pride (p. 128)

Décortiquons maintenant chaque modèle. Voyons comment Scrum le met en place et comment chaque modèle vient appuyer le prochain. Dans les sections suivantes, le texte en gras est extrait du modèle organisationnel dans le livre « Organizational Patterns of Agile Software Development ». Un court texte suit pour expliquer concrètement la mise en application de ce modèle dans une équipe Scrum.

Community of Trust

It is essential that the people in a team trust each other; otherwise, i twill be difficult to get anything done.

Do things that explicitly demonstrate trust. Managers, for example, should make it overtly obvious that they facilitate the achievement of organizational goals, rather than playing a central role to assert control over people. Take visible actions to gve developers control over the process.

Avant de mettre tout autre modèle en avant, il faut tout d’abord que l’équipe se fasse confiance. Et c’est ce qu’on essaie de faire avec les trois piliers de Scrum dont la transparence est le premier. En étant transparent, autant dans son travail que dans ses relations avec ses collègues, on débute par bâtir une communauté de confiance dans l’équipe Scrum.

Work Queue

It is difficult to perform linear, monochronic scheduling in light of implied requirements. 

Produce a schedule that is simply a prioritized list of work. Use the list of implied requirements as a starting point to situate them into a likely implementation order, favoring the more urgent or higher priority items.

Dans son livre, Coplien compare le product backlog de Scrum à ce modèle. En effet, on demande toujours de mettre tout (fonctionnalités, cas d’utilisation, histoire utilisateur, requis non-fonctionnel) dans un seul et unique product backlog. On ne retrouve pas une liste de bogues dans un backlog à part. Si c'est votre situation, posez-vous la question en réfléchissant sur ce modèle.

Avec Scrum, cette seule et unique liste est la concrétisation du modèle « Work Queue ». Une fois que l’équipe se fait confiance, elle peut alors attaquer les items du product backlog.

Informal Labor Plan

A schedule of developer work tasks can both assist workers in planning their time and provide reassurance to stakeholders about scheduling expectations.

Let individuals devise their own short-term plans.

Maintenant qu’on connaît le travail à faire dans le product backlog grâce au modèle « Work Queue », l’équipe peut maintenant s’attaquer aux items les plus importants de cette pile. Avec Scrum, on prescrit le carnet d’itération comme étant le plan de livraison que l’équipe doit mettre en place au début de chaque itération pour livrer la commande au client. À mon avis, c’est une mise en application de ce modèle. On demande à l’équipe de faire son propre découpage en tâches. Si le plan de livraison n’est pas assez précis, le product owner a le droit de questionner le carnet et ainsi demander des précisions pour calmer ses inquiétudes.

Developer Controls Process

A development culture, like any culture, can benefit from recognizing a focal point of project direction and communication. 

Make the developer the focal point of process information.

Avec Scrum, on peut souvent lire que l’équipe est le moteur d’une organisation. C’est elle qui transforme des requis périssables en livrable. Pour exprimer ce point de vue de façon imagée, j’ai déjà entendu l’analogie suivante : une équipe Scrum, c’est un peu comme une Ferrari sur un gros paquebot.

 Ce que ce modèle prescrit, c’est de mettre le développeur au centre du processus de développement. J’extrapole un peu ce modèle pour Scrum où je remplace le mot « développeur » par « équipe ».

Group Validation

Product quality is crucial to the success of the enterprise. 

Even before engaging QA, the development team – including the customer – can validate the design.

Selon ma compréhension de ce modèle, l’équipe doit se valider pour assurer un livrable de qualité. Avec Scrum, cela prend forme à quelques endroits pendant une itération. Tout d’abord, l’équipe se concerte à chaque jour lors de mêlée quotidienne. C’est une validation informelle à mon avis. Une deuxième validation formelle est la revue d’itération pour assurer la qualité du produit.

Mais il y a aussi des moments plus informels dans Scrum comme une revue de code commune (coding dojo) ou une séance d’analyse pour préparer la prochaine itération. Celles-ci ne sont pas exigées par Scrum bien que permises. Lors de ces rencontres, on valide en équipe le code ou l’expression du requis pour s’assurer qu’il est de qualité.

Team Pride

People are most successful when they feel good about their project and when they are confident. But there is a chicken and egg problem here: Confidence breeds success, but success creates confidence.

Instill a sense of elitism into the team. Teams that have a certain arrogance tend to work hard and accomplish what is put before them.

Et finalement, une fois que:

  • la confiance s’est installée (Community of Trust),
  • le travail est défini dans une seule liste (Work Queue)
  • l’équipe est en mesure d’organiser son travail (Informal Labor Plan)
  • l’équipe est au cœur du développement (Developer Controls Process)
  • et l’équipe se valide entre elle (Group Validation)

On peut finalement atteindre le dernier modèle d’organisation que nous offre Scrum, c’est-à-dire la fierté d’équipe.

Vous n'êtes pas convaincu. Prenez ce modèle à l'envers?

Est-ce qu'on peut être une équipe fière si:

  • on ne se fait pas confiance? Non.
  • on ne connait pas le travail à faire? Non. L'équipe ne sait pas quoi bâtir.
  • on ne peut pas gérer son propre travail? Discutable mais probablement que non.
  • on n'est pas au centre du développement? Discutable mais plus stimulant si on l'est.
  • on ne se valide pas pour livrer de la qualité? Non. Êtes-vous fier de vous lorsque vous livrer un produit de piètre qualité. 

Pour conclure

Si on revient à notre image des 33 modèles, je la trouve très utile puisqu’elle aide un coach Agile/Scrum Master à faire un diagnostique (état des lieux) de son équipe. En identifiant les modèles actuellement en place dans l’équipe, on peut se positionner dans la carte des modèles et identifier les prochains à mettre en place avec l'équipe.

Lors des formations à propos de Scrum, je souligne souvent le fait que Scrum est extrêmement facile à comprendre mais difficile à maîtriser. Bien que l’image suivante soit souvent mon point de départ pour expliquer Scrum en 2 minutes, on s’aperçoit avec ces 33 modèles organisationnels pourquoi Scrum est ensuite difficile à maîtriser.

Scrum process

Et c'est pour ces raisons, et bien d’autres encore, que Scrum continue à être la méthodologie Agile la plus employée année après année.

100% Agile ... vraiment?

Publié par Louis-Philippe Carignan le vendredi 24 mai 2013 à 19:00

Je lisais dernièrement sur une présentation de Ken Schwaber à propos d'un sondage effectué par Forrester Research auprès de 205 organisations pour connaître leur utilisation de l’Agilité. Dans sa présentation, Ken questionnait, à la diapositive #11, ce que voulait dire ce 100%. Comment a-t-on réussi à mesurer que 20% de ces organisations étaient Agile à 100%?

Forrester Research

Mais un autre point a piqué ma curiosité dans cette présentation. À la diapositive #3, on y pose la question « Who Is Responsible For Creating More Agility? ». Bien que plusieurs corps de métier soient énumérés à la gauche, un encadré à la droite pointe vers les gestionnaires. J’ai trouvé cette réflexion intéressante puisque je trouve que beaucoup d'efforts a été déployé depuis les 10 dernières années à convaincre les équipes d'adopter l'Agilité. Mais maintenant que les professionnels en T.I ont fait ce changement, qu'en est-il de l'ouverture et la compréhension de la gouvernance face à la philosophie Agile?

Who Creates Agility

Je trouve que les deux personnes les plus en vue ces dernières années en Agilité sont Lyssa Adkins et Jurgen Appelo. Et ces deux personnes visent essentiellement le management dans leur message. Avec son livre « Coaching Agile Teams », Lyssa parle aux Scrum Masters, coach Agile et gestionnaires Agile pour les aider à adopter une nouvelle posture de gestion. Elle a fondé l’institut de coaching Agile avec Michael Spayd où elle offre une série de cours qui cible ces corps de métier, quelque chose qu’on ne retrouvait pas nécessairement il y a plusieurs années. Au Canada, on retrouve maintenant le Agile Coach Camp, un évènement annuel où les coach Agile peuvent se rencontrer.

Du côté de Jurgen Appelo, son livre « Management 3.0 » vise aussi les gestionnaires à s’adapter à la philosophie Agile. Tout comme Lyssa, il offre aussi des cours basés sur son livre. 

Dans son rapport « The Shift Index » en 2011, Deloitte mentionnait qu’on se dirigeait vers du Agile de deuxième génération. Je croyais au début que la méthode Kanban de David Anderson était le candidat potentiel pour cette deuxième génération d’approches Agile.

Mais avec l’apparition du Scaled Agile Framework (SAFe) de Dean Leffingwell, le Disciplined Agile Delivery (DAD) de Scott Ambler et le Path To Agility de Ken Schwaber, je me demande si la deuxième génération d’Agilité ne sera pas plutôt axée vers l'entreprise au grand complet. Ces trois "trucs"/"approches"/"framework" semblent voulour répondre à un besoin organisationnel pour devenir de plus en plus agile face aux changements constants de notre industrie.

En ce début de cette deuxième décennie portant sur l'Agilité, notre industrie ne semble pas se ré-inventer (pour l'instant) comme elle l'a si bien fait dans le passé. En attendant de voir ce qui va arriver avec la méthode Kanban, DAD, SAFe et Path To Agility, il sera intéressant de définir un jour ce que veut dire "être une organisation 100% Agile" et si cela peut mieux se mesurer que les résultats obtenus lors du sondage de Forrester.

Une firme de service-conseils TI pas comme les autres

Publié par Louis-Philippe Carignan le mercredi 22 mai 2013 à 10:00

En avril 2012, Infoq.com a publié la liste des 20 personnes les plus influentes en Agilité. En 20ième position, on retrouve Henrick Kniberg, un suédois dont la biographie mérite d’être lue avant de continuer à lire ce billet. Il est aussi co-propriétaire de Crisp, une petite firme de consultants en technologie de l’information en Suède.

En mai 2010, Henrik a publié un billet à propos de Crisp où il raconte comment ils ont découvert leur identité. Pendant des années, il trouvait que leurs rencontres de compagnie biannuelles ne donnaient pas les résultats escomptés. 

"Every conference we would spend lots of effort around a big conference room table attempting to define these things, but the only results would be a bunch of wiki pages (our intranet) with lots of different options and ideas. No clear decisions."

Une année, Henrik a donc emprunté une approche différente pour identifier leur vision. Il a fait les étapes suivantes:

  • Découvrir leur vision et la mettre en mots.
  • Rendre la vision physique.
  • Dessiner avec des crayons de plomb puisque la vision n’est jamais finale.
  • Limiter l’espace pour se forcer à choisir les bons mots.
  • L’afficher partout.
  • Obtenir l’approbation de tous.

Comparativement à d’autres organisations qui font un exercice similaire, le résultat de cette expérience a fait son bout de chemin au travers le temps. Une fois leur identité découverte avec cette vision en dessins, des éléments intéressants en ont découlé. Voici ce qu’Henrik raconte sur son blogue

Indice du bonheur – version Crisp

Maintenant outillé avec leur vision sous forme de dessins, Crisp a mis sur pied l’indice du bonheur, une simple feuille de calcul sur Google Spreadsheet qui mesure, de 1 à 5, le niveau de bonheur de chaque personne à chaque mois.

On y trace un graphique mensuel où on fait la moyenne de cet indice. Si le graphique montre une courbe négative, les gens deviennent alors concernés et travaillent ensemble pour résoudre ce qui irritent leurs collègues.

HappinessGraph.jpg 

Voici le constat d’Henrik par rapport à cette mesure :

"Crisp Happiness Index is more important than any financial metric, not only because it visualizes the aspect that matters most to us, but also because it is a leading indicator, which makes us agile. Most financial metrics are trailing indicators, making it hard to react to change in time."

Leur indice du bonheur est un bon indicateur puisqu’il donne un aperçu de ce qui va se produire dans la compagnie. En étant heureux chez Crisp, les employés rendront heureux leurs clients. Henrik fait le constat que les indicateurs financiers sont en arrière (lagging) puisqu’ils donnent une lecture après qu’une prestation de service ait été faite chez un client.

La valeur des actions chez Crisp

Leur indice du bonheur a permis une autre prise de conscience aux employés de Crisp:

"As a result of understanding our own values better, we’ve dramatically changed our partnership contract between Crisp stock owners. We’ve literally made our own stock worthless (at least from a pure monetary perspective)"

Vous avez bien lu. Leurs actions ne valent plus rien sur le plan monétaire. Ils ne veulent pas être une firme pour enrichir les actionnaires. Ils veulent être une maison pour les consultants en technologie de l’information.

Il est d’ailleurs dommage qu’il n’explique pas en détails ce volet. Je serais curieux de connaître comment Crisp gère sa comptabilité, paie ses impôts ou si un partage de revenus annuel est fait.

Et leur plan pour gérer la croissance

En continuant la lecture de l’article, on apprend que pour eux, la croissance de l’entreprise n’est tout simplement pas un paramètre qu’ils désirent contrôler. Puisqu’ils s’identifient comme étant une maison pour consultants en TI, c’est plutôt leur indice du bonheur qui indiquer si leur croissance actuelle est plaisante (ou non). J'ai entendu plusieurs fois des gestionnaires expliqués comment la croissance était importante pour aller chercher de nouvelles opportunités d'affaires. Crisp a une vision tout à fait différente de la croissance. Elle n'est pas liée aux opportunités d'affaires mais à l'indice du bonheur de ses employés.   

En conclusion

Je vous invite à consulter les deux dessins qu’Henrik présente au début de son article. Il a traduit les mots en anglais pour faciliter notre compréhension. Le premier montre la maison des consultants avec les valeurs importantes à leurs yeux. Mais c’est le dessin à la deuxième page qui est plus révélateur à mon avis. L’image « What do we do with money? » est particulièrement intéressante ainsi que la mesure du bonheur à la gauche de la feuille. Si les employés sont heureux, leurs clients le seront tout autant.

Comme le dit si bien les Poppendieck dans leur troisième excellent livre « Leading Lean Software Development » à la page 198 à propos des entreprises dans l'économie du savoir :

"In knowledge work, success comes entirely from people and the system within which they work. Results are not the point. Developing the people and the system so that together they are capable of achieving successful results is the point."

Archive