Le but du chapitre 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.
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…
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.
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.
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.
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.
Il y a quelque temps, j’avais audité un projet dont le tableau de features, s’il avait été fait], aurait ressemblé à peu près au schéma (il y avait à la place un gros tableau excel avec des calculs précis —mais faux— d’avancement donnant des % de finition par feature.)
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.
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.
Le passage à grande échelle avec des features teams demande une prise de décision supplémentaire : le choix de l’équipe qui va réaliser une feature.
Comme pour les travaux d’affinage sur les stories, il est souhaitable que cela se fasse autour de conversations, mais impliquant cette fois toutes les équipes.
C’est l’objet des sessions d’affinage et d’affectation des features.
Pour un Scrum à plusieurs équipes, le tableau des features permet de montrer quelle équipe va travailler sur quelle feature.
Avec Pablo, nous préparons cette semaine le Raid Agile #2 qui commencera mardi prochain.
En novembre, après le succès du Raid #1, j’avais annoncé le deuxième en mars en faisant l’hypothèse qu’il serait rempli.
Hypothèse validée, ce Raid #2 est complet depuis quelque temps déjà.
Voyant que cette formule intéressait du monde, nous avons lancé un Raid #3 en juin toujours en Cévennes et même un Raid Agile au Québec en automne.
