Scrum et les méthodes Agile en tant qu'opportunité Business

Comment Scrum peut vous faire décrocher des contrats...

Alors ça y est, vous avez découvert Scrum ! Vous en avez parlé avec d’autres collègues ou amis, vous avez lu moult blog et articles. Votre matériel est prêt, vous avez lu des livres jusqu’à plus soif. Vous avez sélectionné un projet que vous pourriez…que dis-je…que vous voulez réaliser en utilisant Scrum ! Vous êtes fin-prêt.

Reste juste un léger détail à régler… le budget, et là souvent c’est le drame. En effet, autant Scrum et les méthodes Agiles peuvent être séduisantes pour des personnes travaillant dans l’ICT, autant elles peuvent paraître saugrenues ou étranges à des décideurs (Sponsors, CTO, Clients,…). Or, cher Scrum Master dans l’âme, c’est précisément ces personnes qu’il faudra convaincre de l’intérêt de cette méthode car ce sont ces personnes qui vont décider d’allouer ou non du budget pour ce projet.

Une réelle opportunité business

Lors de mon dernier projet dans le secteur public Belge, j’étais là, à l’origine, pour une mission de consultance afin de coordonner la rédaction un cahier des charges pour la réalisation de deux portails Web. Nous avons écrit le cahier des charges en collaboration avec le client mais au moment de l’estimation du budget (de plus de 2.000.000 €) le client nous signale qu’il n’a pas cette somme. Les problèmes n’arrivant jamais seuls,  nous étions de plus confrontés à un autre problème: la longueur de la procédure de l’appel d’offre. Et pour couronner le tout, pour des raisons qui lui sont propres, le client avait besoin d’avoir « quelquechose » 7 mois plus tard.

Suite à cela pour gagner du temps sur la procédure d’appel d’offre, mon Manager me propose d’utiliser une procédure d’appel d’offre simplifiée, plus rapide mais beaucoup plus risquée. C’est à ce moment là que je lui ai parlé de Scrum. Je lui ai parlé de la méthode non pas en termes de daily scrum, product backlog ou sprint review. Je lui ai simplement expliqué que je connaissais une méthode qui pouvait en 6 mois délivrer « quelquechose » qui tourne en production. Je lui ai donc fait une proposition d’équipe type en fonction des besoins de notre projet:

  • 2 personnes ayant un profil d’Analyste Programmeur expérimenté
  • 1 personne ayant un profil de Webdesigner
  • 1 personne ayant un profil d’Architecte
  • 1 Scrum Master (votre humble serviteur)
  • 1 personne ayant un profil d’Expert en Géolocalisation

Le budget disponible pour le projet étant fixe, nous avons décidé de mettre sur pieds une équipe mixte composée d’internes et d’externes. Il nous restait alors à « traduire » le cahier des charges en une suite de User Stories consignées dans notre product backlog.

Résultats à ce jour:

  • Pour notre client une success story à un budget bien moindre
  • Pour notre société de consultance, plusieurs consultants sur projet pendant 1an et demi
  • Pour votre serviteur, avoir pu utiliser Scrum avec succès et le mettre au service du client

Des compromis

Vous l’avez donc compris, dans une majorité des cas, pouvoir réaliser un projet en utilisant Scrum/Agile passera par l’assentiment d’une personne généralement peu au courant de ces méthodes. La principale difficulté sera de faire accepter à votre sponsor, client que vous vous engagez sur un ensemble d’axes à réaliser, un ordre de grandeur et pas sur une liste de fonctionnalités précises (le product owner pouvant changer d’avis).

N’hésitez pas à raisonner avec votre client en terme de contraintes: Budget, Planning, Fonctionnalités. Dans notre exemple nous avons convenu avec notre client d’une deadline fixe, d’un budget fixe mais en lui demandant de pouvoir « jouer » sur les fonctionnalités. Et vous savez quoi ? Ca tombe bien vu que c’est principalement un des atouts de Scrum ;-)

N’hésitez pas également à faire des compromis… Votre client a peut-être déjà une méthodologie en place vous « obligeant » à produire certains document: Project Charter, P.I.D, Progress Report. C’est une bonne pratique de négocier comme ceci: ok je vais faire tes documents de méthodologie et de ton côté tu t’engages à respecter la méthode.

Si vous n’avez pas la fibre commerciale n’hésitez pas à demander conseil à un chef de projet, à un coach ou pourquoi pas un de vos « commerciaux » dans votre société ils pourront vous donner d’excellents conseils sur la meilleure manière d’amener cette méthode à un client.

Enfin vous pouvez aussi rassurer votre client en démarrant un projet pilote. Choisissez alors un petit projet court à risque très limité. Une réussite sur un tel projet vous amènera certainement d’autres opportunités.

Parce qu’en fin de compte l’idée derrière tout ça c’est de pouvoir utiliser une méthode qui amène du sens dans l’entreprise et mettre cette méthode au service des besoins du client…non ?!

Bonne chance à tous dans vos réalisations !

Bruno.

Ps: Les deux Portails Web que nous avons réalisé en utilisant Scrum et les méthodes Agile: Portail Bruxelles Mobilité et Portail Espaces Publics

Plus d’infos:

Agile Business Conference 2008 – Agile: Why Should Your Business Care?

Qu’est-ce que Scrum ?



This content is published under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.

Hullaert Christof

Analyste programmeur, c’est une méthode que je découvre à la lecture de ton blog. Elle semble intéressante pour certains domaines de développement et pourrait même être appliquée à bien d’autres domaines que l’informatique.
Sans te mettre en porte à faux vis à vis de tes clients ou de tes supérieurs, te serait il possible de donner plus de détail sur le rôle que tu as joué concrètement dans l’élaboration du projet en tant que « Scrum Manager » car si je m’en réfère à ce que je crois avoir compris, celui-ci est là pour faciliter la tâche des différents intervenants, à gérer pour eux tout un tas de problèmes qui n’est pas spécialement de leur ressort ou de leurs attributions.
Aussi serait-il possible d’avoir un avis, en situation réelle, de tous tes collaborateurs sur le projet afin de voir la position de chaque intervenant et leur rôle dans le projet global.

Autre chose, je vois qu’ils étaient deux analystes programmeurs. Y a t’il un lien avec d’autres types de méthode, style l’extreme programming?
Est-il d’après toi possible de mixer ensemble ces différentes méthodes? Et pourquoi?

++
Christof

brunosbille

Hello Christof,

Tout d’abord tu as 100% raison quand tu dis « et pourrait même être appliquée à bien d’autres domaines que l’informatique. » Une des spécificité de Scrum c’est qu’elle peut s’appliquer à n’importe quel domaine. Rénover une maison, préparer son mariage, faire un projet software, un jeu etc… Et ce
contrairement à L’Xtreme Programming par exemple.

Pour le rôle de Scrum Master je dirais que son rôle est de faire tout pour que l’équipe sache travailler. Donc aussi bien qu’ils aient un PC, régler un problème avec un sous-traitant ou bien qu’ils aient un endroit au calme pour travailler.

Bonne idée pour les intervenants, je vais leur demander de mettre un commentaire, tu peux déjà aussi les voir sur la vidéo de mon post précédent

Pour moi c’est une très bonne choses de mixer le tout avec des pratiques Agile, nous n’avons pas fait de pair programming. Pourquoi ? Déjà en amenant Scrum c’était révolutionnaire pour le client. Mais si tu arrives à gagner la confiance du client (en réalisant un projet « successfull » ;-) pourquoi pas amener cela par la suite je n’ai rien contre. je suis plutôt partisant du « essayer un peu de tout » et voir ce qui convient à l’équipe.

Bruno ;-)

Tom

Salut venerable scrum master (ca fait un peu jedi comme titre quand meme ;) ),

merci pour ton article tres interessant.
Voici un autre retour d’experience , mon client ne souhaitait pas utiliser scrum sur ses projets et respecter une methode « waterfall » classique.
Nous avons donc utilisé certaines pratiques Agile dans un context orienté PMI:
– stand up meeting
– Scope divided in functional package to create sprint delivery (sprint preparation, dev, test phase)
– Users involved in testing after each sprint delivery to provide feedback.
– poker estimation during sprint preparation.
– sprint feedback after each sprint.

oups, je suis passé en anglais ;)
Mais par contre nous avons gardé certains contraintes venant du l’approche waterfall:
– un budget et un planning pour un scope fixé en debut de projet.
Le planning au niveau de la phase developpement a neanmoins été divisé en sprint. Et apres chaque poker estimation, un check aux milestones communiquées pour vérifier si les nouvelles estimations respectaient toujours le planning.
– Suivi budgetaire et planning, en mode PMI. Donc pas de burtdown chart, de points de complexité et de velocité. Mais à tout refaire, je pense que cela serait possible de l’y ajouter.
– Et pas de product backlog ni de user stories, nous avons effectué une phase d’analyse functionelle et technique complète avant de commencer le development (Ces analyses devaient etre formellement validées avant de passer à la phase suivante). Le key user n’etant pas present (souvent) sur le projet les analyses étaient le principal point de contenu du scope.

Malgres tout, la cohesion et la responsabilisation de l’equipe ont énormement augmentées et le retour utilisateur est pour l’instant satisfaisant.
Une premiere etape pour esperer les convaincre de passer à du full scrum par la suite! ;)

brunosbille

Hello Tom,

Bon je t’avoue qu’étant petit j’étais fan de Luke Skywalker, mais à l’adolescence je me suis plutôt tournée vers Ian Solo. Maintenant le chemin pour arriver à la sagesse de maître Yoda est longue :-)

Sinon quel beau retour d’expérience que tu nous donnes là…que dire…tu as tout compris ! C’est effectivement une très bonne approche de faire avec l’existant et d’amener des choses nouvelles, on ne peut toujours pas tout révolutionner ! Par contre comme tu l’expliques bien une bonne première expérience peut amener le client à l’écoute de nouvelles choses…

C’est tout le mal que je te souhaite.

Pour l’anglais je me pose effectivement la question de comment rédiger…français, anglais, un mix ? deux blogs distinct…toutes les suggestions ou attentes sont les bienvenues !

Enfin si jamais tu voulais écrire un ou deux articles sur tes retours d’expérience n’hésite pas à me contacter !

Bruno ;-)

Johan ten Hoedt

Salut Bruno,

Bravo pour le contenu de ton blog et la méthode agile que tu as su utiliser. Le résultat final est d’ailleurs incroyable.

Tu parles à un moment de budget, je souhaiterais savoir si ce n’est pas indiscret à combien est revenu le budget du client (à peu près). Car tu disais que scrum permet de descendre les coûts ?? Est ce sur la composition de l’équipe uniquement ou autre chose ?

Cordialement

Johan

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *