mardi 16 décembre 2014

Simple (épisode 3)

Si vous avez le temps, relisez mes 2 articles sur le sujet : Simple et Simple (épisode 2). Ils datent de 2013, mais rien n'a changé.

Cette fois je vais vous parler d'un article écrit par Jacob Nielsen : User Expertise Stagnates at Low Levels

Résumé : Learning is hard work, and users don't want to do it; they don't explore the user interface and don't know about most features.

Autrement dit, les utilisateurs se servent de ce qui est immédiatement accessible et visible, et ignorent l'existence du reste.

Il semble que - même s'ils utilisent fréquemment une application - ils n'explorent pas ses possibilités, sauf éventuellement au début.

Ca vous parle ? De temps en temps vous "explorez" un peu les applications que vous utilisez quotidiennement, vous ?

Dans les études citées, les utilisateurs ne savent rien des fonctions qui sont juste un brin à l'extérieur du cas d'utilisation minimaliste.

Les solutions proposées :
- moins de fonctionnalités
- des fonctionnalités plus visibles (pas cachées derrière un scroll ou un swipe)
- "visible signifiants" (je n'ai pas trouvé de traduction courte, sorry, mais en gros : si on peut cliquer quelque part, faites que ça se voit...)
- donner des éléments de doc de temps en temps, au bon endroit / moment (astuces, etc.)
- "essayabilité" : pardonnez les erreurs, donnez l'occasion d'explorer sans risques (ceci est aussi valable en dehors d'une application, dans la "vraie vie"...). Mieux : donner un aperçu de ce qui va se passer si vous utilisez telle ou telle fonction.





Si vraiment vous ne savez pas quoi faire de cette journée, essayez d'acheter quelque chose sur le site www.arngren.net ;-)


dimanche 23 novembre 2014

Quelques idées et livres ramenés d'Agile Grenoble 2014


Comme à chaque fois, je reviens d'Agile Grenoble rempli d'énergie (positive, ça va de soi !).

J'ai fait le plein d'idées, des petites choses concrètes à mettre en oeuvre tout de suite (une rétro en mode "appreciative inquiry", par exemple) aux grands concepts.

Rien de super-nouveau, mais des rappels bien sympa.

Un grand grand bravo et merci à Alexandre Gérard (Chronoflex / InovOn) pour sa keynote brillante et inspirante !

J'ai bien aimé la session de Thierry Conter : "Comment donner un souffle d'énergie positive à vos rétrospectives grâce à l'Appreciative Inquiry". Du concret, utilisable tout de suite (déjà utilisé,pour tout vous dire...)

Et je repars d'Agile Grenoble avec deux livres à acheter :




Vivement l'année prochaine !



vendredi 15 novembre 2013

Concours Open PACA

[Mode Auto-satisfaction = on]

Taratata !!! Nous avons gagné le prix co-production citoyenne au concours Open PACA !



Nous, c'est une équipe de 4 coworkers (Sophie, Céline, Yohan et moi) de La Locomotive, l'espace de coworking de Gap lancé depuis 1 an.


"Joue avec ta ville", c'est un concept de jeux basés sur les données ouvertes fournies par une collectivité.

J'aurai certainement l'occasion de vous en dire un peu plus sur le contenu du projet, mais ce qui me semble important, c'est de parler de l'équipe.

Philippe Mussi, le conseiller régional qui nous a remis le prix, l'a mentionné : un projet original et une équipe intéressante avec notamment - pour une fois - a t-il dit - un spécialiste du domaine du jeu pour créer des jeux. En effet, Yohan est ludothécaire et grand joueur, bref un expert "métier" pour ce projet.

Beaucoup de choses me tiennent à coeur dans cette aventure :

- une équipe qui gagne parce qu'elle est pluridisciplinaire et complémentaire
- des rencontres et des échanges intéressants,
- une équipe efficace et qui ne se pose pas de questions inutiles, alors que nous n'avions jamais travaillé ensemble (certains ne s'étaient jamais rencontrés avant ce projet)
- le coworking et la sérendipité qui va avec, ce ne sont pas que des mots
- l'Open Data : comme beaucoup d'autres, je pense que l'ouverture des données est un enjeu important, tant d'un point de vue économique que démocratique
- et surtout : des personnes qui travaillent ensemble sur un projet, sans y être obligées, avec comme seuls objectifs de réfléchir à quelque chose de "chouette" et de se faire plaisir...  ça marche !





dimanche 8 septembre 2013

Etre agile

La session que j'avais proposé à l'Agile Tour Marseille "Dis monsieur, c'est quoi être agile ?" a été retenue.  J'ai animé cet atelier l'année dernière à Agile Grenoble avec Laurence Hanot et je suis très heureux de le refaire.

L'occasion de revenir sur "être agile" vs "faire de l'agile".

Ce sujet me semble plus que jamais d'actualité, à l'heure où tout le monde se dit agile.

Tout le monde ? Non, pas vraiment. Mais - sans revenir sur le sujet de "Agile has cross the chasm or not?" - de très nombreuses entreprises se déclarent agiles.

Le dessin ci-dessous date de 2009 :



et depuis, l'agilité semble avoir continué de s'étendre, regardez par exemple l'évolution du nombre de jobs liés à Scrum :



Les primo-adoptants, les visionnaires et les pragmatiques ont adopté les méthodes agiles, et certains conservateurs aussi (si si je connais des entreprises on ne peut plus conservatrices qui se sont lancées dans l'aventure).  Voir cet article d'Agile Focus, début 2011.

Mais qu'en est-il vraiment ? Je suis tout à fait d'accord avec l'article d'Agile Focus, "I think there is a vast army of supposedly Agile teams and companies that have adopted the look and the lingo while totally missing the point."

Ce n'est pas en saucissonnant le planning du projet en soi-disant itérations (à la fin de laquelle rien n'est livrable), ni en nommant le chef de projet Scrum Master, ni en collant des post-its partout que l'on est agile...

Etre agile, je pense que c'est avoir intégré un certain état d'esprit (humilité, simplicité, pragmatisme, amélioration continue par exemple) et avoir adopté certaines pratiques. Quand je dis intégré et adopté, je veux dire qu'il n'y a plus besoin d'y penser, cela se fait naturellement, c'est devenu votre façon de penser et de travailler.



mardi 27 août 2013

Simple (épisode 2)

Il y a quelques mois, j'ai écrit quelques lignes sur la simplicité en matière de logiciel : Simple : le premier épisode, dans lequel je m'interrogeais alors sur les raisons qui nous poussent à faire plus compliqué que nécessaire.

Mais essayons désormais de voir comment "faire simple".

Lisez "Simplicité et complexité", de Marc Halévy. Quelques extraits (mais lisez l'article en entier !) :

- "Assumer - et magnifier - intégralement la complexité du réel dans la simplicité de l'acte" 
- "Simple ? Minimal. Econome. Frugal. Non pas faire le plus, mais faire le mieux (complexité) avec le moins (simplicité)."
- "Simplicité. Processus intégratif et non pas concaténation additive"

Intégrer et non pas ajouter. Le secret de la simplicité semble être là.

Un produit ne doit pas être une addition, un empilement de fonctionnalités qui utilisées conjointement permettent (ou espèrent permettre) à son utilisateur de réaliser ce qu'il veut faire. Mais le produit doit avoir intégré la compréhension de cette tâche.

Si je crée un produit ayant les fonctions suivantes :
- orienter une roue
- faire tourner une roue à l'aide de pédales
- permettre de s'asseoir
- avertir à l'aide d'une sonnette
ça n'en fait pas pour autant un vélo...  (et pour peu que l'accent ait été mis sur "avertir à l'aide d'une sonnette", on est loin du compte).

Créer un vélo nécessite la compréhension de ce qu'est l'activité. Comme le dit très bien Marc Halévy, on ne peut pas apprendre à faire du vélo sans... en faire :
"La complexité/simplicité, c'est comme l'art de rouler à vélo. Lorsqu'on sait, c'est facile. Mais c'est extrêmement compliqué - voire impossible - à exprimer. On n'apprend pas à rouler à vélo dans les livres, mais bien dans le vécu, dans l'expérientiel. On peut décrire ou expliquer le roulage à vélo, sans savoir soi-même rouler, et ce sera très compliqué. Mais rouler vraiment à vélo, comprendre réellement le roulage à vélo, passent nécessairement par la complexité/simplicité de l'apprentissage direct, par soi-même, au-delà des échecs, des chutes et de éraflures."

Vous ne pouvez donc pas réaliser un produit (simple a fortiori) sans comprendre profondément (ressentir, expérimenter, vivre !) ce que l'utilisateur veut faire avec. Comment ? En s'asseyant à coté de lui, par exemple.
Et préparez vous à ne pas y arriver du premier coup.








jeudi 11 avril 2013

Lean startup, pas pour moi ?

La semaine prochaine, je dispenserai ma première formation Lean startup.

Comment moi, plutôt orienté développement et management,  en suis-je venu à m'intéresser à ce point à ce qui est présenté comme la méthode miracle par les marketers de la Silicon Valley ?

Le moins qu'on puisse dire, c'est que la création de startups et le marketing, ça n'est pas vraiment ce qui m'a occupé ces 20 dernières années...

Lean startup =  "Customer Development" de Steve Blank +  les méthodes agiles.

Le second point, pas de souci. Mais le premier, ça fait un peu plus peur. "Inbound marketing, early adopters, customer lifetime value, etc."
Mais en y regardant d'un peu plus près, sur Wikipedia, par exemple, on trouve cette définition :
"The concept details a scientific approach that can be applied by startups and entrepreneurs to improve their products success by developing a better understanding of their consumers. Primary to the concept is a balanced relationship between developing a product and understanding the customer."

Améliorer les produits et mieux comprendre les clients, en résumé. Donc Lean startup, c'est faire le produit adapté au client en utilisant les méthodes agiles...

Et un développeur pourrait ignorer ça ? Non.

Lean startup favorise la simplicité et la rapidité - voir mon article "Vite un produit" écrit suite à Agile Grenoble 2011 - mais surtout, je crois que cette méthode a beaucoup à nous apprendre sur la façon de faire découvrir aux utilisateurs leurs besoins et le produit qu'il leur faut. Et pas seulement dans le monde du numérique.

Bref, la semaine prochaine, je dispense ma première formation Lean startup.

A cette occasion, j'ai traduit en français le Lean Canvas, merci à Ash Maurya de m'avoir autorisé à le faire. Et si vous avez une meilleure traduction à proposer, je suis preneur !


Si vous souhaitez un modèle "vierge" de Lean Canvas en français, contactez moi (cf. www.36tribus.com).

dimanche 17 février 2013

Simple


Less is More, Keep It Simple Stupid ou encore, en plus littéraire :

"Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher". Antoine de St Exupéry

"La simplicité est la sophistication suprême" Léonard de Vinci

Les principes et les citations vantant les mérites de la simplicité ne manquent pas.

Certains érigent la simplicité en guide principal lors de la conception de leurs produits, mais...


... la plupart des applications ou sites web ressemblent encore à la troisième.

Un petit rappel :

Source : Standish Group - 2009

45 % des fonctionnalités d'un logiciel ne sont jamais utilisées !
7 + 13 = 20 % sont utilisées toujours ou souvent.

Il y a encore du chemin à parcourir pour atteindre la simplicité...

En tant qu'utilisateur, nous préférons les applications simples, non ? Alors pourquoi dès que nous devenons soit créateur soit acheteur d'un produit nous compliquons tout ?

Je ne prétends pas avoir la réponse, mais essayons quelques pistes :

- L'acheteur veut avoir le plus de fonctionnalités possibles pour le montant commandé (un peu comme s'il voulait faire baisser le prix 'au kilo' de la fonctionnalité)
- Le développeur a plein de bonnes idées et ajoute toutes les fonctionnalités possibles (enfin, si elles ne sont pas trop difficiles à réaliser)
- Le concepteur ne sait pas trop quel est le besoin exact des utilisateurs (des quoi ?) et - inconsciemment la plupart du temps - il masque cette ignorance en offrant plein de fonctionnalités (il y en a bien une qui servira)
-... liste à compléter, je vous laisse la parole.





samedi 1 décembre 2012

Découvrir le manifeste agile en jouant

A Agile Grenoble, j'ai animé avec Laurence Hanot "Dis monsieur, c'est quoi être agile ?", une session pour faire découvrir l'agilité au travers de 4 jeux : un par valeur du manifeste.
L'idée vient de Vincent Daviet, qui en avait parlé à Agile Innovation Lyon. Allez visiter son blog : http://babagile.tumblr.com/. ("Un chef de projet, c'est celui qui pense qu'avec 9 femmes on fait un bébé en 1 mois", j'adore.)

Et le lendemain, à Agile Innovation, on a remis ça. On a notamment testé le jeu du "gouter d'anniversaire" que nous n'avions pas eu le temps de faire la veille.
J'avais promis de partager tout ça, c'est (enfin) fait !

Chaque jeu dure 10 minutes, suivi de 5 minutes de discussion, l'objectif étant de tout faire en 1 heure. A vous d'adapter, bien sur.

1 : Le noeud humain - Individus et interactions > Processus et outils

Le jeu le plus simple et le plus rapide à réaliser. Et il fonctionne à chaque fois !

Deux groupes (Peu importe la taille, je pense. Nous avons fait 2 groupes de 8) et un "chef". Manager, chef de projet, chef d'équipe, donnez lui le nom que vous voulez.
Pour que ça fonctionne encore mieux, faites le sortir de la pièce pendant que vous préparez le noeud.

Dans chaque groupe, faire deux rangées, les participants se font face à face. Un dessin vaut mieux qu'un long discours :


Voilà, c'est prêt. Faites entrer le chef. La consigne est la suivante :

- Groupe 1 : "Vous ne faites que ce que le chef vous dit. Pas d'initiatives, surtout ! Suivez la procédure..."
- Groupe 2 : "Débrouillez-vous."


L'objectif : dénouer le noeud sans lacher aucune main et former un cercle où tout le monde se fait face.

En général, il faut quelques secondes au groupe 2 pour réussir, tandis que le groupe 1... Arrêtez-les au bout d'un moment si vous ne voulez pas y passer une heure !

Vous pouvez corser le jeu en ajoutant un analyste, qui va rédiger un document décrivant comment défaire le noeud et qu'il va donner au chef d'équipe qui va faire exécuter ce qui est écrit.

Bref, une équipe auto-organisée, c'est plus efficace.

2 - Artistes et spécifieurs version courte - Logiciel opérationnel > Documentation exhaustive.

Faites plusieurs petits groupes (4 personnes max ?). Dans chaque groupe, il y aura des spécifieurs et des artistes. Mettre les spécifieurs et les artistes dans des pièces différentes.

Le principe : vous montrez aux spécifieurs un dessin, ils doivent écrire des instructions pour que les artistes (qui n'ont pas vu le dessin) le réalisent. Et interdiction de se parler.

Ce jeu est habituellement réalisé en faisant plusieurs itérations, avec rétrospective entre chaque. Et il dure longtemps.

Ici, nous allons le faire en 10 minutes.

Pour la moitié des groupes, scénario classique : ils ont 10 minutes pour rédiger les instructions et dessiner. Souvent, les artistes ne reçoivent les instructions que 2 minutes avant la fin, et ils n'y comprennent rien...

Pour l'autre moitié : ils ont aussi 10 minutes au total, mais ils peuvent faire plusieurs aller-retours : ils rédigent une partie, la donnent aux artistes. Puis ils récupèrent le dessin réalisé et ils ont le droit d'annoter celui-ci. Attention, ils n'ont pas le droit de dessiner, ils peuvent juste écrire et faire des flèches. Ensuite, ils rapportent le dessin annoté et d'autres instructions aux artistes, qui recommencent le dessin.
Et ainsi de suite...

Il faut un dessin facile à dessiner, mais difficile à expliquer. Du genre de celui-ci :


Nous avons pas mal discuté après ce jeu, c'était très intéressant, les participants avaient ressenti beaucoup de choses.

3 - Le goûter d'anniversaire - Collaboration avec le client > Négociation d'un contrat

Nous n'avons pas eu le temps de faire faire ce jeu. Mais nous l'avons testé à Agile Innovation, et c'était intéressant, même si ça reste à améliorer.

Principe : vous (l'animateur) avez besoin d'un prestataire pour organiser le goûter d'anniversaire de votre fils qui a 10 ans et qui veut inviter une dizaine de copains.

Ce que vous demandez au prestataire de prendre en charge :

- Les invitations
- Le plan d'accès
- Les achats
- La décoration
- Le(s) gateau(x)
- Une chasse au trésor
- Un plan B : des jeux d'intérieur en cas de mauvais temps

Deux groupes :
- le premier peut vous poser une seule question (puis vous partez)
- le second peut échanger avec vous (le client) durant toute la durée du jeu (vous vous asseyez à leur table).

Ils ont 10 minutes pour vous donner un devis détaillé.

Nous avons testé ce jeu 2 fois seulement, mais les 2 fois :
- les joueurs du groupe 2 ont très peu impliqué le client (vous), ils ont très peu profité de sa présence.
- le groupe 1 a fourni un devis largement supérieur au groupe 2

J'avais déjà utilisé ce jeu pour présenter le planning poker, il s'y prête bien car il y a plein d'interprétations différentes et des compétences diverses ("le gateau, on l'achète ou on le fait ?").

4 - Marshmallow challenge - Adaptation au changement > Suivi d'un plan

Le classique marshmallow challenge, mais en 10 minutes seulement. Pas de temps de préparation, vous distribuez le matériel à chaque groupe et en avant !

Où est le changement et le plan ? La plupart du temps, il y a une chose qui ne se passe pas comme prévu. Il y a un truc qui n'a pas la caractéristique prévue.



Cette session a visiblement été appréciée, cf. le ROTI :



Voilà, testez et faites nous part de vos expériences !



jeudi 25 octobre 2012

Agilité et culture française : argh...


L'année dernière, j'avais publié un article sur la distance hiérarchique, et la publication aujourd'hui par Jean-Michel Legrand et Eric Le Merdy de Valtech de leur présentation "Et si l'agilité commençait finalement par Kanban ?" me remet tout ça en tête et me donne envie de le partager avec vous.

Geert Hofstede a travaillé sur les différences de culture entre les pays, et sur l'impact que cela a sur le monde du travail.

Il distingue 5 critères :

- La distance hiérarchique (PDI)
- L'individualisme et le collectivisme (IDV)
- La dimension masculine/féminine (MAS)
- Le contrôle de l'incertitude (UAI)
- L'orientation court terme/long terme (LTO)

Il y a de grandes différences entre les pays (vous pouvez voir tout ça sur son site). J'ai pris l'exemple des USA et du Danemark, pour comparer avec la France :

Pour faire bref, en France nous avons :
- une forte distance hiérarchique
- une forte volonté de contrôler, d'éviter les incertitudes. Nous avons un des plus hauts scores sur ce critère !

Ce qu'en dit Geert Hofstede :

Sur la distance hiérarchique :
"With a score of 68, France scores high on the scale of the PDI. It is therefore a society in which inequalities are accepted. Hierarchy is needed if not existential; the superiors may have privileges and are often inaccessible.
The power is highly centralized in France, as well as Paris centralizes administrations, transports etc.
In management, the attitude towards managers is more formal, the information flow is hierarchical. The way information is controlled is even associated with power, therefore unequally distributed."
Sur l'incertitude :
"At 86 France has one the highest scores on the UAI Index. Certainty is often reached through academic work and concepts that can respond for the need of detail, context, and background. Teachings and trainings are more deductive. In management structure, rules and security are welcome and if lacking, it creates stress. Therefore planning is favored, some level of expertise welcome, when change policies on the other hand are considered stressful."


Voici un des schémas de Jean-Michel Legrand et Eric Le Merdy :



Tout ça n'est pas facile à concilier avec l'agilité qui à tendance à minimiser l'importance de la hiérarchie et des procédures et qui favorise l'empirique face au prédictif (voir mon article "Tout prévoir ou composer avec l'incertitude ?" qui parle d'agilité, d'avalanches et de tremblements de terre).

L'agilité en France, difficile :-(