Less - Plus avec LeSS

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

Auteur : The LeSS Company B.V.
Source : More with LeSS


Traducteur : Nicolas Mereaux
Relecteur : Fabrice Aimetti
Date : 19/10/2018


Traduction :

LeSS - Portail Principes

Le principe Plus avec LeSS est au cœur de LeSS. Il s'agit de la prise de conscience que les désavantages des solutions organisationnelles complexes utilisées pour le développement de produits complexes sont souvent pires que le problème qu'elles essaient de résoudre. Le développement de produits complexes ne nécessite pas des solutions complexes. Il demande une compréhension profonde de l'essence du problème, qui peut être alors résolu avec des solutions plus simples.

LeSS peut être perçu comme un cadre de travail de développement de produit à grande échelle, mais il peut aussi être vu comme un cadre de travail pour décomplexifier les organisations. LeSS tente de supprimer la complexité organisationnelle en résolvant les problèmes dans le développement de produits d'une manière différente et plus simple. Notons que plus simple, ne veut pas dire plus facile, notamment à court terme. Même si LeSS est simple, il est exceptionnellement difficile à mettre en place dans les organisations.

LeSS tente de définir le strict nécessaire suffisant pour un développement à grande échelle. LeSS évite d'ajouter des rôles, artefacts, ou processus supplémentaires, parce qu'il sait ce que représente l'inconvénient de ces ajouts.

Un rôle est un ensemble de responsabilités ou de tâches assignées à un individu. Le plus souvent, il ne s'agit pas de nouvelles responsabilités ou de nouvelles tâches. Donc définir un nouveau rôle signifie que ces responsabilités seront enlevées à quelqu'un d'autre. Dans le développement de produits, cela signifie qu'elles sont pour la plupart du temps retirées aux équipes.

Plus il y a de rôles, moins les équipes sont responsables.

Un processus est une description de la manière dont le travail doit se passer. C'est une manière de partager la connaissance; Mais ! … cela conduit aussi les gens à arrêter de penser. L'interprétation de la mise en place d'un processus est qu'il n'y a plus besoin de penser à comment faire le travail, car cette réflexion a été faite par les personnes qui ont défini le processus. C'est suivre plutôt que changer (et apprendre), et c'est louer plutôt que s'approprier la connaissance. Donc définir plusieurs processus empêche les équipes de s'approprier la manière de faire le travail. Et des équipes sans sentiment d'appropriation ne pourront pas s'améliorer.

Plus il y a de processus mis en place moins il y a d'appropriation dans les équipes et une absence d'amélioration continue.

Un artefact est une information ou une connaissance qui est formalisée et enregistrée. Dans un développement traditionnel de produit, tout un ensemble d'artefacts sont produits en tant que méthode de communication. La plupart de ces artefacts éloignent les équipes du client ou de l'utilisateur réel, les équipes croyant ou il leur a été dit qu'elles peuvent se référer à l'artefact à la place. Cela pourrait sembler convenable, mais en pratique les artefacts dépouillent les équipes de la compréhension client et de l'objectif du développement produit, et cela empêche l'empathie.

Plus il y a d'artefacts moins les équipes sont orientées client.

Garder à l'esprit Plus avec LeSS nous permet de penser différemment au sujet du développement produit.

Au lieu de demander "Comment pouvons-nous faire X d'une manière agile ?" où X est la pratique ou la structure organisationnelle actuelle, nous posons d'abord la question "Pourquoi faisons-nous X d'abord ?" pour voir si nous pouvons trouver une meilleure solution au problème d'origine. Par exemple, "Comment faisons-nous de la gestion de programme d'une manière agile ?" est une question récurrente du passage à grande échelle, alors que, en gardant le principe Plus avec LeSS à l'esprit, nous nous demandons "Pourquoi devons-nous faire de la gestion de programme d'abord ?". Ce qui nous conduit à prendre conscience que les programmes (les grands projets) sont une manière d'organiser le travail, qui peut être organisé différemment. Par exemple, avec une orientation davantage produit, en travaillant vers un objectif de livraison continue, et avec une planification adaptative, tout cela nous mène à être capable de gérer le développement produit sans recourir aux programmes.

La même manière de penser s'applique à d'autres complexités organisationnelles, simplifiant peu à peu les organisations.

Références :