D’une façon générale, la très haute qualité des présentations a aidé à la bonne dynamique de la journée. Un grand bravo aux conférenciers & organisateurs!

Voici ci-dessous quelques notes de cette journée (Même si l’agilité n’était pas le sujet du jour, je me suis permis de faire des parallèles dans mes notes, lorsque ça me semblait pertinent)

BA et UX : « User Centric », confrontés au changement et complémentaires

(Sources : Kevin Brennan, The future of business analysis — Chrystel Black, Expérience utilisateur + analyse d’affaires : compatibilité ou complémentarité ?  )

Que nous soyons analyste d’affaire ou expert UX (et je rajouterai : ou expert agile), nous faisons le même constat : le manque d’efficience des projets TI et les coûts astronomiques de re-work liés à une faible analyse de besoins.

Nous avons aussi des objectifs partagés : comprendre les besoins des clients et des utilisateurs, proposer des solutions, et surtout, nous adapter aux changements et au contexte. Il est intéressant de noter que la dernière version du rôle du BA a été ajustée en ce sens :

Business Analysis (v3) : The practice of enabling change in an organizational context by defining needs and recommending solutions that deliver value to stakeholders

Pour renforcer la complémentarité de nos métiers, Chrystel Black (Yu Centrik) a utilisé la métaphore des hémisphères du cerveau (créativité versus analyse), se basant sur une intéressante étude réalisée sur les métiers de BA et de UX.

Par rapport à cela, je me questionne sur comment unir les forces de nos métiers? Comment l’agile peut-il supporter ces expertises pour encourager la collaboration et l’efficience ? Comment travailler ensemble ? Comment, au lieu d’opposer les points de vue, les accueillir et les composer pour être encore meilleurs ?… Même sans réponse immédiate, je ne peux m’empêcher de trouver cela stimulant et plein de belles perspectives pour l’avenir.

Poka-yoke ou super-héros ?

(Source : Gilles Lalonde, Mettez du Lean dans vos solutions d’affaires)

Sur un autre thème, la conférence de Mr Gilles Lalonde, autant leanifiante que hilarante, m’a particulièrement interpelée. Son approche Lean/Kaizen appliquée largement dans l’entreprise (processus hospitaliers dans l’exemple) m’a permis de réaliser à quel point nous ne mettons généralement pas les efforts et l’énergie au bon endroit.

Un Poka-yoke est un détrompeur, i.e. quelque chose qui nous empêchera de reproduire une erreur.  Lorsqu’on se trouve dans une situation critique, cherche-t-on à jouer au super-héros pour sauver le monde, ou à trouver la cause du problème pour y appliquer un poka-yoke ? La complexité ici est de faire une bonne analyse du problème, en respectant les 7 étapes :

1. Identifier le problème ou le besoin
2. Comprendre la situation / le statut actuel
3. Énoncer l’objectif – établir le statut cible
4. Procéder à l’analyse des causes racines
5. Brainstormer / déterminer des contre-mesures, et établir un plan de mise en œuvre
6. Vérifier les résultats – confirmer les effets
7. Mettre à jour les standards de travail

Un outil Lean permettant de nous guider dans ces étapes est le « A3 Problem Solving ». Ne pas oublier que la créativité est de mise pour aller à la recherche de solutions innovantes…

Appliqué à l’agile, c’est ce que nous cherchons à atteindre lors des rétrospectives. J’y vois là un outil de plus pour enrichir nos façons de faire ces ateliers.

Gemba ou l’importance de bien clarifier son mandat

(Source : Gilles Lalonde, Mettez du Lean dans vos solutions d’affaires)

Encore une opportunité d’apprendre un mot intelligent pour briller dans les soirées mondaines

Gemba signifie « place réelle ». Associé au Kaizen, cela signifie là où l’action a lieu, le fait d’être présent sur le terrain. Le point du conférencier est de montrer que souvent, nos mandats ne sont pas bien définis. La haute direction a souvent une vision différente de la réalité sur le terrain, et nous mandate pour corriger un problème qu’elle pense avoir cerné. En début de mandat, M.Lalonde nous recommande de prendre le temps de clarifier nos mandats, en allant interroger les personnes concernées sur le terrain, en écoutant et en observant. Cela permet d’identifier les actions faciles, et de construire une solution basée sur les « maillons faibles », donc robuste.

L’importance de l’adhésion avant de procéder au changement dans l’organisation

(Source : Serge Cloutier, La transformation organisationnelle, d’abord un état d’esprit!)

M.Cloutier nous explique l’importance de bien « vendre » un changement :

1. En faisant un lien clair entre le changement et la vision de l’entreprise. Des exemples de changements réussis montrent qu’ils étaient basés sur la confiance dans la haute direction, et dans la cohérence du changement avec la vision de l’entreprise.
2. En identifiant les avantages individuels que chaque personne concernée pourra retirer du changement.

Il nous donne aussi quelques bonnes pratiques pour mettre en place un changement :

• Faire contribuer les personnes concernées
• Respecter les phases d’intégration d’un changement (Sensibilisation  >>  compréhension  >>   adhésion  >>  appropriation  >>  intégration)
• Ne pas implanter un changement avant d’avoir l’adhésion
• Avant d’implanter un changement, mesurer le degré d’adhésion et la capacité à changer (des questionnaires existent pour cela)
• Avoir toujours en mémoire les postulats suivants :
• Toute personne est pourvue d’intelligence et de créativité
• Chacun est responsable d’intégrer les changements qui le concerne
• Le changement se déploie à l’intérieur d’un processus
• Il existe des leaders informels dans l’organisation (qu’il convient d’identifier…)
• Toute personne désire apprendre

Cela paraît simple et évident… mais comme le mentionnait Kevin Brennan en début de journée, « People are hard and it’s not going to get easier »…

Et les autres sujets…

D’autres sujets, tout aussi intéressants, ont été abordés au cours de la journée. De la présentation d’outils visuels aux retours d’expérience, en passant par l’ « agile discipliné », cette journée était riche en information. Comme les présentations devraient être disponibles prochainement en ligne, cela donnera un panel plus complet (le lien sera ajouté lorsque disponible).

En conclusion – La ronde des spécialistes

Avec tous ces sujets et réflexions passionnants, de ma vision de Scrummaster, j’ai énormément apprécié ces échanges teintés par la spécialisation de chacun. Il n’en reste pas moins que je m’interroge sur la façon dont nous pouvons briser les silos et unir nos compétences pour le succès des projets.

Cette myriade de spécialistes m’a rappelé un article de Scott Ambler, sur les spécialistes généralistes. Tous autant qu’on est, et tel que je le perçois, il est important de s’intéresser aux autres corps de métier, pour pouvoir identifier les enjeux, comprendre et respecter les spécialisations de chacun, et collaborer efficacement. De beaux défis en perspectives, pour le mieux des projets !

Une cuillère à café de coordonnateur…

… pour s’assurer au quotidien que l’équipe est fonctionnelle, productive et proactive.

Par exemple, le scrummaster planifie les rencontres agiles (revues de sprint, daily scrum, planifications, rétrospectives…), ou encore traque les bloqueurs et s’assure qu’ils sont adressés.

Quelques grammes d’analyste d’affaire…

… pour accompagner le PO à construire et prioriser son Product Backlog, en étant aligné avec les besoins des utilisateurs finaux.

Le scrummaster serait-il un analyste d’affaire qui s’ignore? Les pratiques et ateliers présentés dans l’extension Agile du BABOK rendent cette question légitime… on y retrouve entre autre la définition de la valeur d’affaire, l’approche utilisateur (personas, Kano, BDD, …), ou encore la gestion du backlog (atelier de Story mapping, séances d’estimation, …)… force est de constater que les similitudes sont troublantes, non?

Un zeste de Project Manager…

… pour produire la reddition de compte, suivre les risques et les actions, communiquer l’avancement… et aussi pour utiliser un langage commun avec des parties prenantes venant parfois d’autres environnements.

Par exemple, selon vous, quelles sont les différences entre les thèmes et les items d’un WBS? entre une Epic et une MMF? Entre l’approche « Plan-Do-Check-Act » et l’approche « Inspect & Adapt »? Il y en a, mais pour mieux transmettre un message, il est parfois intéressant de les lisser, pour utiliser le langage de son interlocuteur… Et puis, dans certains cas, MS Project n’est-il pas utile pour communiquer un plan global et montrer l’enchainement des macro-activités?….

Des graines de Tech lead…

…pour comprendre le langage de l’équipe, détecter ses besoins et s’assurer que la solution technique est alignée sur les besoins d’affaires.

Par exemple, cela est particulièrement utile en séance de découpage en tâches, ou pour mieux cibler les axes d’amélioration possibles, les besoins de formation, etc…

Une pincée de QA…

… pour assurer un contrôle qualité de certains livrables, séances et pratiques, en tant que gardien du processus.

Par exemple, il s’assure que le product backlog est en santé (DEEP), que le daily scrum est quotidien, court et efficace, ou encore que l’équipe respecte sa définition de terminé (aux différents niveaux : story, sprint, livraison).

Un saupoudrage de facilitateur/médiateur…

… pour aider l’équipe à communiquer, à s’améliorer, et à développer un sentiment d’accomplissement.

Le scrummaster aide aussi l’équipe (l’ensemble d’individus) à « être » une équipe, en encourageant la collaboration et en créant un équilibre entre compétences et challenges.

Enfin, ajoutez-y du leadership pour consolider l’esprit d’équipe et du coach pour accompagner individuellement chaque membre de l’équipe. Puis liez le tout avec de l’agent de changement, pour favoriser l’adhésion et l’engagement de l’équipe et des parties prenantes.

Voilà, vous avez obtenu un scrumMaster-kaleidoscope, qui adaptera sa dominante et sa couleur au contexte dans lequel il évolue. C’est la raison pour laquelle il est souvent difficile de définir son rôle précisément, car celui-ci se définira en fonction de son environnement. Voyez-vous d’autres compétences et aptitudes qui lui apporteraient encore davantage de saveur?

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!