La facilitation en kit

Ce “falititator toolkit” donne de nombreuses clés pour appréhender et focaliser la dynamique des groupes. Plus qu’un simple article, il s’agit-là d’un mini-book regroupant le “best of” des auteurs en matière de facilitation. J’ai apprécié la concision et l’efficacité du propos dans chacune des parties abordées:

Le rôle du facilitateur : en une seule page, les responsabilités et ses challenges !

La dynamique de groupe : elle s’articule autour du modèle de Tuckman, reprends la liste des bons et des mauvais comportements et les schémas d’intervention.Le tout en moins de 5 pages.

Idéation et consensus : on aborde ici le coeur de l’ouvrage et les outils qui le constitue : l’art de l’écoute, le “focused conversation”, “appreciative inquiry”, Le brainstorm, le consensus, le processus d’affinité. On a du mal à se rendre compte que l’on a couvert tout ça en 11 pages !

Les réunions efficaces : On balaye les états d’esprit, la check-list (avant, pendant et après), les rôles et règles et les comportements. J’aurais cru cette partie plus riche, mais là encore ce chapitre ne fait que 6 pages.
Gestion de projet: Une page … dont je ne comprend pas ce qu’elle fait là !
Stakeholders input tools : Elles tournent beaucoup autour du Focus group et un peu autour du Web Survey (plus pour faire la pub d’un outil dirait-on). En 6 pages, c’est quand même bien.

Outils pour collecter et analyser les données : quelques outils sont proposés, ils sont bons à rappeler même s’ils sont assez classiques : check sheet, importance / satisfaction diagrams, analyse causale, diagrammes d’interrelation, analyse SWOT.
Flowcharting: Il est assez curieux de trouver ici ces 3 pages sur les flow charts diagrams ici. Cela a bien peu à voir avec la facilitation proprement dite…

Outils de prise de décision : Sans être mortel, ce chapitre nous donne ou rappelle quelques outils : matrice de critères, analyse “force field”, Notation 0 à 10, matrice impact / effort.

Mesurer les impacts : On est plus ici dans la déclaration d’intention. Ou plus exactement, il s’agit d’introduire le matériel fourni en annexe qui d’ailleurs vaut aussi bien le coup !

Bref un papier remarquable qu’il serait dommage de négliger, même si 2 ou 3 parties sont un peu plus faibles ou n’ont simplement pas leur place.

La plupart des outils sont décrits de manière introductive, voir un peu plus. En fait, ce qui est fourni ici est largement suffisant pour démarrer, mais les auteurs donnent aussi les pointeurs pour aller plus loin !

Bonne lecture !

Un meetup sur les jeux Kanban avec le FKUG

Retenu à Caen par le printemps agile, je n’étais hélas pas là pour ce second meetup du FKUG consacré aux jeux Kanban, et hébergé chez Criteo. Cette vidéo vous donnera un bref apperçu de ce qui s’est passé durant ce meetup. Grand merci à Gwenael Bonhommeau pour son excellent travail !

Mon CR du premier meetup est ici.

Molecular Structure of Nucleic Acids

Un article qui marque l’histoire des sciences n’est pas nécessairement un monument. L’article original de Watson et Crick décrivant la structure de l’ADN, la fameuse double hélice tient en un peu moins de deux pages de l’édition de Nature datant du 25 Avril 1953. Il vaudra aux deux auteurs associés à Wilkins, le prix Nobel de médecine en 1962.

Pour l’anecdote, le dessin de la double hélice est dû à Odile Crick, la femme de l’un des auteurs, peintre de profession. Ce dessin est par ailleurs la seule oeuvre pour laquelle elle est connue.

Moins drôle : le point de départ de l’article de Watson et Crick est une photographie, connue sous le nom de “photo 51”, prise par Rosalyn Franklin, que Wilkins a montré aux deux auteurs sans en informer sa collègue ! Voici la photo en question

image

Rosalyn Franklin apparait uniquement dans les remerciements de l’article, une bien piètre reconnaissance de sa contribution par ailleurs involontaire !

How Spotify Builds Products

J’avais posté il y a quelques temps un lien vers l’article d’Henrik Kniberg à propos du scaling chez Spotify. Cet article expose la manière “lean startup” dont les produits sont pensés et évoluent :

  • Think it : on a une idée !
  • Build it : on construit un MVP.
  • Ship it : On le met en production.
  • Tweak it : Puis on l’améliore continuellement.

C’est même un Kanban au niveau de la société qui permet de visualiser la totalité des projets et leur état d’avancement.

Think it

Lorsque quelqu’un arrive avec une nouvelle idée, il peut former une petite “squad” (typiquement 3 personnes) s’il a le feu vert de la direction afin de développer celle-ci, typiquement sous forme de prototype. Il s’agit de répondre aux questions : pourquoi devons-nous construire ce produit et pour qui ? Quel va être la mesure du succès ? Bref, une vraie démarche Lean Startup dans l’esprit !

La partie la plus importante est un narratif qui est développé avant que le produit soit développé. De nombreuses maquettes (papier ou non) sont souvent élaborés en parallèle.

Le “done” est accompli lorsque le management décide que le produit vaut le coup. Cela est fait de manière subjective, sans épauler cela de chiffres ou d’études de marché. Cela viendra plus tard, dans le “ship it” !

Build it !

C’est la construction du produit, conduit en agile (Scrum, XP, Kanban) avec un squad plus étoffé. Parfois même plusieurs squad. L’objectif est la création du MVP.

Le MVP est un équilibre délicat entre un proto qualifié d’embarrassant, en tout cas pas assez abouti pour être mis dans les mains des utilisateurs et un produit standard, bien trop coûteux pour un premier jet. Pour Spotify, MVP signifie Minimum Loveable Product, qui soit “narrative complete”, plutôt que “feature complete”.

Le “done” est atteint quand le squad et le management pensent que le produit est assez bon pour passer en production.

Ship it

Il s’agit de déployer progressivement le produit vers 100% des utilisateurs. On commence par le déployer vers un petit échantillon d’utilisateurs, et c’est là que l’on commence à vérifier nos hypothèses initiales. Le processus standard est d’effectuer des itérations pour opérer des ajustements.

Le “done” est atteint lorsque le produit est déployé vers 100% des utilisateurs.

Tweak it

C’est la phase la plus importante. Le produit peut être amélioré de nombreuses façon. Le squad opère des évolutions via de l’A/B testing et le suivi des métriques d’utilisation. A un certain point le produit atteint un optimum local et les nouvelles fonctionnalités n’ajoutent guère de valeur au produit. Soit le squad passe progressivement vers un nouveau projet, soit l’on rentre dans une phase de “re-think” pour changer dramatiquement le produit.

Le MacIntosh dévoilé : c’était il y a 30 ans !

La machine emblématique d’Apple a fêté ses 30 ans il y a peu.

La présentation officielle du MacIntosh du 25 Janvier 1984 est certainement le moment le plus connu. Mais il fut précédé d’une présentation aux actionnaires un jour avant ! C’est ce que montre cette video, hélas de très mauvaise qualité ! Vous pouvez sauter l’introduction et aller directement vers 36’30 où débute ce qui nous intéresse réellement. Sinon la video visible depuis Techland (dont vous trouverez le lien plus haut) vous donnera un support de meilleure qualité.

The Scrum Primer

Plus étoffé que le Scrum en 5 minutes, ce “primer” donne une vision plus précise de Scrum, mais aussi plus subjectives, car elle intègre des pratiques qui, si elles sont généralement acceptées" ne font pas partie de le définition stricte de Scrum. L’article présente aussi l’avantage d’être abondemment illustré de photos mais aussi de représentations d’artefacts tels que les auteurs les utilisent sur leurs projets (je reconnais au moins l’un d’eux que j’avais hérité de Craig Larman).

Avec ses 22 pages et une police plus classique, c’est plutôt 1 heure, voir plus, qu’il vous faudra consacrer à cette lecture. Le public n’est donc pas le manager très occupé. De plus certaines techniques comme les réestimations systématiques ou le burndown ne font pas nécessairement partie de votre processus.

Ce primer figure aussi en annexe du livre co-écrit par Craig Larman : Scaling Lean & Agile Development.

La boite à outil du coach agile

Besoin d’étoffer votre boite à outil de coaching ? Voici des conseils avisés de la part de nos pairs !

Des outils de coaching pour améliorer la dynamique de votre équipe

Cette présentation de JF Hélie et Guillaume Duquesnay a été donnée à Agile France 2012

20 coaching tips in my agile suitcase

Cette fois c’est Yves Hanoulles qui nous délivre une série de recommandations.

Agile coaching workshop

Workshop monté par Craig Smith

Du chef de projet au coach agile

Ces deux vidéos nous ont propos&ées par Lissa Adkins. Il s’agit d’une retranscription d’un workshop donné à Chicogo en 2008 lors d’un Scrum GatherinG

Il s’agit de réflexions à propos de ce que cela signifie réellement de devenir coach agile.

Solution focus

S’intéresser à la solution plutôt qu’au problème et en rechercher les prémisses dans la réalité présente, tel est la ligne directrice du Solution Focus. Vous pouvez aussi vous reporter à la note de lecture que j’avais rédigé sur Coaching Plain & Simple.

Wu Wei Coaching

Je le place ici par pure curiosité. Car en fait, je n’ai toujours pas compris de quoi il retournait ! “Wu Wei” signifie “sans action”. Et en fait, comme il est indiqué à la fin de cette présentation, celle-ci ne vous aidera pas à comprendre ce que c’est !

Réflexions sur la pensée agile, par Tobias Mayer

La keynote de cloture de l’auteur de The People’s Scrum lors d’Agile Spain 2013 évoque le “Business Craftmanship”, qui est également le titre de son blog. Tobias se centre et approfondis les fondement de la pensée agile. “people before process and tools” est une valeur dont on s’éloigne parfois sans même y penser. Tobias nous le rappelle !

Tobias était aussi présent à Agile EE pour évoquer les valeurs du “Tought Citizen”. Il nous parle d’inconfort, de courage et de “deep dialog”.