Mettre du Scrum n’est pas devenir Agile !

Derrière ce titre un peu provocateur « Scrum n’est pas devenir Agile » se cache en fait un sujet très intéressant à traiter. Beaucoup d’entreprises veulent mettre du Scrum en pensant devenir Agile.

Cet article n’est pas un article anti-scrum bien au contraire, il est seulement là pour amener un constat indéniable au sein d’un grand nombre d’entreprises françaises.

Scrum plus populaire que l’agile

Aujourd’hui le Scrum a tellement pris de la popularité au sein des entreprises qu’un grand nombre d’entre elles mettent du Scrum en pensant s’être transformées en entreprise Agile.

Mais c’est en fait très loin d’être le cas et les coachs agiles constatent même que la mise en place d’un Scrum dans certaines structures n’est même pas un premier pas vers l’agilité.

Scrum est une « méthodologie » agile qui apporte de la structure à des projets souvent IT mais l’agilité va bien au delà de la mise en place d’un Scrum. Cependant beaucoup d’entreprises françaises n’arrivent pas à dépasser cette étape.

Trop de rigidité

Je dois rappeler encore aujourd’hui à certaines entreprises que l’un des piliers du Scrum est « l’adaptation » et pourtant celles-ci s’efforcent à respecter scrupuleusement une mise en place d’un Scrum (parfois loin d’être le scrum de base) ; elles pensent enfreindre les lois au moindre changement…

Si une équipe utilise des User-Stories, sachez que ce n’est pas du Scrum mais une pratique empruntée à l’Extreme Programming. Mais alors docteur, est-ce grave ??? Non, bien au contraire, il ne faut pas se priver de certaines pratiques venues se greffer au Scrum de base si elles sont utiles pour vos équipes.

Mais alors je fais du Scrum et je ne suis pas agile ?

En effet, certaines entreprises font du Scrum sans être agile et sans avoir compris la culture agile. Il existe encore des entreprises qui font une sorte de Scrum et qui décident de ne pas faire de board ; un soucis de double saisie qui énerve et qui ferait penser que c’est du travail inutile.

Faux, c’est évidement indispensable de faire du management visuel car c’est un partage d’information très efficace.

Partons de cas que les coachs agiles rencontrent dans les entreprises qui font du Scrum mais qui n’ont pas compris la philosophie de l’agile voire des méthodes agiles elles-même.

1/ « On livrera tout dans 6 mois quand la plateforme sera à peu près stable »

Manifeste agile
"Notre plus haute priorité est de satisfaire le client
en livrant rapidement et régulièrement des fonctionnalités
à grande valeur ajoutée."

Et non, il faut faire en sorte d’avoir une plateforme stable avant de tout développer afin de pouvoir livrer rapidement.  L’agilité passe aussi par le client qui devient moteur de la création du produit ; on a besoin de ses feedback rapidement pour améliorer le produit.

Pour avoir ses feedback réguliers, nous devons avoir une plateforme stable pour livrer le produit même si on ne parle pas forcément de production.

2/ « Le client change toujours d’avis, c’est bon on fait comme on avait dit au début »

Manifeste agile
"Accueillez positivement les changements de besoins,
même tard dans le projet. Les processus Agiles
exploitent le changement pour donner un avantage
compétitif au client."

Il faut comprendre qu’il n’est pas toujours simple de prévoir à 100% un produit avant même de le voir en action. Il est probable que le client s’aperçoive  qu’il y a mieux à faire encore. Autant qu’il en profite pour améliorer le produit et de ne pas cacher des besoins d’amélioration par crainte d’être mal perçus.

Il ne faut pas bloquer le changement mais au contraire l’encourager. pour avoir un produit final de grande qualité.

3/ « On arrête les retrospectives, c’est une perte de temps sur le développement »

Manifeste agile
À intervalles réguliers, l'équipe réfléchit aux moyens
de devenir plus efficace, puis règle et modifie son
comportement en conséquence.

Les rétrospectives sont essentielles au sein des équipes scrum, il ne faut surtout pas les supprimer. Si elle n’est plus efficace, c’est que votre format n’est pas le bon. N’hésitez pas à changer son format.

Voici deux articles sur les rétrospectives pour vous aider :
Découvrez l’art de la rétrospective
Anti-pattern de la sprint retrospective à éviter !

Si vous rencontrez de nombreux problèmes, vous pouvez même décider de faire des « Reflection » qui est une cérémonie venant du Crystal Clear qui cherche à résoudre un problème dès que le problème se pose.

4/ « C’est moi le Chef de projet technique donc c’est moi qui décide »

Manifeste agile
Les meilleures architectures, spécifications et 
conceptions émergent d'équipes auto-organisées.

Dans le monde de l’agilité, on essaye de créer des cercles de compétences qui décident ensemble des solutions à mettre en place. Si cela devient plus rare en ce moment, il arrive encore de voir des chef de projet technique dans des projets scrum. C’est évidemment un rôle à mettre de côté et qui n’a pas de sens en Scrum.

5/ « Notre PO est au siège social à 400km et c’est lui qui gère les utilisateurs là bas »

Manifeste agile
Les utilisateurs ou leurs représentants et les 
développeurs doivent travailler ensemble quotidiennement
tout au long du projet.

Il est essentiel que les développeurs aient toujours accès aux utilisateurs clés et au pire des cas au Product Owner. Bien que peu recommandé, si celui-ci est toujours absent, n’hésitez pas à mettre en place des solutions pour que les développeurs aient un maximum de communication avec les utilisateurs voire leurs représentants.

6/ « Je vais te prévoir tout un système d’internationalisation, on sait jamais dans le futur »

Manifeste agile
La simplicité – c’est-à-dire l’art de minimiser la 
quantité de travail inutile – est essentielle.

C’est assez difficile pour les développeurs de l’accepter mais en agile on ne fait que ce qu’on a besoin. Prévoir est un risque de perte de temps et de complexification de l’application que les développeurs ne doivent pas prendre.

C’est une philosophie difficile pour certains développeurs mais il faut vraiment qu’ils comprennent qu’on ne fait que le nécessaire en agile et qu’on refactorisera en cas de besoin.

7/ « On fera avec ce qu’on a, on va pas investir là dedans »

Manifeste agile
Réalisez les projets avec des personnes motivées.
Fournissez-leur l’environnement et le soutien dont ils
ont besoin et faites-leur confiance pour atteindre les
objectifs fixés.

Les entreprises font souvent l’erreur de ne pas vouloir investir hors cela a un impact direct sur la motivation des équipes ; devoir trouver des astuces pour combler une envie d’économie de certains managers est souvent source de démotivation.

Il faut investir pour que les équipes se sentent toujours motivées et que la productivité reste toujours bonne. La motivation des équipes est directement liée à la productivité.

8/ « Ne perdons pas de temps avec les tests, c’est trop long à faire »

Manifeste agile
Une attention continue à l'excellence technique et
à une bonne conception renforce l’Agilité.

Les méthodes agiles misent sur la qualité technique afin de diminuer au maximum les bugs et s’épargner la phase de certains projets où le legacy est devenu trop important.

Pensez agile avant de penser Scrum !

Il existe d’autres exemples mais je pense que les 8 que j’ai cités sont déjà suffisant pour bien comprendre le soucis de l’application du Scrum dans certaines entreprises non agile.

Donc le conseil que de nombreux coachs agiles pourront vous donner est de penser à faire de l’agile avant de penser à faire du scrum. N’oubliez jamais que si le Scrum peut apporter de la structure dans vos projets, on peut aussi en faire en oubliant d’être agile.

A chaque fois que vous faites du Scrum, pensez également à faire de l’agile et à travailler l’agilité bien au delà de l’équipe Scrum.