Activités, rôles et personnes : une approche pour organiser une équipe projet

par Julien Kirch, le 26 septembre 2017

Est ce qu’un tech lead peut aussi être architecte ?

Est ce qu’un coach agile doit être sur le projet à plein temps ?

Est ce qu’on est encore Agile™ si on a un co-PO ?

J’entends régulièrement ces questions, nottament posées par collègues, pour lesquels il·elle·s aimeraient des réponses toutes faites.

À la place je vous propose une méthode pour vous permettre d’avoir une chance de trouver une réponse qui répondent à vos besoins.

Cette méthode n’est pas forcément à dérouler telle-quelle car elle est un peu fastidieuse, vous pouvez plus simplement vous en inspirer pour répondre ponctuellement à vos problèmes d’organisation.

Déroulement

Il s’agit d’une approche inspirée de programmation par contraintes : définir les contraintes du système, puis itérer pour trouver une solution.

Lister les activités

Listez toutes les activités dont l’équipe doit s’occuper.

Je préfère le mot activité à tâche car il est plus neutre et plus générique.

Définir leurs durées

Pour chaque activité listez la durée estimée qu’il faut y consacrer.

Pour cela placez vous dans un intervalle type qui permette de couvrir toutes les activités de manière représentative, par exemple une itération.

Si vous débutez votre projet et n’avez pas encore de métrique sur lesquelles vous pouvez vous appuyez, servez-vous de vos expériences passées : vous ajusterez ensuite au fur et à mesure.

Il n’y pas besoin de durées précise, mais d’ordres de grandeur permettant de se faire une idée, par exemple : une heure, une demi-journée, une journée…

Certes activités, par exemple "développer", n’ont pas de durée : on peut en faire autant qu’on veut, tant que du temps est disponible. Dans ce cas notez les.

Les spécificités

Pour chaque activité listez ses spécificités, c’est à dire les contraintes qu’elle ajoute sur l’organisation de l’équipe.

Par exemple :

  • toute l’équipe doit être présente

  • la durée est très variable

  • elle est urgente

  • elle est usante …

Comme pour la durée, certaines des spécificités émergeront avec la pratique.

Déterminer qui sait les faire

Pour chaque personne, listez ce qu’il·elle sait faire, indépendamment de son titre.

Exemple

Table 1. Exemple de résultat
Activité Durée Spécificité Cloud Marion Jérôme Stéphanie Zack

Daily meeting

30 minutes par jour

Tout le monde participe

Discussion des US côté métier

un demi ETP par développeur·se

Tout le monde participe

Développement

Tant qu’on veut

Validation des requêtes SQL

Pas longtemps mais ne pas oublier

Support Ember.js auprès de l’équipe de dev

Pas longtemps mais doit être là quand on a besoin de lui·elle

Arbitrage US

Tant qu’on veut

Animations rituels

Variable

Organisation dojo mensuel

1 heure par semaine

Comité d’architecture

4h par semaine

Mardi après-midi

Suivi de production

2h par semaine

Jeudi matin

Suivi budgétaire

2h par semaine

Support utilisateur

Temps à passer variable

Prioritaire sur les autres tâches, usante

Tri nouveau bugs

2h par semaine

À faire tous les 2 jours

Choisir qui fait quoi

Ensuite choisissez qui fait quoi, en tenant compte des différentes contraintes de chaque activité.

Pour cela prenez une feuille par personne et laissez chacun·e choisir ses activités, puis procédez à des ajustements, jusqu’à ce que tout tienne.

Et voilà ! ᕕ( ᐛ )ᕗ

Plus sérieusement, voici quelques éléments pour vous aider :

Astuces

Ne gravez pas dans le marbre

Les estimations que vous ferez seront probablement fausses, et les besoins des projets évoluent.

Il ne faut dont pas prendre le résultat obtenu comme quelque chose de gravé dans le marbre, mais comme une hypothèse pour organiser l’équipe, et qui doit évoluer.

Quand vous voyez qu’une activité est mal couverte, ou qu’un planning devient compliqué à tenir, reprenez l’exercice.

Pas tous les œufs dans le même panier

Essayer de répartir les activités entre les différentes personnes : ne confiez pas toutes les actions importantes à la personne la plus expérimentée car « elle sait faire » : en cas d’absence tout va s’écrouler et les jeunes vont s’ennuyer.

Visez plutôt un recouvrement, en acceptant que pour certaines activités soient moins efficaces le temps que la personne progresse, puis tournez !

Le minimum à viser est qu’il y ait deux personnes en mesure de traiter chaque activité.

Les activités non limitées

Les activité n’ont pas de durée limitée, et elles sont essentielles :

  • elle donnent de l’élasticité (on peut en faire moins sans que ça coince) ;

  • elle permettent d’investir son temps d’une manière qui soit utile à l’équipe.

Idéalement chaque personne devrait avoir au moins une activité de ce type.

Le risque est que quelqu’un dispose de temps libre et nuise à l’équipe en voulant «se rendre utile». L’exemple que j’ai rencontré plusieurs fois est celui d’un Scrum Master s’ennuyant et voulant aider en augmenter le niveau de suivi, et se transformant petit à petit en micromanager.

Toute personne dont le planning n’est pas rempli doit absolument trouver une manière d’occuper son temps libre d’une manière utile, par exemple en intervenant dans deux équipe ou en occupant des activité qui ne collent pas à son titre.

Les activités imprévisibles

L’imprévisibilité d’une activité doit être bien prise en compte car cela peut limiter la capacité des personnes qui s’en occupent à traiter d’autres sujets.

Par exemple :

  • un·e développeur·euse qui s’occupe du support ne sait pas combien de temps il·elle disposera pour développer de nouvelles fonctionnalités, il·elle ne doit pas se mettre sur le chemin critique du projet ;

  • un·e coach qui doit être présent·e avec l’équipe pour pouvoir les faire bénéficier de son aide doit éviter les réunions qui le·a maintiennent éloignée.

Un·e garant·e ou un·e porteur·se ?

Faut-il une personne par activité ?

Pour certaines activités d’expertise, il est tentant d’avoir un·e responsable pour être certain que quelqu’un s’en occupe.

Pour certaines activités, il s’agit d’une fausse bonne idée, par exemple nommer une personne « en charge de la qualité » ne garantira pas la qualité du projet (il·elle ne pourra pas réécrire tout le code tout·e seul·e) et au contraire risque de déresponsabiliser les autres.

Certaines activités doivent donc impérativement être traitées collectivement.

Les activités pénibles et imprévisibles

Les tâches comme le support sont souvent ressenties comme ingrates : traiter des demandes qui doivent être traitées dans l’urgence sur un périmètre sur lequel on n’est pas forcément à l’aise n’est pas du goût de tout le monde.

Pour ne pas pénaliser une personne en particulier, on peut tenter de donner cette responsabilité à l’équipe toute entière. L’inconvénient est que tout le monde est alors dérangé, et qu’il y a un risque de rater des choses.

Ma suggestion est d’avoir un·e porteur·se mais de faire tourner cette responsabilité de manière régulière, en prenant des tours de garde.

Et les titres ?

Vous remarquerez qu’à aucun moment je n’ai parlé de titre mais seulement d’activités.

C’est parce que l' approche consiste à répartir les choses d’une manière qui réponde au mieux aux besoin de l’équipe et de ses membres.

Des questions comme « est-il légitime qu’un architecte SI passe du temps à coder ? » ou « comment faire si on a du travail pour deux PO mais que ma méthode agile dit qu’il ne doit y avoir qu’un seul PO ? » qui sont des questions de statut ou de croyance n’ont pas grand chose à voir là dedans : si l’architecte SI sait coder et que ce qu’il y a de mieux pour l’équipe c’est qu’il·elle passe une partie de son temps à coder, et bien qu’il·elle code !

Sauf que ce n’est pas entièrement vrai : les contraintes de postes et de titres sont importants dans certaines organisations.

Dans ce cas il faut les ajouter aux critères de choix à prendre en compte dans les affectations.

Et si ça ne tient pas ?

Parfois vous ne trouverez pas de solution qui réponde à toutes vos contraintes. Dans ce cas j’ai une mauvaise nouvelle : il n’existe pas de baguette magique.

Les deux seules approches possibles consistent à

  • réduire les contraintes en faisant sauter des activité, ou en distribuant des activité et des responsabilités à des personnes nouvelles ;

  • changer ou ajouter des personnes dans l’équipe.