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

Lire la suite

Agilité et hospitalité Libanaise

J’attendais cela depuis un moment, depuis le milieu de l’été pour être plus précis. Car Pierre Hervouet nous avait invité à venir partager avec la communauté Libanaise pour cette seconde édition de l’Agile Tour Liban ! Nous étions donc 4 Français à nous envoler vers le moyen-orient le vendredi matin pour une conférence qui se déroulerait en week-end.

image

Lire la suite

La rentrée en open space !

Il n’aura pas fallu attendre longtemps pour voir notre premier rendez-vous agile de la rentrée. C’est d’ailleurs un agenda assez rythmé qui nous attend dans les semaines qui viennent !

Mais en ce 4 Septembre, c’est un open-space auquel Yannick nous a convié dans les locaux de Zenika. Beaucoup d’inscrits, peu de venus (environ une quinzaine), mais comme on dit dans les open spaces : les personnes qui sont là sont les bonnes personnes. Petit avantage : l’achalandage de notre place de marché va plutôt vite. C’est bien car ce sont 3 créneaux qui sont prévus pour ce soir !

image

1er round : où il est question de (non) estimations…

3 sujets sont proposés dans chaque tranche de temps, avec 45 minutes consacrées à chacune q’entre-elle ! Voilà, c’est parti.

image

Chaque groupe prend possession de son espace. J’avoue apprécier d’avantage les petits groupes de 5 comme c’est le cas ici.

Il faut faire des choix, parfois difficiles. Ce groupe a choisi d’aborder la définition de « done », un sujet pour lequel j’éprouve un certain intérêt … 

image

Je me décide finalement à rejoindre le groupe de Dov pour débattre du « no estimates ». Je me suis dit que cela faisait une bonne suite à ma rubrique de l’été : en finir avec les estimations !

image

J’ai été rapidement déçu par la direction qu’a prise la discussion, ou plutôt l’exposé que nous a fait Dov de son contexte. Outre que je suis plus intéressé par la discussion que par écouter une seule personne discourir, il ne nous parlait pas de « no estimates », mais plutôt de « diluate estimate » !

Supprimer les estimations « parce qu’elles font durer le planning meeting trop longtemps » sans changer la logique de travail entre le PO et l’équipe, c’est un peu mettre un sparadra sur un bobo. Certes, cela fait diminuer la pression … mais ce n’est pas du « no estimates ». Où plutôt cela l’est au sens littéral, comme quoi le terme n’est pas bon, du moins à mon avis.

Un avis apparemment partagé par Arturo ! Du coup, nous réorientons la discussion sur le changement de focus : la valeur et la définition de succès, du projet ou du rôle du product owner. Dans le cas du projet de Dov, on parle d’implémenter ce qui est dans le backlog : tant que l’on en est là, il n’y a pas de changement de logique et cesser d’estimer est futile, peut-être même malhonnête par rapport au client ?

J’aurais aimé avoir plus de temps pour creuser la question du changement de logique avec Arturo, mais le gong nous a rattrapé. Nous avons à mon goût passé bien trop de temps dans une direction qui ne m’intéressait pas. Oui, je sais j’aurais dû appliquer la loi des deux pieds. Mais le sujet m’intéressait et je préférais le rediriger dans une voie qui me convenait plus.

2nd round : Trop d’agile tue l’agile ?

Pour faire 3 round, Yannick nous a proposé un timing assez rythmé, pour ne pas dire serré. Ca ne laisse pas beaucoup de temps au partage ni au « slack », c’est un peu dommage.

image

Pour ce second round, je me suis joins à Renaud. Je ne suis pas fan de la manière dont il a exprimé le sujet. Peut-être même pas fan du sujet, d’ailleurs. Mais je me dis qu’au pire, il se prête assez bien au hacking !

Renaud s’étonne d’un certain nombre de sujets abordés dans le cadre de Scrum qui sont justement incompatibles avec Scrum. Sans aucun doute, il a raison. Renaud profite de l’occasion pour nous parler de Shu Ha Ri, cela vous rappelle-t-il quelque chose ?

Je ne vois pas trop où le « trop d’agile » intervient dans cette discussion, car on en arrive à évoquer le « Scrum by the book », ce qui est un peu normal quand on parle de Shu, mais pour le seconde fois de la soirée, je m’aperçois que ce n’est pas une direction de la discussion qui m’intéresse !

image

Le « trop d’agile », c’est pour moi trop se focaliser sur le fait de faire effectivement de l’agile au travers de telle ou telle pratique. Et s’intéresser à l’orthodoxie des pratiques (comme nous le faisons là), c’est se focaliser sur les choses qui sont au final inintéressantes. L’agilité est un moyen, c’est aujourd’hui devenu une fin ! On est d’ailleurs en train de parler « d’audit agile » dans cet ordre d’idée, une perspective que je trouve déplaisante.

Merci une fois encore à Arturo pour m’avoir épaulé pour chercher à explorer cette voie. Une fois encore je me trouve un peu frustré par le gong qui raisonne…

3ème round : Convaincre sur l’agile

Rapide partage avant le dernier round. Trop rapide encore. Hélas encore !

image

Nous commençons à nous dépeupler. Ce dernier round ne comptera que 2 sujets, le 3ème passera à la trappe : c’était le mien ! Mais il semble n’intéresser que peu de monde. Peut-être même personne.

Un débat plus intéressant cette fois autour d’un cas réel : quelle prise pour convaincre un management par ailleurs dans l’échec !

image

On a beaucoup parlé de construire un argumentaire, enquêter, chercher des éléments… Tout cela ne vas pas me convaincre. Plutôt que d’argumenter avec de grands mouvements de manche, pourquoi ne pas faire ? Quelle expérimentation mener pour prouver ? Quel investissement semble assez raisonnable pour essayer quelque chose ? Après tout si la situation actuelle ne marche pas …

image

Conclusions

Ce n’était pas la grande forme pour moi, ce jour-là. Mais je souligne 4 éléments à l’issu de cette soirée.

Un petit groupe pour l’open space et des petits groupes de 5 pour discuter, c’est plus convivial et plus interactif !

Le timing était un peu serré du fait de la contrainte que l’on se donnait sur les 3 tranches de temps. C’est dommage ! Je pense que j’aurais préféré deux créneaux de qualité avec un peu de mou et un temps de partage prolongé.

Un peu frustré par la direction prises par les deux premiers sujets. C’est nécessairement un point de vue personnel, je ne peux escompter que tout le monde partage la direction que j’aimerais faire prendre à la discussion.

Enfin, mon sujet n’a finalement pas été abordé. En soi, cela n’a aucune importance. Mais il s’agissait du seul sujet traitant de conception, de craftmanship. Lors des rendez-vous agiles, j’entends toujours des participants parler du TDD « il n’y a que ça de vrai » … mais traiter vraiment du coeur du sujet, en l’occurrence de la conception émergente, cela finalement n’intéresse personne. Est-ce la différence entre l’intention et la réalité ?

Agile Playground #15

Un conflit d’agenda m’a fait raté le 14ème rendez-vous, c’était donc une bonne surprise de voir un Agile Playground programmé en cette première quinzaine de Juillet, alors que je croyais nos rendez-vous interrompus jusqu’en Septembre !

image

Au programme de cette soirée, un ice-breaker sans prétention mais amusant proposé par Frank Beulé et une traditionnelle expérimentation de jeu.

Change agent

On est là pour expérimenter et Christophe Keromen a bravement défendu cette tradition avec une création vraiment difficile, je dois dire : le « change agent » inspiré du How To Change the World de Jurgen Appelo.

image

Le principe :

  • 4 équipes devant s’approprier 4 des modèles décrits dans le livre de Jurgen Appelo : Dnce with the system (PDCA), ADKAR, la courbe d’adoption de Moore et les 4 « I ».
  • 2 tours de batailles (demi-finales et finales)
  • Un storytelling à monter pour chaque équipe à chaque tour. D’abord un exemple d’échec puis un exemple de succès.
  • A chaque tour, chaque équipe change de modèle.

En plus du modèle, nous disposions de cartes pense-bête dont il fallait montrer l’utilisation au fur et à mesure de l’histoire. Bien entendu, le tout était time-boxé, ce qui rendait l’exercice particulièrement difficile !

image

Entre les 2 tours, nous avons fait une rétrospective éclair pour améliorer le fonctionnement. Ca a marché ! N’occultons cependant pas le principal : c’est mon équipe qui a gagné 😉

image

Ce que j’en ai pensé

Je dois l’avouer : je ne me suis pas amusé durant ce jeu. Est-ce grave, docyeur ? Pas vraiment : l’agile playground est là pour expérimenter et Christophe a fait la tentative la plus audacieuse à laquelle j’ai assisté. Et cela doit être salué !
Nous avons donné (beaucoup) d’éléments à Christophe. Voici de nouveau les miens plus une ou deux choses dont j’ai discuté avec Xavier Galleri :

  • Double difficulté de l’exercice : trouver une histoire et comprendre assez bien le modèle pour l’appliquer à l’histoire. Quand on ajoute la contrainte du temps… Il faudrait proposer des trames d’histoire prêtes à être utilisées.
  • Le setup de la salle : la disposition des tables nous collait contre le mur, ce qui crée un style un peu guindé et une certaine pression psychologique.
  • Durant le story-telling, les autres équipes sont trop passives. On pourrait utiliser les cartes pour les faire participer. Un peu comme un loto…

N’oublions pas le plus important : le story-telling, ça marche ! C’est quand même l’ingrédient principal qu’a voulu utiliser Christophe et les remarques que nous avons faite ne doive pas occulté qu’il a réussi sur ce plan !

Lean Agile Camp, saison 2

Le premier opus du Lean Agile Camp s’était déroulé en novembre dernier, une période peu propice pour moi et j’avais abdiqué. Pas question de rater celle-ci par, contre : programmée début Juillet, il n’y avait guère de conflit de dates à l’horizon.

Quand on veut parler de Lean sérieusement, on a de bonne chance que Régis Médina ou Antoine Contal ne soient pas loin. Nous avons eu la chance de bénéficier de l’expertise des deux !

image

Au programme de cette journée, des dojo pour aborder 3 sujets :

  • La compréhension du client
  • Le management visuel
  • La résolution de problème

1er atelier : le « job to be done »

Cet atelier est destiné à confronter nos hypothèses à la réalité. Pour ce faire, nous avons choisi une application (l’application Meetup mobile dans notre cas) et avons cherché à en établir les cas d’utilisation, structuré de la manière suivante :

  • Contexte d’utilisation
  • Job
  • Attributs

Dis comme ça, c’est un peu abstrait. Voyons plutôt le résultat que nous avons obtenu.

image

Dans une seconde étape, nous avons consolidé le travail fait avec nos hypothèses en allant rechercher des feedbacks utilisateurs. On le craignait, mais bien sûr hélas, la réalité du terrain nous donne un tout autre son de cloche : les propriétés que nous avions jugées importantes ne semblent pas les bonnes. Par exemple, la question de la confiance dans les groupes ou les membres semble récurrente (nous avons croisé plusieurs sites et forums utilisateurs).

Bref, on découvre de nouveaux « job to be done », de nouvelles propriétés et en éliminons certaines qui ne sont pas recoupées par nos sources d’information.

A la fin de l’exercice, nous partageaons nos trouvailles entre groupes.

image

Le « misfit » entre nos hypothèses et la réalité est un point commun entre nos deux groupes !

Le FIAP Jean Monnet qui nous hébergeait propose des facilités pour déjeuner. Grâce à cela nous pouvons limiter nous pause déjeuner à 1 heure. D’autant que la zone restauration est carrément vide en ce premier week-end de Juillet !

image

Retour aux choses sérieuses avec notre second kata !

2nd atelier : le management visuel

Cette fois, nous allons partir d’une situation existante, un cas existant dans l’un de nos contexte et proposer des visualisations adaptées. Il pourra s’agir d’une visualisation ex-nihilo ou l’amélioration d’une visualisation existante. Les clés que nous proposent nos deux coaches Lean sont :

  • S’inspirer des jeux video : être clair sur les scores !
  • Donner un contexte stratégique, mais un focus opérationnel !
  • Visualiser le challenge !

Attention, le challenge peut être anxiogène, le mieux est d’être capable de montrer les progrès au jour le jour, car la motivation vient du succès !
Nous avons choisi deux contextes issus de notre groupe :

  • Un centre de service, qui cherche encore quel est son objectif de succès !
  • Un grand projet qui a un objectif de périmètre pour une date donnée et doit motiver celles-cis afin d’atteindre ce but alors que les mesures montrent un état courant en-dessous de ce qui est escompté.
image

Certes, le management visuel n’était nouveau pour aucun de nous. Et pourtant ! Pourtant, grâce à ces quelques lignes directrices et aux interactions du groupe, nous avons abouti à des résultats inespérés !

3ème atelier : la résolution de problème avec le PISCAR

La résolution de problème, c’est un peu l’épicentre du Lean (avec l’amélioration continue). Et qui dit amélioration continue, dit PDCA, n’est-ce pas ?

image

Nous allons nous concentrer sur la partie « problème » du PDCA et utiliser une heuristique proposée par Régis Médina : le PISCAR que nous allons donc expérimenter sur nos études de cas :

  • P : Le Problème ; il doit être énoncé sans essayer de camper un contexte ! On définit un problème comme un écart quantifié.
  • I : L’impact ; Il doit être chiffré. Il nous permet de répondre à la question : Est-ce le bon problème.
  • S : Standard ; la partie la moins évidente de l’exercice. L’idée est de comparer la situation à problème au cas normal.
  • C : Causes ; que l’on obtient par exemple avec les « 5 pourquoi ». Mais surtout on cherche les racines. Les 5 pourquoi, ça fait un peu tarte à la crème…
  • A : Action ; une action qui doit être le plus rapide et le plus simple (donc la moins coûteuse) possible. Donc, une expérimentation.
  • R : Résultats attendus ; ils sont à mettre en rapport avec l’impact.
image

Nous effectuons l’exercice de manière itérative, car c’est probablement le plus difficile de la journée. Corina s’est proposée pour exposer le sien pour clore ce 3ème volet.

image

Ce que j’en ai pensé

C’est ce que j’appelle une journée bien investie, même prise sur mon week-end ! Une journée pour comprendre, pratiquer et échanger sur 3 pratiques: j’ai hâte de remettre ça !

Foot ou ScrumBeer, il faut choisir !

De toute évidence, nous étions un petit nombre a avoir choisi ! Et pour une fois (ceci impliquant cela) nous avons presque atteint la parité hommes-femmes ! Cela dit, en se rendant dans un pub, il restait improbable que nous puissions complètement échapper à une retransmission de la coupe du monde !

image

De nouvelles têtes et des têtes connues, comme d’habitude dirais-je. Je ne vais pas m’étaler sur nos conversations, car contrairement à l’accoutumée, nous nous sommes livrés à quelques activités.

Le noeud humain

Régis nous a convié à l’exercice du noeud humain. D’accord, j’ai déclaré forfait en prétextant mon poignet encore fragile. J’en profite pour prendre des photos (bien entendu) et voir une vue d’ensemble, bien que je n’ai pas suivi les différentes phases !

Bref, on commence par former une chaine « nouée »…

image

Ensuite on doit s’efforcer de se dénouer.

image

Soit en s’auto-organisant, soit sous les directives d’un manager !

Et un marshmallow, un !

Comme nous étions en forme, Arnaud nous a proposé un petit Marshmallow challenge. Deux constructions en compétition. L’une a gagné.

image

L’autre a … moins réussi !

image

Encore une petite dernière ?

Oui, en principe c’est bientôt le break de l’été. S’il fait beau début Juillet (nous n’avons pas tellement de chance de ce côté depuis quelques années), nous pourrons peut-être organiser un petit « Scrum Picnic » pour conclure dignement cette année…