Laissez-vous tenter par le LSD

Le développement en mode agile, c’est vraiment bien. Adapté au Lean Startup, c’est mieux ! Un peu de théorie et beaucoup d’expérience.

Lean Startup ?

Le Lean Startup est une approche de conception produit reposant sur un design itératif. L’idée principale est d’apprendre par l’expérimentation.

Le coeur du Lean Startup est de diminuer les coûts tout en améliorant la satisfaction du consommateur / utilisateur.

Plutôt que de se focaliser sur une préparation du produit en amont basée sur des hypothèses imaginées, on se focalise sur le besoin de l’utilisateur, le problème qu’il rencontre et la meilleure manière d’y répondre.

Il y a plein d’ouvrages sur le sujet, dont le fameux Lean Startup de Eric Ries. Wikipedia vous en fera également une présentation synthétique.

Plusieurs spécialistes du sujet publient également sur Medium.

Lean Software Development (LSD)

Le LSD est une approche de la gestion de projet en mode agile parfaitement adapté au Lean Startup. On se focalise sur l’essentiel.

Éliminer le gaspillage

Le gaspillage est chronophage et n’apporte aucune valeur ajoutée.

Quelques sources de gaspillage classiques :

  • faire le travail à moitié (abandon de projet)
  • mettre en place des processes à faible valeur ajoutée
  • ajouter des fonctionnalités non requises
  • multiplier les tâches / passer d’une tâche à une autre sans cesse
  • attendre (mauvaise organisation)
  • les activités purement managériales
  • faire 2 fois le travail
  • mettre en place des solutions inutilement complexes
  • se mettre la pression inutilement
  • le manque de connaissance du sujet
  • la communication inefficace. (réunions sans CR ni ODJ, communication orale)

Ces sources de gaspillage doivent être identifiées par l’équipe et éliminées.

Inutile de chercher des coupables. C’est également contre-productif.

L’idée est vraiment que chaque membre de l’équipe soit vigilant. Que ce soit une habitude, un automatisme.

À titre d’exemple, je viens de passer 3 semaines sur un projet. On a juste défini en 2h ce que l’on voulait dans ce projet. Puis l’équipe s’est lancée et a terminé le projet dans les délais, sans aucune réunion formelle. Seulement des échanges à la pause café.

Améliorer la connaissance

Il est important que l’équipe de développement ait accès à toute l’information nécessaire. Que cette information soit technique ou non.

Et tous les travaux doivent être suffisamment documentés. Pour que chacun ait accès à l’information en temps réel.

Pour reprendre l’exemple de mon dernier projet, nous avons travaillé à systématiquement documenter notre code. Ainsi, chacun pouvait exploiter le code de l’autre sans avoir à le déranger dans son travail.

Également, le temps de formation a été intégré au temps de développement. Ce qui a permis de gagner du temps sur certains aspects techniques.

Décider tardivement

Autrefois, tout était décidé en amont. On faisait de merveilleux plans sur la comète. Et ça ne fonctionnait jamais comme prévu : problème fonctionnel, limitation technique, problème ergonomique, problème juridique. Autant de problèmes qui sont découverts au fur et à mesure du développement.

Le LSD considère d’entrée de jeu que rien n’est prévisible dans le détail.

Par conséquent, cette prise de décision en amont est repoussée. Ce qui permet d’avoir une prise de décision avec la meilleure connaissance possible, et donc évite ainsi les écueils habituels.

Pour reprendre mon exemple, nous savions où nous souhaitions aller d’un point de vue fonctionnel, en termes d’expérience utilisateur. Mais les manières d’y arriver étaient multiples. Nous avons donc engagé les travaux. Et, au fur et à mesure, avons découvert ce qu’il était possible ou non de faire.

Nous avons réussi à atteindre une bonne solution après avoir tâtonné. Mais sans effectuer tout un développement dans la mauvaise direction. Sans essayer de tordre le cou aux techniques recommandées pour les faire rentrer dans le cadre d’un développement dirigé par une prise de décision hypothétique. Tout s’est fait dans les règles de l’art.

Livrer le plus rapidement possible

Dans le domaine de l’innovation, ce sont les plus rapides qui survivent. Les plus efficaces, et non les plus performants.

Plus une fonctionnalité est fournie rapidement, plus rapide sera la confrontation à la réalité. Inutile de discuter pendant 15 jours de pourquoi ça peut fonctionner et pourquoi non. Le meilleur moyen de savoir est de le mettre à disposition des utilisateurs. Au moins un échantillon d’utilisateurs.

Également, cette capacité à rapidement livrer des fonctionnalités permet de rapidement découvrir le travail effectué par les développeurs et ainsi rapidement adapter le design ou tout autre aspect qui aura un impact sur l’utilisateur final.

Inutile d’envisager les pires scenarii : si la solution est conçue dans les règles de l’art, c’est à dire avec un niveau de formation suffisant, tout correctif pourra être rapidement appliqué. Et, surtout, vu que la solution est rapidement confrontée aux utilisateurs, les véritables pires scenarii seront rapidement découverts.

En appliquant une méthode de développement exploitant intelligemment les tests unitaires et les tests fonctionnels automatisés, on peut disposer rapidement d’une solution robuste ne souffrant d’aucune complexité technique.

Dans le cas de mon précédent projet, nous avions en permanence une application fonctionnelle, prête à être testée. Nous avons donc rapidement découvert les incohérences et les incompatibilités techniques. Et nous les avons corrigé immédiatement. Sans perdre de temps à imaginer ce qui allait ou non se passer. Nous nous sommes confronté à la réalité.

Donner du pouvoir à l’équipe

Traditionnellement, on aime mettre une espèce de hiérarchie dans l’équipe. En gros, les managers expliquent aux exécutants comment réaliser leur travail. Évidemment, les managers n’ont aucune connaissance du métier et prennent des décisions complètement hors de la réalité. Au dépens des équipes et du produit.

En mode Lean, on ne considère pas les personnes comme des ressources… mais comme des personnes.

Chaque membre de l’équipe a des compétences qui lui sont propre et a le pouvoir de décision sur son travail. Évidemment, chacun doit assumer ses choix. Mais il ne s’agit pas non plus d’être dans le jugement.

Le leader d’équipe, dont le rôle tourne, est juste un interlocuteur privilégié.

Mais, globalement, si on donne plus de pouvoir et plus de responsabilité à chaque membre de l’équipe, les choses sont plus limpides. Chaque membre de l’équipe est comme un prestataire qui propose un produit à ses collaborateurs. Libre à lui de faire comme il le sent. Du moment que le résultat est là.

Par ma propre expérience, j’ai pu remarquer combien cette approche est bénéfique. Personne ne râle quand les choix ne sont pas imposés. Il faut juste être patient et laisser le temps de formation nécessaire. Ce qui permet d’obtenir des résultats qui dépassent souvent les espérances.

L’importance de la cohérence

Une approche cohérente est essentielle. Il ne faut pas hésiter à consacrer du temps à la réécriture du code si cela est nécessaire. Notamment lorsque l’on ajoute des fonctionnalités.

En général, cette cohérence est au moins en partie donnée par la technologie utilisée. Le développement iOS suit ses propres règles, imposée par Apple et la communauté open-source. Il en va de même sur Android, qui a une approche différente. Et sur le web, où l’approche est encore différente. D’ailleurs, sur des technologies identiques, le choix des outils peut aussi déterminer des règles de fonctionnement.

L’important est que l’approche soit parfaitement cohérente et limpide. Ce qui facilite la compréhension du code et diminue le risque d’erreur.

Dans mon dernier projet, nous avons parfaitement suivi les guidelines iOS, d’un point de vue technique comme ergonomique. Au final, nous avons pu reprendre aisément le code d’un autre développeur. Et nous avons pu intégrer facilement des solutions externes.

Ce qui permet d’être en phase avec une conception de produit efficace.

Une bonne vue d’ensemble

Il est important d’avoir une bonne vue d’ensemble d’un projet en mode lean. Souvent, le développement impose de découper le travail en tâches. Malheureusement, parfois, on s’y perd.

Il est donc important de régulièrement se re-situer dans une vision d’ensemble, pour s’assurer d’aller dans la bonne direction.

Pour cela, l’un de mes collaborateurs a récemment eu la bonne idée d’afficher des post-its avec des titres et des petits dessins. C’est imagé et très efficace. Un coup d’oeil, même sans lire, permet de se re-situer dans le projet.

La boîte à outils LSD

L’approche LSD ne nécessite pas 50 outils. Il s’agit juste d’outils simplifiant la démarche.

Par exemple :

L’essentiel s’appuie sur beaucoup de bon sens. Et une communication efficace et respectueuse entre les membres de l’équipe.

Vous pouvez également me suivre sur Twitter et LinkedIn
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.