Accueil / Blog / Métier / 2015 / Agilité et bonheur au travail : retours sur l'Agile Tour de Toulouse

Agilité et bonheur au travail : retours sur l'Agile Tour de Toulouse

Par Virginie Girerd publié 10/12/2015
Makina Corpus nous raconte l'Agile Tour Toulouse #attls 2015.
Agilité et bonheur au travail : retours sur l'Agile Tour de Toulouse

Les 26 et 27 novembre, Makina Corpus était à la Grainerie à Balma à l’occasion de l’Agile Tour Toulouse 2015. Deux journées pour parler Agilité autour du thème du “Bonheur au travail”. Cette année, nos représentants étaient Virginie, Bénédicte et Enguerran qui en ont chacun retiré une expérience différente.

Virginie, chargée de projets

L’agilité n’est pas une méthode. Voici ce que j’ai retenu ;) Longtemps complexée de “ne pas être agile”, j’ai découvert qu’en fait, je l’étais déjà de part quelques pratiques : scrum, réunions hebdos, livraisons itératives…

Mise à part la keynote de Danièle Linhart sur l’évolution de l’organisation du travail, la journée du jeudi, dédiée aux retours d’expérience notamment, n’étaient pas si riches en enseignement ; le forum ouvert en revanche du vendredi oui !

Si j’avais à lister ce que j’ai retenu :

Globalement

  1. L’agilité n’est pas une méthode mais un ensemble de pratiques qui permettent un engagement gagnant-gagnant entre le prestataire et le client ;

  2. L’agilité a des avantages pour le management :

    1. + de temps pour les décision-clés ;
    2. + de temps pour la gestion RH ;
    3. + de recul pour envisager les stratégies produits.
  3. Les estimations “ne servent à rien” : on a plus de résultats en ayant seulement un objectif (atelier sur les robots du vendredi) ⇒ favoriser l’auto-organisation ;

  4. Pour s’entraîner sur les prédictions : https://hypermind.com/hypermind/app.html ;

  5. Dans l’agilité, il n’est pas simple de traiter des tickets de bugs ⇒ mettre en place un moment dédié à son seul traitement ;

  6. Mettre en place des rétrospectives régulièrement ⇒ “innovation games”.

Au niveau de la contractualisation agile

  1. Au Québec, l’agilité est déjà très intégrée ⇒ comment s’y prennent-ils ? peut-on “importer” en France leur façon de faire ?
  2. À chaque sprint, un nouvel engagement (contractualisation sur des épics, points fonctionnels) ;
  3. Vendre du SCRUM, pas de l’agilité ⇒ mieux vendre une pratique plutôt que des valeurs ;
  4. Ne pas insister : si le client n’est pas réceptif et mûr à l’agilité, abandonner le marché ;
  5. Chaque sprint doit inclure une marge de “risque” : 60% de développement/tests unitaires et 40% de tests fonctionnels/correction de bugs/réunions ;
  6. “Éduquer” le client : “si pas de User Stories validées à telle date, nous ne pouvons garantir la disponibilité de l’équipe”.

Pour le Product Owner (P.O.) 

  1. Si petit projet : P.O. = Client ; sinon P.O. interne ;
  2. Proposer de le former (obligatoire, au moins 1 journée) avec de l’accompagnement ;
  3. Engagement écrit sur qui dit quoi à qui, quelle disponibilité doit avoir le P.O. par jour (réunion, démo, rétro, scrum. À noter que pour le scrum, il peut participer mais n’a pas le droit de parler) ;
  4. Signature du résultat par le P.O. suite à la démo du sprint (acceptance) ;
  5. Le PV de recette doit inclure la release réalisée (toutes les User Stories traitées ou une liste de features ; parcours utilisateurs, enchaînements d’actions, …) et faire état idéalement d’une mention “Sans signature de votre part dans les 15 jours, le présent document est considéré comme validé” ⇒ voir les aspects légaux. Il doit être signé par le P.O. et le C.D.P. ;
  6. Le P.O. crée les User Stories : (https://lionelfalk.wordpress.com/2011/03/05/comment-rendre-une-user-story-efficace/). Une User story fermée par le P.O. vaut VALIDATION. C’est lui aussi qui passe les User Stories en “Ready” : cela permet d'ajouter la User Story dans le backlog d'un sprint et d'avoir ainsi une double validation ;
  7. Dans Redmine (ou autre outil plus adapté), seul le P.O. ouvre les demandes (User Stories) ⇒ utiliser les versions.

Pour répondre à des AO qui ne demandent pas de l’agilité… en agilité

  1. Se rappeler que les Clients ont souvent déjà vécu des projets “classiques” ;
  2. Amener le Client à lui faire comprendre qu’il n’a pas bien compris son besoin (quand on peut...)
  3. S’engager sur des points / volume / unités d’œuvre / des tailles ;
  4. Chiffrer toutes les fonctionnalités demandées mais proposer une organisation agile (sans forcément la citer) avec notamment une période d’“incubation” ⇒ sprint 0 ;
  5. Proposer de former toutes les parties prenantes au processus agile (½ journée) ;
  6. Si une nouvelle User Story sort du périmètre de l’AO ⇒ new story :
    1. on en rediscute ⇒ troc : “c’est grand, c’est petit, c’est moyen” ;
    2. échanger des points ou tailles de vêtements (S, M, L, XL…) plutôt que des jours/H.

Au niveau de la documentation projet (documentation technique et spécifications)

  1. Bien cibler le destinataire du message ;
  2. La documentation doit être rédigée/générée depuis les spécifications exécutables (dans le commit, bien indiquer à quelle User Story il fait référence) ⇒ il s’agit ici des User Stories rédigées sur la forme de tests d’acceptance ;
  3. Un seul document : technique + spécifications ;
  4. Pas de cahier des charges : bien démarrer avec les User Stories ;
  5. La documentation doit être chapitrée/structurée avec les dossiers/sous-dossiers du code source.

Bénédicte, expérience utilisateur

Pour ma part, il s’agit de mon premier Agile Tour et cela marque mes premiers pas dans cette communauté. Je crois sincèrement dans les valeurs exprimées par l’Agilité et aborder le thème du bonheur au travail était vraiment très captivant.

La keynote de Danièle Linhart était particulièrement enrichissante car elle a permis de retracer l’évolution de l’organisation du travail depuis Taylor. Elle a ainsi rappelé que l’objectif du taylorisme était de prendre le savoir aux salariés afin que le patronat ait du pouvoir (car le savoir est le pouvoir). Elle a ainsi terminé sa keynote en se demandant si l’agilité n’était pas qu’une évolution de plus de cette organisation du travail ou si cela marquait une rupture avec celle-ci. Mais elle n’a pas encore la réponse ! En tous cas, cette keynote nous a permis d'entamer la première journée de l'Agile Tour en douceur et sans trop de technique…

Le thème du #NoEstimates a fait l’objet de plusieurs présentations ou ateliers, ce sujet intéressant nous rappelle que le contexte du projet influe sur le temps de réalisation d’une User Story et qu’il n’est pas toujours évident de capitaliser sur son expérience tant les projets diffèrent dans leur contexte, le client, les attentes, … Certains ont proposé de mettre en place des mesures comme le temps effectif mis pour réaliser les User Stories afin d’en dégager un modèle prédictif. Pour qu'il soit pertinent, il faudrait déterminer si des variables influent sur le temps mis pour implémenter une User Story.

J’ai également apprécié l’atelier de Frédéric Duffau sur la rétrospective : j'ai retenu qu'il était bon de débuter toute rétrospective avec un esprit positif (en se remémorant tous les petits bonheurs qu'on a pu connaitre lors des 30 jours passés par exemple) et de sortir de la rétrospective avec une tâche bien définie qu’on sera certain de mettre en œuvre par la suite.

Pour la première fois, je découvrais le principe de l’open space et j’ai trouvé l’exercice vraiment stimulant de par l’échange de bonnes pratiques et le partage d’expériences entre participants. En tant qu’UX designer, j’ai été marquée par le fait que peu de participants connaissaient l’UX (eXpérience Utilisateur) ainsi que les principes qui en découlent. Je me rends donc compte qu'un travail d’évangélisation est encore à mener pour expliquer les enjeux de coupler agilité et UX.

Concernant l'organisation de l'Agile Tour, les deux journées étaient ponctuées de petits jeux comme l’évaluation des keynotes, conférences ou ateliers en utilisant des gommettes. Ces jeux ont sûrement apporté une petite touche de bonheur, mais j'ai apprécié l'effort fourni pour engager les participants dans l'évaluation de l’expérience qu'ils ont pu ressentir pendant l’Agile Tour.

Enfin, un des principaux enseignements que j’ai retenu de ces deux jours est le fait que l’agilité est un état d’esprit, une philosophie et qu’il ne suffit pas de mettre en place des pratiques pour être agile. D’après ce que j’ai compris, être Agile est avant tout croire en les valeurs et les principes proposés dans le manifeste Agile.

Enguerran, artisan développeur

C’est mon deuxième Agile Tour et le mot d’ordre est toujours le même : la bienveillance. Bienveillance autour des conférences, des ateliers et de la journée de forums ouverts. J’ai particulièrement apprécié les discours autour du courant #NoEstimates qui revient sur l’inutilité de l’estimation en temps des User Stories pour les développeurs. Lorsqu’on demande à un développeur de nous chiffrer telle ou telle tâche, on lui demande une seule et unique chose : de mentir. En effet, il n’y a aucune possibilité d’anticiper ladite tâche. Contrairement aux tâches manuelles comme la pose du carrelage dans une salle de bains qui fait 13 m², le développement logiciel est un travail intellectuel. Et à l’instar de l’écrivain à qui il est inutile de demander combien de temps il va mettre pour écrire le chapitre 3, demander à un développeur d’estimer le temps nécessaire pour ajouter la fonctionnalité d’ajout d’un nouveau favori est une perte de temps (et d'argent). Ces  sujets ont été repris par Olivier Azeau, Christophe Heral et Riadh Layouni.

L’autre sujet qui m’a beaucoup intéressé a été abordé tout au long de ces deux journées : est-ce que l’Agilité est un outil magique pour tout résoudre ? La sociologue, chercheuse au CNRS, Danièle Linhart a d’ailleurs posé les bases en revenant sur l’organisation du travail et “l’utilisation” des travailleurs depuis Taylor et le taylorisme ; l’Agilité, le lean et toutes ces nouvelles trouvailles du monde du travail sont-ils la solution au bonheur et à l’épanouissement ? Ou ne sont-ils que des illusions qui veulent faire croire au travailleur qu’il est l’objet de toutes les attentions en le plaçant sur une délicate position mélant responsabilisation et plan de carrière ? Luc Pouliquen, responsable du bien-être des travailleurs chez Airbus, a lui aussi déroulé les principes du manifeste Agile pour les confronter aux réalités concrêtes qu’il rencontre dans la mise en œuvre de son travail. Ceci n’est vrai que si l’on oublie les valeurs du manifeste Agile, qui, plus que de simples valeurs en entreprise, représentent des valeurs sociétales et civiques.

Je profite pour lister quelques autres retours :

J'espère que nous serons présents l'année prochaine et que nous pourrons continuer à convaincre les participants à la vie active que les individus et leurs interactions, les logiciels opérationnels, la collaboration avec les clients et l'adaptation au changement sont des valeurs à privilégier pour une meilleure organisation du travail.

ABONNEZ-VOUS À LA NEWSLETTER !
Voir aussi
Retours de l'Agile Tour 2013 à Toulouse 16/10/2013

Résumé des conférences de l'Agile Tour auxquelles Makina Corpus a participé.

Des jeux pour apprendre 20/10/2011

Conseils à nos clients pour maîtriser leurs projets Drupal Conseils à nos clients pour maîtriser leurs projets Drupal 10/12/2015

Vous trouverez dans cet article quelques points de vigilance et quelques conseils quant à la ...

Agilité et télétravail 24/10/2011

Comment pratiquer l'agilité dans une équipe à distance ?

Les outils de gestion de projet : le wireframe open source Pencil Les outils de gestion de projet : le wireframe open source Pencil 13/01/2016

Il existe un nombre important de services en ligne gratuits permettant de créer des wireframes. ...