vos clients sont-ils prêts pour Agile ?

Are Customers Ready for Agile?

http://www.scrumalliance.org/articles/403-are-customers-ready-for-agile par Shweta Darbha

prêt à essayer une nouvelle approche?La méthodologie « waterfall » a été présente depuis si longtemps que les organisations de développement logiciel qui la pratiquent – et leurs clients – sont complètement en accord avec le processus. Récemment notre gourou résidant Agile l’a indiqué en commentant qu’avec Agile, clients ou propriétaires de produit (« product owners ») ne peuvent pas décharger leurs pensées sur l’engineering. Autrement dit, ils ne peuvent pas donner à l’ingénierie d’un seul coup tous leurs besoins au démarrage, parce que Agile demande une constante collaboration dans laquelle les besoins sont alignés à la fois sur l’équipe et sur le business.

Cela m’a sonné à réfléchir : Intérieurement, dans une organisation de développement de produits qui utilise Agile, coûte que coûte les propriétaires de produit doivent s’aligner. Ils apprendront le concept d’arriéré de produit et de besoins qui s’empilent; ils accepteront les tâches que les experts Agile attendent d’eux. Cependant, dans une organisation pilotée par les projet où les clients sont les gardiens du besoin, est-ce que ces clients sont prêts pour Agile ?

Je me rappelle de plusieurs occasions pendant mes missions de conseil où trois à quatre mois ont été dédiés « à la découverte » des processus clients, l’esquisse des besoins, l’obtention de la signature d’un document de contenu de projet. Le tout avant que nous ne puissions commencer le projet. Les calculs d’allocation de ressources et d’échéanciers, étaient basés sur ces « besoins ». C’est que la communauté informatique communauté a appris à ses clients sur quoi attendre d’un projet.

Aujourd’hui, comme la communauté IT adopte et s’adapte aux pratiques Agile, en faisons-nous assez pour instruire et informer notre écosystème – nos clients ?

Ce qui suit sont mes opinions sur certains des processus ou des engagements auxquels ces clients ont besoin de s’adapter dans le monde Agile.

Vider son esprit par rapport à construire les besoins de manière itérative

réfléchissonsDans la méthodologie « waterfall » les besoins sont le début des projets, avec des clients les exposant et des consultants les documentant. Les besoins n’étaient jamais revisités de nouveau avec le client, puisque le client les avait déjà formellement signés. Les projets commençaient seulement après que la collecte de besoins soit finie.

Dans Agile, cependant, les besoins, depuis le début même, peuvent être définis comme des « épopées » et doivent régulièrement être décomposées en histoires. À chaque planification de sprint, toutes les parties prenantes (incluant le client) conviennent d’histoires (autrement dit de fonctionnalités et de besoins) qui doivent être développées et testées dans le prochain sprint. Cela devrait être utilisé comme un facteur « WOW » par l’équipe projet, pour aider des clients à comprendre qu’ils peuvent être complètement en accord avec ce qui est développé et ils peuvent aussi prioriser les fonctionnalités selon leurs besoins business.

Cependant, là se trouvent les défis :

  • Participation : les Clients doivent s’engager sur la démonstration et la planification de sprint. Si éviter celles-ci est la norme et les propriétaires de produit deviennent régulièrement des mandataires pour le client, les bénéfices d’Agile ne peuvent jamais être expérimentés ni implémentés.
  • Alignement des équipes : le fonctionnel, le développement et des équipes QA doivent sortir de leurs mentalités « waterfall » et travailler vraiment en tandem dans chaque sprint, recherchant des démonstrations de sprint réussies sans balayer les problèmes sous le tapis.

Les estimations du management par rapport aux évaluations de point d’histoire d’équipe Scrum

En « waterfall », des échéanciers de projet partent du « go ». On s’attend à quelques semaines de collecte des besoins pour permettre au projet et aux managers de dessiner un parfait plan de projet, avec allocation des ressources, test d’acceptation utilisateur et date de livraison bien définie. Un chef de projet méritant son salaire intégrera toujours une marge de 20 à 30 pour cent.

Agile tourne ce processus sur sa tête. Il implique que l’équipe de Scrum (pas le management) devrait calculer les point d’histoire (« Story Points ») et s’engager à atteindre ces points d’histoire en fonction de la vélocité de l’équipe.

Ici, les défis sont :

  • Planification de projet : je crois qu’un échéancier est le plus grand défi du projet. L’idée de toujours avoir une date finale de projet (qui, selon diverses études, n’est pas respectée dans 80% des cas en « Waterfall ») sont si innés dans les organisations IT et chez leurs clients qu’atteindre la date finale possible de projet basée sur des points d’histoire va demander beaucoup de désapprentissage avant que cela ne puisse arriver.
  • Évaluations récurrentes : les propriétaires de produit, ainsi que les clients, doivent participer à la planification de Sprint en aidant ‘équipe, à nettoyer et calculer les points d’histoire de l’arriéré de produit. Ils peuvent alors voir ce qui peut être accompli dans le sprint à venir et ce quels sont les reliquats du sprint précédent.
  • Vélocité d’équipe : la méthodologie Agile implique que l’équipe soit assez mâture pour connaître sa vélocité, a suffisamment d’expérience pour estimer les besoins et a assez d’autorité pour s’engager sur les échéances.

Fin de développement par rapport à démonstration de sprint

démonstrationLes démonstrations de sprint exigent que l’équipe Scrum ait un morceau de code qui marche, digne d’être montré, mais elles exigent aussi l’engagement de la partie prenante clé : le client.

Les défis de cette approche :

  • Revue constante : si l’ingénierie et l’assurance qualité (QA) doivent s’adapter à des cycles de trois à quatre semaines pour créer un morceau de code fonctionnel et digne d’être montré, le client et le propriétaire de produit doivent aussi s’adapter au processus de constante revue. Le succès ou l’échec d’une histoire ramènent finalement à combien l’équipe Scrum a bien compris l’histoire, appelant ainsi à une revue de l’histoire elle-même. Fini sont les jours « Mais je pensais que vous aviez compris ce que je vous avais alors dit ». Si la planification de sprint et même les réunions « stad up » quotidiennes ont abouti à un écart de communication, l’équipe entière doit revisiter beaucoup de terrain, les besoins n’en étant qu’une partie.

Les projets au temps passé et dépenses contre coût fixe

La méthode « waterfall » permet aux organisations de négocier des contrats comme des offres à coût fixe ou bien en fonction du temps passé et des dépenses en matériel. Le type d’offre est dirigé par les offres des concurrents, la longueur possible du projet et le budget et la force de négociation du client.

Cependant, dans le monde Agile, cela n’aurait pas de sens d’avoir des contrats de type temps + coûts en matériels.

article précédent sur assistons-nous à la fin des contrats « classiques »?

Voici Pourquoi:

  • Des pratiques de sprint itératives donnent à toutes les parties prenantes la capacité d’arrêter le projet après n’importe quel sprint. (Assomption : à la fin de n’importe quel sprint, l’équipe a un code qui marche.)
  • La planification de sprint permet à toutes les parties prenantes d’avoir accès et d’analyser ce qui peut être réalisé dans des sprints futurs en fonction de la vitesse de l’équipe.
  • Le soin porté à l’arriéré de produit permet aux besoins d’être alignés sur les besoins business avant chaque sprint, ce qui permet aux clients de prioriser selon ses objectifs business. Par exemple, donner à l’intégration du site Web à PayPal pour les achats en lige la priorité sur un tableau de bord pour les partenaires, atteignant ainsi une présence en ligne avant que la campagne publicitaire « achetez en ligne » ne devienne virale.

Voici quelques-uns des aspects d’Agile auxquels je crois que les organisations doivent s’adapter. Mais un point important est que les clients doivent aussi changer la façon dont ils engagent dans un Monde Agile.

Voici une petite vidéo de Vincent McGevna sur comment « Agiliser » l’approche « Waterfall ».

2 réflexions sur “vos clients sont-ils prêts pour Agile ?

  1. Dix conseils au sujet des contrats adaptés à des projets agiles …..:

    Le français dans le texte: « Cependant, dans le monde Agile, cela n’aurait pas de sens d’avoir des contrats de type temps + coûts en matériels. »
    L’anglais de Schweta Darbha dans l’article en lien était: « However, in the Agile world, wouldn’t it make sense for everyone to have T&M contracts? Here’s why: »
    Il est facile à comprendre le contraire de l’intention en évoquant des méthodes agiles 😉
    Le français de Schweta serait plutôt: « Cependant, dans le monde Agile, ne serait-il pas logique pour tout le monde d’avoir des contrats T & M? Voici pourquoi…. »

    Voici 10 options contractuelles pour des projets agiles:
    et rédigé en Français par un conseil juridique / avocat d’affaires Français)
    1) « Timebox » et « Cashbox » définis (conception à coûts et à délais objectifs à base d’une co-conception et d’une ‘priorisation’ du périmètre / scope), comme souvent dans le domaine de fabrication automobile.)
    2) Établir un budget global; ensuite accorder un prix fixe pour chaque itération et contrôler les dépenses réelles et la vélocité réelle afin d’anticiper des dépassements. Le client aura des livrables utilisables et peut s’arrêter à la fin de chaque itération.
    3) Faire les premières itérations en T&M (régie) et les autres – une fois que les besoins sont mieux clarifiés – en prix forfaitaires
    4) S’entendre sur un prix ‘probable’ avec une rémunération incitative (des économies sont réparties en fonction d’un pourcentage accordé et des dépassements sont rémunérés à prix réduit)
    5) Rémunération dégressive si retard sur les besoins prioritaires (sur le 33 à 66% de besoins ‘impératifs’)
    6) Paiement en fonction de la productivité en points de fonctions
    7) Contrat cadre ‘roulant’ (renouvelable par ‘itération’, par ‘version’ et par ‘projet’)
    8) Définition d’une référence / baseline basée sur des « Business Goals » définis dans une optique de la prise en compte de leur évolution dans l’avancement du projet
    9) Participation aux résultats et esprit de confiance (les interlocuteurs se connaissent)
    10) Contrat type (et rédigé en Français par un conseil juridique / avocat d’affaires Français)

    J’aime

  2. Ping : les articles les plus lus sur leblogdumanagementdeprojet / DantotsuPM en Novembre 2012 « DantotsuPM.com

n'hésitez pas à commenter les billets et à partager vos idées.

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.