Les Rôles, Scrum définit trois rôles fondamentaux

Ce pilier définit les rôles fondamentaux nécessaires au bon fonctionnement de la méthodologie Agile Scrum, qui sont du nombre de trois : Product Owner, Equipe, Scrum Master

1- PRODUCT OWNER :

• Il est le maitre d’ouvrage du produit. Il connaît la finalité, les objectifs et les priorités du produit à réaliser. Le Product Owner est comptable des gains et des pertes envers le management de l’entreprise

• Le Product Owner n’est pas un sponsor, c’est un acteur engagé dans le projet et peut se faire assister des experts pour apporter des réponses ou des précisions à l’équipe projet. Il est chargé de prioriser chaque demande figurant dans la liste de produit à réaliser (Product Backlog) sur la base du ROI.
  

2- EQUIPE

• Elle réalise le produit final. Elle est multi-compétences et comprend toutes les expertises nécessaires pour mener à bien sa mission.

• L’équipe forme un bloc solidaire pour favoriser à la fois la montée en compétence de ses membres et le travail collectif. Il n’existe aucune hiérarchie entre les membres de l’équipe.

3- SCRUM MASTER

• Il est le pivot de la méthode Agile Scrum. Il doit aider le management, l’équipe et le Product Owner à s’approprier les principes de la méthode Agile Scrum.

• Il rend visible les difficultés et les obstacles rencontrés par l’équipe et le Product Owner, et mobilisera les acteurs concernés pour les résoudre dans les plus brefs délais. Il doit protéger l’équipe contre les sollicitations retardant le déroulement des travaux.

Suivi & communication, outils préconisés par Scrum pour assurer un suivi des travaux

Ce pilier présente les outils indispensables pour assurer un suivi rigueur et une communication efficace envers le management. Il a une finalité triple : (i) donner de la visibilité sur la totalité des travaux à réaliser et en cours de réalisation ; (ii) suivre au jour le jour la productivité de l’équipe, et enfin (iii) identifier les obstacles et les difficultés bloquant les travaux.

1- PRODUCT BACKLOG

• Une liste de l’ensemble des demandes à réaliser par l’équipe projet : fonctions, programmes, installation des équipements, matériels et logiciels, etc. Elle est alimentée par les utilisateurs finaux, le management, le métier, la DSI, l’équipe…

• Cette liste est unique pour le projet et sous la responsabilité du Product Owner. Celui-ci affecte une priorité à chaque demande de la liste en fonction de son ROI pour l’entreprise. Les travaux seront réalisés par l’équipe dans l’ordre des priorités fixées par le Product Owner. Le Product Owner peut regrouper un ensemble de fonctions dans des versions appelées Release Backlog.

2- SPRINT BACKLOG

• Liste des tâches à réaliser par l’équipe durant l’itération « le Sprint ». Elle est alimentée uniquement par l’équipe sur la base des fonctionnalistes convenus avec le Product Owner.

• Durant une itération aucune modification des fonctionnalités convenues avec le Product Owner n’est permise.

3- BURNDOWN CHART

• C’est un outil de suivi sous forme graphique montrant le réalisé et le reste à faire.

• Il existe deux types de Burndown Chart :

1. Sprint Burndown Chart assure un suivi des efforts accomplis pendant le Sprint. Il est mis à jour quotidiennement après la réunion « Daily Scrum ».
2. Backlog Burndown Chart donne l’avancement des efforts et le reste à faire pour finaliser le produit. Il est actualisé à la fin d’un sprint.

4- IMPEDIMENT LIST

• Cette liste regroupe tous les obstacles et difficultés que rencontrent l’équipe et le Product Owner pour accomplir leurs missions. Elle est visible de tout le monde.

• Quelques exemples d’obstacles que l’on rencontre souvent sur les projets : Manque d’implication du métier, absence du soutien des sponsors, dépendance en personnel clé, trop de discussion sans action, faible couverture de test, manque de priorisation dans les tâches et les fonctions,….

Les Instances : Scrum définit 4 comités de rencontre

Ce pilier précise le rôle et les objectifs de chaque comité de rencontre entre les différents acteurs pour planifier les travaux, préciser les priorités des tâches, suivre l’avancement des travaux, identifier les points de blocage, valider les travaux finis, faire une revue d’amélioration…

1- SPRINT PLANNING

Réunion de planification qui se déroule au début de chaque itération « Sprint » et se divise en deux parties :

• Partie 1 : Etape de qualification des fonctionnalités de la Product Backlog candidates à l’itération. Elle se tient entre l’équipe, le Product Owner et le ScrumMaster. Elle permet de prendre connaissance des intentions et préoccupations du Product Owner dans le but de bâtir un produit en adéquation avec les besoins du métier.

• Partie 2 : Une rencontre entre l’équipe et le ScrumMaster pour étudier dans le détail les fonctionnalités sélectionnées pour le Sprint. Celles-ci peuvent être décomposées en tâche, si nécessaire. L’équipe estime donc le temps de réalisation de chaque tâche et alimente le « Sprint Backlog » selon l’ordre convenu avec le Product Owner.

2- DAILY SCRUM

• Réunion de suivi quotidienne entre l’équipe et le ScrumMaster, d’une durée de 15 minutes. Chaque membre de l’équipe doit répondre à 3 questions, pas plus : (i) ce que j’ai fait hier ? (ii) ce que je vais faire aujourd’hui ? (iii) Mes problèmes actuellement ?

• A la fin de la réunion, on réactualise les suivis (Sprint Backlog, Burndown chart, Impediment list) pour rendre visible l’avancement des travaux, les difficultés rencontrées et les efforts accomplis par l’équipe.

3- SPRINT REVIEW

• Une réunion qui se tient à la fin du Sprint « itération» durant laquelle l’équipe présente le produit réalisé pendant l’itération. Elle est présidée par le Product Owner qui acte les fonctions finalisées de la Product Backlog et détermine avec l’équipe et le management l’objectif du prochain « Sprint »

• Sont présents à cette réunion, l’équipe, le Product Owner, le Scrum Master, le management, le client et toute autre personne.

• Cette réunion dure maximum 4 heures

4- RETROSPECTIVE

• Une réunion entre l’équipe et le Scrum Master et présidée par ce dernier. Elle a lieu juste après la réunion de « Sprint Review ».

• Durant cette réunion, l’équipe entame une revue auto-critique : les points positifs de fonctionnement sur lesquels l’équipe doit capitaliser ; les points négatifs qu’il faut améliorer et comment les améliorer ; les points à éviter et à ne jamais reproduire

Processus Scrum, un processus itératif pour limiter les effets tunnels et donner de la visibilité en rapport avec la réalité des travaux

Le processus Scrum a été structuré pour limiter les effets du tunnel qui sont sources de gaspillage de temps et de l’argent et caractérisant les méthodes traditionnelles. De ce fait, ces étapes sont cadrées pour : (i) donner une visibilité précise et conforme à la réalité sur le déroulement des travaux, (ii) permettre la prise de décision juste à temps pour éliminer les points de blocage et corriger les dysfonctionnements, (iii) réorienter les efforts vers le plus utile.

Le processus Scrum débute par l’établissement de la Product Backlog qui regroupe l’ensemble des demandes sur le projet.
Le Product Owner fixe les priorités de chaque demande sur la base du ROI et maintient celle-ci à jour pour refléter l’évolution des besoins.
Ensuite, les demandes de la Product Backlog sont ordonnées en priorité décroissante.

Avant de lancer le Sprint (itération), a lieu une réunion de planification de Sprint qui se déroule en deux étapes :
Etape 1 : l’équipe, ScrumMaster et le Product Owner revoient les demandes de priorité supérieure à réaliser durant le sprint, échangent sur l’objectif et le contexte de ces demandes et se mettent d’accord sur la notion de « travail terminé »
Etape 2 : l’équipe se concentre à détailler les demandes, à les transformer en tâches à réaliser durant le sprint et à estimer la durée de réalisation de chaque tâche.

Le sprint (itération), une étape de traitement des demandes convenues avec le Product Owner et rien que ces demandes. Il dure entre 1 et 4 semaines et aucune modification de son but n’est permise.
Le Sprint n’est jamais prolongé au-delà de la durée fixée au départ, bien que l’engagement ne soit pas tenu dans sa totalité.
Durant le sprint une réunion quotidienne a lieu pour faire un point sur l’avancement des travaux et des éventuels obstacles.

A la fin du Sprint, l’équipe montre les travaux réalisés aux parties concernées, les utilisateurs, le management et toute autre personne lors de la « réunion de revue de Sprint »
Celle-ci sera suivie d’une autre réunion dite « Sprint Rétrospective » durant laquelle l’équipe entame une revue auto-critique : ce qui a bien marché, ce qui pourrait mieux marcher, ce qu’il ne faut jamais faire.
Après la réunion « Rétrospective » un autre cycle redémarre en intégrant les points d’amélioration convenus.

La reprise de données «RDD», au-delà de son aspect technique, doit être pensée comme une étape de création de valeur pour l’entreprise.

Le changement des systèmes d’information s’accompagne toujours d’une reprise de données. Une phase cruciale pour la réussite des projets, mais délaissée à la marge des projets et cantonnée à fabriquer des « moulinettes techniques » consistant à transférer les données des anciens vers les nouvelles cases. Ce type d’approche traditionnelle centré excessivement sur la technique peut devenir complexe et source de gaspillage de temps et de ressources. De plus, l’obsession de tout automatiser combinée à l’accroissement des particularismes entraîne la construction d’ « usines à gaz ». Ne voir que par les « moulinettes techniques » a montré la limite de l’approche et ses conséquences : des retards. Une nouvelle approche s’impose pour équilibrer la vision technique et l’orienter vers le plus utile à l’entreprise.

Positionner la reprise des données dans une perspective de création de la valeur pour l’entreprise

Les données du système existant sont le résultat des années de fonctionnement de l’entreprise, certaines sont relatives à des produits ou contrats qui ne sont plus commercialisés, d’autres manquent de cohérence avec d’autres données de l’entreprise, sans parler de celles qui sont complètement obsolètes. Par conséquent, une approche par segmentation et orientée vers les fondamentaux de création de valeur vous évitera de reproduire ces imperfections dans le système cible.

La nouvelle approche de « RDD », guidée par l’impératif « création de valeur », saura orienter et ajuster les deux leviers techniques et métiers pour bâtir une solution en adéquation avec les intérêts de l’entreprise.

Figure 1 : Une démarche en 3 grandes étapes

Les grandes étapes de cette nouvelle approche : de la stratégie à l’exécution

Elle se déroulera en 3 grandes étapes :

1. Stratégie « Reprise de données : RDD » : Cette étape vous permettra de comprendre la nature de la reprise, son étendue, ses influences, ses incertitudes et son niveau de valeur. Une occasion de cadrer le processus de la reprise sur la base des analyses réelles et factuelles, d’anticiper les difficultés et d’orienter l’effort vers le plus important. Autres éléments importants que cette étape vous aidera à expliciter, ce sont les facteurs clés de succès de votre reprise de données. Ces éléments doivent être maitrisés pour dominer les difficultés à venir et vous assurer la réussite de votre mission.

2. Processus « Reprise des données : RDD » : Cette étape vous aidera à dessiner la chaine globale de la reprise des données en corrélation avec les axes stratégiques de l’étape précédente. De même répartir les rôles et les tâches entre la technique et le métier. La réussite de cette étape repose sur votre capacité à optimiser et harmoniser les interactions entre les deux processus dans la durée.

3. Procédé opérationnel « Reprise des données : RDD » : Maintenant que le terrain a été balisé par les deux précédentes étapes, vous pouvez lancer les travaux opérationnels en toute assurance : définir et réaliser les moulinettes techniques, les procédures métiers, exécuter des tests à blanc,… Bref vous êtes sur un terrain connu.

La Reprise De Données « RDD » est un point crucial tant pour la réussite de vos projets que pour la création de la valeur pour votre entreprise, la réduire à une question de « moulinettes techniques » est à coup sûr signé son échec

Le management des situations critiques : Comment passer d’un état d’urgence à une situation maîtrisée

Les directions opérationnelles sont souvent confrontées à des difficultés complexes sur les projets de système d’information. Ces difficultés, à l’origine, apparaissent comme des incidents anodins, et par la suite se révèlent très contraignantes pour la continuité des projets. Celles-ci, par la force des choses, sont obligées d’agir dans l’urgence pour maitriser la situation et circonscrire les risques.

Deux enseignements dans la gestion de ce type de situation :

1. agir vite et communiquer sur les décisions prises, plutôt que de spéculer indéfiniment sur les problèmes.
2. éviter certaines solutions partielles qui retardent les décisions au lendemain et qui aggravent dans presque tous les cas une situation délicate.

Une démarche en 3 étapes :

• « Repérage » : Prise de connaissance du problème, sa situation dans le contexte, évaluation de la criticité de la situation, analyse des risques,..., et mise en place du premier plan d’action et de communication
• « Rapidos » : déclinaison du plan d'actions et de communication pour mettre la situation sous tension et écarter les risques le plus vite possible
• « Aplomb » : une fois les risques écartés, définition d'un plan de stabilisation pour sécuriser et améliorer les solutions mises en œuvre