Sandrine : J’ai 25 ans de carrière dont 18 ans dans l’IT avec un parcours typique de développement : je code, je développe, je manage et j’essaye de trouver des approches innovantes.

J’ai vécu 15 ans aux Etats Unis, où j’ai obtenu mon diplôme en informatique et où j’ai découvert l’agile dans la Silicon Valley, au coeur de l’IT et du High Tech : consultante pendant très longtemps, j’étais spécialisée dans l’intervention dans des cellules de crise sur des projets qui allaient mal.

A mon retour en France, j’ai cherché à rencontrer la communauté agile française et j’ai découvert l’équipe d’Agile France, que j’ai tout de suite souhaité rejoindre.

Aujourd’hui je suis coach Lean chez Operae Partners depuis 3 ans : j’interviens sur des projets de tous types et de toutes tailles : de la production informatique, du développement mais aussi du contrôle de gestion, des centres d’appels, des équipes comptables, bref … partout où je peux continuer à apprendre et comprendre comment ça marche !

Je suis également organisatrice du Lean IT Summit qui aura lieu les 22 et 23 novembre prochain.

Audrey : Quand et comment as-tu découvert le lean ? Quel a été le déclencheur qui t’a poussé à devenir coach Lean ?

Sandrine : Avant de découvrir le Lean, j’ai découvert l’Agile il y a dix ans, sur un projet où j’intervenais en tant qu’expert technique pour rattraper certains problèmes avec une équipe de 20 à 25 personnes qui pratiquait déjà l’agile.

A l’époque, le Waterfall était la règle et je commençais à me dire que j’avais choisi le mauvais métier. Or, lorsque je suis rentrée chez moi, après ma première journée avec cette équipe agile, je me suis dit que j’avais enfin découvert quelque chose qui valait le coup d’être vécu !

Toutes les parties prenantes du projet étaient présentes aux stands up meetings, du “product owner”, aux développeurs et testeurs. Pourtant, ces meetings ne duraient pas plus de 30 mn ! J’appréciais cet aspect cérémonieux, réglé et efficace : l’équipe avançait et le projet a finalement été sauvé au bout de 3 mois, après des mois d’échec.

De retour en France, j’ai managé pendant plusieurs années une équipe offshore / inshore dans une grande banque française où j’ai continué à vouloir innover en faisant de l’agile avec l’équipe indienne, de manière itérative : stand up meeting au téléphone, pair programming en ligne, etc … Nous avions réussi à mettre en place quelque chose qui fonctionnait et à continuer à satisfaire nos clients. Mais ce n’était pas sans fournir des efforts supplémentaires, et il restait malgré tout des points que nous n’arrivions pas à améliorer, la distance n’aidant pas.

La DSI ayant eu vent du succès de l’équipe indienne, elle m’a invitée à faire une présentation aux dirigeants, au cours de laquelle j’ai rencontré Marie-Pia Ignace, experte Lean et directrice d’Operae Partners aujourd’hui. C’est elle qui m’a fait remarquer le lien entre ce que je faisais et le lean : on parlait à nos client, on misait sur la qualité, on testait, on expérimentait, on regardait ce qui avait marché, ce qui ne marchait pas…

J’avais lu et adoré le livre de Goldratt, The Goal : A process of Ongoing Improvement, où il est notamment question de flux, de goulet d’étranglement et d’amélioration. De fil en aiguille, je suis arrivé jusqu’au lean, au travers notamment du livre de Michael Ballé, The Gold Mine ». Mais comme dit Michael lui-même, le lean ça ne se lit pas, ça se pratique … de même qu’essayer seul c’est une chose, mais essayer en étant coaché en est une autre !

Lorsque Marie-Pia a monté Operae Partners et m’a invitée à la rejoindre, j’ai hésité car je n’avais pas envie de laisser mon équipe, car il y avait des difficultés qui n’étaient pas résolues et qui ne pouvaient l’être sans accompagnement : il arrive toujours un moment où nous avons besoin de quelqu’un qui sait où mettre la croix, c’est ce qui est intéressant dans l’accompagnement. Et c’est la raison pour laquelle je me suis lancée dans cette aventure lean, avec l’envie d’être coaché par les meilleurs. Dans une entreprise classique, avec des processus rigides, une équipe agile sans soutien managerial ne peut atteindre ses objectifs complètement. J’en avais assez des initiatives qui n’allaient pas jusqu’au bout, et j’avais envie de comprendre pourquoi ça ne marchait pas, d’où l’envie de tout quitter pour devenir coach lean.

Audrey : Lean vs Scrum vs Kanban … la question que l’on doit te poser tout le temps. L’une des trois approches surpasse-t-elle réellement les autres ou pas selon toi ?

Sandrine : J’apprécie les gens qui essaient de nouvelles choses pour améliorer la vie au travail des collaborateurs et la satisfaction de leur client. Mais de ma propre expérience, en Scrum ou en Kanban, c’est souvent l’équipe qui donne le rythme, pas le client.

On donne à l’équipe une boite à outils pour driver tout, mais celle-ci ne solutionnera jamais tout. Elle peut aider à visualiser les goulets d’étranglement et autres problèmes, ce qui est déjà très bien, mais elle ne permet pas d’aller jusqu’au bout du raisonnement : comprendre pourquoi ils existent, comment les résoudre et les éliminer pour de bon.

C’est ce que j’aime dans le Lean : c’est à la fois une approche personnelle qui ne nécessite pas grand chose pour commencer et une méthode rigoureuse qui touche tout le monde dans l’entreprise, y compris les managers. La méthode lean permet aux personnes de l’entreprise d’éliminer les problèmes et de s’assurer qu’ils ne reviennent pas de façon à obtenir des gains durables, tant sur la qualité de vie que sur le niveau de performance des équipes.

Ça ressemble d’ailleurs beaucoup au refactoring dans le code : on revient sur un problème, on ajuste et on retourne sur une bonne base, sans repartir de zéro !

Une des grosses différences avec l’agile est que le lean engage tout le monde dans l’entreprise et touche tous les niveaux. Les managers apprennent à revenir sur le terrain afin de comprendre ce que font les équipes, à poser des questions de challenge et à découvrir les problèmes auxquels les équipes sont confrontées. Ceci entraîne souvent des remises en cause de certaines décisions manageriales mais permet, aussi et surtout, de prendre les bonnes décisions en conséquence. Les équipes, quant à elles, développent une certaine autonomie dans l’organisation de leur travail, dans la mesure de leur performance et dans la résolution de leurs problèmes au quotidien. Ceci leur permet de retrouver une certaine sérénité dans leur travail. De plus, on s’éloigne d’un contexte où le manager joue les « petits chefs » et donne des ordres, plutôt que de guider et soutenir ses équipes. C’est la partie « respect des personnes » du lean qui n’existe pas vraiment dans l’agile.

Le but de la méthode c’est de montrer, pas de forcer, pour que tout le monde se mettent d’accord sur les problèmes et devienne acteur de ce changement. Le Top Down ne fonctionne pas car les personnes qui prennent les décisions opérationnelles ne sont pas les « gens qui font le travail ». Alors avant de sauter à une solution qui coûte cher et qui ne résout pas forcément le problème, on va chercher à savoir où mettre les croix pour trouver celles qui vont faire toute la différence et résoudre le problème de manière rigoureuse grâce au PDCA. Et cela est à la main de l’équipe.

J’ai ainsi pu voir des sponsors qui grâce au Lean ont changé des processus, des descriptions de poste et amélioré la vie de leurs équipes en leur fournissant des nouveaux équipements plus adaptés, par exemple.

Audrey : Dans le speech de ta session, tu annonces que “les personnes deviennent autonomes dans la résolution de leurs problèmes opérationnels et elles aiment ça”. Est-ce réellement à la portée de tout le monde ?

Sandrine : Pourquoi ce problème est-il important ? Qu’est-ce que vous êtes en train de faire pour satisfaire votre client ? Qu’est-ce que vous faites pour améliorer l’entreprise ? Les conditions de travail des personnes ? Quelque soit le niveau dans l’entreprise auquel je les pose, ces questions font toujours réfléchir.

Le Lean, c’est effectivement à la portée de tout le monde car ce n’est pas un outil que l’on installe mais une démarche très personnelle de réflexion sur ses propres problèmes.

Dans un schéma classique, de type waterfall, on retrouve d’un côté des équipes (de production, de développement ou autre) qui sont là pour créer de la valeur et des managers (n+2 ou n+3, car au-dessus le lien avec les opérations est perdu) dont le rôle est de distribuer le travail et de donner les solutions quand il y a crise.

Or les piliers de la méthodologie sont : l’amélioration continue par la résolution de problème et le respect des personnes. Un des objectifs étant l’amélioration des conditions de travail (la sécurité, l’ergonomie, etc) et de la satisfaction des personnes dans leur métier. Cela passe notamment par la prise de conscience de chaque membre de l’équipe qu’il a le droit de réfléchir et d’expérimenter ses propres solutions au travail. C’est redonner aux personnes l’envie de se battre pour réussir. C’est cela le Lean, et c’est pourquoi c’est accessible à tous.

9 fois sur 10 les gens sont contents. Je dis bien 9 fois sur 10, parce que c’est dur : on pose des questions qui dérangent, on amène un gros changement culturel, tout le monde transpire ! Mais la méthode lean permet de passer toutes ces étapes avec une efficacité certaine. On le voit d’ailleurs dans les enquêtes de satisfaction des salariés : ceux qui ont fait du lean mettent plusieurs points en plus.

Audrey : Peux tu te présenter ? Quel est ton parcours professionnel et ta mission actuelle chez Octo Technology ?

Meriem : Meriem Berkane, consultante chez Octo Technology depuis 2007, dans le secteur des médias, internet et loisirs.

Pendant les 5 années passées chez Octo, j’ai effectué des missions diverses : Développement agile, mise en place de bonnes pratiques de développement, etc. Et ce, dans plusieurs technologies : Java/JEE, .Net et récemment de la mobilité et du Web mobile sur la plateforme iOS.

Depuis Septembre 2011, j’accompagne Corsair dans son changement stratégique, à savoir la dématérialisation de ses documents et de ses rapports de vol à bord de ses appareils.

Audrey : Y a t’il des différences majeures entre la création d’application pour un SI traditionnel et un SI mobile ? Si oui, quelles sont-elles ?

Meriem : Dématérialiser la saisie et le traitement de documents et de rapports n’est pas une problématique nouvelle. Bien au contraire, cela a été fait et éprouvé dans bien des organisations et dans bien des domaines, notamment la banque.

La particularité du SI Corsair tient du fait qu’il s’agisse d’une compagnie aérienne. Nos utilisateurs sont, entre-autres, des personnels navigants. Ils sont par définition nomades et ont comme lieu de travail l’avion. Cela veut dire : l’indisponibilité du réseau Internet pendant le vol et parfois au sol, un contact constant avec des clients, une luminosité parfois réduite, des turbulences, et surtout, et avant tout, un vol à assurer! Tous ces éléments sont à prendre en compte quand on dématérialise des documents liés aux vols. C’est la raison pour laquelle une telle dématérialisation n’était pas envisageable avant l’avènement des tablettes mobiles.

Le SI fournit des applications mobiles à ces utilisateurs pour les accompagner pendant leur vol et leur permettre de saisir leurs rapports. Elles sont donc connectées au reste du SI Corsair par des services. Elles fonctionnent également en offline, pour permettre une autonomie aux utilisateurs dans l’avion et dans les destinations n’ayant pas une couverture réseau (Madagascar par exemple).

Par ailleurs, la dotation de tablettes aux personnels navigant apporte des problématiques nouvelles. Protection des données personnelles et d’entreprise, déploiement d’applications à distance, suivi des versions, etc. C’est la raison pour laquelle nous avons mis en place un outil de MDM (Mobile Device Management).

Audrey : Quelles sont les difficultés que tu as rencontrées lors de la mise en place du SI mobile de CorsairFly ?

Meriem : Certaines difficultés ne sont pas spécifiques à l’aspect mobile, mais liées à la dématérialisation. Quand on dématérialise des processus métier, on optimise certes la fluidité et le traitement de l’information, mais on rend le processus de traitement plus rigide. Nous avons donc eu du travail d’accompagnement des utilisateurs dans les nouveaux processus métier.

Un de nos plus gros enjeux aujourd’hui se situe autour du BYOD (Bring Your Own Device). Beaucoup de nos utilisateurs avaient déjà un iPad ou comptent en acquérir un pour leur utilisation personnelle. La protection des données personnelles et d’entreprise, la sécurisation des iPads mais tout en gardant en vue l’utilisabilité et la simplicité pour nos utilisateurs composent nos enjeux d’aujourd’hui.

Audrey : Pour toi cette évolution vers un usage nomade du SI qui a lieu actuellement dans le milieu de l’aérien est elle appelée à se propager à tous les domaines de la vie d’entreprise ? De quelle manière cette transformation affectera-t-elle notre vie de développeur ?

Meriem : Les terminaux mobiles utilisables ont radicalement changé les usages. 50% des accès internet sont faits depuis un terminal mobile aujourd’hui. Nous sommes libérés d’une contrainte, qui est de devoir rester assis sur un bureau et d’avoir un ordinateur pour transmettre ou recevoir de l’information.

Même si le monde de l’entreprise suit plus lentement cette tendance, je pense que les enjeux de la DSI seront de plus en plus liés à l’aspect mobile des utilisateurs et des équipes. Je vous renvoie vers la session USI de Ludovic Cinquin qui s’intitule : Les nouvelles tendances technologiques qui changent les DSI.

Ce que ça change pour nous développeurs? Cela demande de l’organisation, de la rigueur et de l’outillage.

Les utilisateurs mobiles ne sont pas facilement accessibles. Nous, développeurs, devons comprendre le besoin de nos utilisateurs et avons besoin de les observer travailler pour mieux les appréhender. Pour cela, le GEMBA ou le terrain (au sens Lean management du terme) est notre meilleur allié. Une anecdote intéressante à ce sujet : pendant un vol d’observation, j’ai testé la première version d’une application à destination du personnel navigant qui visait à dématérialiser les rapports faits lors d’un vol. Le vol était de nuit, et les passagers étaient endormis. En testant l’application, je me suis rendu compte de l’effet gênant pour les passagers qu’avait le fond clair de l’application, et je l’ai remplacé dès l’itération suivante par un fond foncé. Une telle observation ne peut être faite que sur le terrain, et nulle part ailleurs!

Aller sur le terrain et tester souvent ce que l’on développe implique de livrer souvent (toutes les deux semaines dans notre cas). Livrer souvent à une population nomade, sans lui imposer des nouvelles contraintes implique d’être outillé.  Intégration continue, déploiement continu (outils de Mobile Device Management ou des stores privés comme Appaloosa-store.com), suivi des déploiements etc., sont des outils sur lesquels on doit s’appuyer pour atteindre nos utilisateurs sans leur imposer plus de contraintes.

Enfin, les technologies Web et hybrides sont les technologies de l’avenir. Ce sont les technologies qui s’adaptent à la mouvance que l’on est en train de vivre. Nous développeurs devons nous intéresser en permanence aux enjeux du développement Web, mobile et hybride et notamment les performances (cf. la session de Joshua Bixbie autour des performances Web mobile)