Les SCRUMS et le Management Agile

 

Management agile 

Ce terme à la mode est en réalité une simple adaptation à la réalité économique moderne : Tout va très vite. Si on reste coincé avec des méthodes « à l’ancienne » on va se faire dépasser par des concurrents plus réactifs, plus agiles. Le management agile prend en compte la notion de temps, mais aussi la notion de client centric : Le client est Roi. Ce que veut le client, il l’aura.

L’exemple de la chute de Nokia face à Apple, puis à tous les autres, Samsung, Huawei etc. est typique du refus des méthodes agiles et du refus du changement en général. Comme disait Maria Montessori « Ce qui manque ce n’est pas le temps mais la patience ». Les clients modernes n’ont pas la patience de lire une documentation de 80 pages. Il faut que l’utilisation soit intuitive « sans doc ». Les méthodes de management agile intègrent toutes ces notions.

Quatre valeurs fondamentales

Les méthodes agiles prônent 4 valeurs fondamentales :

• Individus et interactions plutôt que processus et outils
• Fonctionnalités opérationnelles plutôt que documentation exhaustive
• Collaboration avec le client plutôt que contractualisation des relations
• Acceptation du changement plutôt que conformité aux plans

Douze principes généraux:

1. Satisfaire le client en priorité
2. Accueillir favorablement les demandes de changement
3. Livrer le plus souvent possible des versions opérationnelles de l’application
4. Assurer une coopération permanente entre le client et l’équipe projet
5. Construire des projets autour d’individus motivés
6. Privilégier la conversation en face à face
7. Mesurer l’avancement du projet en matière de fonctionnalités de l’application
8. Faire avancer le projet à un rythme soutenable et constant
9. Porter une attention continue à l’excellence technique et à la conception
10. Faire simple
11. Responsabiliser les équipes
12. Ajuster à intervalles réguliers son comportement et ses processus pour être plus efficace

La question devient alors : Comment remplacer une méthode qui ne fonctionne pas, par une bien meilleure ?

Des Britanniques se sont penchés sur le problème et ont décrit la méthode « SCRUM », dont le nom provient de la mêlée de rugby : Tout le monde pousse en même temps dans la même direction !  La source est le livre écrit par Ken Schwaber et Jeff Sutherland en 2013, « le guide SCRUM ».

Ce concept « Agile » a en fait débuté dès les années 90 dans les développements logiciels puis a été formalisé et étendu pour correspondre à tout développement de produit ou de service.

Définition de Scrum : Cadre de travail permettant de répondre à des problèmes complexes et changeants, tout en livrant de manière productive et créative des produits de la plus grande valeur possible. Un SCRUM est donc:

• Léger
• Simple à comprendre
• Mais, difficile à maîtriser

Le SCRUM est donc une méthode agile dédiée à la « gestion de projets » en remplacement des chefs de projet. Cette méthode de gestion, ou plutôt ce référentiel de management de projet, a pour objectif d’améliorer la productivité de son équipe.

Répartitions des rôles dans un SCRUM

Le SCRUM MASTER :

• S’assure que les principes et les valeurs du SCRUM sont respectés
• Facilite la communication au sein de l’équipe
• Cherche à améliorer la productivité et le savoir-faire de son équipe

L’équipe SCRUM :

• Pas de rôles bien déterminés, chacun peut aider les autres : architecte, développeur, testeur
• Tous les membres de l’équipe apportent leur savoir-faire pour accomplir les tâches
• Taille de 6 à 10 personnes au maximum !

Le Product OWNER :

• Expert métier : définit les spécifications fonctionnelles
• Etablit la priorité des fonctionnalités à développer ou corriger
• Valide les fonctionnalités développées
• Joue le rôle du « client »

Méthode de gestion de projet en mode SCRUM

Les sprints : Le cycle de vie du SCRUM est rythmé par des itérations de quelques semaines : les sprints. Chaque sprint spécifie des livrables intermédiaires qui lui sont propres. Un nouveau sprint ne démarre que lorsque le sprint précédent a été débriefé.

Le Product Backlog

Le référentiel des exigences initiales est dressé et hiérarchisé avec le « client ». Il constitue ce que l’on nomme le « Product Backlog ». Il ne doit pas nécessairement contenir toutes les fonctionnalités attendues dès le début du projet, il va évoluer durant le projet en parallèle des besoins du client.

La notion de POC « Proof Of Concept » permet de montrer une maquette fonctionnelle de ce que sera le produit ou le service.

La notion de MVP « Minimum Viable Product » permet de fixer les fonctionnalités minimales qui rendent le produit ou le service « vendable » ou « mettable en ligne ». Le but du MVP est de modifier la notion de « recettage » en cycle d’amélioration KAIZEN : « mieux vaut 70% aujourd’hui que 100% un jour ». Vous noterez que la plupart des produits vendus aujourd’hui ne disposent que d’une partie des fonctionnalités qui seront commercialisées dans des versions ultérieures : iPhone 3, 4, 5, 6 etc. Par exemple, l’iPhone 3 était déjà comparable à ce que les smartphones offrent aujourd’hui mais avec un écran plus petit, un appareil photo moins performant etc. Le but est de créer, puis d’occuper, la niche de marché pour atteindre rapidement un nombre critique d’utilisateurs. Sur Internet on estime ce chiffre à 1 million d’utilisateurs pour être crédible. De nombreuses sociétés modernes comme Amazon ou Tesla ont englouti des fortunes pour avoir une position dominante sur un marché : aujourd’hui, la valeur d’une entreprise est le produit de son offre originale (ou leader) par le nombre d’utilisateurs.

User Story

Comme tout produit ou service est orienté sur la satisfaction de l’utilisateur (on l’appelle aussi UX ou User Experience), les fonctionnalités décrites portent le nom de « User Stories » et sont décrites en employant la terminologie utilisée par les clients dans le métier considéré.

Une « User Story » ou « Story » contient généralement les informations suivantes :

• ID – un identifiant unique
• Nom – un nom court (entre 2 et 10 mots), descriptif de la fonctionnalité attendue par le client (ex. Export / Import standard des fiches prospects). La dénomination doit être suffisamment claire pour que les membres de l’équipe et le Product Owner comprennent de quelle fonction il s’agit. Le nom ne doit pas introduire d’ambigüités.
• Importance – un entier qui fixe la priorité de chaque story. La priorité d’une story peut être changée en cours de réalisation du projet.
• Estimation – La quantité de travail nécessaire pour développer, tester, et valider cette fonctionnalité ou ce service. L’unité de mesure peut être un nombre de jours/homme (jours à 100% dédiés à la fonctionnalité) ou un nombre de points. Les estimations se font en relatif, en comparant les estimations des stories terminées avec la story à estimer. (la méthode « agile Fibonacci » peut être utilisée, ça sera l’objet de mon prochain article).
• Démo / Maquette / POC – Un test relativement simple permettra de visualiser le rendu du service ou du produit (dans l’exemple précédent cela consiste à exporter un objet en XML puis l’effacer de la base, l’importer depuis le XML, à la fin l’objet doit être dans la base). Ce dispositif constitue ainsi un test de validation.

Notes – toute autre information : clarifications, références documentaires…

Le sprint Planning Meeting

On organise, avant chaque sprint, une réunion de planification, le sprint planning meeting. Ce planning sélectionne dans le product backlog les exigences les plus prioritaires pour le client. Elles seront développées, testées et livrées au client à la fin du sprint. Elles constituent le sprint backlog, un sous ensemble du product backlog.

La Mêlée

Au lancement, à la clôture et au cours du sprint, il est organisé, chaque jour, une réunion d’avancement (environ 15 min) avec tous les membres de l’équipe (y compris en vision pour les membres éloignés) afin de s’assurer que les objectifs du sprint seront tenus, c’est le principe du SCRUM ou mêlée. Chaque jour, après la réunion SCRUM, le SCRUM Master maintient un graphique appelé sprint burndown chart ou « météo » du projet. Ce graphique donne une très bonne vision de ce qui a été fait et du rythme de travail de l’équipe. Il permet également d’anticiper si tous les éléments du Sprint Backlog seront terminées à la fin de l’itération ou non.

Cette réunion n’a pas seulement un but purement informatif, mais aussi celui de stimuler l’esprit travail en équipe et le niveau d’engagement de chaque membre de l’équipe dans le projet. Durant la réunion chaque membre de l’équipe doit prendre la parole et présenter principalement les choses suivantes :

• Ce que j’ai fait hier et les éventuels problèmes rencontrés
• Ce que je vais faire aujourd’hui
• Est-ce que j’ai des difficultés pour continuer mon travail ?

En faisant cet exercice quotidiennement chaque membre de l’équipe est au courant de ce que font ses collègues et il peut coordonner son travail et aider ou se faire aider en cas de difficultés.

Le Scrum Meeting n’est pas une réunion pendant laquelle on cherche à résoudre les problèmes, mais uniquement à les identifier et les exprimer. Le Scrum Master a pour rôle d’apporter des solutions ou de déléguer à un autre membre de l’équipe la résolution des problèmes soulevés durant le Scrum Meeting. A la suite de cette réunion le Scrum Master met à jour le burndown chart.

A la fin d’un sprint, on fait une démonstration au client des derniers développements, le Sprint Review Meeting. C’est aussi l’occasion de faire un bilan, sur le fonctionnement de l’équipe et de trouver des points d’amélioration.

Ainsi, un SCRUM prône l’adaptabilité, sous l’effet de l’expérience acquise et des spécificités du projet ce qui le rapproche des méthodes qualité avec leur roue de Deming (plan – do – check -act). Une inspection ou un audit, consistera alors à vérifier les écarts par rapport à l’objectif initial.

Cette méthode permet de transformer littéralement la grosse unité bureaucratique en « startup » agile. Essayez, vous verrez !

Source http://mauro-israel.over-blog.com/2019/03/zero-management-4-les-scrums-et-le-management-agile.html