Livre : Agile Software Requirements

La mise à l’échelle de l’agilité est devenue une nécessité pour les entreprises et les organisations qui veulent profiter pleinement des bénéfices de l’agilité. Pour répondre à ce besoin plusieurs modèles ont fait leur apparition sur le marché, dont les plus connus à ce jour sont Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD) et Large Scale Scrum (LeSS). Parmi ces différents modèles j’ai fait le choix de commencer par étudier SAFe et, dans ce sens, je me suis donc procuré le livre qui semble supporter ce modèle, Agile Software Requirements de Dean Leffingwell.

SAFe est-il vraiment agile ?

C’est la première question que je me suis posé lorsque j’ai vu pour la première fois le poster SAFe avec ses 3 couches : « Portfolio », « Program » et « Team ».

Avant de continuer, un petit rappel de la première des valeurs du manifeste Agile :

Individuals and interactions over processes and tools

De là mon sentiment, suite à la lecture de ce livre, que SAFe n’est pas si Agile que ça car le livre traite plus des processus et des outils que des personnes et de leurs interactions.

Attention, je ne remets pas en cause les idées de SAFe, qui sont tout à fait louables, car le besoin de coordination dans la gestion des différents projets d’une entreprise est une nécessité. Mais doit-on (ou peut-on) pour autant appliquer ce modèle à grande échelle dans de grandes entreprises ou organisations ?

Il me semble, par exemple, que les responsabilités que perd le Product Owner au profit du Product Management peut-être problématique pour certains projets:

  • « Augmentation » du nombre d’intervenant entre le client (et/ou utilisateur) et l’équipe de réalisation (l’information sur le besoin risque d’être « parasité »)
  • Risque de réduire le sentiment d’engagement de la part de l’équipe de réalisation (effet cascade)
  • Le PO qui ne porte plus la responsabilité de la vision du produit (re)devient finalement un chargé de projet

Cela me rappelle une expérience dans une structure où le rôle du Product Management était tenu par le marketing et le rôle de Product Owner était par ma chef de projet. Tous les « besoins » étaient commandés par le marketing et seuls ces derniers devaient être satisfait. Mais nous avons eu une fois l’opportunité de travailler sans le marketing, juste avec la vision et l’expérience de ma chef, et c’est cette fois-ci que nous avons sorti le meilleur produit. Les clients et les utilisateurs étaient très satisfait par ce nouveau produit même si celui-ci changeait radicalement d’approche par rapport au précédent.

Ce-ci est peut-être une exception mais je ne pense pas qu’il faille pour autant étouffer les projets avec des structures trop rigides ou non adaptées au contexte de certains projets juste pour des raisons d’alignement organisationnel.

Masse critique

La « masse critique » est un terme que j’emprunte au domaine de la physique pour parler d’une structure organisationnelle ayant atteint une certaine taille (que je n’ai pas quantifié) qui rend impossible la mise en place d’un processus (ou méthode) de travail unique au sein de celle-ci.

D’ailleurs dans les grandes structures organisationnelles nous observons souvent des différences culturelles entre les différentes directions, voir même dans les différents services de ces directions, même quand celles-ci vous assure que tout le monde utilise les mêmes pratiques et les mêmes règles.

Tenter de changer les cultures de ces différents services et/ou directions peut-être parfois très coûteux par rapport aux bénéfices réels tirer d’un alignement culturel et organisationnel.

Dan Cobley reprenait un principe physique dans sa présentation « What physics taught me about marketing » qui peut, je pense, aussi s’appliquer à un changement organisationnel :

For a larger masse it require more force to change it direction

Donc, au lieu de se lancer dans une quête perdue d’avance vers le grand alignement, les grandes organisations pourraient s’inspirer du proverbe « Diviser pour mieux régner gérer » et ainsi offrir une certaine autonomie aux différentes unités qui les composent.

Dans le livre How Google Test Software les auteurs nous apprennent que chaque unité de Google a sa propre façon de réaliser les essais des applications qu’elle développe. Il semble que les tentatives d’alignement sur les pratiques des tests ont plus débouché sur des partages de bonnes pratiques que sur des règles formelles pour l’ensemble de l’entreprise.

On peut donc se poser la question suivante : « Est-il donc bon de mettre en place SAFe à grande échelle dans de grandes organisations ? ».

De bonnes choses tout de même 

Comme je l’ai dit plus tôt, tout n’est pas mauvais dans le modèle SAFe. D’ailleurs j’ai eu une intéressante conversation avec un conférencier certifié SAFe, suite à sa présentation. Il s’est trouvé que lui aussi est un grand de ce qui se fait chez Spotify au niveau de l’agilité (lire l’excellente publication Scaling Agile @ Spotify). Pour lui il n’y a aucune obligation à adopter le modèle dans son ensemble, on peut y piocher les éléments que nous trouvons utiles et pertinents dans notre contexte.

C’est un peu ce que je fais aujourd’hui en m’inspirant de l’événement Release Planning que nous propose SAFe pour l’appliquer au niveau du service dans lequel je travaille. Je ne pense pas que cet événement soit une idée originale de l’auteur mais l’adoption d’une bonne pratique qui a su émerger dans la communauté Agile.

Les bénéfices que je recherche avec le Release Planning sont :

  • une meilleure vue sur les interdépendances des projets des différentes équipes qui nous permettra de mieux gérer nos livraisons
  • une meilleure compréhension de la vision du service de la part des différentes parties par leurs participations à la planification des livraison, ce qui permettra aussi de renforcer le sentiment d’engagement chez ces dernières

En conclusion un livre dont je recommande la lecture même si je ne suis pas toujours d’accord avec le contenu (surtout celui de la page 52). 

Advertisements

Laisser un commentaire

Entrer les renseignements ci-dessous ou cliquer sur une icône pour ouvrir une session :

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l’aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s