Facebook EmaiInACirclel
Méthodologies de Management Informatique

La tyrannie du « OU » 4/4 : Quelques recettes de cuisine

PentaGuy
PentaGuy
Blogger

Quand je lis des articles, j’aime avoir du concret sur ce qu’il faut faire pour que cela fonctionne. C’est très difficile de trouver cela au sujet des projets et je pense qu’il n’est pas possible à 100% de rendre un projet « prédictible » (cf. la discussion entre projet et opération). Ceci étant, avec l’expérience, qui s’acquiert non pas avec le temps mais avec la pratique et les erreurs, j’ai retenu (parfois de manière cuisante) des leçons :

Projet Agile – Astuces

Faites-vous accompagner par un CTO expérimenté pour optimiser l’organisation de votre projet de développement logiciel

Inclure un Product Owner dans l’équipe, tu n’oublieras pas

Le contraire reviendrait à penser que le produit est fabriqué par les développeurs : c’est suicidaire… Ecrire et prioriser des User Stories est une activité à plein temps (Backlog Grooming). Pour respecter le principe « Individuals & Interactions » du manifeste Agile, il faut que le PO soit physiquement sur le même desk.

Stabiliser l’équipe, tu devras

La notion d’équipe est cachée dans le « C » de l’équation CQFD : ce qui coûte le plus cher dans un projet ce sont les cerveaux (en particulier dans la création d’un logiciel). Autant investir véritablement et avoir des équipes stables (quel que soit la forme du contrat : motiver les équipes n’a rien à voir avec faire un CDI, de la prestation ou faire appel à un indep). Je parle non seulement du turn-over bien connu dans certaines sociétés mais cela va au-delà : pas question de faire tourner les gens dans différentes équipes au gré des projets ou des sujets. Les équipes sont construites pour durer 1 ou 2 ans minimum : ce sont les sujets qui « tournent » pas les gens ! C’est en stabilisant l’équipe qu’on peut lui demander de s’améliorer.

Du temps au temps avant de mesurer, tu laisseras

C’est un corollaire du point précédent : illusoire de penser qu’une équipe fraîchement constituée donne des résultats fiables à partir desquels établir des projections. Il faut compter à minima 3 à 4 sprints de 2 semaines avant de pouvoir tirer des conclusions de la vélocité de l’équipe. Cela ne signifie pas qu’il faut attendre 3 sprints pour définir les KPIs et obtenir que l’équipe fournisse les infos / remplisse les données nécessaires. Autonomie des équipes ne signifie pas indépendance.

Evidemment s’il y a du turn-over, cela va perturber les résultats mesurés et la vélocité de l’équipe… alors il faut soigner le management autour des équipes (quitte à les aider eux aussi à trouver leur place en les coachant).

L’Agilité à tous les niveaux, tu cultiveras

L’Agilité ce n’est pas que pour la R&D ou les développeurs. Je me rappelle de discussions avec mon parrain : il est maintenant à la retraite mais a longtemps été DAF dans un groupe industriel pour un équipementier automobile. Loin de la production réelle de l’entreprise, il s’attachait malgré tout à faire sentir le métier de son entreprise dans la manière dont les comptes / bilans étaient construits et surtout analysés. Il est donc possible de travailler et d’expliquer aux services dits support (ex : RH, Finance / Compta ou Juridique) la manière de fonctionner d’une équipe projet en mode Agile et d’adapter les pratiques juridiques ou comptables.

Une très bonne initiative (pas forcément beaucoup suivie malheureusement) est venue par exemple de Xebia / Cellenza avec une transposition des pratiques agiles en termes juridiques : http://www.contrat-agile.org/structure.html

Une autre approche d’une autre société bien connue dans le domaine de l’agilité consistait à proposer contractuellement de démarrer en mode régie « classique » et de petit à petit basculer en Agile : au début le contrat stipulait par exemple une équipe de 5 personnes pendant 20 j à 500 € / j et par personne (soit 50 000 €) et puis après quelques sprints, une fois la confiance étable, le contrat était toujours établi pour 50 000 € par mois mais pour un nombre de points (par exemple : 2 sprints avec 75 Story Points par sprint).

Cette approche permet :

  • de ne pas vendre des gens ni même une équipe mais un résultat garanti sous forme de Story Points : cela simplifie le casse-tête habituel du remplacement d’un profil
  • d’introduire une notion de « bonus » / « malus » basée sur les points réalisés par Sprint : cela exprime une notion de résultat forfaitaire sans dépendre de la spécification d’un périmètre par nature protéiforme et instable (« Je ne saurai exactement ce qui doit être fait qu’une fois que je le verrai fait », parole de Sainte MOA).

 

A lire également :

La tyrannie du « OU » 1/4 : projets ou opérations ?

La tyrannie du « OU » 2/4 : C*(Q+F)*D = Le triangle de fer

La tyrannie du « OU » 3/4 : peut-on y échapper?

L’agilité en mode startup : interview d’un directeur de projets IT

De la donnée fiable pour apprécier la performance agile, des programmeurs au CEO !

Transformation Agile : les résultats de 2 ans de transition


Laisser un commentaire

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