OpenStack Summit Austin 2016

Le prochain sommet OpenStack se déroulera à Austin dans moins de 70 jours.

Vous pouvez dés à présent voter pour que vos sessions favorites soient inscrites sur le programme en suivant ce lien.

Pour ma part, j’ai proposé 2 sessions : la première parlera de ce que la science du bonheur peut apporter dans la transformation d’OpenStack et pour la seconde, nous proposons avec Mark McLoughlin d’étudier comment les organisations peuvent améliorer l’impact de leurs contributions en s’inspirant des pratiques, principes et valeurs utilisées par des projets opensource et des projets agile.

Pour voter pour ces sessions :

La cloture du vote est planifiée au 17 février à 11:59 PST

Merci pour votre soutien !

Agile Bordeaux

Le premier meetup Agile Bordeaux s’est déroulé hier, mardi 12 janvier, au Bac à Sable, un nouvel espace de coworking à Bordeaux

Après un mot de bienvenue de Xabina Carreau qui nous accueillait dans ce lieu très agréable. Nous avons enchainé rapidement en présentant les prochains rendez-vous du groupe :

Nous avons ensuite élargi à d’autres événements pouvant intéresser les participants, comme Agile Open France, la semaine prochaine et le meetup Lean Startup Bordeaux le 28 janvier.

Suivant une tradition maintenant bien établie, nous avons ouvert par la session de présentation en 5 minutes, pour laquelle j’avais préparé un « agile en 5 minutes ». Merci pour la vidéo Isabel 🙂

Le groupe s’est ensuite réparti sur 2 activités en parallèle :

2016-01-12 18.20.12La scierie à pratique par Chris Deniaud

3 équipes ont échangées autour des pratiques agiles grâce à cet atelier créé par Pablo Pernot et Stéphane Langlois en s’essayant à une approche de recherche de consentement. Et ils ont tous terminés en choisissant la rétrospective comme pratique qu’ils garderaient (le jeu est bien sûr sur le wiki Agile Games France).

2016-01-12 18.36.33No Scrum, No Win? par Olivier Picaud et Olivier Patou

C’était une session de rattrapage pour ceux qui auraient voulu la suivre mais n’ont pas pu…lors de l’Agile Tour Bordeaux 2015 – Scrum est simple à comprendre et difficile à comprendre. Nous sommes à la recherche d’un Mindset agile afin de traquer nos anti-patterns agile/scrum.

Nous avons ensuite continué la discussion autour d’un verre de vin. J’avais oublié de l’annoncer, mais suffisamment de participants ont pensé à amener le nécessaire ! Bravo et Merci !

2016-01-12 20.29.22Un bel évènement apprécié par les participants comme le laisse entendre le graphique Fun / Valeur 🙂

Vous pouvez bien sur contribuer au programme du prochain meetup qui aura lieu le 29 mars directement dans ce document.

DATFlock2015, licornes, équipes distribuées et mauvais agile

J’étais à Berlin pour 2 jours pour participer à #DATFlock2015 la conférence pour discuter, apprendre, partager autour des équipes agiles distribuées.

Le programme était un mélange de sessions open space et d’ateliers préparés à l’avance.

OKR, Retours et Récompenses

2 sessions m’ont été particulièrement utiles :

  • How to use OKR?
  • Fearless feedback and fair reward

Deux sessions proposées par Petra Liesmons et Kitty Iding, que je remercie au passage ! Les sujets et l’approche retenue pour les couvrir confirment le travail que je mène actuellement pour implémenter ces idées avec certaines équipes.

De la session OKR, je retiens :

  • Quelques améliorations dans la façon d’expliquer les OKR, spécialement la différence entre résultats clés et actions. C’est un aspect important, car les personnes tendent à proposer des résultats clés qui sont en réalités des actions, pour de pas si bonnes raisons. Par exemple : parce que le travail est fait aujourd’hui, parce que c’est important mais pas connecté à un OKR existant… Ce dernier point devrait être un bon signal, soit pour arrêter de faire cette action, soit pour reconsidérer les OKR définis précédemment.
  • Un autre point important, qui est souvent sujet à discussion est que les OKRs ne se cascadent pas depuis ceux de l’entreprise jusqu’à ceux de l’équipe. Il y a des objectifs et résultats clés au niveau de l’entreprise. Ils vont servir aux équipes à prendre leurs décisions et à définir leurs objectifs et résultats clés. Une équipe pouvant contribuer à tout ou partie des objectifs et résultats clés de l’entreprise
  • Les résultats clés doivent être difficiles mais pas impossibles. Ils montrent l’ambition que l’on a. Ce qui signifie que l’on doit changer l’habitude de vouloir atteindre les objectif à 100%. Une habitude qui tend à réduire l’ambition pour être sur de dépasser l’objectif.
  • Un comportement d’autant plus vrai si les objectifs sont associés à la rétribution. Donc les OKR ne doivent pas être connectés aux récompenses.
  • Les résultats clés représentent le succès, l’impact, le comportement que l’on veut induire dans l’entreprise.
  • Les OKR ne sont pas une approche venant de la direction de l’entreprise vers les employés. C’est une approche devant impliquer tout le monde dans la définition et l’évaluation, suivant une périodicité définie. Par exemple : chaque année pour la définition des OKR de l’entreprise, chaque trimestre pour reconsidérer ceux de l’équipe, et sur une base hebdomadaire pour l’évaluation par chaque équipe.
  • Les OKR sont publics dans l’entreprise, et un temps doit être consacré à l’alignement des OKR entre les équipes.
  • Il est probablement nécessaire d’avoir des indicateurs permettant d’identifier les effets de bords générés par les OKR sur les équipes, l’index de bonheur des équipiers peut-être un de ceux là.

 

2015-11-20 12.49.57De la session sur les retours et récompenses, je retiens :

  • Pour recevoir des retours clairs de la part de l’équipe, il est nécessaire de clarifier les attendus, et donc de définir les rôles en fonction de l’organisation de l’entreprise.
  • Un modèle que l’on peut utiliser pour définir les rôles et responsabilités peut être le modèle de Matti Klasson.
  • L’organisation d’un World Cafe pour définir les différents rôles de l’équipe semble être la façon la plus efficace d’y parvenir. Je vais devoir trouver un moyen d’organiser cela en ligne.
  • L’introduction aux types de personnalités (avec des outils tels qu’Insights, Ensize ou MBTI…) peut être une façon de faire prendre conscience aux personnes qu’elles doivent adapter leur façon de donner du feedback aux personnes à qui ils sont destinés.
  • Une suggestion pour aider les personnes à prendre en compte les feedbacks qu’elles reçoivent est de leur attribuer un coach personnel. Le coach personnel est un volontaire des équipes qui va pouvoir coacher 4 à 5 personnes. Ces coachs seront formés et coachés et formeront une équipe virtuelle de coachs.
  • La partie récompense de la discussion a introduit l’idée de l’évaluation pair à pair, en face à face, de chaque personne en fonction des rôles qu’elle tient. Le coach personnel aidant la personne à étudier ces scores. La personne évaluée est alors seule responsable de définir ces scores. Le manager a accès à tous les scores. Les personnes sont classées en fonction de leur score par rapport au(x) rôle(s) qu’elles tiennent. Ce classement est comparé au classement des rémunérations par rapport au rôle et une adaptation est proposée si nécessaire.

Organisation et Architecture

communication-overheadJ’ai également apprécié la conférence d’ouverture du deuxième jour donnée par Johannes Mainusch. Et particulièrement la façon de montrer la connexion entre la taille de l’équipe, le nombre de relations à maintenir et par conséquence le décroissement de la production de travail possible lorsque on ajoute trop de monde à l’équipe.

La conclusion de l’intervenant était qu’il souhaite des équipes pas trop petite, pour pouvoir faire de la programmation en binôme, et pour pouvoir former de nouvelles équipes par division cellulaires.

L’idée d’avoir des architectes faisant parti de chaque équipe et travaillant ensemble à rendre l’architecture évolutive et à s’assurer que les équipes pluridisciplinaires peuvent être indépendantes.

ElmoEt bien sur, je vais utilisé la technique de facilitation ELMO, qui peut fonctionner avec une équipe distribuée en vidéo conférence. Chaque personne a un papier, il peut y avoir un dessin d’Elmo, et lorsque la conversation traine en longueur, les membres de l’équipe peuvent tendre leur papier pour signifier que l’on doit passer à autre chose. ELMO veut dire Enough Lets Move On.

Un fishbowl (bocal à poisson) a été organisé lors du deuxième jour, et pour lancer la discussion Lisette Sutherland a expliqué pourquoi elle avait invité Yegor Bugayenko, fondateur et directeur technique de Teamed.io. Yegor travaille avec des personnes distribuées à travers le monde, et dit que les activités de team building sont sans intérêts. Qu’il s’agit juste d’un signe de mauvais management essayant de corrompre les personne pour remplacer la discipline par l’amitié.

Il était très intéressant d’avoir un point de vue contradictoire et respectueux dans la conférence. Yegor a expliqué sur son blog l’expérience qu’il a tenté avec les participants de son atelier.

Les idées maitresses : les clients veulent le logiciel et ne sont pas intéressés par l’équipe, et une équipe est moins efficace que des individus bien orchestrés. J’ai un désaccord principal… Mais nous y reviendrons…

Comment le système de Yegor fonctionne-t-il ?

Les projets sont découpés en milliers de tâches de 30 minutes chacune. La tâche est proposée à des développeurs qui peuvent prendre ou laisser. Ils seront payés à la tâche uniquement si ils livrent avec le niveau de qualité escompté. Ils devront garder à l’esprit qu’il s’agit de tâches d’une demi-heure, et donc si par exemple, ils ne comprennent pas la classe qu’ils doivent utiliser en un coup d’œil, c’est qu’elle n’est pas bonne et nécessite d’être refactorée. Et donc, ils doivent créer une nouvelle tâche explicitant ce dont ils ont besoin et mettre la tâche initiale en pause. Une autre personne, avec un rôle d’architecte, elle aussi payée à la tâche, validera si la tâche est réellement nécessaire.

Les risques sont gérés par le nombre. Ils choisissent de mettre 25 développeurs sur un projet qui pourrait en nécessiter 3. Si l’un d’eux échoue à délivrer une tâche d’une demi-heure (petit risque), la tâche sera réassignée à quelqu’un d’autre.

Personnes distribuées et pas équipes distribuées

Ce système ne peut probablement pas fonctionner pour tous. Yegor affirme que beaucoup de personnes veulent travailler avec eux, ils ont donc l’opportunité de choisir. Ils donnent du travail à tout les candidats, au départ sur des projets open source pour évaluer leur comportement, si cela se passe bien, ils se verront attribuer des tâches de projets clients. Si je me souviens correctement des données, 1 sur 20 candidats va rester.

Licornes

Durant le fishbowl, une personne s’est assis sur la chaise vide et a expliqué que les licornes de la silicon valley (des startups avec une valorisation de plus d’1 milliard de dollars) démontraient la validité du modèle d’équipe pluridisciplinaire… La réponse de Yegor a été que 1 ou même 100 exemples de ce type ne suffisait pas pour démontrer le rapport de cause à effet… Combien d’équipe font la même chose sans pour autant parvenir à ces résultats exceptionnels ? C’est un bon point bien sur, nous avons une tendance à interpréter hâtivement des situations en fonction de nos propres croyances…

Désaccord, Créativité et Innovation

Le principal désaccord que j’ai concerne la créativité et l’innovation. Les équipes pluridisciplinaires permettent à différents types de personne de travailler ensemble avec un but partagé. Et des frictions qui naissent de ces différences lors de la collaboration émergent de nouvelles idées géniales. Les pratiques agiles sont conçues pour permettre ces opportunités.

Mauvais Agile

Le problème est qu’avec les mauvaises implémentations des pratiques agiles. Ces équipes qui disent faire de l’agile mais pour qui :

  • Pas de collaboration dans l’équipe (Une story assignée par personne par exemple)
  • Pas de discussion avec le product owner
  • Des Story qui ressemble à des tâches dont on ne connait pas le but
  • Pas de revues avec les clients
  • Pas de découpage des tâches en équipe (ce qui devrait faire émerger des nouvelles idées et des architectures évolutives plus pertinentes)
  • Pas de programmation en binome
  • Revue par un architecte
  • Tests par une équipe d’assurance qualité en dehors de l’équipe

Si l’on combine ces mauvaises pratiques avec un mauvais management, qui ne sait pas ce qui doit être fait, qui change les priorités chaque jour, fixant des objectifs irréalistes etc…

On en vient à cette question de savoir comment implémenter une organisation efficiente pour développer des logiciels et des alertes pour les implémentations partielles sans compréhension des conséquences de certains choix.

 

Un grand merci à Lisette, Lucius et tous les autres contributeurs de cet excellent événement.

A la recherche du bonheur

J’ai eu l’opportunité de donner deux conférences lors des derniers jours. L’une à Raleigh, Caroline du Nord, pour le Red Hat Agile Day le 20 octobre 2015. L’autre à Bordeaux, France, en conférence de clôture du premier jour de l’AgileTour Bordeaux, le 30 octobre 2015.

Les 10 jours qui séparent les deux conférences m’ont permis d’adapter le contenu et le déroulement en fonction des retours que j’avais collectés. Pour ces deux conférences, j’ai choisi de prendre pour base les sessions sur le même thème que j’avais donné en conférence d’ouverture des Drupal Developer Days et à Agile France.


 

Agile

La première phrase du manifeste agile est souvent ignorée.

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire.

En étudiant cette phrase on comprend mieux l’état d’esprit des rédacteurs du manifeste et les notions d’amélioration continue, d’entraide, d’écoute des autres. On voit aussi que cela pourrait s’appliquer à bien d’autres champs que le développement de logiciels. Et bien sur, qu’il n’y a pas de raison de limiter l’application à une équipe. Ce sont les pratiques et les outils proposés par certains cadres limitent l’application au développement de logiciels ou à une équipe.

Culture

La culture est la partie immergée de l’iceberg que l’on ne peut voir en observant une organisation. On ne pourra voir que les outils et les pratiques. La culture est constituée des principes et valeurs qui s’expriment au travers des actions des membres de l’organisation. Lorsque des pratiques ou des outils sont introduits d’un façon qui ne correspond pas à la culture de l’organisation, même si on peut constater une amélioration initiale, les choses reviennent à leur état précédent rapidement.

C’est ce qui fait dire à Peter Druker :

La culture mange la stratégie au petit déjeuner, la technologie au déjeuner, les produits pour diner et ensuite tout ce qu’il reste.

Une entreprise agile

Lors d’une session de travail avec l’équipe dirigeante d’une petite entreprise (ils devaient être une vingtaine à l’époque), nous recherchions quels étaient les principes et les valeurs de l’organisation. L’équipe savait que l’entreprise était appelée à grandir, et elle voulait conserver la créativité et l’innovation qui avait fait son succès. J’ai eu la surprise que lors de la conclusion de la journée le principe central retenu soit :

Le bonheur des employés

Un principe central articulant l’autonomie, la responsabilité, la confiance, la transparence, la communication et une conviction que grandir en étant agile serait la façon d’accomplir cela.

how-do-feelPour savoir si nous allions dans la bonne direction, nous avons mis en place un sondage demandant chaque jour d’évaluer le niveau de bonheur et de laisser un retour écrit sur ce qui motivait principalement ce niveau. Une façon rapide de collecter des retours sur les points d’amélioration, les choses à poursuivre etc…

C’est lors d’une des sessions régulières d’accueil des nouveaux arrivants qu’une question pourtant simple m’a donné l’envie de creuser plus avant le sujet :

Qu’est que le bonheur ?

Une question simple, à laquelle je n’avais pas de réponse. Tout le monde sait ce que c’est, mais je ne pouvais pas le définir. Je me suis donc inscrit au cours sur la science du bonheur de Dacher Keltner et Emiliana Simon-Thomas de l’université de Berkeley. J’en ai appris plus sur ce qu’était le bonheur, sur les différences entre les personnes heureuses et les autres, et surtout sur comment être heureux.

« Le bonheur est le sens et le but de la vie,le principe et la finalité de l’existence humaine »
Aristote

Pourquoi être heureux ?

Les études scientifiques menées par les chercheurs sur le bonheur montrent ce que parfois l’on devine intuitivement. Les personnes heureuses sont plus sociables, sont plus aimées des autres, plus résilientes, se sentent bien, sont plus coopératives, vivent plus longtemps, sont plus productives, plus énergétiques, ont un système immunitaire plus fort, reçoivent plus de soutien de leur entourage, sont de meilleurs leaders et négociateurs, ont un réseau d’amis plus riche, gagnent plus d’argent, sont plus charitables, sont en meilleure santé, se montrent plus flexible et ingénieux pour résoudre des problèmes.

Qu’est-ce qui nous rend heureux ?

circonstances-niveau-initial-activitesLa réponse ne va peut-être pas vous surprendre, ce n’est pas une nouvelle voiture, aussi attrayante soit-elle. Ce genre de circonstance aura bien un effet sur notre niveau de bonheur, et nous retournerons ensuite à notre niveau initial plus ou moins rapidement en fonction de la nature de la circonstance. L’information la plus importante que j’ai pu collecter lorsque j’ai suivi ce cours sur la science du bonheur était que 40% de notre niveau de bonheur dépends de nos activités quotidiennes et pas de nos gènes ou des circonstances. Nous pouvons donc faire le choix d’influer sur notre niveau de bonheur.

Comment ?

Tout d’abord en étant positif. En essayant de regarder les circonstances sous d’autres angles. Et en pratiquant cela dans toutes les situations de notre vie quotidienne, dans nos relations avec les autres.

Optimisme

En étant optimiste, et en consacrant du temps en tant qu’individu et en tant qu’équipe à étudier ce que pourrait être le meilleur futur. En s’attacher à créer les conditions pour que les personnes puissent faire de leur mieux. Un des exercices proposés est par exemple d’écrire un auto-portrait de ce qui pourrait être le meilleur de soi même. En consacrant 10 minutes par jour à l’écriture de ce portrait, et en le raffinant sur une dizaine de jours, vous en apprendrez plus sur vous même et sur ce que vous pouvez faire.

Gratitude

En exprimant sa gratitude, et en créant les conditions pour que les personnes puissent le faire dans vos vies. Dans les organisations, cela peut-être à l’occasion des rétrospectives, ou cela peut se faire en mettant en place des Kudos Box, ou en donnant l’accès à des Wow cards. Cela peut-être aussi en se consacrant à l’écriture d’un journal quotidien, ou en encourageant d’autres à le faire. J’encourage les stagiaires ou les nouveaux arrivants à tenir un journal de leur vie dans une organisation, ce qui leur permet de garder une trace de leurs étonnements et de leurs apprentissages qui leur seront utiles.

Gentillesse

En pratiquant la gentillesse, les lettres de remerciement qui étaient courantes dans le passé, ont presque disparue et cela pourrait être une bonne idée de les remettre au gout du jour. Il y a même des personnes qui ont créé une journée mondiale de la gentillesse (le 13 novembre) pour promouvoir ce comportement.

Pardon

En pardonnant, une pratique plus simple à énoncer qu’à pratiquer lorsque vous êtes dans la situation de celui qui pourrait pardonner. Une pratique qui comme la gratitude ou la gentillesse bénéficient d’avantage aux émetteurs qu’aux destinataires. Et dans le cas de la gratitude ou du pardon, cela fonctionne même si les destinataires sont absents.

Carpe Diem

Profite de l’instant présent est une idée facile à comprendre et plus délicate à pratiquer. J’aborde ici différentes notions celles du flux de Mihaly Csikszentmihalyi qui permet de comprendre ces moments ou l’on constate que le temps a filer et que nous étions incroyablement concentré et efficace, des moments qui surviennent également en équipe et que l’on peut retrouver grace aux vertus de la focalisation et en minimisant les interruptions. J’ai même vu une équipe qui se synchronisait en utilisant des pomodoros pour s’affranchir des interruptions. Comme le recommande Philip Zimbardo le meilleur mix passé, présent, futur serait de vous connecter aux choses positives de votre passé qui vous constitue, de voir dans le futur ce qui vous aidera à déployer vos ailes pour de nouvelles destinations, et l’énergie de profiter du présent pour explorer, vous même, les autres, d’autres lieux…

Célébration

Savourez les petits plaisirs de la vie est une attitude de chaque instant. Célébrer ses propres succès, les succès de l’équipe ou de l’organisation est une activité importante et finalement peu habituelle. De nombreux modes de célébrations peuvent être envisagés comme créer une exposition du travail des équipes comme il est proposé dans Workout de Jurgen Appelo.

But

Célébrer des succès sous entends que vous avez défini des buts. Les multiples études scientifiques sur le sujet démontrent que ces buts doivent correspondre à des motivations intrinsèques et que les incitations extrinsèques comme l’argent par exemple ne fonctionnent pas. Dans la définition de vos buts, préférez des choses qui vous approche de quelque chose, que des buts destinés à vous éloigner de la situation actuelle. C’est pour cette raison que j’apprécie l’approche des OKR (Objectives and Key Results) car la définition des objectifs et des résultats clés est le fruit d’une conversation avec l’ensemble des équipes et non pas quelque chose d’imposé hiérarchiquement. C’est aussi l’opportunité de ne pas regarder les objectifs comme étant atteint ou non, succès ou échecs, mais de considérer que l’on cherche à se diriger dans une direction et que chaque pas dans cette direction est un succès partiel que l’on peut donc célébrer.

Nourrir les relations

Contribuer à un objectif plus grand que soi. Le faire avec des personnes avec lesquelles vous appréciez être. Constituer votre tribu, votre troupe, le groupe avec lequel vous pouvez être connecté, avec lequel vous pouvez partager, apprendre. Votre environnement a une importance importante sur votre capacité à faire. Vous entourez de personnes passionnées est un moteur extraordinaire. Vous pouvez donc être ce moteur pour les personnes qui vous entourent.

Corps et Esprit

« Un esprit sain dans un corps sain. »

Cette citation de Juvenal que l’on répète depuis… Faites pour nous rappeler que nous avons un corps et que lorsque nous en prenons soin cela a une influence sur notre esprit, et que l’inverse est également vrai. Au delà du sport, une activité idéale à pratiquer à plusieurs, avec des relations personnelles ou professionnelles, la méditation est une porte pour avancer sur le chemin du bonheur.

L’équilibre

Le bonheur au travail sous entends que nous pourrions être heureux ou malheureux en fonction de l’endroit ou l’on est. L’idée d’équilibre vie privé, vie professionnelle créé une frontière entre deux mondes ou nous ne seriont pas les mêmes personnes. Peut-être est-il temps de n’être qu’une seule personne pour cette vie, sans devoir afficher un masque professionnel qui nous ferait souffrir et ferait souffrir les autres ? Peut-être est-il temps d’être nous-même heureux dans la vie ? Et peut-être que cela commence par nous et par notre sourire ?

 

Un grand merci pour les retours dont vous m’avez fait part lors des conférences et pour vos messages sur twitter.

 

Quelques références pour aller plus loin :

50 idées rapides pour améliorer vos histoires utilisateurs

Gojko Adzic et David Evans ont débuté une série de livres en utilisant un titre efficace et accrocheur : 50 idées rapides pour

Je n’ai lu que celui à propos des Histoires Utilisateurs (User Stories), mais vous pourriez également être intéressés par ceux à propos des tests ou des rétrospectives.

50quickideasLes illustrations des idées sont excellentes, elles aident à se souvenir des idées elles mêmes.

Même si je connaissais et utilisais déjà certaines des idées proposées, la façon de les expliquer donne parfois une meilleure façon de transmettre le message à une équipe.

La structure de chaque idée est : une courte explication, les bénéfices clés et une partie sur comment faire pour que cela fonctionne.

Les auteurs ont créés également des jeux de cartes avec un contenu similaire (Idée Startup: Je voudrais un jeu de cartes numérique que je pourrais transporter dans mon téléphone mobile 😉 )

Manage it!

Manage it! est un livre de Johanna Rothman édité chez Pragmatic Programmers. Vous connaissez sans doute cet éditeur qui a publié par exemple Agile Retrospectives de Esther Derby et Diana Larsen, ou Agile Coaching de Rachel Davies et Liz Sedley que mon ami Fabrice Aimetti a traduit en français. Si vous ne connaissez par Pragmatic Programmers, je vous recommande d’aller jeter un coup d’œil à leur étagère.

Lorsque j’ai parcouru les premières pages du livre, j’ai été surpris, voir rebuté, par le ton « gestion de projet classique » et finalement c’est ce qui me plait dans cet ouvrage. Pourquoi ? Parce que c’est un ouvrage que vous pouvez faire lire à des chefs de projets, ou des managers habitués aux méthodes et aux environnements traditionnels, sans qu’ils aient l’impression que vous cherchiez à les faire entrer dans une secte.

Alors certes, cet ouvrage n’aborde pas les valeurs et principes qui sont constitutif de la culture d’une organisation, ces valeurs et principes qui peuvent être renforcées ou bousculées par l’adoption de l’ « agile ».

Cet ouvrage aborde la gestion de projet, vue de la fenêtre du chef de projet, du chef de programme, des managers, et parfois des équipiers. Il s’intéresse au démarrage du projet, planifier un projet, il s’intéresse aux cycles relatifs à la vie du projet, à la priorisation, à l’estimation, à la constitution d’équipes, au pilotage, au rythme, aux réunions, au tableau de bord, à la question de la gestion de plusieurs projets en parallèle, des équipes distribuées, à l’intégration des tests, aux programmes et portfolio, et bien sur à la terminaison des projets. J’ai repris ici l’ensemble des chapitres pour vous donner une vue globale de ce à quoi vous pouvez vous attendre. Les recommandations sont simples à comprendre, et l’argumentaire utilisé peut vous être utile pour enrichir votre palette d’arguments.

J’ai particulièrement apprécié la façon d’introduire l’importance de poser des questions utiles comme :

  • à quoi ressemble le succès ?
  • pourquoi ces résultats sont souhaités ?
  • quel est la valeur de cette solution pour vous ?
  • quels problèmes ce système cherche à résoudre ?
  • quels problèmes ce système pourrait créer ?

J’ai apprécié la recommandation et la façon d’introduire des rétrospectives dans les cycles du projet (ainsi que la façon d’insister à ne pas appeler cela post-mortem en fin de projet, en espérant que personne ne soit mort au court de ce projet).

La lecture de l’ouvrage peut-être rapide (je l’ai lu dans l’avion qui me ramenait du Red Hat Tech Exchange) et j’imagine qu’il sera une référence utile lorsque vous êtes prêt à démarrer un nouveau projet, ou à intervenir sur un projet en cours.

Agile France et Le Bonheur au Travail

J’ai eu le plaisir de donner une conférence sur le bonheur lors de l’édition 2015 de la conférence Agile France à Paris. Il s’agissait d’une version raccourcie et en français de la keynote que j’avais donné en ouverture lors des Drupal Developers Days : Happiness is Coming.

J’avais choisi de couper beaucoup de contenu pour pouvoir tenir dans les 25 minutes, et il aurait fallu en couper encore…

Un grand merci pour les feedbacks et les sourires !