Deepki, des valeurs favorables au changement

Dans le monde du développement logiciel, l’agilité est devenu un terme galvaudé, trop souvent utilisé comme simple wording censé garantir l’innovation et l’abandon des méthodes traditionnelles jugées trop lourdes.

Loin de ce “grand détournement”, les valeurs défendues au sein de Deepki permettent de voir fonctionner l’intelligence collective à travers un logiciel au service de la transition énergétique. Ainsi l’autonomie, l’auto-organisation et la responsabilité des équipes sont défendues au quotidien et font partie de l’A.D.N de tous les Deepkies :

  • l’équipe est autonome car elle comporte en son sein des compétences pluridisciplinaires qui favorisent la collaboration et la créativité au quotidien.

  • l’équipe est auto-organisée car l’autonomie et la synergie entre ses différents membres lui permettent de choisir son mode d’organisation, son processus de fabrication pour atteindre un objectif commun.

  • l’équipe est responsable car, au sein de cet espace de liberté, elle s’engage de façon collective auprès des différentes parties prenantes à livrer ce qu’elle a inscrit dans son périmètre de développement. Cet engagement, loin d’être un carcan, lui permet d’apprendre, d’oser, d’expérimenter et de se tromper.

Et concrètement, qu’est ce que cela donne ?

Dans les lignes qui suivent je vous propose de suivre une de nos équipes de développement, l’équipe Dev Client, qui a décidé d’expérimenter un nouveau mode de fonctionnement avec réussite.

Vis ma vie de Dev Client

Une équipe, des objectifs communs

Au sein de Deepki, l’équipe Dev Client a pour mission d’implémenter notre produit Deepki Ready pour l’ensemble de nos clients. Elle participe donc à la collecte, l’intégration, la fiabilisation de leurs données énergétiques et implémente de nouvelles fonctionnalités pour répondre à leurs besoins spécifiques. Le travail des Dev Clients s’inscrit dans un objectif global d’amélioration et de stabilisation de Deepki Ready afin d’assurer à nos clients un usage optimal de leur application.

Scrum un jour, Scrum toujours ?

L’équipe Dev Client avait l’habitude de travailler en Scrum à l’image des autres équipes de développement. Le framework agile a permis à l’équipe de progresser collectivement, de ritualiser ses process (daily meeting, revue de sprint) et de faire face au nombre croissant de nos clients.

Pourtant, de par son rôle spécifique, l’équipe s’est retrouvée confrontée à plusieurs difficultés :

  • des interventions sur le même produit mais pour des clients différents aux demandes souvent spécifiques.
  • un périmètre de sprint très souvent modifié au cours de l’itération pour faire face aux urgences.
  • des rituels qui perdaient de leur sens :
    • un daily meeting devenu le lieu d’une série de reportings individuels plus qu’un espace d’échanges pour s’organiser collectivement.
    • une absence de véritable retrospective qui ne permettait pas forcément à l’équipe de s’interroger sur les améliorations à apporter dans son organisation.
  • un board gitlab commun à toutes les équipes qui ne permettait pas de visualiser certains process propres à l’équipe.
  • des sprints rarement terminés au vu de la modification systématique du périmètre initial et un burndown chart plus vécu comme une fatalité que comme un outil de pilotage pour l’équipe.
  • un manque de confiance des parties prenantes dans la capacité de l’équipe à délivrer ce sur quoi elle s’était engagée.

Kanban : épisode 1

Notre premier board kanban

Fort de leur capacité à s’auto-organiser, les Dev Clients ont donc organisé une retrospective pour faire remonter l’ensemble des difficultés rencontrées, les prioriser et dégager une piste d’action : l’abandon de Scrum au profit du mode flux pour voir comment ce dernier pouvait répondre à toute ou partie de leurs problèmes. Certains rituels qui semblaient importants aux yeux de l’équipe ont tout de même été conservés :

  • le daily meeting pour pouvoir s’organiser collectivement
  • le point bi mensuel pour faire le bilan de ce qui a été réalisé, préparer la démo mensuelle, partager les métriques de l’équipe et recueillir un feedback global
  • la retrospective désormais ritualisée tous les mois

Très vite, des post-it ont envahi les murs pour donner naissance à un nouveau board physique. Ce dernier devait permettre à l’équipe de pouvoir se saisir facilement des difficultés évoquées plus haut en respectant les principes suivant :

  • visualiser le flux pour collaborer plus efficacement
  • limiter le flux pour arrêter de commencer et commencer à finir
  • réguler le flux pour augmenter la qualité de ce que l’on délivre
  • améliorer le flux pour qu’il réponde aux mieux aux problèmes rencontrés

Cette étape de mise en place d’un nouvel outil a été décisive pour l’équipe : elle a favorisé les interactions entre les développeurs, sollicité la curiosité des autres équipes et permis aux Dev Client d’affirmer leur rôle au sein de Deepki. Dans un prochain article nous détaillerons comment les différents principes du Kanban ont permis de surmonter certains problèmes rencontrés par l’équipe.