2010, jeux et ateliers ludiques - Scrum, Agilité & rock'n roll

Extraits de mes statistiques Analytics.

En tout cas, ce sera le cas pour moi demain soir, puisque j’aurai le plaisir de présenter, accompagné d’un partie de l’équipe (n’est-ce pas les gars ?), le logiciel libre IceScrum qui assiste les équipes qui pratiquent le développement agile dans la gestion de leur projet. Cette rencontre est organisée par l’association Toulibre, qui avait organisé l’Ubuntuparty en décembre. On en parle aussi sur LinuxFr.org.

Il arrive qu’un changement soit urgent, comment faire avec Scrum ?

Le livre Scrum, le guide pratique de la méthode agile la plus populaire, sera publié dans moins d’un mois chez Dunod.

Il a été produit avec l’outil IceScrum. En abscisse on a les sprints. En ordonnée, on a le nombre de stories dans chaque état de son workflow. Dans cet exemple, les données sont celles du projet IceScrum lui-même. Les sprints durent 2 semaines et représentent environ l’équivalent de 3-4 jours de travail (les membres de l’équipe sont à temps partiel). Ce type de diagramme a été mis en avant par David Anderson qui promeut le Lean Software et en particulier la pratique du Kanban.

Le mini-livre Scrum et Kanban en français

Scrum se présente comme un cadre pour développer des produits, ce n’est pas vraiment une méthode ni un processus complet. Quand on utilise Scrum sur un projet il faut ajouter à ce cadre des pratiques complémentaires, variables selon le domaine, et adapter le tout au contexte. Le cadre Scrum, c’est notamment les sprints et le cérémonial. Quand on associe XP à Scrum, on garde en général le cadre Scrum et on ajoute les pratiques d’ingénierie XP. Le cadre n’est pas affecté. L’association de Kanban avec Scrum semble plus délicate quand on sait que Kanban est un système à flux continu. On se dit que c’est opposé au rythme des sprints. C’est toute la force de ce mini-livre de Kniberg et Skarin de montrer comment prendre (tirer !) le meilleur des deux. Scrum et Kanban sont deux outils de processus qu’on peut combiner et le livre donne des pistes pour que les équipes définissent la combinaison adaptée à leur situation.

Le facteur m’a apporté un exemplaire avant-coureur de mon ouvrage (comme ils disent chez Dunod). Il est beau, il sent le livre neuf. Je l’ai manipulé délicatement et j’ai juste regardé les images.

Depuis 5 ans, au rythme d’une formation par mois environ, j’ai bien dû former pas loin de 500 personnes à Scrum. La plupart au cours de sessions organisées dans les entreprises pour des groupes de personnes. Je propose maintenant des formations publiques, dites inter-entreprises, auxquelles on peut s’inscrire de façon individuelle. La prochaine est celle de Toulouse. C’est l’occasion d’apporter quelques précisions sur cette formation Scrum.

La transition à Scrum dans un contexte de gouvernance et de modèle économique imposant habituellement une production abondante de documents. J’accompagne une équipe Scrum dans un contexte où de la documentation est exigée lors de jalons contractuels. Au départ, il s’agit d’un appel d’offres dans un domaine industriel. L’appel d’offres est classique -pas agile- et la réponse a proposé un développement avec une méthode agile. Le développement se fait avec Scrum, mais en plein accord avec l’émetteur de l’appel d’offres, ce qui laisse, heureusement, une marge de manœuvre par rapport aux jalons et à la documentation à fournir.

Le scrum (ou mêlée) est une pratique très représentative de Scrum. L’adage no scrum no win largement repris pour expliquer la victoire de la France contre l’Ecosse samedi en rugby me donne l’occasion de revenir sur la réunion quotidienne d’une équipe Scrum. Le scrum quotidien est une réunion qui se passe tous les jours avec l’équipe debout.

Je ne suis pas allé voir dans les librairies, occupé que j’étais hier en formation, mais je sais que quelqu’un l’acheté à la FNAC. Il est donc bien dans les bacs !

Dans mon livre, je cite Amazon pour sa pratique du développement itératif (Amazon met en avant la pratique des itérations pour expliquer ses succès) et du déploiement continu. Une présentation faite à Agile 2009 indique que plus de la moitié des développeurs d’Amazon.com font du Scrum. Maintenant que mon livre est sur Amazon.fr, j’observe que, question logistique, l’approvisionnement se fait à flux tendu. Un peu trop parfois : depuis vendredi mon livre était en rupture de stock chez Amazon.fr, le délai annoncé étant de 9 à 14 jours. Pire, certains ayant fait une pré-commande annoncé livrée dès le 10 février ont reçu le message : “Nous avons le regret de vous informer que nous ne pourrons pas vous expédier les articles suivants dans les délais annoncés initialement sur notre site”.

Deuxième version de la traduction de Kanban et Scrum

La traduction en français du mini-livre “Kanban et Scrum” de Kniberg et Skarin, sous-titrée “tirer le meilleur des deux” a été déjà été téléchargée plus de 1000 fois dans la version publiée il y a un mois.

Fabrice, qu’on ne félicitera jamais assez pour l’excellent travail qu’il fait et les traductions qu’il offre à la communauté francophone, m’a fait découvrir un article de Boris Gloger sur IceScrum, directement en français. Je reprends quelques-uns des commentaires de Boris Gloger : La première fois chose à faire est de créer votre projet et vous pouvez choisir entre deux types d’estimation, la plus populaire avec Fibonacci et une plus classique qui va de 0 à 99.

La nouvelle version d’IceScrum, publiée hier, comporte de nombreuses nouveautés. C’est le feedback des utilisateurs qui nous guidés pour définir les priorités. La clé plate que brandissent les membres de l’équipe sur le dessin (merci Manuarii) rappelle une amélioration concrète d’ergonomie : l’accès a de nombreuses fonctions qui se faisait uniquement par clic droit (ce qui n’était pas intuitif pour une application web) est désormais plus évident, grâce à la clé de 12[1].

Vendredi j’étais à Limoges et comme après la conférence nous nous sommes retrouvés, orateurs et organisateurs, dans un excellent restaurant de la ville, j’ai raté Galles-France. Alors aujourd’hui pour me consoler je suis allé voir le match Castanet-Nice, en fédérale 1. Du jeu, du suspens, pas mal du tout. J’ai passé la première mi-temps dans les tribunes. Trop près des supporters de Nice, qui ne donnent pas dans la délicatesse, et trop loin des joueurs. A la mi-temps je suis descendu près du terrain, le long de la main courante, c’est bien mieux, on entend les bruits des joueurs, les encouragements des entraîneurs et les supporters sont plus connaisseurs.

Finalement à Limoges vendredi, c’était plutôt une conférence qu’un séminaire. La preuve, j’étais conférencier et pas séminariste. C’est ce qui était écrit sur mon badge ! Belle réussite pour cette première conférence en Limousin, très bien organisée. Thierry a ouvert avec une présentation de l’agilité basée sur le Manifeste et j’ai enchaîné avec Scrum. Ma présentation a duré 25 minutes ; j’ai bien tenu le timebox (grâce aux annonces de Jimmy), mais pas eu le temps de parler d’IceScrum, ce sera pour la prochaine fois.

J’ai fait la connaissance de Bruno Sbille en mai de l’année dernière, à l’occasion de la circulation sur Internent de la vidéo “Scrum in the real world”. J’en avais parlé dans un billet court, mais enthousiaste et j’avais demandé à Bruno s’il pouvait traduire les sous-titres en français[1]. Quelques mois plus tard Bruno m’a proposé de publier un article à lui sur mon blog, ce que j’ai accepté avec plaisir. C’est le billet Le calendrier visuel, un outil très agile. Cela nous a permis d’échanger sur Scrum (et sur le rock’n roll).

La publication est une étape importante et je pensais être libéré une fois que ce serait fait. Mais non, il reste l’inquiétude de savoir s’il sera bien reçu. Je suis à l’affût de tout ce qui pourrait me donner la tendance. Comme indicateur, il y a bien sûr les commentaires et critiques qui sont publiés. Les avis sont plutôt positifs et cela est déjà un bon indicateur, mais qu’en est-il des ventes ?

Planifiez vos conférences sur les méthodes agiles

On apprend beaucoup en assistant aux conférences. Il faut y aller. Les retours d’expérience, les exposés, les démonstrations et les discussions avec les personnes rencontrées à l’occasion, cela apporte de la valeur aux participants. Mais évidemment cela leur prend du temps aussi. Ces événements peuvent tomber en plein sprint et avoir un impact sur la planification. Peut-être que ça pourra aider certains, je vais prendre l’exemple de l’équipe qui fait le développement d’IceScrum et qui participe à ces 3 conférences. Je dis le développement mais en fait c’est plus large, puisqu’elle s’occupe aussi du support et de la communication et du marketing, ce qui pousse à considérer la participation aux conférences comme une activité de l’équipe, en plus des activités de développement.

Cet après-midi, une idée remontée de la rétrospective portait sur l’identification de types de tâches avec des codes de couleur. Pendant le sprint, l’équipe a eu du mal à s’y retrouver dans le tableau des tâches affiché au mur[1] de la salle commune et en particulier pour savoir facilement quelles tâches de développement restaient à faire. La proposition, qui a été retenue pour le sprint suivant, consiste à associer une couleur de post-it aux 3 types de tâches suivants :

À juste titre, l’adage “no scrum no win” a été ressorti après la victoire de l’équipe de France. C’est Marc Lièvremont, l’entraîneur français, qui l’a fait dans L’Equipe. Effectivement cette victoire difficile doit beaucoup à la mêlée. Il y a 4 ans, ma première présentation de Scrum portait sur l’analogie avec le rugby[1] et de mes premiers billets sur ce blog s’appelait Mêlée. Depuis je continue à faire de temps en temps référence au rugby dans mes billets et je l’ai fait aussi dans mon livre[2]. De temps en temps, parce que l’analogie entre Scrum (ou l’agilité) et le rugby a ses limites.

Mon éditeur m’a annoncé hier qu’il allait demander le retirage de mon livre, sorti le 10 février. En moins de 2 mois, on a largement dépassé les 1000 exemplaires vendus. Dans le sous-titre, qui n’a pas plu à tout le monde, je présente Scrum comme la méthode agile la plus populaire. Scrum est effectivement mainstream parmi les méthodes agiles, et l’agilité est un mouvement en train de devenir mainstream aussi.

Depuis que je fais des formations Scrum, mon style de formation a évolué vers plus de travaux pratiques et surtout plus d’ateliers en groupe. Dans le même sens, mais probablement pas autant, que Agile Bob qui raconte dans le billet “What style of agile training works best?” comment il a changé de style de formation et le succès qu’il a rencontré. Il a l’air sympa Bob et il a de la bouteille, il doit bien avoir mon âge.

Rétrospective de ma formation Scrum à Paris

Dans les formations publiques inter-entreprises, les participants viennent d’horizons différents et c’est très enrichissant. Il y avait finalement 8 personnes à ma formation Scrum de la semaine dernière. Elle était organisée à Paris dans le 11ème, en partenariat avec Ideia qui fournissait la logistique. Cette salle de formation est vraiment idéale pour un groupe de cette taille. On peut se déplacer facilement, travailler en 2 groupes de 4, poser les post-it constituant le backlog de l’étude de cas sur une table annexe pour les ranger par priorité ou pour l’estimation par comparaison et bien sûr coller au mur tous les post-it produits lors de la dizaine d’ateliers. La nourriture et les boissons sont toujours disponibles sur une autre table.

Du TIC, du TOC et aussi du SUG, en vrac pour ce mois d’avril que j’ai commencé le mois sans ADSL (ni téléphone) à cause d’une transition difficile de France Telecom à Free… Et aussi la publication d’un article sur Developpez.com qui présente l’usage de Kanba pendant un sprint.

Mais depuis quelques semaines, il m’arrive de me rendre de temps en temps au centre commercial de Labège. Je passe devant le Carrefour sans m’arrêter et je rentre à la FNAC. Je me dirige vers le fond du magasin, j’arrive au rayon informatique et je cherche un livre. Le mien. Arrivé devant l’étagère, je parcours les tranches des livres en essayant de voir un gros Scrum en noir sur fond blanc. En commençant par le haut.

C’est vrai. Non seulement je publie moins, mais j’ai tendance à faire de l’égotisme quand j’écris un billet. Ecrire régulièrement des billets intéressants demande beaucoup d’énergie et une grande motivation, et en ce moment je me consacre plutôt au lancement d’iceScrum Technologies. Bon, il y a aussi que j’ai beaucoup écrit sur Scrum et les méthodes agiles : depuis plus de 4 ans dans ce blog et pendant 3 mois intensifs pour mon livre. Cela devient plus difficile de me motiver pour trouver des choses originales à dire.

En effet dans le chapitre 13 “De la vision aux stories”, après avoir présenté la démarche pour arriver aux stories, j’ai écrit un paragraphe sur les use-cases (qui ne font pas partie de la démarche) pour rappeler qu’ils sont différents des user stories, et moins bien adaptés au développement agile.

Le post-it éternel ! Cet article (extrait du Monde je crois) que Josiane a envoyé à l’équipe TEC ne parle pas des méthodes agiles, mais il aurait pu, tant le post-it est associé à leur usage : on reconnait tout de suite les équipes agiles avec leurs murs décorés de notes multicolores. Avec l’essor de Scrum, je pense que les ventes de post-it ont augmenté. Certains suggèrent qu’il doit y avoir un marché pour le post-it réutilisable dans une optique de développement durable.

L’utilisation du tableau des tâches avec des Post-it est devenue une pratique courante (mainstream) pour les équipes agiles. Par contre, ce que je vois beaucoup moins souvent affiché sur les murs, ce sont des schémas. Par exemple un schéma de l’architecture du logiciel ou un modèle métier des concepts manipulés ou un digramme de séquence expliquant un comportement représentatif.

Voici les résultats de mon sondage sur la durée des sprints (101 réponses) J’avais fait le même sondage l’an dernier. Que donne l’évolution d’un an à l’autre ?

Mon éditeur m’a annoncé il y a quelques jours que le total des ventes de mon livre Scrum s’établissait à 1372 exemplaires, depuis la publication le 10 février.

Dans les commentaires de mon billet “le post-it défie le temps”, noname vitupère contre le post-it [1]. A l’opposé, on voit régulièrement sur les blogs des billets pour promouvoir le post-it et vouer aux gémonies l’outil informatique. C’est à chaque équipe de se déterminer et de choisir l’outil qui lui convient le mieux. Évidemment la dispersion géographique est un élément important et influe sur le choix : moins facile avec les post-it quand toute l’équipe n’est pas dans le même espace.

Mardi prochain, le premier juin, j’animerai une session lors de la conférence Agile France qui a pour titre : iceScrum, l’outil Scrum Open Source. Cela se passera à 16h30, Salle A - Communication, Belvédère. Dans cette conférence, l’accent est mis sur l’interactivité et le pragmatisme, alors je ne vais pas me contenter de faire une bête démo puis demander à la fin s’il y a des questions. Bien que ma session soit dans la catégorie Outils, il y aura de l’interaction avec les participants. Voilà comment j’envisage les choses.

J’ai reçu il y a quelques jours la 3ème édition du livre de Véronique Messager sur la gestion de projet agile. Déjà la 3ème édition pour un livre[1] sorti en décembre 2007 !

En l’espace de quelques semaines, iceScrum va faire l’objet de présentations dans 4 manifestations à travers la France : mardi prochain, pour la conférence Agile France à Paris, le 7 juin à Toulouse dans un atelier organisé par la SigmaT, le 7 juillet à Bordeaux pour les RMLL (Rencontres Mondiales du Logiciel Libre, catégorie Développement), le 8 juillet dans le cadre d’une session sur Scrum à la Sophia Conf. Pour préparer tout ça, je me suis demandé quelles étaient les attentes de participants à ces présentations. Après avoir interrogé quelques personnes, j’ai commencé la constitution d’un backlog des sujets susceptibles d’intéresser le public de ces sessions.

Le backlog pour ma présentation à Agile France

Donc je vais à la conférence Agile France lundi et mardi prochains. Je vais assister à plein de sessions qui s’annoncent intéressantes. Et mardi j’anime une session sur iceScrum dans la catégorie Outils. Comme je l’ai dit, je vais essayer de rendre ça intéressant et interactif en sortant du cadre de la démo d’un outil. Ce sera une sorte d’open camp géré à la Scrum. J’ai préparé les cartons, des verts et des rouges que j’ai découpés moi-même. Ces cartons ne sont prévus pas pour y écrire les stories, ils sont destinés au public (mais faudra me les rendre après) qui s’en servira pour donner son avis sur son intérêt pour un sujet à traiter et pour dire s’il est satisfait de la couverture du sujet. Ou pas.

J’ai pris beaucoup de plaisir à participer à la grande conférence sur l’agilité la semaine dernière, au chalet de la porte jaune du bois de Vincennes. Quand j’allais dans les conférences sur le génie logiciel dans les années 90, j’ai le souvenir d’un hall de parc d’exposition avec des stands d’exposants et des salles impersonnelles. Rien de tout cela ici : on pouvait aller suivre des sessions à la fermette ou au chalet ou se promener près du lac ou s’asseoir sous les frondaisons pour discuter le bout de gras. Pas de présence commerciale ostensible, des sponsors discrets[1]

Organisé lundi soir à la maison des associations, l’atelier iceScrum reprenait le format de ma session à la conférence Agile France, avec un peu plus de temps.

Un tableau des tâches sert à montrer l’avancement des travaux pendant le sprint, c’est une représentation physique du plan de sprint. Dans un tableau de sprint, il y a une première colonne pour les stories, puis 3 autres pour les tâches, permettant de suivre l’avancement de celles-ci : à faire en cours fini Au début du sprint, toutes les tâches sont dans la colonne à faire. Ensuite au gré des progrès de l’équipe, elles passent dans les colonnes en cours puis fini. Avec un outil comme iceScrum, la largeur des colonnes varie automatiquement avec le nombre de tâches dans la colonne.

Dans ma formation de la semaine dernière, il y avait un peu plus de la moitié des participants qui pratiquaient déjà Scrum, plus ou moins. Mais au moment de parler de planification de release agile, quand je leur ai posé la question “Estimez-vous en points ?”, il s’est avéré que leurs estimations se faisaient plutôt en jours. Certains avaient essayé les points et avaient abandonné devant les nombreuses réticences de leurs équipes.

Dans le mini-livre Scrum et Kanban, tirer le meilleur des 2, l’accent est plutôt mis sur la complémentarité des pratiques. David Anderson, pourtant auteur d’une préface de l’ouvrage en question, pointe, dans son article Thoughts on how Kanban differs from Scrum, des différences importantes entre les 2 approches. Anderson met en avant des contextes d’organisation qui sont plus adaptés à l’une ou à l’autre. Il écrit notamment : If your organization has low maturity, limited capability at risk management, change management and decision making, and is riddled with specialization and defensiveness then Kanban is probably a better choice.

Il y avait moins de monde que d’habitude au SigmaT14 ce vendredi. Nous étions 28 alors que l’assistance a varié dans une fourchette entre 40 et 70 participants pour les précédentes éditions. Je ne sais pas quelles sont les raisons profondes de cette désaffection relative.

Ça fait quelques années que je n’y mets plus les pieds et je vais me contenter de prendre l’événement comme prétexte pour parler de rock’n roll. Car mon blog s’appelle Scrum, Agilité et Rock’n roll depuis janvier 2009 (avant c’était bêtement Scrum, méthodes agiles). Et si j’y parle régulièrement de Scrum et d’Agilité, le rock’n roll est le parent pauvre de la trilogie, le nombre de tags sur le sujet le montre. Cependant, personne ne me le reproche, on ne vient pas sur mon blog pour le rock’n roll, ce que me confirme Google Analytics.

Pour obtenir plus facilement une formation, un de mes prospects me demande une justification des méthodes agiles, à destination des personnes qui gèrent le budget. Alors voilà.

Dans Alternatives Economiques de juillet-août, je tombe, pages 86-87, sur un article, intitulé “Culture d’entreprise, ouvrir la boîte noire” qui parle d’anthropologie d’entreprise. Les auteurs constatent que la culture d’entreprise est une notion bien souvent négligée par le management : La pensée dominante voit toujours la culture d’entreprise comme une boîte noire inaccessible à toute compréhension et à toute action… Cette démission est lourde de conséquences. Privilégiant les objectifs financiers à court terme, les entreprises ne cherchent plus à devenir des collectifs organiques, c’est à dire des regroupements de personnes complémentaires, organisés autour d’un sentiment commun d’appartenance.

Pour être plus explicite, plutôt qu’élément du backlog de produit, j’utilise story. Le backlog de produit contient donc des stories. La vie d’une story se déroule de la façon suivante :

Mon éditeur (Dunod) m’a demandé de commencer à réfléchir à une deuxième édition de Scrum, le guide pratique de la méthode agile la plus populaire. Oh, on a le temps, c’est pour une publication au printemps en automne 2011. Une 2ème édition peut inclure un éventuel nouveau chapitre, mais le plus usuel est d’améliorer et d’ajouter des paragraphes à ceux existant.

C’était l’année dernière, en été, j’écrivais laborieusement et j’envoyais mes chapitres au fur et à mesure de leur rédaction, dès que j’avais quelque chose de lisible.