Agile AIM – Agile Way of Working Harmonisation stratégique & transparence Version /03/2015

© Fedict All rights reserved | p. 2 Mi-2014, l'initiative visant à collaborer avec les fournisseurs en utilisant Agile a été lancée sous la direction du gestionnaire du programme Luc Van Tilborgh. Le but était, et reste encore, d'instaurer une collaboration meilleure et plus étroite entre toutes les parties. Un projet pilote a tout d'abord été réalisé avec le fournisseur qui exploite la plateforme FSB. Après un accueil positif tant auprès du fournisseur que des collaborateurs du programme AIM, il a été décidé fin 2014 d'étendre la méthode Agile aux autres fournisseurs. Contexte L'alignement stratégique du fonctionnement opérationnel veille à ce que le programme AIM atteigne ses objectifs, tels que spécifiés dans la stratégie du programme. Une transparence et une communication améliorées vis-à-vis des parties prenantes (tant les parties externes que les collaborateurs internes qui ne font pas partie du fonctionnement Sprint opérationnel) permettent que les objectifs individuels et communs soient clairs et atteints plus facilement. L'intégration des interactions du Service Management dans le fonctionnement Agile du programme doit veiller à ce que le développement des webservices et de la plateforme de support se déroule plus facilement (et vice-versa). Alignement stratégique Transparence & communication Interaction avec le Service Management Points d'amélioration Aujourd'hui, l'Agile AIM (« Agile Way of Working ») est intégré dans l'ensemble du programme AIM, mais comme toute méthode évolue et doit s'adapter aux circonstances changeantes, il faut toujours poursuivre l'amélioration continue. Dès lors, nous identifions aujourd'hui les points d'amélioration suivants : Interaction avec l'assurance qualité La clarification des activités d'assurance qualité dans le cadre du fonctionnement Agile du programme veille à ce que tout le monde soit informé des contrôles qui seront intégrés pour que la qualité du programme et de ses réceptions soit surveillée. Interaction entre différents backlogs L'amélioration de l'interaction entre les différents product backlogs assurera une meilleure gestion des interdépendances.

Stratégique Tactique Opérationnel © Fedict All rights reserved | p. 3 L'extension de l'AWoW d'AIM ne constitue pas une mise en œuvre intégrale du cadre SAFe, mais s'inspire de certaines meilleures pratiques découlant du cadre SAFe et tente de les traduire dans la réalité du programme. Extension du fonctionnement Agile – SAFe AIM AIM Portfolio AIM Program backlog AIM Program Increment AIM Roadmap AIM fonctionnement Sprint AIM Product backlogs Alignement stratégique Transparence & communication Interaction avec Service Management Priorité de SAFe AIM Interaction avec l'assurance qualité Interaction entre différents backlogs

1. Stratégique : AIM Portfolio Niveau stratégique Structuré via KanBan, prioritisé via WSJF, réparti par type : intégration & orchestrationKanBanWSJF Se composant de business epics et d'architectural epics, ayant chacun un epic ownerbusiness epics architectural epicsepic owner Structure KanBan = « In > Qualify > Ready > Execute > Done » Fait à nouveau l'objet d'une définition périodique des priorités via WSJF Responsable de la gestion du portfolio AIM : PMT, sous la direction du sponsor du programme Sélection & définition des priorités © Fedict All rights reserved | p. 4 « intégration » « orchestration »

1. Stratégique : AIM Portfolio (suite) Niveau stratégique La gestion du portfolio permet d'affiner encore davantage les epics (qualifier et quantifier) lors de la phase « Qualify », en utilisant un « lightweight business case ».lightweight business case © Fedict All rights reserved | p. 5 1.« In » - Tous les epics (business ou architecture) s'y retrouvent, sous la forme d'une idée minimale. Cette phase constitue le premier « catch- all » de toutes les nouvelles idées. Tous les membres du programme peuvent, via le PMT, identifier des epics à reprendre dans le portfolio. 2.« Qualify » - Pour arriver à la phase « qualify », le forward-looking statement (FLS - déclaration prospective) doit être complété par l'epic owner respectif. Ces items sont prioritisés périodiquement via WSJF. Une sélection des epics les plus prioritaires est ensuite analysée et affinée (éventuellement via un « lightweight business case »). Après une décision positive du PMT, un epic peut être transféré pour exécution vers la phase suivante. 3.« Ready » – Il s'agit de l'ensemble des epics prêts pour exécution. Ceux- si sont prioritisés périodiquement en même temps que les epics en exécution (« execute ») via WSJF. 4.« Execute » - Les epics ayant la plus grande priorité sont élaborés dans le cadre du fonctionnement Agile du programme, tout en tenant compte de la capacité disponible. 5.« Done » - Un epic n'est terminé que quand le PMT décide que toutes les réceptions nécessaires ont été acceptées ou quand — si les features appartenant à cet epic n'ont pas encore toutes été terminées — le PMT décide d'arrêter cet epic et de le clôturer. Light- weight business case

2. Tactique : AIM Program backlog Le Program backlog se compose de « features » provenant des epics du Portfolio backlog, ainsi que via un afflux au niveau tactique* (par exemple via des New Service Requests [NSR] de consommateurs)Program backlog features Il incombe à l'epic owner (ou service owner) de traduire l'epic ou NSR en une feature. Cela peut se faire si nécessaire en collaboration avec les membres du programme concernés. Chaque feature sera ensuite répartie en user stories via une grooming session. Ce point est traité dans les slides suivants. Les personnes présentes à la réunion de définition des priorités (PMT à l'exception du sponsor) sont responsables de la gestion et de la définition périodique des priorités du Program backlog Program backlog Feature Program backlog Feature 1. Traduction en features © Fedict All rights reserved | p. 6 Niveau tactique Feature Service owners 1 Feature 2. Définition des priorités des features (*) L'évolution à long terme du PersonService & de l'EnterpriseService est toutefois traitée dans le portfolio AIM Priorisation PMT sauf Sponsor

Program backlog 2. Tactique : Grooming session La Grooming session a pour objectif : de traduire les features prioritaires du program backlog en user stories d’estimer les différentes user stories en charge de travail (via story points) de faire prendre aux différentes équipes –par délégation*- une décision en ce qui concerne le planning pour le Program Increment suivant (= 3 sprints de 9 semaines) d’identifier et d’harmoniser les dépendances potentielles entre les features et les user stories Feature User story Estimate © Fedict All rights reserved | p. 7 Niveau tactique Feature User story Estimate User story Estimate Scrum Master Product Owner Service Owner Specialist (facultatif) Grooming session Estimate Product backlogs User Story PLAT Les features les plus prioritaires sont sélectionnées pour traduction en user stories 2.Chaque feature est répartie en user stories + estimée en termes d'effort (somme des story points) 3.Chaque user story est incluse dans un product backlog (PLAT ou WS). 4.Sur la base de l'effort estimé par feature ainsi que de la priorité attribuée, celle-ci est prévue dans les program increments suivants Program Increment (PI) F FF 4 (*) Pour des raisons pratiques, il a été choisi d'établir un planning par délégation plutôt qu'avec l'ensemble de l'équipe Feature User story Estimate Feature 1 F Product backlogs User Story WS

Program Increment (PI) JanvierMars Mai Roadmap Sécurité décroissante : plus le temps s'écoule, plus la réception de certaines features est incertaine 2. Tactique : Program Increments & AIM Roadmap Program Increment (PI) Feature 1 PI = 3 sprints de 9 semaines Un Program Increment (« PI ») couvre 3 sprints (au total 9 semaines) des différentes équipes Agile et se compose de la réception d'un ensemble donné de features de l'AIM Program backlogProgram Increment features Feature L'AIM Roadmap reprend un aperçu des features prévues dans les program increments en cours et futurs. Le roadmap est régulièrement adapté (après chaque Program Increment).AIM Roadmap © Fedict All rights reserved | p. 8 Niveau tactique Feature 1 Feature 2 Feature 3 Feature 5 Feature 6 Feature 7 Feature 4

2. Tactique : Communication des priorités Le résultat de la grooming session sera communiqué conjointement par les product owners aux membres de la plateforme et le backlog du service web via une séance d'information distincte (y compris la communication via Confluence). Program Increment (PI) FF F © Fedict All rights reserved | p. 9 Niveau tactique Communication Product owners 1.Communication des epics prioritaires du Portfolio backlog 2.Communication des features prioritaires du Program backlog 3.Communication des user stories liées des deux Product backlogs 4.Communication du planning pour le program increment suivant 5.Identification des dépendances potentielles et des problèmes bloquants Program backlog Feature Product backlogs User Story PLAT 3 Product backlogs User Story WS

3. Opérationnel : Fonctionnement Sprint Chaque sprint ou itération mettra plusieurs user stories en œuvreitération Les Product backlogs ne sont pas seulement alimentés par les user stories issues des features, mais aussi par les user stories venant du Service management (p. ex. modifications provenant du Problem management). Cela concerne l'afflux opérationnel des user stories (voir le slide suivant, Interaction avec le Service management) Program Increment (PI) Feature User story Estimate 2 Product backlogs : Réunions Agile : Réunion Sprint Planning Réunion Sprint Review Réunion Sprint Retrospective Réunion Daily stand-up Réunion Sprint Planning Réunion Sprint Review Réunion Sprint Retrospective Réunion Daily stand-up Estimate Story points © Fedict All rights reserved | p. 10 Niveau opérationnel Product backlogs User Story PLAT Product backlogs User Story WS

User Story Product backlog User Story Platform (PLAT) Product backlog User Story Webservices (WS) 3. Opérationnel : interaction avec le Service management Les Product backlogs ne sont pas seulement alimentés par les user stories issues des features, mais aussi par les user stories venant du service management, p. ex. problem management, availability & capacity management,... Des exemples concrets sont les modifications provenant des bugs/issues/problèmes, liés aux services web ou aux composants de la plateforme. Il incombe aux product owners concernés, et le cas échéant aux service owners concernés, de trouver un équilibre dans les marges prévues entre les deux types d'user stories sur la base de la priorité et de la capacité Product development (Agile AIM) + Service management (ITIL) Niveau opérationnel Event Incident Ticket Work- around Problem Record P. ex. Problem management Resolution / Change © Fedict All rights reserved | p. 11

4. Aperçu Au sein de Safe AIM, nous identifions 3 niveaux, à savoir : stratégique, tactique et opérationnel, ayant chacun leurs propres instruments – Medium – et responsable © Fedict All rights reserved | p. 12 InstrumentMediumResponsables Stratégique AIM Portfolio Portfolio backlog Lightweight business case Epic PMT Epic owner Tactique Program backlog AIM Roadmap Feature Epic owner Service owner Réunion de définition des priorités Grooming session Opérationnel Product backlog Sprint backlog User story Product owner Scrum coach Réunions Sprint

4. Aperçu (suite) Chaque niveau comprend ses propres « instruments » (epic / feature / user story) et dispose d'un canal Intake « propre » : © Fedict All rights reserved | p. 13 Stratégique Tactique Opérationnel Portfolio backlog = Epics Program backlog = Features Cascade Intake Par exemple développement d'un nouveau composant Intake Par exemple NSR Product backlog = User stories Product backlog = User stories Cascade Intake Par exemple Bugs

5. Supplément : Rapports Agile & SAFe démontrent que le logiciel fonctionnel reste encore la meilleure preuve en ce qui concerne l'avancement et la création de valeur, sans toutefois supprimer la nécessité de solides rapports. Les rapports permettent de donner à toutes les personnes concernées un aperçu correct et adéquat du statut/de l'avancement des travaux.rapports Agile AIM – AWoW permet d'établir le cas échéant un rapport solide à chaque niveau (stratégique, tactique et adéquat). Pour ce faire, on choisira d'utiliser autant que possible le rapport Jira existant. Exemple « Feature progress report » Story points © Fedict All rights reserved | p. 14

© Fedict All rights reserved | p. 15 Les activités d’Assurance Qualité exécutées veilleront à ce que le cycle de vie des epics soit géré de manière adéquate tant au niveau stratégique que tactique et opérationnel. Concrètement, l'équipe QA peut exécuter les activités suivantes : o Contrôle de l'identification, de la qualification et de la définition des priorités des epics dans l'AIM portfolio ; o Contrôle de la traduction d'une sélection des epics prioritaires en features et user stories ; o Contrôle de la définition des priorités des features dans le program backlog ; o Contrôle de la gestion de documents (Confluence) tout au long du cycle de gestion des items susmentionnés ; o Contrôle du fonctionnement Sprint concerné (via la participation aux réunions sprint planning, sprint review & sprint retrospective + étude des daily stand-ups) ; o Contrôle du processus de déploiement o Contrôle de l'approche de test. 5. Supplément : Assurance Qualité (QA)

© Fedict All rights reserved | p Glossaire explicatif EpicLes Epics sont des initiatives d'une envergure relativement importante qui doivent être analysées plus en détail avant d'être exécutées. Une distinction est établie entre les business epics et les epics d'architecture. Les Business epics répondent à une nécessité « business » bien déterminée d'un client ou d'un utilisateur final. Les epics d'architecture sont essentiellement de nature technologique, c.-à-d. qu'ils forment souvent la base nécessaire d'un ou plusieurs business epics. FeatureLes features sont des items qui offrent une certaine valeur ajoutée à un utilisateur final. Elles font toujours partie d'un epic bien déterminé. Elles se trouvent, d'un point de vue logique en termes d'ordre de grandeur de mise en œuvre, entre les epics et les user stories. Les epics ont une envergure plus importante vu qu’ils peuvent couvrir un ou plusieurs PI, tandis que les user stories sont établies de manière telle qu'elles peuvent être élaborées dans un seul sprint. PortfolioLe portfolio est l'instrument qui regroupe via KANBAN tous les epics d'intégration et d'orchestration au niveau du programme AIM. Portfolio backlogLe portfolio backlog comprend tous les epics approuvés (c.-à-d. que le PMT a décidé d'exécuter). De là, les epics du portfolio sont ensuite répartis par l'epic owner en features. Réunion de définition des priorités Lors de la réunion de définition des priorités, il est décidé au niveau tactique, par le PMT, à l'exception du sponsor, de la priorité des features. Product backlogLe product backlog comprend toutes les user stories liées tant aux features à développer pour les sprints actuels et futurs que les user stories issues du Service management (corrections de bugs,...) et dans le cadre de l'équipe interne (p. ex. à la suite d'une réunion sprint retrospective) Program backlogLe program backlog comporte toutes les features qui sont approuvées pour exécution par le PMT. Elles affluent tant du portfolio que d'un intake local au niveau tactique. Ces features font à leur tour l'objet d'une mise en priorité lors de la réunion de définition des priorités. Grooming sessionLa Grooming session a pour objectif ce qui suit : traduire les features prioritaires du program backlog en user stories, estimer les différentes user stories en termes de charge de travail et, enfin, faire prendre aux différentes équipes –par délégation- une décision en ce qui concerne le planning pour le Program Increment suivant

© Fedict All rights reserved | p Glossaire explicatif (suite) Roadmap Le roadmap présente un aperçu des features prévues dans les program increments et releases en cours et futurs. Celui-ci est adapté périodiquement dans le cadre de chaque grooming session. Sprint Un sprint ou itération se compose de la réception d'une certaine valeur ajoutée sous la forme d'un logiciel fonctionnel par l'équipe Agile. Un sprint dans Agile AIM dure 3 semaines. Sprint backlogLe sprint backlog comprend le travail du sprint suivant et se compose d'une sélection d'user stories provenant du product backlog. User storyUne user story comprend l'aspect détaillé de la mise en œuvre de certaines exigences fonctionnelles et non fonctionnelles (= regroupement de plusieurs tâches). Généralement, une user story peut être exécutée dans un seul sprint.