1. L’Agilité dans un projet gouvernemental :
Mythe ou Réalité?
Réalité?
Agile Tour Québec 2011
26 octobre 2011

2. Agenda
• Objectif de la présentation
• Présentateurs
• Le projet en bref
• Virage vers l’Agilité
• L’Agilité dans le projet
• Impacts sur les ressources
• Leçons apprises
• Conclusion
2

3. Objectif de la présentation
• Cette présentation vise à partager notre
expérience d'un projet gouvernemental de
grande envergure utilisant l’approche
Agile et de vous démontrer que:
OUI l’Agilité au gouvernement du
Québec, c’est possible!
3

4. Présentateurs
• Guy Rochette – Société Immobilière du
Québec
• Directeur TI à la SIQ;
• Chargé de projet TI sur le projet.
• Line Francoeur – Facilité Informatique
• Architecte d’entreprise et directrice de la pratique
de développement chez Facilité Informatique;
• Architecte fonctionnelle et conseillère stratégique
sur le projet.
4

5. LE PROJET EN BREF
5

6. Le projet en bref
• Services d’Affaires (S@)
• Refonte des systèmes de mission de la SIQ.
• Les faits saillants:
• Passage d’une solution technologique « préfabriquée »… à
une solution pleinement adaptée à la SIQ.
• Passage d’une solution technologique confiée à une firme
externe à une maîtrise d’œuvre SIQ à 100 % dont la
gouvernance est assurée par des gestionnaires «métiers»
provenant des opérations de la SIQ.
6

7. Le projet en bref
Phase 4
Phase 3 Phase 5
• Gestion des
• Gestion des projets • Gestion des Phase 6
Phase 2 projets d’aménageme projets
d’immobilisation nt incluant la • Transfert des
majeurs
Phase 1 • Gestion des PC incluant les facturation (PC (PC)
projets et des
projets contrats contrats entre
• Évaluation d’immobilisation et PG) • Estimation
• Estimation • Demande de employés
de l’état de PG incluant les des projets
• Configuration service et • Demande de
l’immeuble contrats majeurs
des immeubles orientation service –
• Planification • Gestion des simulation
triennale • Historiques immobilière appels d’espace
• DIAPP d’espace • Scénario d'offres
réservation • Transfert
• Mesurage • Gestion des d’immeubles
• Attribution d’espace contrats entre DI
d’espace • Proposition (nature
GPM • Gestion des
• Historique tech.,
clients et
•45 000 j/p •Multi-équipes en
d’occupation • Orientation
Projet en partenariat: approv.,
•Choix: Agile interlocuteurs
• Amortissement projet concession)
•Plus de 35 000 j/p TI parallèle •SIQ
• Budget • Sondages
• Gestion des
bâtiment contractants
•35 ress. TI •Équipes mixtes •Facilité Informatique
d’exploitation clients &
•15 ress. Affaires internes et externes immobilisation
•Pyxis évaluations
• Proposition PG contractants
Phases ultérieures : Gestion des baux, entretien préventif et curatif, gestion des
7
interventions (projets PG)

8. Le projet en bref
Les joueurs de la phase 2:
Architecte
PO des PO
fonctionnel
Architecte de
données Architecte
4 équipes composées de:
entreprise
• 1 « Product Owner » (PO)
• 1 Scrum Master
• 1 Analyste fonctionnel
• 1 Analyste organique
• 3-5 Développeurs
Architecte Architecte
organique techno/sécurité
Chargé de
projet TI 8

9. Le projet en bref
• Phase 2:
• 9 600 j/p TI sur une durée de 12 mois.
• Résultats
• Aucune demande de budget supplémentaire;
• Phase 2 du projet: Livrée le 1er octobre.
« on time » « on target » « on budget »
9

10. VIRAGE VERS L’AGILITÉ
10

11. L’Agilité avec un grand « A »
• Le premier contact
avec l’Agilité
ressemble à:
11

12. L’Agilité avec un grand « A »
• La cible à la SIQ:
• Faire un vrai virage
Agile avec un grand
« A » et réussir le
projet.
• Le C.A. s’est
associé au projet et
le suivait de près.
12

13. L’Agilité avec un grand « A »
• Pour implanter l’Agilité à la SIQ:
• Convaincre la direction:
• Estimer le projet sans barème concret;
• Se commettre sur la vision qui sera livrée à la fin du
projet.
• Obtenir un appui de la direction.
• Investissements en temps et en argent;
• 1 coach Agile en permanence;
• 1 Scrum Master d’expérience;
• Formation des ressources TI et Affaires;
• 1 projet pilote.
13

14. L’Agilité avec un grand « A »
• Premiers constats:
• Ne devient pas Agile qui le veut!!!
• Est-ce que ça vaut la peine ???
• Par où commencer ???
• Est-ce qu’on a réussi?
Oui,
mais la route a été parsemée
d’embûches que nous avons dû
surmonter!
14

15. L’AGILITÉ DANS LE PROJET
15

16. Le Projet
Démarrage - Difficultés
• Carnets de commandes non maîtrisés par les PO.
• Tout le monde cherche son rôle.
• Écrire la méthodologie en même temps qu’on
avance.
• L’écriture des «stories» n’est pas facile. Les PO ont
de la difficulté à en pondre rapidement.
• Les développeurs sont en attente.
• Résultats:
• La vélocité de la 1ère itération est bien en
dessous des attentes!
16

17. Le Projet
Démarrage - Actions
• Intégrer les PO plus tôt dans le processus pour
qu’ils s’approprient le contenu.
• Donner le temps aux PO de s’approprier le carnet de
commandes et d’écrire quelques stories avant de
démarrer le projet.
• Pour les premiers projets Agile, préparez les
analystes fonctionnels.
• La formation a ses limites, le concret reste la meilleure
méthode d’apprentissage.
17

18. Le Projet
Portée - Difficultés
• Les projets réalisent des stories facultatives ou hors
vision.
• Les PO ont de la difficulté à écrire des stories.
• La priorisation des stories est par projet et non vers
une cible commune – vision SIQ.
• La communication entre les PO n’est pas adéquate.
• Les équipes travaillent en silo.
18

19. Le Projet
Portée - Actions
• Implication des Scrum Master pour supporter les PO
dans l’écriture des stories.
• Élaboration d’un périmètre minimum.
• Nomination d’un PO des PO.
• Contrôle des carnets de commandes avant chaque
itération.
19

20. Le Projet
Équipes - Difficultés
• Manque de transparence des joueurs des équipes
dans les mêlées quotidiennes.
• L’engagement est en dessous des capacités des
équipes.
• Les développeurs se gardent des marges de
manœuvre.
• L’autogestion n’est pas innée: elle s’apprend. Les
équipes sont quelque peu désorganisées.
20

21. Le Projet
Équipes - Actions
• Augmenter le coaching Agile.
• Redéfinir le rôle des analystes organiques.
• Changer les mentalités.
21

22. Le Projet
Qualité - Difficultés
• La notion de « Terminé » n’est pas respectée.
• La qualité « Production » n’est pas au
rendez-vous.
• Les essais sont escamotés.
• Les régressions sont omniprésentes.
22

23. Le Projet
Qualité - Actions
• Revoir la définition de « Terminé ».
• Ajouter du temps pour les essais dans les
estimés.
• Élaborer une stratégie d’essais.
• Instaurer le TDD.
23

24. Le Projet
Gestion projet - Difficultés
• Impossible de suivre le projet comme on a l’habitude
de le faire.
• Nombre de points varie d’une équipe à l’autre.
• Impossible de dire si les 4 équipes arriveront à
destination en même temps.
• Les équipes sont mal équilibrées. Les caractères de
certains membres sont incompatibles.
• Les problèmes ne sont pas remontés rapidement.
24

25. Le Projet
Gestion projet - Actions
• Mettre en place un Scrum de Scrum.
• Suivre rigoureusement:
• Les graphiques de progression;
• Les bilans d’itération;
• L’engagement en terme de points de chaque équipe à
chaque début d’itération.
• Ajuster la structure de gouvernance.
25

26. IMPACTS SUR LES
RESSOURCES
26

27. Impacts sur les ressources
TI
• Quand on pense Agile, on pense toujours:
• Pas facile pour les gens d’affaires!
• Pas seulement pour eux:
• Les ressources TI doivent prendre un virage important;
• Tout le monde cherche son rôle;
• La zone de confort n’existe plus;
• Il n’y a plus de repère;
• On ne peut plus se cacher derrière une méthodologie avec
une approche en cascade « waterfall ».
27

28. Impacts sur les ressources
TI
• Chargé de projet:
• Un point = combien de jours?
• Il n’y a plus de bien livrable pour suivre le projet!
• Architecte:
• Un carnet de commandes n’est pas une architecture
détaillée!
• Tout est flou, on va nulle part!
• Analyste fonctionnel:
• Je n’ai pas de P250 pour travailler!
• Comment veux-tu faire un P490 avec des stories?
• Développeur:
• Quoi, me commettre sur des estimés et m’engager!
28

29. Impacts sur les ressources
TI
• Les équipes de projet ont l’impression
d’être sur:
• Vous voulez changer la fin de l’histoire:
Il faut s’adapter!
29

30. Impacts sur les ressources
TI
• Les rôles changent, tout le monde a une place.
• Garder le cap et la portée prévue au jour le jour.
• Même si on est Agile, ça prend de l’architecture!
• Les nouveaux rôles:
• Les architectes;
• Les analystes fonctionnels;
• Les développeurs.
• Les nouveaux joueurs:
• Les analystes organiques;
• Les Scrum Master.
30

31. Impacts sur les ressources
TI
• Des nouvelles équipes de
projet qui:
• Travaillent en collaboration;
• Tournent au quart de tour;
• S’adaptent rapidement;
• Réagissent vite.
• Résultats:
• Des équipes qui livrent!
• Et qui ont du plaisir à le faire!
31

32. Impacts sur les ressources
Affaires
• 1er défi, trouver des • 2ème défi:
« PO » à temps plein: • Leur apprendre leur rôle
dans un projet Agile;
• Les intégrer dans un projet
Remplacer
qui roule;
Bon profil
• Leur transférer les
connaissances et la vision
du projet.
Impact
opérations • Sans leur faire peur!!!
Expert
domaine
d’affaires
32

33. Impacts sur les ressources
Affaires
• Les nouveaux joueurs:
• Les « Product Owner » (PO);
• Le PO des PO.
• Les PO et le PO des PO doivent:
• Avoir le support de la Haute Direction;
• Prendre des décisions sur le champ!
• Pas un comité qui prend 5 jours pour
commenter un dossier fonctionnel!
33

34. Impacts sur les ressources
Gestionnaires de projets
• Les nouveaux rôles:
• Chargé de projet.
• Les nouveaux joueurs:
• Scrum Master des Scrum Master.
• Au début, tout le monde viendra chialer
dans votre bureau!
34

35. Impacts sur les ressources
Gestionnaires de projets
• Nouveau style de gestion:
• Ne pas faire d’ingérence;
• « nose in, hands off »
• Être impliqué activement;
• Être bien informé;
• Être proche des équipes.
35

36. LEÇONS APPRISES
36

37. Les pièges à éviter
• Évitez de suivre l’approche Agile « by the book »,
prenez ce qui a du sens pour votre organisation.
• Ce qui est bon pour certains ne l’est pas
nécessairement pour vous!
• Évitez de considérer l’approche Agile comme étant
« LE » facteur clé de succès d’un projet… c’est
« L’UN » des facteurs.
• Ne vous concentrez pas seulement sur l’implantation
de l’Agilité, attention vous avez un projet à livrer!
37

38. Les pièges à éviter
• Évitez de vous poser la question: « Est-ce qu’on est
100% Agile ? »
• Visez le juste assez « Just enough ».
• Évitez de prendre pour acquis que tout le monde
prendra le virage facilement.
• Tout le monde n’adoptera pas l’Agilité au même rythme!
• Évitez de prendre les crises à la légère.
• Intervenez rapidement sinon vous risquez de perdre
l’engagement des ressources et de démotiver les
troupes! 38

39. Les facteurs clés de succès
• Au niveau de la direction:
• Allez chercher un engagement concret;
• Demandez-leur de prendre des décisions rapides;
• Faites-en une direction « Agile ».
• Au niveau du projet:
• Ayez les bonnes ressources aux bons endroits et avec
la bonne expertise. N’hésitez pas à les former;
• Ayez des joueurs clés avec du leadership;
• Équilibrez vos équipes, allez chercher des ressources
externes qui seront complémentaires à vos
ressources. 39

40. Les facteurs clés de succès
• Au niveau Agile:
• Gérez le changement dès le début;
• Adaptez l’Agilité à la culture de votre organisation:
• N’oubliez pas que l’Agilité c’est 4 valeurs et 12 principes axés
sur le travail d’équipe et la communication en face à face
(manifeste agile). À partir de là – tout est possible !!!
• Implantez l’Agilité par palier:
• Prenez le temps de bien maîtriser un concept avant de passer
au suivant et ce, tout en vous questionnant sur la pertinence
du prochain concept pour votre organisation;
• Prenez le temps de bien définir les nouveaux rôles;
• Faites-vous appuyer pendant la transition.
40

41. Les facteurs clés de succès
• Au niveau des appuis externes:
• Soyez le maître d’œuvre, seul vous connaissez
suffisamment votre organisation;
• Développez un partenariat d’affaires avec vos
fournisseurs externes, mettez fin aux célèbres DDC.
41

42. Les facteurs clés de succès
• Et surtout:
• Il faut se donner le droit à l’erreur.
• Ne prenez pas vos erreurs comme des échecs!
• Il faut parfois déroger des concepts Agile pour donner
le temps aux équipes de s’approprier le tout.
• L’agilité ne s’atteint pas en 6 mois!
• Vous avez des forces, misez sur celles-ci et mettez-les
en valeur dans votre approche agile.
• Ne jetez pas tout votre savoir et votre expérience.
• N’oubliez pas qu’il y a autant de recettes qu’il y a
d’organisations!
42

43. CONCLUSION
43

44. Conclusion
• L’agilité dans un projet gouvernemental, ce n’est pas
un mythe mais bien une réalité!
• Est-ce une recette pour mettre fin aux dérapages des
grands projets informatiques?
Faites comme nous!
Passez du rêve à la réalité!
Soyez dans le feu de l’action!
Embarquez, c’est l’avenir!
44

45. grochette@siq.gouv.qc.ca lfrancoeur@facilite.com
MERCI!
45