L’agilité selon Spotify

L’agilité selon Spotify

Nous avons Agile, la méthodologie. Nous avons Scrum, le cadre de travail. Reste à trouver un mode d’organisation qui permette à l’entreprise de mettre tout cela en application.

Le modèle de référence est celui que Spotify a mis en place. On parle d’une mise à l’échelle de l’agilité.  

Chez Spotify, les collaborateurs sont répartis en quatre grands groupes : les Squads, les Chapitres (Chapters), les Tribus (Tribes) et les Guildes (Guild).

Le Squad correspond à l’équipe Scrum. C’est la plus petite des quatre structures (maximum 10 personnes). Elle compte un PO, un Scrum Master et une équipe de développement. Elle est autonome et orientée delivery. Son objectif est d’apporter de la valeur au produit.

Plusieurs Squads sont regroupés dans ce qu’on appelle une Tribe. Ensemble, au sein de la Tribe, les Squads travaillent sur un projet global commun. La Tribe est limitée à maximum 10 Squads et 80 collaborateurs. Elle est généralement suivie par un ou plusieurs Agile Coach. Et est leadée par un Tribe Lead, dont le rôle est s’assurer un alignement.

Chaque collaborateur appartient donc à un Squad, qui appartient lui-même à une Tribe. Mais chaque collaborateur appartient également à un Chapter, en fonction de son domaine de compétence. Les Chapters sont des groupes dédiés au partage de connaissances.

Enfin, il y a les Guildes qui s’apparentent à des communautés de pratiques.

Le modèle Spotify fait aujourd’hui office de référence et a inspiré de nombreuses entreprises.

Certaines réserves sont toutefois soulevées par rapport au fait de transposer ce modèle à l’identique dans d’autres entreprises de la même envergure.

Spotify n’a pas inventé « le modèle Spotify » du jour au lendemain. Celui-ci s’est construit année après année, au fur et à mesure de l’expansion graduelle de l’entreprise, par essai erreur. Il s’est construit AVEC les collaborateurs et en tenant compte de la culture d’entreprise. La tolérance à l’échec par exemple fait quasi partie de l’ADN de Spotify. Est-ce le cas de beaucoup d’entreprises ? Chez Spotify, les Squads sont des sortes de mini startups, totalement autonomes. Les managers sont aussi développeurs, Scrum Master ou autre et ce, afin veiller à toujours rester connectés au réel. Cela en demande du lâcher prise, de l’humilité et de la confiance. Est-ce réellement à la portée de toutes les entreprises ?

Allez, je termine cette note par des mots qui ne sont pas de moi mais que je trouve redoutablement justes : Le « modèle Spotify » a évolué au fil du temps dans une logique d’amélioration continue. C’est donc le résultat d’un processus d’apprentissage mené par les employés et partenaires de Spotify afin de mettre en place une organisation utile pour les aider (et pas votre organisation) à atteindre leurs propres objectifs (et non les vôtres). Vous ne pouvez donc pas copier tout ou partie de ce que Spotify a fait et vous attendre à ce qu’il fonctionne dans votre entreprise. Vous devez mener vos propres expérimentations, garder ce qui fonctionne et continuer à essayer jusqu’à ce que vous optimisiez votre propre modèle organisationnel. Source https://indeed.ailancy.com

Une fois de plus, à voir sur le terrain 😉

Spotify Engineering Culture – part 1 from Spotify Training & Development on Vimeo.

Spotify Engineering Culture – part 2 from Spotify Training & Development on Vimeo.

Empirisme, incrément et itération

Empirisme, incrément et itération

Quand on s’intéresse à la méthodologie Agile et à la méthode Scrum, on découvre des termes savants qu’il est bon de clarifier.

La premier, l’empirisme. On dit de Scrum qu’il est un processus empirique.

En philosophie, l’empirisme s’oppose au rationalisme. Pour les philosophes rationalistes, les idées sont innées. La seule source de connaissance est la raison. Ils défendent la toute-puissance de l’esprit et de la logique.

Pour les partisans de l’empirisme, opposés aux rationalistes, la connaissance n’est pas innée mais dérive de l’expérience. Toute connaissance est acquise a posteriori, par le biais de l’observation et de l’expérience sensible.

Si on applique cette définition à Scrum, on peut affirmer qu’il s’agit d’une méthode de gestion de projet qui privilégie les faits mesurables, l’observation et l’expérience. Plutôt que les plans fictifs (comme c’est le cas dans des projets développés selon la méthode « Waterfall »).

Ce concept d’empirisme se retrouve dans les trois piliers de la méthode Scrum. Rappelez-vous : la transparence, l’inspection et l’adaptation. A la fin de chaque Sprint, on inspecte ce qui a été développé et on l’adapte si nécessaire. Donc, forcément, avec Scrum, on apprend en expérimentant.

Autre terme rébarbatif, beaucoup utilisé en Scrum : l’incrément.

Un incrément est, basiquement, « ce qui vient s’ajouter ». Un ajout, une rallonge si vous préférez.

En Scrum, l’incrément est une partie du produit à délivrer, une étape concrète vers l’objectif final.

L’incrément du produit est composé de tâches appelées User Stories (US). A la fin de chaque sprint, un incrément est délivré par l’équipe Scrum et vient enrichir les incréments délivrés précédemment.

La somme des différents incréments compose le produit à délivrer. Chaque incrément apporte de la valeur au produit final.

Enfin, il y a le concept d’itération. Initialement, je pensais qu’itération et incrément étaient deux synonymes. En fait, non.

« Un processus itératif est un processus dans lequel une série d’opérations est répétée de manière cyclique, avec l’intention de se rapprocher de plus en plus d’un certain résultat désiré. »

Donc, Scrum est un processus itératif vu qu’il fonctionne par cycles courts de développement, appelés sprints. Et ce qui est produit à la fin de chaque de ces cycles (sprints) est appelé un incrément, à savoir une partie du produit final. Par ce fait, Scrum est également un processus incrémental vu qu’il préconise une approche dont l’objectif est de produire davantage de valeur à chaque cycle (sprint).

Allez, c’est limpide ! On peut passer à la suite…

PS : un autre terme me questionne, celui d’Intelligence collective. J’y reviendrai plus longuement, promis !

La révolution industrielle 4.0

La révolution industrielle 4.0

Dans mes deux précédentes notes, j’ai insisté sur l’importance d’être agile dans un environnement en constante mutation.

La période que nous traversons actuellement, appelée la révolution industrielle 4.0, est particulièrement fluide et dynamique.

Celle-ci suit trois autres grandes périodes d’avancées technologiques.

La première remonte à la moitié du 18ème siècle (1750) et est liée à la vapeur. La fabrication, jusque-là artisanale, devient mécanique.

Fin du 19ème siècle (1890), l’électricité entre dans l’équation et rend possible le travail à la chaine et la production de masse. L’automatisation de substitue à la main d’œuvre.

La troisième révolution date du milieu du 20ème siècle (1970) et repose sur l’informatique et les nouveaux moyens de communication. On parle de révolution numérique.

La quatrième révolution industrielle, nous sommes en plein dedans ! Et ce, depuis 2015 environ. C’est la révolution marquée par l’émergence de technologies novatrices et leur fusion. On parle de Big Data, d’Intelligence Artificielle, de robotique, d’internet des objets, de véhicules autonomes, d’impression 3D, de blockchain, de nano technologies, de bio technologies ou encore d’informatique quantique.

Le calcul est vite fait : un siècle et demi pour la première révolution industrielle ; un siècle pour la seconde; et un demi-siècle pour la troisième. Le temps (nous) presse !

Avec la quatrième révolution industrielle, on passe à la vitesse supérieure. Comparée aux révolutions précédentes, celle-ci évolue à un rythme exponentiel et non plus linéaire.

Mais la révolution industrielle 4.0 n’est pas uniquement différente de par sa vitesse. Elle l’est également de par sa portée et son impact.

En effet, pour la première fois en trois siècles, tous les secteurs d’activité sont concernés et ce, partout dans le monde. Le secteur public, le secteur privé mais également le monde académique et la société civile. L’impact s’étend aux citoyens, bouleversant leur manière de vivre et leurs habitudes de consommation.

Un tsunami d’avancées technologiques renforcé par… je vous le donne en mille… LA CRISE SANITAIRE !

Vous l’aurez compris, le vitesse à laquelle apparaissent les innovations actuelles est sans précédent. Face à un environnement en constante mutation, les entreprises doivent se montrer agiles, résilientes.

La résilience, encore un concept que j’adore. J’y reviendrai !

Image : http://ordinal-software.com
Ou, quand et comment est née la méthodologie Agile ?

Ou, quand et comment est née la méthodologie Agile ?

Maintenant que la transformation Agile n’a plus de secret pour vous ;), passons aux origines de l’Agile.

Comment est née cette méthodologie ? Qui l’a inventée ? Quels sont les documents de référence ?

Le terme « Agile » a été officialisé en 2001. A l’époque, aux Etats-Unis, dix-sept éminents spécialistes du développement de logiciels se réunissent pour discuter des problèmes auxquels l’industrie informatique est confrontée. Leur objectif ? Révolutionner les processus de développement.

De cet événement, connu aujourd’hui sous le nom de « sommet Snowbird » (en référence à la ville de Snowbird, dans l’Utah) nait un guide de référence : Le Manifeste Agile, rédigé et co-signé par les 17 experts.

Ne vous attendez pas à un document savant et/ou kilométrique. L’approche Agile se résume purement et simplement à 68 mots, 4 valeurs et 12 principes fondateurs.

Voici les quatre valeurs de l’agilité:

  • Les individus et leurs interactions plus que les processus et les outils.
  • Un logiciel fonctionnel plus qu’une documentation exhaustive.
  • La collaboration avec les clients plus que la négociation contractuelle.
  • L’adaptation au changement plus que l’exécution d’un plan.

En gros, on donne de l’importance et de l’autonomie aux équipes ; les clients / les utilisateurs sont placés au cœur du projet ; les développeurs se concentrent sur la production de fonctionnalités et non sur la rédaction de documentation ; et enfin, on accueille le changement et on fait preuve de flexibilité.

De ces quatre valeurs découlent les 12 principes fondateurs suivants :

  1. Satisfaire le client en priorité
  2. Accueillir favorablement les changements
  3. Livrer le plus souvent possible des versions opérationnelles de l’application
  4. Assurer une coopération permanente entre le client et l’équipe projet
  5. Construire des projets autour d’individus motivés
  6. Privilégier la conversation en face à face
  7. Mesurer l’avancement du projet en termes de résultats
  8. Faire avancer le projet à un rythme soutenable
  9. Porter une attention continue à l’excellence
  10. Raire preuve de rigueur au quotidien pour fournir un produit à forte valeur ajoutée en sortie
  11. Responsabiliser les équipes
  12. Ajuster à intervalles réguliers son comportement et ses processus pour être plus efficace

Aujourd’hui, vingt ans plus tard, le Manifeste Agile reste LA bible pour toutes les méthodologies de gestion de projet dites agiles. Et il s’applique bien au-delà du domaine IT !

Plus qu’une méthodologie, Agile est une philosophie, un état d’esprit. Il implique un changement profond de la culture d’entreprise. Et qui dit changement, dit résistance… on y reviendra.

A lire :
Manifesto for Agile Software Development : http://agilemanifesto.org/

Qu’est ce qu’une transformation Agile ?

Qu’est ce qu’une transformation Agile ?

Si vous regardez dans le dictionnaire, l’agilité est « la capacité à se mouvoir avec légèreté et souplesse ».

Et bien, tel est l’objectif d’une transformation Agile !

Une entreprise adopte la méthodologie Agile afin de gagner en flexibilité et en réactivité.

Par rapport à la méthode de gestion de projet traditionnelle, appelée « en cascade », la méthodologie Agile offre l’opportunité pour les entreprises de s’adapter en permanence aux changements rapides du marché et des technologies..

Avec « Waterfall », tout le projet est défini en amont, dans les moindres détails. Comme son nom l’indique, il s’agit d’un processus séquentiel dans lequel les progrès se déroulent en plusieurs phases, de haut en bas, à la manière d’une cascade. Les phases dépendent bien entendu de la nature du projet mais dans mon cas, il s’agirait de l’analyse UX, du design, de l’intégration, de l’analyse technique, du développement, du publishing et du testing.  Ce n’est que lorsqu’une phase est terminée que la suivante peut commencer. Et ce n’est que lorsque toutes les phases sont finalisées que le projet, dans sa globalité, est délivré au client.

En fonction de la nature du projet, le processus global peut prendre plus ou moins de temps. Durant ce laps de temps, le client n’a aucune vue sur le développement (c’est ce qu’on appelle l’effet tunnel). Avec le risque que le delivery final ne soit pas totalement à son goût, ou qu’il ne réponde plus aux besoins du marché, ou qu’ils ne soit plus compétitif, ou que sais-je. Dans ce cas, c’est reparti pour un tour !

Par ailleurs, ce processus séquentiel ne laisse aucune place à l’adaptation ou à la rétroaction. Ca ne pose pas de problème dans un environnement prévisible et stable. Mais dans un monde comme celui que nous connaissons aujourd’hui, où la technologie évolue d’une manière exponentielle et où tout ce qui nous entoure gagne en volatilité, en incertitude, en complexité et en ambiguïté, c’est extrêmement risqué.

Au contraire, la méthodologie Agile est basée sur une approche itérative et incrémentale. En gros, l’équipe va se fixer des objectifs à court terme. A chaque fois qu’un objectif sera atteint, elle passera au suivant. Par ce fait, le projet ne se présente plus comme une longue ligne droite mais plutôt comme la succession de sous-projets, jusqu’à l’accomplissement de l’objectif final.

Les avantages de cette manière de procéder sont multiples :

  • le client est impliqué tout au long du projet vu qu’il valide chacune des itérations
  • le scope du projet peut être adapté si nécessaire, sans devoir attendre le delivery final
  • le pilotage du projet est sécurisé compte tenu de la meilleure visibilité de l’avancement des développements
  • la gestion des risques est plus optimale
  • la réactivité aux différentes fluctuations du marché / de l’environnement est rendue possible
  • les délais de livraison sont fluidifiés

Si on en croit les chiffres, un projet mené en Agile aurait 3 fois plus de chances de réussir qu’un projet qui suit une méthodologie de gestion classique.

Ce n’est pas un hasard si les plus grands ont adopté cette méthodologie : Amazon, Google, SAP, PayPal, Yahoo, Spotify, Twitter, IBM, Microsoft, Spotify, …

Je reviendrai d’ailleurs sur le modèle Spotify, la référence en matière de transformation Agile.

Bref, vous comprenez mieux à présent ce qu’est une transformation Agile et l’importance pour une entreprise de « se mouvoir avec légèreté et souplesse » 😉

Image : https://www.easyredmine.com