Agile smells – Rôles et motivation

Fin de la série d’articles consacrée aux Agile smells, je vous propose, au travers de situations réellement vécues, de faire un tour d’horizon des dérives, des fausses bonnes idées ou simplement des phrases prononcées qui peuvent vous amener à vous dire que quelque chose sent mauvais. Terminons aujourd’hui en parlant des rôles et de la motivation…

Si vous avez manqué un des épisodes de la série des Agile smells, vous pouvez les retrouver ici :

• Agile smells – Management visuel
• Agile smells – Sprint planning
• Agile smells – Sprint daily stand-up meeting
• Agile smells – Sprint review
• Agile smells – Sprint retrospective
• Agile smells – Backlog et user stories
• Agile smells – Pratiques de développement et de test

« Mais concrètement tu sers à quoi ? »

La situation

Dans une équipe en place depuis neuf mois, une personne ne comprenant pas bien quelle est concrètement l’utilité du Scrum Master, remet ouvertement en question sa présence au sein de l’équipe.

Pourquoi ça sent mauvais ?

Parmi les rôles du framework Scrum, le Scrum Master est certainement celui qui suscite le plus grand nombre d’interrogations. Par sa spécificité, c’est le seul dont le périmètre évolue non seulement d’une équipe à l’autre en fonction du contexte, mais également au sein d’une même équipe en fonction de la vie de cette dernière. Un Scrum Master doit-il être à temps plein sur une équipe ? Doit-il accompagner plusieurs équipes en parallèle ? Doit-il également développer ? Est-il un chef de projet ? Est-il un coach agile ? Mais au final, s’il ne développe pas et qu’il n’écrit pas de spécification, à quoi sert-il ? Ces questions ont souvent traversé l’esprit des personnes évoluant dans un environnement Scrum et pour la plupart il n’existe hélas pas de réponse toute faite.

Cependant, si à un moment donné de la vie d’une équipe, des personnes posent ouvertement ce genre de question, alors un problème est en train d’apparaître : un rôle majeur dans l’équipe n’est pas correctement défini. Cette problématique n’est pas forcément liée au rôle de Scrum Master mais peut toucher n’importe quel rôle. L’une des premières étapes lors de la création d’une équipe est la définition des rôles et de leurs responsabilités. Ce travail va permettre à l’équipe de se structurer en donnant à chacun une place au sein de l’équipe, renforçant ainsi sa légitimité et par conséquent son bien-être. Cela permet également de cadrer un minimum les personnes pour maximiser leur collaboration.

À partir du moment où un rôle est remis en question, une fissure se crée entre l’équipe et la personne concernée. Que ce soit parce que le rôle est mal compris ou parce qu’il n’a pas évolué suffisamment avec l’équipe, ce genre de situation ne peut aboutir qu’à un rejet de la personne par l’équipe via l’apparition de conflits, allant d’un simple trait d’humour jusqu’à la critique frontale, engendrant un climat délétère et un impact non négligeable sur la motivation et la productivité de l’équipe.

Concrètement on fait quoi ?

Revenons au rôle de Scrum Master dont il est question dans notre situation. Scrum définit ce rôle comme le leader au service de l’équipe et énumère toute une série de tâches qui incombent à ce rôle (pour plus d’informations je vous invite à télécharger le guide Scrum). Cette définition du rôle de Scrum Master est valable lors de la formation de l’équipe où elle peut être prise à la lettre, en revanche, avec une équipe expérimentée, le rôle doit évoluer. Si ce n’est pas le cas, la question fatidique de l’utilité du rôle tombera forcément un jour.

Pour éviter ce genre de question, ou pour y amener une réponse si jamais elle a été posée, un exercice en équipe s’impose. Pour être au service de l’équipe, il faut savoir de quels services l’équipe a besoin. Pour ce faire, voici deux exemples d’ateliers qui fonctionnent :

• Build Your Own Scrum Master : demandez à l’équipe ce que devrait faire son Scrum Master idéal, ce qu’il devrait connaître, et comment l’équipe pourrait l’y aider.
• Stop / Start / Continue : demandez à l’équipe ce que doit arrêter, démarrer et continuer de faire le Scrum Master.

Dans un premier temps, le Scrum Master ne s’exprime pas, les équipiers déposent à tour de rôle leurs post-it en expliquant la raison. Lorsque tout le monde s’est exprimé, le Scrum Master peut alors ajouter des éléments. En effet, il se peut que l’équipe n’ait pas toujours pleinement conscience de certains de ses besoins ou de certaines activités gérées actuellement par le Scrum Master.

Le résultat final de ces ateliers est donc un rôle redéfini et accepté par chaque membre de l’équipe. Bien évidemment, ce qui est fait ici pour le Scrum Master est tout à fait envisageable avec chacun des rôles définis dans l’équipe.

Le référent technique

La situation

Sur un projet composé de quatre feature teams et une component team, chaque équipe dispose en son sein d’un rôle de référent technique. Ce rôle contient le périmètre d’activité suivant :

• Choix de la conception et de l’architecture des services développés en amont des itérations en compagnie du responsable technique projet.
• Revues de code.
• Participation à une communauté des référents techniques visant à traiter des sujets techniques transverses.
• Support principal des Product Owners.

Pourquoi ça sent mauvais ?

Lorsqu’une seule personne rassemble autant de responsabilités, cela laisse peu de place à l’équipe de développement pour s’épanouir. En effet, si le référent est le point d’entrée unique de l’équipe, s’il décide seul de la conception et s’il est le seul à participer à des chantiers techniques, le développeur se retrouve restreint à faire du code fonctionnel en suivant des concepts qu’on lui a imposé. En d’autres termes, en n’apprenant rien et sans être autonome dans la manière de faire son travail, aucune chance pour lui d’éprouver la moindre motivation.

Concrètement on fait quoi ?

Des rôles de référent technique ou de leader technique existent souvent dans les organisations. Leur présence est souvent utile lorsqu’il y a plusieurs équipes et qu’une cohésion dans les choix de conception doit être garantie. Ils sont également importants quand un consensus ne peut être trouvé et qu’une décision doit être prise.

En revanche un bon référent est une personne capable d’impliquer le reste de l’équipe dans les décisions :

• Choix de conception ou d’architecture

Réunir toute l’équipe quand il s’agit de choix structurants est le meilleur moyen de faire adhérer tout le monde. Si chacun à la possibilité de s’exprimer et d’exposer ses arguments en amont, il sera alors plus simple de faire évoluer la solution plutôt qu’une fois le choix effectué et en partie mis en place.

• Revue de code

Les revues de code doivent pouvoir être faites par tout le monde. Mieux, le pair programming doit permettre à chacun de partager ses connaissances, et donc au référent de diluer ses connaissances au sein de l’équipe.

• Chantier technique

Les chantiers techniques sont généralement une grande source de motivation pour la plupart des développeurs car ils leur permettent de faire davantage parler leur créativité par rapport au quotidien des user stories. Le réserver à une seule personne est par conséquent le meilleur moyen de créer de la jalousie et de la frustration. Avoir un rôle tournant de personne participant à ce genre de chantier permet d’impliquer tout le monde de la même manière et d’éviter les conflits inutiles.

• Support du Product Owner

Identiquement ici, un rôle tournant de support aux questions du Product Owner peut être mis en place. Que ce soit une question sur la faisabilité ou une brève explication à donner, ceci est un travail de partage qui implique davantage les développeurs et que chacun doit être en mesure de faire.

« Tu peux déjà commencer par lire les SFD le temps que ton ordi arrive… »

La situation

Un nouveau développeur intègre une équipe mise en place depuis plus d’un an. Son matériel de travail n’est pas encore disponible et ses premières journées de présence consiste en la lecture de la documentation projet.

source uneviededev.com

Pourquoi ça sent mauvais ?

Lorsqu’une personne intègre une équipe déjà formée, elle aura une forte tendance au doute, peu importe son niveau de compétence : « J’espère être à la hauteur », « J’espère ne pas me faire virer », « J’espère que les gens sont sympas », « J’espère apprendre des choses », etc. La liste peut être plus ou moins longue en fonction du degré naturel d’anxiété de chacun.

Sur cette base, lorsque l’accueil se résume à lire la documentation papier, les messages envoyés au nouvel équipier sont les suivants :

• Nous n’avons pas vraiment pensé à toi du coup nous n’avons pas de poste de travail pour toi.
• Nous n’avons pas vraiment le temps de nous occuper de toi du coup tu lis la documentation.

Cette première impression altère sérieusement l’aspect « équipe sympa » et son côté bienveillant envers les équipiers.

Ensuite, sur la documentation aussi bien fonctionnelle que technique, la probabilité qu’elle soit obsolète est significative. Ce qui signifie que le nouvel arrivant est en train d’apprendre, seul, des informations qui sont erronées. Son apprentissage en sera par conséquent ralenti et ses mauvaises connaissances viendront alimenter sa peur de ne pas être à la hauteur.

Enfin, lorsque son poste de travail est bien installé, une fausse bonne idée va consister à lui proposer de commencer par la correction de bug sous prétexte que cela le fera directement entrer dans le vif du sujet. Ramasser les ordures laissées par les autres n’a jamais permis d’apprendre à bien manger. Si le bug est complexe, le nouvel arrivant doutera de ses capacités, alimentant ses doutes d’être à la hauteur, et dans tous les cas, cela ne le fera nullement grandir en tant que développeur.

Concrètement on fait quoi ?

L’arrivée d’un nouveau développeur au sein d’une équipe doit être anticipée et préparée :

• Présentation officielle

Hormis les startups de quatre personnes, les futurs collègues du nouvel arrivant ne se résume pas forcément à l’équipe dans laquelle il va travailler. Lui faire faire un tour du propriétaire en le présentant officiellement à tout le monde est le minimum. Ajoutez à ça une annonce plus officielle (simple mail par exemple) et vous serez sûr que tout le monde saura qui est le nouveau venu. Au-delà de l’intégration dans l’équipe, il s’agit ici de l’intégration dans l’organisation.

• Éléments de travail

Il est extrêmement rare qu’une arrivée se fasse du jour au lendemain. C’est pourquoi de nombreuses choses doivent être anticipées comme la création d’un badge d’accès au bâtiment, les comptes utilisateur avec tous les droits nécessaires, l’achat ou la récupération d’un poste de travail. Lorsque le nouvel arrivant arrive dans ces conditions, il observe alors que tout a été prévu pour lui et qu’il fait déjà partie de l’équipe.

• Présentation fonctionnelle

Pour présenter votre produit, oubliez la documentation. Le Product Owner doit pouvoir prendre du temps en tête à tête avec le nouvel arrivant pour lui montrer directement le produit et lui expliquer le but de chaque fonctionnalité en fonction des utilisateurs.

• Présentation technique

Une nouvelle fois, oubliez la documentation. Un membre de l’équipe de développement doit également prendre du temps en tête à tête pour expliquer l’architecture et les choix techniques. Rien de mieux qu’un tableau blanc pour dessiner des schémas qui seront alors bien plus vivants que des schémas déjà posés sur des diapositives.

• Kit du nouvel arrivant

Il n’y a rien de pire que d’être sans arrêt obligé de demander où se trouvent les choses. C’est pourquoi tous les liens régulièrement accédés par l’équipe, doivent être centralisés dans un unique endroit (un wiki par exemple) pour permettre au nouvel arrivant de trouver en toute autonomie de la documentation, des modes opératoires sur l’installation de l’environnement local, les adresses des dépôts, de la plateforme d’intégration continue, des environnements de développement et de production, etc.

• Pair programming

Pour apprendre et pour s’intégrer rapidement, le pair programming est ce qui fonctionne le mieux. Pour guider davantage les développements, une pratique comme le TDD est très utile également. Elle permettra au nouvel arrivant de cibler facilement le code et lui fera découvrir le métier petit à petit avec le support d’un coéquipier en temps réel.

• Rapport d’étonnement

Enfin, quelques semaines après l’arrivée du nouvel arrivant, demandez lui tout ce qui l’a étonné durant cette période, en positif comme en négatif. L’idée étant de faire émerger des actions avec le reste de l’équipe, de les rendre visibles et d’impliquer le nouvel arrivant dans leur résolution. La confiance engrangée par le fait d’avoir en peu de temps participé à l’amélioration de l’équipe ne peut être que bénéfique pour le futur. Attention tout de même au filtre naturel que peuvent s’imposer certaines personnes qui viennent de rejoindre une équipe et qui auraient peur de se faire virer sous prétexte d’avoir été trop négatif. Au préalable, un climat de confiance doit alors avoir été mis en place pour lui permettre d’être le plus honnête possible.

« On n’avait pas déjà un coach agile ? » – « Si si mais il en fallait au moins un de plus là ! »

La situation

Sur un plateau de cinquante personnes distribuées en quatre feature teams fonctionnant en Scrum et en place depuis deux années, un nouveau Coach Agile vient s’ajouter à celui déjà en place afin d’accompagner les équipes à temps complet. Les plus gros problèmes identifiés sont que les testeurs qualifient l’incrément avec une itération de décalage, que les Product Owners écrivent des spécifications généralement trop détaillées ou encore que la base de code est de plus en plus complexe à maintenir.

Pourquoi ça sent mauvais ?

Bien évidemment, toute ressemblance avec un mini-cycle en V est purement fortuite. Ici, les trois problèmes majeurs qui sont présentés dans cette situation nous amènent à nous questionner sur deux rôles qui seront impactés par l’arrivée d’un nouveau Coach :

• le rôle de Scrum Master

Si vous ne voyez chez le Scrum Master que la personne responsable du bon alignement des post-it sur le taskboard, facilitatrice de cérémonies et peut-être même développeuse également, alors la présence continue d’un Coach Agile ne sera pas un problème pour vous. Seulement ce rôle a bien évolué depuis sa création et ses responsabilités sont en réalité bien plus importantes, à tel point que l’on pourrait l’appeler coach d’équipe. La présence trop importante d’un Coach Agile aura alors tendance à réduire le degré d’influence du Scrum Master sur son équipe, diminuant par conséquent la portée de ses actions. En effet, la posture du Coach est, dans l’inconscient collectif, bien plus valorisée que celle du Scrum Master, ce qui a pour conséquence qu’il sera davantage écouté. Si sa présence est trop importante, l’équipe préfèrera alors écouter le Coach plutôt que le Scrum Master et un smell comme le premier de cet article peut vite arriver.

• le rôle de développeur

Lorsque l’on pense à un Coach Agile, on pense souvent à la personne qui va accompagner une organisation dans sa manière de fonctionner, afin d’être plus « agile ». Hors il existe une chose aussi importante que l’organisation et qui a autant besoin d’être agile : le code. Un code qui n’est pas en mesure de s’adapter aux changements facilement sera alors autant pénalisant qu’une mauvaise organisation. En privilégiant la présence d’un Coach Agile qui se concentrera sur les processus organisationnels, il manquera une personne accompagnant les équipes dans leur processus de développement.

Concrètement on fait quoi ?

• Scrum Master vs Coach Agile

À ce jour, il n’existe plus vraiment de différence fondamentale sur la posture que doivent tenir un Coach Agile et un Scrum Master.

Seul le périmètre diffère : le Scrum Master sera focalisé sur son équipe alors que le Coach agira davantage au niveau de l’organisation. Dans l’idéal, le Coach n’interfère pas au niveau de l’équipe, il reste dans un simple rôle d’observateur vis-à-vis d’elle. Et c’est sur ces observations qu’il pourra accompagner le Scrum Master par du conseil, du mentorat ou de la formation pour l’aider à accompagner au mieux l’équipe.

Mais alors comment gérer cette situation sans Coach à temps complet ? La première étape est de mettre en place une communauté de Scrum Masters. Elle aura pour but d’échanger sur les pratiques de chaque équipe afin d’en extraire le meilleur et de converger un maximum sur la manière de fonctionner. Accompagnée par le Coach Agile, cette communauté aura également pour but de trouver des moyens de s’améliorer, comme pour l’intégration des phases de tests dans l’itération en cours. Si les Scrum Masters ne sont pas conscients des problèmes que soulèvent la manière de tester des équipes, le Coach pourra, suite à ses observations, leur donner des conseils.

Il en est de même pour la problématique des spécifications détaillées, où le Coach pourra donner des conseils et éventuellement dispenser une formation ou un atelier pratique aux Product Owners. Dans tous les cas, les Scrum Masters doivent être ceux qui accompagnent les équipes dans ces changements profonds car leur présence en continu est un véritable atout pour en garantir le succès.

• Coach craft

Les problématiques liées à une base de code de plus en plus complexe à maintenir ont de multiples origines. De mauvaises pratiques peuvent en partie expliquer cela, et c’est ici que le rôle de Coach Craft peut être intéressant afin de permettre à l’équipe de développement de se remettre en question sur ses pratiques. Son périmètre peut être varié : pratiques de développement (pair programming, revue de code, kata, dojo, etc.), application de principes de design de code (DDD, SOLID, etc.), pratiques de test (TDD, BDD, stratégie de mock, etc.) ou encore mise en place d’outillage (intégration continue, déploiement continue, etc.). Centré principalement sur le développement, son rôle sera alors le complément technique parfait du Scrum Master dans l’équipe. Si l’équipe possède des profils suffisamment expérimentés et craft, le rôle de Coach Craft permettra d’avoir un œil nouveau sans être forcément immergé dans l’équipe.

« On en a profité pour terminer notre reliquat de user stories »

La situation

Sur un projet composé de six feature teams, afin de mettre en avant le travail des développeurs et de les aider à s’améliorer et améliorer la base de code, une demi-journée leur a été mise à disposition sans contrainte sur le contenu de celle-ci. L’idée étant d’avoir du temps pour traiter des sujets techniques ou effectuer du partage de connaissances. Dans la réalité, ce temps est dédié pour un tiers à finir les user stories non terminées lors de l’itération, pour un autre tiers à faire des refactors techniques, et pour le dernier tiers à se divertir.

Pourquoi ça sent mauvais ?

Allouer un temps libre pour les équipes est une excellente idée : non seulement cela offre un cadre parfait à l’amélioration continue mais cela permet également de mesurer la motivation des personnes. Par conséquent, lorsque ce temps est utilisé à des fins de divertissement, on peut en déduire que la motivation des équipes pour travailler sur le produit n’est pas élevée et que des actions sont à entreprendre. Cette conclusion rapide est généralement vraie mais il est nécessaire de la nuancer :

• lorsque toutes les users stories n’ont pas été terminées durant l’itération, un sentiment de culpabilité couplé à une insistance du Product Owner peuvent pousser l’équipe à vouloir se rattraper et donc utiliser leur temps censé être libre pour faire du fonctionnel.
• lorsqu’une personne est de bonne volonté mais manque d’idée, elle se retrouve dans une impasse. Cette personne aura alors besoin d’un cadre plus précis que simplement avoir une demi-journée de libre.

Concrètement on fait quoi ?

Créer un environnement favorable à la motivation n’est pas aisé. L’idée de libérer une demi-journée est bonne mais selon les personnes ou le contexte, un cadrage est parfois nécessaire. Afin de poser un cadre tout en laissant suffisamment de liberté à chacun, voici un exemple d’activité mise en place et qui a porté ses fruits.

Pour répondre à la question « Que faire durant cette demi-journée ? », un exercice assez simple basé sur des activités liées au Software Craftmanship peut être mis en place. Dans notre exemple, huit activités sont proposées dans chacune des équipes :

1. Club de lecture : lire un livre et le présenter aux autres.
2. Brown Bag Lunch : faire une présentation d’un sujet technique.
3. Table ronde : discuter de divers sujets techniques.
4. Echange de projet : échanger deux personnes entre deux équipes.
5. Revue de code en groupe : organiser une session de revue de code avec tout le monde.
6. Hands-on : faire des ateliers pratiques pour apprendre en codant.
7. Pet projet : réaliser un projet annexe en lien avec le projet actuel.
8. Communauté : organiser des communautés de personnes se réunissant autour de thèmes précis.

Afin de décider rapidement quelle sera l’activité favorite d’une équipe, la méthode du consensus systémique est utilisée. Sans rentrer dans les détails, cette méthode ne se focalise pas sur une majorité d’acceptation mais plutôt sur le moins d’objection possible, évitant ainsi de trop fortes déceptions dans le choix final. Dans les faits, chaque activité est notée entre zéro et dix : zéro signifiant qu’il n’y a aucune objection et dix signifiant qu’il y a un désaccord total.

En faisant le total pour chaque activité, une activité n’obtient aucune objection et est donc sélectionnée : le pet project. Pour organiser de manière ludique des pet projects avec une trentaine de personnes, la première étape est de relever les idées de pet project. La seule contrainte pour les idées : elles doivent de près ou de loin avoir un rapport avec le projet. Un pot commun d’idées est constitué et lorsque un nombre minimum d’idées a été récolté, l’activité est alors lancée durant la première demi-journée de libre de la manière suivante :

1. Création de stands : dans une grande salle, chaque idée est affichée sur un mur de manière à ce que l’ensemble occupe toute la pièce.
2. Pitch : la personne qui avait suggéré l’idée a deux minutes pour la présenter à tout le monde devant son stand et donner envie aux participants de le rejoindre.
3. Conversation : pendant dix minutes les personnes peuvent aller poser des questions aux porteurs d’idées.
4. Choix : les personnes s’inscrivent pour rejoindre le projet auquel elles ont envie de participer.

Une fois les nouvelles équipes créées, les personnes sont libres de s’organiser comme elles le souhaitent, les demi-journées de libres servant alors à faire avancer ces nouveaux projets.

Pour éviter d’avoir des personnes qui continuent de travailler sur des user stories non terminées, un point de synchronisation regroupant tout le monde est mis en place pour démarrer la demi-journée de libre. Servant de bilan d’avancement des pet projects, il permet par la même occasion de déconnecter officiellement les personnes des itérations.

En résumé, cette activité a eu le mérite de :

• faire travailler ensemble des personnes appartenant à des feature teams différentes
• reconnaître les idées des personnes et donner les moyens de les mettre en œuvre
• changer du travail quotidien tout en apportant de la valeur au projet
• laisser les personnes autonomes sur la manière de faire leur travail
• augmenter la motivation : des personnes qui ne faisaient rien de cette fameuse demi-journée se sont senties investies dans un nouveau projet et ont même parfois dégagé du temps personnel pour faire avancer les sujets

Conclusion

Dans cette série d’articles sur les Agile smells, nous nous sommes attachés à regarder des situations dans un contexte précis pour soulever un ou plusieurs problèmes et y répondre de manière concrète. Finalement, que retenir de tout cela ? Simplement qu’une bonne idée dans un certain contexte peut être une mauvaise idée dans un autre contexte. Les frameworks agiles nous mettent à disposition suffisamment d’éléments pour pouvoir s’adapter à n’importe quelle situation, l’idée n’étant pas de les appliquer aveuglément. Remettre en question de manière régulière la manière dont vous travaillez, essayer de nouvelles pratiques et mesurer leur impact sont autant de bonnes choses qui vous permettront d’éviter de tomber dans des smells.