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.

La valeur des actifs logiciels

Publié par David Beaumier le mercredi 26 novembre 2014 à 09:39

J’ai beaucoup apprécié l’allocution d’ouverture du dernier Agile Tour de Québec par Michael Feathers. J’ai trouvé qu’il abordait des aspects souvent négligés en développement logiciel. Une des choses qui m’a particulièrement accrochée c’est lorsqu’il a mentionné que les organisations devraient devenir plus consciente de la valeur et de l'état de leurs actifs logiciels.

Aujourd’hui combien d’organisation seraient en mesure de fonctionner normalement sans utiliser une solution logicielle? J’en connais bien peu. La plupart des organisations ont des besoins assez élaborés : outils de collaboration, suivi des opérations, relation clientèle, gestion financière, partage de fichiers, systèmes de téléphonie, etc. Qu’elles aient acquis et piloté un progiciel ou investi dans le développement d’une application sur mesure, des ressources importantes ont été engagées dans ces  solutions logicielles.

Malheureusement, la nature même d’un logiciel (ne dit-on pas justement software en anglais) vient fausser la perception que peuvent en avoir les différentes fonctions de l’organisation. En comptabilité on inclut les logiciels dans la catégorie des « actifs incorporels », aussi appelée « capital immatériel ». Bien qu’il existe des façons de déterminer la valeur financière courante de ces actifs, ça se corse lorsqu’il vient le temps de planifier les investissements futurs requis pour maintenir ceux-ci dans un état permettant d’apporter de la valeur à l’organisation.

Avouez que c’est plus simple de déterminer que l’entrepôt vaut 250 000$ et de prévoir un montant annuel pour couvrir les taxes foncières, les assurances, etc. Un gestionnaire attentif remarquera probablement aussi que la toiture commence à être endommagée et qu’il faudra envisager son remplacement d’ici 2-3 ans.

L'hypothèque logcielle

Est-ce que le même gestionnaire sera en mesure de se rendre compte que le moteur de base de données de son système d’expédition s’apprête à être dépassé en fonction du volume projeté des ventes des prochains mois? Est-ce que les parties prenantes ont pris la peine d’inclure la capacité du système dans leurs analyses?  Pas certain. En contrepartie, est-ce que l’équipe de développement a communiqué le vieillissement de la technologie? A-t-elle mis en place ce qu’il faut pour mesurer les performances du système en production?

HypothequeLogicielleLe jour ou le système deviendra si lent qu’il ne sera quasiment plus utilisable (sans doute pendant la période la plus active de l’année) est-ce que l’organisation aura le luxe de procéder à une mise à jour tout en douceur? L’équipe de développement pourrait devoir prendre certains raccourcis pour livrer rapidement une solution corrigée. C’est une approche tout à fait acceptable si elle permet à l’organiser de retrouver sa vitesse de croissance. Par contre, toutes les parties impliquées doivent être conscientes de l’hypothèque logicielle qui grève maintenant le système.

Prenons l’exemple du camion de livraison d’un marchand de meubles pour illustrer cette situation. Si ce marchand néglige l'entretien de son camion en évitant de procéder à un changement d’huile pour pouvoir effectuer plus de livraisons, il risque d’en payer le prix s’il ne planifie pas un autre moment pour faire cet entretien. Une panne lors d'une grosse journée de livraisons risque lui coûter cher et lui causer bien plus de souci qu’une période d’entretien planifiée.

Feathers a mentionné dans son allocution que certaines organisations rendent ces hypothèques visibles et incluent dans le plan de produit les activités requises pour s’en libérer. En procédant au remboursement, l’organisation réduit la possibilité de se retrouver dans une situation où sa dette logicielle l’empêche de saisir une opportunité d’affaires.

C'est, à mon avis, un devoir qu’ont les professionnels du développement logiciel de garder l'organisation dans son ensemble informée de l'état de leurs systèmes. L’information doit pouvoir remonter de l’équipe de développement jusqu’aux parties prenantes. Il faut travailler pour éviter les situations où un gestionnaire se fait dire un bon matin « Votre logiciel est désuet. Il faut le réécrire et on en a pour x mois et ça vous coûtera x centaines de milliers de $ ».  En même temps, les organisations doivent devenir plus sensibles à l’égard de leurs actifs logiciels, poser des questions aux équipes et prévoir un plan pour limiter le gonflement de l’hypothèque logiciel. 

Pour en savoir plus

D'autres billets sur le même thème

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."

Culture. Culture. Culture.

Publié par Louis-Philippe Carignan le samedi 2 mars 2013 à 00:00

Lorsque je donne le cours Professional Scrum Master (PSM), je m’efforce de toucher le point de la culture organisationnelle à quelque part. Partant de la fameuse citation de Peter Drucker « Culture eats strategy for breakfast », je désire informer les participants qui s’intéressent au rôle de Scrum Master de l’importance de la culture organisationnelle dans leur objectif personnel à mettre en place certaines parties de l’Agilité.

Une vidéo que j’aime bien pour vous donner une idée de la culture organisationnelle, ainsi qu’identifier celle de votre entreprise, est celle que Michael Sahota a fait en mai 2011. Dans cette vidéo de 10 minutes, Michael décortique les valeurs et principes Agiles pour les agencer au modèle de Schneider, modèle qui identifie 4 cultures organisationnelles.

La leçon que je retire de cette vidéo est l’importance de bien identifier la culture organisationnelle en place avant de démarrer avec l’Agilité. À mon avis, cela peut vous aider à déterminer l’ampleur des efforts dans votre promotion des valeurs Agile. D’ailleurs, peut-être même que vous réaliserez pourquoi certaines pratiques ont été faciles à mettre en place tandis que d’autres sont plus difficiles.

Par exemple, dans une culture de compétence où l’excellence technique est fortement valorisée, les pratiques d’ingénierie logicielles promues par l’Agilité seront probablement facilement acceptées par votre équipe.

Mots-Clés :

Comment identifier un Scrum Master potentiel

Publié par Louis-Philippe Carignan le lundi 3 décembre 2012 à 00:00

Lors d’un démarrage Agile où vous avez choisit Scrum comme approche, il est important de ne pas négliger le choix de votre Scrum Master.  Cette personne se verra confier des responsabilités importantes. Il faut donc identifier la personne apte à tenir ce rôle qui n’existe pas dans un projet informatique traditionnel.

À mon avis, la personne tenant le rôle du Scrum Master doit être une bonne communicatrice. Par communicatrice, je ne veux pas dire qu’elle est extravertie. Elle doit être en mesure de bien faire passer ses messages aux membres de l’équipe ainsi qu’aux parties prenantes qui gravitent autour de son équipe. Par ses messages clairs, elle établira une confiance initiale envers les parties prenantes tout en s’assurant que l’équipe de réalisation livrera les résultats à la fin de l’itération.

La créativité est aussi un point important chez la personne qui sera désignée Scrum Master. Puisque la personne sera appelée à animer des rencontres, son sens de la créativité lui sera utile pour dynamiser ces évènements. À cause de la nature itérative de Scrum, les cérémonies se répètent souvent et pour les dynamiser, un certain sens de la créativité peut aider l'équipe à sortir de la routine. Dans l'intérêt de renouveler ses techniques de facilitateur, on peut inviter le Scrum Master à suivre des formations d’animations. Par exemple, la conférence « Agile Games » est un bon endroit pour un Scrum Master qui désire s’outiller en termes de jeux.

Et pour organiser ces cérémonies, il faut que votre Scrum Master ait un sens de l'organisation. Il doit être en mesure de voir à l'avance les rencontres à planifier. Il doit se préparer pour chaque rencontre, préparer l'agenda, établir l'objectif ainsi que l'extrant obtenu à la fin de chaque rencontre. Il faut donc faire attention de ne pas retenir une personne qui est souvent désordonnée dans son travail.

Puisque le Scrum Master est un rôle de gestion sans pouvoir décisionnel, la personne doit comprendre ce qu’est le pouvoir d’influence et en faire bon usage. Le Scrum Master n’est pas imputable du résultat. Cette imputabilité revient au propriétaire de produit (Product Owner). Le Scrum Master doit donc guider l’équipe à répondre aux besoins du client sans imposer sa vision du travail à faire. Elle doit donc influencer l’équipe dans leurs décisions tout en se rappelant qu’elle est au service de l’équipe. 

Par mon expérience, je trouve que le Scrum Master est un « process manager ». C’est une personne qui doit comprendre le processus Scrum ainsi que son implication au sein de l’organisation. Par exemple, une personne qui voit et comprend tout le processus dans l’équipe, de la collecte des besoins jusqu’à sa livraison, sera avantagée si elle tient le rôle de Scrum Master puisqu’elle voit l’équipe dans son entier. Cela lui donnera la chance d’être un pas en avant de son équipe lorsque celle-ci semble vouloir apporter un changement à leurs façons de faire. En étant un pas en avant d’eux, cela lui permet de mieux guider son équipe sur les impacts que leur idée peut avoir sur le reste de l’organisation.

La personne identifiée doit aussi vivre les valeurs Scrum dont elle fera la promotion. Les trois valeurs de Scrum étant la transparence, l’inspection et l’adaptation, le Scrum Master doit démontrer qu’il vit ces valeurs. Elle doit se montrer transparente dans sa démarche puisqu’elle rappellera souvent à son équipe l’importance de la transparence. Elle doit aussi se montrer ouverte à se faire critiquer sur son approche pour montrer qu’elle n’a pas peur de s’améliorer elle-aussi. Il faut donc choisir une personne qui est en mesure de vivre ces valeurs. Il faut identifier une personne qui est capable de mettre « ses tripes sur la table » pour montrer l’exemple au lieu de dicter ce que l’équipe doit faire.

Je vous suggère aussi une personne qui est capable de s’oublier. Dans la littérature Scrum, on lit souvent le terme « servant-leadership ». Cette personne doit être en mesure de favoriser des interactions et la communication entre les membres de l'équipe. Par exemple, lorsque le Scrum Master anime des rencontres, il ne doit pas devenir le centre d'attention mais bien un catalyste entre les individus autour de la table. Il doit s'assurer que les intravertis ont autant leur mot à dire que les extravertis de l'équipe. On parlera aussi d’une personne qui est capable de générer des idées. Même si ses idées ont du sens, le Scrum Master doit favoriser l’apparition d’idées dans l’équipe. À l’aide de sa créativité mentionnée précédemment ainsi que la transparence, cette personne trouvera des moyens originaux d’exposer la situation actuelle à son équipe pour que celle-ci voit ce qui ne va pas. 

Au final, le choix de la personne qui tiendra le rôle du Scrum Master est important puisqu’elle est à la base de l'approche Scrum. Je crois que la citation de Lao Tzu, père du taoïsme, résume l’idée de l’apport d’un Scrum Master dans une équipe :

« A leader is best when people barely know he exists, when his work is done, his aim fulfilled, they will say : we did it ourselves. »

 

Archive