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 !

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 :

Source : www.agilemodeling.com Scott Ambler

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

Source www.indeed.com

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.

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.

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).

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.