La gallerie de mes photos de l’Agile Tour Bruxelles 2013
Agile Tours Bruxelles 2013, un album sur Flickr.
Mois : décembre 2013
My “Business Craftsmanship” keynote given at Agile Spain 2013, Bilbao. The slides are not visible in this video so I recommend just listening to the soundtrack and following along with the slides available here.
(Source: https://www.youtube.com/)
Markets that don’t exist don’t care how smart you are.
Marc Andreesen
User Stories … What else ?
Voici le support de ma présentation, faite lors d’Agile Grenoble 2013. Elle aborde le sujet épineux de l’emprunt de techniques issues du monde non-agile dans nos projets agiles !
Le teaser
Les users stories sont rapidement devenus la formulation convenue du besoin. Mais est-ce la seule ? Est-ce toujours la meilleure ? On dit que quand on a un marteau, tout ressemble à un clou. Notre communauté agile tend à ignorer ce qui vient d’ailleurs. Pourtant ce qu’on appelle l’ingénierie des exigences est un domaine riche de plusieurs décennies de connaissances et de techniques. Certaines peuvent être utilisées directement, d’autres doivent être adaptées ou peuvent servir d’inspiration.
Cette présentation va nous permettre d’étudier ensemble plusieurs techniques et concepts du recueil des besoins et les regarder par le prisme de nos pratiques agiles. A l’aide d’exemples, nous verrons comment elles peuvent renforcer nos pratiques actuelles.
Ce que vous allez en retirer
Découvrir l’ingénierie des exigences, prendre conscience de la profondeur de ce domaine de connaissance. A la fin de cette session les participants auront des clés pour enrichir leur maitrise de la capture du besoin en s’alimentant hors du champs de l’agilité, et j’espère le goût de le faire !
Si j’ai assez de courage, je produirais cette présentation sous forme d’article. Mais alors pas avant Janvier !
Note de lecture : Don’t Just Roll the Dices 2nd edition, par Neil Davidson & Jamie Rumbelow
Note : 8 ; Condensé, clair, bien écrit, pertinent et qui plus est, gratuit ! Ne ratez pas cette lecture !
Quel est le bon prix pour votre produit ? Est-ce simplement son coût agrémenté d’une marge ? Dans ce livre (qui est plutôt un livret), Neil Davidson nous propose une réflexion approfondie sur la question, en partie étayée par des exemples du marché, mais aussi en bonne partie étayée par sa propre expérience à Red Gate Software. Ce texte ne livre pas de solution magique, mais il donne d’excellentes voies à explorer et donne des clés pour les utiliser. D’une certaine manière, il reflète en condensé le « business model generation » qu’il ne cite pourtant pas dans les sources.
Court, ce texte l’est avec moins de 70 pages. En fait, il donne même l’impression d’avoir été raccourcis dans sa seconde édition, car il était long d’environ 80 pages lorsqu’il était publié chez Simple Talk Publishing. Mais je pense (sans l’avoir vérifié) que le format du nouvel éditeur donne simplement un total de pages moins élevé pour la même somme de contenu. Le livre compte 6 chapitres, ils sont assez courts, le plus velu totalisant à lui seul un peu plus de 20 pages.
Le premier chapitre « economics » est une mise en bouche où l’auteur nous expose la théorie du prix de vente, c’est à dire l’équation prix / volume qui nous amène à un point d’optimal hélas pratiquement impossible à deviner. C’est plein de graphiques, facile et agréable à lire.
Le second chapitre « pricing psychology » s’attaque à la perception du produit et l’auteur propose plusieurs axes pour adresser cette perception. De nouveau on retrouve trace du « business model generation », mais c’est dit de manière simple, sans modèle et permet d’appréhender le concept et ses variantes efficacement en quelques pages.
Le chapitre trois « pricing pitfalls » nous parle des différents écueils à adresser : la concurrence, le « switch », la corrélation du prix et du coût, etc… C’est peut-être le chapitre le plus faible, mais croyez-moi, ce n’est pas une raison pour le sauter !
Le chapitre 4 « advanced pricing » est le fameux chapitre costaud. Celui-ci présente les différents axes stratégiques permettant des déclinaisons de prix : versions, déclinaisons, zones géographiques ou groupes démographiques, bundles, stratégies de licence, abonnements, etc… L’auteur étaye chaque cas de figure d’informations et de points d’attentions et donne souvent des exemples de réussites mais aussi d’échecs en les étayant. Le condensé d’information donné dans ces 20 pages laisse tout bonnement dubitatif !
Le chapitre 5 « pricing perception » discute du « message » qu’envoie le prix ou la stratégie de prix que vous prévoyez et la nécessité d’aligner le marketing et le service à ce message. Et une dernière chose : l’auteur est clair sur l’inutilité des études de marché sur ce point. Par contre, on peut faire des expérimentations. A ce point, le texte se teinte un peu de « Lean Startup ».
On a déjà beaucoup de matériel utile, mais le petit chapitre 6 est une cerise sur le gâteau : une checklist pour aider notre réflexion sur le prix ! Evidemment, il reprends de manière extrêmement synthétique les points déjà vus. Juste 2 pages pour ça, bon boulot !
Vous l’aurez compris à mon enthousiasme : je recommande fortement cette lecture qui ne mobilisera guère que 2 ou 3 heures de votre attention. Savoir ce livre gratuit est un plus mais il justifie sans problème un prix, même en eBook. J’ai eu l’impression de lire sinon un condensé du « business model generation », une vue de celui-ci filtrée sur le thème du prix et complétée de matériel original. A ne pas rater, donc !
Référence complète : Don’t Just Roll the Dices, 2nd edition – Neil Davidson & Jamie Rumbelow – Efendi Books 2012 – ISBN : 978-0-9571791-2-7
Twenty years from now you will be more disappointed by the things that you didn’t do than by the ones you did so. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover.
Mark Twain (via niptech)
ScrumBeer de Décembre : avec passion !
C’est toujours un grand plaisir de nous retrouver autour d’une boisson houblonnée lors de ces rencontres organisées par Arnaud ! Les évènements du SUG sont certes de belle tenue, mais très espacés dans l’année et les ScrumBeer constitent pour moi le vrai fil rouge de ce user group !
C’est maintenant une habitude : pas d’agenda, mais des discussions animées et passionnées ! Plusieurs sujets ont donné lieu à débat avec les quelques personnes qui m’entouraient.
Plaisir et professionnalisme
La notion d’envie et de plaisir versus le professionnalisme. Ces notions sont-elles incompatibles ? L’une doit-elle prendre le pas sur l’autre ? De là à parler du modèle Tayloriste, il n’y a qu’un pas ! Ayant lu le “Principles of Scientific Management” il n’y a pas si longtemps (oui, oui, la note de lecture viendra…), il nous fallait recadrer l’inadéquation du modèle par rapport à son usage initial : les postulats de base et le contexte historique.
L’engagement
Voilà une notion qui me met mal à l’aise, à défaut de la rejeter !
Oui à l’engagement consistant à se “considérer à bord” et contribuer à ce qui est nécessaire de faire pour faire avancer le projet sans se planquer derrière un processus.
Non à “l’engagement guet-apens” dans lequel les membres de l’équipe doivent absorber les incertitudes et les inconnus du projet car ils se sont engagés sur une date (avaient-ils le choix de ne pas le faire ?). Cette forme d’auto-mutilation moderne est sensée être cool car auto-consentie, mais n’a pour moi rien d’agile…
Bien sûr, j’expose ici mon point de vue avec beaucoup de subjectivité. L’important est que ayons pu échanger dessus … avec passion !
Carnet de route : Agile Grenoble 2013 en Images (2/2)
Je vous avais laissé à la fin de la pause déjeuner lors de mon précédent post. Nous allons débuter cette seconde moitié d’Agile Grenoble de nouveau dans le grand amphi.
Retour dans le grand amphi
J’ai oublié de vous parler de Jérôme Bourgeon. Il est … magicien ! Il introduira ce début d’après-midi et j’aurais aussi l’occasion de reparler de lui plus tard.
Puisque l’on en est aux animateurs de cette journée, nous ne pouvons pas passer sous silence les organisateurs de cet Agile Grenoble, qui est quand même la plus grande manifestation agile en France ! Ils sont nombreux et nous avaient préparé une petite animation à base de fausses pizzas …
La keynote qui suit sera, elle, confiée à Pascal Van Cauwenberghe.
Pascal Van Cauwenberghe : Comment écrire du code legacy plus rapidement
Comme souvent, Pascal nous présente ce qui sera ma session préférée de cet Agile Grenoble. Ca fait aussi parfois un peu mal, car l’orateur ne fait pas trop de concessions.
Outre le sens toujours aiguë de l’auto-dérision de l’agiliste Belge, on voit aussi de nouveau apparaitre nos Scribers prêts à l’action, chacun indépendamment d’un côté de la scène !
Il est surprenant de voir à quel point les résultats obtenus sont différents. Ils me laissent néanmoins toujours admiratifs
Revenons à la session de Pascal.
En bref, cette session est de “techniques” pour dégrader le code plus rapidement ! Le tout découpé en 4 catégories.
Pour le développeur : travaillez votre talent sur la dette technique !
Soyons clairs : ce que l’on nomme avec pudeur “dette technique” n’est ni plus ni moins que du code pourri ! Quelques techniques (sournoises) pour progresser (ou régresser, selon votre point de vue) en ce sens :
- IDD ou “if driven développement” : J’ai un nouveau cas à prendre en compte ? Hop ! Un nouveau if, un nouveau cas spécifique … plutôt que de généraliser !
- Des commentaires pour leurrer : Il suffit d’écrire une intention en commentaire et ne pas la respecter lors de l’écriture du code. Mais le plus souvent le commentaire devient simplement obsolète en n’étant pas mis à jour lors du “bug fixe”.
- Du refactoring qui rend le code plus mauvais ! Là aussi à l’occasion de multiples bug fixes…
- Désactiver les tests qui échouent (on les corrigera au prochain sprint). Evidemment, ce n’est jamais corrigé car il y a toujours mieux à faire…
- Les tests sont une perte de temps : il y a du code à développer … mais comment sait-on qu’il marche ?
- Le framework du jour. Ou comment faire sombrer un projet sous le poids des bibliothèques que l’on a envie d’essayer…
- La collaboration c’est pour les nuls ! Et chacun bosse dans son coin en développant ses trucs de sioux qui nous font paraitre tellement plus intelligents…
Des techniques pour les testeurs
- La loi de Pascal : La qualité du code est inversement proportionnelle à la taille de l’équipe de test ! Quand on est blindé par une équipe de test, pourquoi produire du code de qualité ? La solution ? Retirer l’équipe de test !
- Ajouter la qualité en testant ! Bien entendu, les tests ne font jamais progresser la qualité.
- Semer la confusion sur “la qualité”. Chacun peut interpréter “qualité” comme il l’entend. Mais quelle type de “qualité” attend-t-on en fait ?
Des techniques aussi pour le PO et les managers !
- Je veux tout ! Le meilleur moyen d’avoir du travail bâclé en abdiquant ses responsabilités.
- C’est pas ça ! … ou le syndrome du PO distant. Un rôle bien confortable, où l’on se désengage du produit en rejetant la faute sur ceux “qui ne comprennent pas”.
- C’est trop cher ! Essayer de faire “une bonne affaire” en rentrant dans une logique de négociation … ça se paie toujours à un moment ou à un autre !
Des techniques pour les managers, coaches, etc.
- Protéger l’équipe. Malgré ce que dit Scrum, ce n’est pas une si bonne idée. L’équipe doit être au diapason des problèmes, des mécontentements, etc.
- Isoler l’équipe. C’est le syndrome extrême. Les développeurs travaillent sans appréhender les utilisateurs.
- Optimiser le développement de bugs avec une équipe de maintenance. Ou comme le dit Pascal : une équipe pour écrire les bugs, l’autre pour les corriger !
- Obtenir l’engagement. Très bien pour mettre l’équipe au pied du mur et obtenir l’un des 3 résultats suivants :
- Hacking de fin de sprint.
- Presque done. Un travers dont j’avais déjà parlé.
- Mentir sur sa vélocité pour garder un matelas de secours.
Ne pas suivre ses propres règles. Rétrospectives sans résultat. Pas la peine de faire croire que l’on va s’améliorer si l’on ne fait rien. Réécriture complète. Le genre de projet qui n’aboutit jamais … et peut même faire couler une boite !
L’énoncé des symptômes fait plutôt mal, surtout si l’on considère que j’ai bien eu au moins l’un d’entre-eux sur la plupart de mes projets ! Mais cela fait réflechir aussi pour m’aider à être plus exigeant. Merci Pascal !
Et pendant ce temps, chez Zenika …
Je l’avais évoqué, Zenika était sponsor de l’évènement. Nous avions donc un stand pour nous représenter.
Avec la présence active d’Hervé Jacob, notre directeur d’agence sur Lyon.
Et Christophe Campan en complément de la fine équipe.
Etre sponsor d’un évènement, est une expérience nouvelle pour moi. C’est juste la seconde fois après Rennes. Nous pouvons nous améliorer à cet égard (car on peut de toute façon toujours s’améliorer). Nous aimerions essayer de courtes animations agiles autour de notre stand. A réflechir et essayer pour les prochaines fois.
Service IT Agile, agilité managériale, agilité entrepreneuriale ? Par Michel Cezon
J’aurais voulu m’essayer au Visual Thinking, mais hélas la session a débuté avant l’heure avec une audience au complet ! Je me suis donc rabattu sur cette session.
L’introduction est un peu longue à mon goût : qu’est-ce que l’agilité, etc. Et même le manifeste agile ! C’est presque 20 minutes qu’il faut patienter pour en arriver au coeur du sujet !
Le coeur du sujet, en l’occurrence, c’est la définition du manager agile selon Jérôme Barrand. Selon ce modèle (dont il serait beaucoup dire que je l’adopte) il y a 4 principes de base de l’agilité :
- L’effisens (c’est un mot ?) : donner du sens, responsabiliser et optimiser la performance organisationnelle. Même si j’adopte certaines parties, cela fait un peu fourre-tout et je perçois mal la corrélation entre ces 3 éléments…
- Coopération. Un classique. J’achète.
- Anticipation : prévoir des plans d’action. Pourquoi pas, mais en quoi est-ce lié à l’agilité ?
- Innovation : Mais pourquoi “avec parcimonie” et je ne vois pas le rapport avec la “performance durable”.
N’étant pas spécialement ébloui par les 4 principes agiles, voyons les 6 comportements, qui sont liés à 3 des 4 principes agiles :
- Coopération
- Empathie systémique : c’est favoriser la performance collective. On est d’accord !
- Synchronisation : Agir pour ne pas bloquer la situation. Un bon sens que j’approuve.
Anticipation
- Intelligence de situation : On en a plein la bouche, mais cela signifie simplement agir en fonction des informations disponibles. Je ne peut qu’abonder mais aussi remarquer que c’est pratiquement l’inverse de l’anticipation !
- Proaction : Mettre en place une analyse des risque, des plans d’actions, bref tous les machins pas agiles. Et oui, là c’est bien de l’anticipation.
Innovation
- Rebellion constructive : J’aime bien cette expression. Et en gros, c’est “sortir du cadre”.
- Pédagogie relationnelle : agir comme un leader qui donne du sens correspond bien à ma vision des choses. J’aurais bien classé cela dans “effisens”.
Dans ce modèle de management agile, les outils du manager se classent en 2 catégories :
- Les outils liés à la structure de personnalité. Ici on utilise surtout la Process Com.
- La perception de l’environnement en utilisant un radar type “Agile Profile” avec une détermination en mode normal et en mode “sous pression”.
Le dernière partie avait trait à l’entreprenariat. Je vous laisse regarder les slides, mais je ne m’étendrais pas dessus, là moins qu’ailleurs, le propos me convainc.
Bref, assez déçu par cette session qui n’aura eu d’intérêt pour moi que l’évocation du modèle de Jérôme Barrand dont Véronique Messager avait parlé dans son ouvrage sur le coaching Agile. Je ne pense pas encore prendre ma carte du fan-club…
Petit break de l’après-midi
A Agile Grenoble, c’est café et boissons toute la journée. Mais aussi tours de magie à l’occasion !
Un impromptu drôle et réussi ! Finalement, je vais d’ailleurs rester avec Jérôme Bourgeon sur le créneau suivant.
Petits conseils aux orateurs, par Jérôme Bourgeon
Notre magicien de service est un artiste de scène chevronné et il nous fait partager quelques conseils à propos de nos prestations de présentateurs.
Première règle : Y’a pas de règle ! Bon, ça commence bien…
L’espace de scène est en gros divisé en 6 :
- Horizontalement : gauche, milieu, droite ; on entre à gauche, on s’arrête au milieu. A la fin, on sort par la droite. Sauf Steve Jobs qui fait l’inverse.
- En profondeur : l’avant-scène permet de prendre une position dominante pour faire passer des idées, tandis que l’arrière scène permet au public de souffler, pour faire réfléchir.
Il faut se déplacer sur scène pour éviter la monotonie, mais ne JAMAIS tourner le dos au public ! La monotonie, c’est aussi faire attention à ne pas parler d’une voie monocorde ou ne pas agacer l’assistance avec des tics corporels (aka “la savonnette”, le “mal de mer”, etc.). D’ailleurs, si on doit présenter le matin, il faut penser à chauffer sa voie (je ne savais pas cela…).
Pour une présentation longue, on ne peut (ni ne doit) garder le même niveau d’énergie. Surtout pour un moment crucial, il faut faire monter la sauce, donc, comme dit Jérôme, “gérer sa chiantitude” !
Ah ! Il y a un point sur lequel j’ai bon, de toute évidence : penser à se créer une identité visuelle. Si vous voyez ce que je veux dire…
Enfin, avant de sortir : penser à remercier !
End of AG13
Il reste encore une session, mais déjà c’est l’heure des premiers départs.
Pas de session non plus pour moi sur ce créneau, surtout parce que je commence à fatiguer.
Sur le stand Zenika, on plie les gaules, car on va avoir un peu de route pour rentrer sur Lyon (toujours pas de trains pour Paris en départ de Grenoble).
Mais on n’est quand même pas pressés au point de refuser le cocktail de fin offert par les organisateurs, ce serait mal poli. De plus, on va quand même pas rouler à jeun, c’est très déconseillé…
Agile Grenoble, c’est terminé pour cette année. Je suis satisfait de l’accueil fait à ma session. Moins satisfait de moi-même sur mon parcours de session : il y avait beaucoup de sujets de qualité, mais je n’ai pas su bien sélectionner ceux qui me correspondaient. C’est un peu dommage, mais la faute m’en incombe.
Il s’agira de faire mieux l’an prochain : l’ambiance et les échanges étaient géniaux, j’espère revenir. Un grand merci aux organisateurs !
Celui qui rame dans le sens du courant fait rire les crocodiles.
Proverbe Africain
Software Freethinker 
