Learning and groking recursion

I’ve started learning functional programming in July 2016. Actually I wanted to learn Elm because it looked to me like a powerful web development language (and I’d head some good things about Elm from very experiences Haskell programmers. One word that drew my attention was : the code written in Elm is very elegant.

I “practice” Elm only when I am at home, in my free time (which basically means, when the 3 young kids are asleep, at night).

I soon discovered the Functional Programming world, which was not really my first intention. But I thought, well, let’s go for it, let’s be “mainstream” J

That’s where things got a little more complicated than I had expected. As many will say, it is a change of paradigm, for people like me, who did some PHP, SQL, ASP 3.0 or a little “copy/paste JavaScript” before.

When this change of paradigm was done in my head, things became really smooth and fun.  But then I decided to dive into recursion (I had not really notice that a List.map IS actually a recursion).

Things again became complicated. I was told to read some books to grasp the “recursion” thing, but it was hard. I started reading “The little schemer”, I understood this very simple and fun book, so I thought it was ok.

Then I decided to actually write a recursive function of my own, and I fell lost. I didn’t understand what I was not doing that was in the book. I decided to stop looking at the book, and to try, and try and try, again and again, with very different exercises that I invented. It was hard, the solution was never easy to find, sometimes I felt like I was an expert in recursion, and sometimes I felt like I would never be able to do it. I thought it was a good thing that I was not paid to program.

Guess what? Yesterday I began reading Evan Czaplicki’s book Functional Programming in Elm. And he describes, not exactly in the same way, the pain that he had when he was a student, learning and practicing recursion. Wow, how good it felt to hear that.

Especially when he compares it to leaning the For loop, and it reminded me that, yes, at the beginning it was hard for me to grasp the For loop. But I had forgotten that I had to learn it long ago. Now it is feels so obvious.

In this book, Evan also gives some advice about how to understand recursion when you try to apply it. It looks like some “dumb” advice, coming from an expert in this field. But guess what? That was the same tricks that I had found myself. Which means that what we think is just something that we use because we are not experts, is also used by experts! How good it is to hear that also!

One last thing. Evan says that we the existing functions of Elm, we don’t really have, most of the time, to invent our own recursive functions in Elm. Was I wasting my time trying to learn that? Trying to re-do the functions of the Elm List library? Was I the only one on earth trying to do that?

Guess what… Later in the book, Evan writes that it is a very good thing to learn recursion, and the best way to do it is, for instance, trying to write the recursive functions from the Elm List library.

What I learned :

  • Don’t be afraid of what you try.
  • Prefer practicing again and again than reading books.
  • Consider you learned something not when you understood what was written in a book, but when you can actually do it.
  • Invent your own exercices.
  • Try to dig deeper than the surface.
  • Be your own master.

Advertisements

Rétrospectives/facilitation : quelques ressources utiles

Agile Retrospectives – Making Good Teams Great
de Esther Derby et Diana Larsen
Le bouquin de référence sur les rétrospectives agiles
Le PDF gratuit est

The Retrospective Handbook: A guide for agile teams
par Patrick Kua
Un bouquin que je n’ai pas lu mais dont j’entends le plus grand bien

 

 

Project Retrospectives: A Handbook for Team Reviews
par Norman Kerth
Le bouquin de référence sur les rétrospectives en général (donc pas pas spécialement dans un cadre agile). Un des tout premiers écrit sur le sujet.

Getting Value out of Agile Retrospectives – A Toolbox of Retrospective Exercises
de Luis Gonçalves (Auteur), Ben Linders (Avec la contribution de)
Un bouquin tout petit, qui donne déjà une très bonne intro sur le sujet
Le PDF gratuit est

Training from the back of the room
de Sharon L. Bowman
Ne parle pas du tout de rétrospectives, mais plein de conseils utiles pour de nombreux facilitateur. Pour info, outre-atlantique, c’est le livre de chevet de nombreux agilistes/facilitateurs. Beaucoup moins connu en France.

Les slides du coach agile Vincent Daviet :
https://www.slideshare.net/VincentDaviet/exceller-dans-la-facilitation-de-rtrospective

Rétrospectives : mise en place de l’agilité

Il est parfois nécessaire de faire un bilan sur ce que l’équipe a mis en place au niveau de l’agilité, et sa manière de fonctionner.

Voici quelques idées pour ce type de rétrospectives.

1/ Strength-based (basée sur les forces)
Etape 1
Dans une colonne chacun indique la liste des choses positives qui sont faites depuis la mise en place de l’agilité (par exemple, tests au plus près du développeur,…), et au moins une raison pour laquelle c’est positif (moins de bugs, plus de satisfaction au travail,…)

Etape 2
Puis, dans une deuxième colonne, chacun indique ce qui était positif avant la mise en place de l’agilité et au moins une raison pour chaque élément

Etape 3
On regroupe dans une troisième colonne tout ce qu’on aimerait garder des 2 premières colonnes.

Etape 4
On discute pour savoir comment les mettre en place.

2/ High performance tree
Etape 1
Chacun indique quelles sont les principes qui doivent guider le travail de l’équipe (par exemple : être ultra-disponibles pour les développeurs, fluidifier le traitement bout en bout d’une User Story, etc…). Pour faciliter le brainstorming, on peut afficher en premier lieu les valeurs de l’agilité ( engagement, courage, ouverture, focus, respect) et demander de place des principes qui correspondent à une de ces valeurs.

Etape 2
L’équipe se met d’accord sur des principes communs, qui définiront son identité. On peut procéder par un vote (chacun dispose de plusieurs voies à répartir comme il le souhaite sur plusieurs principes)

Etape 3
On indique quelles sont les conditions nécessaires pour que ces principes puissent être appliqués.

Exemple : le courage (valeur) peut être de se donner le droit de dire non au métier (principe) et on peut le faire en communiquant de façon transparente sur le burn-down chart de release (condition nécessaire)
3/ Skills matrix
Etape 1
Chaque membre de l’équipe indique ce sur quoi :

  • il s’estime compétent (tests, analyse, écriture de Users stories, automatisation,dialogue avec le métier, dialogue avec les développeurs,….)
  • il aimerait progresser

Etape 2
On repère qui pourrait aider qui sur telle ou telle compétence.

Etape 3
On décide d’un plan d’action pour voir comment faire en sorte que l’équipe et chacun devienne plus “multi-fonctionnel”.

4/ Starfish
Etape 1
On dessine un camembert avec : Keep, Less, Stop, Start, More
Chacun indique donc ce qu’il aimerait continuer à faire, faire moins, arrêter, commencer, ou faire plus (on doit bien distinguer chaque personne).

Etape 2
On discute d’un plan d’action pour voir comment satisfaire tout le monde.

5/ Mad, Sad, Glad
Etape 1
On crée 3 colonnes (Mad, Sad, Glad) et chacun positionne des post-its pour dire, depuis le début de l’agilité :

  • ce qui l’a rendu heureux
  • ce qui l’a rendu triste
  • ce qui le rend fou (des choses incompréhensibles, débiles, ….)

Etape 2
On discute des différents points pour voir comment améliorer les choses pour chacun.

Rétrospectives efficaces

Voici les grandes étapes d’une rétrospective réussie, avec pour chaque étape une proposition d’animation.

Le facilitateur doit timeboxer les 5 étapes (chrono en main), pour être sûr que la rétrospective ne dépasse pas le temps prévu
1/ Set the stage (prendre le “pouls” des participants)

Animation proposée : Explorer, Shopper, Vacationer, Prisoner (ESVP)
Timebox : 5 mns

On demande à chaque participant de dire dans quelle catégorie il se classe.
Prisoner : je suis là parce que j’ai pas le choix, je suis forcé d’y être
Tourist : j’ai vu de la lumière, ça va me faire un petit moment de break dans la journée
Shopper : je compte repartir avec quelques éléments positifs
Explorer : je vais m’engager pleinement dans l’activité, parce que je sais que ça va être une réunion qui va m’apporter plein de choses.

Astuce1 : utiliser des dessins rigolos et inviter chacun à mettre un post-it dans la bonne case.

ESVP-1.jpg

Source : Karren Greaves, in http://www.growingagile.co.za

Astuce2 : ne pas demander à chacune de s’expliquer. On repère juste quelle est la case où il y a le plus de post-its, et on ne fait pas de commentaires.

2/ Gather data (réunir de la donnée sur laquelle réfléchir)
Animation proposée : Sprint timeline
Timebox : 15 mns

Dessiner une ligne qui va du début du sprint à la fin du sprint, et inviter chacun à mettre un post-it avec les grands “événements” du sprint (positifs ou négatifs)
L’exercice doit se faire en commun, tout ensemble debout devant un grand mur ou mieux assis autour d’une grande feuille A2 posées sur la table. Si tout le monde le fait ensemble, cela évitera que chacun doive expliciter son post-it à tour de rôle.

photo

3/ Generate insights (réfléchir ensemble sur des sujets sélectionnés)
Timebox : 10mns

  • Dans la liste des faits remontés, voter pour 2 sujets positifs et 2 sujets négatifs :
    commencer par éliminer les doublons
  • Grouper les sujets semblables (ne pas chercher à grouper à tout prix, pour ne pas aboutir à des catégories trop généralistes)
  • Dot-voting sur les sujet “prioritaires” : chacun à droit à autant de votes que de sujets à prioriser

4/ Decide what to do
Timebox : 25mns

Pour chaque sujet, décider d’une durée définie pour en parler et aboutir à un objectif simple (target condition) qui peut être atteint à l’issue du sprint suivant (5 mns par sujet par exemple).
Il peut être bien d’avoir un bâton de parole pour que les personnes ne s’interrompent pas mutuellement : une balle que chacun peut réclamer pour prendre la parole et qui la transmet au prochain qui veut parler.

La technique est de se mettre d’accord sur un objectifs, et de définir les taches qui permettront d’atteindre cet objectif.
Cela peut être dessiné sous forme d’une route avec un point d’arrivée (objectif) et des étapes intermédiaires (tâches).

5/ Close the retrospective
Timebox : 5 mns

Faire un petit vote à main levée, (de 1 à 5) pour juger de la qualité de la rétrospective

Les actions décidées doivent être intégrées dans le backlog de l’équipe et suivies lors du sprint comme tout autre élément du backlog (il faut donc que ces actoins soient estimées en sprint planning).

Remarques complémentaires

  • Pour chacune de ces 5 phases, il existe beaucoup d’activités différentes possibles. Consulter les livres de référence sur le sujet. Ne pas hésiter à créer des nouvelles activités !
  • Pour l’angle d’attaque général de la rétrospective, 3 approches différentes sont possibles :
    • Solution focus/Strenght based : se concentrer uniquement sur les choses positives, et savoir pourquoi et comment elles ont été positives.
    • Sujet spécifique : choisir un sujet qui revient depuis plusieurs rétrospectives et axer la rétrospective uniquement sur ce sujet.
    • Généraliste : comme son nom l’indique…

A vous de JOUER maintenant !

Rétrospective fun : “Like to Like”

Pour briser un peu la cadre habituel des rétrospective, un format assez original, vise à mettre en avant autant les choses positives que les choses négatives, et se veut plutôt fun, ce qui est toujours utile !

Avant la rétro :
Le Scrum Master prépare à l’avance des “cartes de facilitation” avec un mot sur chacun. Il retourne ces cartes face masquée et en fait une pile qu’il pose sur la table. Il faut mettre des mots sérieux, des mots positifs, des mots négatifs et des mots fun. Par exemple, la liste suivante :

  • Fun
  • Les 12 Travaux d’Hercule
  • Dans les délais
  • Un jour sans fin
  • Clair
  • Higway to hell
  • Réussi
  • Accessible
  • Freddy
  • Intégré
  • Eureka !
  • Dangereux
  • Talentueux
  • La vie est un long fleuve tranquille
  • Propre
  • Rapide
  • Collaboratif
  • Génial
  • Fiable

Pendant la rétro
Brainstorming individuel
Chaque participant prépare plusieurs post-its (le maximum possible) :
des choses à continuer à faire, des choses à arrêter de faire, des choses à commencer à faire (il faut que chacun ait des items dans chacune de ces 3 catégories).

1er tour de jeu
Une personne de l’équipe est désignée comme juge.
Le juge retourne une des cartes de la pile de cartes de facilitation préparées par le Scrum Master et chaque participant pose sa carte qui se rapproche le plus de cette carte (face cachée). Le dernier qui donne sa carte a perdu : il reprend sa carte.

Seul le juge regarde les cartes posées par les joueurs et sélectionne la carte qui se rapproche le plus, selon lui, de la carte de facilitation.
C’est cette carte qui est gardée, et les autres sont écartées du jeu.

Tours suivants
Le même process reprend, mais on désigne à chaque tour un nouveau juge (lorsqu’elle la personne est juge, elle se contente de jouer le rôle de juge et pas le rôle de joueur).
Le jeu s’arrête lorsque chaque joueur a donné toutes ses cartes.
En fonction du nombre de post-its que chacun aura rédigé, il est possible que ce ne soit pas nécessaire de tirer les 20 cartes de facilitation.

Générer un plan d’action
Pour ce faire, il faut décider comment faire pour que les choses négatives passent dans une catégorie positive, comment reproduire les choses positives, et comment commencer les choses qu’on ne fait pas encore. Cela peut être fait en discussion collective ou en brainstorming individuel.

Remarques

  • Je vous invite à faire une petite répétition avant avec 3-4 personnes pour être sûr de bien le faire le jour J.
  • Comme vous l’aurez remarqué, le facilitateur s’efface au profit du groupe.

Lean Coffee

Chacun réfléchit à des sujets dont il aimerait qu’on parle. Ce peut être des choses positives (“on a bien géré ça, il faut continuer à le faire”, “telle personne m’a bien aidé, je voulais lui dire”,….)

On les affiche silencieusement.

On élimine les doublons.

On vote pour 5 ou 6 sujets (dot-voting)

On dispose de 10 mns pour parler de chaque sujet (il faut un timer visible de tous) en commençant par le sujet qui a obtenu le plus de vote.

Au bout des 10 mns, on décide si le sujet est clos, ou si on rajoute 5 mns pour continuer la discussion (au détriment des autres sujets).