scalabilité

L'agilité à grande échelle

L'agilité à grande échelle

Il faut un vrai besoin pour changer d’échelle. Dessin de Patrice Courtiade et légende extraits de Scrum, le guide etc. page 278 Sur Twitter, David, après avoir publié son organigramme d’une organisation agile ajoute : Très influencé par SAFe, qui reste à ce jour la seule proposition de modèle global d’entreprise David est provocateur… ou sort d’hibernation. Ou il est peut-être tombé sous l’influence de ceux que j’appelle les néocons dans Scrum mon scrotum.

Développer un produit avec plusieurs équipes Scrum

C’est le titre du 21e chapitre de la 4e édition de mon livre Scrum. Cette dernière édition, sortie il y a un an, marche bien ; alors peut-être que quelques lecteurs sont arrivés jusqu’à ce chapitre… Je m’adresse à eux, qui ont lu ce chapitre, sur lequel j’aimerais bien avoir du feedback, car je l’ai réécrit presque entièrement, avec un positionnement de type “retour ô sources”, pour reprendre le thème d’Agile tour Toulouse cette année.

Lecture au klub : Lean Entreprise

Le livre choisi pour le klub d’octobre était donc : Lean Enterprise: How High Performance Organizations Innovate at Scale de Jez Humble, Joanne Molesky, Barry O’Reilly. Un gros livre. En anglais, ce qui n’a pas attiré les foules. Mais, bien que je fusse le seul à l’avoir lu entièrement (et sur mon smartphone !), la discussion s’est avérée passionnante. Un livre qui présente plein de choses, certaines dont je parle régulièrement sur ce blog et dans mon livre (le développement agile, impact mapping, lean startup, kanban) et d’autres un peu moins (design thinking, value stream mapping, devops).
Scrum éparpillé façon puzzle

Scrum éparpillé façon puzzle

En 2014, j’avais essayé un jeu de simulation de Scrum, avec un puzzle ; il mettait l’accent sur l’affinage et la présentation du backlog en bacs[1], c’était donc le jeu des bacs. Début 2015, j’avais expérimenté une variante pour simuler du Scrum à plusieurs équipes. Cette variante a reçu un très bon accueil, ce qui fait que je l’ai animée de nombreuses fois. J’ai eu du mal à lui trouver un nom.

Taille et stabilité d'une équipe Scrum

On a vaincu la loi de Brooks. Pour justifier qu’une équipe Scrum doit rester de taille raisonnable et surtout stable dans le temps, j’invoque souvent Tuckman et Brooks. Le modèle de Tuckman présente les phases dans la construction d’une équipe. Il sous-entend une certaine stabilité pour que l’équipe puisse progresser. En formation, il m’arrive de demander à des managers qu’est-ce qu’ils feraient si, à quelques semaines de la livraison, ils s’apercevaient que leur projet avait du retard.
Scrum en grand : LeSS, SSwS, Nexus et le rôle de Product Owner

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

« Développer un produit avec plusieurs équipes » 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. Ken Schwaber vient de publier le guide Nexus, son framework de Scrum à grande échelle. Un de plus ! Cela en fait trois, au moins, qui se revendiquent de l’esprit Scrum : Nexus, SSwS et LeSS.

Passer à l'échelle avec Scrum

Workshop le 2 juin à Toulouse. 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 4ème édition de mon livre Scrum, le guide de la méthode agile la plus populaire.
Tableau de features à grande échelle

Tableau de features à grande échelle

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 ?

Astérix et la grande échelle en Scrum façon LeSS

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.

Chapitre dix-neuf

Le chapitre 19 de mon livre s’appelle “Scrum à grande échelle”. C’est un sujet délicat. 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é.

La présentation AgilEuclid au ScrumDay

Voici le support de la session « Expérimentation de l’Agilité pour un grand projet scientifique spatial » présentée à 3, avec Maurice Poncet (Cnes) et Laurent Meurisse au ScrumDay 2013[1]. L’objectif de la mission Euclid est de cartographier la géométrie de la matière noire et de l’énergie sombre. Euclid est un projet, sous l’égide de l’ESA, dont les instruments et le segment sol scientifique sont réalisés par un consortium européen regroupant les principales agences spatiales nationales et laboratoires scientifiques, dont le Cnes.
La matière noire au ScrumDay

La matière noire au ScrumDay

Jeudi prochain le 11, au ScrumDay, je participerai à la présentation de l’expérimentation de l’Agilité pour un grand projet scientifique spatial. Nous ferons la présentation à trois, avec Maurice Poncet, du CNES, et Laurent Meurisse. Il manquera le quatrième mousquetaire, Nicolas Deverge. Car nous faisons l’étude à trois consultants /coachs agiles. L’objectif de la mission Euclid est de cartographier la géométrie de la matière noire et de l’énergie sombre. Euclid est un projet, sous l’égide de l’ESA, dont les instruments et le segment sol scientifique sont réalisés par un consortium européen regroupant les principales agences spatiales nationales et laboratoires scientifiques, dont le CNES.

Quiz agile, retour sur les questions 13 à 15

Les 3 dernières questions des 15 du quiz placé à la fin de mon livre Scrum. A propos de quiz, il y en aura un qui sera proposé à la fin de la formation Kanban du 24 octobre, comme dans mes formations Scrum, en plus court. Indicateurs La question était la suivante : Au milieu du sprint, le burndown chart de sprint remonte. Vous êtes ScrumMaster, que faire ?

Lean depuis les tranchées, le draft en VF

Piloter de gros projets avec Kanban, l’histoire de la police suédoise. Henrik Kniberg a publié Lean from the trenches chez The Pragmatic Programmers en fin d’année 2011. Il l’a écrit de façon itérative et a sorti plusieurs versions intermédiaires. C’est une de ces versions, le draft 0.9, que nous avons traduite. Bien sûr, c’est avec l’accord d’Henrik : Cette version draft est gratuite. Je l’ai rendue disponible pour ceux qui ont un budget serré et qui ne peuvent pas s’offrir le livre, ou qui souhaitent parcourir le draft pour se faire une idée générale de la portée du livre avant de l’acheter.

Quizz, la dernière question

La question était : 3 équipes Scrum participent au développement d’un seul produit, chacune s’occupant d’un ensemble de features. Comment gérer la signification de fini ? Je proposais les réponses suivantes : Une seule définition de fini pour tout le monde Pas besoin, on en parle au scrum de scrums Chaque équipe a la sienne et la communique aux autres C’est le Product Owner qui décide Nous sommes dans une situation de Scrum en multi-équipes, ce qu’on appelle souvent le scrum de scrums.

L'Agilité des pompiers

… avec leur grande échelle. J’ai participé aux étapes toulousaines et bordelaises de l’Agile tour. Pour en savoir plus sur ce qui s’est passé dans ces belles conférences du Sud-Ouest qui ont attiré la grande foule, le point d’entrée que je vous recommande est Agilarium, le roi de la rétrospective (et du Sky Castle Game) : Toulouse le 19 Bordeaux le 21 Dans les 2 villes, j’étais invité à présenter l’Agilité à grande échelle.

Agilité à grande échelle

Lors du premier ScrumDay fin mars à Paris, j’avais présenté Scrum au-delà du projet, pour des produits et des organisations. En juin, pour la deuxième édition de mon livre, j’ai écrit un nouveau chapitre qui reprenait et approfondissait les idées présentées. Pour faire plus court, je l’ai appelé Scrum à grande échelle, c’est le chapitre 19. Demain à Toulouse, vendredi à Bordeaux, je suis au programme des tours (détours ?) agiles pour raconter la suite, c’est la session “Agilité à grande échelle”.

Des chaussures aux étoiles

Agile dans tous les domaines. En tant que consultant, j’ai la chance de travailler dans des domaines variés. Après avoir accompagné Sarenza.com dans sa transition radicale et à grande échelle à Scrum[1], j’interviens sur le projet Sirius du CNES avec Thalès. Il s’agit de développer le patrimoine de base de la dynamique du vol, sur lequel viendront se construire les futurs outils opérationnels pour les mises à poste et maintien à poste de satellites.
Scrum avec plusieurs équipes

Scrum avec plusieurs équipes

Vous avez plusieurs équipes qui font du Scrum et vous voulez garder une vue générale, plutôt que d’avoir des projets séparés. Voilà une façon simple de faire du “scrum de scrums”. Equipes et Features Constituez les équipes et associez à chacune une couleur. Identifiez les features, éventuellement à partir d’une vision. Rangez-les par priorité. Montrez quelle équipe va réaliser la feature en lui donnant sa couleur. Le “backlog” de features donne un aperçu du partage entre les équipes à haut niveau :
Les échelles de l'agilité

Les échelles de l'agilité

La scalabilité des méthodes agiles, c’est leur aptitude à s’appliquer, tout en restant efficaces, quand la taille des projets et des équipes grandit. Mercredi matin je présentais l’agilité à grande échelle. Devant une trentaine de personnes chez IBM Toulouse, j’ai montré comment on pouvait appliquer l’agilité sur de gros projets avec plusieurs équipes, sur des projets qui s’enchainent pour faire vivre un produit, sur des programmes, des lignes et des portefeuilles de produit.