Après avoir refactoré un peu de code la semaine dernière (je continue mon apprentissage de Meteor JS en 2015), l’idée m’a pris de refactorer mon blog.
J’ai eu plus de lecteurs en fin d’année dernière, cela m’a motivé pour faire cet effort.
La question se posait d’un changement de moteur de blog et de thème de présentation. Finalement, côté moteur je reste fidèle à Dotclear et je conserve mon thème qui date maintenant de quelques années, mais qui fait toujours le travail.
Le but du chapitre Il est présenté dans l’introduction :
On peut distinguer trois niveaux pour la prise en compte de l’agilité dans des organisations : projet, produits, organisation. Beaucoup d’expériences actuelles avec Scrum restent au niveau projet. Nous allons approfondir les niveaux produits et organisation. J’ai évoqué, dans le chapitre 18, Transition à Scrum, la façon dont une entreprise gérait le changement vers l’agilité. Ici, il s’agit d’aborder le changement d’échelle dans ce qu’il implique sur la mécanique de mise en œuvre de Scrum, en termes d’équipes, de backlogs et de cycle de vie.
Je publie à nouveau la préface de la deuxième édition du livre de Laurent Morisseau Kanban pour l’IT, en essayant de rendre sa lecture plus fluide (c’est du flux).
Ma préface de Kanban pour l’IT est publiée en 6 billets.
Introduction Je commence cette préface dans le TER vallée de la Marne, après une journée d’accompagnement à Scrum chez un client. Mon travail a consisté à aider une dizaine de futurs Product Owners ou ScrumMasters à la sélection et l’adaptation des pratiques pour leurs projets.
Depuis mercredi à 12h03 avec le tweet de Nathalie et toute la suite des événements, je suis bouleversé.
Avant d’essayer de reprendre des activités (plus ou moins) normales, mon petit hommage personnel à Charlie.
J’ai été profondément marqué par la culture Hara Kiri et Charlie. Surtout Charlie Hebdo[1].
J’ai dû lire à peu près tous les numéros de Charlie depuis le début des années 70, jusqu’à sa disparition, pour 10 ans.
Le chapitre 20 de mon livre s’appelle Scrum en France.
Le but du chapitre Montrer ce qu’il y a de particulier dans l’usage de Scrum en France : vocabulaire, diffusion, spécificités des usages, contraintes organisationnelles, culture, éducation…
Changements dans les éditions successives Ce chapitre avait grossi dans la deuxième édition. Il est revenu à environ 9 pages, ce qui en fait le plus court de tous les chapitres de mon livre.
Raid Agile La deuxième édition du Raid Agile aura lieu en mars. Toujours dans les Cévennes.
Le Raid Agile, c’est une formation différente, rassérénante et captivante. Voyez cet aperçu de la première édition.
Il y avait 16 places proposées, il en reste encore 3 au moment où j’écris ce billet.
Lean User Research Workshop Mes amis d’ekito, toujours en quête de nouvelles initiatives autour du Lean Startup, organisent un atelier de 2 jours en mars aussi, mais à Paris : Lean User Research
Management 3.0 Workout Ce livre fera l’objet du prochain Klub de lecture d’Agile Toulouse. Il est encore temps de le lire pour y participer, alors je ne vais pas le raconter. Sachez seulement qu’il est très bien écrit avec de magnifiques illustrations et un tas de références sur la gestion de projet.
-> Management 3.0
Je n’avais pas lu le premier livre de Jurgen Appelo, pas vu non plus, mais j’en avais entendu causer[1].
Cela fait plus de 20 ans que je suis consultant indépendant. Indépendant, mais pas solitaire. En 2015, je vais continuer et amplifier les coopérations, avec d’autres consultants ou des petites entités agiles et sympathiques.
En début d’année j’ai fait une formation de facilitation aux jeux innovants avec Alexandre Boutin.
La semaine dernière j’ai animé une sensibilisation à l’Agilité, à base de jeux, avec Thierry Cros.
J’espère animer bientôt quelques Gymkhana avec Stéphane Langlois de Scopyleft, avec qui nous co-écrit l'histoire parue dans Rupture Douce 3.
Nous avons raconté nos premiers essais pour atteindre ce but dans l’ouvrage collectif Rupture Douce 3.
Après le teaser, voici le premier paragraphe :
Les citoyens dans le phare, les développeurs sur le bateau Pour imaginer des applications innovantes, le citoyen est un réservoir d’idées brutes. Cette matière première est malheureusement mal exploitée, la collaboration avec les développeurs, directe ou par des intermédiaires, étant souvent infructueuse. C’est criant dans les sociétés où des années de silos ont érigé des barrières entre les utilisateurs ou leurs mandataires et les équipes de développement.
Mais aujourd’hui je ne vais pas vous parler aujourd’hui de série numérique.
J’ai écrit plusieurs fois des billets qui faisaient partie du même récit. Des séries narratives, quoi.
Seulement quand on les publie sur un blog, on commence par le premier. Comme la suite du récit ne fait pas encore l’objet d’un billet, on ne peut pas dans le premier billet faire un lien vers son suivant de la série.
Comme l’an dernier, l’association Agile Toulouse organise une après-midi sur la découverte des savoir-faire professionnels par le jeu.
Cela se passe à l’IPI à Blagnac. Aujoud’hui.
Comme l’an dernier, j’y serai, cette fois pour animer un nouveau jeu permettant d’appréhender les pratiques de l’Agilité à grande échelle, quand il y a plusieurs équipes qui collaborent à un seul produit. Il s’appelle (provisoirement) Agile Scaling Puzzle.
Il y aura d’autres jeux animés par mes camarades de l’association :
10 ans après ma transition de consultant à Scrum (oui, déjà, c’est en 2005 que j’ai mis Scrum sur ma carte de visite), je m’aperçois que mes activités sont très différentes de ce qu’elles étaient au début.
Je fais toujours du Scrum, certes, mais de façon différente et cela va bien au-delà.
Crise en incubation L’inception de Gymkhana date de 2013. À l’époque, notre idée était de réaliser une application Web, baptisée Crise, avec pour but d’aider les citoyens à prendre les bonnes décisions en situation d’intempéries importantes, comme les épisodes cévenols. Nous avions choisi de proposer ce projet à un incubateur dédié à l’Économie Sociale et Solidaire.
Durant six mois, nous avons éprouvé les approches d’accompagnement proposées par l’incubateur. Nous avons suivi des formations marketing afin de réaliser un business plan et une étude de marché.
Le Large Scale Scrum ou Agilité à grande échelle, c’est un sujet ancien qui avait déjà été d’actualité en 2011. J’ai participé au mouvement : j’ai écrit le chapitre 19 de mon livre “Scrum à grande échelle” à cette époque, j’avais fait une présentation au ScrumDay 2011 et c’était aussi le thème de mes présentations aux conférences Agile tour de l’automne. Avec cette grande échelle, on avait parlé de l'Agilité des pompiers.
Un plan de release est souvent présenté en colonnes, comme on peut le voir dans ce schéma.
Le problème avec cette représentation, c’est qu’on ne voit pas l’incertitude. Et il y en a forcément. Qu’on ait fait des estimations ou pas, la prévision comporte une marge d’incertitude.
Une solution pour la montrer pourrait être de publier 2 plans : un optimiste et un pessimiste. Pas terrible : il faut regarder à deux endroits pour comprendre.
Suite à mon billet d’hier sur Plan de release et incertitudes, j’ai reçu un commentaire qui m’amène plusieurs réflexions.
Mon lecteur commence à parler du schéma :
Le schéma est facile est 3 colonnes. L’incertitude cumulée sur 6-7 sprints (ex. release de 3 mois avec des sprints de 2 semaines) risque d’être très forte.
Avoir un plan de release comme ça, avec les incertitudes dans les prévisions, 3 sprints avant la fin de la release, c’est déjà pas mal.
Le plan de release peut être montré avec des incertitudes et des vagues. Les éléments qu’on y fait figurer sont tirés du backlog, on les trouve donc aussi dans les bacs.
Dans le cadre du management visuel, ces deux représentations sont utiles. Cependant il faut passer d’une l’une à l’autre, ne pourrait-on pas tout mettre dans une seule vue ?
Cela éviterait d’avoir à dupliquer les post-it…
On peut noter que le temps y est représenté différemment :
Après avoir unifié en une seule vue le backlog (et ses bacs) avec le plan de release, ajoutons-y les incertitudes.
Nous sommes dans le cadre d’une release dont la date de fin est fixée. Par exemple : elle se termine après 8 sprints, chacun de deux semaines. Nous sommes à la fin du 3ème sprint. On nous demande des prévisions sur ce qui sera fini pour cette release.
On pourrait faire des estimations et mesurer la vélocité.
Gymkhana, c’est une co-création avec Stéphane Langlois et c’est une aventure qui se poursuit.
Montpellier, un essai transformable Le premier coup de pied gymkhana a été donné à Montpellier. Il nous paraissait possible d’obtenir, en une seule journée, ce que nous n’avions pas réussi à construire en six mois d’incubation : collecter les besoins pour modéliser une première hypothèse de travail. Nous avions hâte de revenir à nos pratiques, et de commencer enfin la réalisation de Crise.
Une feature est un service, observable de l’extérieur, qui contribue à un impact, et dont la description se situe à un niveau tel que toutes les parties prenantes comprennent facilement ce dont il s’agit.
Côté développement, une feature peut se voir comme un ensemble de stories et qui a sa propre existence.
Un aspect fondamental du développement agile est de répondre à l’impact (et donc fournir de la valeur) en minimisant l’effort à faire pour développer la feature.
Il y a quelque temps, j’avais audité un projet dont le tableau de features, s’il avait été fait[1], aurait ressemblé à peu près à ça :
Tout un tas de features commencées, aucune de finie, même après des mois de sprints.
Avec cette vue, on voit bien que l’avancement peut être résumé très vite. Zéro. Rien de fini. Pas besoin de feuille de calcul.
Pourtant sur le projet, l’avancement n’était pas présenté comme ça : il y avait des stories de finies, une vélocité obtenue à chaque sprint.
Un tableau de features permet de montrer la décomposition du travail à faire et l’affectation aux différentes équipes dans le cadre d’un Scrum à grande échelle.
Dans le billet la vie d’une feature, j’ai présenté un tableau permettant de visualiser et suivre le développement des morceaux essentiels d’un produit.
Ce tableau de features reste unique quand le produit est gros et que plusieurs équipes y travaillent.
Qu’est-ce qui change dans ce tableau quand on passe à Scrum à l’échelle ?
L’affiche de Fabrice avec les explications de ce que c’est.
Cela se passe à Bordeaux, plus exactement Bazas sur la route de Bordeaux en venant de Toulouse.
Breaking news Cette année, Agile Games France accueille un peu plus de monde, environ 75 personnes. Les places se sont arrachées le jour d’ouverture en quelques heures. Cependant, des désistements de dernière minute laissent la possibilité à quelques joueurs d’y participer au dernier moment.
Le sous-titre de cette nouvelle saison de Rupture Douce est :
Libérons l’agilité !
On y trouve le témoignage de plusieurs entreprises libérées qui font partie du documentaire sur Le bonheur au travail passé hier sur Arte et visible pendant 60 jours.
Avec Gymkhana, co-créé avec Stéphane Langlois, notre objectif est aussi de libérer l’agilité, pour favoriser les idées citoyennes.
Vous trouverez l’histoire complète, celles des entreprises libérées et plein d’autres, dans Rupture Douce le livre.
