Scrum n'est pas une méthode de développement de logiciel

La semaine prochaine, c'est Agile tour Toulouse. Ma session Scrum ? mon scrotum ! a été retenue par les organisateurs. Après le Pays Basque et Rennes, ce sera ma dernière représentation.

Parmi les raisons qui conduisent au scrotum, il y a la peur. Celle qui pousse les développeurs à produire de la dette technique alors qu'ils savent bien que c'est mal.

Lire la suite...

Anars vs neocons

J'ai eu le plaisir de faire la keynote d'introduction d'Agile Pays Basque :

Scrum ? mon scrotum !

Sur Twitter, ce qui a été le plus cité de ma présentation, c'est "anars vs néocons", juste devant "le cycle en Vrum".

Voici un exemple[1] :

Je ne vais pas expliquer ici tout ce qui m'a amené à cette formulation[2], je le réserve d'abord à ceux qui viendront m'écouter à Rennes dans 2 semaines.

Sachez que le titre est important, je parle des influenceurs, et comme toute catégorisation, elle est réductrice.

Cependant, elle dénote d'une tendance, exprimée par exemple dans ce retour ô sources. Paradoxalement, elle n'a rien de passéiste, elle est ultramoderne. Bientôt en français.

Notes

[1] venant d'un Software Anarchist"

[2] Tiens, en 2010, j'avais publié un billet : Agilité et anarchie où j'évoquais en filigrane la possibilité qui s'incarne maintenant dans les "néocons".

Nouveau guide Scrum

Pendant les vacances, j'ai participé à la traduction du nouveau guide de référence de Scrum, les règles du jeu. Dans cette version de juillet 2016, la nouveauté est l'ajout du paragraphe Les valeurs Scrum.

Les 5 valeurs dont il est question ne sont pas nouvelles. J'en parlais dans un billet de 2013, intitulé Les valeurs de Scrum et elles figurent dans mon livre Chapitre 3 §3.1.2 Valeurs partagées.

Mais c'est la première fois qu'elles apparaissent dans le guide de référence. Avec les traducteurs agiles, nous avons profité de cette nouvelle version pour revoir le texte en entier. La quinzaine de pages, disponible sur le site en différents formats, est maintenant beaucoup plus facile à lire.

Une bonne préparation pour ma keynote à Agile Pays Basque : Scrum mon scrotum !

Ouverture d'Agile Pays Basque

J'aurai le plaisir de faire la présentation d'ouverture du premier Agile Pays Basque, à Bidart (presque sur la plage).

bidart.png

Lire la suite...

Contextualiser Scrum

Pour utiliser le cadre Scrum, il faut d’abord y insérer des pratiques complémentaires, variables selon le domaine, et adapter le tout au contexte.

Lire la suite...

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. Cela a d'abord été "Astérix et la grande échelle de Scrum" parce que j'utilisais le puzzle "Le village gaulois".

Finalement c'est "Puzzle grand Scrum".

Un atelier que j'ai animé une quinzaine de fois :

  • au cours des jeux agiles de l'IPI à Blagnac,
  • à Agile Games France 2015 à Bazas,
  • au ScrumDay 2015,
  • à Agile tour Montpellier,
  • à Agile tour Toulouse,
  • au cours des 4 derniers Raids Agiles (animation avec Pablo aux manettes pour les rétros),
  • dans 5-6 autres formations Scrum.

À raison de plus de 2 heures par session, cela m'a permis de collecter plein de comportements intéressants sur, par exemple, la notion d'équipe feature, le rôle de Product Owner, l'auto-organisation et le ScrumMaster, l'affinage multi-équipes, les démos et les rétrospectives, la définition de fini. Je vais en restituer quelques-uns, en commençant par la façon de prioriser.

Mais avant, et en rappelant que l'objectif de l'atelier est de simuler la réalisation d'un seul produit avec 3 équipes, une réaction émerge parfois, et c'était en particulier le cas lors du dernier Raid, qui est : "ce serait plus facile avec une seule équipe". C'est probablement vrai pour le puzzle, mais c'est aussi une question légitime pour du développement de logiciel. Le passage à l'échelle complique les choses et il vaut mieux l'éviter chaque fois que c'est possible.

Ceci étant dit, voyons ce que donne le jeu avec 3 équipes, sur la question : par quoi commencer le puzzle ?

Par le cadre

L'envie de commencer le puzzle par le cadre arrive fréquemment, c'est comme cela que cela se fait d'habitude pour un puzzle. L'exercice pousse à changer cette habitude (le cadre n'a pas de valeur métier, on ne fera pas tout le puzzle et j'insiste sur cela) et certains ont du mal. Cela provoque des discussions avec le PO sur la priorité à donner. Parfois les partisans du cadre l'emportent (pas bien loin, car le cadre ne survit pas à la première démo).

Je rappelle que je fournis au début du jeu une liste de 20 stories (ou features, peu importe ici) et pour chacune la valeur métier que je lui donne. Dans cette liste, il n'y a pas de cadre, qui nécessiterait pour être réalisé plusieurs stories, toutes de faible valeur.

Par le tri

Il est arrivé que le backlog soit enrichi de nouvelles cartes genre tri des pièces. C'est assez rare ; en général, cela vient dans la conversation mais n'est pas accepté par les partisans de la valeur métier.

Une story "tri" n'apporte pas de valeur métier, mais on peut considérer qu'elle apporte de la valeur à l'équipe. Cela correspond à une story technique.

Il est probable que si je ne fournissais pas une liste prédéfinie, il y aurait plusieurs stories techniques de ce genre dans le premier sprint.

Par un personnage

La logique utilitariste voudrait que ce soit Astérix qui soit fait en premier, puisque c'est le personnage qui a le plus de valeur. Dans l'atelier, on ne fait pas d'estimation de la taille des personnages (ni de l'effort pour les réaliser), mais c'est assez facile à imaginer avec la surface que prend ce personnage dans l'image du puzzle. Même en utilisant le ratio valeur / taille, c'est toujours Astérix qui semble prioritaire. La différence avec Obélix est flagrante, qui rapporte moins de valeur et qui est plus gros enveloppé.

Pourtant, ce n'est pas toujours Astérix qui est choisi en premier. Par exemple, lors du Raid Agile #5, Richard, qui était le PO, a demandé Bonnemine en premier. Pour lui, c'était mieux de commencer comme ça. Richard n'est pas utilitariste, il a fait parler son cœur (à la démo du premier sprint, il a un feedback rude des parties prenantes).

tableau du puzzle au début

Pendant le jeu, tout cela provoque des conversations et c'est le but. La façon dont est prise la décision sur la priorité, dépend finalement du ou des PO (j'ai essayé le jeu avec différentes configurations), c'est un sujet sur lequel je reviendrai.

Dans un prochain article, je parlerai aussi de la définition de fini. Astérix fini, est-ce bien clair pour tout le monde ce que cela signifie ?

Note

[1] notion qui est présentée en détail dans mon livre, chapitres 7 et 8

Accompagnement Scrum

Il y a des coachs agiles qui sont à plein temps chez leur client. Parfois même, ce sont des armées de coachs à plein temps qui restent pendant une longue période au sein d'une organisation.
Je suppose que c’est pour des transformations agiles aussi massives que délicates.

Ce n’est pas la forme d’accompagnement que je pratique. En général, j’accompagne mes clients de façon discontinue et sur une période limitée.

Un bon exemple de ce que je fais, bien que ce ne soit jamais pareil, a été montré dans le retour d’expérience d’Intel à Agile tour Toulouse (il avait aussi été présenté au ScrumDay à Paris en avril).

Chronologie accompagnement Intel

Voici la chronologie du Scrum chez Intel Toulouse, service Telephony, dans la bonne humeur, telle que présentée par Christophe et Cyril.

Dans cette histoire de transformation du service, j’étais le « coach agile », voici les faits saillants de mon intervention.

Cadrage

Une question essentielle est comment démarrer. Dans ce cas d’organisation par silo d'activités, il s’agissait de se mettre d’accord entre le sponsor et ses managers sur l’opportunité de constituer une équipe pluridisciplinaire, en connaissant les implications de Scrum. Comme le contexte est plutôt difficile, un pilote a été lancé assez longtemps après la séance de cadrage que j’ai prodiguée.

Formation initiale

J’ai d’abord donné une formation (on the job training) qui consiste à prendre l’équipe Scrum juste constituée à cette occasion et son vrai projet et à appliquer Scrum dessus. On démarre le sprint zéro ensemble lors de cette formation (4 jours). On pratique sur l’essentiel. On constitue le backlog initial, on prépare le premier sprint. Ensuite ils continuent tout seuls.

Accompagnement d’équipes

Ensuite, j’ai accompagné cette équipe, plutôt légèrement, en participant à des événements de leur sprint : affinage (ils disaient grooming), mêlée, revue, rétro. Légèrement mais suffisamment, parce que l’équipe se débrouillait bien toute seule. Quelques mois plus tard, une deuxième équipe a démarré. Une équipe que j’ai formée de la même façon. Mais une plus difficile à faire adhérer au cadre Scrum. J’aurais dû, je pense, les accompagner plus que ce que je n’ai fait.

Évaluation

Finalement je suis revenu pour une évaluation de ces 2 équipes. J’ai fait cela en interviewant individuellement des membres des équipes, ainsi qu’en animant une rétrospective pour chaque équipe. Le résultat de mon évaluation a permis de mieux aligner les 2 équipes et le management. Un exemple qui me revient est sur l’usage de la vélocité : les équipes avaient le sentiment que le management mettait la pression sur la vélocité, alors que le management voulait juste avoir de la visibilité. Ma restitution les a orientés vers un engagement sur l'objectif de sprint.

Accompagnement de l’organisation

Finalement, un déploiement plus général, de type scrum de scrums, s’est opéré mais sans que j’intervienne pour lancer l’initiative.

J'ai peut-être eu un impact quand même, car l’envoi de 5 personnes du service au premier Raid Agile a sûrement contribué à renforcer le mouvement.

Je suis revenu pour accompagner cette transformation incluant tout le service, avec des actions ciblées sur : la mise en place de Kanban avec l’équipe pour laquelle c’était adapté, des compléments avancés pour les PO, des séances de travail avec le staff sur des sujets comme la planification de release et l’impact mapping et la consolidation de l’approche globale.

En tout, cela a représenté un peu plus d’une vingtaine de jours sur presque 2 ans.

Agile scaling avec bonne humeur

Scrum se diffuse inexorablement dans le domaine industriel, sur des programmes ou produits impliquant plusieurs équipes. Il m'arrive de plus en plus souvent d'être appelé pour du scaling Scrum. J'interviens actuellement pour accompagner des programmes spatiaux d'envergure qui ont fait le choix du développement agile.

Les toulousains intéressés par le sujet seront les bienvenus demain à Agile tour Toulouse, dont le thème cette année est le bonheur au travail.

Affiche Agile tour Toulouse 2015

Voici deux sessions qui parleront de Scrum à plusieurs équipes (en restant dans le thème du bonheur) :

  • celle présentée par Intel, service Telephony qui s'appelle Le Scrum chez Intel : retour d’expérience dans la bonne humeur. Il y est question de "SoS", autrement dit Scrum of Scrums. Nous avions présenté cette session au ScrumDay 2015 à trois sur 50 minutes. Cette fois, ce sera plus court, actualisé et avec un débat à la fin.
  • l'atelier Puzzle grand Scrum que j'animerai en début d'après-midi. Une façon ludique de découvrir la façon de s'organiser à plusieurs équipes. Je l'ai donné de nombreuses fois, au ScrumDay aussi, au cours des Raids Agiles, et récemment à Agile tour Montpellier.

Scrum n’est pas une marque

Heureusement ! Mais il en a été question, c’est fou.

Lire la suite...

Scrum est un cadre de processus

Dans l’article initial de 1996, Ken Schwaber parlait volontiers de processus et de méthodologie. Ensuite, Scrum a été souvent qualifié de méthode (agile).

Cette difficulté à classer Scrum a continué un certain temps.

Puis Ken Schwaber et Jeff Sutherland, l’autre co-fondateur, ont défini Scrum comme un cadre de processus (process framework).

Scrum n’est pas un processus complet -et encore moins une méthodologie, c’est un cadre de processus.

Un processus définit une façon de travailler, un cadre de processus se contente de délimiter, de « cadrer ».

Le cadre Scrum est léger, n’imposant que peu de choses :

  • les sprints et leurs événements,
  • une équipe avec 3 rôles,
  • un backlog contenant le travail à faire.

- page 1 de 3