Constat
A l'heure de la "mode" SCRUM et agile, beaucoup de chefs de projet tentent la reconversion vers l'agilité.
Nombre d'entre eux, n'ont pas compris qu'il ne s'agit pas en premier lieu d'appliquer une méthode. Malheureusement en France, nous avons fait l'erreur de nommer cela "Méthodes agiles".
Pour rappel, l'"Agilité" telle que nous le connaissons, est d'abord issu du manifeste agile, qui reprend les valeurs et les principes principaux sur lesquels nous fondons notre conviction, et notre état d'esprit.
Ensuite, s'agissant de SCRUM, SCRUM se définit lui même comme étant un "FrameWork", un cadre de travail. Pas une méthode à proprement dite.
Pourquoi cette introduction, car de ce que je vois, nombre de personnes tentent d'appliquer une recette magique, et parfois, quand cette recette, ne donne pas le résultat escompté, on remet en cause la recette, et non les hommes qui tentent de l'appliquer.
Il s'agit avant tout, de changer d'état d'esprit. Il faut revoir sa manière de penser, et d'appréhender les projets.
Mais il est dur de sortir de 20 ans (voire plus long), de cycle en V, mais je ne mettrai pas tout sur le dos de cette méthode qui a toujours ses bénéfices dans les contextes appropriés.
Je pense, que l'aspect qui a le plus gangréné notre manière de travailler est la monétisation via le sacro saint "mode forfait".
Le mode forfait consiste, pour rappel, à débarasser le client d'un projet, en lui produisant un logiciel, qui répond à des spécifications écrites par des tierces parties (rarement le métier), et dont l'interprétation est assez identique à tout livre de référence (ancien testament, Nostradamaus, La divine comédie), c'est à dire très éloignée de la réalité, ou de la volonté du spécifieur (ou écrivain).
Le client est alors souvent spectateur de son projet, à l'image d'un film, où il ne le voit qu'une fois finie, et souvent avec une certaine appréhension, et au final, une certaine déception.
Aujourd'hui, les notions de transparence, de responsabilisation, de ce que j'appellerai le code "just in time", sont encore de mots vains pour beaucoup.
Collaboration : partage des difficultés
L'agilité est d'abord question de collaboration. A mon sens, la collaboration signifie que nous faisons partie d'une même équipe. Nous jouons dans le même camp, pour aboutir ensemble au bon résultat.
Pour l'ensemble des parties, c'est de réussir à partager ses succès, mais surtout partager ses échecs, ses difficultés.
On arrête de masquer ou de lisses ses difficultés. La transparence est une clef de succès. Mentir met systématiquement quelqu'un dans une position difficile.
Il faut que chaque partie réussisse au plus tôt à mettre en évidence, les difficultés liées à son poste (pour le PO, et pour la dev Team). On essaye alors de trouver les plans d'action pour prendre en charge ces difficultés, et les rendre acceptable dans la cadre du projet.
Nier l'évidence, est le meilleur moyen d'aller vers l'échec. La mise en évidence, permet à chacun de travailler en fonction du contexte, et non pas en faisant semblant que l'équipe se trouve dans un utopie.
Transparence & Avancement
Ce que j'essaye d'inculquer à chacune de mes formations est la culture du succès. Idéalement, chaque itération doit correspondre à un succès.
Le succès n'est pas exempt d'embûches ou de difficultés. Le succès c'est d'avoir réussi à en tenir compte pour mener à bien son itération.
La fin d'itération est aussi là pour exposer à chacune des parties les difficultés rencontrées, pour les prendre en compte. Soit pour les aplanir, car les moyens à mettre en oeuvre sont à notre main, soit pour les considérer commme faisant partie du contexte.
Si ces difficultés font partie du contexte, lors des itérations suivantes, les items dans le même contexte, seront à évaluer avec un indice de difficulté les prenant en compte.
Il est important de comprendre, que des items de même type, puissent changer d'évaluation lors de l'estimation, suite à la découverte de leur contexte. Il est sain, que ce contexte entre en ligne de compte la prochaine fois qu'il est évalué.
Auto organisation
Je pense que le plus gros penchant pour le chef de projet est de réussir à se contenir quant à l'organisation de l'équipe. Des règles d'équipes se mettent en place, soyez vigilants à ce qu'elles soient bien respectées, cela demeure dans votre rôle.
Par contre, quant à l'affectation des tâches, à l'entraide... soyez vigilant à rester assez neutre. L'équipe doit maîtriser ce qu'elle fait, et le fait d'avoir un pilote qui s'immisce dans la micro organisation va donner quelque chose de très inefficace et de frustrant pour l'équipe.
Vous pouvez sonder quelques fois, afin de savoir si l'équipe n'a pas oublié quelque chose, plus en format rapport d'étonnement. Soit l'équipe a effectivement oublié quelque chose, et s'adaptera pour compenser cet oubli, soit c'est sciemment que ce choix a été fait, en ce cas, elle vous fournira l'explication qui saura vous rassurer.
Il faut réussir à trouver la bonne distance, entre conseil, et intrusion.
Pascal Ogil
Aucun commentaire:
Enregistrer un commentaire