27 Jan 2013, 15:01

Des 'Feature Teams' à l'échelle de l'entreprise ?

Il y a quelques mois, le Gartner annonçait qu'en 2014, 25% des dépenses IT seront désormais pilotées par le Marketing. Pourquoi pas, après tout avec l'arrivée des solutions SaaS, même si les expériences actuelles montrent qu'elles sont besoin d'être accompagnées pour tout ce qui tourne autour des problématiques de SLA, Sécurité/Confidentialité, Réversibilité, Import/Export de données, Intégration avec le SI, etc.

Il y a quelques mois, j'ai lu "Scaling Agile @ Spotify" qui met en avant les "Feature Teams".

Pour ceux qui ne connaissent pas les Feature Teams :

  • contrairement aux organisations traditionnelles découpées par technologie/composant/expertise (Les architectes d'un côté, les développeurs d'un autre, etc), la feature team est organisée selon une logique fonctionnelle et en son sein toutes les compétences sont représentées/réunies ; le but étant qu'elle soit autonome et suffisante pour la création de la fonctionnalité dont elle a la charge.
  • En soit, je trouve ça fort pertinent dans la mesure où cela permet de maintenir une cohérence d'ensemble dans le développement de la fonctionnalité mais aussi une implication de l'ensemble de l'équipe projet.

Pour revenir à Spotify, l'intérêt du document est qu'il présente comment cela est implémenté _pour de vrai_ :

  • Niveau 1 - le "Squad" : elle ressemble à une Scrum Team classique avec son Product Owner et l'équipe en mesure d'assurer la fonctionnalité avec l'ensemble des expertises nécessaires. Chaque Squad est en charge d'une fonctionnalité sur le long term (Client Android, Player, etc) et développe une véritable expertise sur le sujet
  • Niveau 2 (en vertical) - la Tribu (Tribe) : c'est un ensemble de Squads qui travaillent sur des sujets connexes, regroupé dans un lieu commun et avec notamment des restitutions sur l'avancement de chaque squad et le partage d'expérience.
  • Niveau 3 (en horizontal) - Le "Chapter" : au sein d'une tribu, chaque "Chapter" regroupe des personnes ayant la même expertise/compétence afin qu'ils puissent s'entraider / partager entre eux : testeurs, développeurs, etc.
  • Niveau 4 (en horizontal et inter-tribus) - la guilde : sur le principe des communautés d'intérêt, elle rassemble toutes les personnes d'une ou plusieurs tribus qui sont intéressées par un sujet donné : les technologies web, la mobilité, etc. Une guilde rassemble par défaut les "chapters" lié au sujet de la guilde mais n'importe qui d'autre peut la rejoindre.

Ce qui se traduit par le schéma suivant :

Feature Teams : Guilde Squad Chapter Tribe

Si le product owner du squd définit le "quoi", on voit bien que le chapter et la guilde travaillent davantage sur le "comment" mais aussi et surtout permettent de partage les expériences, les bonnes pratiques et maintenir une cohérence d'ensemble sur un sujet/métier donné.

Je n'ai pas détaillé ici vu que ce n'est pas le propos mais il y a d'autres choses intéressantes : les "hack days", la pratique du Lean et du Minimum Viable Product, etc, etc etc. Je vous laisse lire les 15 pages en détail.

Pour revenir à notre propos de départ, extrapolons cette organisation de développement logiciel à l'échelle d'une entreprise :

  • Notre Squad pourrait être une équipe en charge d'un produit avec par ex une personne du marketing en tant que product owner. Dans son équipe, il y aurait une personne de la R&D, une personne du juridique, une personne de l'IT, et ainsi de suite avec chaque département requis.
  • La tribu serait assez similaire en regroupant un ensemble de squads travaillant sur des sujets connexes
  • Les chapters permettraient alors de maintenir la cohérence d'ensemble sur un sujet donné pour un profil donné ; si l'on compare avec nos organisations traditionnelles, notre expertise actuelle serait maintenue via les partages au sein des chapters.
  • Les guildes, sur le même principe, regrouperaient les chapters du domaine et toute autre personne intéressée par le sujet.

Du coup, plutôt que de ne voir que le budget partir de la DSI vers le Marketing, c'est un budget et une compétence/expertise qui rejoint une équipe centrée sur un projet donné. On met ainsi également fin aux guerres de chapelles (IT vs Marketing vs ...). Si nos organisations actuelles sont fondées sur un principe de rationalisation (excessive ?), ce mode d'organisation semble vouloir viser l'efficience, en étant à la fois plus agile au sein d'une squad, mais tout en maintenant la cohérence d'ensemble et des règles communes via les chapters et guildes.

Reste à voir si ce modèle est déployable et à quelle vitesse dans nos organisations...

05 Dec 2012, 22:16

Web Giants patterns

Octo, a French consulting company, published on their blog (in Frenh) a series about patternes used by Web Giants (Google, Amazon, etc). Patterns are about organisation, methodology, development and technology. So it not only concerns IT department but can also interest business ones

A few examples :

  • Minimum Viable Product
  • Reccurent Beta
  • Feature flipping
  • Hardware commodity
  • Features teams - see also how it works at Spotify
  • NoSQL data bases
  • DevOps
  • Build vs Buy
  • Pizza teams
  • Cloud first
  • Etc

For each topic, the presentation principles are simple :

  • Pattern definition
  • How web giants use the pattern
  • How can I use the pattern in my firm / department / team

They also published (still in French) a book you can buy or download.

They organised a breakfast some weeks ago to introduced their book and the topic in general, you can watch the video and/or read the minutes. Of course in French

I would strongly recommend French readers to read this serie as it shows in an easy way how traditionnal IT patterns are evolving and what we can learn from such companies.

Definitely a must read for me.