Quand agilité rime avec surcharge

Depuis maintenant bientôt 2 ans, j’ai, parmi certaines de mes activités, la responsabilité d’une application en développement spécifique (Angular & Spring).

Nous sommes une (très) petite équipe puisque il y a un développeur et moi ! J’ai tout de même souhaité par appétence, et parce que j’y crois, d’utiliser les principes agiles pour gérer le développement de cette application et ai fait du SCRUM “à ma façon”.

Derrière le “à ma façon” il faut voir l’organisation suivante:

• j’ai un client identifié qui sera l’utilisateur de l’application
• j’ai un développeur à plein temps dans la dev team
• je suis le Product Owner (PO) et fait office de peer reviewer pour le code mais ne code pas (presque pas )
• l’équipe gère de manière autonome le rôle de Scrum Master (SM)

Les itérations sont organisées en sprint de 15 jours calendar et contiennent un grooming de backlog avec le dev et une démo au client le dernier jour. Durant le sprint la MEP du sprint précédent est effectuée (pas de déploiement continu donc les durées de MEP sont forcément un peu longues).

Enfin entre chaque sprints je fais un brain storming avec le client et je mets à jour ma backlog.

Je ne sais pas si je fais bien les choses d’où le “à ma façon” du début mais ça a le mérite de fonctionner car très vite l’application a été en production et on a un rythme d’une MEP tous les 1,5 mois à peu près avec à chaque fois un nombre assez important de nouvelles fonctionnalités (et quelques bugs fix ).

Une dernière chose: n’étant pas ma seule activité il se passe plus au moins de temps entre chaque sprint (entre 1 et 3 semaines) afin que je puisse faire les autres tâches inhérentes à mon poste. C’est là aussi la faiblesse de l’exercice car même durant un sprint je ne considère pas que je suis à 100 % dédié mais plutôt entre 80 et 50 (quand ça va mal) %.

Nous attaquons notre dernier sprint dans les semaines qui viennent car l’application arrive à une complétude de fonctionnalités qui satisfait le client et plutôt que d’ajouter pour ajouter nous avons convenu d’arrêter là la partie développement et de passer en MCO.

Et c’est là que je me suis rendu compte que j’étais soulagé d’arrêter le pilotage de ce projet alors que tout s’est bien passé dans une bonne ambiance et qu’au final le produit livré correspond (même dépasse) les attentes.

Mais alors pourquoi ce soulagement ?

Selon moi il y a plusieurs raisons et quoi de mieux qu’un REX pour les identifier !

L’agilité demande beaucoup d’implication

C’est quelque chose que j’avais constaté auprès des équipes qui utilisaient les principes agiles: l’implication que demande cette approche use au fil du temps. Je m’explique, si le SM ou l’équipe arrive à bien s’organiser: l’équipe à toujours quelque chose à faire, en résumé la backlog est toujours alimentée, il y a toujours du dev à faire, des démos, …

Ce qui fait qu’il n’y a jamais vraiment de temps mort, y compris pendant les démos / grooming où si l’équipe ne fait pas sa tâche habituelle (par exemple développer) elle est tout de même sollicité pour le projet.

Pour le PO c’est pareil entre la préparation de la backlog, son raffinement et sa disponibilité pour les développeurs il ne chôme pas ! Dans mon cas on peut se dire que cela va car comme j’ai des pauses entre les sprints je dois normalement avoir moins cette impression de course en avant. Oui et non: oui car effectivement je n’ai pas de “perturbations” liées au sprint (les questions des développeurs par exemple) et non car il faut “rattraper” le temps perdu durant le sprint où je n’ai pas pu faire mes autres activités et il faut tout de même préparer le prochain !

L’implication et donc le fais d’avoir toujours quelque chose à faire avec les sprints qui s’enchaînent explique, je pense, cette forme de lassitude.

Ne pas être dédié

C’est peut être la raison principale, en effet, hormis l’évidence que le switch de contexte est toujours compliqué à vivre, cela entretien aussi une culpabilité / stress permanent d’avoir l’impression que la tâche courante se fait au détriment d’une autre tâche et pour peu que l’on veuille bien faire les choses, cela débouche souvent sur du travail en temps masqué (donc très souvent sur le temps perso …).

Cela semble être une évidence, mais c’est très souvent au début de tous les livres traitant d’agilité: le fait d’être dédié est une condition importante voire essentielle pour le succès d’une équipe organisée selon les principes agiles et lorsque l’on regarde dans la réalité: c’est rarement le cas, notamment par les collègues et managers proches qui peuvent avoir du mal à comprendre que lorsque vous faites partie d’une équipe agile et êtes en plein sprint, même 1 heure à faire autre chose c’est un switch de contexte qui peut avoir de plus lourdes conséquences.

Alors stop ou encore ?

En conclusion: oui, je suis soulagé d’arriver à la fin du projet et je vais pouvoir souffler un peu en termes de rythme et de parallélisation de tâches mais - car il y a un “mais” - j’ai déjà un nouveau projet qui se profile, projet qui concernera plus de la conception d’architecture CI / CD que du développement.

Et devinez quoi? J’ai déjà identifié ma core team, mes clients, prévu quelques ateliers de brainstorming avec eux, des ateliers de raffinement de backlog avec la core team et des itérations courtes pour voir assez vite si on va dans le bon sens ou non !

Je crois que lorsque l’on a goûté à cette façon de fonctionner et que l’on y adhère, il est compliqué de faire autrement. Alors oui on l’adapte mais on y revient.

Si je n’avais qu’un conseil: c’est de rester vigilant sur l’implication et l’émotion que l’on met dans nos projets agiles et d’essayer au plus possible d’être dédié pour éviter le temps masqué (ah ça fait deux conseils ).