Session de 30 min
Premiers retours sur le début de la transformation agile d'un éditeur logiciel du secteur public.
Nous avons initialisé une mise à l'échelle de projets scrum : mise en place de scrum sur chaque nouveau projet mais aussi une synchronisation entre les équipes via les scrums de scrums, les synchronisations PO, des rétrospectives inter-équipes et un début de portfolio agile...
Nous verrons les difficultés rencontrées et actuelles et discuterons du changement de culture que cela provoque
6. GIP MiPih
• Structure publique de coopération
inter-hospitalière
– Editeur de progiciels de gestion
– Infogérance (ASP), hébergement
de données de santé
• Activité en forte croissance
– CA 54 M€ en 2012
– 400 adhérents (typologies variées)
– 3 agences, 450 p (140 en R&D)
7. Organisation
Archi, QA …
Pôle R&D (MOE)
Direction Stratégie
…
MOA
Direction Clientèle
Services
Affaires
Diffusion
• Mode MOE / MOA, Cycle en V
• 3 Produits (Applications)
– Gestion Eco. et Financière (Cobol)
– Gestion Admin. Patient (Natstar)
– Gestion RH (Axiant, PHP)
• Multiples acteurs et représentants
des utilisateurs
– Experts Métier (MOA, Diffusion, …)
– Architectes Fonctionnels
– Consultants
Projets PGIH®
Applications
Pôle Infogérance
…
ASP
8. Un projet ambitieux : PGIH®
• ERP de gestion hospitalière
– Refonte des Applications
– Enrichissement de l’offre
• Socle technique
– Java/JEE (GWT, EJB3, …)
– Architecture SOA
– Génération de code (MDD)
– Software factory
(Jenkins, Maven…)
9. Orientation vers l’Agilité
• Initiative de l’équipe « socle technique » en 2010
• Un premier projet en 2011
– Module de gestion des actes (1 équipe de 5 p.)
– Quelques difficultés … mais une expérience encourageante
• Mise en place de Scrum en 2012
– Nouveau produit de GRH (plusieurs équipes), montée en
charge en cours
11. Les projets et les équipes
• 1, puis 2 jusqu’à 6 Equipes
– Regroupées par domaine fonctionnel
– Utilisent des fonctionnalités d’autres équipes
• 1 équipe responsable de l’évolution et la
maintenance du socle
12. Organisation des équipes
• 3 à 7 développeurs
– Dont 1 scrum master
• Product Owner dédié
– 30 à 100% de leur temps
– Origine : MOA ou Architecte produit
• Parties prenantes :
– MOA + Diffusion + sites
• Equipes transverses aux directions du MiPih
13. Mise en place
• Création des backlogs
– Tous les besoins sont dans des backlogs produit
– Ateliers (Personas, Story Mapping, Priority poker…)
• Estimation
– Planning poker en début de release
– Revue de backlog
• Au départ 1 fois/sprint
• Maintenant 1 fois/semaine pour la plupart des projets
14. Cycle de vie d’un sprint
• Sprint planning
• Standup meeting
• Démonstrations
– Avec invitation de toutes les parties prenantes
– mais pas encore des sites
• Rétrospectives
16. Gestion des backlogs
• Backlog dans Excel
– Template « Backlog Manager »
de Henrik Kniberg adapté
• Onglet Product Backlog
• Onglet Features
• Onglet Utilisateurs Ciblés
• Pour chaque User Story ce template
à remplir
17. • Meilleure visibilité des backlogs
– Vue PO, équipe, tableaux de bords
• Equipes multi-sites
• Facilite
– la priorisation
– la synchronisation inter-projets
Mise en place d’un outil
18. Synchronisation & communication inter-projets
• Synchronisation des
sprints et releases
– Sprint de 3 semaines
– Release de 5 sprints
– Plus facile
• Pour planifier
• Pour gérer les
dépendances inter-
backlog
• Pour se familiariser aux
cadences
• Synchronisation entre les PO
– Avant toutes les 2 semaines
– Aujourd’hui toutes les 3
semaines
• Scrum de scrum
– Avant tous les jours
– Aujourd’hui 2 fois /semaine
• Rétrospective inter-équipe
– À chaque fin de release
20. A tous les niveaux
• Apprentissage par la pratique
• Accepter de s’améliorer en prenant le mur
– Création, entretien du backlog
– Sous-estimation des difficultés
– Définition du fini (DoD)
– Respect du DoD
21. Au niveau des équipes
• Niveau de maturité différent
• Maintenir le cap
• Nouvelles pratiques de développement
• Mise en place de pratiques kanban
• Communautés de pratiques
– Tests
– Développement et architecture
22. Au niveau des PO
• Priorisation
• Entretien du backlog
• Interaction avec l’équipe pendant le sprint
24. Accompagnement
• Ne pas aller trop vite (ShuHaRi)
• Formalisation de la mise en pratique de
Scrum au MiPih
• Identification des relais de changement
26. Pas à pas …
• Se concentrer sur les objectifs de chaque étape
– Accepter les priorités dictées par la logique économique
– Se détacher des applications existantes (spectre large)
– Focaliser sur les personas et les US des early adopters
– Refactoring, conception émergente
• Dépasser l’organisation hiérarchique
– Choix des PO
– Evolution des rôles : chefs de projets, experts …
27. En bonne voie !
• Visibilité de l’avancement des projets
– Mise à disposition plus rapide des démos et des produits
• Rapprochement vers les utilisateurs
– Meilleure priorisation des besoins (early adopters)
• Valorisation du travail des équipes
– Auto-responsabilisation, management visuel …
• Décloisonnement progressif de l’organisation
– Travail collaboratif (MOA, R&D, Diffusion …)
• Intérêt croissant des autres entités
– Ateliers Lean startup avec la MOA