« Les coûts n’existent pas pour être calculés. Les coûts existent pour être réduits. » — Taiichi Ohno

3M, ce n’est pas qu’une entreprise célèbre de Post-it®, c’est aussi un acronyme pour les trois causes majeures des coûts et retards de tout processus (de fabrication ou autre) : Muda, Mura et Muri.

Alors que les industries partout dans le monde sont de plus en plus au fait des principes Lean, on commence à comprendre ces concepts et, dans plusieurs organisations, les politiques d’amélioration les abordent de façon plus ou moins efficace.

Du côté du développement logiciel, de plus en plus de méthodes combinant les principes Agiles et Lean voient le jour, mais il y en a peu qui abordent les 3 M aussi efficacement qu’un cadre Scrum mis en place correctement. Dans le présent billet, je vais vous présenter les trois M et tenter de résumer comment les pratiques Agiles permettent de les aborder.

« Le plus dangereux des gaspillages, c’est celui qu’on ne voit pas. »Shigeo Shingo

Le M le plus connu, c’est le muda. Il fait simplement référence au gaspillage.

Défini habituellement comme une activité ou un processus qui n’apporte pas de valeur aux yeux du client, le muda est une perte pure et simple de temps, d’argent et de ressources. Il ne faut pas hésiter à le supprimer.

La plupart des gaspillages entrent dans l’une des sept catégories suivantes (T. Ohno, système de production de Toyota, 1988) :

  1. Surproduction : C’est de produire plus que ce que les clients ont besoin.
  2. Inventaire en excès : Il s’agit des matériaux bruts, des travaux en cours ou des biens finis qui ne produisent pas de revenus.
  3. Transports et déplacements inutiles : Il s’agit des déplacements de produits, de pièces, de documents, etc., qui n’apportent pas de valeur ajoutée.
  4. Traitements inutiles : Ce sont les tâches ou étapes réalisées pour rien.
  5. Mouvements inutiles (motion) : Ce sont les déplacements de personnes physiques qui n’apportent pas de valeur au client (ex. : blessures).
  6. Défauts : Il s’agit d’erreurs, de retouches nécessaires ou de l’absence de quelque chose qui est nécessaire.
  7. Temps d’attente : C’est le temps pendant lequel les biens ne sont pas en cours de production ou de transformation.

Souvent, on ajoute une huitième catégorie. Il s’agit de la mauvaise utilisation du capital humain pour ajouter de la valeur, mais celle-ci entraîne du gaspillage.

Voyons maintenant comment les pratiques Agiles abordent les gaspillages.

Puisque les membres d’une équipe Scrum sont habituellement colocalisés (physiquement ou virtuellement), moins de déplacements sont nécessaires.

Il y a réduction des stocks dans les différents emplacements puisque l’équipe choisit uniquement un sous-ensemble du carnet de produit à réaliser au cours de l’itération, limite les travaux en cours et livre seulement les éléments sélectionnés pour la fin du sprint.

Pour ce qui est des mouvements, c’est un peu plus compliqué. Heureusement, les risques sont assez faibles qu’un employé subisse une blessure physique au cours du processus. De plus, deux des principes du manifeste Agile préconisent la réalisation de projets à un rythme soutenable et soutenu avec des gens motivés. Ces principes préviennent grandement les risques d’épuisement physique ou psychologique découlant du désengagement, du stress ou d’une surcharge de travail. Ils sont aussi la clé libérant le potentiel humain, ce qui permet de créer quelque chose de génial, réduisant ainsi le huitième type non officiel de gaspillage.

Même s’il peut y avoir de l’attente, celle-ci est réduite au minimum grâce à la rencontre quotidienne (Scrum : daily scrum; XP : stand-up meeting). De plus, puisqu’un des caractéristiques essentielles, c’est que l’équipe soit autonome et multidisciplinaire, il ne devrait pas y avoir de l’attente causée par des dépendances externes.

La simplicité, ou l’art de minimiser la quantité de travail inutile énoncé dans le manifeste Agile, diminue le risque de mise en œuvre de traitements inutiles. Lorsque le travail est découpé en morceaux maniables, l’équipe se concentre sur ce qui est strictement nécessaire pour réaliser chaque élément du carnet de produit. En se concentrant sur la création de ce qu’il y a le plus de valeur pour le client, les méthodes Agiles aident à réduire la surproduction. Ce type de gaspillage se matérialise habituellement lorsque de grands lots sont produits à l’avance.

Enfin, les pratiques Agiles portent sur la production de logiciels fonctionnels; c’est-à-dire sans défauts. La définition de « terminé » dans Scrum et certaines pratiques de génie logiciel telles que le développement piloté par les tests (ou TDD) sont des exemples de ce qui peut être fait ou utilisé pour réduire les risques au minimum.

« La tortue, plus lente mais régulière, cause moins de gaspillage et elle est de loin préférable au lièvre qui court à perdre haleine puis s’arrête pour se reposer. Le système de production de Toyota ne peut être réalisé que lorsque tous ses acteurs deviennent des tortues. »Taiichi Ohno.

Le mura, ou irrégularité, c’est ce qui crée plusieurs des formes de gaspillages mentionnées ci-dessus. L’incapacité d’adopter et de maintenir un rythme constant crée des variations dans le processus.

Un exemple classique purement fictif, mais en quelque sorte familier à toute personne ayant de l’expérience en informatique, c’est la longue durée de l’implantation de certains systèmes.

Au début du projet, le travail est généralement lent. L’équipe se met en marche. Elle attend les approbations nécessaires. Les plans sont représentés dans des diagrammes de Gantt. Les nombreuses rencontres pour s’assurer que tout le monde se met au diapason font perdre un temps précieux. Il y a rédaction de longs documents afin de couler dans le béton tout ce dont on pourrait avoir besoin.

Au fil du temps, le stress monte alors qu’on prend conscience de la date de livraison et de la portée du projet, et les équipes accélèrent le rythme. Des réunions sont nécessaires pour suivre l’état d’avancement des travaux et coordonner les équipes. Les diagrammes de Gantt sont mis à jour. On rédige des documents afin de faire passer le travail d’une équipe à l’autre. On choisit irrévocablement les architectures et, enfin, on peut commencer à coder.

Malgré les efforts importants et la priorité accordée, la date approche dangereusement et l’équipe travaille le soir et les fins de semaine pour que tout soit prêt à la date convenue. Lorsque le système est finalement en production, le deuxième cauchemar commence à la découverte des défauts. Les joueurs restants font des heures supplémentaires pour régler hâtivement ce qui peut être réglé et trouver des solutions de contournement pour ce qui ne peut l’être.

Je pourrais continuer longtemps avec cet exemple, mais je pense que vous comprenez… Les inégalités de cet exemple en cascade entraînent plusieurs des gaspillages mentionnés précédemment. C’est désastreux pour toute l’organisation, et ce, à tous les niveaux : coûts nécessaires pour livrer à temps, fatigue extrême des membres de l’équipe de projet, insatisfaction du client. De plus, on n’a pas le sentiment d’accomplissement avec les défauts découverts après la livraison.

En se concentrant sur la livraison rapide et itérative d’incréments de logiciel fonctionnels, les méthodes et pratiques Agiles visent à établir un rythme soutenable pour tous les acteurs : l’équipe de développement et le client. La répartition du travail en blocs de temps aide le processus empirique en définissant une boucle d’inspection et d’adaptation constante. Ceci aide grandement l’équipe à connaître son rythme grâce aux itérations passées. La vélocité est souvent utilisée pour définir le rythme.

De plus, l’inspection fréquente du processus de production d’incréments fonctionnels de logiciel (rétrospective de l’itération) assure la suppression des obstacles et le bon déroulement des travaux alors que les membres de l’équipe apprennent à mieux travailler ensemble. Comme nous l’avons vu précédemment, l’utilisation professionnelle des pratiques Agiles permet d’éviter ou, du moins, de réduire la plupart des gaspillages.

« Nous sommes condamnés à échouer sans la déconstruction quotidienne de nos diverses préconceptions. »Taiichi Ohno

Le muri, ou excès, c’est habituellement le résultat des mura, mais c’est aussi le résultat de nombreux problèmes organisationnels. Il s’agit de stress inutile que l’on fait subir aux employés et aussi de processus organisationnels inutiles. Au fil du temps, si on ne traite pas le muri adéquatement, il en résulte de nouveaux mura ou muda, et ce, même si l’organisation a réussi à les réduire par le passé.

Les gens et les processus écopent des excès lorsque les obstacles sont de nature structurelle ou procédurale (parfois, ils sont même institutionnalisés par des politiques internes). Des lieux de travail mal aménagés et encombrés, des directives peu claires, le manque de formation, les mauvais outils, un manque de maintenance, des modes de communication pauvres sont les principales causes des surcharges imposées aux employés et processus. Pendant l’énumération, je suis pratiquement certain que des images fondées sur votre propre expérience vous sont venues à l’esprit.

En ce qui concerne les pratiques Agiles, ces anomalies structurelles et organisationnelles s’appliquent dans une bien moins grande mesure. Scrum, par exemple, est un cadre léger et facile à comprendre. Par conséquent, il n’y a pas vraiment de stress lié au manque de formation.

Les directives sont assez claires. De plus, chacun des événements, artefacts et rôles a un but, une portée et des responsabilités qui lui sont propres. Un membre de l’équipe a la responsabilité de s’assurer que le cadre respecte le but fixé. Ainsi, les autres membres en sont libérés.

Comme l’indique le manifeste Agile : « La méthode la plus efficace pour transmettre l’information est une conversation en face à face. » Toutes les pratiques Agiles visent à réduire autant que possible les canaux de communication déficients en favorisant la collaboration directe.

Enfin, pour ce qui est de l’organisation du lieu de travail et le choix des outils appropriés, les équipes auto-organisées sont la clé permettant la réduction des fardeaux à ce niveau. Ce sont elles qui sont les mieux placées pour optimiser leur travail.

« Si vous êtes pour utiliser le système de production de Toyota, vous devez le faire à fond. Vous devez aussi changer votre façon de penser. Vous avez à changer votre façon de voir les choses. »Taiichi Ohno

Cette citation dit tout! De fait, se débarrasser des trois M au niveau de l’équipe, c’est comme faire le ménage d’un tiroir se trouvant dans votre sous-sol… Aussi parfait que puisse être ce tiroir, ça a quand même très peu d’impact si le reste du sous-sol est en désordre et rempli de cochonneries.

On peut parler de vraie transformation lorsque l’organisation et toutes ses parties constituantes apprennent à penser différemment. Ce qui est réalisable plus facilement au niveau de l’équipe grâce aux approches Agiles et à la pensée Lean nécessite beaucoup plus d’efforts et d’engagement quand il s’agit de l’organisation dans son ensemble.

Une telle transformation n’est pas toujours plaisante puisque les pratiques Agiles et Lean favorisent la visibilité et la transparence, jetant rapidement la lumière sur les gaspillages et obstacles. Il est nécessaire que tous démontrent un engagement sans réserve à de meilleures façons de faire puisque, selon Taiichi Ohno, « une introduction faite à moitié cause 100 dommages et ne procure aucun gain ».

Les transformations les plus réussies sont celles réalisées lorsque les organisations n’ont pas le choix si elles veulent demeurer compétitives dans un environnement économique de plus en plus agressif. Comme l’a indiqué Ken Schwaber : « Pour réussir avec Scrum, la souffrance liée à son utilisation doit être inférieure à celle ressentie si on ne l’utilise pas. »

Billet précédent

DevTeach, la conférence pour les développeurs Web

Billet suivant

Démêler les fils de l'esprit d'équipe

Pawel MYSLIWIEC

Diplômé en 2004 et certifié Professional Scrum Master, Pawel a joué divers rôles depuis le début de sa carrière – programmeur, analyste, chargé de projet, coordonnateur, responsable de produit et, plus récemment, architecte d’affaires – dans des contextes de réalisation de projet tant traditionnels qu’Agiles. Depuis 2011, il met en application les méthodes Agiles dans des équipes de projets informatiques et aussi dans celles responsables des activités commerciales.

Convaincu de la force des principes Lean et de la philosophie Agile, Pawel s'est joint à Pyxis en 2015 pour continuer à aider les personnes et les organisations à découvrir une façon de travailler valorisante, responsabilisante et efficace et qui demeure centrée sur la valeur pour le client.

Pas de commentaire

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *