All Posts by Lothon Florent

20

Introduction à Holacracy

La première claque professionnelle que j'ai pu recevoir en terme de remise en question sur la façon de travailler était la découverte des méthodes agiles en 2007. Depuis, c'est devenu une passion, un véritable levier de réussite sur les projets confiés aux équipes que j'accompagne dans l'apprentissage de cette approche. Et j'irai même jusqu'à dire, un art de vivre basé sur les valeurs et principes agiles. Cette année, soit 9 ans plus tard, je reçois une seconde claque. La découverte de Holacracy.

C'est cette découverte que je souhaite partager dans ce nouvel article. Le premier d'une série sur le même thème sans doute. Ca dépendra surtout de vous (cf. message en bas de cet article) 😉

Pour précision, j'utilise le terme Holacracy plutôt que la traduction française Holacratie car Holacracy est désormais une marque. A travers le dépôt de cette marque, les créateurs ont souhaité protéger l'intégrité et la qualité des services associés. Le contenu quant à lui est open source. De la même façon que Linux est une marque.

Allons au delà des idées reçues

Heureusement, ma curiosité et ma soif d'apprendre a été plus forte que les idées reçues ou intox qui gravitent autour de cette nouvelle technologie sociale et managériale qui fait polémique. L'idée reçue la plus répandue étant : "Avec Holacracy, on vire les chefs et c'est l'anarchie". C'est bel et bien une idée reçue.

Holacracy, successeur des méthodes agiles ?

Autre bonne nouvelle, Holacracy ne remplace pas les méthodes agiles pour ceux qui les utilisent. Au contraire, les équipes réellement agiles - dans le respect des valeurs et principes du manifeste agile - bénéficient d'un terreau fertile à l'adoption de Holacracy. En fait Holacracy revient à changer le "système d'exploitation" de l'organisation sur laquelle on peut conserver les "applications" utilisées (dont les méthodes agiles).

Autrement dit, le changement est plus profond. Je dirais que les méthodes agiles font l'objet d'un changement de paradigme en matière de gestion de produit et Holacracy fait l'objet d'un changement de paradigme de l'organisation qui l'adopte. L'agilité se positionne principalement à l'échelle d'une équipe ou projet là où Holacraty peut nativement s'appliquer à toute l'entreprise quelque soit sa taille ou son secteur.

Connaître les origines de Holacracy pour mieux cerner son potentiel

Pour aider à comprendre ce point, il y a une histoire à connaître. Celle de l'origine de Holacracy. Cette technologie sociale et managériale a été mise au point par des agilistes aguerris qui ont décidé de créer leur entreprise. Mais hors de question pour eux de travailler au sein d'une organisation similaire à celles dans lesquelles ou pour lesquelles ils avaient travaillé. Qui représente - il faut bien le dire - quelques inconvénients notoires (cf. illustration ci contre).

Ils devaient trouver un nouveau modèle d'organisation. L'inventer. On peut facilement imaginer l'ampleur et la complexité de la tâche. Ils ont donc eu recours au meilleur outil utilisé par les méthodes agiles pour faire face à la complexité et l'incertitude : un processus empirique. Pendant 7 ans, ils ont testé des idées, gardé ces dernières si elles s'avéraient utiles, les ont rejeté ou adapté dans le cas inverse. Pour aboutir à une première version publiée et partagée en 2009. Inutile de préciser le degré de pragmatisme et d'efficacité de cette technologie conçue selon une telle approche.

Une technologie applicable à n'importe quel secteur, n'importe quelle échelle et tenant compte des réalités du monde d'aujourd'hui devenu si complexe et incertain. Une technologie pouvant donner à une entreprise un degré d'agilité sans précédent tout en libérant les énergies et l'engagement des collaborateurs. Chacun y trouve donc son compte. Direction, actionnaires et collaborateurs.

Mais Holacracy ou l'holacratie, c'est quoi au juste ?

Holacracy, c'est quoi encore ce non barbare ? Il vient du mot "holarchie" qui décrit l'encapsulation d'élément(s) autonome(s) dans d'autres élément(s) autonomes de façon fractale. Ce qui caractérise une organisation holarchique par opposition à une organisation hiérarchique classique.

Quid du manager et du leadership en Holacracy ?

Etant particulièrement sensible au thème du management et étant moi même manager, la question de la place du manager dans une organisation fonctionnant en Holacracy n'a cessé de m'obséder durant les lectures et formations que j'ai pu suivre à propos de cette technologie. Avant d'y répondre, faisons un petit état des lieux des responsabilités généralement associées au manager dans le monde d'aujourd'hui.

Pour commencer, lorsque l'on devient manager, nous ne sommes plus seulement responsable de nous même mais aussi des autres, de son équipe. Nous devons donc fixer des objectifs, contrôler le travail et assurer le reporting de l'activité associée, au niveau hiérarchique supérieur. On prend généralement des engagements de délais voire de budget à respecter. On assure le suivi "RH" de ses collaborateurs : évolution de carrière, formation, augmentations & primes, etc. Nous devons souvent intervenir pour gérer toutes sortes de problèmes organisationnels, techniques, humains, etc. Bien sûr, nous devons définir la meilleure organisation possible pour être efficace. Parfois ou souvent, nous devons mettre à profit notre expertise pour des sujets pointus ou à fort enjeux. On attend souvent de la part du manager qu'il ait réponse à tout. Omniscient et omnipotent. Par ailleurs, dans le monde d'aujourd'hui, chaque service devient de plus en plus dépendant des autres,  la transversalité devient un enjeux fort, nous devons également assurer la coordination avec nos pairs et leurs équipes. Nous devons aussi faire redescendre l'information venant d'en haut et des "côtés" (autres équipes).

C'est déjà pas mal non ? Est ce bien raisonnable d'ailleurs ? Ne sommes nous pas en train de demander à ce manager d'être un véritable super héros (sans les super pouvoirs....) ?

Combien de temps reste t'il à ce manager - qui passe probablement beaucoup de temps à traiter ses mails ou en réunion - pour écouter les difficultés ou idées d'amélioration de son équipe pour les traiter ou les mettre en oeuvre ? Et quid de notre monde qui bouge et pousse les entreprises à se transformer en profondeur ? N'a t'on pas cruellement besoin des managers pour réaliser cette transformation ? Comment faire avec des managers saturés et souvent en souffrance ?

La réponse de Holacracy à ce problème ? Décharger le manager des tâches sur lequel sa valeur ajoutée est faible et remettre à profit son expertise pour des tâches à plus forte valeur ajoutée pour l'entreprise et lui même.

Ok, c'est bien beau tout ça, mais on arrive à la fin de l'article et on n'en sait pas beaucoup plus sur le fonctionnement concret de Holacracy. En effet, c'est ce que nous verrons dans un prochain article maintenant qu'on vient de poser le décor 😉

D'ici là, dites moi - via le formulaire situé en bas de cette page - ce que vous voulez absolument savoir à propos de Holacracy. J'essaierai de vous répondre au mieux dans le prochain article ou directement dans les commentaires.​

2

MOOC L’entreprise agile

Un MOOC pour faire passer les organisations dans l’ère du digital

La révolution digitale, couplée à la mondialisation, rendent le monde de plus en plus complexe et donc incertain pour les entreprises, qui doivent également composer avec les nouvelles attentes des jeunes générations de collaborateurs.

Dans cet environnement, il s’agit pour elles de réaliser le bon produit au bon moment, malgré les imprévus, qui ne manquent pas d’arriver : innovations technologiques permanentes, cadres réglementaires mouvants, écosystème concurrentiel dynamique etc. A cela s’ajoute la difficulté, voire l’impossibilité à cerner précisément le besoin du client en amont du projet, qu’il soit interne ou externe.

Les méthodes agiles offrent une réponse adaptée : apparues au début des années 1990 dans le cadre de projets de développement avant de s’étendre à d’autres contextes. L’approche offre de nouveaux leviers de réussite et permet d’intégrer le client tout au long du processus, tout en offrant la souplesse nécessaire pour aboutir à une solution sur mesure par rapports à ses réelles attentes. Tout en réduisant les risques du projet au plus tôt, en créant des opportunités de réduction du délai de mise sur le marché ainsi qu’un environnement de travail motivant pour un engagement maximal des employés. Ça peut paraître trop beau pour être vrai, mais c’est une réalité pour beaucoup d’entreprises désormais. Un atout considérable sur la concurrence “non agile”.

Pour passer à l’échelle, ces pratiques et d’autres, ainsi que l’état d’esprit associé se doivent d’être diffusées à tous les niveaux hiérarchiques de l’entreprise et dans différents services bien au delà des équipes informatiques : une transformation d’ampleur, qui implique pour les collaborateurs de changer leurs habitudes et leur mode de fonctionnement classique. C’est cette transformation que le MOOC “L’entreprise agile” de Unow, en partenariat avec Onepoint et L’Agiliste, a pour ambition d’accompagner.

MOOC “L’entreprise agile” - Lancement le 14 novembre

Qu’est ce qu’une entreprise agile ? Quel est le rôle du manager ? Quels sont les outils permettant davantage d’agilité au sein des équipes ? Comment entraîner l’ensemble de ses collaborateurs vers plus d’agilité ? etc. Ce MOOC Entreprise Agile, proposé par Unow en partenariat avec le groupe One Point et L’Agiliste, qui débutera le 14 novembre prochain, entend bien répondre à l’ensemble de ces questions.

Pour en savoir plus : MOOC Entreprise Agile

9

5 idées reçues sur la gestion de projet agile

Les idées reçues à propos de la gestion de projet agile ou des méthodes agiles ne manquent pas et peuvent vous éloigner des bénéfices que vous pouvez en attendre. Avouez que ce serait dommage. A l'issue de cet article, vous pourrez vous faire votre propre idée.

Idée reçue n°1 : L'Agilité est une mode

Si l'on considère les méthodes agiles comme de simples méthodes, on peut se dire que c'est juste une mode qui passera. Après tout, des méthodes, on en a vu défiler. En réalité, les méthodes agiles sont bien plus que cela. D'une part, elles véhiculent des valeurs et principes fondamentaux - de management notamment - qui font d'elles un véritable état d'esprit, et d'autre part elles font l'objet d'un véritable changement de paradigme. A tel point qu'une ne devrait pas parler de gestion de projet pour qualifier cette approche mais de gestion de produit.

Le conditionnement du "mode projet" nous pousse à nous focaliser - parfois jusqu'à l'obsession - sur des critères de succès relevant du respect du délais, budget, périmètre... et qualité quand on ne la sacrifie pas au profit des premier critères. Et le produit alors ? Et la satisfaction des utilisateurs ? En mode agile, on se centre sur le produit et le but du jeu ne consiste pas à couvrir tous les besoins exprimés dans un cahier des charges initial qui sera tôt ou tard en déphasage avec le principe de réalité (cf. réelles attentes des "vrais" utilisateurs, évolutions réglementaires, nouvelles idées de fonctionnalités découvertes en cours de route, imprévus techniques, etc). Il consiste plutôt à satisfaire les utilisateurs et enjeux business associés avec le minimum de fonctionnalités.

On ne peut donc pas parler d'un effet de mode pour qualifier un tel changement de paradigme. D'autre part le mouvement agile est un mouvement de fond qui remonte à 2001, année de parution du manifeste agile, voire au delà, puisque la publication du cadre méthodologique agile le plus utilisé, Scrum, remonte à 1993. Un mouvement qui prend toujours plus d'ampleur malgré quelques dérives (certifications bidons, formateurs sans réelle expérience en gestion de projet agile, pratiques de développement agiles négligées, etc).

Idée reçue n°2 : L'Agilité, c'est l'anarchie

Cette idée reçue provient souvent d'une lecture un peu trop hâtive du manifeste agile décrivant les 4 valeurs et 12 principes communes aux différentes méthodes agiles.

4 valeurs qui consistent à privilégier les hommes et leurs interactions par rapport aux processus et aux outils car les projets sont devenus trop complexes pour interagir uniquement à travers des outils ou processus. A privilégier la réalisation d'un produit utilisable plutôt qu'une documentation exhaustive ou pléthorique, à privilégier la collaboration avec les clients plutôt que la négociation contractuelle et enfin l'adaptation au changement plutôt que le suivi d'un plan. Mais le manifeste ne s'arrête pas là, il ajoute : Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

Autrement dit sur des projets agiles, il y a bien sûr des processus, Scrum en est un (très simple mais c'est un processus), des outils (il existe désormais pléthore d'outils de gestion de projet agile), de la documentation (il faut bien à minima capitaliser les connaissances requises pour la maintenance du produit et sa pérennité), des contrats (il existe même des contrats agiles "gagnant/gagnant") ainsi que des plans macro et beaucoup de planification (planification à 3 niveaux : long, moyen et court terme pour s'adapter aux changements).

J'ajouterai, que la gestion de projet agile exige bien plus de discipline et de rigueur que l'approche classique. A titre d'exemple, l'équipe d'un projet agile doit être capable de produire de nouvelles fonctionnalités potentiellement livrables aux utilisateurs à la fin de chaque itération dont la durée est très courte. 2 semaines en moyenne.

Idée reçue n°3 : L'Agilité, c'est pas pour les gros projets

Autre idée reçue liée au fait que les méthodes agiles et Scrum en particulier préconisent généralement une taille d'équipe inférieure à 10 personnes. Pour des raisons d'optimisation de "coûts" de coordination notamment. Une limitation qui n'est pas issue de la théorie mais de l'empirisme. Seul véritable moyen de parvenir à une méthodologie pragmatique adaptée aux réalités du terrain. Bien que cette recommandation de taille s'applique à une équipe, rien n'empêche de faire travailler plusieurs équipes de moins de 10 personnes. Il existe même des frameworks éprouvés de gestion de projet agile à grande échelle.

Idée reçue n°4 : L'Agilité, c'est uniquement pour les projets de développement logiciel

Nul doute que les méthodes agiles proviennent du secteur du développement logiciel. Cependant, on voit désormais Scrum (par exemple) utilisé sur des projets industriels, hardware ou encore dans l'éducation. Pour une raison simple, c'est que Scrum n'est qu'un cadre méthodologique léger et adaptable à toutes sortes de contextes projets. Il nous laisse toute liberté d'y intégrer les pratiques et techniques propres à notre contexte. Au point de nous déstabiliser au début car on a l'habitude d'attendre d'une méthode, la réponse à tous les problèmes et tous les cas de figure. Scrum est un cadre méthodologique, pas une méthode.

Idée reçue n° 5 : L'Agilité, ça marche qu'avec des bons et si tout le monde joue le jeu

Bien amenée, les méthodes agiles peuvent satisfaire aussi bien le top management que les acteurs de terrain. Car il se trouve que pour bénéficier des 8 leviers de réussite de la gestion de projet agile, il faut émanciper et respecter les acteurs de terrain : confiance, soutien, auto-organisation, rythme soutenable. Le manager quant à lui (ou chef de projet), généralement en surcharge, sera déchargé de certaines activités pesantes telles que les aspects planning et organisation du travail pour se concentrer sur la gestion des ressources, le leadership et le coaching des membres de son équipe pour développer leur potentiel, les faire grandir.

Mais si tout le monde ne joue pas le jeu ? L'important est surtout d'avoir un noyau dur de personnes prêtes à tenter l'aventure et un "sachant" agile déterminé à introduire l'agilité, notamment à travers le coaching des acteurs. Le niveau de compétences techniques des membres de l'équipe n'a pas davantage ou moins d'importance que sur un autre projet. De toute façon, tout le monde aura l'occasion de développer ses compétences.

Conclusion

Finalement, la seule véritable incompatibilité avec l'agilité serait une culture en conflit avec celle de l'agilité. Autrement dit avec les 4 valeurs et 12 principes du manifeste agile. Et là encore, il faut bien se dire que la culture d'une organisation peut évoluer. Il faudra peut être commencer par un premier projet pilote avec un sponsor fort qui adhère à la culture agile, a bien perçu les gains à tirer de l'agilité et saura démontrer ces gains en cas de succès du pilote pour faire basculer par la suite le reste de l'organisation.

​Et vous, voyez vous d'autres blocages liés à l'adoption des méthodes agiles ?

Déposez un commentaire en bas de cette page.

Déjà 1000 abonnés, ça se fête !

Déjà plus de 1000 abonnés à la newsletter

Nous sommes désormais plus de 1000 personnes à partager un intérêt commun pour les méthodes agiles au travers de la Newsletter de L'Agiliste. Ce qui - je ne le cache pas - me fait extrêmement plaisir, compte tenu de la raison d'être de ce site. J'ai créé L'Agiliste, dans le but de partager avec un maximum de monde ces méthodes agiles qui ont définitivement changé ma façon de mener et vivre un projet.

L'Agiliste 3.0 + Un Webinaire Gratuit

Pour fêter cet événement, j'ai décidé de m'attaquer à une nouvelle refonte totale du site L'Agiliste. Afin de rendre ce dernier encore plus utile et agréable à consulter. Et ce, sur n'importe quel appareil. J'ai encore un peu de travail, mais il y a de bonnes chances pour qu'il soit en ligne avant la fin du mois.

Et ce n'est pas tout. J'ai également prévu d'animer un webinaire (séminaire en ligne) gratuit dans lequel je vais vous expliquer en quoi, CONCRÈTEMENT, les méthodes agiles et Scrum en particulier démultiplient les chances de réussite de mes projets, quels qu'ils soient. Ce sera aussi l'occasion de répondre personnellement à vos questions. Le créneau prévu pour ce webinaire est celui du mardi 15 septembre de 18h à 19h.

Bref, surveillez votre boite mail et bloquez votre agenda 😉

Vous n'êtes pas encore inscrit à la newsletter ? L'inscription est dans la colonne de droite (ou plus bas si vous êtes sur votre smartphone).

Nouveau site de CaptainSPOC

Pour rappel, dans le but de réaliser des formations agiles innovantes et à la pointe, j'ai décidé de m'associer à CaptainSPOC. Une startup pionnière et leader en création de formations de nouvelle génération. Or l'équipe de CaptainSPOC a également refondu son site qui recense ses formations au format SPOC (Small Private Online Course).

Dont mes 2 formations agiles :

Je vous recommande chaudement de visiter le site CaptainSPOC. Et de visionner en particulier la vidéo de 3 minutes de la page d'accueil qui vous explique de façon illustrée en quoi ces formations d'un nouveau genre améliorent la vie des apprenants et la transformation des entreprises à l'heure du digital.

SPOC : 3 minutes pour tout comprendre (Vidéo)

Il reste des places...

J'en profite pour vous préciser que le programme de formation & coaching d'initiation à Scrum et de découverte des méthodes agiles qui démarre le du 21 septembre est confirmée. Puisque nous avons dépassé le nombre minimum de participants. Et il reste des places. Profitez en maintenant.

A très bientôt,
Florent

1

Gestion de Projet Simple (GPS)

Introduction

Cet article vise à décrire un cadre méthodologique de gestion de projet simple. Il s’adresse à toute association de personnes (équipe) désireuses de mener un projet quel qu’il soit aboutissant à ce qu’on appellera par abus de langage un “Produit”. Les membres de l’équipe peuvent travailler à temps plein ou partiel, partager un même lieu de travail ou non et participer à l’ensemble des étapes du projet avec ou sans hiérarchie.

Étapes du projet

Définir la vision du “Produit”

Le projet débute par la formalisation de la vision du “produit fini” faisant l’objet du projet. Elle a pour principal objectif de mettre l’ensemble des acteurs sur la même longueur d’onde et de les guider dans les choix et les décisions qu’ils seront amenés à prendre tout au long du projet. Le travail sur la vision consiste principalement à répondre aux questions « Pourquoi réalise t’on ce produit ? », « A quel public s’adresse t’il ? », etc.

Construire et ordonnancer le “Product Backlog”

Une fois que la vision est partagée et claire pour tout le monde, il est temps de faire la liste de toutes les tâches – connues à date – nécessaires à la réalisation du “Produit”. Cette liste appelée “Product Backlog” peut être modifiée/complétée tout au long du projet.

Les éléments du Product Backlog sont ordonnancés de manière à mettre en haut de la liste – dans la mesure du possible (cf. dépendance entre les tâches) – les tâches bénéficiant du meilleur rapport « Valeur ajoutée au produit” / « Coût de mise en oeuvre ».

Diviser le temps

Afin de planifier le projet, la durée totale estimée du projet est divisée en blocs de temps successifs d’une durée fixe et courte appelés “Sprints” (en général 2 à 4 semaines).

Planifier le sprint

Les tâches prioritaires du Product Backlog (en haut de la liste) sont sélectionnées par l’équipe pour alimenter la liste des tâches du Sprint sur le point de commencer. Elle réalise cette sélection en fonction de sa capacité à les réaliser dans le délais du sprint (dès que l’équipe estime que ça ne rentre plus, elle arrête sa sélection).

Exécuter le sprint

Durant le sprint, chaque membre de l’équipe prêt à commencer une tâche, s’affecte cette dernière et la passe au statut “En cours”. Une fois terminée, il la passe au statut “Terminé”. Il peut alors s’affecter une nouvelle tâche de son choix au statut “A faire” jusqu’à épuisement des tâches du Sprint. Voir paragraphe : “Outil associé” pour plus d’explications et d’illustrations.

Revue de sprint et nouveau sprint

A la fin de chaque Sprint et quelque soit son avancement, l’équipe fait le bilan des travaux réalisés au cours de ce dernier et définit un plan d’action susceptible de rendre le prochain Sprint plus efficace, agréable, qualitatif et productif. De cette façon, le processus de réalisation du produit est sans cesse amélioré. La Planification du Sprint suivant s’enchaîne et ainsi de suite jusqu’au dernier Sprint aboutissant au “produit final” ou à sa nouvelle version.

Schéma du processus de gestion de projet simple

Schéma du processus de gestion de projet simple

Outil associé

Le principal outil associé est un “Tableau des tâches” virtuel composé à minima de 3 colonnes liées aux 3 statuts de base d’une tâche :

  • A Faire : La tâche n’est pas commencée et non affectée à un membre de l’équipe
  • En cours : Un membre de l’équipe s’est affecté la tâche et l’a commencé
  • Terminé : La tâche est terminée

Les tâches sont déplacées d’une colonne à une autre en fonction de leur avancement. Ce tableau permet à toute l’équipe de connaître en temps réel l’état des lieux du sprint en terme d’avancement.

Outil Trello

Tableau des tâches sur Trello dans le navigateur web

L’outil Trello a le mérite d’être simple, gratuit, web et utilisable sur un mobile sans rien installer. Son seul inconvénient est qu’il est en anglais mais le titre des colonnes reste personnalisable.

Reste à prévoir un outil pour gérer le Product Backlog. Un simple tableau Google Sheets peut faire l’affaire.

L’outil iceScrum est une autre alternative simple, complète, en français, gratuite et plutôt fun. Elle nécessite en revanche une installation sur un serveur.

Pour une équipe partageant un même espace de travail, un tableau des tâches physique mural avec un post-it par tâche peut être plus simple et efficace (l’informatique n’est pas toujours LA solution). Idem pour le Product Backlog qu’on rendra ainsi plus visuel, transparent et plus facile à ordonnancer (simples déplacements de postit).

Informations complémentaires

Ce n’est qu’un cadre méthodologique

Ce cadre méthodologique ne fait que définir les règles du jeu de base et n’a pas pour vocation de dicter à l’équipe la façon de réaliser les tâches et de s’organiser (ce qui est souvent spécifique au contexte de chaque projet). Il définit simplement un processus itératif offrant régulièrement à l’équipe l’occasion d’améliorer son organisation et de trouver elle même les solutions à ses éventuels obstacles (lors de la revue de sprint). Le projet peut ainsi démarrer très vite avec une organisation légère qui s’affinera au fil des sprints.

Tailles d’équipe

Ce cadre méthodologique s’adresse à des équipes de 2 à 9 personnes. Au delà, la coordination est plus compliquée, il est donc recommandé de former plusieurs équipes de 5 à 9 personnes. Chaque équipe disposant de son tableau des tâches de sprint alimentées à partir d’un Product Backlog commun à toutes les équipes du projet ou plusieurs. Par ailleurs, une synchronisation des sprints (commencent et se terminent en même temps quelque soit l’avancement) de chaque équipe offre pas mal d’avantages en terme de planification et d’intégration du travail de chaque équipe.

Origine et aide à la mise en oeuvre

Ce cadre méthodologique s’inspire ouvertement du cadre méthodologique préexistant Scrum créé pour le développement logiciel. Voir mini guide Scrum. Le livre électronique “Scrum & XP depuis les tranchées” (gratuit) – bien que venant du monde du développement logiciel – peut apporter des conseils précieux dans la mise en oeuvre de la présente méthodologie. Si vous souhaitez aller plus loin dans l’adoption de Scrum, j’ai pris soin de conserver le vocabulaire. Ainsi vous ne serez pas perdu en approfondissant le sujet. Pour vous accompagner dans cette démarche, je vous invite à lire le guide de démarrage Scrum.

Glossaire

  • Product Backlog : liste des tâches à réaliser pour aboutir au “Produit” ou au moins une première version de ce dernier.
  • Tâches du Sprint : liste des tâches à réaliser sur la durée du Sprint uniquement. Cette liste est donc un sous ensemble du Product Backlog.
  • Planification de Sprint : étape consistant à sélectionner des tâches prioritaires du Product Backlog à réaliser au cours du Sprint sur le point de commencer.
  • Produit : résultat auquel le projet aboutit (objet, film, logiciel, bâtiment,…)
  • Revue de Sprint : étape marquant la fin d’un sprint au cours de laquelle l’équipe inspecte son avancement, l’état du “Produit” et réfléchit aux moyens de s’améliorer.
  • Sprint : bloc de temps d’une durée fixe et courte (2 à 4 semaines) durant laquelle l’équipe réalise un sous ensemble des tâches à réaliser pour aboutir au “Produit” visé.
  • Vision : description du “Produit” final tel qu’imaginé par l’équipe pour guider cette dernière dans ses choix.
2

La pratique du lean management dans l’IT

 

Qu’est ce que le lean management concrètement ? Si j’applique le cadre méthodologique agile Scrum ou une autre méthode agile, suis je en train de faire du lean management sans le savoir ? Est ce que le lean management peut compléter la valeur ajoutée d’une approche agile pour mener un projet ? Ce sont ces questions qui m’ont poussé à lire cet ouvrage intitulé « La pratique du lean management dans l’IT – Agilité et amélioration continue« . J’ai pu y trouver les réponses à ces questions que je partage avec vous ci dessous. Et bien davantage.

Qu’est ce que le Lean ?

Voici la définition donnée par le livre

« C’est un système de management qui vise tout à la fois à satisfaire pleinement les clients, tout en réduisant les coûts et en développant les collaborateurs. Les managers lean assument pleinement ces trois ambitions simultanées qui peuvent paraître paradoxales ».

Lean management et méthodes agiles

Les principales caractéristiques du lean management sont les suivantes :

  • La recherche de la satisfaction client avant tout. En allant physiquement à la rencontre de ce dernier et en recherchant inlassablement la création de valeur.
  • L’élimination des gaspillages avec 7 familles de gaspillage.
  • Une pratique agressive de la résolution de problème
  • Le refus du status quo et la conviction que la perfection n’existe pas et qu’il y a sans cesse matière à s’améliorer
  • L’obsession de la mesure pour vérifier l’amélioration concrète et apporter ainsi la motivation nécessaire au changement
  • L’importance accordée au développement des compétences de chacun. Autrement dit pour reprendre une phrase du livre « Développer l’humain avant de développer des logiciels« . Des valeurs clairement opposées au Taylorisme.
  • Le management visuel pour voir ensemble, agir ensemble et de comprendre ensemble

Le lean provenant à l’origine du secteur industriel et de l’entreprise Toyota en particulier, les auteurs du livre déclinent, exemples à l’appui, 7 familles de gaspillage dans le secteur de l’informatique. C’est l’une des parties que j’ai trouvé les plus intéressantes et utiles au quotidien. Cela permet de se forger un détecteur d’optimisations de l’efficacité pour davantage de satisfaction client et de sérénité au travail.

Les méthodes agiles ont également dans leur ADN, les principes d’amélioration continue, de recherche du feedback rapide des utilisateurs, une part importante accordée à l’humain, etc. Mais pas aussi poussée et affichée que le lean management à mon sens.

J’ai donc tendance à partager la conclusion du livre, illustrée par un contexte dans lequel une équipe agile a atteint un niveau d’efficacité satisfaisant. Mais peine à passer un nouveau cap d’efficacité malgré l’application à la lettre des pratiques et principes agiles. C’est à cet instant que le Lean Management peut apporter un complément utile.

Quelques phrases clefs du livre pour finir :

« Le manager est celui qui crée les conditions dans lesquelles ses équipes vont expérimenter, apprendre et réussir ».

« Le lean s’attache à satisfaire le client, l’actionnaire et le collaborateur. Le collaborateur développe son savoir faire et son expertise par la résolution de problèmes qui tiennent à coeur les clients et les actionnaires ».

Acheter ce livre

Scrum

Scrum

Claude Aubry, l’auteur du livre Scrum – Le guide pratique de la méthode agile la plus populaire,  fait partie des pionniers de l’adoption de l’agilité en France. A l’époque où aucun livre en français n’existait sur le sujet. C’est d’ailleurs ce qui explique la rédaction tardive de cette nouvelle fiche de la collection « J’ai lu pour vous ». En effet, mes lectures au sujet de Scrum remontent à cette même époque. Des lectures d’ouvrages en anglais donc. Depuis la sortie de sa première édition, je m’étais toujours dit que je prendrai le temps de lire le livre de Claude bien que ma connaissance de Scrum soit déjà plus qu’approfondie. Voilà qui est fait avec la 3eme édition.

Structure du livre Scrum

Si je devais diviser le livre Scrum en trois grandes parties, je dirais que :

  1. Les premiers chapitres sont consacrés à Scrum en soi. Ils détaillent chaque élément du cadre méthodologique Scrum.
  2. Les suivants viennent compléter Scrum par les différentes pratiques agiles connexes telles que celles associées à la gestion de produit ou les pratiques de développement agiles (pratiques d’ingénierie).
  3. Enfin, les derniers traitent des outils Scrum, de la spécificité des contextes projet français, de la transition vers l’agilité ainsi que de l’utilisation de Scrum à grande échelle.

Principaux atouts de ce livre

Voici les principaux atouts du livre Scrum :

  • Son exhaustivité : Claude ne se contente pas de couvrir avec exhaustivité le cadre méthodologique Scrum en soi, il aborde aussi les pratiques agiles connexes et indispensables que Scrum ne couvre pas. Ainsi que les enjeux de transition agile. Car connaître Scrum est une chose mais maîtriser sa mise en oeuvre en est une autre.
  • La prise en compte du contexte projet à la française : La France s’étant inspirée du BTP pour définir les organisations projets, la séparation Maîtrise D’ouvrage (MOA) et Maîtrise d’Oeuvre (MOE) pré-existe en général. Ce livre couvre ces spécificités.
  • Sa perspective Product Owner : Les livres traitant de Scrum sont souvent « déséquilibrés » et couvrent principalement le rôle de Scrum Master dont la responsabilité consiste à garantir le respect du cadre méthodologique Scrum et s’assurer que l’équipe de développement est pleinement efficace. Ce déséquilibre n’est pas un mal un soi et il est plutôt logique. Cependant, on apprécie dans ce livre l’expérience de l’auteur dans le rôle de Product Owner et sa sensibilité à ce rôle demeurant clef pour la réussite du projet.
  • Les anecdotes : Au delà de la description des pratiques agiles couvertes, des exemples utilisés, les anecdotes contribuent énormément à la dimension « pratique » de ce guide. L’auteur partage ainsi toute son expérience.
  • Les dessins humouristiques : Les illustrations humoristiques apportent du fun et de la légèreté à l’ouvrage.
Acheter ce livre

Lean Startup

Lean Startup

Qu’est ce que le Lean Startup ? En quoi est ce différent des méthodes agiles ? En quoi ce livre peut intéresser n’importe quelle entreprise ou organisation ? C’est à ces questions que je propose de répondre dans cette nouvelle fiche de la collection « J’ai lu pour vous ».

Qu’est ce que le Lean Startup

On pourrait dire que le Lean Startup est le fruit d’une série d’échecs. Et quand l’échec est une source d’apprentissage, c’est déjà un bon point de départ pour faire de ce livre, un véritable outil pragmatique et efficace. L’auteur qui n’est autre que l’inventeur du Lean Startup – à force d’échouer dans ses projets de startup – a fini par se tourner vers la méthodologie et le système de pensée Lean issues du milieu industriel. De Toyota plus particulièrement. Petit à petit, il a élaboré une véritable méthodologie permettant d’augmenter considérablement les chances de succès d’une startup. Nous pourrions dire la même chose de l’apport d’une approche agile à un projet. Les deux approches sont d’ailleurs très complémentaires et ont des principes communs.

Depuis sa naissance en 2008, le Lean Startup a connu un développement considérable tout comme comme les Startup Week-end consistant à créer une startup et un prototype de produit en seulement un week-end à partir d’une simple idée.

La fin des startups dépourvues de méthodologie

Les bénéfices apportés par le Lean Startup sont tels qu’on peut s’attendre à ce qu’il devienne difficile de se lancer dans la création d’une startup sans un minimum de méthodologie et d’organisation. Si je devais moi même investir dans une Startup, je ferai du respect du Lean Startup et d’une approche agile un prérequis essentiel. Mais ça n’engage que moi et je dérive un peu.

Remettre en question ses croyances

Le Lean Startup nous encourage à remettre en question les croyances suivantes :

  • La méthodologie menace l’innovation : Un entrepreneur se lançant dans l’aventure de la création d’une startup peut se dire que la méthodologie et l’organisation font obstacle à l’innovation qui elle-même est un fondement de la startup. Hors au contraire, le Lean Startup va canaliser l’innovation pour décupler son impact dans le développement de la startup.
  • Les gens vont adorer mon produit : Deux croyances peuvent nous mener droit à la douche froide. L’excès de confiance en son instinct ou idée « les gens vont adorer mon produit et y mettre le prix » ou la peur de l’échec qui peut nous pousser à consommer énormément d’énergie et d’argent à mettre au point un produit de A à Z avant le mettre sur le marché.

Tester au plus tôt ses hypothèses

Afin d’éviter la douche froide, il est nécessaire de vérifier au plus tôt les hypothèses de croissance associées aux produit réalisé. Intérêt pour le produit, comportement des utilisateurs, canaux de distribution, etc.

Lean Startup nous apprend à mettre en oeuvre une organisation et une démarche nous permettant d’apprendre le plus tôt et le plus fréquemment possible. Prenons l’exemple de Dropbox, cette solution de partage de fichiers entre plusieurs ordinateurs et plusieurs personnes. Les créateurs de Dropbox, avant même de développer la moindre fonctionnalité ont commencé par réaliser une vidéo montrant le fonctionnement cible de Dropbox comme s’il existait déjà. Et c’est seulement en constatant le succès de cette vidéo, qu’ils ont décidé de se mettre à l’oeuvre.

Voilà une anecdote qui illustre à l’extrême l’état d’esprit Lean Startup. Un état d’esprit décliné en une méthodologie éprouvée décrite en détail dans ce livre.

Faire du Lean Startup dans les entreprises

De plus en plus d’organisations, petites et grandes et de tous secteurs sont amenés à « faire plus avec moins ». Beaucoup d’entre elles évoluent dans un contexte de plus en plus complexe rendant la réalisation du « bon produit » sans cesse plus difficile. Lean Startup vient répondre à ces enjeux avec une approche pragmatique, redoutablement économique lorsqu’elle est bien utilisée et complémentaire à l’approche agile. Sur un projet agile, le Lean Startup intéressera particulièrement le Product Owner. En particulier en amont du projet mais il peut également s’avérer être utile pendant.

Enfin dans son livre, l’auteur Eric Ries, utilise énormément d’exemples pour illustrer ses propos. L’un d’entre eux concerne l’utilisation de l’approche Lean Startup pour réaliser de la transformation d’organisation. Cet exemple est décrit brièvement mais peut servir d’inspiration pour mener un projet de transformation agile qui par nature fait l’objet de beaucoup d’incertitude et par conséquent, d’hypothèses à vérifier au plus tôt.

Acheter ce livre

 

2 minutes pour présenter l’approche agile

2 minutes pour présenter l'agilité à 1500 personnes

2 minutes pour présenter l’approche agile à plus de 1500 personnes réunies au théâtre Mogador de Paris, c’est le challenge qui s’est présenté à moi en ce début d’année. Un challenge, mais aussi une belle opportunité, celle de faire connaître l’approche et surtout la culture agile à davantage de collègues de travail SwissLife. Cet évènement rassemblant tant de monde est le rituel annuel de cérémonie des voeux de l’entreprise.

Dans cet article, je partage avec vous le discours préparé pour cette occasion. L’objectif était simple : faire court (pas plus de 2 minutes), sans support de présentation, avoir un maximum d’impact et être suffisamment clair pour un public varié incluant des personnes ne travaillant pas en mode projet.

On sait jamais, ce discours pourrait vous servir d’inspiration, que vous ayez besoin d’expliquer l’intérêt et les principales caractéristiques d’une approche agile à un décideur pressé dans l’ascenseur ou à votre belle mère au prochain repas de famille.

Le voici exprimé en « langage naturel » :

« Question de l’animateur : Florent, qu’est ce que la ‘méthode agile’ ?

Réponse : Il s’agit d’une méthodologie utilisée pour mettre au point des produits logiciels. Une méthodologie qui part du principe que dans ce type de projet, les imprévus sont inévitables et qu’il est très difficile de savoir à l’avance ce dont un utilisateur a réellement besoin. Partant de ces principes, l’approche agile, à travers son mode de fonctionnement, offre une grande capacité d’adaptation aux imprévus et aux besoins des utilisateurs. D’où le terme agile.

Et plus qu’une simple méthodologie, il s’agit d’un véritable état d’esprit porteur de valeurs et de principes qui tournent autour de la collaboration, la communication, l’auto-organisation des équipes, la transparence, l’amélioration continue et repose sur un style de management basé sur la confiance. Le manager agile met son pouvoir au service de son équipe afin d’aider cette dernière à atteindre ses objectifs. C’est d’ailleurs ce qui me plait le plus dans cette approche car ça met l’épanouissement de chacun au service des résultats. Autrement dit, tout le monde est gagnant.

Pour finir, il faut savoir que cette approche touche désormais d’autres secteurs que celui du développement de logiciel. »

Lancement du SPOC d’initiation à Scrum

Suite au dépouillement des réponses au questionnaire envoyé au printemps de cette année, j'ai décidé de mettre au point un nouveau dispositif de formation et d'accompagnement afin de répondre aux objectifs suivants :

  • Aider chaque acteurs d'un projet (maîtrise d'ouvrage, PMO, chef de projet, développeur, décideurs, etc) à partager une même définition de l'approche agile et Scrum afin de collaborer le plus efficacement possible ensemble
  • Expliquer le fonctionnement concret d'une approche agile et plus particulièrement Scrum pour mener collectivement un projet
  • Préciser quels bénéfices une telle approche peut apporter à votre organisation
  • Guider vos premiers pas vers l'adoption d'un approche agile avec Scrum
  • Vous aider à éviter les principaux pièges liés à cette mise en oeuvre.

J'ai également voulu créer un environnement d'apprentissage vous permettant d'apprendre à votre rythme, d'où vous voulez avec ce sentiment d'appartenance à une communauté de personnes qui, comme vous, s'intéressent à l'agilité. Un environnement dans lequel on apprend et progresse ensemble.

Concrètement, chaque semaine en moyenne, vous accédez à un nouveau module de formation composé de vidéos que vous pourrez consulter directement en ligne sur la plateforme de formation privée. Ou télécharger, pour les visionner dans les transports en commun par exemple. A l'issue de chaque module, un quiz vous permettra d'évaluer vos connaissances.

Je répond personnellement à vos questions sur le forum de la plateforme ou pendant des sessions live. Vous pouvez vous même répondre aux questions des autres si vous le souhaitez. Saviez vous que la meilleure façon d'assimiler ses connaissances consiste à les transmettre à son tour ?

Par ailleurs, vous pouvez opter pour un parcours avancé comportant en plus des éléments déjà cités, un exercice fil rouge vous permettant de mettre en application vos connaissances sur un projet fictif.

Comptez environ 2 à 3 heures de travail par semaine en moyenne pendant 5 semaines.

Parcours du SPOC d'initiation à l'approche agile et Scrum

Parcours du SPOC d'initiation à Scrum et découverte des méthodes agiles

Voici le contenu du programme
Module 1 - L'agilité : plus qu'une méthodologie, un état d'esprit

Objectif : comprendre en quoi l'agilité est un véritable changement de paradigme à travers les valeurs et principes qu'elle véhicule et son principe général de fonctionnement

Module 2 - Scrum : focus sur la "méthode" agile la plus éprouvée

Objectif : Connaître les différentes méthodes du marché ainsi que le contenu et fonctionnement concret du cadre méthodologique Scrum, ses rôles, ses évènements et leur articulation.

Module 3 : Pilotage d'un projet Scrum

Objectif : comprendre comment piloter un projet SCRUM , et notamment les règles du jeu proposées en matière de gestion des changements sur un projet dont le délai et budget sont fixes.

Module 4 : Les bénéfices à tirer et les pièges à éviter

Objectif : Saisir les principaux bénéfices d'une approche agile tout en étant conscient des pièges à éviter et donner des pistes pour approfondir ses connaissances.

Bonus de la formation : "Extrait d'une formation Scrum Avancée"

En bonus, vous apprendrez par l'exemple une technique d'animation de la "Rétrospective". La rétrospective fait parti des pratiques agiles d'amélioration continue. Applicable à tous types de contextes, cette pratique fait aussi parti des premières "briques" généralement mises en place en cas d'adoption d'une approche agile.

Garantie "satisfait ou remboursé"

Vous avez changé d’avis ? La formation ne vous convient pas ? Vous n’avez pas le temps de participer à cette session ? Aucun souci. Vous avez 7 jours, à compter du jour de lancement de la formation, pour appliquer la procédure de remboursement sur simple demande à l’adresse contact@capitainespoc.com en précisant la raison de votre demande. Vous aurez alors deux options : Transférer votre inscription sur une session ultérieure de ce SPOC, ou d’un autre SPOC ou demander un remboursement.

1 2 3 7