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.

Ma courte revue du livre "Product Development for the Lean Enterprise"

Publié par Louis-Philippe Carignan le lundi 3 septembre 2012 à 12:00

Après avoir assisté à la présentation de Michael N. Kennedy à la conférence Lean Software & Systems Conference à Boston en mai dernier, je me suis procuré les deux livres du conférencier comme lecture d’été. Certains diront que M. Kennedy a fait une belle job de vente pendant sa conférence. Je suis tout à fait d’accord. Ce conférencier m’a donné le goût d’approfondir quelque chose que Mary Poppendieck touchait à peine dans ses livres.

Après quelques jours d’attente suite à ma commande sur Amazon, les livres « Product Development for the Lean Enterprise » et « Ready, Set, Dominate » sont arrivés dans ma boîte aux lettres. Pour les curieux, ces livres ne sont pas disponibles en format électronique.

 Livre-Product-Development-for-the-Lean-Enterprise-Kennedy-Michael-N  Livre-Ready-Set-Dominate-Kennedy-Michael-N

Je m’attendais à un livre de référence sur le sujet. À ma grande surprise, le premier livre de Kennedy est écrit sous la forme d’un roman (business novel) où une entreprise voit ses revenus diminuer tandis que ses coûts de développement augmentent. Elle commence à perdre des clients à cause des prix trop élevés de ses produits. La compétition est de plus en plus féroce. Comme toute entreprise qui doit survivre, elle se doit de réagir. À l’aide d’une intrigue légère, on y introduit l’approche du développement de produit basé sur le savoir (knowledge based design) comme solution pour renouer avec les profits. J’ai apprécié ce style d'écriture puisque cela facilite et agrémente la lecture en s'identifiant aux personnages. Les mises en situation nous rappellent notre propre contexte au travail ainsi que les types de personnage que l’on retrouve dans nos réunions.

À la fin de chaque chapitre, l’auteur revient sur ce qui s’est produit pour nous clarifier certains points. Cette section « Discussion » nous permet de revisiter des concepts qu’on aurait peut-être manqués pendant notre lecture.

Je recommande fortement ce livre aux gens qui désirent approfondir les approches pour le développement de produit. Dans l’Agilité, on ne mentionne jamais la découverte et le partage de connaissances comme valeur. Ce thème est central dans ce livre puisqu'il est à la base du succès chez Toyota. Dans l'Agilité, on mise sur les individus, leurs interactions et leur collaboration. On parle de bonnes pratiques d’ingénierie. Les livres de Mary Poppendieck nous ont révélé les 7 gaspillages en développement logiciel. Mais lorsque votre projet logiciel fait partie d’une solution plus globale, je pense que l’Agilité ne vous guide pas complètement et que l’approche « knowledge based design » vous sera d’une grande utilité. Pour des gens qui sentent avoir fait "le tour de l'Agilité" et à la recherche d'un autre point de vue en développement de produit, ce livre vous sera utile. Bien que Toyota soit la référence de l'approche "knowledge based design", Kennedy en fait mention sans exagération. On cite quelques chiffres pour mettre en valeur cette approche mais sans plus. Dans l'histoire fictive, on fait référence à Toyota lorsque les personnages se posent des questions. Mais l'auteur fait attention pour ne pas simplement développer un cultre d'adoration envers Toyota. 

J’ai commencé la lecture du second livre de Kennedy. Toujours sous la forme d’un roman, il revient un an plus tard avec l’entreprise introduite dans son premier livre pour mesurer le progrès qu’elle a fait avec l’approche « knowledge based design ». Bien que le premier livre nous donnait les grandes lignes de l’approche, le deuxième livre nous raconte les difficultés rencontrées lorsqu’on l’implémente. Bien que j’aie beaucoup apprécié le premier livre où on m’a vendu les concepts, le deuxième me ramène sur terre où l’on me présente les difficultés que l’on peut rencontrer lors de sa mise en œuvre. Jusqu’à présent, je le trouve plus difficile à lire puisque je dois revenir sur les concepts de l’approche et réfléchir comment ils ont été mal mis en œuvre dans l’entreprise fictive.

 

Ma revue du mini-livre de Michael Sahota

Publié par Louis-Philippe Carignan le vendredi 10 août 2012 à 12:00

J’ai pris le temps de lire dans les derniers jours l’excellent mini-livre « An Agile Adoption and Transformation Survival Guide: Working with Organizational Culture » de Michael Sahota, coach Agile dans la région de Toronto. J’ai trouvé le contenu très intéressant à un point où j’ai voulu écrire ce billet pour partager mes impressions.

Qui voudrait lire ce mini-livre?

  • Les gens qui ont baigné dans l’Agilité et qui se demande si cela vaut la peine à long terme;
  • Les gens qui pensent à utiliser l’Agilité pour atteindre leurs objectifs d’affaires et qui cherchent une bonne (ou mauvaise) raison pour l’introduire dans l’organisation;
  • Les gens qui font de l’Agilité depuis plusieurs années et qui se cherchent une explication générale pourquoi cela fonctionne dans certains projets et dans d’autres, non;

Pour ma part, je tombe dans cette dernière catégorie. Je me cherchais un regard externe pour m’expliquer dans des connaissances que je n’avais pas pourquoi l’Agilité fonctionne (ou non) dans des organisations.

Comme point de départ dans son mini-livre, Michael prend le temps d’affirmer que l’Agilité définit une culture. Ce n’est pas un processus ou un ensemble de méthodes. En faisant ce constat, Michael utilise alors le modèle de Schneider où on définit les 4 cultures organisationnelles existantes (Control, Collaboration, Compétence et Cultivation) pour voir dans quelles cultures l'Agilité se retrouve.

Michael place l’Agilité dans les cultures de collaboration et de cultivation. Il met alors en garde les lecteurs de bien connaître leur culture organisationnelle avant d’entreprendre un pas vers l’Agilité. Tout comme un système immunitaire attaque et détruit les intrus, il se peut que l’organisation rejette l’Agilité s’il a déphasage entre les cultures.

Après avoir pris le temps d’expliquer les différentes cultures organisationnelles, Michael explique la différence entre adoption, transition et transformation Agile. Pour lui, on parle d’adoption lorsque l’organisation va adopter les pratiques Agile. Ils vont faire de l’Agilité en adoptant les pratiques qui s’insèrent dans la culture organisationnelle en place. Mais, ils ne seront pas Agile. En d’autres termes,

  • Faire de l’Agilité = Adoption
  • Être Agile = Transformation 

Michael confesse qu'il a vu peu (ou même pas) d'organisations se transformer pour être Agile. Les coûts et les risques d'une telle transformation sont énormes. Il cite l'exemple NUMMI et semble nous indiquer qu'une transformation est nécessaire quand l'organisation se dirige droit vers la faillite et qu'un virage radical est nécessaire.

Finalement, Michael termine son livre avec des suggestions pour effectuer des adoptions et transformations Agile. Il aborde des modèles existants (ADAPT, Cynefin, Kutter) sans trop aller dans les détails. Cependant, il les présente pour nous donner le goût de les approfondir. 

En somme, je recommande la lecture de ce mini-livre pour les gens qui recherchent comment l’Agilité s’insère dans la culture organisationnelle d’une entreprise. J'ai aussi apprécié la fin du livre où Michael a ajouté les commentaires de personnes qui étaient plus ou moins d'accord avec ce qu'il avançait. Un bon p'tit livre qui se lit rapidement. 

Vous trouverez ce livre sur infoq.com. On peut le télécharger gratuitement en s'enregistrant à ce site.

Bonne lecture!

Ma revue du livre "The High-Velocity Edge"

Publié par Louis-Philippe Carignan le dimanche 5 août 2012 à 20:00

Lors de la conférence Lean Software & Systems à laquelle j’ai participé en mai dernier, j’ai eu l’opportunité d’assister à la présentation de Steven J. Spear à propos des organisations fonctionnant à haute vélocité. Par haute vélocité, on entend des organisations qui se démarquent de la concurrence et qui sont devenues des leaders dans leur domaine respectif.

M. Spear a publié en 2010 le livre « The High-Velocity Edge : How Market Leaders Leverage Operational Excellence to Beat the Competition » où il y détaille sa compréhension des capacités que doit développer une entreprise pour fonctionner à haute vélocité.

Lors de la conférence, on nous a remis une copie de ce livre dans la pochette du participant. Lors de mon vol de retour, je me suis permis de lire les premières pages. Il fut alors difficile pour moi de fermer le livre. J’aimerais donc partager mon impression à propos de cette lecture que je juge pertinente pour tous ceux et celles qui désirent instaurer une culture d’amélioration continue dans leur organisation.

Le premier chapitre du livre présente les quatre capacités que doit posséder une organisation pour se démarquer dans son industrie. On les présente mais puisqu’elles ne sont pas détaillées en utilisant des exemples concrets, on reste sur notre appétit et c’est ce qui nous transporte vers le deuxième chapitre. L’auteur les présente juste assez pour susciter notre intérêt à continuer vers le prochain chapitre.

Le chapitre 2 prend le temps d’expliquer ce qu’est un système complexe. En consacrant seulement une dizaine de pages pour ce chapitre, c’est tout de même une bonne introduction à l’approche systémique avec quelques exemples pour expliquer le concept. On comprend comment bien des systèmes dans notre société sont complexes (manufacturier, médical, développement de produit, etc).

Une fois expliqué ce qu’est un système complexe, Spear présente des systèmes complexes qui ont échoué au chapitre 3. Il explique comment un système complexe qui ne se renouvèle pas est comdamné à produire de mauvais résultats. L’exemple qui m’a particulièrement plus est celui de la formation d’un nouvel employé chez GM. L’auteur explique comment il a fait plusieurs stages de travail dans des usines de GM et Toyota. Il y détaille son expérience en tant que nouvel employé sur la chaîne de montage dans une usine de GM. Bien que l’auteur reste neutre en racontant son expérience chez GM, on sent une chaîne de montage mal organisée et dysfonctionnelle. Cette expérience lui servira tout le long du livre pour la comparer à des entreprises opérant à haute vélocité. Il utilise aussi l’accident de la navette spatiale Challenger ainsi que le système médical pour expliquer comment un système complexe peut échouer. Il montre comment le système médical n’a pas évolué depuis les 50 dernières années et que cela est en bonne partie responsable de son inefficacité. Mais à mon avis, l’exemple de l’usine de GM comparé à Toyota est le plus frappant.

Les chapitres 4 à 9 sont très faciles à lire. L’auteur présente plusieurs exemples d’entreprises qui appliquent les capacités qu’il détaillera dans les chapitres 6 à 9. L’exemple à propos des réacteurs nucléaires américains au chapitre 4 est très intéressant à mon avis. Après avoir comparé le nombre d’accidents de sous-marins nucléaires russes aux accidents des sous-marins nucléaires américains, Spear prend plusieurs pages pour expliquer comment la culture organisationnelle de ce département, le Naval Reactor de la marine américaine, a largement influencé la fiabilité des réacteurs nucléaires américains. Ensuite, il détaille le cas d’Alcoa, où la prévention des accidents de travail a servi de base pour mieux connaître leur système complexe.

Les chapitres 6 à 9 présentent les 4 capacités que l’auteur identifie comme étant nécessaire pour devenir une organisation à haute vélocité. Chaque chapitre est dédié à une capacité. Celle-ci est supportée par plusieurs exemples, souvent de Toyota ou de ses fournisseurs. Ces capacités se résument ainsi :

  1. Concevoir son système et en comprendre ses opérations
  2. Résoudre les problèmes du système et l’améliorer
  3. Partager ses connaissances
  4. Développer les 3 premières capacités chez ses pairs

Le chapitre 10 est tout aussi intéressant. L’auteur reprend les 4 capacités mais dans des situations d’urgence. Par exemple, il explique comment Toyota a réagit lorsque l’usine de son unique fournisseur d’une valve importante a pris feu. Bien que la presse américaine prédisait qu’i faudrait des mois avant que la production revienne à une cadence normale, il n’a fallu que 5 jours après l’incendie pour que la production redevienne normale dans les usines Toyota. Spear souligne comment les 4 capacités étaient encore à l’œuvre, seulement dans un contexte différent. Puisque les employés étaient habitués à résoudre des problèmes dans leur travail quotidien, l’incendie de l’usine était seulement un plus gros problème à résoudre. 

Le chapitre 11 est par contre un peu décevant. Spear présente plusieurs exemples des 4 capacités dans le domaine hospitalier. Cependant, les cas présentés sont cours et mal détaillé. On sent que l’auteur voulait en parler mais qu’un livre en entier aurait pu être dédié à ce domaine.

En somme, je recommande fortement ce livre aux gens qui désirent influencer, modifier ou améliorer la culture organisationnelle de leur entreprise. Le livre offre énormément d’exemples sur lesquels vous pouvez vous baser pour entamer des discussions avec vos collègues. Il ne vous restera plus qu’à travailler pour qu’elles prennent place dans votre organisation.

Bonne lecture!

Software in 30 days

Publié par Louis-Philippe Carignan le dimanche 1 juillet 2012 à 00:00

Le dernier livre des créateurs de Scrum, Software in 30 days est écrit pour les gestionnaires occupés qui cherchent les grandes lignes de Scrum sans aller dans les détails. La police est nettement supérieur aux livres Agile de référence. Les chapitres sont meublés de diagramme pour simplifier la compréhension. Écrit en 120 pages, ce livre est parfait pour ceux et celles qui désirent convaincre leurs gestionnaires des avantages que l'Agilité peut apporter à leur organisation.

Software in 30 days

Le Guide Scrum disponible en version française

Publié par David Beaumier le mardi 29 mai 2012 à 14:03

Note: Billet mis à jour en novembre 2014 pour tenir compte du déplacement des guides vers le site scrumguides.org

La nouvelle est un peu passée sous silence, mais depuis quelques semaines une version mise à jour du Guide Scrum français est disponible sur le site de Scrum.org. Cette version est une traduction du Guide officiel publié en 2011 qui consistait en une mise à jour relativement importante de certains aspects du cadre de travail Scrum. Les raisons qui ont motivés ces changements sont expliqués dans la lettre officielle de Jeff Sutherland et Ken Schwaber.

L'équipe de bénévoles qui a procédé à l'adaptation francophone a pris grand soins de proposer une terminologie respectant la langue française tout en demeurant compréhensible par l'enssemble des intervenants. Je vous avoue que c'est tout un défi, surtout lorsque l'équipe se compose de plus de 15 personnes!

Bravo à tout ceux qui ont pris part de près ou de loin à cet exercice et merci de vos efforts! Le résultat est de très grande qualité et je n'ai aucun doute que le document sera très utile à toute la communauté Scrum francophone de par le monde.

Guide Scrum Francais v2011

L'équipe de Scrum.org a publié un billet qui explique les principaux changements contenus dans la version 2011 du Guide. Bien que celui-ci n'ait pas (encore) été traduit, je vous suggère d'en faire la lecture pour bien saisir les motivations des pères de Scrum concernant les principaux changements. Globalement, on y discute des éléments suivants:

Le billet discutant d'Engagement vs prévision est également une lecture complémentaire fort intéressante.

Archive