Avez-vous vraiment besoin d’agilité ?

Bien sûr, le processus offre des avantages pour de nombreux produits numériques. Mais parfois, l’agilité n’est pas la meilleure solution pour vos besoins, explique Builtin.

Aujourd’hui, lAgile est plus qu’une méthodologie. C’est un marqueur, un club exclusif, un shibboleth. Si vous utilisez l’agile, vous êtes légitime. Si vous ne le faites pas, c’est que vous n’avez manifestement pas lu suffisamment le Harvard Business Review.

En raison de l’importance accordée à ce label, les équipes affirment souvent qu’elles utilisent l’agile alors qu’en réalité, elles en utilisent des parties ou même une seule caractéristique. Il n’y a rien de mal à cela. Les équipes de développement de logiciels doivent utiliser le processus qui leur permet le mieux d’atteindre leurs objectifs commerciaux et leur feuille de route produit.

La plupart du temps, ce processus aboutit à un développement logiciel agile. Mais il y a des cas où l’agilité n’est pas la meilleure solution, que ce soit pour des raisons budgétaires ou d’autres contraintes du marché.

Quand l’agilité est la meilleure solution

La méthodologie agile présente des avantages incontestables, en particulier pour les applications SaaS.

  • En fin de compte, elle est généralement moins coûteuse que le développement traditionnel.
  • Elle oblige à optimiser les processus et à innover.
  • Elle encourage un retour d’information constant et donc une amélioration continue.
  • La méthode agile permet de pivoter rapidement, sans « perdre » du temps et des ressources en cas d’échec.

Les avantages sont également plus nombreux, c’est pourquoi tant d’utilisateurs vivent et meurent sur la colline agile. Les avantages ci-dessus amélioreront le processus pour de nombreux produits numériques, mais pas tous.

Quand l’agilité n’est pas la meilleure solution pour votre équipe produit

  1. Pour que la flexibilité ait un sens, il faut d’abord que le coût du changement soit assez faible.
  2. Deuxièmement, vous devez être en mesure de recueillir les réactions des utilisateurs en temps utile.
  3. Et troisièmement, vous devez avoir la possibilité d’être rétrospectif – d’examiner le système que vous construisez et d’analyser ce qui fonctionne.

Dans de nombreux cas, ces trois exigences ne sont pas remplies, et il est donc nécessaire d’explorer des options de développement non agiles. Voici quelques scénarios possibles où cela pourrait se produire.

Les coûts d’itération ou de déploiement sont élevés

Les itérations ont lieu toutes les deux semaines dans un environnement agile standard, mais cela nécessite que les itérations soient peu coûteuses, ce qui n’est pas toujours le cas.

Un exemple pourrait être les intégrations de matériel.

Si vous avez un composant logiciel pour un élément de matériel, vous devez prendre en compte les composants du matériel et construire l’usine autour de celui-ci. Si vous changez de composants, vous devez alors reconstruire votre usine, ce qui n’est pas rentable.

De même, si le matériel n’est pas connecté à internet (par exemple, un vélo électronique ou un appareil médical), les coûts de déploiement sont élevés. En choisissant de déployer souvent, les utilisateurs seront fragmentés sur différentes versions d’un même logiciel, ce qui augmentera les coûts associés au soutien de ces utilisateurs.

Un autre exemple est tout ce qui nécessite l’approbation d’organismes gouvernementaux, comme la Food and Drug Administration. Toute modification apportée après l’approbation de la FDA nécessitera un nouveau cycle d’approbation, ce qui est incroyablement long et coûteux.

Que faire à la place ? Même si ce n’est pas l’idéal, votre équipe produit devra établir une feuille de route stratégique qui tienne compte des restrictions en matière d’itération et de déploiement. Mesurer le succès d’une mise à jour annuelle, par exemple, est difficile et peut brouiller les calculs de retour sur investissement (ROI). Dans de tels cas, vous devrez créer un processus d’itération et de déploiement au service de votre équipe et de votre produit.

Vous ne pouvez pas obtenir de commentaires en temps utile

L’idée du retour d’information est utile, mais si elle est trop coûteuse, alors elle ne peut pas s’intégrer dans un processus agile.

Reprenons l’exemple du vélo électronique. Les habitudes d’achat et les cas d’utilisation étant très dispersés, il se peut que vous ne puissiez pas recueillir un retour d’information opportun ou cohérent.

Que faire à la place ? Demandez-vous s’il y a des procurations pour le client. Pouvez-vous créer et exécuter un test automatisé ? Existe-t-il une simulation que vous pouvez exécuter en fonction de la chimie du matériel ? Les tests et les simulations peuvent certainement vous aider à recueillir un retour d’information productif sur l’expérience de votre logiciel.

Vous ne pouvez pas être rétrospectif

Même dans les environnements purement agiles, les feedbacks ne sont pas faciles.

Les gens peuvent être malhonnêtes ou complaisants, en passant par les étapes sans fournir de véritable aperçu. Si vous ajoutez à cela des couches supplémentaires de travail à distance et de hiérarchie, votre rétrospective n’a plus aucune valeur.

Que faire à la place ? Que vous fassiez des rétrospectives traditionnelles ou non, il est essentiel de discuter de ce qui a fonctionné et de ce qui n’a pas fonctionné dans votre processus. Trouvez un processus qui fonctionne pour vous et mettez-le en œuvre. Encouragez tout le monde à prendre la parole, à se répartir en petits groupes ou à créer des questions rapides pour accroître la participation.

En fin de compte, trouvez ce qui convient à votre équipe

Aujourd’hui, agile est surtout un mot. Ce qui est important, c’est de trouver un processus qui fonctionne pour votre équipe, votre produit, votre secteur et vos limites légales.

Les cérémonies traditionnelles de développement agile sont des formalités. Souvent, elles passent à côté de l’essentiel si l’agile devient pesant.

Prenez plutôt du recul et analysez votre environnement unique. Demandez-vous comment votre processus pourrait être amélioré. Si c’est avec des cérémonies agiles strictes, tant mieux. Mais si vous devez vous écarter des mêlées et des itérations de deux semaines pour des raisons commerciales, n’ayez pas peur de le faire. Après tout, toute la méthodologie agile est basée sur la recherche du meilleur processus possible, quoi qu’il arrive.

 

Via Builtin

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.