Devenir agile, c’est aussi savoir dire non!

STOP!

Image by I am marlon via Flickr

NON. C’est l’un des premiers concepts auquel j’ai été confronté quand j’ai commencé à vouloir être agile dans ma façon de travailler. Une fois ma décision prise de prendre la voie de l’agilité, j’ai dû m’exercer à dire non aux demandes de changements.

Cela semble tout à fait contradictoire avec le concept même d’agilité. Pourtant, si je n’avais pas su commencer à dire non aux demandes de mes patrons et collègues, jamais je n’aurais pu arriver à devenir agile. Qu’il n’y ait pas de mésentente sur mes propos. J’ai appris à dire non, pendant une période transitoire seulement, qui a duré quelques semaines.

Auparavant, chaque demande de changement dans le cours de mon planning de développement était accompagné d’un « impératif » de la part du chargé de projet. Du coup, j’éprouvais de la frustration. La résistance au changement en somme. Non seulement ce changement était « urgent », mais je devais en plus chambouler toute l’organisation de ma semaine.

La première tâche que je me suis imposée fut de dire NON à ces demandes de changements. En fait, pas aux changements eux-mêmes. Mais je me refusais de substituer ce que j’avais sur ma  planche de travail pour ces demandes dites urgentes. Sans le savoir, je commençais à appliquer une méthodologie SCRUM.

Action-réaction

Ce qui m’a immédiatement surpris fut la réaction de mes collègues et patrons demandeurs. Il y avait bien évidemment de la déception, et aussi de l’incompréhension de leur part. Mais contrairement à ce que j’anticipais, il n’y eut pratiquement pas d’argumentation. Le fait que j’expliquais ma décision par une volonté ferme de terminer ce que j’avais en cours de complétion justifiait mon choix à leur yeux. Tranquillement, je me suis monté un backlog (encore un concept de la méthodologie SCRUM que j’appliquais sans le savoir). Les différentes demandes reçues de l’équipe y étaient inscrites, et avec un collègue on l’examinait de temps en temps pour en juger les priorités. À cette étape-ci je ne connaissais même pas encore la méthode SCRUM , je n’avais donc pas commencé à planifier mes horaires en sprints réguliers.

J’estime que cette étape a été cruciale dans ma métamorphose. C’était la pédale de frein, si je peux dire, au modèle Waterfall que nous utilisions depuis si longtemps. C’est parce que j’ai commencé à dire NON aux interruptions que j’ai pu commencer à renverser la vapeur.

Des résultats rapides

Très rapidement, mon entourage s’est bien habitué à ce que je ne dise plus OUI à tout un chacun. Les résultats ne se firent pas attendre. En moins de deux semaines je peux dire que je voyais une différence majeure dans mon travail. J’avais commencé à être agile en limitant les interruptions dans mon cahier de charge. Celui-ci était  maintenu à plus courte échéance, au lieu de contenir l’ensemble des fonctionnalités et livrables du projet. Ce que je planifiais pour la semaine, je le faisais. Je faisais des itérations d’une semaine. En environ deux mois, j’avais réussis à me créer une horaire de semaine pratiquement immuable, sauf pour les véritables urgences. J’avais ainsi pris l’habitude chaque vendredi après-midi de planifier ma semaine suivante. Et mieux encore, je pouvais commencer à donner des estimés sur la date d’arrivée d’une fonctionnalité dans mon développement. Ce que j’avais été incapable de faire de façon précise jusqu’à ce jour. Et ce point était une véritable valeur ajoutée pour notre équipe.

Conclusion

J’encourage tous ceux et celles qui se sentent étouffés par le modèle Waterfall ou par les trop nombreuses demandes de changements à prendre une pause, suivi d’un petit mouvement de recul pour réorganiser leur façon de planifier.

L’agilité telle que je la comprends n’est pas d’instantanément répondre à toutes les demandes. Je citerai pour appui l’un des 12 principes sous-jacents au manifeste Agile :

Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.

Il m’apparaissait fort évident que depuis de trop nombreuses années mon rythme de développement était en relation directe avec ces demandes de changements qui étaient  -de ma part-   mal gérées, mal planifiées, et surtout mal-évaluées.

Dire «NON, ceci ne sera pas fait cette semaine, mais la semaine prochaine, je l’ai céduler.» a été pour moi un point clé dans mon apprentissage et la mise en pratique des méthodologies agiles.

Avez-vous des moments clés de votre apprentissage agile que vous aimeriez partager avec nous? Quel a été le moment où vous avez senti que vos preniez le tournant vers l’agilité dans votre gestion de projet?

Publicités
Tagué , , , , , ,

Une réflexion sur “Devenir agile, c’est aussi savoir dire non!

  1. Je viens de lire un article intéressant qui abonde dans le même sens, sur le blog de Chris Brogan, intitulé « Say no faster ».

    – à lire!

    http://www.chrisbrogan.com/say-no-faster/

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :