2 fausses bonnes idées pour sauver l’Agilité

Le titre provocateur « L’Agilité est morte » a envahi la blogosphère ces derniers temps avec des articles qui proposent toujours les mêmes solutions pour la sauver. L’ironie est que ces solutions pour sauver l’Agilité sont souvent les causes de son échec. Voici les 2 fausses bonnes idées les plus courantes.

Étendre l’Agilité à toute l’organisation

Il est couramment admis qu’une équipe agile, isolée et seule, ne peut pas fonctionner correctement si l’ensemble de l’organisation n’est pas elle-même agile et si l’ensemble du management n’est pas impliqué dans la transformation agile globale. Mais c’est une fausse bonne idée pour les raisons suivantes…

Toute transformation globale de l’organisation est une aventure à la fois coûteuse et extrêmement risquée. L’échec de la transformation globale est quasi certain. Cela aboutira au rejet de l’Agile. 

De plus, une transformation globale peut-elle être initiée avec une approche inventée dans le domaine informatique ? Même si le Digital a gagné en importance, une transformation d’une telle envergure ne peut être initiée qu’au niveau des Métiers. 

Enfin, il est utile de rappeler que l’Agilité, née dans les années 90, n’avait alors pas besoin d’une entreprise entièrement agile pour démontrer ses bénéfices. Les pionniers de l’Agilité ont prouvé que d’excellents résultats peuvent être obtenus sans un changement organisationnel global.

Plutôt que de prôner une transformation agile de l’ensemble de l’organisation, n’est-il pas plus judicieux de démontrer concrètement les bénéfices à petite échelle ?

Appliquer l’Agilité au-delà de l’Informatique

L’idée d’appliquer l’Agilité à d’autres domaines que l’informatique est séduisante. Si cela fonctionne pour l’IT, pourquoi pas ailleurs ?

En fait, rien ne garantit que cela marchera. Et en cas d’échec, c’est l’ensemble de l’approche agile qui pourrait être remise en question.

La première difficulté réside dans les spécificités de chaque domaine. Même dans  l’Informatique, l’Agilité n’est pas adaptée à tout. En effet, conçue pour le développement logiciel, l’Agilité n’est pas adaptée aux projets d’infrastructure.

La seconde difficulté est la résistance naturelle au changement. Les autres services de l’entreprise pourraient être satisfaits de leurs processus actuels et percevoir cette transformation initiée par l’informatique comme une intrusion indésirable.

Il faut faire une distinction entre l’Agilité dans le développement logiciel et les autres formes d’Agilité dans d’autres domaines. L’Agilité dans le développement logiciel a de solides fondements et des réussites reconnues tandis que les autres formes ont besoin de faire leur preuve.

Faut-il sauver l’Agilité ?

L’Agilité n’étant pas une fin en soi, une question s’impose: faut-il sauver l’Agilité ?

En fait, l’Agilité n’a pas besoin d’être sauvée. Si cela fonctionne, tout va bien et la question de sa survie ne se pose pas. Si il n’y a pas de bénéfices évidents, il faut chercher une approche plus adaptée.

D’ailleurs, l’Agilité comme un tout unique n’existe pas. Il y a juste des interprétations de principes très généraux et des tentatives de mise en oeuvre de ces principes.

Pour toute organisation qui se lancerait dans une mise en oeuvre de l’Agilité, notre conseil serait de toujours commencer à petite échelle.

En conclusion, on peut dire que l’Agilité « solution miracle » est morte. Les tentatives pour la sauver en la faisant passer « à l’échelle » risquent d’aboutir à une déception encore plus grande. Mais ce serait dommage de ne plus en faire du tout…

 

Le mythe des Valeurs Agiles

Souvent il est fait référence aux 4 valeurs agiles du Manifeste Agile. Mais cette expression « valeurs agiles » est bien mal venue. Elle freine la compréhension et l’adoption de l’approche agile en lui conférant un statut de dogme. Or l’Agilité est tout sauf un dogme.

« Valeurs Agiles » est un terme dangereux

Dire que l’Agilité repose sur des valeurs génère automatiquement des résistances lors de sa mise en oeuvre.

L’entreprise a ses valeurs. Les individus ont leurs valeurs. En positionnant l’Agilité sur le plan des valeurs, on déclare la guerre aux valeurs existantes, donc aux individus et à la culture des entreprises.

Or l’objectif de l’Agilité n’est pas de révolutionner la culture des entreprises, ni de changer les gens.

Le Manifeste Agile commence par « Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. ». Il est facile de mettre tout le monde d’accord sur cet objectif quelles que soient leurs valeurs…

Un problème de traduction

Dans la traduction officielle du manifeste, on utilise le verbe valoriser et non le mot valeur.

Ces expériences nous ont amenés à valoriser :

  • Les individus et leurs interactions plus que les processus et les outils
  • Des logiciels opérationnels plus qu’une documentation exhaustive
  • La collaboration avec les clients plus que la négociation contractuelle
  • L’adaptation au changement plus que le suivi d’un plan

source: http://agilemanifesto.org/iso/fr/manifesto.html

On pourrait dire aussi donner plus d’importance à ceci plutôt que cela. Ce n’est pas une question de valeurs. C’est un choix de priorités.

Préceptes Agiles

Plutôt que de parler de « valeurs agiles », il vaudrait mieux dire les 4 préceptes agiles, c.-à-d. des « recommandations pratiques enseignées par l’expérience » (cf. Larousse).

Pour tous les « anciens développeurs » qui ont connu les méthodes et les processus lourds des années 90, les plannings de Gantt qui ne servent à rien, les spécifications incohérentes ou incomplètes, les projets au forfait qui tournent mal etc., les 4 pseudo-valeurs sont des recommandations pratiques issues des enseignements des erreurs du passé.

Et même si ce ne sont que de simples préceptes, ils s’opposent à la croyance dominante dans le monde de l’Entreprise. Cette croyance héritée du Taylorisme est que les méthodes et les processus seraient la clé de l’efficacité et de la réussite.

En s’opposant à cette croyance si largement admise, les préceptes agiles représentent un changement de paradigme. Ils sont donc déjà une mini-révolution.

En parlant de préceptes agiles plutôt que de valeurs, on redonne à l’Agilité sa nature d’approche pragmatique de recherche d’efficacité qui ne menace pas les valeurs de l’entreprise.

 

Agilité: de l’auto-organisation vers l’auto-gestion

coaching PMA et gestion de projet 2.0La méthode Scrum et l’Agilité sont en train de bouleverser la culture des entreprises avec le principe de self-organizing team: une équipe auto-organisée qui n’a plus de manager et qui gère seule ses tâches. La justification d’une équipe auto-organisée est simple: responsabiliser et donner plus d’autonomie aux équipes.

Pour être tout à fait autonome, pourquoi une équipe projet ne gérerait-elle pas aussi son budget ? Une sorte d’auto-gestion…

Coûts, budget, ROI et rentabilité sont des termes absents des méthodes Agiles. De tous les leviers qui influencent les décisions dans une entreprise, l’aspect financier est sans doute le plus puissant. Il a le pouvoir de vie et de mort sur les projets. L’ignorer, c’est prendre un risque.

La proposition est d’intégrer la gestion des coûts et du budget dans le fonctionnement des équipes agiles. 

Concrètement, en quoi consisterait l’autogestion ?

Pour les équipes auto-organisées, cela consiste simplement à ajouter 2 ou 3 indicateurs financiers à leur « radiateur d’information » et à utiliser ces informations dans leur communication externe et pour la prise de certaines décisions.

Par exemple, avec l’autogestion, le backlog produit Scrum montre une liste de fonctionnalités avec un budget associé – Fonctionnalité X 11500€, Fonctionnalité Y 23200€… – comme pour les options d’une voiture neuve. C’est beaucoup plus concret pour le Product Owner et les utilisateurs que les estimations en Story Points qui sont artificiels et relatifs à cette équipe.

Autre illustration: en mode autogestion, l’équipe sait justifier financièrement auprès du management certains choix :

  • investissement pour gagner en productivité (équipement, logiciel…),
  • choix de faire un développement interne ou l’achat d’un composant sur étagère,
  • appel à un prestataire, à la sous-traitance pour des compétences spécifiques
  • recrutement

Avec un logiciel comme TimePerformance, la gestion financière d’un projet se fait toute seule.

Les bénéfices business

  1. Faire coïncider les enjeux réels de l’entreprise avec ceux des équipes projet, aligner les objectifs du management et des équipes
  2. Sensibiliser les équipes à l’importance de la maîtrise budgétaire et de la rentabilité (notamment pour sociétés de service)
  3. Accélérer les prises de décisions d’investissement pour gagner en productivité
  4. Intégrer les impacts financiers dans les choix techniques

Les obstacles: le management et le tabou de l’argent

Cela ne sera pas facile de faire admettre aux managers qu’ils doivent déléguer une partie de leurs prérogatives, la gestion des coûts et des budgets. Comme nous l’avons dit, l’aspect financier en entreprise est le vrai pouvoir.

Mais un manager intelligent verra dans cette délégation une opportunité pour se défaire de tâches administratives de gestion financière pour se tourner vers des missions à plus forte valeur ajoutée: le pilotage, la recherche d’opportunités, le développement de la vision, l’amélioration de la relation client, la conduite du changement, l’amélioration des processus…

Comment surmonter les obstacles

C’est très simple: faîtes-le. C’est à dire gérez les coûts et le budget même si on ne vous le demande pas. Cela ne demande aucun effort avec un logiciel comme TimePerformance. Et il n’est pas besoin d’avoir des chiffres exacts, car ce qui compte est l’ordre de grandeur.

Puis glissez subrepticement au hasard des conversations ou des réunions quelques indicateurs montrant que vous maîtrisez les aspects financiers du projet. Et peut-être que petit à petit on vous fera confiance et on vous confiera plus de responsabilité.

Sachez enfin que cette délégation de la gestion du budget et des coûts n’a rien d’exceptionnel. En fait, elle est pratiquée partout ailleurs que dans l’Informatique. Un chef de produit Marketing a un budget. Un chef de chantier dans le BTP gère un budget et des coûts. Dans le PMBoK, la gestion financière du projet est indissociable de la gestion de projet.

Il y a fort à parier que si les équipes agiles se mettent à parler budget et rentabilité de leurs projets dans les réunions, l’Agilité ne risquera plus de passer pour un « truc » de développeur auprès du management.

Bien utiliser le diagramme de Gantt

Chaplin Modern Times
A l’origine, le diagramme de Gantt est un outil d’organisation scientifique du travail inventé au début du 20ème siècle pour améliorer la productivité des chaînes de montage dans les usines.

Quelques décennies plus tard, le Gantt a été utilisé avec succès pour gérer de grands projets d’infrastructure avant de devenir une icône de la gestion de projet. C’est aujourd’hui un outil incontournable du chef de projet. Et pourtant, il convient de l’utiliser avec discernement…

Si tous les projets ont un besoin de planification et de respect des délais, ils ne s’apparentent pas tous à du travail à la chaîne, ni à des grands projets de construction.

Dans le développement informatique, combien de diagrammes de Gantt finissent sans suite ? Environ 99%…

Le piège est de faire un Gantt par habitude sans se poser la question de l’utilité de ce qui n’est au final qu’une technique parmi d’autres. A quoi sert  le Gantt ? Quels problèmes résout-il ? Y a-t-il des conditions à son utilisation ?

Diagramme de Gantt et Planification

Diagramme de Gantt

Le Gantt permet de visualiser simplement les délais, l’ensemble des tâches et leur séquencement.

Mais c’est une erreur de commencer la planification du projet dans un Gantt. 

En effet, dans le Gantt, il y a tout: la définition du périmètre du projet, la décomposition en tâches et leur ordonnancement, l’estimation des charges et le calcul des durées, les affectations, la disponibilité des ressources… C’est trop d’un coup. La planification d’un projet requiert un processus d’analyse qu’il est dangereux de court-circuité…

La construction du Gantt est la dernière étape du processus de planification. Il permet de calculer les délais et d’optimiser les ressources.

Le Gantt peut être utilisé à un niveau macroscopique pour visualiser le projet et les délais. Mais pour cela, il existe d’autres outils plus simples de visualisation comme la ligne de temps.

Dans la suite de l’article, on considère uniquement le cas de l’utilisation du Gantt pour une planification détaillée jusqu’aux tâches des équipes.

Un outil indispensable pour…

Le Gantt est nécessaire pour gérer le séquencement des tâches lorsque les interdépendances sont fortes. Sur un chantier de construction, ces interdépendances sont très nombreuses et incontournables. (Il faut couler les fondations avant de pouvoir monter les murs…) Un outil pour les gérer est indispensable.

Le Gantt est aussi nécessaire lorsque les intervenants sur le projet sont nombreux. Il permet de construire les calendriers d’intervention, de répartir les tâches et de coordonner les équipes.

Sur un chantier de construction, il y a plusieurs équipes (terrassiers, électriciens, plombiers..) qui n’interviennent qu’à des moments précis, se croisent et donc communiquent peu entre elles; d’où l’importance d’une planification précise.

Mais un outil complexe

Pour un projet de taille moyenne avec une équipe de 6 personnes sur 1 an, on atteint très vite le millier de tâches à ordonnancer et à gérer. Même avec un bon logiciel, c’est un travail fastidieux.

Planifier avec un Gantt nécessite un effort important de la part du chef de projet. Il peut même être nécessaire de déléguer la planification à un expert.

Mais les enjeux du chapitre précédent peuvent justifier ce travail important de planification.

Quand ne pas utiliser le Gantt…

Le Gantt est utile pour planifier dans le détail. Or construire un planning détaillé et calculer des délais n’ont de sens que si:

  • l’ensemble du contenu du projet est connu à l’avance
  • les estimations sont relativement fiables

Dans certains projets, le périmètre flou, les inconnues et les aléas rendent toute velléité de planifier dans le détail futile.

Notamment, dans le domaine du développement informatique, les projets avec ces caractéristiques sont le cas général. Ceci est à l’origine du mouvement Agile et de son énorme succès. Gérer un projet Agile avec un Gantt est donc une hérésie.

Dans certains domaines, les problèmes adressés par le Gantt, séquencement des tâches et gestion complexe d’équipes, sont mineurs.

Toujours dans le développement logiciel, il n’y a pas de problème de séquencement des tâches car il y a peu de contraintes fortes dans l’ordre pour faire les choses. Il n’y a pas non plus de gros problème de gestion des équipes (solution simple de gestion des ressources).

Dans ces contextes, l’utilisation du Gantt génère un travail important avec des replanifications perpétuelles et ne résout aucun des problèmes majeurs.  Ceci explique l’abandon rapide du Gantt observé si souvent.

Exemples concrets

Voici 2 projets « informatiques » avec des enjeux très différents, donc un besoin d’outil différent.

Type de Projet Déménagement de salle serveurs Développement d’un logiciel
Problématique Réduire la durée de coupure de service (optimisation des délais) Répondre aux besoins des utilisateurs, intégration aux SI, ergonomie, apporter de la valeur… Problématiques variées où les délais sont une variable parmi d’autres.
Contenu du projet Parfaitement connu (équipement actuel) Cahier des charges ou spécifications qui vont évoluer, solution à peine ébauchée…
Estimation de la charge de travail Facile, déjà fait Marge d’erreur importante du fait de la nouveauté et des inconnues, nécessite d’acquérir plus de connaissances sur le problème et d’expérience dans les technologies ou le fonctionnel
Ordonnancement des tâches Important, nombreuses règles à respecter dans le montage ou le démontage des équipements. Pas important. Grande flexibilité.
Coordination des équipes Au moins 2 équipes distinctes très spécialisées (déménageurs et administrateurs réseaux) qui doivent se coordonner avec des délais courts Une seule équipeImpossible de prédire en détail le travail à faire du fait des nombreuses inconnues du projet.
Conclusion Utilisation du Gantt recommandée Se focaliser sur le périmètre du projet, l’architecture, les technologies, l’ergonomie, les risques… plutôt que sur le séquencement des tâches dans un Gantt.

Conclusion

Le contexte idéal pour l’utilisation du Gantt se définit par:

  • Le contenu du projet est défini avec un grand niveau de détail
  • Les charges de travail peuvent être estimées avec une bonne précision
  • Les dépendances entre les tâches sont des contraintes fortes
  • La coordination et la gestion des équipes sont complexes

Le diagramme de Gantt est un puissant outil d’optimisation du travail plutôt réservé à des experts de la planification.

Mais diagramme de Gantt et gestion de projet ne sont pas synonymes. S’il n’y a pas les conditions pour utiliser le Gantt, ni de valeur à le faire, il vaut mieux s’en passer.

Équipe pluridisciplinaire SCRUM: avantages et inconvénients

La méthode Scrum a introduit le concept d’équipe pluridisciplinaire (cross-functional team).

Une équipe pluridisciplinaire Scrum est une équipe pluridisciplinaire dont les membres sont eux-mêmes pluridisciplinaires.

L’avantage évident est de faciliter la collaboration inter-discipline. Mais cela ne serait pas suffisant pour justifier la contrainte supplémentaire de devoir trouver les « bons profils ».

Quel est l’avantage d’une telle équipe par rapport à une équipe pluridisciplinaire classique où chaque membre à un rôle précis ?

L’avantage souvent méconnu est de pouvoir affecter les personnes à 100% sur un projet.

Continuer la lecture de « Équipe pluridisciplinaire SCRUM: avantages et inconvénients »

Modèle de plan pour Prince2

Chez Time Performance, nous sommes fans de la méthode de gestion de projet Prince2 pour les raisons suivantes.

Prince2 fournit une vraie méthode de gestion de projet avec un cycle de vie de projet standard, une organisation et des rôles précis. Cette méthode guide les chefs de projet, tandis que les référentiels de bonnes pratiques généralistes comme le PMBoK propose une liste d’outils et de techniques. Prince2 permet de mettre immédiatement la gestion de projet sur des rails, ce qui est un point commun avec notre logiciel de gestion de projets TimePerformance.

Prince2 a été conçu pour l’approche itérative et incrémentale, qui est la bonne approche pour le développement logiciel, notre métier.

Prince2 repose sur le principe du management par exception. Ce principe donne beaucoup plus d’autonomie aux équipes tout en gardant le contrôle du projet. Ce principe est dans l’ADN de notre solution TimePerformance.

Prince2 propose une planification orientée produit (product-based). Pour comparaison, l’approche classique repose sur une planification orientée tâche (cf. Gantt, PERT). La planification orientée produit est beaucoup plus simple et focalisée sur l’essentiel: les livrables. TimePerformance utilise ce type de planification avec un gain de temps important pour les chefs de projet.

Prince2 est le complément idéal des méthodes agiles Scrum et XP. Les méthodes agiles, centrées sur l’équipe de développement, ne couvrent pas certains domaines essentiels de la gestion de projet.

Modèle de Projet Prince2

Voici un modèle de projet Prince2 construit avec le logiciel TimePerformance.

Version complète en PDF du modèle Projet Prince2

Voici le Gantt avec le phasage d’un projet selon Prince2. Les étapes d’avant-projet et de clôture avec leurs livrables de gestion de projet sont standardisées par la méthode. Les étapes de construction sont à définir avec le contenu spécifique du projet.

PRINCE2® is a Registered Trade Mark of AXELOS Limited

La méthode agile SCRUM et le logiciel TimePerformance

Le logiciel de gestion de projet TimePerformance a été conçu pour apporter aux équipes SCRUM  une solution simple de gestion de projet qui respecte les principes de l’Agilité et apporte le top de la gestion traditionnelle pour le management.

Petit rappel sur la méthode SCRUM

analogie de la mêlée de rugby avec la méthode agile Scrum

SCRUM est une Méthode Agile créée en 1996 par Ken Schwaber et Jeff Sutherland, conçue initialement pour le développement logiciel.

La principale motivation de son élaboration est de pouvoir gérer des projets complexes avec de nombreuses inconnues, pour lesquels les méthodes classiques (cycle en V, cascade etc.) sont par nature inadaptées.

Pour gérer ce type de projet, il faut pouvoir s’adapter facilement et rapidement aux changements fréquents. C’est le concept d’Agilité.

L’image de la mêlée de Rugby (SCRUM en anglais) illustre parfaitement le style de cette méthode: progression continue, effort soutenu, importance de la cohésion de l’équipe, faire face ensemble pour surmonter les difficultés…

Management Visuel vs Utilisation d’un Logiciel

Le management visuel avec des post-it sur le mur a des avantages indéniables, notamment de convivialité. Mais il a aussi de nombreux inconvénients.

Garder la cohérence entre les post-it, les backlogs dans Excel et les courbes d’indicateurs est fastidieux.

De plus, un tableau vissé au mur n’est pas très pratique pour les communications vers l’extérieur ou les équipes réparties sur plusieurs sites.

L’utilisation d’un logiciel unique permet aussi l’automatisation de certaines tâches administratives.

La question n’est pas de remplacer le management visuel par un logiciel. Il s’agit de remplacer un ensemble hétéroclite de petits outils ou feuilles de calcul annexes, par un logiciel unique et simple.

Rationalisation de l’outillage, génération en temps réel des indicateurs et des courbes, partage de l’information font partie des bénéfices de l’utilisation de TimePerformance.

SCRUM et le monde de l’Entreprise

Convertir toute l’entreprise à la terminologie Scrum est difficile. Il y a très peu de chance que les story points, le burndown, les backlogs, la vélocité etc. soient un langage compréhensible par tous.

Par ailleurs, le contexte d’une entreprise ajoute des contraintes au niveau de la gestion des projets: suivi budgétaire, contrôle des coûts, suivi des temps… Le reporting de projet requiert de parler en jours-hommes et en euros, notamment pour le service Compta.

La spécificité de TimePerformance est de faire le pont entre agilité et management traditionnel.

Cette capacité est illustrée par les nombreuses vues tantôt agiles tantôt classiques proposées par le logiciel.

Cockpit de projet

Vu de l’équipe, le projet suit la méthode Scrum avec ses outils spécifiques: tableau des tâches, release backlog… Vu de l’extérieur, le projet Scrum est géré « comme les autres » avec un suivi budgétaire, un planning…

En fait, pour le management, le projet Scrum géré avec TimePerformance sera bien mieux géré que les autres projets. En effet, TimePerformance met en oeuvre la technique de la valeur acquise. Cette technique est recommandée par les référentiels professionnels de gestion de projet pour la gestion financière et le calcul de l’avancement.

C’est donc le top de la gestion de projet traditionnelle qui est mis à disposition des équipes agiles. De quoi crédibiliser Scrum auprès du management !

Autres bénéfices

Voici quelques autres apports possibles de TimePerformance pour les équipes.

  1. Intégration avec la gestion des ressources
  2. Historique du projet et possibilité d’analyser ce qui s’est réellement passé.
  3. Mesurer les évolutions de périmètre du projet.
  4. Améliorer les estimations grâce à la mesure des écarts planifié vs réalisé au niveau de chaque user story.
  5. Renforcer la Definition Of Done grâce à la fonctionnalité « Méthode ».

Pour la mise en oeuvre pratique de SCRUM avec TimePerformance, lire l’article Guide pour utiliser TimePerformance avec la méthode agile SCRUM.

Anti-pattern agile: le manque de transparence

locked folderLa plupart des retours d’expérience à propos de la mise en place de l’Agilité dans les organisations font apparaître un obstacle majeur: la transparence ne fait pas partie de la culture des organisations.

Pire, la transparence est le plus souvent découragée. On préfère faire bonne figure en toute occasion, quitte à minimiser les problèmes, afin de ne pas être injustement classé parmi les messagers porteurs de mauvaises nouvelles. Cela engendre le syndrome du projet pastèque, rouge à l’intérieur et vert à l’extérieur.

Or c’est justement sur la transparence, ou plus exactement sur le marché implicite «confiance contre transparence», que repose la démarche Agile. Grâce à elle, la collaboration entre le Métier et l’équipe de développement est beaucoup plus efficace, car elle est directe, peu formalisée dans des documents ou ralentie par des processus (de validation ou autres).

Pour passer à l’Agilité, il y a un changement de culture à opérer au niveau de l’organisation tout entière.

Les équipes de développement, et les chefs de projet en particulier, doivent désapprendre la crainte de se faire taper sur les doigts à chaque annonce de contre-performance ou de difficulté. Ils doivent trouver un courage nouveau pour communiquer les éventuelles mauvaises nouvelles le plus tôt possible. Cela permet à tous de prendre les bonnes décisions au meilleur moment. Le Management doit encourager cette transparence et associer la contre-performance à de l’apprentissage. 

Quant au Métier, il doit s’associer à l’équipe de développement et quitter le mode de collaboration client-fournisseur. S’associer implique de ne former qu’une seule équipe et de participer à la résolution de tous les problèmes, y compris techniques. Cela passe par une acquisition d’un minimum de connaissances techniques sur le projet et par la recherche active du meilleur compromis entre valeur métier et faisabilité. Un gain supplémentaire non négligeable pour le Métier sera d’en retirer au final une bien meilleure compréhension de son produit ou de son outil.

Les équipes sont-elles prêtes à faire part de mauvaises performances éventuelles ? Le Management pénalise-t-il les mauvaises performances sans distinction ? Le Métier a-t-il envie de s’impliquer dans la technique ? Les réponses à ces questions sont essentielles pour démontrer un environnement propice au développement de la valeur Transparence, indispensable à la démarche Agile.

Quel rôle pour les chefs de projet dans Scrum ?

La méthode Scrum définit 3 rôles. Celui de chef de projet n’en fait pas partie. Beaucoup en déduisent qu’il n’y a plus de chef de projet avec Scrum. Certains s’en inquiètent en se demandant ce que vont devenir les chefs de projet lors du passage à Scrum.

Dans Scrum, le «chef de projet» est le Product Owner

Le chef de projet est la personne à qui on donne une mission, un mandat, pour mener à bien un projet. On lui délègue des pouvoirs, des moyens et la responsabilité du succès du projet.

Mener à bien un projet signifie de livrer de la valeur tout en respectant un budget et des délais.

C’est aussi la mission du product owner.

Le product owner est le responsable du backlog produit. Il priorise les éléments et leur associe une valeur business. Il gère aussi le release backlog qui détermine les délais et le budget du projet. Il a aussi le pouvoir d’arrêter le projet lorsqu’il juge que le ROI est insuffisant. 

Ce qui change avec Scrum

Certaines fonctions dévolues traditionnellement au chef de projet sont déléguées à d’autres personnes.

Il n’y a plus de management d’équipe

Dans Scrum, l’équipe s’auto-organise et s’autogère à l’aide d’un facilitateur, le Scrum Master. Il n’y a donc plus de management hiérarchique.

La gestion de la qualité

Le Scrum Master est responsable du respect du processus de développement et des normes de qualités.

C’est l’équipe toute entière qui est responsable de la qualité du produit.

Le découpage technique du projet et les estimations

L’expertise technique est du ressort de l’équipe. C’est elle qui identifie les tâches et estime la charge de travail.

Les bénéfices de l’approche Scrum

Le fait de déléguer une partie de ses fonctions à d’autres personnes peut être vu comme une très bonne chose.

Le chef de projet est traditionnellement surchargé du fait de ses multiples tâches: gestion de l’équipe, contact client, planification, gestion des coûts, gestion des anomalies…

De plus, certaines responsabilités peuvent amener à des conflits d’intérêt. Par exemple, la recherche de réduction des délais et des coûts peut inciter à sacrifier la qualité du produit.

Enfin, le rôle traditionnel de chef de projet peut exiger des compétences très différentes (communication, expertise technique, négociateur, écoute client, gestionnaire, leadership). C’est pourquoi on trouve souvent des descriptions de poste de chef de projet qui ressemblent à celle d’un mouton à 5 pattes.

Conclusion

La mission essentielle du chef de projet vis-à-vis de l’entreprise est confiée au Product Owner. Il n’est pas le chef d’une équipe mais le titulaire d’un projet ou d’un produit qu’il incarne.

Les chefs de projet qui deviennent product owners verront  leur (sur)charge de travail diminuée et pourront se concentrer sur la création de valeur métier.

Par contre, le management d’équipe disparaît. Le concept de « chef de projet technique » ou de team leader n’a pas d’équivalent dans Scrum. C’est un réel problème pour les personnes avec ce type de profil. Une reconversion en Scrum Master n’est pas forcément possible dans la mesure où cela requiert un type de personnalité très différente de servant leadership et non de chef. Les autres choix sont d’aller vers l’expertise technique, en espérant que celle-ci soit reconnue à sa juste valeur, ou vers le fonctionnel pour devenir product owner.

Valeur Business ou Valeur Acquise ?

La volonté de maximiser la valeur business est une bonne pratique de gestion de projet, tout comme la technique de la valeur acquise. Ces deux concepts de valeur reposent sur des principes de valorisation de projet différents: l’un à partir des bénéfices, l’autre à partir des coûts. Faut-il pour cela les opposer ?

Récemment, nous avons présenté la technique de la valeur acquise à des managers d’une SSII. Après nous avoir écouté poliment pendant quelques minutes, un des interlocuteurs nous rétorque:

« Vous savez, nous, nous sommes agiles, la seule valeur qui nous intéresse c’est la valeur business !»

Voilà le nouveau mot à la mode: la Valeur Business.

Que les approches Agiles mettent en avant la maximisation de la Valeur Business, c’est très bien. Mais cela doit-il empêcher d’être par ailleurs un bon gestionnaire ? Et pour cela, il n’y a qu’une technique, celle de la Valeur acquise, approche agile ou non.

Valeur Business

La valeur business est juste un autre terme pour désigner les bénéfices attendus du projet ou du produit. Ce concept n’a donc rien de nouveau. Ce qui change avec l’Agilité par rapport à l’approche traditionnelle, c’est la possibilité de faire des modifications afin de maximiser la valeur business en cours de projet.

La valeur business permet de justifier le projet et de prioriser les items.

Continuer la lecture de « Valeur Business ou Valeur Acquise ? »