Skip to main content

Raisons de l’adoption d’Agile par Salesforce

Une fois cette unité terminée, vous pourrez :

  • Expliquer pourquoi Salesforce utilise Agile
  • Énumérer quelques avantages d’Agile
  • Définir ce qu’est Scrum
  • Expliquer le concept de « définition de terminé »
  • Pourquoi les processus agiles fonctionnent mieux pour Salesforce

Imaginez que vous vous rendez à un évènement Dreamforce, pour au final apprendre sur place qu’aucune conférence ne sera donnée et qu’il n’y aura pas d’annonces de nouveaux produits ou services, ni d’innovations ou de fonctionnalités prêtes pour la production disponibles l’année suivante.

Cela a failli arriver à Salesforce en 2006, mais nous avons évité ce scénario catastrophe en mettant en œuvre un nouveau workflow qui a révolutionné la façon dont nous développons et livrons nos produits.

Depuis 1999, année de la fondation de Salesforce, notre pôle Technique et produits réalisait son travail avec la régularité d’un métronome. La communication et la collaboration entre ses différentes composantes était toujours simple et fluide. Toutefois, en 2006, nous avons connu une croissance phénoménale : nous assistions plus de clients, générions plus de chiffre d’affaires, proposions plus de produits et avions une plus grande entreprise que jamais auparavant. Comme pour toute poussée de croissance, cela ne s’est pas fait sans douleur. 

Tous les processus qui, avant, se déroulaient avec aisance ne fonctionnaient plus aussi bien. En conséquence, nous avons commencé à connaître un ralentissement de l’innovation. 

Adapter la communication, la collaboration et la gestion à ce changement d’échelle tout en respectant les dates de lancement était devenu un véritable défi. Il était clair que nous avions besoin d’une nouvelle approche, centrée sur un processus de livraison des produits simple, qui garantirait des lancements en temps et en heure. 

L’image est un graphique qui montre comment le temps entre les sorties des versions principales a augmenté tandis que le nombre de fonctionnalités produites par équipe a diminué entre 2000 et 2006.

Nous avons donc fait ce que nous faisons de mieux : nous avons pris un risque et réinventé notre façon de fournir des solutions. Nous avons adopté un ensemble de principes et de pratiques agiles.

Pourquoi Agile ?

Chez Salesforce, une grande partie du travail est itérative et s’appuie sur l’innovation. En d’autres termes, le résultat final n’est pas toujours connu à l’avance et le chemin pour y parvenir évolue. C’est toujours une nouvelle aventure ! 

Cela ne veut pas dire que toutes les équipes de Salesforce utilisent des processus agiles. Certaines équipes utilisent le cadre de travail en cascade, qui est un processus de gestion de projet beaucoup moins flexible. Le processus à employer dépend de ce que vous savez (ou ignorez) lorsque vous abordez la réalisation d’un élément de travail.

Voici un aperçu rapide des pratiques en cascade.

  • Tout est planifié dès le départ.
  • Les exigences sont documentées en détail avant la mise en œuvre.
  • Chaque étape doit être terminée avant de passer à la suivante.
  • Le résultat à atteindre est déterminé dès le début du processus.

Planifier ou s’adapter

Si vous essayez de déterminer quel est le processus vous convenant le mieux, voyez les choses sous cet angle : si vous peignez un tableau et que vous avez décidé de vos couleurs, de la manière dont vous serez installé, du temps que vous passerez à peindre et de l’apparence de votre résultat final, vous avez peu de marge de manœuvre pour apporter des modifications en cours de route. Cela ne veut pas dire que votre tableau ne sera pas un Picasso, mais votre processus ne peut pas prendre en compte de nouvelles idées ou des commentaires pouvant influer sur le résultat final (en vue de l’améliorer, bien sûr). Ce cas de figure s’apparente à une approche en cascade.

Par contre, si vous peignez de manière itérative, il est fort probable que vous soyez amené à apporter des modifications à votre œuvre en fonction des premiers retours à son sujet, de nouvelles idées, voire de nouveaux apprentissages (ces couleurs ne vont pas ensemble !) plutôt que de la peindre de façon planifiée et progressive. C’est une approche plus agile. 

Voici une représentation de ces deux processus de peinture : 

L’image montre une illustration d’une peinture en cours de réalisation représentant une personne. Elle montre à quoi ressemblerait la peinture aux différentes étapes du processus en cascade et du processus agile.

Image inspirée du travail de Jeff Patton, utilisée avec autorisation, jpattonassociates.com

La complexité du travail

Vous savez désormais que certains processus conviennent mieux à certains types de tâches. Alors, comment déterminer le meilleur processus pour vous et votre équipe ?  

Lorsque vous essayez de choisir un processus de workflow, posez-vous les questions suivantes : 

  • Que savons-nous de ce projet ?
  • Dans quelle mesure les objectifs et les exigences du projet sont-ils clairs ?
  • Dans quelle mesure la solution est-elle claire et bien définie ?
  • Quelle est l’expérience de l’équipe et des parties prenantes avec ces méthodologies ?
  • Quelle est la complexité du travail ?

Situations dans lesquelles choisir une approche en cascade

Tâche simple :

  • La tâche est simple et prévisible.
  • N’importe qui peut déterminer comment la réaliser.

Tâche complexe :

  • La tâche est prévisible, mais nécessite une expertise particulière.
  • La tâche peut être automatisé.

Situations dans lesquelles choisir une approche agile 

Tâche complexe :

  • Le tâche repose sur un retour régulier d’informations, implique des risques et s’appuie sur l’innovation.
    • Vous voulez essayer quelque chose, voir comment cela fonctionne et pouvoir changer de cap en fonction des nouvelles informations recueillies.
    • Vous créez de nouveaux produits, logiciels et services et faites des choses qui n’ont jamais été faites auparavant.

Mise à l’échelle de Salesforce de manière agile

À ce moment-là, les dirigeants de Salesforce se sont lancés dans un projet pilote visant à mettre en œuvre des pratiques agiles au sein de différentes équipes. Il y a eu quelques réticences, mais les dirigeants de Salesforce ont soutenu le concept. Ainsi, en 2006, l’équipe Salesforce Technique et produits s’est réorganisée en une équipe de développement agile.

Comment avons-nous procédé ? Eh bien, nous avons : 

  1. Adopté un nouvel état d’esprit vis à vis des livraisons
  2. Mis en place des processus standardisés
  3. Adopté les principes Lean (nous vous en dirons plus à leur sujet plus tard !)
  4. Normalisé ce que la notion de « travail fini » signifie

Notre nouvelle mentalité agile 

Qu’est-ce que ce processus agile exactement ? Pour faire simple : « agile » est un terme générique désignant diverses pratiques techniques, processus, cadres de travail, principes et valeurs qui invitent à la flexibilité dans les workflows et à l’amélioration constante des produits.  

Il s’agit d’une approche itérative dans laquelle les équipes créent des livrables qui évoluent de manière progressive tout au long du projet, au lieu de se concentrer sur la production d’un seul produit fini livré à la toute fin du processus. Les méthodes agiles renforcent la cohérence au sein des équipes, améliorent la qualité et obligent tout le monde à mesurer et à gérer l’avancement pour offrir plus de valeur aux clients plus rapidement. 

Cela s’est avéré la solution idéale pour Salesforce, car nous cherchions à résoudre nos problèmes de communication et de mise à l’échelle.

Vue d’ensemble de notre nouveau processus agile 

L’un des processus agiles que nous avons choisi de mettre en œuvre chez Salesforce s’appelle Scrum. Nous l’avons complété par des principes spécifiques qui définissent encore notre façon de travailler aujourd’hui.

En quoi consiste Scrum ?  

Scrum est un processus impliquant des rôles, des réunions et des éléments livrables définis qui offre un cadre de travail permettant d’apporter rapidement une valeur ajoutée de haute qualité à nos clients.

Pourquoi avons-nous adopté Scrum ? 

Scrum nous apporte un cadre de travail flexible nous permettant de découvrir ce qui fonctionne et ne fonctionne pas dans nos produits et d’y apporter des modifications en conséquence. Avec Scrum, les responsabilités et les préoccupations vis à vis des tâches à réaliser sont partagées entre tous. 

À quoi ressemble le processus Scrum chez Salesforce ? 

Lorsque nous l’avons adopté, 150 personnes ont été réparties en petites équipes multidisciplinaires travaillant en cycles courts (nous les appelons des sprints). L’objectif était alors de garantir les livraisons et d’organiser notre processus. À l’heure actuelle, la majorité des équipes Salesforce Cloud utilise des variantes de Scrum. 

En quoi consistent les principes Lean ?

Nous avons également adopté les principes Lean. Au nombre de sept, ils décrivent notre workflow et notre processus de livraison. Ils reflètent notre culture Ohana, soulignant l’importance du travail en équipe pour favoriser le succès de notre structure. Nous reviendrons plus en détail sur eux dans une unité ultérieure.

La nouvelle définition du travail « terminé »

Une fois notre nouvelle façon de travailler mise en place, les équipes pouvaient répéter et améliorer leurs processus de manière efficace au fur et à mesure qu’elles prenaient connaissance de nouvelles informations sur leurs workflows et les produits. Toutefois, comment pouvions-nous déterminer que nous en avions fini avec un élément de travail ?  

Facile. Nous avons normalisé ce que l’on appelle une définition de terminé (abrégée en DoD, pour « Definition of Done ») au sein du pôle Technique et produits, afin que tout le monde soit en mesure d’indiquer clairement qu’un travail est… terminé !

Imaginez le scénario suivant : on vous demande de créer une nouvelle fonctionnalité pour un produit. Vous confiez cette nouvelle tâche à votre équipe et lui demandez de mettre la fonctionnalité en œuvre ce mois-ci. Elle s’exécute, puis passe à autre chose. Quelques mois plus tard, l’élément de travail terminé refait surface, des problèmes y ayant été décelés. Peut-être que des clients se sont plaints car les intégrations n’avaient pas été complètement testées. Il se peut également que des problèmes de sécurité subsistent, ou que les performances ne soient pas à la hauteur. Conclusion : l’élément de travail n’était pas vraiment terminé, du moins pas assez pour être déployé.

Notre définition de terminé est un ensemble de directives qui dicte tout ce qu’une équipe doit faire avant de pouvoir dire que son travail est vraiment terminé. La création d’un tel standard est essentielle si l’on veut respecter l’une des valeurs fondamentales de Salesforce : la confiance.

En résumé

Nous n’avons de cesse de nous demander : « Faisons-nous la bonne chose, de la bonne manière ? » C’est ainsi que nous nous assurons que nos clients sont toujours au centre de tout ce que nous faisons.  

La rigueur du processus Scrum et les états d’esprit Agile et Lean sont des éléments clés pour nous permettre d’améliorer nos livraisons et de réaliser des déploiements plus fluides. Il s’agit d’enjeux de taille pour Salesforce : nous proposons en effet trois nouvelles versions principales à nos clients chaque année. 

Partagez vos commentaires sur Trailhead dans l'aide Salesforce.

Nous aimerions connaître votre expérience avec Trailhead. Vous pouvez désormais accéder au nouveau formulaire de commentaires à tout moment depuis le site d'aide Salesforce.

En savoir plus Continuer à partager vos commentaires