[SCRUM] – Approche de la gestion de projet agile avec SCRUM

Dans cet article, je n’ai pas la prétention de réaliser une formation, il s’agit là de mes prises de notes à partir des formations suivies à partir des vidéos de l’excellent Florent LOTHON (manager & coach agile).

Vidéos disponibles sur le mooc de gestion de projet :

 Je vous recommande son site l’agiliste https://agiliste.fr/

Et pour aller plus loin, le livre de Florent est disponible sur amazon : http://amzn.to/2sTbBYJ

Pour finir , J’ai complété quelques points de mes prises de notes, à partir du guide Scrum

et du manifeste Agile

A quoi sert SCRUM et AGILE ?

SCRUM permet d’apporter des leviers permettant la réussite de projets complexes.

Scrum utilise une approche itérative et incrémentale pour optimiser la prédictibilité et le contrôle de risque.

Une approche agile

Constat

  •                 L’incertitude est inévitable
  •                 Le besoin ne peut être connu complètement tant que les utilisateurs ne l’ont pas utilisé

Scrum propose de:

  • Diviser pour mieux maitriser
  • Diviser le périmètre
  • Diviser le temps : sprint
  • Diviser les équipes en moins de 10 personnes

Il est contre-productif de :

  • Spécifier dans les détails l’intégralité d’un produit avant de réaliser ce dernier
  • Ou
  • Chercher à présenter en détail avant de se lancer

3 piliers à la méthode agile

  • Transparence (visibilité sur la construction)
  • Inspection
  • Adaptation

Définition des termes Scrum

Product owner apporte la vision du produit qui est à réaliser et représente les utilisateurs de ce produit (acteur de la maitrise d’ouvrage)

Le product owner permet de poser les questions :

  • pourquoi fait-on ce produit ?
  • que va-t-il résoudre ?
  • qui va utiliser le produit ?

Le Product owner utilise l’outil product backlog pour référencer les besoins (les blocks au-dessus du pavé product backlog). Pas de détails dans un premier temps (niveau macroscopique).

Le product owner sollicite l’ / les équipes de dev pour estimer la charge de chaque pavé macroscopiquement et complète le back log par les contraintes ou des objets techniques par exemple.

L’équipe de dev a pour objectif de réaliser le produit  (appelé aussi équipe de réalisation).

Puis l’équipe scrum (Scrum Team) ordonnance les différents étapes à travers le product backlog, en s’efforçant de mettre en haut les éléments qui apporte une forte valeur ajoutée aux produits ou considère comme indispensable pour réaliser une première version de ce dernier. En bas des éléments moins importants ou à faible valeur ajoutée, et/ou plutôt couteux.

L’ordonnancement n’est pas aisée, elle doit donc s’appuyer sur d’autres acteurs, tel que les équipes de réalisation ou partie prenant du projet.

Il est important aussi de définir le terme « terminé» dans une itération (definition of Done) dans le product backlog. Cette définition doit être réalisée entre le product owner, les équipes de dev , mais aussi les parties prenant du projet (stakeholders). Les membres doivent avoir une compréhension commune de ce que signifie travail fini, afin d’assurer la transparence.

A partir de là, il est possible de commercer les premières itérations : les sprints.

Il convient de réaliser une réunion de planification de ces derniers (sprint planning), il permet alors de sélectionner les premiers éléments du backlog pour réaliser les sprints.

Il permet aussi de sélectionner le nombre d’éléments à réaliser « rapidement» en fonction de la capacité de réalisation des équipes de dev.

Les éléments sélectionnés sont ajoutés dans le sprint backlog, qui définit les périmètres du spring et le plan d’actions associé dans l’objectif de pouvoir atteindre ce sprint.

Le sprint backlog peut faire l’objet de découpage des taches des éléments sélectionnés, afin de pouvoir mieux répartir les actions au sein des équipes de réalisation.

Ceci permettra de mieux mesurer au quotidien l’état d avancements des actions et des éléments.

Comme toute réunion sur scrum , la planification des sprints est time boxé (sprint planning), ce qui signifie qu’ elle est limité dans le temps, et doit s’arrêter quelques soit sont avancement à la fin du temps imparti. Elle doit être limitée à 1 h.

Ceci permet de rester focuser sur son objectif, plutôt que de s’éterniser inutilement.

Elle ne doit pas dépasser les 8h de réunion sur le sprint d’un mois.

La durée d’un sprint ne doit pas dépasser au maximum 1 mois

Ensuite il convient de passer à l’étape de réalisation du sprint, incluant :

  • la conception détaillée,
  • la mise en œuvre,
  • les tests des fonctionnalités.

Scrum est piloté par des fonctionnalités.

Chaque jour, les équipes de réalisation réalise un mini point avancement  (mêlée quotidienne : Daily Scrum) et planifie ces actions pour les prochaines 24h. Cette réunion doit être limitée à 15 min, et pour respecter ce timing, il convient de rester debout. On n’instruit pas les problèmes en séances, mais plutôt après les mêlées avec les personnes concernées.

Les sprints sont eux aussi time boxés, il se termine par les réunions de revue de sprint (sprint review)², puis de rétrospectives de sprint (sprint retrospective).

Pendant les revues de sprint (sprint review), il convient d’inviter les parties prenant du projet (les sponsors, les Moa, les ambassadeurs, service marketing, équipes de conduite du changement…), dont les retours seront utiles.

On fait aussi le point global sur l’avancement du projet, et on décide des possibles orientations à prendre en fonction de cet avancement.

La rétrospective de sprint permet de prendre de l’expérience sur le sprint écoulé, pour améliorer le processus de réalisation pour le prochain sprint. Cette réunion doit être limité à max 3 h pour un sprint d’un mois (plus court si le sprint est plus rapide).

Elle doit rassembler toute les équipes scrum  (product owner, équipe de réalisation, scrum master).

Il s’agit là d’un premier post mortem de réalisation du sprint.

Enfin, à chaque fin de sprints, il convient de faire un incrément de produit (ou de projet) : Product Increment.

Il est validé par le statut  terminée pour le / les sprint(s) (cf definition of done) , ce qui implique que le résultat du sprint est dans un état « publiable » pour une mise en production (par exemple). 

Un incrément est la partie d’un travail fait, qui prend en charge l’empirisme, et vérifiable à la fin du Sprint. L’incrément est un pas vers une vision ou un but.

Chaque Incrément est ajouté à tous les Incréments précédents et testé de manière approfondie, tout en veillant à ce que tous les Incréments fonctionnent ensemble.

La décision de publication de l’incrément est à la charge du product owner (à publier ou non), toutes les équipes doivent au minimum respecter cette décision.

Les leviers de réussites

Un projet réussit c’est un projet qui donne le sourire à tout le monde (définition personnelle donnée par Florent LOTHON dans l’un de ces vidéos).

Il convient de définir des leviers à la réussite d’un projet scrum :

  1. Sur un projet scrum on doit réduire l’effet tunnel en jouant sur le délai entre l’expression de besoin et la concrétisation de fonctionnalités du projet.

2.S’ouvrir aux changements, voir les évolutions comme des opportunités plutôt que des problèmes.

S’ouvrir aux changements est une question de survie. “Chaque idée qui n’est pas introduite dans le sprint en cours peut être ajouté, ou troqué au profil d’une fonctionnalité à plus haute valeur ajoutée. Il apporte plus de souplesse à un projet. Le terme Agile permet de démontrer la légèreté / la souplesse d’un projet.

3. Optimiser la communication, éviter les échanges asynchrones qui sont sujets à interprétation.

Rien n’est plus efficace que la communication en face à face. Il est crucial de bien se comprendre.

La méthode agile favorise cette méthode de communication, mais il n’interdit pas de restituer le fruit des échanges par écrit ou dans de la documentation.

4. Etre minimaliste.

Commencer le projet par ce qui apporte le plus de fonctionnalités, ce qui permet de mettre à disposition rapidement une partie du produit (la solution) aux utilisateurs.”

5. S’appuyer sur une méthode empirique pour rationaliser les couts de projets.

6. Détecter les défauts au plus tôt

Plus un défaut est détecté tard dans un projet, plus il coute cher à corriger. Pour  faciliter la correction et l’analyse des défauts, il est recommandé de :

* Réaliser des phases de recettes régulières        

* Utiliser de l’intégration en développement continu

* Favoriser le travail en en binôme

* piloter les déploiements par le test

7. Utiliser une architecture souple et émergeante.

Attention au risque d’enfermement et aux couts d’adaptation pour permettre l’utilisation d’une infrastructure.

8. La motivation constitue un levier important de la méthode agile.

Une équipe motivée ira au-delà des attentes.

L’équipe a l’opportunité de s’auto organisée, elle peut ainsi innover, et définir les méthodes et les choix techniques.

Il est important de proposer des challenges, afin de conserver un meilleur esprit d’équipe.

Le management doit croire en la capacité d’atteindre les objectifs fixés et doit offrir son soutien quand cela est nécessaire.

Le management doit aussi à veiller à ce que l’environnement de travail soit motivant, et s’assurer que le rythme de travail est soutenable afin de maintenir celui-ci dans la durée sans sacrifier la qualité.

Le management doit accorder le droit à l’erreur dans le choix des équipes.

Avant de continuer sur ces prises de notes sur scrum, il convient de se rappeler ce qu’est un chef de projet « traditionnel » :

Dans un projet en cycle en V, le Chef de projet doit travailler avec différentes variables :

  • Budget
  • Périmètre
  • Délais
  • Organisation
  • Problèmes à résoudre et imprévus
  • Risques
  • Qualité

Le chef de projet est aussi un manager, il doit être un leader et donner un cap. Il doit affecter les taches aux membres de l’équipe. Il doit aussi revoir régulièrement le planning (et ce quasiment quotidiennement).

Il doit estimer une date de fin, tout en garantissant la fin de projet et ceux malgré le fait que des impondérables pourront arriver.

Ces situations peuvent être stressantes et imposent énormément de rigueur.

Définition des rôles de l’équipe scrum

Définition du scrum master

Scrum master est le garant et s’assure que tout le monde adhère à SCRUM et qu’il est correctement utilisé. Il doit être le coach pour s’assurer que tout le monde ait bien compris les enjeux de la méthode scrum.

Le scrum master est le garant de la bonne compréhension et de l’application du cadre méthodologique scrum. Il s’assure que l’équipe scrum adhère aux principes et règles.

C’est le leader auprès des équipes de dev et du product owner et voir auprès de l’organisation et doit s’assurer de l’adoption. 

Il n’a pas un rôle de manager, mais « servant leader ».  (Leader serviteur)

Le servant leader s’assure que le product ower et l’équipe de dev interagissent correctement ensemble. Il peut coacher le product owner sur le product backlog et sur la planification, ou s’il ne respecte pas les valeurs de scrum.

Le servant leader  coache aussi l’équipe de dev afin de les aider à s’auto organiser pour aboutir à la fin de chaque sprint (mais aussi sur l’increment, et les livrables produits).

Il est sensible aux obstacles que l’équipe de dev rencontre, il met tout en œuvre pour les supprimer, voir faciliter le contournement et ainsi optimiser l’efficacité du travail de l’équipe de dev. Il doit être là pour protéger les équipes de dev des possibles perturbations freinant le travail des équipes. Au besoin, il peut animer les réunions scrum.

Même si le scrum master n’a pas de rôle de manager, mais il manage le processus scrum.

  • Il doit avoir une place de leader / influenceur dans l’organisation si celle-ci doit avoir des adaptations pour adopter scrum.
  • Il doit être soutenu par le sponsor du projet.

Il faut oublier certaines postures auprès des équipes de dev, ce n’est plus un donneur d’ordre, mais plutôt un coach, ceci facilitera la transformation de l’équipe de dev vers une équipe auto organisée. Il doit faire preuve de lâcher prise dans ces nouvelles fonctions (à la différence d’un chef de projet traditionnel).

Un bon scrum master (qualité) doit :

  •   Etre responsable (et s’assurer de la bonne application de scrum)
  •   Créer un environnement de travail motivant
  •   Etre humble et accepter toutes les idées des protagonistes d’un projet
  •   Travailler en mode collaboratif
  •   Etre engagé et accompagner le changement malgré les freins
  •    Etre omniscient sur SCRUM / AGILE et ses pratiques et savoir transmettre les connaissances aux autres
  •    Avoir foi en l’humain

Définition du product ower

Le product owner porte la vision du produit et représente les utilisateurs. Il est maître du product Backlog. Il définit l’ordre dans lesquelles les choses seront faites.

Le product owner définit

  • Le périmètre
  • Les dates de livraison
  • Le contenu du produit

Définition de l’équipe de développement

L’équipe de développement réalise le produit. S’auto-organise et est responsable de tout ce qui concerne le budget, délai et le coût.  

Taille maximale est de 9 personnes pluridisciplinaires pour pouvoir réaliser le produit.

L’équipe de dev est auto organisée, elle estime et s’affecte elle-même les tâches, et cherche des solutions aux difficultés rencontrées.

Cette équipe n’attend pas qu’un chef de projet lui dise comment faire les choses.

Cette équipe de dev n’est pas uniquement composée de développeurs comme on pourrait le croire.

L’équipe de dév en réalité est une équipe de réalisation, elle est composée autant d’architecte technique, d’experts technique, de valideurs (testeurs),  tant sur la partie développement que sur la partie système et infrastructure.

Définition du manager agile

Avec l’évolution des équipes de dev auto organisée, il est important que les sprints ne se transforment pas en anarchie. Pour cela , le(s) manager(s) d’équipe peu(ven)t et doivent toujours exister dans scrum.

Le manager qui met son pouvoir au service du développement des compétences et de la réussite de son équipe.

Le manager doit être présent dans les moments difficiles pour apporter son soutien et communiquer avec les équipes scrum.

Le manager agile doit accorder sa confiance à l’équipe de dev et croire aux capacités à réussir le projet. Il doit s’assurer que le rythme de travail de ces équipes est acceptable et soutenable pour tenir dans la durée.

Le manager doit être compréhensif et accepter le droit à l’erreur.

Ne pas oublier que l’erreur, si elle se produit, n’aura un impact que sur le sprint. Il pourra alors mettre en place des plans d’accompagnement pour aider le ou les collaborateurs.

Répartition des responsabilités

Les parties budgets, organisation globale, qualité, imprévus sont de la responsabilité de l’ensemble des membres de l’équipe scrum (scrum master, product ower, équipe de dev). La responsabilité est partagée à l’ensemble des membres.

Ceci est la principale différence avec la méthode dite traditionnelle, qui faisait porter la responsable uniquement au chef de projet (héros).

Leave a Reply

Your email address will not be published. Required fields are marked *