ScrumBeer d’Avril

La ScrumBeer, c’est un peu le freestyle du Scrum User Group. Petit rappel subliminal sur notre dernier rassemblement Parisien afin d’envoyer un signal subliminal pour la rentrée !

Agilité et formule 1

Une ScrumBeer apporte souvent son lot de discussion surprenante. Ces soir-là j’ai eu l’opportunité d’apprendre des choses passionnantes sur Renault F1.

image

Car un motoriste de Formule 1 doit faire face aux mêmes défis qu’une équipe agile. Elle cherche la performance encore et toujours. Cette saison encore, Renault F1 fait face à des difficultés, son bloc propulseur concède pas mal de puissance par rapport aux champions en titre (Mercedes) et même par rapport à Ferrari qui a mieux progressé durant l’hivers.

Ce n’est visiblement pas l’équipe d’ingénieur qui en est la cause : elle est hautement qualifiée et n’a pas à rougir face à ses compétiteurs. Seulement la nouvelle règlementation qui est dans sa seconde année a donné naissance a de nouveaux groupes propulseurs très complexes où tout est à apprendre.

Renault F1 a abordé cette nouvelle ère en continuité de la période précédente, qui fut une relativement longue période de stabilité avec des moteurs classiques. Renault faisait alors appel à des sous-traitants spécialisés pour produire nombre de composants du moteur. Le manufacturier Français a misé sur un travail de conception très élaboré en amont et une planification précise des fournitures par les sous-traitants passant par un service achats.

Mercedes pour sa part fabrique elle-même la quasi-totalité de ses composants. La marque Allemande s’est ainsi donné les moyens d’expérimenter et d’itérer très rapidement, bref d’être très performant sur son cycle d’apprentissage.

Un nouvel exemple que face à un territoire méconnu, optimiser l’acquisition de connaissance est plus performant qu’optimiser la production (surtout quand celle-ci est principalement handicapé par le processus d’achats).

image

Il y a eu un peu de mouvement au French SUG, j’espère toutefois que l’on pourra perpétuer la tradition de la ScrumBeer. Comme vous le voyez, on y apprend des choses…

ScrumDay 2015 : Scaling Dilemna, par Mary Poppendieck

Quand nous étions petits, nous étions fantastiques ! Maintenant que nous sommes plus gros … nous avons cessé d’être fantastiques. En fait, on ne communique plus aussi bien.

Quels sont les problèmes ?

  • La coopération
  • La complexité
  • L’état d’esprit
  • Le focus

Ce sont ces 4 points que Mary Poppendieck va développer dans sa keynote de ce second jour du ScrumDay.

Coopération

Quand l’entreprise grandit, on tend à l’organiser en silo. Et ça ne marche pas si bien que ça ! On peut prendre le problème dans l’autre sens, et mettre les fonctions (ou les fonctionnalités) en silo. Ce n’est guère mieux.

Bref, nous sommes plutôt doués pour fabriquer des silos, mais médiocre à franchir les franchir ! Ce que l’on cherche avec ces silos, c’est l’autonomie. Et elle apparait alors plus importante que la coopération. Coopération et autonomie apparaissent antinomiques : lorsque l’on travaille sur quelque chose de gros, on perd de l’autonomie. Si nous privilégions l’autonomie, la coopération est le facteur clé pour aborder la complexité, comme Yves Morieux le souligne dans sa conférence TED

Mary Poppendieck nous emmène vers les communautés auto-organisées et vers Elinor Ostrom qui identifie 8 règles de gouvernance des biens communs :

  • Définir une limite du groupe claire
  • Faire coïncider les règles gouvernant l’usage du bien commun avec les besoins et les conditions locales.
  • S’assurer que ceux qui sont affectés par les règles peuvent participer à la modification de ces règles.
  • S’assurer que le droit d’édicter des règles des membres de la communauté est respecté des autorités extérieures.
  • Développer un système, porté par les membres de la communauté, permettant de surveiller le comportement des membres.
  • Faire usage de sanctions graduées envers les violateurs de ces règles.
  • Donner accès à des moyens de résolution de problèmes à faible coût.
  • Une gouvernance à multiples niveaux.

Quelle taille de groupe est la plus pertinente ? C’est au nombre de Dunbar qu’évoque l’oratrice, celui évoqué dans le Tribal Leadership, et ses variantes :

  • Le cercle d’intimité : 3 à 5 personnes
  • Le groupe de sympathie : 7 à 10 personnes ; c’est la taille d’un groupe pouvant accomplir « quelque chose ».
  • Le groupe de chasse : de 30 à 70 personnes ; c’est la taille nécessaire pour construire un sous-système indépendant et indépendemment.
  • Le clan : de 100 à 150 personnes ; C’est la taille d’une compagnie, dans les organisations militaires.
image

Complexité

Pour aborder la question de la complexité, Mary Poppendieck nous parle de micro-services, en évoquant le livre de Sam Newman (que je n’ai pas encore lu).

Les micro-services fractionnent les ensembles complexes en petits systèmes indépendants (jusqu’à la base de données) qui ne font qu’une seule chose, mais bien. « small » est bien le mot d’ordre pour les micro-services :

  • Petit services qui font une seule chose, mais bien. Nous l’avons dit.
  • Petites équipes, capables de prendre en main un service, depuis la compréhension du besoin avec les équipes métiers, jusqu’au suivi en production, en passant bien évidemment par la construction et le déploiement. qui s’effectue indépendamment des autres briques du SI.
  • Petites itérations et petit coût de démarrage: de zéro à une première étape en 3 semaines !

L’aptitude à réaliser des microservices a des corolaires.

  • Pas de couplage avec les autres briques du SI (nous l’avons évoqué).
  • Automatisation extensive des opérations : tests, intégration, déploiement.
  • « canary release » qui permet de pré-tester le système en situation réelle.
  • Continuous delivery et aptitude a être toujours « prêt au déploiement ».
  • Equipes pluridisciplinaires.

Etat d’esprit

Le focus sur le projet a fait son temps ! Place au focus sur le produit !

Vous êtes focalisés sur « le métier » ? Ce n’est même pas un concept … et pendant ce temps on laisse filer le focus sur le client… Il faut changer de regard.

  • Passer du focus métier au focus client
  • Passer du gestionnaire de projet à l’entrepreneur leader.
  • Migrer du développement qui execute les commandes à une équipe proposant des réponses.
  • Ne plus faire des choix sur les planning, mais sur les marchés.
  • Abandonner la mentalité « centre de coût » pour un état d’esprit « centre de produit ».

Dans son livre Inspired, Marty Cagan localise la création de grands produits à l’intersection de la valeur, de l’utilisabilité et de la faisabilité ! Pour donner vie à cette vision, il faut 3 personnes d’agal statut, l’un d’entre-eux est le « product manager », qui n’est pas un Product Owner : son rôle n’est pas d’écrire des User Stories ou de concevoir la solution, mais d’être un canal direct avec le client.

Focus

C’est se focaliser sur les bonnes questions. Et comme l’a popularisé Simon Sinek, cela commence par « pourquoi ? ».

La bonne question n’est plus « comment maximiser la valeur » ? » mais « comment maximiser l’impact » et trouver les métriques qui nous montreront que nous allons dans la bonne direction. C’est l’essence même du Lean Startup.

Dave Snowden au Scrumday 2015 : Making Sense through Action

Faire une bonne transcription de la keynote de l’auteur du modèle Cynefin n’est pas chose facile. Je ne pense pas y parvenir. Son accent n’est pas évident, pour commencer. Ensuite, suivre son propos s’est souvent avéré pour moi difficile. Je vais donc plutôt passer en mode « morceaux choisis ».

Adopter l’approche scientifique

Dave Snowden nous met en garde contre l’approche par l’exemple: on ne saurait proclamer une réussite basée sur un nombre limité de succès. En fait, la théorie s’avère alors un meilleur fondement que la technique.

image

Des entreprises montrent des succès spectaculaires en faisant des choses différentes, mais il est illusoire de chercher à les copier

All the path up are different, all the path down are the same

Le modèle Cynefin

C’est ce pourquoi Dave Snowden est connu. Il était normal que son auteur nous l’évoque. L’ayant déjà évoqué dans ce blog, je n’y reviendrais pourtant pas. Le billet de Nicolas Lochet développe très bien ce sujet également (de manière plus approfondie que moi pour être franc).

Mais le modèle Cynefin n’est pas statique mais dynamique. C’est pour décrire les transitions entre les états qu’il a été créé. Scrum transite ainsi entre « complexe » et « compliqué », il maintient même une cadence entre ces deux états. A la longue, il peut même revenir vers « évident » !

Simple or simplistic

Répéter les recettes est attrayant. Mais Snowden nous met en garde contre celles-ci. Et en particulier sur 3 effets :

Le « novelty effect » : Ce n’est pas parce qu’une approche est populaire qu’elle est bonne. Ce disant, Snowden vise SAFe sans aucun détour.

Le « cobra effect » : Il faut se méfier des solutions simples. Vous pensez à récompenser la correction de bugs ? Méditez sur cette histoire : Le gouvernement Britanique voulait réduire le nombre de Cobras pullulant certaines régions et a donc proposé des primes pour la capture des cobras. En retour, les paysans ont commencé a élever les cobras pour pouvoir toucher les primes…

Le « butterfly effect » : Ce n’est pas parce que quelque chose a marché une fois qu’elle continuera a marcher plus tard…

L’ethnographie scalable

Bien sûr, la scalabilité, c’était le thème de ce ScrumDay. L’ethnographie scalable, c’est le modèle que nous propose Dave Snowden. Hélas, je n’ai pas compris grand chose au propos, le point d’orgue étant le « human metadata ». C’est un peu trop pour moi. Je vous livre toutefois une pensée que j’aime bien :

Scale, not by aggregation, but by redistribution.

C’est une autre façon de dire que l’agile à l’échelle tant à la mode aujourd’hui doit se faire, non pas en « scalant », mais en « dé-scalant ».

Bref hélas une keynote que j’ai trouvé décevante. Mais pas par la pauvreté du propos, mais par son altitude stratosphérique et par la difficulté que j’ai eu à comprendre l’auteur à travers son accent.

Less is more avec Craig Larman

En préambule d’une formation LESS (j’y reviendrais bientôt), Greg Hutchings nous a permis d’assister à une présentation dans le cadre du Scrum User Group. Une présentation autour de LESS, bien entendu. De mon point de vue, une présentation de Craig Larman, ça vaut toujours le détour: ses talents d’orateur ne sont plus à démontrer et même si vous n’adhérez pas à la totalité de son propos, vous êtes sûr de repartir avec de nouvelles connaissances, des idées et surtout de quoi reflechir !

Pour commencer

Avant même d’aborder le thème même de la présentation et après la traditionnelle histoire drôle qui ouvre toujours ses présentations, Craig campe l’ambiance : je ne suis pas intéressé par vos opinions ! Je ne suis d’ailleurs pas non plus intéressé par MES opinions. Ce qui compte, ce sont les faits. Même les études de cas sont insuffisantes. Ce qui compte, ce sont les études menées de manière scientifiques sont des échantillons statistiquement signifiants et publiés dans des journaux à comités de lecture. Une approche scientifique sur laquelle l’orateur se revendique de Thomas Kuhn.

image

Pour lui, nous sommes à l’âge de l’obscurantisme du management, où les croyances prédominent sur les faits. Où une plus grande attention aux recherches académiques devrait être portée, alors que 50 ans de recherche en management sont simplement ignorées. Alors, laissons tomber les opinions personnelles.

Le “Scrum fake” : à la recherche des causes racines (1ère partie)

Le constat premier de Craig Larman rejoint le mien : il y a de plus en plus de “Scrum Fake” dans les mises en place de Scrum aujourd’hui. Le co-auteur de LESS y voir 2 causes racines. Des causes racines qu’il faut activement adresser, car si notre transition agile ne les adressent pas, celle-ci pourrait faire plus de mal (la déstabilisation liée au changement) que de bien (la mise en place d’un véritable environnement agile).

Cette première cause racine a un nom : le “contract game”. C’est à dire le jeu autour du contrat auquel se livrent les équipes de développement d’une part et le client (au sens client interne) d’autre part. Oui, on parle bien d’un contrat “virtuel” interne et non d’un contrat légal avec un client externe. Pourtant le fond reste le même.

image

La première partie du projet, celle où se joue l’établissement de ce contrat, est le théâtre d’un duel où le business demande “plus, plus, plus” et où l’équipe de développement réponds “moins, moins, moins”. Il y a ce combat, car chacun sait qu’au moment où celui-ci sera ficelé, le jeu changera :

  • Le business n’a plus la main, elle passe au développement qui devient seul maitre.
  • Le business lui-même ne veut pas être inclus dans le jeu du développement.
  • Ce contrat est basé sur l’illusion de la faible variabilité. Une illusion dont on sait qu’elle est fausse depuis de nombreuses décennies.
  • On dit d’un d’un contrat qu’il est aboutit quand les deux parties sont mécontentes de manière équilibrée. Au fait, quel est son rôle au contrat ? Ce n’est pas de permettre la réussite du projet mais de permettre de blâmer l’autre partie en cas d’échec !

Donc on s’engage dans une longue phase de réalisation où le chef de projet fait le lien avec le business. Craig nous parle des outils du PMI (qu’il appelle le Project Magic Intitute) concernant la relation entre le chef de projet et le client :

  • Comment le chef de projet assure le client de la réussite : en déclarant « je m’engage ! » ; une approche dont on sait depuis longtemps qu’elle ne marche pas !
  • Comme dans toute magie, on utilise des symboles ésotériques : ici, on les appellent « diagrammes de Gantt » … en fait une illusion de contrôle !

Enfin les managers pilotant ces projets à plusieurs niveaux hiérarchiques de distance transmettent des rapports d’avancements faussement optimistes au grée des remontées d’information entre niveaux hiérarchiques ! Un phénomène appelé « greenshifting ».

Tout cela se paie à la fin du projet : les blâmes sont rejetés entre les acteurs du projet, le périmètre est bâclé en toute urgence pour se débarrasser du projet en sacrifiant la moindre parcelle de qualité. Enfin, le tout se conclut en « dette managériale » : les bons managers et les bons développeurs quittent la structure !

image

Larman explicite ces fonctionnements par ce qu’il appelle en toute modestie les « lois de Larman » !

1 – Les organisations sont sont implicitement optimisées pour maintenir le statut quo du pouvoir des managers de proximité et des spécialistes

2 – Corollaire de la première loi, toute initiative de changement sera réduite à des changements d’appellation maintenant ce statut quo.

3 – Second corollaire de la première loi, les initiatives de changement seront tournées en dérision, puis qualifiées de « puristes », « théoriques » ou « révolutionnaires », puis « nécessitant des adaptations pragmatiques pour customiser pour l’organisation », menant au statut quo managers / spécialistes.

4 – La culture se calque sur la structure : les plans de carrière favorisent la spécialisation. Changer la culture en tant que tel n’est pas possible.

La seconde cause : le découpage par fonction

Le découpage « orienté composants » présente de graves lacunes :

  • Du « code privé » : au contraire d’augmenter la qualité, ces groupes créent une complexité artificielle qu’ils ne sont plus capables de voir au bout d’un certain temps !
  • Les fonctionnalités à délivrer traversent les composants. Mais comme elles deviennent subordonnées aux planning locaux, elles mettent très longtemps à être livrées. Donc un cycle de feedback qui va de même.
  • Les fonctionnalités étant l’assemblage de fonctionnalités implémentées dans les divers composants, les tests de bout en bout ne peuvent avoir lieu qu’une fois l’ensemble complété. Notre cycle de développement est en fait séquentiel à ce stade. Il subit le syndrome du « hands of » typique du cycle en cascade.
  • Ce « hands of » n’est pas seulement en aval, il est aussi effectif en amont: chaque fonctionnalité demandée doit être ventilée en éléments de réalisation, il est donc nécessaire d’avoir des analystes effectuant ce découpage au préalable du développement !
  • Le staffing étant effectué par composant, l’occupation générée par ls demandes n’est pas nécessairement en ligne avec cette disposition de ressources. La priorisation des fonctionnalités finit donc par être dirigée par l’occupation des équipes, plutôt que par les priorités métier !

Hélas, le « découpage par composants » a des airs bien trop familiers pour moi. La démonstration de Craig est plutôt édifiante !

image

Mais alors…

Et LESS, dans tout ça ?

Le point de départ de la reflexion de LESS vient de l’expérience de RUP (j’y ai participé chez Valtech, à la fin des années 90). Les deux grands défauts de RUP, que je partage avec l’orateur, étaient :

  • Un niveau de détail bien trop grand. Personnellement, je traduis celà comme une rémanence d’une vision Tayloriste du travail .
  • Un manque de contextualisation.

Le framework LESS est guidé par plusieurs principes :

  • Celui des organisations apprenantes, en s’inspirant du Shu Ha Ri. Ainsi plutôt que le ras-de-marée de détails, LESS propose des principes et juste « un peu moins que nécessaire » d’éléments de processus. Il se revendique en cela dans la lignée de Scrum.
  • Une organisation en « feature teams » plutôt qu’en composants. Comme c’est le cas chez Spotify.
  • Une « serious change initiative » destinée à bouleverser l’organisation et les titres de postes ! LESS se revendique d’inspiration Lean ici : La préservation des emplois ne signifie pas la préservation des rôles !

Pour démarrer tout cela, Larman débute une réorganisation LESS avec 2 points de rencontre très importants :

  • L’informed consent meeting. C’est un meeting de 2 à 3 jours avec Craig, avec tous les exécutifs ! S’ils ne peuvent y consacrer ce temps, c’est qu’ils ne sont pas sérieux sur leur volonté de changement ! D’après l’orateur, la plupart des organisation n’en valent pas le coup ! Hum…
  • Une fois le changement décidé, il y a le « flip », qui dure 2 heures. C’est le Design Team Meeting. Il s’agit d’une grande place de marché où les équipes s’auto-forment en s’appuyant sur une « check list ». Cela nécessite parfois plusieurs tours. Une fois cela fait, les équipes embauchent… leur Scrum Master ! Puis… leurs managers !
image

Il y a de nombreux éléments spécifiques à LESS, comme la façon de gérer les planning meetings, les démos et les sprints synchronisés. Par ailleurs, pour donner de la cohérence à l’ensemble des travaux menés par des features teams indépendantes, il faut des communautés de pratiques: certaines sont requises, d’autres informelles.

En conclusion

Tout d’abord, Craig Larman est un orateur hors pair. Non seulement sa diction est claire, mais son jeu de scène est vivant, son propos est intéressant et souvent pertinent. L’approche de changement des organisations de Larman me semble par ailleurs brutale : le RAZ sans tenir compte de l’existant ou du contexte, avec le dogme que l’organisation LESS est de toute façon la bonne. Pour Olaf Levitz, cela démontre un manque de respect. Je le rejoins sur ce point.

Les pré-requis au passage à LESS sont très importants car Craig Larman n’accepte aucun compromis. De fait peu d’entreprises acceptent un tel changement, mais doit-on dire de fait que les autres ne « valent pas le coup » ? Je ne suis pas non plus l’auteur sur ce point.

image

LESS est résolument d’inspiration Scrum par sa légèreté. Au contraire de SAFe que je trouve sujet à caution, la fibre agile de ce process me semble réelle. Mais je reste dubitatif sur le concept même et sur la motivation du scaling, quel que soit la dose d’intelligence qui y est mise (ce qui est bien le cas ici). L’idée de « scaler » me semble une réminiscence d’un ancien mode de pensée qui vient infecter le nouveau. Je pense que l’enseignement de l’agilité est différent…

Vous pourrez retrouver quelques éléments de la prose de Craig dans l’interview suivant. Un livre sur le sujet est à venir cette année, mais on trouve déjà une majorité du matériel dans les deux livres co-écrits avec Bas Vodde, dont celui-ci.

L’Impact Mapping s’invite au French SUG !

Décidément, cette nouvelle année du French SUG voit émerger une nouvelle dynamique : celle de permettre aux membres de la communauté d’être acteur des évènements ! D’accord, pour l’évènement de février on peut argumenter que je suis un ancien membre du bureau… Mais ce n’est pas le cas de celui-ci . Il a été imaginé par Géraldine Legris, épaulée par Dragos Dreptate.

image

A l’image de la soirée « en finir avec… », cette rencontre prend la forme d’un open-space. Le principe est simple et commence à être bien connu, ne revenons pas dessus. Le thème est encadré, certes. On dispose de 2 créneaux horaires et 3 salles qui seront finalement 4 ! Une restitution en fin de première session, pour la seconde, ce sera autour des pizzas !

La place de marché est rapidement alimentée et il ne reste plus qu’à faire son choix. Pas mal de monde ne connait pas en fait l’Impact Mapping ! Pour toi, cher lecteur, sache que j’avais fait une note de lecture sur le livre éponyme et que Gojko Adzik était venu en parler dans les locaux de Zenika !

Session 1 : un « why mesurable »

Ce point précis est souvent vu comme une difficulté, et s’en est bien une. Mais c’est aussi une aide, car ne pas avoir de mesure signifie souvent que l’on encore dans le moyen et non dans le « pourquoi » ! Un certains nombre d’idés et pratiques remontent rapidement :

  • Le « why » est notre pôle nord, la direction à prendre sans nécessairement devoir l’atteindre.
  • L’impact est notre boussole, qui nous indique si nous sommes dans la bonne direction.
    • Les OKR : Objective Key Results.
    • Les NPS : Net Promoter Scores.

Bien sûr, rapidement la conversation dévie sur des sujets connexes : User Story mapping et le problème de la convergence sur le why… Il est temps de passer à la restitution !

Restitution !

C’est Géraldine qui se charge de la restitution pour le groupe. Inutile de revenir là-dessus.

L’impact mapping de la soirée

Beau challenge que s’était donné l’une des équipes : construire un impact mapping sur la soirée elle-même ! Une sorte de paradoxe auto-référençant… Laurent se charge de la restitution.

La construction de la map a donné lieu à 2 difficultés :

  • D’abord converger sur un même objectif quantifiable. Au final celui qui est choisi me semble sujet à caution. Mais l’exercice est difficile.
  • Choisir dans quel sens construire la map ! Descendant ou montant 

Finalement, l’équipe aura utilisé les deux directions alternativement. C’est en fait ce qu’on fait dans la vraie vie !

Qu’est-ce que l’Impact Mapping

C’était le track « débutant », mais qui manquait un peu de praticiens expérimentés pour aider ! Le group a donc exploré diverses questions liées à l’impact mapping :

  • L’impact Mapping permet de redonner du sens à ce que l’on fait !
  • Comment se positionne l’Impact Mapping par rapport au Story Mapping ?
  • La construction d’un impact mapping conduit à des cycles successifs de divergence / convergence à l’image de ce que l’on fait en Design Thinking. Cette alternance évite l’effet fractal des mind-maps et induit une sorte de « respiration ».
  • Qu’il y a-t-il au delà de l’Impact Mapping ? Les cartes heuristiques ?

Second créneau

Impact Mapping et Lean Startup

L’Impact Mapping et le Lean Canvas sont deux outils qui me semblent pertinents pour donner du sens à ce que l’on construit, de manière agile. Mais sont-ils concurrents ou complémentaires ? Peuvent-ils s’utiliser en association ? Si oui, comment ? Voilà des questions sur lesquelles je reste pour l’instant complètement sans réponse.

C’est pour réfléchir ensemble à cette question que j’avais choisi ce groupe. Hélas pour moi, la session prend la tournure d’un long exposé.

Non seulement la teneur ne m’intéresse pas, mais je viens aux open-space pour échanger : réfléchir, écouter, enrichir les autres de mes idées et m’enrichir de même. Je ne trouve pas cela ici, je fais marcher la « loi des deux pieds » !

Retours d’expérience

Je m’arrête dans la salle où se discutent des retours d’expérience. Plusieurs sujets d’intérêt sont évoqués :

  • Comment sait-on qu’un Impact Mapping est réussi : lorsque les participants ont envie de continuer !
  • L’impact Mapping crée un effet positif important au niveau des conversations et de l’alignement.
  • Il est important de construire une branche complète (avec les 4 niveaux) assez tôt. Ce premier accomplissement soulage les participants.
  • Il faut rester « macro » sur les impacts. Cet outil n’est pas là pour créer des stories détaillées.
  • C’est un outil utile quand on ne sait pas par où commencer !
  • On peut l’utiliser dans les projets qui ont déjà commencé pour consolider ce qui existe, ou pour s’en servir comme outil de communication.
  • Ce n’est pas un outil « fire and forget » : on l’initialise avec de premiers chemins, puis on revient dessus plus tard, à la lumière de ce que l’on a appris.

Fin de soirée

Sans aller jusqu’à dire que la 3ème mi-temps est ma préférée, c’est au moins un moment dont j’essaie de profiter. Discussions avec Frédéric sur les spécifications et l’agilité, retrouvailles avec Sébastien après 8 ans… Il se fait hélas tard…

Soirée « en finir avec… »

Cela faisait déjà un petit moment que je pensais à ma petite soirée mégalo à moi. Oh, surprise, elle a fini par avoir lieu ! Nous nous sommes donc retrouvé ce Jeudi 29 Janvier chez Zenika autour de ce thème. Cette fois, ce ne sont pas les intempéries, mais une grève inopinée des transports qui ont eu raison de l’enthousiasme de 2/3 des inscrits. Heureusement pour nous le format d’atelier que nous proposions se prêtait bien à un groupe plutôt restreint, une vingtaine de personnes.

Bon, c’est ma soirée, c’est donc à moi de faire l’ouverture !

Pas de répit pour les braves, on enchaines avec les propositions et les choix de sujets !

La place de marché

Visiblement, choisir un sujet avec lequel on veut en finir n’est pas un problème.

image

Nous allons former 3 groupes dont les sujets seront finalement :

  • En finir avec le PO
  • En finir avec les Sprints
  • En finir avec les estimations

Première mission : produire un teaser sur son sujet !

image

Teasing, teasing

Les séquences duraient toutes 20 minutes. Cela peut paraitre long pour produire un teasing d’une minute ou moins, mais il fallait compter sur l’échauffement ! Les résultats sont timides, avec quelques bonnes idée :

  • Un sprint, c’est un mini cycle en V !
  • Un rôle de PO, c’est déjà fragmenter l’équipe.
image

Tout ca reste bien timide. Dans la forme, les équipes théatralisent différemment leurs présentations. On clos cette première partie par un petit perfection game.

image

Construire une mind-map

Cette seconde séquence durait également 20 minutes. Chaque équipe ayant pour mission de développer les idées initiées pour le teaser.

image

Voyons les résultats obtenus.

En finir avec le Product Owner

Plus de questions que de réponses à la fin du temps imparti. De bonnes questions de toute évidence, le temps ayant manqué pour aller plus loin.

L’équipe a probablement laissé échapper certaines idées :

  • Product Owner versus Product Ownership. Je suis même étonné que le groupe ait laissé échappé celui-là…
  • Les antagonismes et la déresponsabilisation que peuvent entrainer cette ségrégation des rôles.

La tendance de voir aujourd’hui ce rôle de PO comme celui d’un analyste et retourner ainsi à l’ancien modèle. Mais en gardant la conscience tranquille car le rôle est occupé !

Bref, il y avait quand même de quoi dire. J’avais traité le sujet il y a déjà un moment. Mais il est vrai que pour écrire un post, je m’accorde bien plus que 20 minutes !

image

En finir avec les Sprints

L’équipe a relevé quelques points tout à fait pertinents, comme l’essoufflement inhérent à cette pratique, le problème d’être « figé » sur une période de temps. Même si le « le sprint, si j’en fais je suis agile, non ? » est précisément la logique que j’essaie de combattre. Il n’en reste pas moins une matière première intéressante.

De mon côté, je crois que j’aurais aussi appuyé sur le côté « stock » inhérent à la préparation du travail et à la démonstration d’une quantité de travail sur une période de temps, fut-elle courte. Sans oublié « l’overhead » corrolaire de ce stock (durée du planning meeting meetin, de la démo…) ainsi que le délai induit pour avoir du feedback.

Je n’ai pas encore traité ce sujet dans ma série de posts. Peut-être le ferais-je cet été ?

image

En finir avec les estimations

On a de quoi se régaler avec ce sujet, qui est au coeur du mouvement « no estimates ». Un point qui n’a pas échappé à cette équipe.

L’illusion de visibilité inhérent aux estimations a bien été vu par l’équipe, bien qu’elle n’ait pas poursuivi sa reflexion vers le rejet de responsabilité vers l’équipe de réalisation qui est souvent lié.

Dans le même ordre d’idée, la notion « d’engagement » a été accrochée. On s’est toutefois arrêté là en proposant comme substitut l’observation du réalisé, alors que c’est la notion même de « quantité » contre laquelle il faut lutter.

C’est également un sujet que j’avais abordé, assez récemment pour celui-ci.

image

Et alors ?

Mon analyse des travaux peut paraitre critique. Mais il est dans ma nature d’être exigeant, je le suis d’ailleurs aussi avec moi-même ! Mais si je remonte au moins quelque points sur lesquels il aurait été possible d’aller plus loin, il ne s’agit nullement d’une déception.

image

D’abord, il est assez facile pour moi d’identifier des points alors que je réfléchis sans limite de temps !

Ensuite, l’objectif de cette soirée était d’amorcer une reflexion. Un jeu auquel les 3 équipes se sont livrées ardemment. Les résultats sont probants et tout le monde a oeuvré à sortir du carcan des ides reçues.

Bravo !

Fin de soirée

Le buffet clôturant la soirée était amplement mérité pour tout le monde. Déjà on évoque le ScrumDay 2015 qui fait maintenant plus que pointer le bout de son nez…

image

Soirée « en finir avec… » organisée par le French SUG

Ca y est, je l’ai : Ma soirée mégalo à moi ! En effet, le 29 Janvier nous nous retrouverons sous l’égide du French Scrum User Group pour une soirée exceptionnelle « en finir avec… ».

Pourquoi une telle soirée ? Tout d’abord pour fair écho bien sûr à la série de post que je vous ai asséné depuis maintenant 3 étés, et que vous retrouverez encore quelque temps. Ensuite et surtout pour réfléchir ensemble à nos pratiques agiles : les comprendre et savoir les remettre en cause !

En effet, nous tenons pour acquis la nature agile des pratiques identifiées comme « bonnes pratiques ». Qu’en est-il réellement ? Quelle est la nature et l’objectif fondamental de chacune d’entre-elles ? S’inscrivent-elles vraiment dans notre système de valeur ou s’en éloignent-elles au contraire sous pretexte de compromis à un environnement aux antipodes de ce que nous voulons faire ? Notre acceptation inconditionnelle même de ces pratiques s’inscrit-elle dans un état d’esprit agile ? Mais là, je crois que nous avons déjà la réponse…

Si ma prose vous interpelle, rejoignez-nous le 29 Janvier ! Aucune promesse ne sera faite sur ce que vous pourrez en retirer, car cela dépendra largement de ce que vous saurez y apporter !

Soirée « en finir avec… » organisée par le French SUG

En route vers un nouveau sondage sur l’adoption de l’agilité

Le Frenchsug s’est déjà par deux fois livré à des sondages sur l’adoption des pratiques agiles. Le dernier en date commence a avoir quelques rides, car il date de 2010 / 2011. De plus, il avait été mené par des membres du bureau. Le bureau du Scrum User Group que nous avons aujourd’hui a décider de mieux procéder : faire participer la communauté à l’élaboration du sondage !

C’est donc à cette fin que nous nous sommes retrouvés entre-nous ce 12 novembre !

image

Mais d’abord : un bâton d’Hélium

On appelle ça un « ice breaker » ! Dans la pratique, c’est un truc beaucoup plus économique que d’abreuver l’assistance d’alcool ! Connaissez-vous le principe ? Un bâton très, très léger repose sur un doigt de chacun des participants. On doit le poser au sol sans en ayant toujours tous les doigts en contact à tout moment. Sinon, on recommence !

image

Résultat des courses : une équipe a réussit, l’autre pas. Il semblerait que l’exercice marche mieux avec un bâton d’Hélium en Fer (le poids de l’Hélium liquide sur Jupiter, j’imagine ?), je me demande bien pourquoi…

Et maintenant, au boulot !

Un backlog, des sujets… mauvaise nouvelle pour moi qui était venu pour mettre les pieds sous la table et causer avec mes potes ! Arnaud (encore lui) nous explique le déroulement de la soirée.

image

Donc nous avons des sujets que nous a concocté le bureau (mais on a le droit d’en choisir / créer d’autres. Toutefois, comme nous avons tous le cerveau plus ou moins lessivé par une journée de travail, nous ne le ferons pas. Le bureau nous a même mis à disposition les supports d’autres sondages à des fins d’inspiration. D’autres apelleront cela « biais cognitifs » !

image

Ah oui, c’est vrai les sujets :

  • Entreprise : tout ce qui concerne l’adoption de l’agilité au niveau de l’organisation, la culture d’entreprise, etc..
  • Projet : Même chose au niveau des projets. Quelles sont les conditions favorables ou défavorables à l’adoption à ce niveau.
  • Localisation : Quelle est l’influence de cet aspect sur le déploiement des principes agiles ? A Paris, hors de Paris, à l’international… Bien sûr en filigrane, il y a la question du near-shore et de l’offshore. Sans compter la répartition dans plusieurs salles, plusieurs étages ou plusieurs bâtiments. Ce qu’Alistair Cockburn appellerait la communication qui se mesure en mètres, portes et escaliers.
  • Personnes : quels profils des répondants, avec quelle expérience dans / hors de l’agilité ? A qui ressemblent les promoteurs de l’agilité dans l’entreprise ?
  • Contrat : Le sujet mal aimé par excellence. Quel type de contrat a un effet positif / contreproductif sur le déroulement en mode agile ? Quelles sont les contraintes par rapport aux achats ?
  • Méthodes et pratiques : XP, Scrum ? Kanban ? Lean ? Qu’adoptent les équipes ? Ou encore : quels mixes ? Même question sur les pratiques telles que story mapping, TDD, BDD/ATDD, pair programming, etc…
  • Impact : Quels sont les gains, les motivations et les enjeux ?
  • Outils : Que ce soit pour suivre le projet ou pour l’executer, quels types d’outils utilisez-vous et avec quelq gains espérés/réel ?

3 itérations étaient prévues, nous en feront 2, parce que hein, quand même…

image

1ère itération

Nous formons rapidement des petits groupes, par affinité de sujets.

image

Je me rapproche du groupe s’interressant aux personnes. Premier obstacle : on a mis à notre disposition un Canvas. Et pour commencer, il nous faut comprendre comment il fonctionne…

image

Plutôt que de recenser directement les questions, nous cherchons plutôt à articuler les thèmes. Caramba, je n’ai pas pris en photo notre Canvas !

Donc plus de détails plus rtard, quand on aura retravaillé la matière. Le temps passe vite, car l’itération n’était prévu que pour 30 minutes ! Il est temps de restituer. Pour notre équipe, c’est Géraldine qui fera la « démo » !

image

Pas le temps de souffler, on remet le couvert !

2nd itération

Peu de changement à notre groupe où règne une bonne entente pour cette seconde itération. Par contre, nous choisissons d’aborder un autre sujet !

Et c’est bien le sujet le moins sexy sur lequel nous allons nous arrêter : le contrat !

Quelle cadre contractuel est appliqué aux projets agiles : forfait classique ou aménagé ? Assistance technique dans un cadrat cadre ou choisie librement ? Quelles sont les conséquences de ces choix…

Pas plus que la première fois, je n’ai conservé les notes. Et déjà il est l’heure de la démo…

image

Et ensuite ?

Nous n’avons fait qu’amorcer le travail. Nos Gentils Organisateurs du SUG se ont fort d’enclencher la suite des groupes de travail. Objectif : des résultats de sondage pour le ScrumDay 2015 !

Retrouvez aussi le compte-rendu (officiel cette fois) de cette soirée sur le site du French SUG.

ScrumBeer de Septembre : Histoire sans paroles…

Je rate rarement une Scrumbeer. Il faut vraiment qu’il y ait un empêchement pour cela. Cela a bien failli être le cas ce 25 Septembre, à cause d’une collision de date avec le meetup Product Tank, comme cela arrive bien trop souvent…

C’est donc tranquillement à 21h30 je me suis joins à notre petit groupe d’habitués. Auquel fort heureusement se joignent à chaque fois quelques nouveaux venus !

image

C’est Au Fut et à Mesure qui nous avions rendez-vous. Une idée originale, dans un lieu au concept très « tendance » ! Mais aussi hélas à la musique bien trop forte.

Mon arrivée tardive aidant, j’ai peu échangé avec les autres. Nous avons quand même pu le faire rapidement sur le sujet toujours délicat et d’actualité de la façon d’introduire et convaincre de mettre mettre en oeuvre de nouvelles pratiques.

Je suis de plus en plus sceptique, pour ne pas dire plus, sur la méthode consistant à « convaincre » de l’intérêt d’adopter telle ou telle pratique. Cela me parait une voie menant à des discussions sans fin ! Désormais j’essaie plutôt de faire accepter une petite expérimentation sans porter de jugement préalable, puis d’évaluer la pertinence de ce qui a été vécu sur la base de critères partagés. Bref, faire plutôt que discuter !

Avant de nous séparer, nous avons brièvement évoqué le prochain ScrumDay.

image

C’est vrai, c’est dans un bout de temps, mais il va bientôt y avoir un open-space pour amorcer sa co-création ! Malheureusement, j’aurais (encore) un autre meetup pile-poil à la même date ! Je ferais quand même mon possible  pour apporter mon gravier à l’édifice, à moins que je tente de nouveau le « double date »…

Soirée « fails » de l’agilité : une exclu du SUG !

Une soirée consacrée aux échecs de la mise en oeuvre de l’agilité, cela devait nécessairement commencer par un beau « fail ». Le mien fut d’oublier mon appareil photo ! Me voici condamné à utiliser mon téléphone portable et les images partagées par les autres participants !

Qu’à cela ne tienne, une excellente soirée s’annonce, bien que nous ne fassions pas salle comble. Mais avec au moins une quarantaine de participants, nous avons largement de quoi nous divertir. C’était annoncé : il fallait venir avec un « fail ». J’étais un peu inquiet, aurions-nous suffisamment de cas à nous mettre sous la dent ?

J’étais moi-même sollicité pour être l’un des membres du SAV, mais n’ayant jamais opéré avec Raphaël, Bertrand et Gwenael, impossible de savoir si notre quatuor allait fonctionner !

image

Pitchons !

Finalement toutes ces craintes se sont avérées vaines ! Des cas proposés, nous en avons eu près d’une trentaine ! Tous proposés de bon coeur et dans la bonne humeur. En fait, ce succès a même un peu dépassé nos espérances. Nous n’avons pas bien correctement maitrisé la durée des pitches, ce qui au final s’est avéré un peu long.

image

Un point d’amélioration pour la prochaine fois.

Votons !

Un simple vote à points pour prioriser nos cas. C’est quelque chose que nous savons bien faire. En quelques minutes, nous avons réglé cela.

image

Jusqu’ici, le SAV n’a guère eu besoin de beaucoup s’activer. Ca va changer !

Le SAV à votre service !

Ce qui est au SAV reste au SAV ! Cela m’interdit d’être trop précis et surtout de nommer les cas représentés. Si le thème de la soirée n’avait exclu aucune approche agile, tous les cas tournaient autour de mises en oeuvre de Scrum. Les problèmes évoqués tournaient beaucoup autour des thèmes suivants :

  • Mise en oeuvre problématique de l’approche.
  • Casting des acteurs, beaucoup autour du PO.
  • Contexte inapproprié : budget fixe / coût fixe, contractualisation mal ficelée.
  • Jeux politiques ou relationnels.

Certains des cas exposés étaient même des combinaisons de plusieurs points énumérés ci-dessus !

Nous avons cherché à comprendre en remontant au mal se cachant derrière les symptômes. Le public a bien joué le jeu en rebondissant sur les points investigués. Parfois avec des questions « sans issues », mais l’investigation est un art difficile. Je me suis pour ma part efforcé de poser des questions inquisitrices. Dans un style complètement différent, Bertrand Dour nous a proposé ses résolution de problèmes façon « terminator ». Le moins que l’on puisse dire, c’est que ça change ! J’en suis en tout cas reconnaissant à Bertrand : je manquais un peu d’énergie en fin de journée, ayant enchainé cette soirée avec une journée de formation !

image

Notre quatuor a finalement bien fonctionné, malgré ou à cause de 4 styles différents ? L’un de nous 4 avait souvent une idée d’angle d’attaque quand les autres étaient à sec, même s’il est vrai que nous avions souvent des manières différentes de voir le problème. Cela n’a pas semblé être une gêne au final.

Le deal était de trouver des solutions, pas moins ! Pas de rester en posture coach. Ne soyons pas prétentieux, je n’espérais pas aller jusqu’à la solution clé en main, pour autant que cela existe. Non, mais il était raisonnable d’espérer proposer des pistes sérieuses à explorer. Nous l’avons fait finalement souvent, quelques cas ardus s’étant par contre soldés par quelques idées pas forcément tangibles, donc que je ne classerais pas dans les solutions.

image

Nos chers animateurs ont demandé à l’assistance de voter sur la qualité des réponses. Si nous l’avons fait pour les premiers cas, cela est vite tombé aux oubliettes. Dommage, l’idée est bonne et aide à impliquer le public.

image

Enfin, nous avions prévu un « time boxing » de 15 minutes par cas. Je pense que c’est la bonne dose. Même si vu du côté du SAV, ce n’est pas si facile à tenir !

image

After !

Soat qui nous accueillait dans ses locaux proposait aussi les sandwiches pour se sustenter. Un accueil impeccable de bout en bout, je dois dire.

Hélas, je ne me suis pas tellement attardé, juste le temps d’échanger quelques mots avec les uns et les autres (et oui : seconde journée de formation le lendemain !). Le prochain rendez-vous devrait se caler vers la fin du mois prochain pour un « open-space de préparation du Scrum Day ». Annonce faite par Arnaud !

image

Entre-temps, ce même Arnaud nous aura organisé une Scrum Beer !

Cette soirée change résolument de ce que le Scrum User Group avait organisé jusque là ! L’agenda est probablement à adapter un peu. Nous avons été trop gourmands, je pense, concernant le nombre de cas. Mais le mot de la fin revient aux participants : voici leur appréciation :

image