Note de lecture : User Story Mapping, par Jeff Patton

Note : 9 ; Bien au-delà du story mapping, vers la découverte de la vraie nature des spécifications agiles en tant que compréhension partagée. Book of the year 2015 !

Jeff Patton est un vrai maître Jeidi de l’agilité : après avoir lu, ou plutôt dévoré son livre, je n’en ai plus aucun doute ! Mais si vous pensez lire « simplement » un ouvrage décrivant par le menu la technique développée par Jeff Patton, vous allez être surpris ! Car c’est bien plus que cela.

Le livre fait un peu plus de 260 pages en 18 chapitres. Je dis « un peu plus de 260 pages » car le corps principal du livre est précédé d’une introduction « read this first » qu’il ne faut rater sous aucun prétexte. On y parle « instructions » versus compréhension partagée, de comparer les (docs de) spécification à des cahiers de voyage, de l’importance de raconter des histoire et d’être frugal dans la construction tout en cherchant à maximiser l’impact plutôt que les fonctionnalités ! Bref, cette introduction à elle seule a la valeur d’un très bon livre. Et ce n’est pas fini !

Raconter des histoires, c’est le sujet du 1er chapitre où l’auteur introduit les story maps dans le but de raconter la grande histoire du système, d’avoir une « big picture ». Il le fait d’ailleurs en racontant une histoire, celle de Gary par qui les user stories sont arrivées ! D’ailleurs la totalité du livre est formée d’histoires. Et celles-ci sont illustrées de photographies des fresques (en couleur dans la version anglaise) que sont ces stories maps auxquelles l’auteur surimpose des explications sous forme de cartographie.

Lire la suite

Note de lecture : Agile and iterative development a manager’s guide, par Craig Larman

Note : 9 ; Eclairé et agréable à lire. Comme toujours, avec Larman…

Nous commençons à avoir l’habitude de la qualité des textes de Craig Larman. Celui-ci ne fait pas exception et est également témoin du virage de l’auteur vers les pratiques agiles. Dans cet ouvrage, Larman se focalise sur l’aspect gestion de projet, mettant l’emphase sur le cycle itératif et ses bénéfices, notamment par rapport au cycle en V. Il s’agit donc bien d’un ouvrage pour convaincre et faire prendre conscience du changement de paradigme qu’amène l’agilité. Le texte date de 8 ans, mais je pense qu’il reste tout à fait d’actualité, d’une part car il reste beaucoup de monde à convaincre, et d’autre part car il est à peu près seul sur son créneau, la plupart des livres dédiés à l’agilité se focalisent sur le « comment » plus que le « pourquoi ». Il serait plutôt à comparer à « Agile Software Development Ecosystem » de Jim Highsmith.

Cela dit, ce volume n’est pas un guide touristique. Ses 330 pages découpées en 12 chapitre en attestent. Je passe rapidement sur le premier chapitre qui ne compte que 6 pages : il fournit quelques généralités sur la logique de projet prédictifs à opposer avec le développement de nouveaux produits. Il fournit aussi nombre de liens dont beaucoup sont toujours actifs ! Le second chapitre traite sur une quinzaine de pages la logique des projets évolutifs et itératifs. C’est très abondamment illustré, extrêmement clair et chirurgical, dirais-je. Un plaisir !

Lire la suite

Note de lecture : Agile Metrics in Action, par Christopher W. H. Davis

Note : 3 ; L’agilité à mi-chemin.

Ce livre est une déception, je n’ai hélas pas d’hésitation à cet égard. Il est vrai que l’on manque souvent sur les projet agile à mesurer des choses alors que la collecte de faits tangibles est la base d’une démarche Lean ! L’origine de cet ouvrage est un système de collecte de mesures pensé et développé par l’auteur et déployé sur les équipes dont il était le manager. Ce système collecte des données depuis Jira, Github, Jenkins, la plateforme de déploiement et Google Analytics, pour ensuite consolider cela. Une idée tout à fait brillante. Malheureusement, comme nous allons le voir, le livre ne parvient pas à valoriser cela.

La structure de l’ouvrage suit en grande partie les 5 grandes « travées » que l’auteur voit dans le développement agile. Il est organisé en 10 chapitres format 3 parties, le tout totalisant 220 pages. A cela il faut ajouter les 2 annexes qui ajoutent près de 20 pages : celles-ci apportent quelques éclaircissements sur la chaine de collecte conçue par l’auteur. La première de ces parties ne compte qu’une trentaine de pages sur deux chapitres. Le premier d’entre-eux « Measuring Agile Performance » dresse sur près de 20 pages un tableau du problème que l’on s’efforce de résoudre. Je ne suis que partiellement d’accord avec l’auteur, par exemple quand il prétend que l’on a pas une vue claire de nombreux concepts comme celui de « bonne qualité » ou qu’il pointe du doigt le focus sur le produit plutôt que sur le projet comme un problème !

Le second chapitre « observing a live project » nous donne un éclairage sur le fonctionnement du projet s’appuyant sur les collectes de métriques. On y voit que les mesures de productivité ont une part prépondérante (vélocité, nombre de lignes modifiées). On voit aussi que la peinture agile du projet présente de nombreuses craquelures : l’utilisation des mesures ressemble à du contrôle en bonne partie, destiné à un « leadership team », joli contresens pour appeler ce qui n’est autre qu’une équipe pilotage (a.k.a. « papa-maman »). Une autre observation, qui sera récurrente, est que la plupart des diagrammes sont difficiles à interpréter. La plupart du temps, je ne suis pas parvenu à comprendre comment l’auteur parvenait à ses conclusions…

Lire la suite

Rendez-vous à l’Agile Vendée !

C’est toujours un grand plaisir d’assister à la naissance d’un mouvement local de notre communauté agile. En ce mois de Juin, c’est la vendée qui va poser la première pierre de sa communauté.

J’y serais, avec un plaisir d’autant plus grand que l’équipe organisatrice compte des personnes que j’apprécie vraiment beaucoup !

Pour vous inscrire ou vous régaler du programme, c’est ici !

Rendez-vous à l’Agile Vendée !

Taylorisme et travailleurs du savoir

Durant les formations, je me retrouve souvent en situation de devoir expliquer pourquoi (et en quoi) l’agilité est différente des processus classiques, mais pas seulement. Bien sûr on pense au bon vieux « cycle en V », la tarte à la crème des processus non-agiles, mais nous pouvons aussi évoquer les processus itératifs tels qu’Unified Process !

Unified Process est un cas intéressant, voir embarrassant. Certains le classent dans la limite basse des méthodes agiles [4] (après tout, on est loin du cycle en V), d’autres considèrent qu’il ne s’agit définitivement pas d’une approche agile. C’est mon cas. Je trouve par ailleurs intéressant de voir que Ken Schwaber lors de sa première présentation de Scrum en 1995 classait déjà ces approches (pourtant plutôt novatrices à l’époque) en dehors de ce que l’on appelait pas encore les « approches agiles » [1] !

Pour débuter notre reflexion, je vous propose de nous intéresser au modèle Cynefin.

Le modèle Cynefin

Le modèle Cynefin permet de classifier la complexité des contextes en fonction de la nature des relations de causalité entre problème et solution. Je simplifie un peu, pourtant cela doit sembler obscure. Ne vous en faites pas, cela deviendra plus clair lorsque nous expliquerons le modèle. Le voici.

image

Le modèle Cynefin [2] est une illustration de la théorie de la complexité. Ce n’est pas le seul modèle développé à cet égard. L’usage premier de ce modèle est de montrer le dynamiques de transition entre les différentes zones. Pourtant, ce n’est pas ce à quoi il va nous servir aujourd’hui. Nous allons l’utiliser pour catégoriser nos contextes projet !

Le domaine simple (évident)

La relation de causalité est directe, évidente. Dès lors la solution s’impose d’elle-même. C’est pourquoi nous sommes dans le domaine des « best practices » : on peut déterminer la meilleure solution à un problème donné. La déclinaison la plus connue de cette approche de « bonnes pratiques » est le management scientifique du travail, qui se traduit par la décomposition d’un travail en tâches élémentaires optimisées. Nous reviendrons bientôt sur ce sujet.

Le domaine compliqué

Toujours sur la base de la relation de causalité, on estime ici que cette relation de causalité nécessite une analyse ou une expertise pour pouvoir être établie à priori. C’est le domaine des « bonnes pratiques ». La solution au problème n’est donc pas nécessairement unique ! On s’offre un éventail d’options restreintes pour traiter notre problème. Cette déclinaison correspond assez bien à Unified Process qui supporte une forme de customisation [5] par rapport au contexte, permettant cette notion d’options.

Le domaine complexe

Il est en rupture avec les deux précédents, car ici, le lien de causalité ne peut être établi à priori, mais seulement observé à postériori. Nous sommes donc dans le domaine de l’approche empirique et des phénomènes emergents utilisant une boucle de feedback.

Nous sommes dans le « sweet spot » de l’agilité : les territoires inconnus se prêtant à une approche exploratoire.

Le domaine chaotique

Ici, il n’y a aucune corrélation entre cause et effets. Ce domaine induit de purs comportement de réponse aux situations. Nous sommes dans des environnements type « guérilla urbaine » qui ne sont plus le domaine de prédilection de l’agilité.

Le cadre du management scientifique du travail

Le « management scientifique du travail », vous en avez tous entendu parler. Mais peut-être pas sous ce nom. Peut-être êtes-vous plus familier avec le terme « Taylorisme » ?

Dans les grands traits, le management scientifique du travail [3] divise les responsabilités entre deux groupes :

  • Les managers dont le rôle est d’analyser et de dicter la façon de faire le travail
  • Les ouvriers qui doivent suivre à la lettre les instructions (selon le propos de Taylor « ils sont trop stupides pour savoir comment bien travailler » !)

Replacé dans le contexte de la fin du XIXème siècle, à une époque où le travail des ouvriers avait une nature hautement mécanique, cela a du sens. Je vous choque ? Pourtant le Taylorisme fut une avancée majeure pour permettre la production de masse (qui n’existait pas avant) et a permis la révolution industrielle. Aujourd’hui même, les biens de consommation que nous ne saurions nous passer sont presque là grâce au Taylorisme !

image

Quelle place le Taylorisme occupe-t-il dans le modèle Cynefin ? De mon point de vue, il s’agit indubitablement du quadrant « simple » (évident). On est réellement dans le domaine des « best practices, d’ailleurs Taylor parle bien de selection du « best movement » (p. 57) !

Toutefois, et cela a été ignoré par les successeurs de Frederick Taylor, il y a bel et bien des postulats au Management Scientifique du travail

Les postulats du Taylorisme

Ma lecture du texte de Taylor m’amène à penser que les postulats de base sont au nombre de 3. Allons-y !

Le travailleur est trop stupide pour savoir organiser son travail lui-même !

Vous êtes surpris (ou de nouveau choqués) ? En fait, je ne fais que répéter les propos même de Frédérick Taylor ! En fait il répète même cela à plusieurs reprises dans son livre. Il faut dire que l’humain n’était pas forcément le soucis principal de cet ingénieur.

Si le respect des personnes ne semble pas tellement présent, le texte ne laisse pas non plus penser que les travailleurs en question sont des genies…

Le besoin du travailleur se situe au niveau de la sécurité

Certes, on n’avait pas encore la pyramide de Maslow à l’époque, mais un point méconnu est pourtant tout à fait explicite dans le texte de Frederick Taylor : le partage des gains opérés entre le détenteur du capital, le travailleur et le consommateur !

Il faut se replacer dans le contexte de l’époque. Les travailleurs manuels luttent pour nourir leur famille, se loger et s’habiller. L’accomplissement de soi n’est pas leur problème du moment. Ils e situent bien au second niveau de la pyramide de Maslow

image

Ce que propose Taylor est une augmentation très importante de leur revenu [3], p. 46 allant de 80% à 100% avec une réduction significative de leur temps de travail (de 10,5 heures à 8,5 heures). Ce qui, chemin faisant, fait du travailleur un consommateur !

Curieusement, cette contrepartie a progressivement disparue chez les successeur de Taylor !

Le domaine adressé est celui du travail répétitif

Ce postulat n’est pas explicite. Mais il est implicitement présent tout au long du livre. Car l’auteur parle bien de « mechanical shops ». Il n’est fait mention nul part d’expérimentation portant sur du travail non répétitif ou du fait qu’un travail de reflexion puisse être assimilé à un travail répétitif. On trouve cependant une référence au travail de chirurgien, dont il est dit à juste titre que les opérations simples peuvent tomber dans le cadre du « management scientifique du travail ». Un raisonnement que l’on peut accorder à l’auteur … en gardant à l’esprit que l’on parle de chirurgiens du 19ème siècle !

La nature intrinsèque des méthodes classiques

Que l’on parle de cycle en « V » ou d’Unified Process, ces processus sont toujours abordés de la même façon : sous l’angle de ce qui est produit, par qui, comment … En fait tous ces processus peuvent être décrits par le biais d’un métamodèle ! C’est déjà ce que Ken Schwaber mettait en lumière en 1995 [1] !

Voici justement, à peine simplifié, celui d’Unified Process.

image

Même avec un processus accordant certains degrés de liberté, la logique reste bien là : on définit qui produit quoi, comment est-ce produit et dans quel contexte. Intrinsèquement, nous faisons la même chose que Taylor, il y a 130 ans, mais sans respecter aucun de ses postulats. Aucun !

Les approches agiles : une nature disruptive

Ce qui distingue les approches agiles (j’évite le terme « processus » à dessein) des autres, c’est justement de ne pas être construites sur un métamodèle, mais sur ce que nous appelons souvent la pyramide agile. Vous la connaissez très certainement, pardonnez-moi de la refaire figurer ici (et de l’expliquer).

image

Les valeurs : Ils figurent dans le manifeste agile et nous montrent la direction. C’est ce que j’appelle la « boussole agile ».

Les principes : Mise en musique du manifeste, les principes donnent des axes concrets sur les règles à suivre.

Les pratique : Boite à outil infinie (ou presque) à utiliser tel quel pour réaliser les logiciels, les pratiques nous donnent des aides, des façons de faire.

Point de métamodèle ici : on ne peut être émergent et prescriptif. On peut seulement fournir un cadre pour nous aider à aller dans la bonne direction !

Et alors ?

Retour au modèle Cynefin. Le Taylorisme n’est pas mauvais en soi. Il ne l’était surtout pas à l’époque. Mais justement le contexte doit être pris en compte : aucun des 3 postulats, ni le domaine d’application ne sont adaptés au développement du logiciel. Cela devrait nous laisser froid s’il n’existait pas une incarnation directe de celui-ci dans le monde informatique : c’est le micromanagement !

Las, les méthodes classiques s’éloignent quand même au moins un peu du micromanagement. Néanmoins, l’observation sous l’angle du métamodèle nous montre que le paradigme est le même !

Une approche moderne du développement logiciel doit satisfaire :

  • Les besoins des personnes, qui se situent aux niveaux 3 à 5 de la pyramide aujourd’hui.
  • La nature émergente, non prédictive du travailleur du savoir qui a d’avantage besoin d’une boussole que d’un marionnettiste !

Et vous, vous ai-je convaincu ?

Ressources

[1] : The Scrum Development Process – Ken Schwaber – OOPSLA 1995

[2] : The Cynefin model : http://en.wikipedia.org/wiki/Cynefin

[3] : The Principles of Scientific Management – Frederick Winslow Taylor

[4] : Agile and iterative development, a manager’s guide – Craig Larman

[5] : The Rational Unified Process, an introduction, third edition – Philippe Kruchten

Open-Space des pratiques Agiles

Deux mois se sont écoulés depuis notre rendez-vous précédent chez Zenika. Nous voici de retour pour échanger sur les pratiques. Au menu : petit groupe, provisions de bouche en mode collaboratif, et des sujets qui restent à choisir !

SAFe, est plus que LESS ?

Premier sujet autour de SAFe, décidément, l’un des grands sujets du moment. Peut-être du fait de son adoption récente par JC Decaux ?

En dépit des retours très positifs de Lissa Adkins, je reste très dubitatif sur ce framework. Ce retour de formation SAFe correspond plus à l’idée que je m’en fais. Disons que je suis très dubitatif, mais j’entend aussi des choses positives de la part de gens que je respecte…

Yannick lui, voit un indiscutable avantage à SAFe : la possibilité qu’il ouvre de parler aux DSI ! Je suis hélas d’accord avec lui, mais pour une toute autre raison : C’est une sorte de perversion de l’agilité pour la transformer en un processus classique tel que l’apprécie nos vieilles DSI poussiéreuses (vous avez dit RUP ?). Pas étonnant qu’il gagne de l’attention.

image

Plus intéressant à mon gré, Vincent nous propose de déconstruire les pratiques de SAFe pour démontrer qu’elles sont effectivement utiles pour appliquer l’agilité à plus grande échelle. La démonstration est convaincante. Je pose toutefois la question : si les pratiques sont individuellement intéressantes et utiles, est-il besoin de les cimenter en un framework ?

Maintenant, on n’a finalement pas parlé du tout de LESS. Petite déception. Mais c’est sans doute parce que l’on ne savait pas en parler…

Hacker un projet pour l’agilifier

Le sujet sur le « hacking de projet agile » nous avait un peu intrigué par son intitulé. Un retour intéressant sur la manière de remettre un projet sur les rails avec des parties prenantes pas évidentes.

image

Mais il faut bien reconnaitre que nous n’avons pas été très inspiré pour échanger dessus. De quoi nous laisser le temps d’aborder le sujet proposé par Géraldine.

Est-il important d’avoir un objectif de Sprint ?

Oui, parfois c’est compliqué de faire rentrer le menu du sprint sous le chapeau d’un objectif ! Aussi est-il légitilme de se se poser la question : est-ce obligatoire ? Qu’est-ce qui se passe si on ne le fait pas ?

Certes, nous avons conclu qu’il est bien plus difficile pour le PO d’être capable d’exprimer cet objectif. Et parfois, ce n’est pas un, mais deux ou trois objectifs !

image

Mais nous avons aussi conclu que cet objectif de sprint apportait deux éléments très liés et complémentaires :

  • Donner un sens à ce que l’on va accomplir dans le sprint. Pas seulement une liste de trucs à faire qui transforme l’équipe en ouvriers spécialisés, mais un vrai but !
  • Permettre de co-construire la façon d’atteindre ce but, entre l’équipe et le PO. Nous parlons d’une dynamique et d’une relation différente. L’équipe n’est plus seulement le volet « réalisation », il s’implique et contribue au côté du PO sur le volet fonctionnel.

Cet objectif de sprint, finalement, n’est-ce pas un moyen d’obtenir les bonnes interactions entre les acteurs qui est la signature de l’agile ? « co-construction » restera le terme important de cette discussion.


Ma galerie de photo du Printemps Agile 2014

Je vous avais asséné il y a quelques temps deux posts (ici et ici) sur le Printemps Agile qui s’est déroulé à Caen le 20 Mars. Voici la galerie de toute les photos que j’ai prises durant cette journée. Ce n’est hélas pas la couverture photos dont je suis le plus satisfait, loin s’en faut.

Présentation Marshmallow Challenge (2/2)

Les équipes Marshmallow challenge (1/7)

Les équipes Marshmallow challenge (3/7)

Mon équipe !

printemps agile 2014, un album sur Flickr.

Note de lecture : Deal with It, par Gavin Davies

Note 6 ; L’attitude avant l’aptitude et l’hygiène de vie du développeur

Ce livre est plutôt un « mini livre » car il ne totalise que 60 pages ! Cet essai se lit donc rapidement, il m’a pris moins de 2 heures. Car non seulement le nombre de pages est compté mais il n’est constitué que d’articles (qui ressemblent plutôt à des blog post qui tiennent tous sur une page, titre compris ! Et encore, on parle là d’une page pas bien grande.

C’est aussi la qualité de cet opuscule car il s’agit là en fait d’une contrainte de taille que s’est donné l’auteur lui-même. Chaque sujet devant alors être exposé avec le maximum d’efficacité. Une sorte de « lean » de l’écriture, si on veut bien.
Intéressons-nous maintenant au contenu. Ce mini-livre est découpé en 5 parties.

La première partie « overall attitude » regroupe 11 essais. L’auteur développe ici les question d’état d’esprit : être courageux, ne pas avoir honte de son ignorance, être curieux et savoir chercher, etc…

La seconde partie « tools, learning et techniques » concerne plus un savoir « tactique pour faire face aux différentes situations. On y parle tests, déploiement et … lire des livres ! Par exemple… Ce sont 13 essais qui forment cette partie

La troisième partie « wisdom for the Long Haul » comporte 7 essais. Il évoque les questions de relations entre personnes et d’hygiène de vie. En fait : comment tenir la distance !

La quatrième partie « communication is key » comporte juste 7 essais. Zut, justement un des essais nous apprend à ne pas utiliser le mot « juste » ! On y évoque la documentation, les emails et les relations entre les managers, mais finalement peu de choses sur les relations entre collègues. Donc c’est un peu décevant.

La cinquième partie « closing advices » ne compte que 5 essais. C’est un peu dans le style « allez en paix ».

L’auteur m’avait prévenu : je ne serais pas d’accord avec tout et ce serait même curieux que je le sois. Cela a bien été le cas, mais j’avoue être en accord avec une grande partie de ses positions. Ce livre s’adresse sans ambiguïté aux développeurs. Et pourtant, l’auteur focalise son propos sur les « savoir être » plutôt que sur les « savoir faire » ! A ce titre, il me rappelle un peu le « pragmatic programmeur » d’Andrew Hunt et Dave Thomas. Rappel justifié, car l’auteur y fait référence vers la fin de son texte.

Au final, il ne s’agit pas d’une lecture indispensable. Elle est juste intéressante : la concision de l’expression de l’auteur et la rapidité avec laquelle on avale le texte sont des plus. Je la classerais en lecture d’agrément en sus de textes plus solides tels que le Pragmatic Programmer suscité, ou encore les Clean Code / Clean Coder de Robert Martin et quelques autres.

image

Référence complète : Deal with It, attitude for coders – Gavin Davies – Leanpub 2012

Deal With It Attitude for Coders

https://www.goodreads.com/book/add_to_books_widget_frame/16190992?atmb_widget%5Bbutton%5D=atmb_widget_1.png