Cet article a été initialement publié par Foundry4, un cabinet de conseil en technologie aidant les organisations à exploiter la technologie pour résoudre les problèmes complexes d'aujourd'hui. Lisez l'article originalici et plus encore Foundry4 insights ici.

Votre organisation a-t-elle changé ses méthodes de travail en Agile mais ne s'est toujours pas améliorée de manière significative ?

De nombreuses organisations ont du mal avec Agile. Ils adoptent un framework Agile tel que Scrum, mais n'y voient aucun avantage. Pour certains, c'est parce qu'ils ne font que des paroles en l'air – par exemple en organisant des événements Scrum, tels que le Daily Scrum, sans vraiment changer leur état d'esprit.

Mais même si vous vivez dans l'état d'esprit Agile (comme décrit dans le Manifeste pour le développement logiciel Agile de 2001), votre objectif peut sembler insaisissable.

Quel est ton but?

Mettre en œuvre une approche Agile telle que Scrum ne doit pas être votre objectif : Scrum, Extreme Programming, Kanban, etc. ne sont que des approches pour vous aider à atteindre votre véritable objectif. Alors quel est votre véritable objectif ?

Lorsque je pose cette question, un objectif commun que j'entends est : « Nous voulons que nos équipes livrent plus rapidement ». '. Il indique même que « un logiciel fonctionnel est la principale mesure du progrès ».

Par conséquent, il est compréhensible qu'une livraison plus rapide soit un cri de guerre courant de la gestion, en particulier dans les organisations qui se considèrent « agiles ».

Le problème avec une livraison plus rapide

Je trouve que de nombreuses organisations négligent deux problèmes importants lorsqu'elles se concentrent sur ce type d'objectif : Quel problème est abordé et qui le veut ? Quelle qualité est souhaitable ?

« Avant de commencer une chasse, il est sage de demander à quelqu'un ce que vous recherchez avant de commencer à le rechercher. » - Winnie l'ourson

L'exemple que j'utilise est celui de servir des convives dans un restaurant. Nous identifions que nous avons un grand nombre de convives affamés et le patron nous pousse à servir ces clients le plus rapidement possible. Si nous nous concentrons sur la vitesse sans considérer la qualité, nous sortons une omelette toutes les 30 secondes et servons des omelettes dégoûtantes à nos clients qui ne reviennent jamais. Si nous nous concentrons sur la vitesse sans tenir compte des besoins de nos utilisateurs, nous découvrons seulement que nous servons des omelettes aux végétaliens une fois que les assiettes arrivent sur les tables. Notre solution de livraison plus rapide n'a pas satisfait nos convives affamés et nous avons perdu ces clients à jamais.

Le problème de qualité est relativement facile à résoudre en refusant de céder ; un produit ou un service moins complet ne signifie pas nécessairement une mauvaise qualité, cela peut simplement signifier qu'une fonctionnalité plus limitée est disponible dans les premiers jours. Portée réduite, pas de qualité réduite.

Malheureusement, de nombreuses organisations à l'esprit agile sont confrontées à l'autre problème, se précipitant souvent dans la livraison avant de savoir ce qu'elles devraient fournir.

La correction

"Avant de commencer une chasse, il est sage de demander à quelqu'un ce que vous recherchez avant de commencer à le rechercher." - Winnie l'ourson

Construire quelque chose, puis dire aux gens qu'ils en ont besoin, est un moyen très difficile de vendre un produit ou un service ; nous devrions essayer de répondre à un besoin réel et existant des utilisateurs.

Cependant, nous, l'organisation, ne savons pas quel est le besoin le plus important du client. Nous pourrions penser que oui, mais ce n'est généralement qu'une hypothèse non vérifiée. Et de qui s'agit-il ? Les équipes? Le PDG ? Celui d'un autre expert au sein de votre organisation ?

Vos clients sont les mieux placés pour vous le dire. Je ne suggère pas que nous devrions simplement donner aux clients ce qu'ils demandent. Bien que Ford n'ait jamais dit "si j'avais demandé aux gens ce qu'ils voulaient, ils auraient dit des chevaux plus rapides", cela fait toujours comprendre que donner aveuglément aux clients ce qu'ils demandent n'est pas nécessairement une bonne idée. Les organisations doivent tenir compte des besoins, des désirs et des désirs de leurs clients parallèlement à leurs besoins commerciaux.

Le point idéal est l'intersection entre la vision/l'objectif de l'organisation et les besoins/désirs/désirs des clients. Ce n'est qu'alors que vous commencerez à passer à une phase de livraison, via des phases de solution et de prototypage.

Le Manifeste Agile a-t-il tort de se concentrer sur la livraison ?

Écrit en 2001, le Manifeste Agile a défini quelques principes qui couvraient un ensemble d'approches de la création de logiciels, notamment Scrum, Extreme Programming et Crystal Clear. Il a abordé une variété de mauvaises pratiques qui étaient courantes au tournant du millénaire : projets de 12 mois avec une sortie big bang à la fin, équipes travaillant en silos, documents d'exigences ridiculement longs et détaillés, risque poussé jusqu'à la fin du projet , etc.

Il n'a pas prescrit comment aborder chaque projet. Il a délibérément laissé beaucoup de côté, par exemple, il ne mentionne pas la définition d'une vision ou d'un objectif, mais je suis certain que les créateurs voulaient que vous les ayez. Donc, ce n'est pas que le Manifeste ait tort ; il s'agit de la façon dont les gens l'interprètent.

Tout est question d'interprétation

Il est bénéfique que de nombreuses organisations aient absorbé les mots du Manifeste. Cela leur a permis de se libérer de leurs anciennes méthodes de travail inutiles. Ils sont désormais en mesure de lancer des produits et des services plus tôt, réduisant ainsi les risques et offrant de la valeur à leurs utilisateurs plus tôt.

Les organisations intelligentes sont conscientes que le Manifeste Agile ne leur donne pas de guide étape par étape. Ils reconnaissent qu'on attend d'eux qu'ils réfléchissent eux aussi.

Malheureusement, certaines organisations font une lecture littérale du Manifeste, comme s'il s'agissait d'un évangile. Ces organisations adoptent une attitude de type « nous ne faisons que ce qu'il dit dans le Manifeste » et risquent de manquer la première étape cruciale du développement de produits/services : comprendre quel est l'objectif.

Ils ne parviennent pas à comprendre ce dont leurs clients ont besoin. Ils ne parviennent pas à comprendre quelle est la « valeur » que le Manifeste exige qu'il soit livré tôt et continuellement. Ces organisations sont comme le restaurant qui optimise pour sortir deux omelettes par minute… mais ne reconnaît pas que ses convives sont végétaliens ! La solution

Une option judicieuse consiste à suivre l'approche à double diamant, créée par Design Council. Cela commence par comprendre le but et les problèmes de votre organisation. Il cherche ensuite à comprendre les problèmes de vos clients, à recueillir des informations sur ces problèmes et à trouver des solutions potentielles… À ce stade, vous pouvez commencer votre prototypage et votre livraison itérative.

Ce n'est pas que le Manifeste Agile se soit trompé ; c'est que certaines personnes le suivent aveuglément et manquent l'étape initiale fondamentale de découvrir et de définir le problème qu'ils essaient de résoudre. Il est vraiment important de réfléchir un peu plus avant de vous précipiter pour essayer d'accélérer votre livraison.

*Crédit photo : Eden Constantino (Unsplash) *