Vous est-il déjà arrivé de vous plonger dans le casse-tête ardu d’une gestion de projet? Après une longue fragmentation des tâches, de vous lancer dans la mise en place d’un diagramme de Gantt en sachant pertinemment que d’ici peu, plus rien n’y tiendra? Informations fragmentaires, délais de livraison changeants, restrictions budgétaires ou financement partiel, disponibilités des ressources humaines surévaluées, compétences spécifiques inexistantes et en pénurie, etc. Tout y est pour l'effet domino (Waterfall bias)…
Une mêlée efficiente
Effectivement, bon nombre de gestionnaires de projet ont le réflexe d’utiliser le modèle de gestion de projet en cascade (Waterfall Model) où on organise de manière séquentielle, les grands pans du projet, eux-mêmes décortiqués en séquences de tâches à accomplir. À priori, voilà une manière plutôt logique de concevoir la création et la réalisation d’un produit. D’ailleurs, ce modèle est issu des secteurs manufacturiers et de la construction et dessert bien la production en chaine. Il n’est par contre pas adapté à la réalité d’une gestion de projet en technologie de l’information. Après un certain temps, les impondérables, les avancements technologiques, la compétitivité innovante et la mouvance du secteur des TI nous forcent à abandonner la rigidité de cette structure qui risque l’effet domino à la moindre embuche.
There are two main problems I have with the Gantt chart. Mainly, it assumes that details of the project (at some level) are known from start to finish. It also has the annoying side effect of requiring a project manager to sit and attempt to piece together this plan — usually before any real details about the project are known. This leads to an incomplete plan driving an inadequate development process.
The real problem with the Gantt chart is that it’s so married to the Waterfall development methodology of yesteryear. The practice of software engineering has evolved. Agile development calls for agile project management, and Gantt isn’t it. Adopters of Agile processes realize that the details of the project are not known from the start. They embrace the fact. (http://www.projectshrink.com/the-death-of-gantt-charts-121.html)
C’est ce que 17 experts en développement de logiciels ont décrié en signant le Manifeste Agile (Agile Manifesto) en 2001. Parmi ces experts figurent Jeff Sutherland et Ken Schwaber, les principaux porte-étendard de la méthode Scrum depuis 1996, eux-mêmes inspirés par Hirotaka Takeuchi et Ikujiro Nonaka qui utilisaient l’analogie d’une mêlée de rugby (scrum en anglais) pour exprimer la complémentarité et la flexibilité de l’équipe qui doit continuellement s’adapter aux mouvements du jeu pour être plus efficiente.
Le modèle est bien simple et repose sur un aspect central : l’homme au cœur de l’équipe. Attitré à des fractions du projet, il doit démontrer son implication, ses capacités et ses limites et son engagement à fournir le meilleur résultat. Il s’agit d’une gestion décentralisée et transparente basée sur la confiance et l’interaction humaine.
Le manifeste Agile prône quatre valeurs:
1. L’individu et l’interaction plutôt que les outils et le processus;
2. Le produit opérationnel plutôt que la documentation abondante;
3. La collaboration du client plutôt que la négociation de contrat;
4. La réponse au changement plutôt que le suivi d’un plan.
Une mêlée de savoir-faire: nous sommes tous meilleurs qu’un autre en quelque chose
«Si je ne peux le faire et toi si, alors tu es la personne qu’il me faut». Toute relation client est basée sur ce principe et doit être respectée. Cependant, elle n’est pas à sens unique et nécessite la participation complète du client. De plus, elle doit s’étendre aux équipes de travail. Il y aura toujours une meilleure personne pour répondre à une problématique, à un besoin. Cette approche nécessite une communication constante entre tous les intervenants, et cela, indifféremment des statuts. Dans un scrum, il n’y a d’ailleurs pas de chef. Chacun est chef de son propre rôle. Et assumer ses responsabilités impose de le faire avec humilité. Pour atteindre le but, il faut savoir identifier ses limites au profit des forces de l’autre jusqu’au point d’équilibre « qualité-temps-ressources».
Le Scrum Master quant à lui agit comme un facilitateur. Il doit s’assurer de fournir à l’équipe, tout le nécessaire à leur plein potentiel. C’est un coordonnateur de ressources, un intermédiaire et non pas un dirigeant. Il ne possède pas un poste hiérarchique pas plus qu’une autorité sur les équipes.
Un caucus matinal dans la mêlée (Daily scrum)
L’efficacité de cette méthode repose principalement sur son processus itératif et incrémental. Le projet est fragmenté en segments qui représentent des « sprints » de production d’une durée de 4 semaines. Les équipes doivent alors elles-mêmes établir le plan du sprint et les livrables. Une rencontre quotidienne de 15 minutes permet de faire un suivi sur ce qui a été réalisé, ce qui reste à faire, les problèmes rencontrés et le positionnement dans le temps. En d’autres mots, il s’agit d’un bilan d’efficience.
Vous êtes peut-être plus «mêlée» que vous ne le croyez? Carpe Diem!
À la lecture de ceci, plusieurs se diront : «Ha! Enfin, mon malaise s’explique.» En effet, par la force des choses plusieurs ont dû abandonner la gestion de projet conventionnelle pour s’adonner à une gestion adaptative. Certains y ont trouvé l’équilibre, d'autres le sentiment d’être en marge. Et pourtant, vous n’êtes pas si loin de la mêlée! Cependant, le rugby est une discipline sportive tout comme votre secteur est disciplinaire.
Alors, disciplinez-vous! Implantez le modèle au quotidien, structurez vos rencontres, écoutez vos équipes, offrez leur les moyens dont vous disposez en tant que ScrumMaster, travaillez les solutions et les alternatives dans une gestion adéquate de contingences, responsabilisez vos ressources à travers l’accomplissement et vous verrez vos ressources plus capables que vous ne l’auriez souhaité sans même appeler au surtemps!
… « Mark! »
Aucun commentaire:
Enregistrer un commentaire