Avant de commencer sur les features team et la mise en place d’une organisation agile à l’echelle, les équipes s’organisent autour de scrum/kanban/scrumban.
Elles arrivent à délivrer de la valeur grâce au modèle suivant :
Certains éléments dépendant des méthodes sont facultatifs, et dans l’ensemble tous sont adaptables (ex : le rôle du scrum master sur Kanban n’existe pas, mais peut être ajouté, ou la notion du sprint qui est le pilier de Scrum peut se transformer en itération sur Kanban).
Dans le modèle ci-dessus nous retrouvons, une agile team composée d’un Product Owner, d’un Scrum Master ainsi que l’équipe de développement. Il y a les cérémonies agiles « Scrum » tel que le Sprint Planning, le Sprint, le Daily Meeting, la démonstration et la rétrospective.
Les artefacts agile sont respectivement le backlog, les User Stories et la Definition of Ready & Done, ainsi que les metrics Burndown Chart & Velocity Chart.
Une seule équipe Agile est par défaut une Feature Team, cette équipe délivre de la valeur business au fil des sprints.
Avant de rentrer dans le détail des Features Teams, nous distinguons deux méthodes pour découper une application et la développer :
- Le découpage par couches technologiques (component team)
- Le découpage par couches fonctionnelles (feature team)
Avec le découpage technologique, plusieurs équipes développent les couches d’une application (Front, Back, Socle…) et sont toutes dépendantes les unes des autres.
Une organisation d’équipe en découpage technologique revient à « siloter » le développement d’une application.
Le passage d’Agile Team en Feature Team
Le fonctionnement en Feature team est basé sur le fonctionnement d’une équipe agile de 3 à 9 personnes (sans compter le Scrum Master et le Product Owner), auto-organisée, pluridisciplinaire, qui est capable de livrer la valeur « business » et de le démontrer à la fin de chaque itération (sprint dans Scrum), rien de différent d’une Agile Team.
La différence s’effectue réellement sur la façon dont on effectue la répartition des équipes.
Dans le modèle Spotify les équipes sont appelées des Squads. Un groupe de plusieurs Squads est une Tribe (Tribu).
Le découpage s’effectue par features (fonctionnalités). Les équipes s’organisent pour délivrer de la valeur par « bloc » de fonctionnalités de l’application.
Pour rentrer un peu plus dans le détail sur comment les équipes fonctionnent, dans le schéma ci-dessus, la même équipe délivre le lecteur de musique pour l’application Web, tablette, iOS et Android…
Ainsi une équipe peut être complètement autonome pour délivrer de la valeur métier.
Conclusion
Le modèle Spotify est réellement une révolution dans le fonctionnement d’équipes agiles pour augmenter l’autonomie des équipes et réduire au maximum le time to market.
Il faut malgré tout faire attention, toutes les organisations qui ont plusieurs équipes ne peuvent pas forcément adopter le modèle des Feature Team comme Spotify.
Une des limites que vous pouvez rencontrer est l’utilisation de technologies/langages de développement trop disparates entre les équipes.
