Les 7 leviers du consultant pour aider ses clients dans leur transformation digitale

Vous intervenez en tant que consultant dans une entreprise pour amener la transformation digitale de votre client ? Ce rôle n’est pas forcément évident car n’étant pas interne à l’entreprise, vous avez forcément un peu moins de pouvoir dans l’entreprise. Néanmoins, vous avez des leviers d’action absolument considérables.

Découvrir nos formations en ligne

Levier n°1 : « Nul n’est prophète en son pays. »

Vous avez un point de vue extérieur, donc pendant un certain temps vous allez être très écouté. Cette vision extérieure, votre client est venu la chercher en faisant appel à vous. Cela va vous donner un petit peu de marge de manœuvre et d’écoute supplémentaire lorsque vous allez prendre en main votre mission. Appuyez-vous sur ce regard externe, sur cette approche neuve des problématiques de votre client, c’est quelque chose dont il va être extrêmement friand.

Levier n°2 : le rapport d’étonnement

Peut-être que le rapport d’étonnement vous parait suranné, mais bien au contraire. En arrivant dans l’entreprise de votre client avec un œil neuf, il faut tout de suite consigner les choses qui vous paraissent anormales, peu efficientes, ou peu performantes. C’est à ce moment où vous prenez possession de votre mission. Il vaut mieux ne pas attendre avant de dresser ce rapport avant de perdre votre regard extérieur.  Pour vous y aider, rien de tel qu’une « meilleure pratique » parce que vous pourrez y trouver des templates, des méthodes, des cadres méthodologiques qui vont vous permettre plus facilement d’établir votre rapport. Par exemple, si vous êtes dans l’agilité, vous rapprocher d’un cadre comme Scrum® ou PRINCE2® Agile va être quelque chose d’important. Quand vous êtes dans l’organisation d’un système d’information, un cadre comme ITIL® ou comme CoBIT®  va vous permettre d’accélérer la production de ce rapport d’étonnement.

Levier n°3 : Mettez l’accent sur les parties prenantes

En venant de l’extérieur, vous allez découvrir les différents acteurs qui tournent autour de votre projet. Essayez d’élargir ce cercle sous forme concentrique pour découvrir de plus en plus de parties prenantes et essayez de bien détecter si elles sont supportrices, résistantes, si elles sont besoin d’être convaincues ou si elles le sont déjà. La gestion des parties prenantes représente 30% des échecs de projets. C’est une personne que l’on n’avait pas identifié au début du projet et qui a un impact ou bien une influence très importante. Cette personne peut également  avoir eu l’air supportrice en apparence, mais en fait ne l’était pas. C’est pourquoi la gestion des parties prenantes est extrêmement importante.

Levier n°4 : La communication avant tout

Que vous veniez de l’extérieur ou pas, un point fondamental en gestion de projet, c’est la communication. Cela implique de communiquer de la bonne manière avec les différentes parties prenantes, de ne pas sauter de rapport d’étape, d’être toujours très vigilant sur les termes employés, ou encore faire relire les communications par des utilisateurs/acteurs importants de votre client. Pour cela, nous vous conseillons les approches de communication de PRINCE2®, ou de PMP®. Ces approches vous donnent un cadre qui va vous permettre d’identifier les bons moyens pour communiquer avec vos différentes parties prenantes. Dans le cadre d’un projet, un chef de projet passe plus de 80% de son temps à communiquer.

Levier n°5 : Profitez de votre candeur

L’idée, c’est de dire vous venez de l’extérieur, vous avez donc des idées et une vision qui est différente de celle de votre client. Alors n’hésitez pas, parfois, à faire l’innocent(e), la personne qui ne comprends pas complètement. Cela peut débloquer des situations, ou encore donner des idées. Il sera plus acceptable de quelqu’un qui ne connaît pas le sujet un certain nombre de remarques que l’on accepterait pas de quelqu’un qui est expert dans le secteur ou qui connait bien l’entreprise. Donc profitez de cette candeur, elle peut vous ouvrir des portes et vous pourrez d’autant plus faire passer de messages.

Levier n°6 : « What’s in it for me »

Le sixième point est universel, c’est le : « What’s in it for me » soit « Quel va être l’apport du projet pour les utilisateurs« . Si les utilisateurs ne comprennent pas la valeur apportée par le projet, les utilisateurs vont être résistants. Il faut donc être capable de répondre aux questions suivantes :

  • « Qu’est-ce que les gens vont trouver dans l’apport que vous allez amener avec ce projet »
  • « Pourquoi est-ce que ce projet a été lancé ? »
  • « Pourquoi tout le monde doit être motivé ? »
  • « Que faire pour que la valeur apportée soit encore plus grande ? »

Levier n°7 : Ne vous découragez pas !

Il va falloir redoubler d’efforts, convaincre, remettre l’ouvrage sur le métier, reconvaincre, probablement ré-emmener un certain nombre de parties prenantes. Ne vous découragez pas ! Vous avez également des outils qui vous aident dans ce travail, ce sont des méthodes internationales. Ces référentiels regroupent l’expérience de milliers de praticiens. Ils sont là pour vous faciliter la tâche et vous donner des outils, des méthodes qui existent déjà.

Ne réinventez pas en permanence la roue, cela ne sert strictement à rien, la réelle valeur est apportée par ce que vous faites, pas par votre façon de réinventer une méthode !

Découvrir nos formations en ligne

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

NOUVEAU CURSUS : « Maîtriser les projets digitaux avec PRINCE2® et SCRUM® »

Découvrir nos formations en ligne

Nous sommes heureux de vous annoncer le lancement de notre nouveau cursus : Maîtriser les projets digitaux avec PRINCE2® et SCRUM®.

Ce cursus empaquette trois certifications :

  • PRINCE2® Fondation : pour apprendre à structurer un projet de manière classique.
  • Professional Scrum® : qui est la méthodologie la plus reconnue dans l’agilité.
  • Professional Scrum Product Owner : parce que sans un bon product owner, une équipe agile ne fonctionne pas.

Ce cursus et ouvert à toutes les personnes qui souhaitent se reconvertir dans le digital ou renforcer leurs connaissances avec trois certifications internationalement reconnues.

Ce cursus sera bientôt disponible au CPF* (Compte Personnel de Formation).

Découvrir nos formations en ligne

Lancement des webinaires Skills4All !

Nous sommes ravis de pouvoir vous annoncer le lancement de nos webinaires gratuits, qui se tiendront entre 12h15 et 13h00.  Nous parlerons de tous les sujets  liés à la transformation digitale : gestion de projet, agilité, management, amélioration de processus, organisation des systèmes d’information

Notre objectif est également de vous donner une visibilité sur l’ensemble des référentiels et des certifications qui existent. Si vous ne le saviez pas, elles apportent énormément de valeur à ceux et celles qui les détiennent : obtenir des outils au quotidien pour améliorer son travail, changer de poste, se réorienter, ou encore acquérir de nouvelles compétences de manière très efficace.

Inscrivez-vous, nous serons ravis d’échanger avec vous autours de ces sujets qui nous rassemblent.

Découvrir nos webinaires

Le chef de projet doit-il être technique ?

Une question brûlante dans la gestion de projet : le chef de projet doit-il être technique ? Pour moi la réponse est vraiment claire, c’est non. Pourquoi ?

Découvrir nos formations en ligne

Le chef de projet est un chef d’orchestre

Le chef de projet est un chef d’orchestre. En effet, il n’est pas censé jouer de tous les instruments de l’orchestre. Par contre, il connait la musique. Il est donc capable de s’appuyer sur le reste de l’orchestre, pour faire jouer cette musique. C’est exactement ça, le rôle de chef de projet. En fait, il est à un niveau de pilotage par rapport au reste de l’équipe. De ce fait, que le chef de projet connaisse la musique, bien-entendu, mais il n’est pas obligé de savoir jouer de tous les instruments. Être chef de projet, c’est la même chose. C’est d’ailleurs pour ça que le PMI® a construit PMP®, et qu’Axelos vend PRINCE2®, c’est parce que ce sont de vraies méthodes reconnues. Il est très compliqué de devenir chef de projet du jour au lendemain, même si c’est le sort de beaucoup d’entre nous, mais ce n’est pas vraiment raisonnable. En effet, être chef de projet c’est un métier qui nécessite compétences spécifiques qui ne sont pas des compétences de développement, de bases de données, ou encore de construction de bâtiments. Ce sont des compétences d’organisation. Le chef de projet n’a pas besoin d’être développeur, maçon ou encore chaudronnier pour gérer un projet de construction.

Le rôle du chef de projet au sein d’une équipe

Un chef de projet doit être communiquant, et doit être capable de s’entourer des bonnes personnes. Il doit être conscient des plannings et des budgets, de la temporalité, des coûts, et du périmètre qui est attendu. Tout cela, ce sont les compétences les plus importantes.

Il arrive assez souvent que l’on nomme un chef de projet quelqu’un qui est technicien. Ce n’est pas la meilleure idée, parce que la plupart du temps, quand on nomme un profil technique chef de projet, on risque d’avoir une approche trop technique du projet. Ce n’est pas forcément un gros problème, mais ce qui va manquer c’est une approche à plus haut niveau du projet en termes de déroulé général, de risques, ou encore de respect de la communication par exemple. Le rôle du chef de projet ce n’est pas juste de faire en sorte que tout les routeurs soient bien installés, mais qu’il y ait eu un accompagnement. Les chefs de projets n’ont donc pas besoin d’être techniques, mais ils doivent comprendre la technique, être capable de dialoguer avec les équipes qui se chargent de la technique mais son rôle principal c’est d’être dans la communication, l’anticipation et le leadership.

Découvrir nos formations en ligne

La réponse est donc non, le chef de projet n’a pas à être technique mais à besoin de savoir écouter et communiquer.

Qu’est-ce que fait le chef de projet quand le sponsor ne vient pas aux comités ?

Aujourd’hui, nous répondons à une question souvent posée en formation Prince 2 et en gestion de projet  : « Qu’est-ce que je fais quand le sponsor ne vient jamais aux comités de pilotage ? ».

Découvrir nos formations en ligne

Le chef de projet ne doit pas prendre de décisions structurelles

La réponse immédiate serait de dire : ne prenez de décisions à sa place. C’est la chose que ne peut pas faire le chef de projet, c’est prendre des décisions structurelles vis à vis du projet, parce que ce n’est pas son rôle. Le chef de projet à le rôle de chef d’orchestre. Il doit faire jouer une musique qu’on lui a donné. C’est-à-dire de respecter le budget qui lui a été donné, le timing qui lui a été donné et le produit qu’on lui a demandé de produire. Mais si à un moment donné, il y a besoin de prendre des décisions, il ne faut pas que ce soit le chef de projet qui le fasse, parce qu’à ce moment là, il endosse une responsabilité qui n’est plus la sienne. Il y a pleins de projets où le chef de projet est un peu seul dans son bateau, et il essaye de faire avancer la chose comme il peut, avec ses possibilités, avec les moyens, de manière à respecter l’engagement qu’il a contracté vis à vis de son client. C’est d’autant plus prégnant notamment lorsque l’on est prestataire, consultant dans le cadre d’une société de service par exemple et qu’on doit faire avancer le projet de son client, et le client peut avoir tendance à laisser le chef de projet se débrouiller parce que de toute façon c’est une ressource externe. En effet, on peut rencontrer ce genre de dynamique là. En tant que chef de projet, malheureusement, il faudrait se garder le plus possible de prendre des décisions structurantes, ce qu’il faut faire, c’est de remonter les alertes le plus souvent possible à son sponsor, et le tenir informé par écrit des risques de manière à ce que le sponsor ait toute les informations lui permettant potentiellement de prendre la bonne décision. S’il n’a pas les informations, il est clair que ça va être de la faute du chef de projet.  Il faut donc absolument que le chef de projet fasse remonter les alertes dès qu’elles se produisent. Et par conséquent, mettre le sponsor devant ses responsabilités.

L’anticipation des risques

Si, au delà de tout ça, le sponsor ne vient toujours pas en réunion, ne prend toujours pas de décisions, malheureusement, il n’y a pas de recette miracle pour faire face à ce genre de situation qui se produit assez souvent, vous faites un petit peu comme vous pouvez. Maintenant, en tant que prestataire, vous avez un engagement auprès de votre client qui est difficile de faire exploser en plein vol. Mais lorsqu’il n’y a pas l’édifice de base, c’est-à-dire le responsable ultime et lorsqu’il n’y a pas de volonté de faire, en fait, il n’y a pas de projet. Néanmoins, tout ces référentiels là, ils vous disent des choses importantes : le chef de projet ne prend pas de décisions structurantes. Faire remonter toutes les positions de risque au responsable de l’entreprise, à votre sponsor ou à votre exécutif. Essayez d’anticiper le plus possible ces situations de risque. Essayez de mettre en place des plans d’action, des alertes, des warning sign, des déclencheurs et de nommer des Risk Owners par exemple qui vont permettre d’alerter le chef de projet au plus tôt dans une possible matérialisation d’un risque.

L’aspect qu’il faut traiter urgemment quand on a pas de sponsor ou quand il ne prend pas les décisions, bien-sûr, c’est les risques. Donc il faut mettre le paquet dessus de manière à ce qu’au moins, cela puisse remonter et que vous ayez fait votre travail le plus professionnellement possible.

Découvrir nos formations en ligne

C’est quoi le Proxy-PO ?

On entend souvent parler de Proxy-PO. Mais qu’est-ce que c’est ?

Découvrir nos formations en ligne

Le Proxy-PO supplée le Product Owner (PO)

Premièrement, dans Scrum, le Proxy-PO n’existe pas. Ça n’existe parce qu’un Proxy-PO c’est quelqu’un qui supplée le PO. Pourquoi ? Parce que dans beaucoup d’organisations, le PO doit avoir un certain niveau dans l’organisation pour avoir une vue transverse de la problématique à laquelle il participe. Il ne suffit pas juste de se concentrer sur un développement, il faut voir dans quel contexte plus global il va s’insérer. Les PO sont censés être à un niveau relativement élevé dans l’organisation, avec une vue suffisamment transverse. Ils sont très occupés la plupart du temps. Donc, on a du mal à ce qu’ils soient 100% disponibles pour l’équipe. Mais on a besoin qu’ils puissent être mobilisés 100% du temps. La distinction est très fine, je vous l’accorde. A tout moment, l’équipe de développement doit pouvoir contacter son PO pour demander des éclaircissements, ça n’aurait aucun sens d’attendre la semaine d’après, ni même le jour d’après, ce qui pose donc la question de la disponibilité. Les PO sont des personnes normalement assez occupées du fait de leur vue transverse, donc on nomme un Proxy-PO. Le Proxy-PO, c’est donc la personne qui endosse le rôle de PO à la place du vrai PO.

Risque de désynchronisation entre le PO et le Proxy-PO

La difficulté, c’est que le Proxy-PO et le PO peuvent se désynchroniser. C’est-à-dire qu’à un moment donné, le Proxy-PO se fait une vision de ce que le développement pourra réaliser. Il se l’approprie, et se désynchronise du PO qui lui, en à peut-être une autre. Ce genre de problème peut alors mettre en difficulté toute l’équipe. C’est le problème principal. C’est pour cela que Scrum ne recommande pas du tout ce genre d’organisation. Mais à un moment donné, dans les entreprises, il a fallu trouver des solutions. Le Proxy-PO reste donc une solution  moins grave que de ne pas avoir de PO ou d’avoir un PO qui n’est pas vraiment embarqué dans le projet. Alors, on nomme un Proxy-PO qui va essayer de représenter la voix du PO le mieux qu’il peut.

Découvrir nos formations en ligne

Le Product Owner doit-il avoir du pouvoir dans l’organisation ?

Une question très importante qui est posée assez régulièrement : « Est-ce que le Product Owner doit avoir du pouvoir dans l’organisation ? ».

Découvrir nos formations en ligne

Il n’y a pas de hiérarchie dans la Scrum Team

Si vous avez suivi une formation Skills4All, vous savez que le Scrum Master a une position de management dans l’organisation même s’il n’est pas le manager de l’équipe de développement. Le PO (Product Owner) lui, c’est pareil. Il doit avoir un certain niveau dans l’organisation, non pas pour avoir autorité sur l’équipe, puisqu’il n’y a pas de hiérarchie dans une Scrum Team. Le Scrum Master n’est pas une hiérarchie de la development team, de la même manière que que le PO n’est pas le chef du Scrum Master ou de la development team. On est dans une équipe qui est transverse puisque on est en fait en mode projet, même si on aime pas dire ça pour une équipe agile puisqu’on est pas entrain de faire de la gestion de projet.

Mais pourquoi le PO a-t-il tout de même un certain niveau dans l’organisation ?

A un moment donné, si le PO a un niveau dans l’organisation, c’est parce qu’il faut qu’il ait une vue suffisamment haute du produit qu’il va réaliser. Il ne faut pas qu’il se contente de savoir qu’il faut développer un CRM. Il ne peut pas se contenter de se dire qu’il faut développer tel produit à destination de tel client. Ce n’est pas suffisant. Il faut qu’il ait une idée du contexte : de l’entreprise, des contraintes de l’entreprise, des besoins des utilisateurs, de la concurrence, du marché. Et ça on le dit très bien en formation : on a toute une séquence sur le Product Owner qui dure un petit moment où on essaye de le décrire. Le PO n’est pas technique, il n’est pas censé connaître le développement, il a même aucun intérêt à connaître le développement. Un PO technique n’est pas un avantage.

Le Product Owner doit être fonctionnel

Le PO doit être fonctionnel. Il a déjà suffisamment de difficultés à être dans le fonctionnel pour qu’il ait à s’occuper de tout ce qui est du développement. Il vaut mieux un PO qui soit fonctionnel à l’écoute l’équipe de développement plutôt qu’un PO qui soit technique et qui n’écoute pas. Ce PO, doit avoir un certain niveau dans l’organisation parce que pour avoir une vision transverse, il faut quand même plutôt être à un niveau plus élevé dans l’organisation où on ne s’occupe pas seulement du produit mais également du produit dans son contexte. Il faut avoir une vue du processus dans lequel le produit va s’insérer. Si on est entrain de développer un CRM : il faut avoir une vue de l’ensemble de la relation client pas juste du fonctionnement du CRM. Donc ce Product Owner va se retrouver relativement fréquemment normalement à un niveau quand même conséquent dans l’organisation, justement pour avoir cette vue transverse parce que plus on s’élève dans l’organisation ,plus on a une vue transverse de la situation.

Découvrir nos formations en ligne

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

Comment être agile simplement ?

Aujourd’hui, nous allons parler d’agilité.  Au cours des formations, ou d’entretiens avec des clients, on nous demande souvent « Notre entreprise est-elle agile ? », « Que faut-il pour devenir agile ? ». Nous ne reprendrons pas un cours sur ce que c’est l’agilité, mais nous allons remettre la focalisation sur les 4 grandes valeurs agiles.

Découvrir nos formations en ligne

Individus et échanges plutôt que processus et outils

Rapidement, la première grande valeur agile, c’est de préférer les individus aux processus. Il vaut mieux avoir un petit peu d’intelligence dans ce que l’on fait plutôt que de s’appuyer sur des outils, qui sont formatés, et qui nécessitent qu’on emprunte toujours la même route.

Produit fonctionnel plus que documentation pléthorique

La deuxième valeur, c’est d’avoir un produit qui fonctionne. Quel est le meilleur indicateur de succès, par exemple pour une application, que d’être en mesure de l’utiliser sans avoir besoin de la moindre documentation ? C’est ça une des grandes valeurs également de l’agilité. Je suis entrain de construire itérativement un produit, et finalement je n’ai pas besoin de documentation utilisateur parce que l’utilisation du produit elle-même, se suffit.

Collaboration du client plus que négociation du contrat

La troisième valeur, c’est la collaboration. Le fait de travailler ensemble, que ce soit MOE, MOA, les métiers, les clients, ou l’IT : il faut être ensemble pour se comprendre et pour être capable de s’adapter à des changements rapides.

Réactivité au changement plutôt que suivi d’un plan

La quatrième valeur, c’est le fait de s’adapter aux changements, en permanence.  L’agilité c’est de la construction itérative, par petits morceaux, avec du feedback de client extrêmement rapide. Il faut donc être en mesure de s’adapter et d’être réactif.

 

Voilà, si on est plutôt dans chacune de ces dimensions là, si on respecte chacune de ces valeurs là, il y a de fortes chances qu’on soit proche de l’agilité, qu’on soit dans un fonctionnement agile. Il n’y a pas besoin d’être Scrum®, il n’y a pas besoin d’être SAFe®, il n’y a pas besoin d’être  DSDEN, ou XP ou tout ce que vous voulez. Il faut être conforme, le plus possible à ces 4 valeurs là, les respecter et alors là il n’y a pas de raison de ne pas parler d’agilité. L’agilité, ce sont ces 4 grandes valeurs là.

A très bientôt évidemment sur Skills4All où on parle de tout ces sujets là, avec grand plaisir !

 

Découvrir nos formations en ligne