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

Open-Space des pratiques agiles, en toute intimité

Pour ce premier Open-Space 2015, nous étions accueillis par Malten. Etait-ce l’éloignement (pourtant pas si important, à Neuilly), la pluie ou un début d’année déjà chargé ? Seul un quart des inscrits étaient fidèles au rendez-vous.

Qu’importe, les règles de l’open-space disent : « les personnes présentes sont les bonnes personnes » et c’est ce que nous avons acté !

image

Il n’y avait pas non plus floraison de sujets. Mais il y en avait bien assez pour alimenter nos discussions. Et une fois n’est pas coutume, j’en ai proposé un ! Il a même reçu plus que sa part de vote.

image

Il s’est ainsi retrouvé en première tranche horaire. Allons-y

Et la motivation, alors ?

Les principes agiles nous disent bien de « prendre un groupe de développeurs motivés et de leur laisser faire leur travail ». Mais motivés par quoi ? Quelle type de motivation nous intéresse ? Et est-ce une bonne idée de chercher à filtrer un type de motivation adéquat ?

Assez rapidement, quand on parle de motivation, on arrive sur les fameuses motivations intrinsèques de Jurgen Appelo. Mais sélectionner le type de motivation recherchée ou retenir ceux-ci n’est pas si facile. Ici, nous avons identifié le facteur que je trouve le plus intéressant de cet atelier :

Aligner les valeurs de l’entreprise avec le ou les types de motivations qui nous intéressent.

Ainsi on favorisera « l’équilibre écologique » recherché, si bien sûr ces valeurs sont effectivement vécues au jour le jour.

Nous avons évoqué bien d’autres choses encore, comme la spirale dynamique, mais bon, pour en savoir plus, il fallait être là, n’est-ce pas ?

image

Entracte

Dans l’autre salle, on discutait agilité dans le business avec un jeune chef d’entreprise qui vient de découvrir l’agilité par ses informaticiens…

image

On perd quelques participants au passage, mais cela ne saurait nous empêcher d’attaquer le second créneau !

#noestimates

C’est à la manière du hashtag Twitter que nous était proposé le sujet. Sur cet atelier nous ne sommes carrément plus que 3, cela simplifie la photo de groupe.

image

En parlant d’estimations, on remonte aux finalités du planning meeting, qui sont l’acquisition de la connaissance du sujet et l’alignement sur la valeur recherchée et le plan d’action.

Mais les estimations focalisent sur la taille (comme on faisait avant l’agilité) plutôt que sur la valeur ! Il faut donc un nouveau type de discussion centrée sur le découpage, afin de maximiser la valeur et se créer des options. Des sujets que j’avais traité d’ailleurs dans « en finir avec les estimations ».

image

En clôturant l’open-space…

Pendant ce temps, on parlait portefeuille de projets dans l’autre salle…

image

Bref, c’était certes un open-space restreint, mais la quantité n’a jamais primé sur la quantité dans mon esprit. Une soirée que je noterais donc 4 (sur 5) sur mon « fist of 5 ».

Meetup Craftsmanship : où il est (aussi) question de documentation…

C’est dans les locaux de Zenika que s’est déroulé ce nouveau meetup Craftsmanship, en fait le premier pour moi ! Cyrille Martraire sera le maître de cérémonie, il introduit le déroulement de la soirée, à savoir : 2 lightning talks, 1 talk moins light et enfin le coeur de cette soirée, l’open-space

image

Alors, Dev4Fun, qu’est-ce que c’est ?

Xavier Detant est venu nous présenter un nouveau meetup, non pas concurrent, mais complémentaire à Software Craftsmanship : Dev4Fun !

image

Dev4Fun, c’est un « coding dojo », mais sans le mot « dojo », car ciblant plus les débutants. Pour rendre cela Fun, on s’appuiera, au moins pour la prochaine rencontre planifiée pour le 22 Janvier, sur une plateforme dédie au développement de code sur des jeux : codingame.

Bref cette rencontre a pour but de faire découvrir, comme le dit Xavier « pourquoi on kiffe sur les barres vertes » !

Comment amener les changements techniques dans l’entreprise ?

Cette présentation avait pour but de donner un coup de projecteur sur ce sujet issu du livre de Sandro Mancuso sur le Software Craftsmanship. Plus précisément, il est question ici de classifier les profils d’une équipe afin d’adopter la bonne stratégie en fonction des interlocuteurs !

image

On trouvera ainsi :

  • Le Non-Informé : Il ignore tout du sujet, on peut l’amener à bord en partant de zéro.
  • Le mouton : Pas la peine de s’en préoccuper. Si on embarque les autres, il suivra.
  • Le cynique : Il va prendre le contre-pied juste pour le plaisir de se montrer plus malin. Attention de ne pas perdre trop de temps avec lui.
  • Le désabusé : Il a essayé des choses et s’en est mordu les doigts, il n’a plus le goût à essayer.
  • Le surbooqué : Il n’a pas le temps de vous écouter
  • Le boss : Ne pas perdre de temps avec lui, car de toute façon, il n’y cmprendra rien.
  • L’irrationnel : c’est le cynique mais en pire ! Il va contre-argumenter sans but et va vous faire perdre du temps.
  • L’indifférent : Il ne se sent pas impliqué, mais attention ! Il peut être la source de mauvaises implémentations de bonnes idées.
  • Le persécuté : Il nuit au projet en attendant sa prime de licenciement. A écarter à tout prix.
  • L’inapte : Simplement pas à sa place. A éviter.
  • L’architecte « tour d’ivoire » : Il croit tout savoir mais ne touche plus au code. Attention, il peut avoir beaucoup d’influence…
  • L’inscure : Il s’est construit son petit confort, mais il est « has been » et a peur que l’on s’en rende compte.
  • Le fan boy : Implémente le pattern « golden hammer » avec une technologie qu’il admire et connait très bien. Mais si on peut le convertir…

Dans ce tableau idylique, il manque bien sûr le gars normal ! Comme le souligne l’orateur, identifier les profils, c’est déjà 50% du travail. Sur le fond, je trouve ici une matière un peu intéressante mais pas révolutionnaire. En fait, c’est une vision très simplifiée de ce que l’on peut trouver dans Fearless Change. Quand au livre, vous pouvez en voir un excellent résumé ici.

Does your code speak business ?

Pas un lightning talk ici, mais plutôt une présentation de 30 minutes (avec les petits soucis techniques qui l’ont émaillée). Maxime énonce le problème qu’il veut traiter ainsi : comment ajouter de la valeur si votre code ne parle pas métier. A titre de contre-exemple, il nous assène le syndrome de l’homme fort ! Vous savez, celui qui écrit un code incompréhensible plus vite que son ombre, qu’il ne faut jamais déranger et qui au final livre une usine à gaz à côté de la plaque ?

image

L’homme fort n’est pas le seul syndrome. De manière générale, on rencontre nombre d’équipe où le business et l’équipe de développement utilisent des vocabulaires différents ! Un problème encore amplifié par les modèles de développement en silos où le besoin initial fait l’objet de traductions successives…

image

La solution ? Le fameux « ubiquitous language » du DDD. Mais l’orateur nous invite à ne pas en rester là : pour découvrir ce vocabulaire, parlons Event Storming ! Il s’agit d’une approche proposée par Alberto Brandolini, elle prend la forme d’un workshop dans lequel on invite « des personnes avec des questions (les développeurs) et des personnes avec des réponses (le business) ». On part de « l’évènement le plus important dans le système » et on remonte dans le temps. A chaque évènement correspondra une commande et au final on sura comment le système doit se comporter.

Je ne connaissais pas l’Event Storming, un nouvel outil à considérer sérieusement !

Open-space : alors, cette doc ?

Oui, c’est un open-space, vous savez celui où on forme des groupes, on propose des sujets et on vote sur ceux-ci. Le zLocalHost de Zenika a fait le plein et nos 3 cercles sont un peu enchevêtrés…

image

Donc, on propose des sujets…

image

Puis on vote ! Je vais m’incruster dans le groupe qui parlera de documentation !

image

La discussion démarre sur les chapeaux de roues : moi j’utilise Sharepoint, moi un Wiki … Mais un instant : La documentation n’est qu’un moyen, non ? Quelle finalité cherche-t-on à atteindre avec cette documentation dont on pense implicitement qu’elle est indispensable ? Car là, on commence à parler du moyen du moyen !

Visiblement, la finalité, c’est souvent de transmettre de l’information quand quelqu’un part ou qu’un nouveau membre de l’équipe arrive. Un bien pauvre substitut au partage du savoir que l’on obtient en travaillant ensemble. On évoque aussi les tests, plus précisément les acceptance tests en tant que « living documentation ».

image

Pour en revenir à la documentation sensu-stricto, je relève :

  • Que je ne suis pas le seul à avoir des problèmes pour m’y retrouver dans les Wiki. Cyrille semble avoir le même problème que moi. Donc un bon moteur de recherche full-text y est indispensable.
  • Coupler la documentation avec la gestion de version, une option importante.
  • Les nomenclatures de noms de documents ou de répertoire, ça fait peut-être « old school », mais ça marche !
  • Le problème de la divergence de la documentation avec la réalité : un obstacle sur lequel on finit toujours par arriver. Pourtant on reste câblé sur l’idée de la documentation qui sauve de tout…
  • Les docs de haut niveau sont finalement celles qui sont le plus souvent demandées et utiles. Outre qu’elles ne sont pas trop volumineuses, elles souffrent moins du phénomène d’obsolescence, donc plus faciles à maintenir.

Cet échange n’a pas révolutionné mais idées, mais il était agréable. Les 2/3 choses que j’ai notées au passage ne feront pas de mal !

Assez bossé, il est temps de migrer vers le buffet pour conclure la soirée !

image

Open-Space des pratiques Agiles

Deux mois se sont écoulés depuis notre rendez-vous précédent chez Zenika. Nous voici de retour pour échanger sur les pratiques. Au menu : petit groupe, provisions de bouche en mode collaboratif, et des sujets qui restent à choisir !

SAFe, est plus que LESS ?

Premier sujet autour de SAFe, décidément, l’un des grands sujets du moment. Peut-être du fait de son adoption récente par JC Decaux ?

En dépit des retours très positifs de Lissa Adkins, je reste très dubitatif sur ce framework. Ce retour de formation SAFe correspond plus à l’idée que je m’en fais. Disons que je suis très dubitatif, mais j’entend aussi des choses positives de la part de gens que je respecte…

Yannick lui, voit un indiscutable avantage à SAFe : la possibilité qu’il ouvre de parler aux DSI ! Je suis hélas d’accord avec lui, mais pour une toute autre raison : C’est une sorte de perversion de l’agilité pour la transformer en un processus classique tel que l’apprécie nos vieilles DSI poussiéreuses (vous avez dit RUP ?). Pas étonnant qu’il gagne de l’attention.

image

Plus intéressant à mon gré, Vincent nous propose de déconstruire les pratiques de SAFe pour démontrer qu’elles sont effectivement utiles pour appliquer l’agilité à plus grande échelle. La démonstration est convaincante. Je pose toutefois la question : si les pratiques sont individuellement intéressantes et utiles, est-il besoin de les cimenter en un framework ?

Maintenant, on n’a finalement pas parlé du tout de LESS. Petite déception. Mais c’est sans doute parce que l’on ne savait pas en parler…

Hacker un projet pour l’agilifier

Le sujet sur le « hacking de projet agile » nous avait un peu intrigué par son intitulé. Un retour intéressant sur la manière de remettre un projet sur les rails avec des parties prenantes pas évidentes.

image

Mais il faut bien reconnaitre que nous n’avons pas été très inspiré pour échanger dessus. De quoi nous laisser le temps d’aborder le sujet proposé par Géraldine.

Est-il important d’avoir un objectif de Sprint ?

Oui, parfois c’est compliqué de faire rentrer le menu du sprint sous le chapeau d’un objectif ! Aussi est-il légitilme de se se poser la question : est-ce obligatoire ? Qu’est-ce qui se passe si on ne le fait pas ?

Certes, nous avons conclu qu’il est bien plus difficile pour le PO d’être capable d’exprimer cet objectif. Et parfois, ce n’est pas un, mais deux ou trois objectifs !

image

Mais nous avons aussi conclu que cet objectif de sprint apportait deux éléments très liés et complémentaires :

  • Donner un sens à ce que l’on va accomplir dans le sprint. Pas seulement une liste de trucs à faire qui transforme l’équipe en ouvriers spécialisés, mais un vrai but !
  • Permettre de co-construire la façon d’atteindre ce but, entre l’équipe et le PO. Nous parlons d’une dynamique et d’une relation différente. L’équipe n’est plus seulement le volet « réalisation », il s’implique et contribue au côté du PO sur le volet fonctionnel.

Cet objectif de sprint, finalement, n’est-ce pas un moyen d’obtenir les bonnes interactions entre les acteurs qui est la signature de l’agile ? « co-construction » restera le terme important de cette discussion.

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.

Agile Playground #16

L’Agile Playground ne se repose jamais … ou si peu ! Après une rencontre organisée mi-Juillet, on reprend nos bonnes habitudes dès mi-Septembre. Pierrick fait office de grand orchestrateur aujourd’hui. Et il nous propose un mode d’organisation inspiré de l’open-space, avec 2 catégories de propositions :

  • Les jeux que l’on souhaite proposer.
  • Les jeux auxquels on souhaiterait participer.

Le formule marche bien, nous recueillons quelques propositions, largement assez pour animer la soirée, pas trop pour ne pas être obligé de rentrer dans une gestion compliquée ! Voilà dejà une formule que l’on pourra rééditer !

image

Pour cette reprise nous étions un peu plus d’une trentaine de personnes, à vue d’oeil. Comme on dit lors des open-space : les personnes qui sont là sont les bonnes personnes !

image

Le « software ball » que propose Pierrick m’intrigue, ne serait-ce que par son nom : allons-y !

Le Software Ball

Le principe de ce jeu est simple et curieux et finalement pas si facile à saisir ! Les participants sont invités à se lancer une balle selon un schéma défini par le maître de jeu (nous ferons 5 itérations en complexifiant ce schéma). Pour exécuter cela, il faut « programmer » chaque participant avec des instructions en français à suivre très précisément. Elles sont inscrites sur des post-it que l’on colle sur soi.

A chaque itération, nous gagnons 10 points, moins le nombre d’instructions nécessaire pour programmer tout le dispositif (les instructions sont les verbes des phrases). C’est là que ça se gâte, n’est-ce pas ? Ce n’est pas fini ! On a droit au copier-coller et c’est gratuit ! Si 2 participants (ou plus) ont les mêmes instructions, on ne décompte que les instructions d’un seul participant. De même, si l’on garde des instructions entre 2 itérations, c’est aussi gratuit !

image

Bref, c’est quand même compliqué, vous pouvez toujours faire un tour sur le site du Software Ball. Pas mal de perte de temps au début : nous essayons un peu vainement de « bien » conceptualiser la chose avant de commencer. En fait, il est plus simple de se lancer et d’expérimenter sur le tas : nous nous lançons donc à deux pour commencer. Rapidement, après une paire d’itération, nous nous rendons compte que notre implémentation initiale génère des coûts exponentiels, car toute la complexité est sur le rôle du « lanceur-dispatcheur » qu’il faut réimplémenter à chaque fois ! Peitit moment de reflexion.

image

Nous galérons un peu pour passer du mode « push » au mode « pull » où les recepteurs appellent la balle et où il n’y a plus d’intelligence sur le dispatcheur. En effet, les règles stipulent de l’on ne peut pas faire de réutilisation partielle d’implémentation. Nous finissons par trouver le contournement !

Ce jeu a pour but de mettre le doigt sur des pratiques de Craftsmanship. En cela il est tout à fait original ! Il nous permet de reflechir à la réutilisation, au moment adéquat pour changer de stratégie et c’est franchement pas mal. Par contre il est frustrant sur le peu de libertés qu’il nous laisse pour faire des choix de cinématiques de circulation de balle. Je pense aussi qu’il devrait permettre la réutilisation partielle. En synthèse, voici le résultat du débrief.

image

Bref, j’ai bien envie de l’essayer, mais en hackant légèrement les règles !

La balle supersonique

Petite originalité de cette édition : un jeu frugal durant le buffet de fin ! Nous avons pu expérimenter une balle supersonique. Enfin, l’ayant déjà joué à Agile Game France, j’ai passé mon tour !

image

Mention spéciale à Julien qui l’a animé en n’ayant expérimenté la chose qu’une seule fois à Agile France. Il a d’ailleurs un peu hacké les règles en permettant de tenir la balle pendant qu’elle circule ! Je pense ne pas le suivre dans cette voie. Mais il bon d’essayer des choses. Voici de que cela donne

See you later

Toutes les bonnes choses ont une fin. Je coupe court à l’un de mes moments préférés : le buffet et la discussion qui terminent la soirée. Rendez-vous le mois prochain !

image

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é ?

Carnet de route : Agile France 2014 (2/4)

Suite de notre première journée d’Agile France.

On se dirige tout doucement vers l’activité de l’après-midi. Toutefois, nous allons avant cela prendre 10 minutes pour une photo de groupe !

image

Une formule inédite pour cette première après-midi : elle est entièrement consacrée à un open-space ! Cela rapelle un peu la formule du ScrumDay, elle-même inspirée d’Agile Grenoble. Mais peu importe qui emprunte à qui !

Open-space : ouverture !

Pour cette ouverture, nous nous retrouvons tous dans la grande salle Belvédère.

image

Ca fait du monde, vous en serez peut-être plus convaincus avec la vue panoramique ?

image

L’ouverture de cet open-space ressemble d’autant plus à celui du ScrumDay que c’est de nouveau Raphael Pierquin que l’on retrouve aux commandes !

image

Il n’est pas seul, Lan Levi lui donne la réplique.

image

Nous avons de la chance en ce Jeudi après-midi : la météo est avec nous ! On pourra se mettre à l’intérieur des salles et dehors. Dans ces conditions, le Chalet de la Porte Jaune est tout simplement l’endroit idéal pour faire un open-space. La place de marché nous permet d’utiliser tous ces lieux.

image

Qu’est-ce qu’un manager agile ?

J’ai trainé un moment du côté de la session proposée par Alain Buzzacaro sur le manager agile, avec l’envie de confronter mon expérience avec celle des autres, mais aussi d’avoir la perception d’un membre de Codir (ce qui est le cas d’Alain). J’ai vite été déçu par la teneur des échanges. En fait, il m’est apparu qu’une bonne partie de l’assistance n’avait aucune expérience du management. Ca n’empêche pas d’exprimer un avis, visiblement…

image

Parmi les quelques points relevés (histoire que vous ne pensiez pas que je n’ai rien relevé) :

  • L’agilité est un style de management.
  • Le manager est en partie un coach pour son équipe.
  • Son travail est de faire grandir son équipe. Merci Alain !
  • Donner du sens est une dimension importante de son travail.

J’applique la loi des deux pieds et vais voir ailleurs.

L’assertivité

Dommage que je n’ai pu assister depuis le début à la session animée par Mathilde Remy ! Arriver en cours de route m’empêche de bien raccrocher les wagons. Mathilde anime cette session sous forme d’un jeu de rôle.

image

Doublement dommage, d’ailleurs, car Farid se livre à l’exercice : son calme et son rationalisme sont terriblement efficace. J’en sais quelque chose, je l’avais moi-même recruté dans mon équipe il y a quelques années…

Je sens que vous voulez un nouveau petit panoramique ! Allez, hop !

image

Ah oui, n’oublions pas non plus le travail des scribers !

image

Comment amener mon directeur à l’agilité

Cette session est du vécu, un cas réel. Cela m’a semblé intéressant de m’y pencher. Disons, pour diverses raisons…

Au départ, il s’agissait de confronter les expériences, mais finalement nous sommes arrivés à réfléchir autour de ce cas particulier ! Le constat n’apporte pas beaucoup d’espace de manoeuvre :

  • Ce manager n’a pas de problème : pourquoi devrait-il changer ? Rien d’étonnant à ce que l’argumentaire ne porte pas.
  • Est-ce important que ce manager aille dans ce sens ? Ne peut-on « vivre avec » ? C’est hélas important : cette attitude a un impact notable sur l’équipe : démoralisation, départs…

Je ne suis de toute façon pas très bon à cet exercice. S’il fut un temps lointain où je m’y livrais, j’ai abandonné de puis très, très longtemps l’idée de chercher à convaincre des personnes qui n’ont pas envie de l’être.

En fait aujourd’hui je ne cherche plus à convaincre du tout. Ca ne m’intéresse pas, je n’ai pas une vocation de martyre. Je préfère travailler avec des gens qui ont envie d’avancer dans le même sens que moi, avec qui je pourrais me poser des question, que je pourrais aider.

De nouveau, nous avons été scribés en live avec talent !

image

Ces fresques valent largement ma prose, je vous laisse en profiter.

image

Et aussi…

image

Les accords Toltèque

Depuis le temps que j’en entend parler… Je n’ai pas hésité longtemps à rejoindre le petit groupe se formant autour de Frédéric Dufau-Joël sur ce sujet.

Les accords Toltèque nous viennent du peuple éponyme d’Amérique Centrale. Ces accords sont au nombre de 4 :

  • Que votre parole soit impeccable.
  • Quoi qu’il arrive, n’en faites pas une affaire personnelle.
  • Ne faites pas de suppositions.
  • Faites toujours de votre mieux.

Je trahis certainement un peu la chose en disant qu’il s’agit d’une sorte de manifeste de la facilitation … ou même d’une discipline de vie, si j’en crois ce que disent certaines personnes du cercle !

image

Frédéric anime la discussion autour de deux livres écrits par un Chamane Mexicain, Miguel Ruiz, dont le premier est justement le best seller « les 4 accords Toltèque ».

Autres lieux, autres sujets…

On ne peut être partout à la fois. Ailleurs, il y avait aussi :

La définition du bon coach

image

ou encore du théatre d’improvisation, avec Vincent et Simon !

image

Clôture de l’open-space

Nous nous retrouvons une dernière fois en salle Belvédère pour partager nos impressions.

image

L’intelligence collective, par Thibaud Brière

Thibaud est « philosophe en entreprise » ! Je ne savais même pas que cela existait !

Pourquoi s’intéresser à l’intelligence collective, et surtout : pourquoi les grandes entreprises s’y intéressent-elles ? Parce qu’aujourd’hui, elles veulent concilier l’avantage que leur donne leur taille avec la réactivité des startups ! L’intelligence collective est donc un moyen pour être plus adaptable.

Qu’est-ce que l’intelligence collective ?

C’est une dynamique de groupe s’appuyant sur la capacité à diverger. En ce sens, on entretient la pluralité de point de vue plutôt que la convergence, qui est en fait du mimétisme et finalement une abolition du raisonnement. Le point critique est de passer de l’opinion à la pensée ! Cela signifie bien entendu des techniques de facilitation adaptées.

image

Pour Thibaud Brière, la pensée, c’est une opinion (au départ) + la confrontation à d’autres opinions.

L’orateur différentie aussi diversité et variété, une nuance que je ne suis pas parvenu à saisir.

Ce que j’en ai pensé

J’ai retenu deux ou trois choses de cette intervention :

  • Différencier opinion et pensée.
  • Faire fonctionner la divergence (cela me rappelle la keynote de Régis) et valoriser les opinions minoritaires.
  • Encourager l’impertinence.

Je reste un peu sur ma faim. Il faut dire que le format choisit favorisait les interruptions, ce qui n’a peut-être pas aidé (toutes interruptions étaient loin d’être pertinentes).

Au sortir de la cette intervention, les avis étaient très partagés sur l’intérêt de du sujet.

Fin de journée

Pas de diner pour moi, la faute à un gros mal de tête. Visiblement, celui-ci fut bien animé, Alex Boutin s’en est chargé en préparant un quizz durant l’open space !

C’est tout pour aujourd’hui. Rendez-vous très bientôt !