En finir avec le stand-up ?

Le stand-up, ou scrum meeting, quelque soit le nom que vous lui donniez, est un élément prépondérant du framework Scrum (et d’autres approches agiles également). C’est lui qui permet de maintenir le cap de l’itération et de s’assurer que tout reste dans les clous de ce qui a été prévu en début de Sprint et de faire des choix ou des actions correctrices le cas échéant.

Vous connaissez sans doute le principe : à heure fixe chaque jour, les membres de l’équipe se rassemblent, souvent devant leur Scrum Board. C’est un rendez-vous court d’une dizaine de minutes (c’est pourquoi tout le monde reste debout) et chacun répond à 3 questions :

  • Qu’ai-je fait hier ?
  • Qu’ai-je l’intention de faire aujord’hui ?
  • Quelle problème ai-je rencontré ?

Tout est dans l’efficacité. Qu’est-ce qui pourrait mal tourner ?

Lire la suite

En finir avec les User Stories ?

Aujourd’hui je vous propose d’investiguer l’un des outils les plus emblématiques des approches agile : la User Story. Par son « focus » et la légèreté de son expression elle symbolise une part importante de ce que nous voulons faire en agile.

Créées avec l’Extreme Programming, elles ont été adoptées largement par la communauté Scrum (Scrum n’évoque qu’une notion plus générique de « product backlog item » ou PBI). Ces User Stories peuvent-elles nuire aux projets agiles ? En quoi leur usage peut-il être néfaste ?

3 mots sur un bout de carton !

…Ou sur un post-it, pour rester dans la tradition agile. Voilà qui nous change des documents de spécification tellement épuisants à compléter ! Sans compter que ces derniers sont vraiment ennuyeux : traquer la précision, chasser l’ambiguité, devoir tout justifier… Un vrai travail de romain !

Lire la suite

Quand les users stories deviennent techniques…

Je ne suis pas un intégriste de la User Story. Il ne m’importe pas tellement qu’elles suivent le fameux template de Mike Cohn « en tant que… je veux… afin de… ». Même si ce template n’a rien de mauvais et peut guider vers l’écriture de meilleurs histoires, c’est aussi un bon moyen de devenir un « template zombie ». Je préfère les 3 questions de Jeff Patton : Qui ? Quoi ? Pourquoi ?

image

En fait, peu m’importe que vous parliez de User Story, d’item de backlog ou d’un autre terme inventé de toute pièce. Ce qui va m’importer, c’est que votre story ait un sens d’un point de vue externe au système que l’on construit. C’est là qu’intervient le « qui », un acteur externe aus système. Ce n’est pas par dogmatisme que j’y suis sensible, mais au contraire par pragmatisme. Une petite explication s’impose.

Lire la suite

Soirée « en finir avec… » organisée par le French SUG

Ca y est, je l’ai : Ma soirée mégalo à moi ! En effet, le 29 Janvier nous nous retrouverons sous l’égide du French Scrum User Group pour une soirée exceptionnelle « en finir avec… ».

Pourquoi une telle soirée ? Tout d’abord pour fair écho bien sûr à la série de post que je vous ai asséné depuis maintenant 3 étés, et que vous retrouverez encore quelque temps. Ensuite et surtout pour réfléchir ensemble à nos pratiques agiles : les comprendre et savoir les remettre en cause !

En effet, nous tenons pour acquis la nature agile des pratiques identifiées comme « bonnes pratiques ». Qu’en est-il réellement ? Quelle est la nature et l’objectif fondamental de chacune d’entre-elles ? S’inscrivent-elles vraiment dans notre système de valeur ou s’en éloignent-elles au contraire sous pretexte de compromis à un environnement aux antipodes de ce que nous voulons faire ? Notre acceptation inconditionnelle même de ces pratiques s’inscrit-elle dans un état d’esprit agile ? Mais là, je crois que nous avons déjà la réponse…

Si ma prose vous interpelle, rejoignez-nous le 29 Janvier ! Aucune promesse ne sera faite sur ce que vous pourrez en retirer, car cela dépendra largement de ce que vous saurez y apporter !

Soirée « en finir avec… » organisée par le French SUG

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

Lire la suite

En Finir avec le Planning meeting ?

Je vous avais laissé sur la remise en cause des estimations. Natrellement, le sujet suivant ce dvait être le planning meeting. Nous allons nous y attaquer aujourd’hui !

Autopsie du planning meeting

Le planning meeting de Scrum, c’est une composante importante de la démarche, du moins dans le Scrum Su (). De là découle tout ce qui sera fait durant le sprint. Aussi intéressons-nous à ce qui le constitue.
Tel que décrit initialement, le planing meeting comporte 2 parties, c’est donc en fait 2 meetings en un seul [1] :

  • Une présentation des fonctionnalités souhaitées pour le prochain sprint
  • Une planification de l’execution de ces fonctionnalités pour la durée du sprint

Les textes ultérieurs ont ajouté un peu de détail, comme la présentation de l’objectif de sprint et la détermination de la capacité de travail [2]

image

Lire la suite

En finir avec les estimations ?

Poker, Fibonacci et stock

Aujourd’hui j’aimerais parler d’estimations. D’estimations agiles, bien sûr. Elles n’ont rien à voir avec les estimations classiques. Ou du moins, pourrait-on le croire. Voyons cela !

L’un des points marquants souvent évoqué est que l’estimation n’est pas faite par une seule personne, mais par l’ensemble des membres de l’équipe, afin de bénéficier de la sagesse de la foule. En fait, l’estimation collective est utilisée depuis longtemps dans les approches classiques et est connue sous le nom de wideband Delphi. Il est vrai toutefois que la technique est sous-utilisée, beaucoup de chefs de projets préférant « optimiser » le temps nécessaire aux estimations ou ignorant simplement cette technique !

L’autre élément majeur est l’utilisation d’estimations relatives, décorellé d’une estimation en charge. Une approche déjà utilisée dans le Function Point Analysis. Ici l’approche agile se distingue par l’utilisation d’une échelle de précision adaptative qui a donné lieu aux fameux jeux de carte du planning poker

image

Lire la suite

Bientôt l’été !

J’en fais déjà une tradition : le blog va passer en régime estival. Essayons d’en dire plus.

Mon activité

L’an dernier, je vous avais fait part de gros changements. Ce ne sera pas le cas cette année, heureusement ! En fait, j’ai plusieurs petits projets personnels en cours ou à venir pour lesquels je dois me ménager un peu de temps. Mais il ne sert pas à grand chose d’en parler tant qu’ils ne sont pas arrivés à maturité.

Pour préparer la rentrée

Oui, il faut y penser dès à présent ! Il y a bien sûr des conférences et principalement la série des agile tours ! Le programme n’est pas encore fixé, mais je vise 3 présences sur ce dernier trimestre pas plus. Il reste à déterminer sur quels évènements.

Sur le blog

Malgré les sarcasmes de mes confrères, je suis bien décidé à vous relivrer mes notes de lecture has been (je pense à Pablo et Alfred, principalement…). J’en ai un paquet à écouler, donc ce ne sera pas la dernière année. Dans l’ensemble il devrait s’agir de textes accusant une vingtaine d’année environ !

Toujours dans la séquence nostalgie, j’ai aussi quelques articles écrits il y a une dizaine d’année d’année. J’attendais une opportunité pour les replacer : ce sera fait !

En finir avec…

Ce n’est pas très logique de sortir ce genre d’écrits à l’époque où la fréquentation baisse, mais je récidive dans cette voie.
Ce sont 5 opus que je vous ai livré sur les deux années précédentes. Ont déjà subi mon traitement impitoyable :

Je vise 3 sujets pour cet été. Cela parait peu, mais ces posts me demandent vraiment beaucoup de travail et de recherche. L’an dernier, je me suis même limité à deux ! Je vous laisse deviner les sujets que je me prépare à aborder. Vous pouvez laisser un commentaire si vous avez une idée.

L’été commencera le 1er Juillet ! A très bientôt.

2.0, I me mine (opus 2013)

Comme je l’avais fait sur les deux années précédantes(donc 2011 et 2012), voici mon l’état de mon usage du Web 2.0

Cette année écoulée est marquée des révélations de Snowden. La NSA a transformé l’Internet en source d’information, bien d’autres pays sont sur la voie. Je pensais déjà à ce que je met sur le Web en terme d’information pouvant être espionnée. Il faut se faire à l’idée que ce ne plus une question de pouvoir l’être, mais de l’être vraiment.

De moins en moins à plus du tout

Yammer : J’utilisais peu du temps du SUG. Je ne fais plus partie du SUG, donc maintenant c’est “plus du tout” !

Quora : J’utilisais peu. Là il faut que je l’avoue tout net, j’ai fait une année complète sans y aller. Donc, termeiné ? On verra…

Diigo : J’étais parti avec pas mal d’enthousiasme sur cet outil de bookmarking. Au final, je me suis lassé de continuer son utilisation.

Producteev : C’était un peu mon outil GTD. Des détails ergonomiques un peu crispant ont fini par avoir raison de ma pugnacité. C’est bien dommage. Peut-être essaierai-je un outil concurrent ?

Ideascale : Je l’avais fait figurer ici car j’étais au bureau du SUG. Depuis que je n’y suis plus, mon usage en est devenu anecdotique.

Pas plus, pas moins … mais peu

Google Doc : J’aimais pas avant, j’aime toujours pas ! Je l’utilise pour partager des choses avec des collègues, mais c’est tout, et contraint et forcé !

Google plus : C’est surtout un outil de notification pour moi. Parfois je lis des posts dans certaines communautés… en fait, ce sont bel et bien les communautés que j’ai tendance à trouver pratiques.

github : Ca ne fait pas terrible de dire ça, mais j’utilise très peu github. Juste un peu les gist…

Stackoverflow : Il est et reste le site incontournable pour répondre à n’importe quelle question de développement. Même si c’est rare, je cntinue à en faire l’expérience !

Trello : Quelques boards personnels et quelques boards professionnels. Je garde un rythme modéré mais réel sur l’outil.

Meetup : Je n’administre plus le meetup du French SUG, mais je reste connecté à 3 ou 4 groupes qui y organisent leurs rencontres.

Slideshare : Là non plus, ce n’est pas un site que je fréquente régulièrement. Juste pour y poster mes présentations 4 ou 5 fois par an…

Disqus : J’ai connecté mon blog à Disqus. Mais pour être honnête, j’ai très peu de commentaire par ce biais. J’en ai bien plus par LinkedIn d’abord, et par Google plus ensuite !

Capitaine Train : La plupart de mes déplacements en train sont pris en charge par l’entreprise. Mais j’utilise bien volontier cet excellent service quand je dois le faire moi-même. Donc peut-être 2 fois par an ou quelque chose comme ça…

Viadeo : Le LinkedIn Français est un incontournable. On y accepte des contacts, j’y notifie les posts de mes blogs (ça ne semble pas porter beaucoup…). Et dans tout ça, mon profil n’y est même pas à jour !

LinkedIn : Si Viadeo est le LinkedIn Français, LinkedIn est le Viadeo international. J’entretiens avec beaucoup d’attention mes contacts. Et mes informations y sont à jour. L’un dans l’autre, je l’utilise un petit peu plus que Viadeo, également pour les notifications de post. Mais ce n’est pas mortel quand même…

Pas plus, pas moins … mais plutôt pas mal

Dropbox : Le stockage en ligne reste un de mes très gros usages. J’y stocke vraiment beaucoup de choses. Bref, usage quaotidien et intensif. Aussi bien “pro” que “perso” !

Evernote : Je suis toujours un utilisateur intensif de DropBox. Et même si cela ne se justifie pas toujours pas, j’ai désormais un abonnement Premium. Et aussi un Livescribe (sur lequel je ferais bientôt un post). Bref, je l’utilise quotidiennement : usage professionnel, personnel, brouillons de mes posts (y compris celui-ci), etc.

GMail : Il faut bien l’avouer, aujourd’hui pratiquement tous mes mails sont sur GMail. Autant pour la confidentialité…

Twitter : Il s’agit surtout d’un usage pro, qui tourne autour de la thématique de l’agilité. C’est aussi pour moi un outil de notification. Pour moi, le web “social” tourne presqu’exclusivement autour de Twitter. Bien que je ne sois pas un fondu des réseaux sociaux…

Tumblr : Mon volume de posts est disons … intéressant. Avec plus de 200 posts par an, on peut dire que c’est une plateforme que j’utilise intensivement !

Plus aujourd’hui qu’hier

Flickr : Depuis que j’ai fait l’acquisition d’un appareil numérique digne de ce nom (un Olympus Pen), mon volume de photo a bien grimpé. Notament lors des évènements pro. Je poste toutes mes photos pro sur Flickr, ne serait-ce qu’à cause du redimensionnement qu’effectue ce service pour faire rentrer mes prises de vues dans le blog. Ce redimensionnement est réellement d’excellente qualité.

Dashlane : J’ai pratiquement cessé d’avoir un même mot de passe pour plusieurs services. J’ai aussi arrêté les mots de pase triviaux. Tout cela grâce au coffre-fort électronique. Esérons que la confidentialité affichée soit réelle … et que le service dure très longtemps !

Issuu : J’utilise désormais exclusivement ce service pour partager des PDF sur mon blog (malgré un techno Flash…). Donc de plus en plus, que ce soit pour mes propres textes, ou d’autres du domaine public que je souhaite partager.

Les nouveaux venus

Goodreads : Le seul nouveau venu de l’année écoulée ! Goodreads permet de partager sa liste de lecture et de consulter celles des autres. Bref, tout ce que l’on a envie d’échanger sur la lecture !

Donc peu de grosses nouveautés pour cette année. En fait, j’ai même un peu fait le ménage. A l’année prochaine !

L’agilité, une question de feedback

J’avais évoqué, lors d’une présentation en 2012, la question du feedback et son rôle majeur en tant que moteur de l’émergence.

J’aimerais revenir sur ce sujet qui me tient à coeur et le développer plus avant ici. Je vais aussi tenter de lui donner, modestement, un petit éclairage historique.

Les boucles du feedback

Pourquoi focaliser sur le feedback ? En fait, nous pouvons interpréter une grande partie des pratiques d’ingénierie et de projets agiles sous forme de boucles de feedback imbriquées. c’est ce que j’avais fait lors de mon lightning talk sur l’émergence. En voici l’illustration.

La Boucle de feedback

Nous reviendrons sur cette illustration un peu plus tard. Car on peut aussi présenter ces boucles  de feedback autrement. Elles ne sont pas le fruit de ces 10 dernières années. L’émergence progressive de ces boucles de feedback a commencé il y a bien longtemps. Longtemps avant que l’on parle d’agilité.

Un regard historique sur les boucles de feedback

Compilation interactive

La plupart d’entre-vous n’avez pas connu cette époque, mais vous savez certainement qu’il fut un temps on l’on saisissait les programmes sur ceci

Punch Card

Chaque carte représente une ligne de code, plus exactement 80 colonnes de texte. Le processus est le suivant :

  • On écrit son programme sur papier.
  • Dès qu’on l’a rédigé (et vérifié, croyez-moi, c’est mieux), on va le saisir sur un terminal produisant une carte par ligne de texte.
  • On donne la pile de cartes au centre de calcul. Ce dernier va programmer sa compilation et son exécution. Ce ne sera pas pour tout de suite, probablement dans quelques jours.
  • Quand le job est passé … on vous donne le résultat … ou pas !

Une de mes anciennes collègues m’a ainsi racontée qu’elle a reçu un jour en retour sa pile de cartes entourée d’un élastique et d’une note rageusement libellée : “fait planter la machine !”. 

Une anecdote hélas probablement pas si rare que ça…

J’ai à peine connu cette époque. mais à mes début, j’empruntais un ordinateur de poche 2 jours par semaine. Je n’avais que ce créneau à ma disposition pour saisir et tester les programmes que j’avais écrit sur papier pendant le reste de la semaine. C’est un peu le même cas de figure.

Cette période est révolue depuis longtemps. Au début des années 80 nous sommes passé de la compilation batch à la compilation interactive. Ou à peu près. On est passé de délais de feedback de quelques jours à quelques minutes (et quelques heures dans le cas de gros projets)

Coloration syntaxique

Il y a certes eu de discrets essais sur des environnement confidentiels dans les années 80 et même avant, mais comme beaucoup j’ai découvert la coloration syntaxique avec un IDE mainstream : Borland C++, au début des années 90.

Je me souviens avoir assisté à la présentation de lancement de l’IDE. Le public a littéralement réagit à la seconde où le présentateur a dévoilé la fonctionnalité.

Coloration syntaxique

C’est le feedback sur la syntaxe d’écriture du programme que cette fonctionnalité adresse. Passer de quelques minutes, c’est à dire le délai entre deux compilations, à quelques secondes est une amélioration conséquente.

Complétion de code

De la coloration à la complétion, il n’y a qu’un pas. C’est le feedback sur notre implémentation que cette fonctionnalité adresse en nous proposant les méthodes disponibles.

Code completion

Vous allez me dire qu’il ne s’agit pas de feedback ici. Vous avez raison. C’est mieux, cette fonctionnalité anticipe le feedback, le rendant inutile. Disponible assez tôt dans les environnements Smalltalk, il faudra attendre la moitié des années 90 pour voir cette fonctionnalité se démocratiser.

Compilation continue

Egalement amorcé par Smalltalk, c’est dans Visual Age Java que j’ai vu pour la première fois cette fonctionnalité faire son apparition, vers la fin des années 90. Cette fois c’est la justesse grammaticale sur laquelle le feedback passe de quelques minutes à quelques secondes.

Agilité et feedback

J’ai dit que nous reviendrions sur l’illustration des boucles de feedback. Nous allons le faire. Mais pourquoi s’intéresser au feedback, en quoi ce mécanisme est-il important et si particulier à la pensée agile.

Parce qu’en tant qu’être humain, et même en fait en tant qu’organisme vivant, c’est notre principal mécanisme d’adaptation. Et l’adaptation au changement, ça figure quelque part dans notre manifeste agile, j’en suis pratiquement sûr…

La rétrospectives

Cette pratique n’est pas à proprement parler nouvelle. les rétrospectives de projets (alors appelés post-mortems) ont probablement plusieurs décennies d’existence. En quoi est-ce différent ici ? Pourquoi faire des rétrospectives plus souvent ?

Agile retrospective

La rétrospective est le mécanisme d’adaptation de notre processus. Un post-mortem de projet sert surtout à se lamenter, la rétrospective d’itération sert à adapter notre processus et nos pratiques agiles.

Cycles itératifs

J’entends souvent les équipes parler de “lotir” les itérations. C’est ce que l’on fait dans les processus itératifs. Seulement le lotissement n’a rien à voir avec l’adaptation.

Le cycle itératif agile utilise ce que l’on a appris de l’itération qui vient de se dérouler pour réévaluer les priorités et la pertinence des items figurant dans le backlog ou comme opportunité d’émettre de nouvelles idées, d’aller plus loin dans les fonctionnalités venant d’être développées.

Acceptance tests

Nouveau venu de nos pratiques agiles, le test d’acceptance nous permet d’avoir du feedback sur l’implémentation des stories, lorsqu’ils sont exécutés. Mieux encore lorsqu’on les écrit, ces tests d’acceptance donnent du feedback sur les user stories elle-même ! Ecrire des tests d’acceptance, c’est instancier les spécifications, lever les ambiguïtés, se décider sur les cas aux limites, générer de nouvelles questions.

Integration continue

Il y a un temps pas si lointain où l’intégration représentait une phase majeure, longue et risquée des projets. Le feedback sur le fonctionnement conjoint des différentes briques se faisait alors sur des cycles allant de 3 mois à deux ans.

C’est avec émotions que nous repensons parfois à ces périodes particulières des projets qui occupaient nos soirées et nos week-ends avec enthousiasme, au lieu de manger des chips et boire de la bière devant un match de foot…

Late integration

Avoir la température, non seulement sur l’intégration, mais sur la qualité du code et la couverture de test, cela fait aujourd’hui partie de notre quotidien. Next !

Tests unitaires

En parlant de quotidien, en voilà un sur lequel je ne vais pas non plus m’attarder : les tests unitaires nous donnent du feedback sur le fonctionnement du code : fait-il ce à quoi nous nous attendons qu’il fasse ? C’est aussi de l’acquis : next again !

Pair programming

On pense souvent au pair programming comme à une technique de collaboration. C’est vrai. Mais c’est aussi et surtout une technique de peer review en temps réel et en continue. Un feedback sur l’écriture de code et les choix de conception fait en temps réel.

Mais aussi …

Le feedback des pratiques agiles ne s’arrête pas là. Après tout, toutes ces techniques sont plus ou moins déjà identifiées comme des techniques de feedback.

Management visuel

Les projets agiles aiment s’afficher. C’est aussi une forme de feedback

  • De la part de chaque membre de l’équipe envers tous les autres.
  • De la part de l’équipe vers tous ceux qui souhaitent savoir ce qu’il s’y passe.
obeya

Lean startup et le validated learning

A plus grande échelle, le cycle agile peut servir à donner du feedback, non plus à l’échelle du projet, mais à celle du business. Lean Startup étend la portée des cycles de feedback au-delà du déploiement, jusqu’à l’usage du produit afin de vérifier les hypothèses produit : persévérer ou pivoter.

De la seconde à l’entreprise

L’agilité fonctionne en harmonie avec le feedback. Mieux, elle guide chaque action par cette simple interrogation : comment vais-je évaluer que je suis satisfait du résultat ? C’est la mise en oeuvre du PDCA de Deming depuis les cycles les plus courts jusqu’aux décisions les plus impactantes.