Le bon mix pour adopter l’agilité !

Auteur

Stéphanie Herve-Pineau

Date

20/11/2020

Share on facebook
Share on twitter
Share on linkedin
Share on pinterest
Share on email
0

Voici un cocktail classique mais qui ne demande qu’à être plus connu. Il est fait à base d’agilité et peut se boire pour l’apéritif, tout au long de la soirée et même en digestif. Bref, c’est un cocktail très adaptable et rafraichissant nommé: L’AGILE SMASH.

 

Avec L’AGILE SMASH, nous allons vous donner les clés pour mettre en place et adopter l’agilité. A savoir qu’il y a diverses méthodologies agiles. Nous allons aborder ici la recette la plus classique faite à base de Scrum.

 

Scrum a été initialement développé au début des années 1990 pour la gestion et le développement de produits. 

Nous allons vous présenter cette recette en deux façons:

Agile Smash

POSER LES BASES

“ La base ! “

Scrum est fondé sur la théorie de l’empirisme. L’empirisme affirme que la connaissance provient de l’expérience et la prise de décisions est basée sur des faits connus. Scrum utilise une approche par étape dite itérative et incrémentale, c’est à dire par brique, pour optimiser la prédictibilité et le contrôle de risque.

Trois piliers soutiennent cette base empirique: la transparence, l’inspection et l’adaptation.

 

SOYEZ PLUS TRANSPARENT

“ Clair comme de l’eau de roche. “

Les différents éléments qui composent le processus doivent être compris et visibles par tous les participants. Il faut être en capacité de voir le travail de chacun et que le vôtre soit visible de tous. Autre point important: être transparent! C’est aussi être clair. Le vocabulaire des processus Scrum doit être connu de tous ainsi que la définition du travail fini aussi appelé “Definition of Done”.

 

METTEZ UNE DOSE D’INSPECTION

“ N’hésitez surtout pas à goûter, goûter, goûter ! ”

L’inspection permet de repérer des écarts indésirables et l’état d’avancement du projet. L’équipe projet doit fréquemment inspecter son travail pour éviter toute mauvaise surprise.

 

ARROSEZ AVEC DE L’ADAPTABILITÉ

“ Soyez réactif ! ”

N’ayez pas peur du changement. Soyez en mesure de réagir vite et réaxer la stratégie en fonction des retours utilisateurs ou de votre propre équipe. Si un membre de l’équipe juge qu’un ou plusieurs aspects du processus dérivent et que le produit final ne sera pas acceptable, il faut adapter rapidement. Comme la méthode s’appelle : “Agile”. Soyez agile, soyez souple, soyez réactif.

 

GARDEZ LES 5 VALEURS SCRUM EN TÊTE

“ Ça donne beaucoup plus de corps. ”

Les cinq valeurs Scrum sont : engagement, courage, focus, ouverture et respect. L’équipe Scrum les incarne elle-même. Elle les apprend et les explore au fur et à mesure qu’elle travaille les évènements, les rôles et les artefacts de Scrum. Les membres de l’équipe s’engagent personnellement à atteindre les objectifs communs. Tout le monde se concentre et se focalise sur le travail à faire. L’équipe Scrum et ses parties prenantes acceptent d’être ouvertes sur tout le travail et les défis impliqués par l’accomplissement de ce travail. Les membres de l’équipe se respectent mutuellement en tant que personnes compétentes et indépendantes.


METTEZ EN PLACE UNE EQUIPE AGILE

“ Étape obligatoire ! ”

Une équipe Agile en mode Scrum est composée d’un Product Owner, une équipe de développeurs et un Scrum Master. Elle ne doit pas excéder 9 personnes.

Product Owner: Le Product Owner est responsable de maximiser la valeur du produit résultant du travail de l’équipe de développement.

Équipe de développement: L’équipe de développement se compose de professionnels techniques qui fournissent un incrément « Fini » potentiellement publiable (Releasable) à la fin de chaque Sprint. Ils sont en général entre 2 et 7.

Scrum Master: Le Scrum Master est chargé de promouvoir et supporter Scrum. Il aide tout le monde à comprendre la théorie, les pratiques, les règles et les valeurs de Scrum.

Cette équipe est auto-organisée et pluridisciplinaire. Auto-organisée, l’équipe choisit SA façon d’accomplir son travail. Cela promeut la flexibilité, la créativité et la productivité.

 

LES ÉVÈNEMENTS OBLIGATOIRES

“ Ce cocktail se prête à nombre d’occasions ! ”

Les évènements prescrits sont utilisés pour créer de la régularité et minimiser la “réunionite”. Tous les évènements sont limités par le temps, “time-boxés”. Nous vous les présentons:

Le Sprint: C’est une itération de développement. Le travail à effectuer pour aboutir à un incrément est fait durant le Sprint qui est time-boxé. Un Sprint dure en général deux à quatre semaines.

Le Sprint Planning: Le travail à effectuer durant un Sprint est défini lors de la réunion de Sprint Planning. Le Product Owner arrive avec sa liste de besoins priorisés sous forme de Features ou User Stories. Il va soumettre ces besoins aux développeurs qui vont noter la complexité de chacune des demandes. Un exemple de type de vote de la complexité est le Poker Planning. Le Poker Planning est une façon ludique de produire des estimations sur l’effort de développement de fonctionnalités via un vote de point fait sur la base de la suite de Fibonacci.

Le Daily: Le Daily est un évènement quotidien de 15 minutes destiné à l’équipe de développement. L’équipe de développement planifie son travail pour les prochaines 24h et fait le point sur les éléments bloquants. Certains développeurs pourront alors intervenir pour apporter leur aide et leur bonne pratique afin de trouver des solutions. On voit ici un exemple de transparence, d’inspection et de pluridisciplinarité.

La Sprint Review: Elle est tenue à la fin du Sprint pour inspecter l’incrément réalisé et adapter le Backlog Produit si nécessaire. Pendant cet évènement, l’équipe et les parties prenantes échangent sur ce qui a été fait durant le Sprint et font également une démonstration de leur réalisation.

La Sprint Retrospective: Est une opportunité pour l’équipe de s’auto-inspecter et de créer un plan d’améliorations à adopter au cours du prochain Sprint.


LES ARTEFACTS A INCORPORER

“ Ils coulent de source ! ”

Les artefacts sont des éléments produits, modifiés puis utilisés dans le cadre de Scrum. Ils sont souvent générateur de valeur. Il y en a quatre majeurs à retenir :

Product Backlog : C’est une liste ordonnée de tous les éléments identifiés comme nécessaires au produit. Il constitue l’unique source pour tout changement à apporter au produit. Le Product Owner est responsable du Backlog produit, y compris son contenu, son accessibilité et son ordonnancement.

Sprint Backlog : C’est une prévision que l’équipe de développement fait sur la fonctionnalité qui sera présente dans le prochain incrément et sur le travail nécessaire pour livrer cette fonctionnalité dans un incrément dit « Fini » (Done).

Increment : L’incrément est constitué des éléments du Backlog produit « Finis » pendant le sprint ainsi que les incréments livrés précédemment.

Definition of Done: Lorsqu’un élément du Backlog produit ou un Incrément est décrit comme « Fini », tout le monde doit comprendre ce que « Fini » signifie. Il faut donc que l’équipe se mette d’accord sur une définition commune.

Voilà ! Vous avez tous les éléments pour réussir votre AGILE SMASH.

Enfin, le guide Scrum nous résume ce cadre de travail en 3 points:

Alors n’hésitez pas à essayer, pratiquer et pratiquer. Votre cocktail n’en sera que meilleur à chaque fois.

 

Et si vous désirez voir notre carte des cocktails, vous pouvez la consulter ci-après: Mojito Thinking, Usertest Lagoon, Prototypacolada, Pitchini, Caipicreativity.

 

À bientôt pour une nouvelle recette…🍹