Comment vendre le développement Agile à des clients (cascade)

Notre atelier de développement aimerait vraiment faire des projets plus agiles, mais nous avons du mal à trouver des clients. Beaucoup de clients veulent un budget et une échéance. Il est difficile de vendre un client sur un projet agile lorsque nos concurrents fixent des délais et des prix fixes basés sur des cascades. Nous savons que leurs numéros fixes sont mauvais, mais le client ne le sait pas. Nous finissons donc par avoir mauvaise mine pour le client car nous ne pouvons pas fixer le prix ou une échéance, mais nos concurrents peuvent le faire.

Comment faire en sorte que votre force de vente vende avec succès un projet utilisant des méthodes de développement agiles ou un produit développé à l'aide de telles méthodes? Toutes les informations que j'ai trouvées semblent se concentrer sur la gestion de projet et les développeurs.

La clé pour bien le faire consiste à utiliser un contrat de support.

Fondamentalement, lorsque vous vendez le client pour la première fois, vous le vendez en fonction de votre expertise et vous le faites en cascade. Cela signifie un contrat qui définit la portée et une échéance ferme. C'est ce que veut le client. Le client connaît plus ou moins la portée. Waterfall fonctionne très bien, dans un environnement à portée fixe et définie, je dirais que cela fonctionne mieux que l'agile dans de tels environnements. Et dans ce cas, le client est plus à l'aise lorsqu'il a tendance à être nerveux, car il n'a jamais travaillé avec vous auparavant. C'est bon, Agile n'est pas toujours meilleur que la cascade.

Vous avez donc un contrat à prix fixe pour X scope. Ensuite, vous dites au client: « Regardez, vous allez vouloir apporter des modifications et vous allez avoir besoin de notre soutien pour votre post-production, réservons 20% de votre budget pour que ces choses-là soient utilisées au besoin par contrat de support . "

Si un changement devait survenir au cours du projet, différez-le simplement pour qu'il soit traité dans le contact de support. (En supposant que ce changement perturberait sérieusement le projet)

Les conditions du contact de support sont les suivantes: «Le travail à effectuer à l'heure, à la demande du client, peut être utilisé pour des demandes de modification ou pour le support et la maintenance système généraux .» BAM! Vous êtes en agile.

Vous pouvez ensuite continuer à étendre le contact de support et utiliser simplement le contact de support comme moyen d'exécuter de nouveaux projets. De plus, si ces heures sont achetées et payées à l’avance , nous accordons généralement au client un rabais de 15%. C'est gagnant-gagnant.

Agile n'exclut pas les délais et les budgets. Si j'étais un client et que je consultais un développeur et qu'il me disait qu'il ne pouvait pas me donner de délai ni de coût estimé, je mettrais en doute sa santé mentale. Et leur dire qu'ils ne comprennent tout simplement pas ne va pas marcher: ils doivent pouvoir budgéter et planifier.

Ils n'ont pas besoin de connaître votre processus de développement. Ils ont besoin de savoir combien de temps il faudra pour développer des fonctionnalités et combien cela coûtera. Donnez-leur un nombre basé sur l'hypothèse (non essentielle) que leurs exigences sont exactes à 100% et, lorsque leurs exigences changent, modifiez ensuite vos estimations.

Cela leur donne les postes budgétaires et les dates de déploiement souhaités, et lorsque les choses changent, votre processus vous permet d'avoir l'air flexible et accommodant.

Il semble que vos vendeurs créent une couche de problèmes de communication entre vos équipes de développement et vos clients. S'ils ne vendent pas leurs produits sur le marché des technologies de l'information depuis longtemps, ils peuvent considérer leur rôle comme étant de «déplacer le produit», ce qui signifie obtenir la signature d'un contrat «peu importe ce qu'il faut». En bref, ils sont motivés à fermer, peu importe ce qu’ils promettent. Dans de telles circonstances, ils vont suivre la langue du client le plus fidèlement possible.

Je suis un disque brisé citant ceci, mais voici: vous êtes sur la table d'opération et, sous votre contrôle, le chirurgien dit: "nous vous ferons partir à temps et dans les limites du budget". Génial. Est-ce que je serai en vie?

Si vous travaillez sur les organes internes d'une entreprise, vous arrêtez-vous à un moment quelconque? En règle générale, une application est affectée par des forces que ni vous ni votre client ne maîtrisez - réglementations, climat des affaires, comportement concurrentiel, émergence d'un nouveau paradigme, etc. Si vous dites simplement "nous ferons" chose x pour "prix y", le client reviendra trois mois plus tard et dira: «eh bien ...». Cela signifie généralement qu'ils savent quelque chose qu'ils ne savaient pas quand vous avez accepté un projet de cascade.

Ce qui pourrait fonctionner dans une telle situation est de montrer à votre personnel des ventes à quoi ressemble une promenade dans un canyon. À chaque tour, il y a des surprises. Il n'est pas possible de voir plus que trois mois environ. Ainsi, si un client demande un projet de 18 mois, il sera méconnaissable lorsque vous aurez presque terminé. Par conséquent, votre représentant commercial doit commencer par rechercher les retombées financières du projet. Cela augmentera-t-il les ventes de 10 millions de dollars? Dans l'affirmative, vaut-il la peine d'investir 2 000 000 $ pour gagner 10 millions de dollars supplémentaires? Si le client et le représentant des ventes convergent vers un engagement de 500 000 USD, il se peut que quelque chose ne tourne pas rond et que personne ne puisse dire ce que c'est, cela ne leur semble tout simplement pas bien. Ce qui «ne se sent pas bien», c'est un engagement à faire quelque chose qui risque d'être inutile.

Les deux derniers modèles d'avions de ligne à réaction ont une histoire de snafus. Healthcare.gov n'a même pas besoin de discussion. Si vous pouvez trouver des livres ou des articles de presse spécialisés sur les avions de ligne, vous pouvez expliquer certaines hypothèses qui se sont avérées optimistes et que les projets ont souvent manqué à leurs échéances. Cela était souvent dû à une sous-estimation de la complexité. Si vous ne pouvez pas vraiment comprendre sa complexité jusqu'à ce que vous commenciez à le coder, vous aurez besoin d'un «tour initial» pour avoir une meilleure idée des véritables problèmes. Le budget doit correspondre à une fraction du total des profits supplémentaires (ou des revenus dans certains cas), et ce nombre doit être supérieur à ce que quiconque pense que le projet actuel coûtera. Si vous pouvez montrer comment le dernier jalon peut être franchi sans dépasser la «limite de remboursement»,

Le principal obstacle à la réalisation des avantages d’Agile-Scrum en dehors du développement logiciel est son intégration aux mécanismes de contrôle existants. Ces mécanismes de contrôle sont stipulés en raison de divers prérequis organisationnels et sont normalement actualisés à l'aide de l'approche et de la méthodologie Linear Waterfall.

Quatre de ces conditions organisationnelles typiques sont décrites ci-dessous:

• Grandes entreprises mondiales - dans ces organisations matricielles hiérarchiques, le contrôle de portefeuille descendant est la règle. L'approche agile et libre d'esprit a du mal à s'adapter aux contrôles rigoureux. Plus précisément, les concepts sans plan Agile inhérents rendent Agile-Scrum difficile à avaler pour l’organisation.

• Industries hautement réglementées - certaines industries sont tenues par un organe de contrôle et de gouvernance de disposer d'un mécanisme de contrôle contraignant strict. Celles-ci peuvent être, par exemple, des unités commerciales de recherche sur le matériel, les aéronefs, les produits pharmaceutiques et le développement de produits. Bien que chaque équipe puisse utiliser Agile-Scrum, le processus de développement doit suivre une méthode d’approche linéaire en cascade rigoureuse pour la traçabilité et la gouvernance.

• Produits complexes prédéfinis - certains produits intégrés comprenant à la fois du matériel, des logiciels, des composants intégrés et bien plus encore, sont développés en tant que contrat avec un client final conformément à un ensemble prédéfini d'exigences. Dans ces cas, le degré de flexibilité requis est faible, bien que plus grand que prévu initialement. Le concept d'un carnet de commandes entièrement flexible d'Agile-Scrum souffre considérablement dans ces cas.

• Services informatiques génériques - une grande partie des activités quotidiennes et hebdomadaires des services informatiques axés sur la maintenance est ponctuelle. Les modifications apportées aux horaires quotidiens sont nombreuses et immédiates. Les interférences constantes dans le travail des équipes sont la norme. Le concept de la boxe temporelle et de l'absence d'interférence est difficile à maintenir dans ces situations.

Naturellement - plusieurs fois les quatre catégories distinctes décrites ci-dessus se mélangent; il est donc courant de trouver un produit complexe dans une grande entreprise mondiale qui doit se conformer à une réglementation stricte.

Sur la base de l’expérience pratique, la méthode recommandée pour aborder ces scénarios et d’autres consiste à habiliter le bureau de gestion agile pour qu’il agisse en tant que facilitateur, conducteur et traducteur entre les équipes Agile-Scrum émergentes et les éléments de cascade linéaire.

Reportez-vous au tableau ci-dessous pour connaître les directives spécifiques.

Source - Interface entre les approches linéaires en cascade et agiles par Michael Nir

Nous organisons 2 ou 3 sessions d’estimation avec le client potentiel et nos développeurs. Nous discutons du travail à effectuer et définissons les critères d’acceptation. Les développeurs estiment le travail en points d’histoire au cours de la réunion.

Ensuite, nous vendons au client un certain nombre de points d’histoire. C'est possible parce qu'il a une bonne idée de la valeur des points d'histoire. Nous lui disons qu'il a la possibilité d'ajuster son arriéré / sa portée pendant le projet et que ce sera facile grâce à l'utilisation des points de scénario. Nous lui disons également qu'il y aura une livraison fréquente de logiciels fonctionnels afin qu'il puisse suivre les progrès et obtenir de nouvelles informations.

En s'accordant sur un certain nombre de points d'histoire, le client est assuré d'obtenir un bon rapport qualité-prix. S'il ne modifie pas son carnet de commandes, il a son projet à prix fixe / périmètre fixe, mais d'après mon expérience, il apportera des modifications. En effectuant les estimations en présence du client potentiel, nous essayons de construire une relation basée sur l'ouverture et la confiance.

Nous avons réussi à convaincre les clients comme vous le décrivez, qui "veulent un budget et une échéance", et ils étaient heureux de vouloir vraiment comprendre ce dont ils avaient besoin, au lieu de travailler à partir d'un document. Nous avons montré que nous voulions investir dans ces projets.

Au cours des sessions d’estimation, nous avons estimé l’ensemble de leur arriéré. Cela a donné x points d'histoire. Nous avons suggéré d'ajouter 25% pour les fonctionnalités qui n'étaient pas encore claires ou connues à l'époque. Avec le retard estimé dans le contrat, ils ont été rassurés qu'ils obtiendraient tout pour le budget fixe.

À l'origine, l'offre était le temps et le matériel. Comme ils souhaitaient avoir une offre à prix fixe, nous avons suggéré de travailler au prix que nous leur avons donné et d'utiliser les 25% de points de scénario supplémentaires pour les imprévus. Si les choses se passaient bien, la partie des 25% non utilisée pour couvrir les retards que nous avons rencontrés serait utilisée pour offrir davantage de fonctionnalités au client.

Cela les a stimulés de différentes manières: premièrement, ils ont tout mis en œuvre pour permettre à nos développeurs de travailler aussi vite que possible, car cela était clairement dans leur propre intérêt. Nous n'avons jamais eu à attendre les réponses aux questions. Deuxièmement, ils ont vraiment compris le concept des points d’histoire. Avant le début du projet, ils avaient déjà retiré certaines histoires et nous avaient demandé d'estimer d'autres histoires. Aucune négociation de contrat compliquée n'était nécessaire pour cela.

Nous les avons tenus au courant des progrès et avons maintenu une communication très ouverte. Ils ont reçu un rapport d’avancement toutes les deux semaines: x% des points d’histoire réalisés en y% du temps estimé laisse z% des points d’histoire supplémentaires disponibles. Nous avons eu un début un peu difficile mais nous avons réussi à rattraper les estimations d’ici la fin du projet, ce qui laissait 100% des points d’histoire supplémentaires disponibles pour un développement supplémentaire. Le client était heureux car il obtenait tout ce dont il avait vraiment besoin (et c'était un peu différent des fonctionnalités initialement demandées, il en a supprimé certaines et en a ajouté d'autres).

Le client était également satisfait du fait que tout avait été livré dans les délais prévus (où il a également tout mis en œuvre pour nous aider, comme la chasse aux billets, la réponse immédiate aux questions, l'implication des utilisateurs dans des réunions d'analyse hebdomadaires et également dans des tests de fonctionnement).

Mon entreprise était heureuse parce que nous avons livré dans les délais et dans les limites du budget. Mon entreprise était également heureuse car le succès de ce projet a ouvert la porte à d'autres projets. Nous avons même été mentionnés dans le magazine mensuel du client qui a été envoyé à des personnes du monde entier.

Faire les bonnes estimations était la partie la plus difficile du projet, mais les sessions d'estimation à l'avance nous ont aidés à comprendre la difficulté et les risques. Cela nous a permis de donner une estimation basée sur des faits et d’évacuer beaucoup d’inconnues.

Essayer d'utiliser les méthodes Agiles dans un environnement de conseil / enchères est très difficile lorsque le client n'est pas à bord.

S'ils sont habitués au style Waterfall "voici nos exigences, combien et combien de temps cela prendra-t-il?" tapez des projets et lancez un appel d’offres, il n’ya pas vraiment le temps de les convaincre qu’Agile ou tout autre moyen est meilleur.

Agile a ses avantages (et ses inconvénients bien sûr), mais très franchement, le client ne sait souvent pas ou ne se soucie pas des détails dans les coulisses.

Ils veulent deux choses: les coûts et le calendrier. Et une fois que vous leur dites cela, ils le veulent alors moins cher et plus tôt. Et vous savez quoi, nous voulons tout. Toutes les exigences. Personne ne peut attendre ou être haché.

Et même si je n'aime pas les vendeurs dans la plupart des milieux, ne soyez pas trop dur envers les vendeurs. C'est un travail difficile.

Ils ne construisent pas de logiciels, ils n'ont généralement aucune idée de la façon dont tout cela fonctionne au-delà des mots à la mode.

Cependant, ils doivent établir des échelles de temps et des coûts en fonction de la satisfaction de certaines exigences. Peut-être qu’ils ont avec eux des techniciens spécialisés dans la technologie, mais ils doivent faire une vente pour que les choses se déroulent bien.

Comment faire en sorte que votre force de vente vende avec succès un projet utilisant des méthodes de développement agiles ou un produit développé à l'aide de telles méthodes?

En faisant en sorte que votre force de vente amène le client au bureau. Le but de l'agilité est d'obtenir un retour immédiat du client afin que vous puissiez produire ce qu'il veut (sans plus). Amenez-les, demandez ce qu'ils veulent. Deux semaines plus tard, apportez-les et montrez-leur une démonstration / prototype. Vendez-les sur cette interaction. Montrez-leur que vous avancez et expliquez-leur que ce genre d'itération est ce que vous aimeriez faire pour qu'ils obtiennent exactement ce qu'ils veulent.

Donnez des estimations de la quantité de travail nécessaire (c'est ce qu'est un budget après tout), mais laissez-les le pouvoir (lire: responsabilité) d'inclure ce qu'ils veulent intégrer dans leur budget.

Je pense que la réponse est que dans la plupart des cas, vous ne le ferez probablement pas. J'essaierais de voir cela au début comme une petite partie de votre entreprise - peut-être 20%, le reste sous un modèle traditionnel. Avec le temps, j'essayais de me concentrer davantage sur les produits Agile et les clients et de faire en sorte que cette partie grandisse davantage.

Une autre solution consiste peut-être à essayer d’utiliser les deux approches. Utilisez l'approche de la cascade avec la haute direction et les gens de la négociation des contrats. Par exemple, "un système permettant aux clients de gérer leurs portefeuilles et de prendre des décisions d'investissement à l'aide de dispositifs de téléphonie basés sur un navigateur et mobiles (Apple et Android)". ou quelque chose comme ça. Ensuite, utilisez Agile pour développer les fonctionnalités plus détaillées de l'équipe de développement, telles que Créer une page d'accueil, Créer une page de connexion, Créer un historique de gestion de portefeuille, Créer une connexion mobile, etc.

Une autre idée est de faire d’Agile votre différenciateur. Je sais que beaucoup, sinon la plupart des grandes entreprises, ne font pas Agile. Cependant, la plupart (la grande majorité selon mon expérience) des petites entreprises le sont. Je pense qu'Agile se développe rapidement et cela continuera. L'avantage de cet itinéraire est que vous proposez ce que vous voulez le plus à faire aux clients qui le reconnaissent déjà. Cette approche nécessitera un certain travail dans le temps sans aucune garantie de succès.

Vous pourriez également trouver un avantage si vos clients aiment les tests. Avoir des produits bien testés peut être une vente plus facile à certains clients. Un livre que je trouve utile dans ce domaine est "Agile Testing" de Adison Wesley Press.

Vous pouvez également utiliser les événements en cours pour appuyer votre cas. Par exemple, le site de soins de santé actuel (écrit en octobre 2012) est un excellent argument pour NE PAS gérer les changements qui étaient nécessaires deux semaines avant la mise en production. En outre, la sur-ingénierie apparente aurait probablement été mieux traitée avec des méthodes plus agiles.

Contactez d'anciens clients satisfaits de votre travail. Surtout s'ils sont Waterfall to Agile convertis. À tout le moins, les convertis qui n'étaient pas vos clients.

Leurs témoignages (en tant que client) l'emporteront sur tout ce que vous pourriez dire. Ils peuvent répondre aux préoccupations et aux peurs de votre nouveau client plus que vous n'auriez jamais pu le faire.

Du point de vue de la gestion, un budget et une échéance sont un besoin commercial du projet. Vous devez vous assurer de répondre à ces besoins, et si vous regardez les témoignages d'une entreprise sur le changement, vous remarquerez que cela se présente directement. Si vous examinez les témoignages de développeurs sur le changement, vous remarquerez souvent que ce n'est pas le cas.