PMP, SCRUM ou PRINCE2 ?

Que vaut-il mieux choisir : une formation PMP®, PRINCE2® ou Scrum® ? Dans une entreprise, on ne trouve pas que de la gestion de projet classique ou que du management agile. On a donc deux référentiels différents : un classique (PMP® ou PRINCE2®) et un agile (SCRUM® ou d’autres).

Découvrir nos formations en ligne

Connaître vos objectifs

Pour répondre à cette question, il faut répondre à la question « quels sont vos objectifs exactement ? ». Est-ce que vous voulez renforcer votre approche de gestion de projet globale et auquel cas vous avez intérêt à vous présenter à deux PRINCE2® ou du PMP®. Est-ce que votre objectif c’est de vous approprier une façon de livrer les applications et de livrer de nouveaux produits en mode itératif, et là, évidement ce sera plutôt du côté Product Owner ou bien Scrum Master. Si je reviens sur les deux premières options : PMP® et PRINCE2®.

Différencier les certifications

PMP® valide une expérience professionnelle, il faut au mois 4500 heures de gestion de projet et c’est la certification aujourd’hui la plus recherchée dans le monde en ce qui concerne le métier de chef de projet. PRINCE2® ce n’est pas la même approche : c’est beaucoup plus abordable, c’est plus opérationnel aussi puisqu’on a une vraie méthode qui décrit de A à Z comment gérer un projet sous toutes ses formes.

La certification n’a donc pas le même degré d’effort : quelques semaines pour PRINCE2®, plusieurs mois pour PMP®.  Du côté agile, PSM ou PSPO, soit Scrum Master soit Product Owner : c’est vraiment pour appréhender une façon de livrer de manière itérative un produit ou un service et on est sur les deux rôles qui font parti de la méthode Scrum®. Le Product Owner parle du produit et ramène une vision de celui-ci; dans quel contexte d’organisation et client ce produit va-t-il s’insérer. Le Scrum Master lui, veille à ce que la méthodologie Scrum® soit respectée et que les différents obstacles soient supprimés au fur et à mesure de l’avancement du projet.

Multiplier les certifications

Il n’y a pas soit PMP®, PRINCE2® ou SCRUM®, les trois vont ensemble. De la même manière, vous pouvez être certifié SCRUM® et PRINCE2®, cela dépend de vos attentes, de celles de votre employeurs ou de vos clients. A la question « Vaut-il mieux PMP®, PRINCE2® ou SCRUM® ? » la réponse c’est de savoir quel est votre objectif n°1.

Découvrir nos formations en ligne

Le rôle de chef de projet

Aujourd’hui, nous répondons à une question souvent posée par les chefs de projet qui sont en formation PMP® ou PRINCE2® c’est : « Vous êtes entrain de me dire qu’un chef de projet ne doit ni développer, ni faire de chiffrage, ni de travaux, mais c’est mon quotidien ! Expliquez-moi alors cette différence qui nous vient des référentiels comme PMP® ou PRINCE2® et que je ne retrouve absolument pas dans la réalité de mon quotidien.  »

Découvrir nos formations en ligne

Pourquoi le chef de projet ne doit pas cumuler les tâches malgré ses compétences ?

En fait, l’explication est toute simple. Vous jouez le rôle de chef de projet et de chef d’équipe. Le chef d’équipe c’est la personne qui va faire faire le travail à ses équipes spécialistes. Parfois, vous jouez même un triple rôle qui est celui « d’équipe de développement » comme on dirait dans SCRUM®, c’est-à-dire de réaliser des choses.
Si vous avez fait un peu de base de données dans votre vie, votre client ou votre sponsor peut être tenté de vous dire « Vous savez faire de la gestion de projet, et de la base de données, sortez moi ces requêtes de manière à ce que je puisse avoir ces chiffres. » Il s’agit d’une demande absolument classique. Néanmoins, lorsque l’on fait cela, on cumule deux ou même trois rôles, ce qui compromets le projet. Si vous passez du temps sur le développement, évidemment vous ne passez pas de temps sur le pilotage du projet.

Quels sont les exceptions, et quelles règles respecter ?

Quand il s’agit de petits projets, sur lesquels il y a assez peu de moyens / ressources, il est concevable qu’une personne puisse remplir plusieurs fonctions. Quand le projet a une certaine taille, il faut être conscient que c’est un vrai problème et que cela peut constituer un risque, qu’il faut faire remonter à son sponsor bien-entendu. Ainsi, le sponsor prendra la décision qu’il juge utile et pertinente pour la situation. Néanmoins, le rôle du chef de projet, c’est de faire remonter cette information de manière à ce que le sponsor puisse prendre une décision. Si une fois que vous avez fait remonter le fait que vous ne puissiez pas accumuler différentes tâches seul, et que le sponsor ne vous propose pas de solution, vous aurez au moins respectez votre mission. La décision doit être clairement consignée de manière à ce que il y ait une trace, et que si jamais vous êtes mis en cause, vous puissiez au moins montrer que vous aviez averti votre sponsor du problème.

Il est donc possible d’intervenir dans le développement du projet dans certains cas, mais il faut rester extrêmement vigilant. Ce cumul de fonctions dans l’organisation du projet ne doit pas desservir votre pilotage vis à vis de votre sponsor. 

Découvrir nos formations en ligne

Quel est le rôle principal dans une équipe de projet ?

Même si une équipe de projet se compose de membres importants, il reste quand même un rôle prédominant , c’est le rôle de Sponsor ou d’Executif (dans Prince 2).

Découvrir nos formations en ligne

Le rôle primordial du sponsor

Le décisionnaire final par rapport au périmètre, au timing, et aux coûts, c’est le sponsor qui l’endosse. En effet, c’est à lui qu’on donne les clefs du projet, pour qu’il finisse dans les temps, à un certain coût, et avec ce qui est attendu. C’est bien cette personne là qui est la décisionnaire principale et unique du projet. C’est pour cela que ce rôle particulièrement sensible est confié normalement à quelqu’un qui soutient le projet, et qui a un intérêt dans l’entreprise. Ce sponsor doit être motivé à la réalisation de ce projet, et compétent pour comprendre le projet afin de l’emmener dans la bonne direction pour qu’il livre les avantages à l’entreprise.

La responsabilité du chef de projet

Le chef de projet c’est quelqu’un qui va aller dans la direction qui lui a été indiquée par le sponsor, c’est quelqu’un de compétent. Cependant, la personne décisionnaire et ultimement responsable, ce n’est pas le chef de projet, c’est le sponsor. Bien entendu, si le projet va dans le mur, le chef de projet va se prendre des coups de pelle mais le responsable ultime, c’est le sponsor. Si le chef de projet a bien fait son boulot, c’est le sponsor qui aurait du probablement à un certain moment prendre des décisions pour rétablir la situation. Donc le rôle le plus important dans l’équipe de projet c’est l’exécutif, c’est le sponsor.

Découvrir nos formations en ligne

Le chef de projet doit-il faire les chiffrages ?

Le chef doit de projet doit-il faire les chiffrages en termes de temps, ou encore de budget ?

Découvrir nos formations en ligne

Le chef de projet ne doit pas faire le chiffrage

Normalement, le chef de projet n’a pas à faire ça. Le chef de projet doit s’appuyer sur le chiffrage des équipes pour au moins deux raisons.

La première, c’est que si le chef de projet fait une évaluation, ça devient l’évaluation du chef de projet. Si l’équipe chiffre une tâche à 4 jours, et que le chef de projet, parce qu’il a déjà vécu ça, le chiffre à 2, ça pose alors problème. C’est la première raison pour laquelle le chef de projet ne devrait pas faire de chiffrage.

La deuxième raison, c’est que ça devient une manière d’impliquer les équipes dans le projet. Si le chef de projet se substitue aux équipes du groupe, il y aura vraisemblablement démotivation, parce que la subsidiarité c’est quelque chose qui est mal vécue. « Je te demande de faire ça mais finalement je le fais à ta place », c’est une manière d’envoyer le message : « Je te demande de faire ça mais finalement tu sais pas bosser, donc je vais t’apprendre comment on fait ». C’est une des pires façon de faire bien entendu.

Aujourd’hui, on a bien compris que c’était le collaboratif et l’implication de chacun qui fonctionnait dans les équipes. Le chef de projet ne devrait pas faire les chiffrages. Quand on dit ça, on peut se faire la remarque « Oui mais moi je le fais tous les jours, et heureusement que je le fais sinon le projet n’avancerait pas ». Là, on doit se poser la question si le chef de projet n’est pas entrain de jouer un double rôle. C’est-à-dire de jouer le rôle de chef de projet et de chef d’équipe. Si vous jouez à la fois le rôle de chef de projet et de chef d’équipe, cela veut dire qu’on vous a missionné d’à la fois piloter le projet, et d’en réaliser une certaine partie. C’est pour cela qu’on peut se permettre de dire que le chef de projet ne doit pas faire les chiffrages, mais que c’est le chef d’équipe qu’il doit le faire.

Chef de projet ou chef d’équipe ?

En fait ces deux profils, sont considérablement différents. Le chef de projet est un chef d’orchestre et le chef d’équipe, c’est plutôt un musicien. Donc si le chef de projet sait jouer du piano, c’est très bien, mais ce n’est pas son objectif initial, ni sa mission. S’il est chargé de jouer ces deux rôles, c’est soit parce qu’il s’agit d’un petit projet, soit parce qu’il est consultant dans une entreprise et qu’il est chargé de tout faire faire.

En effet, quand vous êtes prestataire pour le compte d’un client, votre client a tendance à vouloir vous faire tout faire : la gestion de projet, la réalisation d’UX, ou encore du codage. Donc évidemment, en tant que prestataire dans une entreprise pour un client final, c’est sûr qu’il est possible qu’il vous missionne à réaliser des tâches supplémentaires. Le problème, c’est que l’on est à cheval entre deux rôles. Dans ce cas, il est compliqué de refuser le tâches supplémentaires. Néanmoins, il faut être conscient que vous êtes entrain de jouer deux rôles et qu’il faudrait peut-être un deuxième type de ressources pour faire le travail de réalisation réelle. Il faut aussi faire remonter les différents risques qui sont liés à ce mode de fonctionnement à votre sponsor sur l’un ou l’autre sujet qui le préoccupe.

Découvrir nos formations en ligne

Quelles décisions le chef de projet peut-il prendre ?

Dans cet article, nous répondons à une question qui très souvent posée : « Quelles décisions le chef de projet peut-il prendre ? ».

Découvrir nos formations en ligne

Le rôle du chef de projet dans l’organisation

Le chef de projet ne prend pas de décisions structurelles par rapport au projet. Ce n’est pas son rôle. Celui qui prend les décisions par rapport au projet (objectifs, moyens), c’est le sponsor, ou dans PRINCE2®, l’exécutif. La plupart du temps, le chef de projet est un opérationnel hautement qualifié. Être chef de projet, c’est un vrai métier. D’ailleurs, c’est ce qui pose le problème lorsqu’on est « catapulté » chef de projet. En effet, si c’est la première fois, cela peut poser problème au niveau des compétences ou des chances de réussite du projet.

Le chef d’orchestre de l’équipe

On peut comparer le chef de projet au métier de chef d’orchestre. En effet,  il n’est pas censé jouer du violon, du piano, ou encore de la contrebasse. Par contre, il connaît la musique. Son rôle, c’est de faire jouer les autres. Ce n’est de prendre des décisions structurelles par rapport au projet. Bien entendu, si Jean-Michel est absent et qu’il faut plutôt que ce soit Bernadette qui le remplace, ça c’est opérationnel et tant que ça ne sort pas du cadre défini par l’exécutif, il n’y aucun problème à ce que le chef de projet prenne ce genre de décisions là.

Les limites décisionnelles du chef de projet

Cependant, lorsqu’il y a un changement d’orientation, une décision importante à prendre vis à vis du projet, le chef de projet ne peut pas s’en charger, il faut confier cela à l’exécutif, au sponsor. A ce moment là, c’est lui/elle qui va prendre les décisions finales, les orientations. En faisant cela, le chef de projet  est parfaitement dans son rôle. En prenant une décision, il en sortirait. Le chef de projet fait jouer la musique qu’on lui a demandé de jouer, et c’est ça son rôle le plus important, encore une fois.

 

 

Découvrir nos formations en ligne

Qui fait l’interface entre l’équipe et le reste de l’organisation dans SCRUM® ?

Dans cet article, nous répondons à une question qui est assez souvent posée en cours SCRUM® : « Qui fait l’interface entre l’équipe et le reste de l’organisation ? » A cette question, il y a deux réponses, suivant l’angle du produit, ou de l’organisation.

Découvrir nos formations en ligne

Le Product Owner (PO), interface principale entre l’équipe et le reste de l’organisation

Concernant l’interface des utilisateurs et des parties prenantes, elle est clairement assurée par le Product Owner. En effet, il n’y a pas d’autres interfaces avec l’équipe de développement en termes de fonctionnalités, d’attentes, ou encore de priorisation. Lorsqu’une fonctionnalité doit être intégrée au travail de l’équipe, c’est une problématique du PO. En effet, il doit être au bon niveau de priorisation pour qu’elle soit embarquée au bon moment. De ce fait, l’interface des codeurs, utilisateurs et équipe de développement est évidement également assurée par le PO.

Ensuite, s’il y a besoin d’interactions entre l’équipe et les utilisateurs, rien ne l’empêche de les mettre en relation. Le PO peut très bien dire « Ecoutez, pour Monsieur/Madame l’utilisateur, pour clarifier quelque chose, je vous propose de vous mettre directement en relation avec l’équipe de développement. » Cela ne pose aucun problème, puisque le PO n’est pas toujours censé avoir une vue aussi précise de l’application. Imaginez, vous pouvez être PO, développer un CRM, vous avez globalement une idée de ce qui doit être réalisé, vous en avez même une assez bonne idée.

Mais à un moment donné, quand l’équipe de développement vous dit : « Alors le champs « date » est-ce que je le veux là ? Est-ce que c’est en interaction avec cette chose là ? Est-ce que vous préférez plutôt mettre cette information là à tel moment dans mon déroulé ? ». Là, le PO n’a pas forcément la vision aussi claire qu’un utilisateur lui-même, qui est dans une application de CRM tous les jours.

Il n’y a donc aucun sens que le PO face l’intermédiaire. En effet, on a vu que les intermédiaires dans SCRUM devait être absolument bannis. Donc le PO peut très bien déléguer le soin à l’équipe de développement de prendre contact directement avec un certain nombre d’utilisateurs pour répondre à leurs questions. L’important, c’est que le PO soit tenu au courant et qu’il y ait toujours une synchronisation entre l’équipe de développement et le PO.

Et si on se passait d’interface ?…

Un des biais de faire cela, même si c’est tout a fait recommandé dans certains cas, c’est que l’équipe de développement étant en contact des utilisateurs et inversement, les utilisateurs peuvent appeler l’équipe de développement pour ajouter des fonctionnalités. Cela peut causer une interférence entre l’environnement de l’équipe de développement et l’équipe de développement.

Cette problématique doit être gérée par l’équipe de développement bien entendu, mais si elle n’y arrive plus, c’est au Scrum Master d’intervenir.  Pour faire en sorte que ces interférences cessent, le Scrum Master doit avoir une position dans l’organisation, suffisamment élevé pour être entendu, ce qui n’est pas forcément le cas par exemple de certains prestataires.

En outre, l’équipe de développement peut faire l’interface avec les utilisateurs mais bien entendu, c’est une responsabilité ultime du PO. Le Scrum Master lui, intervient lorsqu’il y a un obstacle et que l’équipe de développement n’est pas en mesure de le lever seule. Pour le reste, quand il y a des démonstrations, des revues, quand il y a des échanges avec les utilisateurs : chaque membre de l’équipe de développement est libre de se mettre en avant sur l’un ou l’autre sujet qui le préoccupe.

Découvrir nos formations en ligne

Agilité et documentation : on ne documente plus ?

En agilité, on privilégie un produit fonctionnel à la documentation pléthorique. Cela veut-il dire qu’il n’y a plus de documentation en agilité ?

Découvrir nos formations en ligne

Documenter avec le bon niveau d’effort

Dans Scrum, on parle de « documentation pléthorique« . Donc l’idée, c’est quoi ? Bien-sûr qu’on continue à documenter, mais avec le bon niveau d’effort. C’est là que c’est un petit peu plus délicat. Il faut un niveau d’effort adéquat. Par exemple, il faut adopter le niveau de documentation qui va bien par rapport à l’utilisation des fonctionnalités. Et pour prouver la fonctionnalité, il suffit de la montrer. C’est tout l’objectif de faire participer un grand nombre d’utilisateur au développement applicatif : pour qu’ils s’approprient d’autant mieux le développement. Pour tout ce qui est lié au développeur, à l’architecture, et à la conception, on ne peut pas ne pas documenter. C’est impossible de dire « Ecoutez, vous avez l’application, lisez le code et puis vous vous débrouillerez. »

Un niveau de documentation adapté… Mais adapté à quoi ?

Il faut un niveau de documentation qui soit adapté. Mais adapté à quoi ? Premièrement, à la maturité de l’équipe de développement. Si c’est une équipe qui n’est pas très mature, on aura peut-être intérêt à documenter un petit peu plus qu’un équipe qui est mature. Deuxièmement, la documentation doit être adapté au besoin de passer la connaissance. De plus, s’il y a du turnover de manière importante dans l’équipe, il y a plutôt intérêt de documenter un peu plus. Troisièmement, le niveau de complexité de l’application. Si c’est une application complexe, qui a de nombreuses interactions, qui a des modèles un petit peu compliqué ou des modèles qu’il faut simplement avoir identifiés, tout ça ça a besoin d’être documenté. Rien n’empêche qu’à une user story par exemple soit rattaché un commentaire dans un autre outil où une série de règles métier dans un autre outil comme « Confluence » par exemple, que beaucoup d’entreprises utilisent ce logiciel.

Découvrir nos formations en ligne

En conclusion, il y a encore de la documentation. La réelle question serait plutôt « Quel niveau de documentation« ? Pour cela, c’est du cas par cas. Et justement, dans la méthode agile, on va construire ça plutôt que de décréter que le niveau de documentation doit être de « tant », mais on va le faire de façon un peu plus itérative.

Existe-t-il un sprint 0 ?

Dans la méthodologie Scrum, existe-t-il un sprint 0 ? Lors des formations, les apprenants ont tendance à répondre à cette question par une phrase telle que « Bien sûr qu’il existe un Sprint 0, dans toutes les entreprises où nous avons travaillé, nous avons rencontré un sprint 0, pour constituer l’infrastructure qui va bien pour le développement. ». Cependant, cette affirmation est fausse. Il n’existe pas de sprint 0 dans la méthodologie Scrum, découvrez pourquoi.

Découvrir nos formations en ligne

La fin d’un sprint se caractérise par un incrément de produit

A la fin d’un sprint, on doit pouvoir montrer un incrément de produit qui peut potentiellement être mis en production. C’est à ça que sert une itération. Une itération ne sert pas à construire un environnement,  à outiller, ou à se doter. Un sprint est fait pour livrer un utilisateur. Ou du moins, à montrer des fonctionnalités qui fonctionnent et qui puissent être mises en production par le Product Owner. Donc il est hors de question de terminer un sprint sans rien avoir à montrer à un utilisateur, sans ne rien avoir construit de visible pour l’utilisateur. Alors pour Scrum, c’est très clair, il ne peut pas y avoir des sprint 0 car à la fin de travaux d’architecture ou d’infrastructure il n’y a rien à montrer. On a juste monté ce qu’il fallait au niveau du data center, des boîtes de stockage, de la virtualisation, des composantes, qui va juste permettre de travailler. Tout cela ne s’appelle en aucun cas un sprint 0.

Les travaux préparatoires

En réalité, tout ce qui a été décrit précédemment s’appelle  des travaux préparatoires. D’ailleurs; on le dit très bien dans Scrum. En effet, on dit que si l’infrastructure n’est pas en place pour permettre les travaux de développement, et bien à ce moment, l’entreprise n’est pas prête pour ce projet là. Il faut préparer l’environnement qui va bien, pour permettre au premier sprint de s’exécuter. C’est pour ça qu’il n’y a pas de sprint 0. Et c’est pour ça également qu’une livraison itérative et incrémentale pilotée par Scrum fait partie, tout naturellement d’une gestion de projet classique qui elle doit avoir anticiper les besoins en infrastructure, doit les avoir chiffré, bien entendu puisque c’est pas parce que je fais du scrum que j’ai pas besoin de budget, c’est pas parce que je fais du scrum que j’ai pas un idée de la temporalité des choses, c’est pas parce que je fais du scrum que je n’ai pas de délai ! Bien sûr que non. Donc un développement en scrum, en mode itérative incrémental, bien sûr il est embarqué dan un projet qui est plus vaste, qui est chiffré qui est suivi et donc ce projet doit avoir prévu la mise en place de l’infrastructure qui va bien pour permettre à la livraison itérative et incrémentale de se dérouler. Voila pourquoi il n’y a pas de sprint 0, et voilà pourquoi dans le même temps, je vous l’ai fait un peu rapide, tout ça soit intégré dans une gestion de projet classique.

Découvrir nos formations en ligne

Quand on change le « Done » doit-on revenir sur les développements passés ?

Est-ce que, lorsque l’on revoit la définition du « Done« , il faut revenir sur les développements passés ?

Découvrir nos formations en ligne

Une problématique de la qualité des développements passés

Lorsque l’on parle du « Done » on parle de critères de qualité. A partir du moment où le niveau de qualité change, il y a une problématique sur la qualité des développements passés, qui normalement, n’est plus au niveau des attentes. Etant donné qu’à la fin de notre sprint, on doit livrer quelque chose qui fonctionne, on ne peut pas se permettre de dire : « écoutez, on va griller un sprint ou deux, pour récupérer tout le travail qui a été fait avant ce changement de manière à ce que tout soit au niveau attendu. »

Il faut remettre à niveau les développements passés

Dans la méthodologie Scrum, on attend qu’à la fin d’une itération, il y ait quelque chose qui soit montrable et qui puisse être mis en production. Il est donc nécessaire d’établir ce travail de « refactoring« . Cela signifie qu’au fur et à mesure des itérations, il faudra procéder de manière à remettre à niveau les développements qui ont été faits avant, et qui ne correspondent plus au niveau de qualité attendu. Donc oui, bien-sûr, il faut remettre à niveau les développements qui ont été réalisés, mais on va le faire de manière progressive, continuelle, de façon à ne pas bloquer une itération ou ne pas mobiliser en une seule fois, les forces pour faire ce travail là, ce qui serait contre-productif.

Découvrir nos formations en ligne

Quelles sont les différences entre Scrum Master et Product Owner ?

Quand on est entrain de parler de la description des rôles de Product Owner et de rôles de Scrum Master, il y a toujours des choses qui gênent aux entournures. Il est vrai que la plupart du temps, c’est à ce moment là que je vois des yeux extrêmement inquiets ou très surpris par la description de ces deux rôles.

Découvrir nos formations en ligne

Qu’est ce qu’un Scrum Master ?

Qu’est-ce qu’un Scrum Master ? Evidemment, on le détail en long, en large et en travers dans nos formations. Un Scrum Master, c’est un leader qui est censé permettre à l’équipe de développement (celle qui va faire le travail pour réaliser le produit fonctionnel), de trouver sa voie et son adoption de Scrum. Scrum, c’est une méthodologie détaillée dans le Scrum Guide dans une quinzaine de pages, donc on a l’impression que tout est évident. Loin s’en faut. C’est simple, mais ce n’est pas facile à maîtriser. Parce que cela demande un changement de mentalité qui est radicalement différent des méthodes classiques. Le Scrum Master c’est donc un leader qui doit permettre à l’équipe de développement de  trouver sa manière de fonctionner la plus efficace possible. Il doit également  préserver l’équipe de développement d’interférences avec l’extérieure. Par exemple des utilisateurs qui n’arrêtent pas d’appeler l’équipe de développement parce qu’ils veulent des modifications, clarifications, il faut que le Scrum Master  soit en mesure de protéger cette équipe et de dire « Stop ! Ça suffit, l’équipe est en plein sprint, elle est entrain de réaliser un gros travail, vous la laissez tranquille. Si il y a des fonctionnalités supplémentaires ou des changements de fonctionnalités qui sont demandées, vous vous adressez au Product Owner, et pas à l’équipe de développement.  » Donc cela veut dire que le Scrum Master doit avoir un certain pouvoir dans l’organisation. Cela implique qu’il ne peut pas être quelqu’un de bas dans l’organisation, dans les responsabilités, parce que sinon, il ne va pas pouvoir se faire entendre. Scrum, c’est une organisation matricielle. On constitue des équipes qui sont transverses par nature puisqu’elles ont toutes les compétences pour réaliser le produit final. Par conséquent, on a des équipes qui peuvent provenir parfois de silos différents, mais ducoup, on est bien dans un organisation transverse et donc l’équipe est autonome. Le Scrum Master ce n’est donc pas un chef, ni un chef de projet, ni un manager, mais il doit pouvoir se faire respecter de l’organisation vis à vis du travail en cours. Donc ce n’est pas évident de trouver ce type de profil là, c’est un profil très particulier, et en formation, on a évidemment tout le loisir d’approfondir ça pour que ce soit encore plus clair.

Qu’est-ce qu’un Product Owner (PO)

Le PO (Product Owner), lui ce n’est pas du tout le même type de profil, il est responsable du produit. C’est de loin le rôle le plus important, parce que si le PO n’a pas une vue claire du produit, on va aller dans n’importe quelle direction. Même si on a une équipe de développement qui est super performante, ou mature, ça ne changera pas grand chose. On va se prendre le mur, plus rapidement, mais on se prendra le mur quand même de toute façon.  Ce qui compte en numéro 1, c’est que quelqu’un ait la vision du produit, et une vision suffisamment large pour ne pas être juste concernée par l’application. Le produit lui même mais son environnement également en se posant les questions telles que :

  • « Est-ce que ce produit va être utilisé par la clientèle qui nous concerne ? »
  • « Comment le produit va être utilisé ? »
  • « Qu’est-ce qui va apporter de la valeur à l’entreprise ? »

Ce sont les préoccupations d’un PO. Normalement, le PO est assez élevé dans l’organisation parce qu’il faut qu’il ait une vue transverse de l’utilisation du produit qu’il est entrain de faire réaliser par l’équipe. Et donc, c’est quelqu’un qui est ouvert à l’innovation, qui a une vue quand même relativement claire du produit qui est capable d’écouter, parce qu’il y a des choses qui vont lui remonter de l’équipe de développement qu’il va devoir prendre en compte. Le PO, ce n’est pas un technicien, ni un développeur : c’est quelqu’un qui doit connaitre l’informatique, le produit, et c’est de ça dont il est le garant vis à vis de l’entreprise. Le Scrum Master c’est pareil, il n’a pas à être technique, il doit être leader, il doit avoir la capacité à écouter les différentes parties prenantes, et les aider à trouver leur manière de faire dans l’organisation. Donc on a un Scrum Master qui est gardien de la méthodologie, et un PO qui est gardien du produit. On a deux acteurs qui ont un rôle très important dans l’équipe. Naturellement, on détail tout cela en formation.

Découvrir nos formations en ligne