Aller au contenu | Aller au menu | Aller à la recherche


C'est moi ou quoi ?

verre.jpg

Il y a quasiment 15 ans, je faisais mon stage de fin de maîtrise. Et le fait de déjeuner encore de temps avec mon maître de stage est un plaisir tout particulier. L'une de ces rencontres, dans la vie, simple, chouette. Nous nous sommes d'ailleurs retrouvés un jour par hasard, mais c'est l'histoire d'un autre billet...

Lors de notre dernier déjeuner, nous échangions sur nos dernières nouvelles professionnelles. De bonnes nouvelles, nous sommes heureux tous les deux.

Et il me dit : "Je me rends compte que professionnellement, dans mon entourage, je suis quasiment le seul à me plaire dans ce que je fais. A aller au travail avec plaisir le matin. C'est moi ou quoi ? C'est le fait que je vois le verre à moitié plein la plupart du temps ?".

Je dirais que oui, et pas seulement. Certains ont la capacité à changer les choses autour d'eux. Et c'est ce qu'il fait, tous les jours, dans son travail. Il amène de nouvelles manières de faire les choses, et surtout des manières de voir les choses différemment. C'est lui qui façonne son environnement de travail, et même son travail lui-même, en quelques sortes.

Cela m'a fait penser à un courant vu ces dernières années de temps en temps sur le net : le 'job crafting'.

Tu n'aimes pas ton job ? Change-le ! (et non "changes-en"...)

La plupart des personnes disposent d'une certaine (souvent beaucoup plus grande qu'elles ne le pensent) marge de manœuvre pour changer leur poste (la manière de faire, les collaborations avec les autres acteurs, etc). D'ailleurs c'est une partie de mon champ d'actions, professionnellement : amener les personnes à voir le champ des possibles dans leur équipe, dans leur organisation. Voir au-delà du cadre existant. Et c'est l'une des nombreuses choses qui me plaisent dans mon job...

Illustration : le verre de quand j'étais petite... Avec le numéro au dessous, qui donne notre âge !


Est-ce que tu vois ce que je vois ?

champ_de_fleurs.jpg

C'est une chanson de Vanessa Paradis, qui commence comme ça :

Non mais tu vois ce que je vois



Toute la vie devant toi

Viens voir comme elle est belle

Je te fais la courte échelle

Et vous savez ce que je vois, moi, à chaque fois que je l'écoute ? Et bien je me vois derrière un vieux muret de pierres, qui donne sur un magnifique champ de fleurs. Et je fais la courte échelle à ma fille, en lui disant : "Regarde comme elle est belle ! N'aie pas peur, vas-y !"

C'est facile, au signal, tu décolles du sol

C'est facile, même pas mal, tu t’envoles dans le ciel

Ma fille n'a que 6 ans, mais déjà, je veux qu'elle sache que la vie est à la fois un immense champ de fleurs, et un grand tableau vierge qui n'attend que ses coups de pinceau. Et c'est un peu notre rôle de parent de transmettre cela, chaque jour, dans notre manière de vivre.

Oui, la vie amène parfois son lot d'obstacles, d'épreuves à affronter. La force de les surmonter est en nous. Apprendre à mobiliser cette force, c'est avant tout avoir confiance dans le fait qu'elle est là. Avoir confiance en la résistance de nos ailes.

N'aie pas peur qu'elles se brûlent tes ailes

N'aie pas peur qu'elles s’emmêlent ma belle

Elles ne sont pas fragile tes ailes, ma belle

Illustration : un champ de fleurs, comme celui que je vois...


Le sel de la vie

acacia.jpgLe sel de la vie, ce sont toutes ces petites choses agréables de la vie. Et chacun, chacune, a "son sel", quasiment infini.

Pour moi, ce pourrait être, marcher pieds nus dans le sable aux premiers beaux jours, redécouvrir un foulard oublié au fond d'un tiroir, l'odeur d'un acacia portée par un courant d'air, les premiers sons d'un concert lorsque les musiciens accordent leurs instruments, déballer un savon neuf...

Une femme, Françoise Héritier, en a écrit ainsi un livre entier. Et pourquoi pas ?

Le rapport avec les rencontres d'une vie ? Rencontrer quelqu'un, c'est, d'une certaine manière, aller à la rencontre de soi-même...

Un dernier grain de sel avant de vous quitter : regarder les livres à côté de mon lit, et laisser seule mon envie de l'instant choisir celui que j'ouvrirai pour commencer la nuit...

Bonne nuit...


Les choses changent...

...et moi aussi. Depuis quelques mois, j'ai la chance de faire partie de la dream team Agile Garden. Ce que je pouvais écrire avant ici, je l'écris désormais là-bas.

Ce blog évolue donc, pour accueillir désormais des choses plus personnelles. Son nom change en conséquence.

Car la vie est faite de... rencontres. Dont j'ai envie de parler ici. Et aussi partager quelques instants choisis, quelques pensées furtives, et autres questions ronronnantes...

De temps en temps, peut-être !

Dorothée


L'agilité vue par un cabinet d'avocats

avocat.png La question de la contractualisation revient très souvent à un moment ou à un autre lorsque l'on parle d'agilité, et c'est bien normal. Il est possible de trouver assez facilement sur le net des modèles de contrats et les préconisations d'agilistes. Malgré tout, les agilistes ont beau avoir un avis sur la question, ils ne sont pas spécialistes en droit des affaires.

Et des spécialistes en droit des affaires qui auraient compris ce qu'est l'agilité, ce serait intéressant, non ? Et bien voilà : Staub & Associés est un cabinet d'avocats spécialisés dans le domaine de l'informatique, et ils ont écrit sur leur blog deux articles au sujet des méthodes agiles.

Lire la suite...


La Route de Brique Jaune

Dorothy

La Route de Brique Jaune est un jeu presque sérieux inventé par Portia Tung. J'en profite d'ailleurs pour citer son excellent blog Selfish Programming, que je vous invite à aller découvrir quand vous aurez fini la lecture de ce billet !

L'objectif du jeu est de nous amener à modifier notre façon de penser pour trouver des solutions à un problème, et ceci grâce au co-coaching. Portia définit le co-coaching comme un genre de coaching : au sein d'un binôme, chaque personne joue tour à tour le rôle de coach et le rôle de personne coachée. L'idée est de nous aider à voir nos problèmes différemment, et ainsi d'entrevoir d'autres façons de réagir, d'autres pistes de résolution.

Pour comprendre et apprendre le co-coaching, le jeu nous met en situation d'appliquer 4 compétences les unes après les autres : poser des questions, observer, écouter et faire part de ses impressions à son pair. En prenant pour sujet des problèmes de la "vraie vie" que l'on souhaite travailler.

J'ai découvert ce jeu par hasard (un peu parce que je m'appelle Dorothée,merci Bénédicte), et je l'ai laissé longtemps de côté, sans trop savoir comment l'utiliser. Le sujet est délicat : ce jeu aborde l'"être", et non le "faire" comme souvent, et tout le monde n'est pas prêt à cela, d'autant plus dans un jeu, au sein d'un groupe.

Mais voilà, l'occasion s'est présentée à moi de le jouer : les agile games. Un événement où des gens (très ouverts d'esprit) se retrouvent pour jouer, animer, inventer des jeux ayant un lien avec l'agilité. Le principe est simple : chacun a la possibilité de proposer un jeu, et c'est en fonction du nombre de personnes intéressées qu'il est joué ou non. Après avoir beaucoup hésité, j'ai proposé le jeu de la route de brique jaune. Et pas mal de monde s'est dit intéressé. Pierrick m'a aidé à l'animer. Et je l'ai même rejoué, à la demande de ceux qui n'avaient pas pu participer au premier tour !!

Quelques amis de jeu en ont parlé sur leurs blogs :

Romain : "3ème coup de cœur de ces 2 jours, un jeu sur le co-coaching, merci Dorothée ! Chaque équipe est composée de 3 personnes qui à tour de rôle jouent le coach, le coaché ou l’observateur. Un grand merci à Caroline et Christophe avec qui cette heure passée ensemble m’a beaucoup appris sur le problème que j’ai exposé. Ils m’ont aidé à le comprendre et à l’analyser sous des angles nouveaux, j’étais vraiment libéré ! Je repars aussi avec de nouvelles techniques de coaching pour mes prochaines équipes." Blog Talon d'agile

Pierrick : “C’était une expérience vraiment à part de tout ce qui s’est déroulé pendant ces 2 jours, de part la durée : 2h30, mais surtout par l’intensité des échanges que cette activité a générés. Très rapidement, les discussions ont abordé des points très personnels, et parfois intimes, mettant certains participants en zone d’inconfort. Même si c’est un des objectifs de l’exercice, en tant que facilitateurs, on a eu peur que certaines personnes atteignent la zone rouge. Heureusement, ça n’a pas été le cas. ...Blog d'Agile Garden

Fabrice : "Dorothée est prête, elle se fait assister de Pierrick (@keurvet) - son doudou comme elle dit - pour maîtriser le timing et la décharge émotionnelle du jeu, parce qu'il va y en avoir ! ... C'est génial... et beau, chut... je n'en dis pas plus, c'est rien qu'à nous ;-) ..." Blog Agilarium

Je ne regrette pas de l'avoir proposé. Et je le rejouerai certainement un jour, lorsque l'occasion se représentera. Toutes les explications sur le jeu sont là : Agile Fairytales.

Les Agile Games, ça recommence en 2013 : les 1er et 2 février prochains et ce sera à Avignon. Allez-y ! Attention, places limitées !

Pour finir, un grand merci à Portia pour ce jeu, mais aussi et surtout, une pensée pour elle, qui a postulé pour un job de maman, et qui démarre son nouveau métier très prochainement ! A bientôt Portia !


KISS me

kiss

Je vais encore avoir droit à quelques remarques sur mon titre, mais après "Perfectionne-moi", celui-ci s'imposait, pour rester dans le ton ;)

Pour beaucoup d'entre nous, le principe KISS, Keep It Simple Stupid, nous parle déjà, puisque la simplicité est l'une des valeurs de l'agilité.

Mais ça vaut le coup de la rappeler, car dans certaines situations on a vite fait de l'oublier. Et j'ai envie de préciser que cela n'est pas valable uniquement pour la partie développement. Il faut savoir rester simple dans l'organisation, dans les relations, dans l'expression.

Ainsi, le principe ne s'applique pas qu'aux développeurs, mais aussi aux product owners. Par la façon de procéder à l'expression du besoin, préconisée par les méthodes agiles (dans SCRUM notamment), au travers d'un backlog que l'on priorise, on réussit à ne faire que les fonctionnalités nécessaires aux utilisateurs. Et ainsi, on simplifie le produit. Alors que lorsque l'on doit tout spécifier dès le départ dans une expression de besoin "exhaustive", on a tendance à mettre absolument tout ce à quoi on pense, et de peur d'en oublier on s'efforce de penser à tous les cas de figure imaginables.

Mais c'est aussi dans la rédaction des user stories que le PO doit penser à faire simple. Ce qui ne veut pas dire simpliste. Je cite Einstein : Rendez les choses aussi simple que possible, mais pas plus simple. *. Il faut continuer à expliquer les règles de gestion, les règles de calcul (au travers de tests d'acceptation c'est encore mieux). Mais sans se noyer dans les explications. On pourrait d'ailleurs s'inspirer des développeurs lorsqu'ils se disent qu'une tâche estimée à plus d'une demi-journée de travail doit être redécoupée. On pourrait se dire que la description d'une user story doit tenir X lignes, ou X pages (selon votre projet), et si ce n'est pas le cas, c'est peut-être signe qu'elle peut être découpée en 2 user stories ? D'ailleurs on pourrait dire KISS = Keep It Simple and Small ! Si le coeur vous en dit, essayez !

Je ne peux pas finir sans citer Léonard, Antoine et Steve :

  • La simplicité est la sophistication suprême. Leonard de Vinci
  • La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer. Antoine de Saint-Exupéry
  • La simplicité peut être plus difficile à atteindre que la compexité : il faut travailler dur pour arriver à faire simple. Steve Jobs

* : Cette citation, lors de mon premier projet agile, je l'avais affichée au mur de notre bureau. Souvenirs, souvenirs...

Kiss, Dorothée


Exister est un fait, vivre est un art.

Il y a un peu plus d'un an de cela, je me trouvais à la gare, attendant le train qui devait m'emmener à l'autre bout de la France, dire une dernière fois au revoir à ma grand-mère.

J'ai eu envie de m'offrir un livre pour m'accompagner dans ce voyage. Sur le présentoir, c'est un petit livre bleu qui m'a fait de l'oeil. "Petit traité de vie intérieure" de Frédéric Lenoir. Mon choix n'a pas été difficile, il fallait que je le lise. Ce livre ne s'est pas contenté de m'accompagner sur le trajet Nantes - Nancy, il continue de le faire.

Exister est un fait, vivre est un art. Tout le chemin de la vie, c’est passer de l’ignorance à la connaissance, de la peur à l’amour.

Ce petit traité est [...] le fruit d’une réflexion personnelle élaborée à partir des courants de sagesse philosophiques d’Orient et d’Occident, de la spiritualité chrétienne libérée de sa gangue normative et de la psychologie des profondeurs. Je n’ai pas d’autre ambition que d’offrir ce qui m’a aidé à vivre et à me construire.

L'auteur nous parle ainsi tour à tour de confiance et lâcher prise, de la non-violence et du pardon, de l'amitié et de l'amour, de l'"ici et maintenant"... De la mort, de la beauté...

Après avoir lu l'auteur, j'aurai vendredi prochain l'occasion de l'écouter lors d'une conférence autour de « La quête spirituelle ou la recherche de la vie intérieure ». J'ai hâte...

Bonne semaine à vous tous.


C'est aussi cela, l'agilité !

Régulièrement, j'entends "Regarde, moi aussi je suis agile !!!".
Avant, j'avais parfois envie de répondre "Ben oui, mais pas vraiment... Comment dire..."
Je vous donne deux exemples récents.

Le premier, c'est une amie qui travaille dans les ressources humaines au sein d'une SSII. Elle s'occupe notamment des recrutements. Elle m'avait vue travailler sur un projet en mode agile il y a quelques mois, et avait observé en particulier les pratiques les plus visibles : le tableau de suivi avec les post-it, et le stand-up du matin avec l'équipe. Il y a quelques jours, je passe dans son bureau, et toute fière, elle me dit "Regarde, je me suis mise à l'agilité !" en me montrant son tableau de suivi des recrutements (à contacter, en cours...). Elle m'explique la signification des colonnes, la codification des post-it, et la mise en place du stand-up, tous les matins, avec l'équipe des commerciaux, ce qui leur permet de faire le point entre le recrutement et les besoins. J'ai trouvé ça super. S'être inspirée de ce qu'elle avait vu pour améliorer le fonctionnement de son activité, c'est très chouette ! Mais j'avais aussi envie de lui dire que l'agilité ce n'était pas que cela, sans trouver vraiment les mots pour l'exprimer simplement.

Le deuxième exemple, c'est un ami qui a rencontré quelques difficultés l'année dernière avec l'un de ses enfants. Celui-ci se désintéressait de l'école, se faisait remarquer en classe etc. A la fin de l'année scolaire, et après de nombreux rendez-vous avec différentes personnes, les parents ont finalement appris que leur fils était surdoué !
Mon ami a deux autres enfants, et ne souhaitait pas revivre des difficultés de ce genre. Il a donc trouvé un moyen de déceler au plus tôt les passages à vide de ses enfants, en s'inspirant de ce que j'avais pu lui montrer des méthodes agiles. Ainsi, chaque soir, ses enfants collent sur un calendrier mural, une pastille de couleur : verte = ma journée a été bonne, orange = ma journée a été mitigée, rouge = ma journée a été mauvaise. Et le papa voit vite les périodes difficiles, durant lesquelles il doit porter une attention particulière, et poser les bonnes questions.
Quelle bonne idée !

Alors toutes ces personnes qui se disent agiles, le sont-elles ?
J'ai eu l'occasion d'en discuter lors de l'Open Space organisé par Agile Nantes au début du mois. Et voici notre conclusion. En un sens, oui ces personnes sont agiles : elles ont su trouver une action concrète pour résoudre des difficultés. Et probablement que ces personnes continueront à se poser la question de ce qui peut être amélioré. Amélioration continue, pragmatisme, c'est aussi cela l'agilité.
Et finalement, mettre l'étiquette "agile" ou non, peu importe... Non ?


Une équipe remarquable au quotidien

Christophe Thibaut (@ToF_ sur twitter) est venu, à l'occasion de l'Agile Tour Nantes 2011, nous présenter sa session "Ni gladiateurs ni bisounours. Une équipe remarquable au quotidien" (vidéo ici, slides ici), et nous a ainsi donné quelques-unes des clefs d'une équipe qui fonctionne.

Je conseille vivement aux personnes qui travaillent en équipes, ou qui sont amenées à accompagner des équipes dans leur travail, de la visionner avec les slides sous les yeux. Ou encore mieux d'aller le voir lors d'une prochaine rencontre agile !

En attendant, voici les grandes lignes.

Avant tout, Christophe nous invite à adopter, pour l'ensemble de ce qu'il présente, la posture suivante :
"Quelque soit ce que nous découvrirons, nous comprenons et croyons vraiment que chacun a fait le meilleur travail possible étant donné ce qu'il savait alors, ses compétences et ses capacités, les ressources disponibles, et la situation" (traduction de la prime directive de Norman Kerth disponible dans son livre référence, Project Retrospective).
Par ailleurs, il nous rappelle qu'une bonne équipe ce n'est pas "d'excellents" équipiers réunis, mais ce sont des équipiers qui fonctionnent bien ensemble.

Les antipatterns : des situations à reconnaître, et dont il faut essayer de sortir. Pour chacun de ses antipatterns, Christophe donne les clefs pour les reconnaître, ce qui renforce ces situations et où cela mène. je vous en cite mes trois préférés :

  • Les vrais programmeurs

Lorsque l'on a affaire à des attitudes un peu macho, du genre "Si c'est dur à programmer, c'est normal, c'est ça le vrai code !".
Où ça mène : produit non maintenable, absence de standards, apprentissage restreint, conflits de personnes latents ou patents.
Les réflexes du coach : revues de code, mise en place de standards, organisation de retro.

  • Les super héros

Quand on entend des choses comme :
"-on a confié le truc à JiPé, il s’en est tiré en deux jours..."
"-on te donne ce challenge parce qu’on sait que tu vas assurer!"
Où ça mène : goulets d’étranglement, conflits de conception, de personnalités.
Les réflexes du coach : binômage, revues de code.

  • Le maillon faible

L'équipe se trouve une ou plusieurs personnes boucs-émissaires, qui servent d'écran aux vrais problèmes. Ce qu'on peut entendre :
"–Ah c’est le code de Roger !
–Qu’est-ce qu’il a le code de Roger ?
–... Je t’offre un café (je vais t'expliquer) ?" (au café, on parlera de Roger, qui ne sera pas là...)
Où ça mène : conflits latents d’équipe, interventions en haut lieu.
Les réflexes du coach : coaching, rétro.

Tous ces antipatterns ont un point commun : ils amènent à des situations d'insécurité personnelle. Christophe nous propose une contre-mesure : la confrontation cruciale. C'est une pratique qui a pour but de résoudre les conflits entre deux personnes, en 3 étapes : travailler sur soi, confronter en sécurité, et passer à l'action. A lire pour approfondir le sujet : la traduction française de BTW Crucial Confrontations.


Au niveau de l'équipe, l'objectif est d'apprendre à se confronter mutuellement.

La question qui se pose alors est de savoir s'il est possible d'imaginer des équipes qui n'aboutissent pas aux antipatterns habituellement observés. Des personnes qui ont travaillé sur ce sujet, ont recensé des protocoles de communication qui permettent à une équipe d'assurer la bande passante de communication maximale.
Pour plus de détail sur ces core protocols : www.mccarthyshow.com

D'autres sujets qui peuvent aider, à creuser :

  • Les accords toltèques
  • La Programmation Neuro Linguistique
  • La communication Non violente

L'objectif à poursuivre : devenir "super agile", c'est-à-dire atteindre un état de confiance au sein de l'équipe (grâce à une large bande passante) qui permette d'être dans l'action coordonnée. L'équipe est alors "dans le flow", elle "avance avec beaucoup d'implicite", elle "arrive à des résultats extraordinaires".

Pour toutes les pratiques présentées, un dernier conseil de Christophe : "commencer par soi pour transmettre".

Merci Christophe !


Devenir PO, c'est changer de paradigme - 5/5

Ce billet est la suite et fin de la série :

Rappel : Devenir PO (product owner) n'est pas anodin. C'est changer sa manière de voir les choses.
Il est intéressant de se pencher sur ce changement, au travers des difficultés éventuellement rencontrées, tout en envisageant quelques pistes d'aides et (pour les 2 dernières bulles du schéma ci-dessous) des propositions de bonnes habitudes à prendre ; le but n'est donc pas ici d'expliquer en détail les activités du product owner (comment réaliser un backlog, qu'est-ce qu'une user story, etc). Si ce sujet vous intéresse, je vous conseille le très bon livre de Claude Aubry : 'Scrum, Le guide pratique de la méthode agile la plus populaire'.

Et pour finir la série, regardons la bulle n°11.

PO_11bullesOrdonnees.JPG

Bulle n°11 : Le PO fait partie d'une équipe

equipe3.JPG Le PO fait partie intégrante de l’équipe. Travailler en équipe est l’un des facteurs de réussite du projet.

Pourtant ça n’est pas ce qui est le plus facile. Kofi Annan le dit très bien lui-même : « Dieu a créé le monde en 7 jours. Mais il a eu la chance de travailler seul… » Si l'on rapproche ceci du fait Kofi Annan a été secrétaire général des Nations Unies pendant 10 ans, on se dit qu'il a peut-être rencontré quelques difficultés.

Travailler en équipe ne s’apprend pas à l’école (peut-être un jour ?), mais il n’est jamais trop tard. C'est donc sur le "terrain" que l'on apprend, et alors, l'aide d'un coach d'équipe peut s'avérer précieuse.

Pour l'heure, je vous propose 5 bonnes habitudes qui aident énormément.

Habitude n°3 : Apporter et demander de l'aide

entraide.jpg Même si développeurs et PO n'ont pas le même métier, ils peuvent bien souvent s'entraider.
Un jour, PO sur un projet, je peinais à rédiger mes tests. Je voyais l'itération suivante approcher, et je sentais que les user stories n'allaient pas être prêtes. L'un des développeurs a rédigé avec moi quelques tests et on a réussi à être prêts pour l'itération suivante. On peut presque toujours trouver un moyen d'aider ou de se faire aider.

Habitude n°4 : Utiliser les qualités de chacun

differences.jpg Chacun a ses points forts ; utilisons-les au maximum. Sur l'un de mes projets, un des développeurs avait un goût particulier pour les "belles" ihm (intuitives, esthétiques). Je lui demandais régulièrement de me donner des idées, et son avis sur les écrans de l'application que nous développions. Un autre développeur de cette même équipe était un "clown", il avait toujours envie de glisser une blague dans la conversation. Il nous a été très utile pour "dégoupiller" certaines tensions.

Habitude n°5 : Chercher les solutions, pas les coupables

solution.jpg Ne serait-ce que parce que cela nous permet de gagner du temps : savoir qui a fait quoi, ça ne nous avance pas toujours. On peut faire un rapprochement avec l'idée évoquée dans un précédent billet : "Il vaut mieux enseigner les vertus que condamner les vices".



Habitude n°6 : Ne pas parler à la place des autres

boucheBarree.JPG D'une part parce que c'est toujours mieux de laisser chacun exprimer ses propres idées. D'autre part à cause du risque de l'effet "téléphone arabe".



Habitude n°7 : Écouter, écouter, écouter

ecouter.jpg Nous avons deux oreilles et une seule bouche...c'est sûrement qu'il faudrait écouter 2 fois plus qu'on ne parle !
"Je sais, ça n’a rien à voir, nous aurions pu aussi avoir, en tant qu'espèce animale, une seule oreille et deux bouches, ou six oreilles et pas de bouche, et avoir toujours cette irrépressible tendance à préférer parler qu'écouter..."
Christophe André

Devenir PO, c'est prendre de nouvelles habitudes

Finalement, devenir PO, c’est en grande partie prendre de nouvelles habitudes.
Et prendre une habitude, n’est pas si simple : comme le définit Stephen Covey dans son livre The 7 Habits of Effective People, une habitude, c’est le point de rencontre de la connaissance, du savoir-faire et du désir. Pour que quelque chose devienne une habitude, il faut réunir ces trois éléments.
Je prendrai l’exemple de la dernière habitude vue ensemble : écouter les autres.
Avoir conscience qu’il faut écouter l’autre c’est déjà très bien. Mais si je ne sais pas comment m’y prendre pour vraiment écouter l’autre, je ne le ferai pas. Il faut donc que je l'apprenne. Mais encore une fois ce n'est pas suffisant.En effet, si je sais qu’il faut écouter l’autre, que je sais comment le faire, tant que je ne veux pas écouter, que je n’en éprouve pas le désir, je n’intégrerai pas cette pratique à mes habitudes.

A force de travailler sur l’acquisition de nouvelles habitudes, nous nous détachons de nos anciens paradigmes. Et nous changeons de lunettes !!

Pour finir, je parle ici du rôle de Product Owner, parce que c’est un changement que j’ai vécu. Mais il semble raisonnable de penser que le changement de paradigme peut s’appliquer aux autres rôles d’une équipe agile !

Références :


Devenir PO, c'est changer de paradigme - 4/5

Ce billet est la suite des 3 précédents :

Rappel : Devenir PO (product owner) n'est pas anodin. C'est changer sa manière de voir les choses.
Il est intéressant de se pencher sur ce changement, au travers des difficultés éventuellement rencontrées, tout en envisageant quelques pistes d'aides et (pour les 2 dernières bulles du schéma ci-dessous) des propositions de bonnes habitudes à prendre ; le but n'est donc pas ici d'expliquer en détail les activités du product owner (comment réaliser un backlog, qu'est-ce qu'une user story, etc). Si ce sujet vous intéresse, je vous conseille le très bon livre de Claude Aubry : 'Scrum, Le guide pratique de la méthode agile la plus populaire'.

Aujourd'hui, intéressons-nous à la bulle n°10 !

PO_11bullesOrdonnees.JPG

Bulle n°10 : Le PO est responsable du succès du projet

Être chef d'orchestre

orchestre.jpg En quoi est-ce nouveau ?
Dans les schémas classiques, une certaine distance existe (du fait entre autre, du temps passé entre la demande et le produit fini, et du champ des possibles incompréhensions du besoin) entre la personne qui a défini le besoin et le produit fini. Et donc une déresponsabilisation. Ne l'avez-vous pas observé ?

Pourquoi le PO est-il responsable du succès du produit (et donc de son échec) ?
Parce qu'il a la vision en tête, et donne donc la direction à suivre au reste de l'équipe. C'est en cela que je compare le PO à un chef d'orchestre. Et bien entendu, "chef d'orchestre" doit être compris ici comme "celui qui donne la direction" et non comme "celui qui commande". Seul le PO a la partition entière en tête. Et son rôle est d’emmener l’équipe de manière à ce que la musique sonne bien. C'est là que se situe la responsabilité du PO dans le résultat du projet.

L'équipe entière est bien entendue responsable du succès ou de l'échec du produit, puisqu'il est le fruit de son travail. La responsabilité du PO n'est pas plus grande, mais différente pour les raisons citées plus haut.

Ce qui peut aider : Assumer cette responsabilité peut être une difficulté en soit. C'est bien connu, il est nettement plus facile d'assumer le fruit de son travail lorsque l'on fait de son mieux, et que l'on se donne les moyens. Obtenir un produit répondant au mieux au besoin est un challenge. Pour moi, se donner les moyens de remporter le challenge, passe par l'acquisition des 2 bonnes habitudes suivantes.

Habitude n°1 : Accueillir favorablement le changement

Il nous rapproche un peu plus du BON produit.

Lorsqu’un changement de programme intervient (changement dans une US, changement de priorité…) :

  • En général, on commence par réagir avec agacement, ou découragement, ou même refus…
  • Je vous conseille d'essayer de garder ces premières réactions dans votre tête, ne pas les exprimer au reste de l’équipe, car cela pourrait les perturber, les démotiver…
  • Revenez ensuite avec recul et discernement sur le sujet, avec en tête l’idée que si ce changement de programme est légitimement demandé, c’est qu’il est nécessaire pour atteindre l’objectif.
  • Dites-vous que c’est finalement une chance : un pas de plus vers le bon produit.
  • Normalement, une fois que l’habitude est acquise, on n’a plus les réactions négatives... Autant d'ondes négatives en moins !

Habitude n°2 : Ne pas avoir peur des problèmes

Leur résolution nous fait avancer un peu plus vers le BON produit.

C’est un peu la même idée que pour la peur des changements :

  • Il faut essayer de mettre de côté tout ce qui est "réactions négatives".
  • Je vous conseille ici de ne pas hésiter à échanger avec d’autres personnes, pour confronter les différents points de vue.
  • Veillez à garder un certain recul, de manière à distinguer les vrais problèmes des faux problèmes.
  • Décidez, avec le reste de l'équipe, d'une action ou d'un plan d'actions à mettre en œuvre (avec échéance, et suivi),
  • Essayez de rester pragmatique on ne peut pas traiter tous les problèmes à la fois.

Accepter les changements et résoudre les problèmes, dans une optique d'amélioration continue, fait que l'on travaille en donnant toutes les chances au projet d'atteindre son but. Le résultat obtenu est le fruit de nos efforts : c'est en cela que nous en sommes complètement responsable.
Bien entendu, ces 2 habitudes sont utiles à l'ensemble des intervenants sur le sujet !

Dans le dernier billet de la série, nous finirons par la bulle 11, et ce sera l'occasion pour moi de proposer 5 bonnes habitudes à prendre, qui me semblent fondamentales lorsque l'on tient le rôle de PO.
A bientôt !


Merci à Roman Pichler, dont le billet "The Product Owner on One Page" m'a inspirée pour le schéma du "PO en 11 bulles".


Devenir PO, c'est changer de paradigme - 3/5

Ce billet est la suite des 2 précédents :

Rappel : Devenir PO (product owner) n'est pas anodin. C'est changer sa manière de voir les choses.
Il est intéressant de se pencher sur ce changement, au travers des difficultés éventuellement rencontrées, tout en envisageant quelques pistes d'aides et (pour les 2 dernières bulles du schéma ci-dessous) des propositions de bonnes habitudes à prendre ; le but n'est donc pas ici d'expliquer en détail les activités du product owner (comment réaliser un backlog, qu'est-ce qu'une user story, etc). Si ce sujet vous intéresse, je vous conseille le très bon livre de Claude Aubry : 'Scrum, Le guide pratique de la méthode agile la plus populaire'.

Pour continuer la série, aujourd'hui nous regardons de plus près les bulles 5, 6 et 7.

PO_11bullesOrdonnees.JPG

Bulle n°5 : Le PO détient et partage la vision produit

Avoir la vision... produit

Antoine de Saint-Exupéry a parfaitement décrit la vision, lorsqu’il a écrit : "Si tu veux construire un bateau, ne rassemble pas tes hommes et femmes pour leur donner des ordres, pour expliquer chaque détail, pour leur dire où trouver chaque chose... Si tu veux construire un bateau, fais naître dans le cœur de tes hommes et femmes le désir de la mer."
vision3.jpg Lorsque l’on a un plan précis de l’endroit où l'on veut aller, il suffit d’une erreur dans le plan, ou d’une incompréhension de celui-ci pour se perdre. Alors qu’avec la notion de direction uniquement, on arrive au but. En effet, tant qu'on est dans la bonne direction, et qu'on avance vers l'objectif, on s'approche de plus en plus du but. Avoir la vision de ce que doit être le produit donne la direction à suivre. Et cette vision est un facteur de motivation très important pour l'équipe. Lorsque l'équipe a la vision en tête, elle sait quel est son objectif, son "challenge".
Il y a plusieurs difficultés concernant la vision :

  • La première c’est de la définir,
  • La seconde c’est de réussir à la partager,
  • Et la troisième c’est de réussir à garder suffisamment de recul tout au long du projet pour ne pas l’oublier, bien que, en tant que PO, l’on soit plongé avec l’équipe dans le quotidien.

Ce qui peut aider :

  • Pour la définir, il existe des outils sur lesquels s’appuyer (Document de vision, Jeu du Product box, Vision du produit en mindmap...).
  • Pour la partager, je vous proposerais de la formuler de différentes manières, et la rappeler à l'équipe dès que l’occasion se présente (aux bilans d’itération par exemple).
  • Quant à la difficulté de ne pas la perdre de vue, je vous proposerais de vous créer de petits rituels personnels. Comme par exemple, avant chaque préparation d’itération, se la rappeler. Et vérifier qu’elle est toujours bonne, en la confrontant régulièrement à d’autres acteurs.

Bulles n°6 et 7 : Le PO ne change rien durant l'itération, et accepte ou refuse le travail réalisé

Suivre les règles du jeu

regles1.jpg Le fonctionnement en mode agile (même s’il diffère d’une organisation à l’autre) demande de la rigueur de la part de tout le monde. Il existe notamment deux règles particulièrement importantes. La première est le fait de ne rien changer durant l’itération. Et cela malgré une grande tentation parfois. La seconde est la responsabilité d'accepter ou refuser, clairement, au moment de la démonstration du produit en fin d’itération, les fonctionnalités présentées. Ces 2 points sont fondamentaux.

Ce qui peut aider :

  • Se faire une affiche avec les règles du jeu. Souvent, les développeurs ont les-leurs, pourquoi pas les PO ?
  • Le ScrumMaster !! En effet, son rôle est entre autres choses, de s'assurer que l'équipe respecte les principes de fonctionnement qu'elle s'est définis.

Bulles n°8 et 9 : Le PO collabore avec les parties prenantes et communique à l'extérieur, promeut le projet

Représenter, à l'extétieur

Que l'on soit en mode agile ou non, ces activités restent les mêmes.

La prochaine fois, nous aborderons la bulle 10, et ce sera l'occasion pour moi de proposer 2 bonnes habitudes à prendre, qui me semblent fondamentales lorsque l'on tient le rôle de PO.
A bientôt !


Merci à Roman Pichler, dont le billet "The Product Owner on One Page" m'a inspirée pour le schéma du "PO en 11 bulles".


Devenir PO, c'est changer de paradigme - 2/5

Ce billet est la suite de celui-ci.

Devenir PO (product owner) n'est pas anodin. C'est changer sa manière de voir les choses.
Il est intéressant de se pencher sur ce changement, au travers des difficultés éventuellement rencontrées, tout en envisageant quelques pistes d'aides et (pour les 2 dernières bulles du schéma ci-dessous) des propositions de bonnes habitudes à prendre ; le but n'est donc pas ici d'expliquer en détail les activités du product owner (comment réaliser un backlog, qu'est-ce qu'une user story, etc). Si ce sujet vous intéresse, je vous conseille le très bon livre de Claude Aubry : 'Scrum, Le guide pratique de la méthode agile la plus populaire'.

Aujourd'hui je vous propose de regarder de plus près les 4 premières bulles du "Product Owner en 11 bulles".

PO_11bullesOrdonnees.JPG

Bulles n°1, 2 et 3 : Le PO crée et maintient le backlog produit - planifie les releases et gère la roadmap - rédige les user stories et les tests d'acceptations

Changer de pratiques, d'outils

outil3.jpg L'agilité, c'est avant tout des valeurs, et des principes. Mais ceux-ci se traduisent par des pratiques - adaptées à chaque contexte - et l'utilisation d'outils.
Scrum préconise ainsi au PO de créer et gérer le backlog produit (bulle n°1), de planifier les releases (bulle n°2), de décrire les user stories (bulle n°3). Ce sont de nouvelles façons de décrire le besoin et de planifier le projet. Ce n’est pas "juste" de la mise en forme différente : ces pratiques et outils reflètent une façon d'aborder le besoin différemment. Et il ne faut pas négliger la difficulté que cela peut représenter d'appréhender ces nouvelles pratiques. Cela peut déstabiliser tout le monde de changer sa façon de travailler, et cela d’autant plus lorsque cela fait longtemps que l’on travaillait d'une manière différente.

Ce qui peut aider :
Ces nouvelles pratiques et outils méritent un apprentissage, que l'on pourra trouver dans :

  • Une formation initiale "spécifique PO",
  • Un accompagnement par un PO confirmé (et pédagogue, tant qu'à faire ;)) ou un coach agile (au moins pour l’initialisation et les premières itérations).

Bulle n°4 : Le PO priorise et re-priorise le backlog produit

Apprivoiser la valeur métier

valeur3.JPG En mode agile, on commence par réaliser ce qui a le plus de "valeur métier" : ce qui apporte le plus aux utilisateurs. Schématiquement, en méthode classique, on décrit l’ensemble du produit, et on essaie de le réaliser entièrement (dans l'illustration, le gros rocher sur le dos du bonhomme fatigué). En méthode agile, on « casse » le rocher, et on en recueille ce qui a le plus de valeur (les pépites d’or, dans l'illustration). Mais pour cela il faut réussir à les repérer ! C’est en cela qu'est utile la valeur métier. Pour savoir ce qui apporte le plus de valeur métier parmi tous les items du backlog, il faut attribuer une note à chaque item et ainsi "prioriser" le backlog.
Il s'agit encore une fois d'une nouvelle pratique, qui nécessite de bien appréhender ce qu'est la valeur métier, dans son propre contexte.

Ce qui peut aider :

  • Tout d'abord, commencer par prendre conscience de ce qu'est la notion de valeur métier, en faisant par exemple un Business Value Game,
  • Ensuite, dans la mesure où la valeur métier a un sens différent d'un contexte à l'autre (ce qui est important pour le client X ne l'est pas forcément pour le client Y), il est bon de définir le modèle de l’entreprise (grille et pondération = tamis), et s’assurer qu’elle est en cohérence avec la stratégie d’entreprise.
  • Il est important de revoir régulièrement la grille, d'autant plus dans un contexte "changeant".
  • Une fois que l'on a cette "grille" (qui peut parfois être très simple) il s'agit de noter les items du backlog ! Pour cela, il est beaucoup plus facile de travailler de manière relative, plutôt qu’absolue.
  • Le PO a tout intérêt à se faire aider : il lui faudra alors organiser des ateliers de priorisation avec des intervenants bien choisis (d’autres utilisateurs, la direction, le marketing…). Il existe d'ailleurs un jeu, qui peut aider : le priority poker (je ne l'ai pas encore testé, mais j'y compte bien).


La prochaine fois, nous aborderons les bulles 5, 6 & 7.
A bientôt !


Merci à Roman Pichler, dont le billet "The Product Owner on One Page" m'a inspirée pour le schéma du "PO en 11 bulles".


Devenir PO, c'est changer de paradigme - 1/5

Devenir PO (Product Owner), c’est un changement « multi-facettes » : c’est changer d’outils, de pratiques, de méthodes… c’est aussi - et surtout - changer sa façon de voir les choses.
C'est en cela que s'opère chez la personne qui devient PO, me semble-t-il, un changement de paradigme. Et c'est cette idée que je souhaite développer dans les jours à venir au travers de 5 billets :

  • Aujourd'hui : qu'est ce qu'un paradigme,
  • Bulles 1 à 4 du dessin ci-dessous : difficultés et aides
  • Bulles 5 à 9 : difficultés et aides
  • Bulle 10 : difficultés et 2 bonnes habitudes à prendre
  • Bulle 11 : difficultés et 5 bonnes habitudes à prendre

PO_11bullesOrdonnees.JPG

Paradigme et Changement de paradigme

Qu'est-ce qu'un paradigme ?

C'est une façon de voir les choses, conditionnée par le vécu, la culture, etc. de chacun. On peut représenter un paradigme par une paire de lunettes, au travers desquelles on voit le monde. lunettes.jpg Et il existe un nombre infini de façons de voir le monde. De paires de lunettes.

Mais alors, un changement de paradigme, c'est...

... Changer de lunettes, oui ! Changer de paradigme, c’est voir une même réalité différemment.
La réalité dont il est question ici, ce sont les projets de réalisation de produit logiciel. Et que l'on soit en méthode classique ou en mode agile, l'objectif d'un tel projet reste le même : réaliser le produit répondant au mieux au besoin (représenté dans l'illustration par le petit drapeau). Plaçons-nous dans l'hypothèse où le PO en devenir (le bonhomme souriant de l'illustration) est un utilisateur, le client, ou un assistant à maîtrise d'ouvrage (AMOA). Cette personne connaît le besoin, doit le décrire et sait effectuer ce travail de manière 'classique' (non agile).

realiteChangePas.jpg

Si l'objectif reste le même, c’est la façon de voir le chemin à parcourir pour atteindre celui-ci qui va changer. Le PO en devenir va probablement changer de lunettes. realite1.jpg Ce changement s'explique bien entendu par le fait que les spécifications ne s'effectuent plus tout à fait de la même manière, que le reporting n'est plus tout à fait le même.

Mais ce n’est pas tout. Le futur PO doit envisager son rôle dans le projet différemment. Ses relations aux autres différemment. Son engagement différemment.

En épousant, comme le reste de l'équipe, les principes et les valeurs de l'agilité.

Le schéma du "Product Owner en 11 bulles" représente le rôle du PO. Je vous propose, dans les billets à venir, de parcourir ces bulles, d'aborder les difficultés auxquelles un PO en devenir sera confronté, et d'évoquer les aides sur lesquelles il est possible de s'appuyer. Ce sera l'occasion de comprendre en quoi devenir PO c'est changer de paradigme.

A venir, donc :
11 bulles, les difficultés auxquelles se préparer via des propositions d'aide et surtout 7 bonnes habitudes à prendre.

A bientôt !!


Merci à Roman Pichler, dont le billet "The Product Owner on One Page" m'a inspirée pour le schéma du "PO en 11 bulles".


Agile Tour Nantes : petit bilan

AGT 2011

Agile Tour à Nantes, c'était hier. Et c'était une bien belle journée.



J'ai juste envie de dire en vrac ce qui m'a plu :

  • Le venue de Christophe Thibaut. Le revoir et échanger avec lui a été ma petite pépite d'or de la journée. J'ai beaucoup aimé sa session (on a ri, on a appris, on a envie d'aller plus loin) et je suis loin d'être la seule.
  • L'atelier de Dominic Williams. Pour apprendre à "créer du lien horizontal". Déstabilisant (il a quand même fallu que je dise à 2 inconnus ce qui m'empêche de dormir la nuit...) et efficace. Clin d'oeil à Arnaud et Nicolas, mes co-équipiers. Juste un mot : encore !
  • L'un des deux inconnus ne l'est pas resté longtemps : Arnaud Bailly. Enchantée !
  • La key note de Rémy Genin, qui a donné le ton de la journée : l'homme (et la femme) au centre.
  • Le soutien des uns et des autres lorsqu'un vague sentiment de stress est monté avant ma session : merci Arnaud, Sébastien, etc.
  • La venue (surprise parfois) d'amis : Thomas, Pascale & Hubert, Olivier...
  • Le rencontre de Dominique : vive Agile Vannes !

Vous l'aurez compris, ce qui m'intéresse, c'est les gens ! Et à ce niveau, c'était top !! Merci à tous les intervenants, organisateurs et participants.

A l'année prochaine, ou avant, lors d'une session à l'association Agile Nantes !?


Mon petit âne

Mon petit âne

On le voit partout, c'est la rentrée !!! C'est le top signal pour un certain nombre d'entre nous : on recommence à poster.

Mais moi, j'ai un petit âne dans la tête. Il s'est installé cet été, et il refuse d'avancer. On commence à bien se connaître d'ailleurs. Je vais songer à lui donner un nom. Pompon ? Comme tout âne qui se respecte, il attend sa carotte. Donc maintenant... je cherche la carotte.

A part ça quelques nouvelles, dans le désordre :

  • Agile Tour Nantes, un beau programme en préparation ! Il sera très prochainement publié sur le site d'Agile Nantes,
  • A venir, un billet sur les juristes qui s'intéressent de près à l'agilité,
  • A venir également, un mot sur l'excellent essai de Frédéric Lenoir, "Petit traité de vie intérieure".

A très bientôt.


Jamais sans ma liste

to-do-list.jpg

J'aime beaucoup observer les petites coïncidences de la vie.

J'avais ce billet au sujet de l'organisation personnelle en préparation, lorsqu'au cours d'un dîner un ami me dit : "Je crois que ma femme est en train de péter un câble. Elle a 10 milliards de choses en tête, tout le temps. A tel point qu'elle en rêve la nuit et ça la réveille !". Je comprends tellement bien cette situation...

Je l'ai vécue il y a un an, lorsque j'avais beaucoup de choses à gérer en même temps. Je me suis mise à faire des listes. J'en ai toujours utilisé au boulot (mes To Do List), et aussi pour les courses, je suppose comme tout le monde. Mais là, c'est devenu nécessaire pour moi, pour lister tout ce que j'avais en tête.

A tel point que j'ai eu droit un jour à une remarque de mon mari genre "Tu exagères avec tes listes, tu en fais pour tout et n'importe quoi !". C'est vrai que j'ai un peu dérapé le jour où j'ai commencé à LUI faire des listes... (j'ai vite arrêté !) :)

Et j'ai gardé cette habitude. Je m'en passerais difficilement, car ça m'aide beaucoup à définir mes priorités, et donc a être plus efficace au quotidien.

Alors quand je me suis rendue compte que quelqu'un en avait fait une méthode d'organisation personnelle, ou plus exactement une méthode de gestion des priorités quotidiennes... J'ai un peu halluciné.

La méthode c'est GTD : Getting Things Done de David Allen. Elle a droit à sa page Wikipedia. Et voici le retour d'expérience de quelqu'un qui s'y est mis : ici.

Il existe même des outils : Remember the milk.

Moi, je préfère rester avec mon bête papier-crayon, et ma méthode de priorisation bien perso. Mais si ça peut aider des gens tout perdus, pourquoi pas ?

Quoiqu'il en soit, ma prochaine liste à tester : la to do less List... Histoire d'être un peu plus "lean" ;)


Perfectionne-moi !

PefectionMe

Le Perfection Game est un outil qui permet de profiter des idées des autres pour améliorer un produit.

Je l'ai découvert au XP day 2009, lors d'un atelier vraiment génial animé par Christophe Thibaut et Raphaël Pierquin. Je continue à l'utiliser régulièrement, par exemple pour améliorer un support de présentation. Pourquoi se priver des idées des autres ?

Comment ça marche ?

Le perfection game commence évidemment par la présentation du produit (n'importe quoi que l'on souhaite perfectionner). Ensuite c'est simple, 3 étapes :

  1. On donne une note de 1 à 10
  2. On dit tout ce qu'on a aimé
  3. On dit tout ce qu'on ferait pour arriver à 10 (et donc ajouter de la valeur).

Il y a quand même quelques "règles du jeu" :

  • La note doit être cohérente avec la valeur que l'on pense pouvoir ajouter :
    • 1 = je peux ajouter presque toute la valeur,
    • 10 = je ne vois pas ce que je pourrais ajouter.
  • Le "perfectionneur" ne fait que des commentaires positifs : ce qu'il a aimé, et ce qu'il ajouterait. Le but n'est pas de dire ce qu'on n'aime pas.
  • Le "perfectionné" est en droit de prendre / ne pas prendre tout ce qu'il veut.



Je présente ce jeu dans mes initiations aux méthodes agiles, en tant qu'outil issu du monde de l'agilité. C'est en fait plus précisément issu des core protocols, de Jim et Michele McCarthy. Il existe même un site dédié : www.perfectiongame.org

Et le perfection game peut même être utilisé en dehors du boulot : Improve your sex life using the perfection game... :)


Avant le Management...

Voici un article passionnant de Mary Poppendieck, traduit par Fabrice Aimetti sur son blog : "Avant qu'il existe un Management".

Pour les gens pressés (mais pas trop quand même, j'ai eu du mal à faire court), voici ce que j'en retiens :

Le Management existe depuis 150 ans tout au plus. Pourtant, les gens ont vécu ensemble pendant des milliers d'années sans manager...

On peut expliquer cela par le fait que les hommes, des êtres sociaux avant tout, savent naturellement s'auto-organiser via :

  • des meneurs qui donnent une direction générale,
  • des obligations mutuelles bien comprises.

La seule condition est que la taille du groupe soit suffisamment petite pour que tous ses membres se connaissent les uns les autres. Cela a été observé dans toutes sortes de communautés, tout autour du monde, et en remontant très loin dans les temps. L'anthropologue Robin Dunbar a évalué, dans sa théorie, la taille limite à 150 personnes.

Lire la suite...


- page 1 de 2