Peut-être la fatigue a influencé mon comportement, mais malgré toutes ces belles énergies, j’ai eu le blues du ScrumMaster. Parce que la qualité a un coût et qu’en informatique de gestion, notre tolérance aux dysfonctionnements est très élevée… ce qui génère une motivation très moyenne pour investir dans l’amélioration de la qualité.  Ce qui provoque le blues du ScrumMaster certains jours…

Dans les domaines automobile, aérospatial ou médical, les erreurs ne sont pas permises, en toute logique, car les conséquences pourraient impacter des vies humaines. En informatique de gestion, notre comportement en entreprise s’apparente à celui que nous avons chez nous le soir, face à notre ordinateur. Que se passe-t-il si une transaction sur internet échoue? Combien d’entre nous vont juste vérifier sur leur compte en banque que la transaction n’a pas été complétée, et réessayent une heure plus tard? Oui, on est un peu frustré …. Mais on l’accepte quand même, on retente, on finit par compléter, et on passe à autre chose, oubliant l’incident.

Quelle est notre situation aujourd’hui en entreprise?

Je trouve intéressant le billet de W.Pietri, qui reprend la théorie de G.Moore, « crossing the chasm ». En combinant cette approche avec le Hype Cycle de Gartner, voici une estimation de là où nous nous trouverions aujourd’hui, dans l’approche agile.

Sans reprendre le détail du blog de M.Pietri, force est de constater que nous sommes dans une phase difficile pour l’agilité. Mais nos problématiques actuelles sont-elles liées à la méthodologie ou à la qualité des produits livrés?Dans quelle mesure la méthode de travail, agile ou traditionnelle, n’est-elle pas seulement un moyen pour favoriser cette qualité? C’est la raison pour laquelle je dirais plutôt que nous sommes aujourd’hui dans une phase difficile pour l’atteinte de la qualité dans le développement d’applications de gestion.

Quelques raisons qui, à mes yeux, sont des freins à la qualité :

• L’urgence du Time-to-Market, pour ne pas manquer un marché éphémère et chaotique. Cela favorise une vision à court terme, et un manque d’intérêt pour investir dans une qualité à long terme.
• Le gap technologique : plus le système existant est ancien, plus la courbe d’apprentissage pour appréhender les nouvelles technologies est abrupte, longue et couteuse.
• Le cœur de métier : pour beaucoup d’entreprises, l’informatique est un moyen pour atteindre une clientèle, mais la transaction se passe généralement encore dans le réseau physique (ex : vendeur de voiture, immobilier, …). D’ailleurs, notons que dans ce cas, la méthodologie de travail devient le moyen du moyen… Tout un défi pour la faire valoir! Notons également que le gap technologique est souvent présent chez ces client (logique, étant donné que l’informatique n’est pas (encore) une priorité pour eux).

Il y en a surement beaucoup d’autres, mais je m’arrêterai à ces trois qui me viennent spontanément à l’esprit, car ils ont un même effet de bord : contorsionner notre cher triangle… Nous avons beau le tourner dans tous les sens selon nos méthodologies, il se  métamorphose  malgré lui en un carré à coins ronds…. Le budget est serré, la date est Q1 2012, le scope est déjà au périmètre minimal obligatoire… réponse « Jeopardy » à $100: le 4^e levier non négociable. Je vous laisse trouver la question.

Ce qui m’importe maintenant, c’est ce qu’on peut faire avec toutes ces données pour aider nos clients, et améliorer la qualité globale des produits.

Une proposition d’approche en 4 étapes :

1. Analyser la situation actuelle. Par exemple, le diagnostic PATH peut être utilisé pour inspecter la qualité des Processus, des Affaires, de la Technologie (qualité interne et externe), et des relations Humaines.
   • L’objectif est de produire des recommandations évaluées (en gain & effort)
2. Définir la cible souhaitée idéale, en la confrontant aux bonnes pratiques de développement logiciel, aux recommandations du diagnostic initial, et aux spécificités de l’organisation. L’objectif ici est de produire
   • la définition de terminé courante (la qualité qu’on peut atteindre de façon réaliste à court terme),
   • la définition de terminé cible (associée à un plan d’action SMART et jalonné dans le temps pour chaque item)
   • le suivi des risques liés à chaque manquement dans la situation actuelle (avec plan de mitigation) (i.e. la gestion de la dette).
3. Suivre et mesurer à chaque itération :
   • la conformité à la définition de terminé courante (chaque item doit être mesurable),
   • la progression vers la définition de terminé cible
   • les risques associés aux manquements, et les mitigations
4. Choisir de nouvelles actions, soit pour stabiliser la situation actuelle, soit pour l’améliorer et se rapprocher de la cible.

Cela n’a rien de révolutionnaire, mais demande de la patience et de la persévérance. Un de nos beaux défis, en tant que défenseurs de la qualité, est de faire valoir et rendre visible le retour sur investissement de la qualité, autant pour l’entreprise que pour les individus.

Non, la qualité n’est pas un luxe. C’est une économie de 1ere classe, ne l’oublions pas!

Dans ce contexte où l’instantanéité est reine, comment peut-on concentrer notre esprit sur une seule chose?

Je ne sais pas pour vous, mais dans mon cas, j’ai le sentiment un peu dérangeant qu’avant, j’avais moins de difficultés à me concentrer pour quelques heures… Qu’est-ce qui a changé aujourd’hui? Pourquoi est-ce si compliqué de terminer complètement ce qu’on commence… et non pas à 80 %? Pourquoi notre capacité à garder notre focus est-elle si fragile et si influencée par notre environnement?

L’objectif ici n’est pas de blâmer la société actuelle, ni d’y résister ou de chanter une complainte de type « C’était mieux avant… ». Non, mon intention est plutôt de travailler sur notre capacité de nous adapter à notre environnement, maintenant qu’on a conscience de ce qu’il est.

Ma perception est qu’aujourd’hui, nous avons besoin de plus de discernement et de rigueur personnelle pour mieux choisir ce sur quoi nous mettons nos énergies et aussi pour mieux gérer les perturbations.

En tant que Scrum Master, je peux dire qu’un des aspects de l’Agilité qui me plaît beaucoup est qu’il encourage cela. De façon simple, en tant qu’équipe, nous nous « protégeons » des sollicitations extérieures (toujours urgentes) et des distractions (toujours tentantes) par un ensemble de techniques : équipes dédiées, programmation en binôme, blocs de temps, tâches courtes avec un objectif, salle de travail adaptée…

Tel que je le comprends et l’applique, le but n’est pas d’ignorer toute vie autre que la nôtre, mais plutôt de nous questionner sur le moment le mieux adapté pour traiter les demandes, de nous organiser en fonction de cela et surtout de savoir dire « non » (ce qui est incroyablement plus simple à écrire dans un blogue qu’à faire dans la vraie vie J).

Dans mon cas, considérant que j’étais dans cette longue phase d’apprentissage du « non », et que ce n’était pas de toute façon la cause de toutes les perturbations, j’ai essayé d’être rationnelle. J’ai tenté de déterminer l’origine des distractions (Internet, environnement de travail,…), d’accepter certains faits (veut-on vraiment se focaliser sur des tâches ardues un vendredi après-midi ou un lundi matin?) et d’accomplir quelques petites actions simples. En voici quelques-unes :

• planifier sa journée comme si c’était un minisprint (faire une liste de tâches courtes, ordonnées et bien définies en tenant compte de la courbe d’efficacité dans une journée et des tâches plus importantes – sans procrastiner s.v.p.). Par exemple, AgileZen et Evernote sont deux outils parmi d’autres qui peuvent aider à gérer ses tâches;
• prévoir des blocs de temps où on ne peut pas être dérangé (connaissez-vous Pomodoro?) et en prévoir d’autres où on peut l’être;
• dans les moments « sans dérangements », couper les sources de distraction (fermer les applications qu’on n’utilise pas, la boîte de courriel, etc.);
• penser positivement, surtout pour les tâches pénibles;
• combattre la « réunionite aigüe » en s’assurant d’avoir des rencontres courtes et efficaces. (J’aime beaucoup le concept du « 22 minute meeting », simple et efficace.)

Cependant, il reste qu’en premier lieu, la clé est de comprendre pourquoi on fait (ou ne fait pas) certaines choses. Quand on n’est vraiment pas capable de se concentrer sur une action, il me semble qu’on peut se questionner sur la raison pour laquelle on la fait et sur ce qui nous motive…

C’est assurément un défi de tous les jours et, même avec toute la meilleure volonté du monde, il est vraiment facile de déraper et de tomber dans une spirale difficilement gérable. D’où la nécessité de prendre quotidiennement un moment pour ralentir un peu et organiser sa journée. C’est tellement agréable de respirer!

Liens :
Pomodoro : http://www.pomodorotechnique.com/book.html
Evernote : http://www.evernote.com/
AgileZen : http://agilezen.com/
22 minute meeting : http://www.scottberkun.com/blog/2010/the-22-minute-meeting/

Cependant, surtout dans les grandes organisations qui font le choix de l’agilité, notre équipe Scrum se retrouve bien souvent scrutée par les stakeholders, qui déplorent parfois leur manque de visibilité sur l’avancement global du projet. Certes, le Release Burndown, couplé le cas échéant au graphique de Vélocité, adresse ce besoin, mais il a une lacune majeure : il ne permet pas de rendre visible l’atteinte du périmètre minimum, ni de ce fait le levier que l’on a sur la portée.

Mon collègue Mathieu et moi-même avons envisagé un autre graphique, baptisé « Sunset Graph » (en hommage à son visuel si… jaune), dans le but d’optimiser notre communication sur l’avancement et sur les prévisions.

Ses caractéristiques? Il s’agit d’un burn-up mettant en valeur :

• Le périmètre du backlog, catégorisé en obligatoire/important/optionnel
• l’avancement réel catégorisé en obligatoire/important/optionnel
• l’avancement prévisionnel compte tenu de l’auto-évaluation de l’équipe
• la vélocité réelle de l’équipe
• les fluctuations du backlog

Par exemple : Nous sommes au sprint 0 d’un projet, et le PO a catégorisé ses stories. L’équipe fait une macro-estimation de la totalité du carnet de commande par un atelier type wall session, puis nous alimentons le graphique avec les valeurs estimées. Par rapport à l’engagement de l’équipe pour le sprint 1, nous avons le point de départ des prévisions pessimiste et optimiste. L’équipe fait ensuite des hypothèses sur sa courbe d’avancement pire et meilleure (en fonction de sa courbe d’apprentissage pressentie par exemple).

Dans l’exemple du graphique ci-dessus, on constate que selon les hypothèses, à la fin du sprint 8, on pense avoir atteint l’optionnel dans le meilleur des cas, et le milieu de l’important dans le cas pessimiste. Les courbes prévisionnelles divergent logiquement (plus on s’éloigne, moins on est précis).

Suite au sprint 0, au fil des sprints, on met à jour les données après chaque planification.

Par exemple, dans le graphique ci-dessous, au bout de 3 sprints (donc 3 sprints de données réelles), on constate que :

• le périmètre du backlog a évolué
• les évaluations des cas pessimiste et optimiste tendent à converger car l’équipe affine ses estimations
• la pente du réalisé nous montre la vélocité de l’équipe qui va en s’améliorant
• dans ce cas, suite à la révision du backlog et aux réalisations meilleures que prévues initialement, l’équipe pourrait couvrir dans tous les cas l’obligatoire et l’important du backlog.

Ainsi, ce graphique, associé au travail annexe de catégorisation du backlog et de macro estimation de ce dernier, permet :

• à l’équipe, en sprint 0, de prendre conscience de l’ampleur du backlog et des objectifs
• à l’équipe, en réalisation, de vérifier sa vélocité, la justesse des estimations, et de mieux s’évaluer
• au PO, en tout temps, de savoir ce à quoi il peut s’attendre, et si besoin d’ajuster ses priorités et/ou de jouer sur ses leviers Calendrier/Budget/Portée
• de rendre visible l’avancement du projet (atteinte du périmètre minimum), mais aussi les potentiels dysfonctionnements (ex : fluctuation forte du backlog, vélocité dégradée, …)

Tout cela favorisant la communication… CQFD!