L’agilité en Scrum : de la théorie à la pratique

Les éditions Eyrolles m’ont récemment offert le livre Scrum, de la théorie à la pratique co-écrit par Bassem El Haddad et Julien Oger. En tant que designer produit travaillant en milieu agile et ayant appris sur le tas avec un scrum master et un product owner géniaux, j’ai eu envie de me pencher sur la théorie pour mieux comprendre les fondements de la méthodologie Scrum. J’ai donc pris ce livre à revers puisque dans mon cas, il s’agit plutôt « de la pratique à la théorie ».

Livre sur la méthodologie Scrum co-écrit par Julien Oger et Bassem El Haddad

Scrum, qu’est ce que c’est ?

Faire du Scrum c’est accroître efficacement et progressivement la qualité d’une application logicielle. (Extrait du livre Scrum, de la théorie à la pratique)

Plutôt que de livrer en une seule fois un projet ou un produit, l’équipe va faire plusieurs petites livraisons permettant d’introduire une nouvelle fonctionnalité à chaque fois. Cela permet entres autres d’ajuster au fur et à mesure les choix (techniques, fonctionnels) afin d’arriver de la manière la plus directe possible au service que l’on souhaite rendre à l’utilisateur.

Scrum et le concept d’agilité

Le manifeste de l’agilité définit 4 préceptes :

• Placer l’humain et la communication au centre
• Réduire la documentation (les cahiers des charges et de spécifications fonctionnelles notamment) de manière à les rendre plus légères. Elles seront ainsi moins chronophage à rédiger et plus courtes à lire par l’équipe (et donc mieux comprises).
• Investir le client dans une démarche de co-conception
• Adapter le produit/projet aux changements en intégrant en cours de route une nouvelle fonctionnalité ou en en retirant.

Être Agile, c’est donner à votre équipe :

• Les outils de l’agilité : le cahier de produit, le cahier de sprint,
• Les mesures d’évaluation : nombre de points (tickets) livrés, humeur de l’équipe, KPI
• Les évènements de l’agilité : les mêlées quotidiennes, La revue (ou démo), La retrospective

Agilité ne veut pas dire :

• profiter des sprints pour imposer continuellement des rush à vos équipes : ce sont les différentes parties prenantes qui fixent ensemble un rythme soutenable (durée des sprints).
• lésiner sur la qualité : l’agilité n’est pas la méthode du vite fait mal fait ! Un recettage et des protocoles de tests complets sont indispensables.
• être sur le dos de l’équipe en permanence : être agile c’est faire confiance à l’équipe pour atteindre les objectifs fixés (les outils et évènements sont là pour canaliser les éventuels débordements).

Quelle place pour le designer d’interface dans une production agile type Scrum ?

Ayant évolué dans un environnement agile chez un éditeur logiciel qui mettait en place Scrum, j’ai parfois eu du mal à trouver ma place. Je devais fournir les conceptions AVANT le début du sprint ce qui impliquait que je m’organise en amont. Mais devais-je m’imposer mes propres sprints de conception en parallèles des sprints de production ?

Julien Oger et Bassem El Haddad expliquent la place du designer dans Scrum

J’ai questionné Julien Oger et Bassem El Haddad, les auteurs du livre Scrum, de la théorie à la pratique à propos de la place du designer dans l’agilité. Voici leurs réponses :

Cette problématique va dépendre de plusieurs facteurs et notamment :

• l’organisation générale : les designers sont-ils totalement intégrés dans le processus de production ? Sont-ils rattachés à un autre service (communication VS service IT) ?
• le format contractuel : l’équipe de design est-elle dans la même logique contractuelle que l’équipe de développement (par exemple dans le cas d’un client final qui aurait recours à une agence ET une société de service en développement) ?
• le cadre du projet : s’agit-il d’un projet de quelques mois ou d’un projet de plusieurs années ?

En fonction de ces critères, il est tout à fait possible d’envisager les 3 solutions suivantes :

1. Intégrer totalement les designer ET les développeurs dans un seul et unique process Scrum avec pour chaque Sprint : une phase de conception graphique permettant de proposer les déclinaisons, maquettes complémentaires au fil des développements (Solution idéale notamment pour les projets longs),
2. Avoir 2 équipes ayant chacune leur propre méthode Scrum et leurs propres Sprints de développement. Dans ce cas une synchronisation est essentielle pour que les éléments graphiques arrivent à l’équipe de développement AVANT la production des récits utilisateurs correspondants (par expérience, très difficile à mettre en place avec la meilleure volonté).
3. Mettre en place une solution alternative en privilégiant des solutions type Scrum de Scrum (qui revient en schématisant beaucoup à une solution 2 mais dont les équipes sont coordonnées par des membres dédiés).

Informations pratiques :
Scrum, de la théorie à la pratique
Par Julien Oger et Bassem El Haddad
Editions Eyrolles
28 € (ou 19,99€ en version numérique)

Partagez cet article sur les réseaux sociaux !