2015, agilité et produit - Scrum, Agilité & rock'n roll

Le but du chapitre est présenté dans l’introduction : On peut distinguer trois niveaux pour la prise en compte de l’agilité dans des organisations : projet, produits, organisation. Beaucoup d’expériences actuelles avec Scrum restent au niveau projet. Nous allons approfondir les niveaux produits et organisation. J’ai évoqué, dans le chapitre 18, Transition à Scrum, la façon dont une entreprise gérait le changement vers l’agilité. Ici, il s’agit d’aborder le changement d’échelle dans ce qu’il implique sur la mécanique de mise en œuvre de Scrum, en termes d’é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. Au lycée, quand j’étais étudiant, à l’armée (en cachette le plus souvent) et quand j’ai commencé à travailler. J’attendais le jeudi avec impatience[2]

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…

La lecture, pour garder l’esprit critique. !–more–> 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.

En 2015, je vais continuer et amplifier les coopérations, avec d’autres consultants ou des petites entités agiles et sympathiques.

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 :

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à. Quelques exemples récents.

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.

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 l’édition 2 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.

Incertitudes et planification par vagues

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.

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é. Mais nous allons suivre une approche de prévision sans estimations.

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.

Finir une story c’est bien, finir une feature c’est mieux

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.

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.

Session d’affinage et affectation des features

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.

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.

J’ai été enchanté de retrouver des camarades de jeu, d’en découvrir de nouveaux et d’essayer des nouveaux jeux. Voici quelques-uns de mes moments choisis pendant ces 2 jours.

Techniques de prise de décision : expériences

Au cours Agile Games France 2015, Kervin nous a proposé un atelier sur le consentement systémique, une façon de décider en groupe basée sur les objections de chacun.

Après la châtaigne, le gland à l'honneur au Raid Agile

Voici la rétroglandouille.

Former, entraîner, coacher, des activités qui se recoupent.

De retour du 2e Raid, et encore sous l’effet des beaux moments passés, j’ai envie de faire de la pub pour les deux suivants. Ça fait plus de 25 ans que je fais des formations et si je continue encore, c’est parce que des moments comme ces 3 jours de Raid me procurent beaucoup de plaisir. Pour les participants aussi, je pense que le Raid Agile est une source d’apprentissage absolument exceptionnelle, que cela leur apporte beaucoup de valeur. Et d’ailleurs, ils le disent :

Cette rétrospective cherche à garder un rythme soutenable pour l’équipe. Elle s’intéresse au 8ème principe du Manifeste, souvent oublié, qui commence ainsi : Agile processes promote sustainable development.

J’ai passé une bonne partie des ces dernières années à réfléchir à l’utilisation de Scrum sur des gros projets et à mettre en place ce passage à grande échelle pour des organisations. Les enseignements que j’en ai tirés, j’ai commencé à en parler sur ce blog et ils pourraient être présentés, qui sait, dans une 4e édition de mon livre Scrum, le guide de la méthode agile la plus populaire. Par ailleurs je viens d’animer avec succès un atelier pour simuler l’organisation de plusieurs équipes qui collaborent à un même produit.

Parmi les raisons évoquées par ceux qui disent : on arrête Scrum pour passer au flux certaines m’apparaissent très discutables : les réunions prennent trop de temps, le sprint est un carcan qui met la pression sur les équipes, on déploie à un rythme différent du sprint, alors pourquoi le garder ?

Comme tous les ans depuis 2011, aura lieu début avril le ScrumDay, le grand rendez-vous de la communauté Scrum. Et comme tous les ans, j’y participerai, c’est toujours l’occasion de rencontres et un grand moment de partage. Le thème est cette année “ScrumCorp au-delà des équipes”. Un thème qui sera repris dans les keynotes, avec Mary Poppendieck et Dave Snowden, des grands noms de l’Agilité et pas spécialement de Scrum, ce qui montre bien l’ouverture de la conférence.

Le rythme fonctionne selon 3 cycles dans Scrum : celui de la mêlée quotidienne, tous les jours donc, celui du sprint, selon sa durée, celui de la saison, si elle est aussi cadencée avec une durée constante (en général 3 mois).

Cinquième extrait de Gymkhana, construire ensemble et autrement des idées citoyennes, histoire écrite à deux mains avec Stéphane Langlois, publiée dans Rupture Douce 3, libérons l’Agilité.

Et si je continue encore, c’est parce que je constate toujours des impacts positifs. En voici quelques-uns :

La troisième édition avait été publiée le 19 juin 2013. Ce qui fait que j’avais travaillé dessus fin 2012 et début 2013. J’avais annoncé le lancement de cette édition 3, ici même, le 9 octobre 2012. Cela fait donc plus de deux ans. Il s’en est passé des choses depuis. Alors quand mon éditeur m’a dit qu’il serait bien de songer à une nouvelle édition et m’a demandé si j’avais des changements à apporter, je lui ai dit que oui, j’avais quelques idées de nouveautés.

Le roman de Peetic dans Scrum 4 et au Raid 3

Dans la 3ème édition de mon livre, à la demande générale, j’avais ajouté un peu plus d’exemples. Pour qu’ils soient cohérents, j’avais pris un fil rouge. Ce fil c’est Peetic.

Samedi le facteur m’a apporté le Dictionnaire amoureux du rugby de Daniel Herrero. La version illustrée qui vient de sortir. Je ne sais pas qui me l’a envoyée, je n’ai pas trouvé de carte dans le paquet. Je remercie très chaleureusement le bienfaiteur anonyme qui m’a fait ce beau cadeau. Le rugby, cela faisait un bout de temps que je n’en avais pas parlé sur ce blog. Ce livre m’en donne l’occasion.

J’ai commence à écrire quelques chapitres pour la nouvelle édition de mon livre. Je donne une grande importance aux mots employés et je n’hésite pas à changer entre deux éditions avec le feedback des lecteurs ou le changement dans les usages. Par exemple, j’employais dans l’édition 3 “la culture du backlog”. Pour l’édition 4, comme les lecteurs de mon blog s’en doutent depuis ce billet, je passe à “l’affinage du backlog”. Pour d’autres expressions, j’hésite encore.

Dans son article initial de 1996, Ken Schwaber parlait volontiers de processus et de méthodologie. Plus tard Scrum a été souvent qualifié de méthode (agile). Cette difficulté à classer Scrum a continué un certain temps.

Une majorité — relative — d’entre vous effectue des sprints de 2 semaines. Voilà ce que ça donne, en comparaison avec les deux précédents sondages sur le même sujet :

C’est le cas de INVEST, lancé en 2003 par Bill Wake. Cela fait donc 12 ans et INVEST est encore populaire ; des ouvrages récents y font toujours référence (je pense à No Estimates).

Dans « Extreme Programming Installed », Ron Jeffries, en 2001, définit la vie de la story avec trois phases : la carte comme moyen de l’identifier, puis une conversation et enfin une confirmation. Cela est connu comme les « 3C ».

Voici le résultat du sondage, auquel plus de 100 personnes ont répondu. La question était : “Votre équipe Scrum est ?”, avec 5 réponses possibles.

J’ai le plaisir d’accueillir un invité qui va nous parler du Lean Startup. C’est seulement la deuxième fois que mon blog publie un billet que je n’écris pas moi-même. Le premier était de Bruno, qui est devenu célèbre depuis. Mon deuxième invité est Nicolas Deverge, créateur de TeamMood. À l’instar de Scrum, le Lean Startup est très simple à comprendre. Ce n’est que du bon sens, mais exactement ce que l’on ne fait pas traditionnellement.

Dans la famille des cupulifères, après la châtaigne, à l’honneur au Raid#1, après le gland au Raid#2, c’était le tour de la noisette pour le Raid#3 de fin juin.

Sticky notes collectées lors de la rétrochâtaigne du Raid Agile #3 en Cévennes. Il y a quelques semaines, j’ai reçu un courrier (une lettre recommandée avec accusé de réception, quand même) des avocats de la société 3M, pour me dire que j’avais un usage inapproprié de la marque de leur client sur mon site.

En écho à mon billet “sticky notes” sur la tyrannie des marques, j’avais lu avec stupéfaction, il y a un mois, le billet alarmant de Ken Schwaber.

À la rentrée, traditionnellement, on nous demandait d’écrire nos souvenirs de vacances. Je m’y colle, mais pour moi, ce ne sera pas sur les vacances (quoique…). Je vais vous raconter un peu du dernier Raid Agile.

Sixième extrait de Gymkhana, construire ensemble et autrement des idées citoyennes, histoire écrite à deux mains avec Stéphane Langlois, publiée dans Rupture Douce 3, libérons l’Agilité.

Scrum en grand : LeSS, SSwS, Nexus et le rôle de Product Owner

Développer un produit avec plusieurs équipes C’est le titre du 21ème chapitre de mon livre Scrum, édition 4. Quand plusieurs équipes travaillent sur le même produit, un point délicat est la mise à l’échelle du rôle de Product Owner ainsi que l’affinage à haut niveau.

J’ai reçu de chez Lulu mon exemplaire de Xanpan. J’ai commencé à le lire, pour le prochain klub de lecture qui aura lieu le 7 septembre.

Je rebondis sur le billet de Laurent Morisseau “Kanban contre le flux continu” pour dire, avec lui, que Scrum et Kanban peuvent cohabiter. C’est le sujet de ce nouveau chapitre. En introduction du chapitre, je donne les impacts souhaités sur les rôles Scrum, qui rencontrent des problèmes dans certaines situations.