Faire de l'innovation dans les équipes agiles, c'est possible !

Introduction

"Faire de l'innovation dans les équipes agile, c'est possible !" est une présentation faite en interne de la DSI de Pôle emploi
auprès des développeurs de Nantes, mais aussi auprès des chefs de projet / product owner.

Le support est disponible ici : en attente publication externe

Cela parait évident mais j’entends souvent des équipes agiles annoncer qu’elles sont sous l’eau, que leurs sprints sont plus que chargés et qu’elles n’ont pas de temps de faire autre chose qui sort de leur périmètre.

A la DSI Pôle emploi, les équipes de fabrication travaillent avec une stack technique fixée par la stratégie d’entreprise, laissant peu de manoeuvre aux développeurs. Durant les sprints, les développeurs vont passer 3 semaines à produire des lignes de code Java et Angular (ou tapestry). Et à la fin du sprint, cela enchaine sur un nouveau sprint de 3 semaines, etc.
Lors des sprint planning et des backlog grooming, les chefs de projet ou product owner n’hésitent pas -et ils ont raison- à charger les sprints avec des user stories pour faire évoluer leur(s) application(s).

Et l’innovation dans tout ça ?

Ce n’est pas forcément des robots tels que Pepper ou des casques de réalité virtuelle, c’est pour les développeurs assurer une veille technologique et permettre de tester de nouveaux langages, des librairies et surtout les mettre en pratique.
La question qu’on peut se poser c’est est-ce que tout le monde doit en faire ? La réponse est “Non” ! Cela ne doit pas une obligation. Permettre aux personnes volontaires de le faire, c’est bien, mais l’imposer n’est pas une bonne idée. Vouloir fouiller une nouvelle techno n’est pas un trait de caractère présent chez tous les développeurs et ne pas l’avoir n’est en rien un reproche.

Quel temps y consacrer ?

ll n’y a pas de timing “parfait”. Toutes les équipes ont des engagements à respecter et les repousser pour y faire de l’innovation pourrait être mal perçus. Imaginez la tête d’un chef de projet ou product owner si la livraison de sa feature est décalée parce que l’équipe a voulu faire des tests sur un sujet qui n’a aucun lien avec le projet … pas top ! Chaque équipe est responsable et le temps à consacrer dans l’innovation varie selon les équipes, selon les sprints, selon la période.

Dans quel(s) but(s) ?

Faire de l’innovation c’est bien mais on peut se demander dans quel(s) but(s) faire de l’innovation ?
Et bien tout d’abord l’innovation permet d’éviter de la dette technique. Une mise à jour de langage ou d’une librairie peut permettre de résoudre un problème. Le changement stratégique de mise à jour de Java en est un bon exemple ! L’innovation permet également de faire une pause dans le travail de tous les jours. Je mentionne plus haut le fait que les développeurs travaillent toujours dans une même stack technique. Cette période d’innovation peut permettre d’aller tester des nouveaux langages, voir les méthodologies de travail suivies à l’extérieur de son entreprise, bref, se changer les idées comme on dit ! Et apprendre de nouvelles choses permet de les partager en les présentant à ses collègues, ou à l’extérieur de son entreprise.

Cas concret : notre équipe

Notre équipe est constituée d’une testeuse agile, d’une proxy PO, de 5 développeurs et d’un tech lead -mon rôle-. J’essaye de prévoir une période d’innovation d’une demi journée par sprint. Cela peut paraitre peu, mais je fais en fonction de l’activité des projets. Lors des sprint planning, nous gardons une marge de manœuvre de 20% de notre capacité à faire pour prévoir des anomalies détectées lors des phases de test, des post mises en production ou autre urgence. Cette période d’innovation peut donc être intégrée dans ces 20% même si rien n’est officialisé.

Une période d’innovation “type”

Une période d’innovation commence généralement par une mélée, afin de prévoir et de partager les objectifs de la séance. Elle se termine par une phase d’échange sur ce qu’on a fait et les éventuelles pistes d’améliorations détectées. Toutes nos actions sont tracées dans un board agile à base de post it, permettant de visualiser les choses à faire, en cours et terminée. Rien d’innovant dans une équipe agile !

Nos réalisations

Depuis 1 an et demi, nous avons réussi à récupérer une VM en tant que root et d’y installer plusieurs microservices conteneurisés sous Docker et développés avec différentes technos : python, go, Kotlin, Angular, Vuejs, React, GraphQL, Mongo, Postgre.
Plusieurs restitutions ont été faites auprès des équipes de développement de la DSI, que ce soit en format court de 15 minutes -Quicky-, en format 1h ou 4h en mode Code lab. Une communication via Mattermost permet également en interne d’échanger quotidiennement sur l’actualité, alimentant notre “backlog” d’innovation.

Le ressenti de tout ça ?

Le ressenti dans l’équipe est plus que positif. En plus d’avoir mis le nez dans des technologies inutilisées à Pôle emploi, nous avons pu les tester, voir comment nous pouvons les intégrer à Pôle emploi et les partager avec les architectes et urbanistes.
Une dizaine d’API sont désormais disponibles, nous les utilisons au quotidien pour suivre nos livraisons, préparer nos démos et nos fins de sprint. Un réel gain de temps pour l’équipe tout en découvrant de nouvelles technos ! Un concept à conserver et à présenter dans les autres équipes !