© 2013© 2013

Stéphane Lecuyer & Frédérick H. Stoltz

AGILE et le PMO

Conférence présentéeà

Agile Montréal 12 septembre 2013

1

© 2013

Qui sommes-nous?

� Frédérick H. Stoltz, PMP, ITILParallèlement à son engagement en tant que consultant en gestion de projet, depuis 22ans il a toujours été impliqué dans l’amélioration continue et la professionnalisation des métiers en gestion de projet.

• Au cours des 5 dernières années, il a été invité à 6 reprises par le bureau chef du PMI à contribuer à l’évolution de la certification PMP® ainsi qu’à l’accréditation des REP®

• Frédérick mise principalement sur l’amélioration continue des relations entre les entités, ressources et processus des organisations afin de favoriser l’efficacité et surtout l’efficience dans l’atteinte des objectifs de ses clients

� Stéphane Lécuyer, CSM, CSP, CST, CoachDepuis 25 ans, parallèlement à son engagement technique, il a toujours été impliqué dans la gestion d'équipes informatiques en tant que chef de projet ou directeur de service.

• Depuis plus de 8 ans, il soutient activement les méthodes Agiles et agit principalement comme facilitateur et accompagnateur Agile pour les organisations désirant intégrer ce type d'approche

• Stéphane mise principalement sur le capital humain des organisations et favorise toujours la collaboration afin de créer des environnements productifs où il fait bon vivre

2

© 2013

Objectifs

� Discuter de l’alignement de la gestion de projet organisationnelle (GPO) en fonction de l’Agilité

Présenter certaines adaptations possible du PMO pour des projets SCRUM

Présenter des pistes de réflexion pour adapter la GPO en fonction des valeurs Agile

Légende:

PMO Project Management OfficeGPO Gestion de projet organisationnelle

3

© 2013

� Pour vous, un bureau de projet Agile, c’est:

4

Qu’est-ce qu’un « PMO Agile »?

4. Autre chose?

SCRUM!

AGILE!!

SCRUM!

2. Mieux intégrer le changement plutôt que suivre

systématiquement les plans?

3. Faire des rencontres de 15 minutes?

1. Gérer votre portefeuille en Sprint?

© 2013

Agile et Scrum

� Le terme “Agile” représente une série de valeurs et de principes appliquées au développement logiciel

� Le terme “Scrum” représente un cadre pour la gestion de projet favorisant:� l’application des valeurs Agile;

� la création de valeur ajoutée;

� un développement par vague (rolling wave planning);

� l’inspection et l’adaptation fréquente (Deming/PDCA);

� l’amélioration continue;

SCRUM!

AGILE!

5

© 2013

� Nous découvrons comment mieux développer des logiciels

� par la pratique et

� en aidant les autres à le faire

� Ces expériences nous ont amenés à valoriser :

� Nous reconnaissons la valeur des seconds éléments,mais privilégions les premiers.

6

>

Les valeurs Agile

>

>

que les processus et les outils

qu’une documentation exhaustive

que la négociation contractuelle

que le suivi d’un plan

Les individus et leurs interactions

Des logiciels opérationnels

La collaboration avec les clients

L’adaptation au changement

>solutions

© 2013 7

SCRUM ET LE PMO

Deux des préoccupations du PMO:

1. La gourvernance• Processus de « go/no-go »

2. Maîtrise et contrôle des projets • Gestion des Demandes De Changements (ddc)

© 2013

Deux réalités de nos/vos contextes!

La gestion

� En général on contrôle beaucoup plus qu'on planifie

� Par contre la gestion c’est

� Planifier ET contrôler

Si on fait de la bonne gestion

� IF(maturité)� AND(maîtrise/compétence)

• AND(communication)– THEN(latitude!)

8

© 2013 9

Légende :

Scrum et adaptations mineures à la

gestion de projet

Gestion de projet classique

Sprint 0 Sprint 1 … N

Scrum et gestion de projet largementadaptée

Deux approchescomplémentaires!

Scrum

?

Scrum

?

Gestion de projet classique

Scrum

Adaptation Scrum

Scrum

?

© 2013

Comment tirer profit des 2 approches

� Scrum suggère des méthodes et des outils pour : � Livraison rapide et flexibilité

� Accent sur la qualité interne et externe

� Participation directe de l’entreprise dans la direction du projet

� Plus grande visibilité

� Plus grande capacité d’anticiper les dépassements

� La gestion de projet classique suggère des méthodes et des outils pour : � Consolider l’ensemble des plans de TI et d’affaires du projet

� Balancer les demandes concurrentielles

• Entre les projets– portefeuille, matriciel

• À l’intérieur du projet

� Gestion intégrale des risques au niveau du projet

• Planification, mesure, qualification, quantification et réponses

10

� 2 objectifs communs

Maximiser les

avantages

Minimiser les

risques

© 2013

Comment arrimer gestion de projet classique et

Scrum?

Nous vous proposons de discuter d’un élément de

solutions pour 2 d’entres eux :

� Gouvernance de projet

� Comment arrimer vos « porte-projets » (gates) et les sprints?

� Maîtrise et contrôle des projets

� Comment gérer les demandes de changement (DDC)?

11

© 2013

Scrum, la gouvernance et la gestion de projet :Qui sont les acteurs?

12

Gestion de projet

classique

Planification financière

Gouvernance(porte-projets)

Scrum(sprints)

Portefeuille

PMO

Comité

Directeur

Gestion de

Projet

© 2013

Monitoring et contrôle

Charte de projet

MOP / PMP

Scrum, la gouvernance et la gestion de projet :Voici une proposition de solution

13

ExécutionDémarrage Planification ClôtureGestion de projet

classique

Planification financière

Gouvernance(porte-projets)

Scrum(sprints) S

pri

nt

Sp

rin

t

Sp

rin

t

Sp

rin

t

Sp

rin

t 3 à

n

Sp

rin

t 2

Pla

nif

.et

exec

Sp

rin

t 1

Pla

nif

. et

exéc.

Sp

rin

t 0

Se

tup

40 321

Planification annuelle, business caseROM, ordre de grandeur

(-25 à + 75 %)

Budget(-15 à + 25 %)

Définitive(-5 à + 10 %)

© 2013

Les DDC et Scrum

� Qui approuvera les DDC s’il n’y a pas de DDC?� Chèques en blanc?

� Y a-t-il perte de contrôle de l’évolution des lignes de référence (baselines)?

� Qui approuve les changements qui ont un impact sur les avantages et les échéanciers?

� Nous sommes une organisation ayant des obligations envers nos clients :� Nous avons besoin de règles et de contrôle de direction sur

nos projets.

14

© 2013

DDC formelles approuvées par la gouvernance :

y en a-t-il en Scrum?

� « Noui… »

� Avec Scrum, le responsable de produit approuve certains changements relatifs uniquement à la portée, sans aucun impact ailleurs.

� Pour changer tout autre élément du projet, c’est-à-dire concernant le temps ou les coûts et avantages, le responsable de produit doit consulter une instance supérieure soutenue par un plus grand formalisme (comité directeur, gouvernance).

15

PortéeQualité et spécifications

© 2013

Pourquoi faut-il adapter la gestion des DDC pour

Scrum?

� Responsabiliser l’équipe Scrum� Il faut s’assurer que le « bon niveau d’expertise » prenne la

« bonne décision ».• Qui est mieux placer pour comprendre les enjeux de

changer « x par y »?• Exemple :

– Lors d’un comité directeur, un commanditaire de projet (qui au quotidien est V.-P. d’une unité d’affaires et pour qui « API » est une sorte de pommes) a-t-il les compétences requises pour déterminer convenablement si, à coûts, avantages et délais égaux, l’utilisation de Java ou .NET sera un meilleur choix pour réaliser une partie d’une API?

� Il faut favoriser l’intégration des changements.

� Diminuer les délais d’approbation� Il faut favoriser la rapidité d’exécution et la prévisibilité.

16

© 2013

Scrum, la gouvernance et les DDCVoici une proposition de solution

17

Cas de figure de DDC Comité directeur

Resp. de produit

Équipe Scrum

Enlever la fonctionnalité « A » sans impact sur les coûts

et avantages ni sur le temps de livraison I A R/C

Ajouter la fonctionnalité « D » sans impact sur les coûts

et avantages ni sur le temps de livraison I A R/C

Modifier la fonctionnalité « X » avec pour impact de

diminuer de 20 000 $ les bénéfices attendus A R C

Modifier la fonctionnalité « W » avec pour impact

d’augmenter de 5 000 $ les coûts A R C

Changer la fonctionnalité « Z » avec pour impact de

retarder la livraison du projet de 3 semaines A R C

Altérer comment la fonctionnalité « Y » sera

développée, sans impact sur les objectifs du sprint I I R/A

Responsible (R) : « fait » Accountable (A) : « approuve »Consulted (C) : « contribue » Informed (I) : « informé »Légende

© 2013 18

AGILE ET LE PMO

© 2013

Portefeuille

PMOComité

Directeur

Projet

F a i t• Aligne la

sélection des projets sur la vision et les besoins corporatifs

• Propose des scénarios alternatifs à la haute direction pour équilibrer « offre et demande »

A p p r o u v e• Le début de

projets en fonction d’un portefeuille équilibré et approuvé par la haute direction

F a i t• Offre du support

et de l’encadrement aux gestionnaires du Portefeuille, Comités directeurs et chefs de projets pour assurer la livraison des bénéfices visées

A p p r o u v e• Les façons de

faire de la gestion de portefeuille et de la gestion de projet

F a i t• Pilote l’évolution

des projets• Offre du support

lorsque le chef de projet est incapable de résoudre une situation hors de son contrôle

• Assure le lien entre le projet et la vision corporative de façon continue

A p p r o u v e• Autorise le

passage de portes projet en fonction de démonstrations de maitrise par les chefs de projets

• Approuve les baselines et leurs changements

• Approuve les stratégies proposées par le projet

F a i t• La planification

et le contrôle du projet

• Livre la valeur désirée

A p p r o u v e• L’utilisation des

budgets pour l’atteinte des objectifs du projet

• Les multiples scénarios de gestion des menaces et opportunités qui seront entérinées par le CoDir

La Gestion de Projet

Organisationnelle

19

© 2013

AGILE et la Gestion de Projet Organisationnelle (GPO)

1. Individus et interactions …• Coacher plus que diriger• Favoriser les équipes-produits dédiée• Et non “équipes-projets dédiées”• Impliquer les RH pour construire des meilleures équipes

2. Des logiciels (solutions) opérationnels …• Livrer souvent et régulièrement• Qualité “built-in”

3. Collaboration avec les clients …• Favoriser implication du client tout au long du

projet• Favoriser le contact direct avec client

utilisateur4. Adaptation au changement …

• Plus de pouvoir au Product Owner• Favoriser initiative amélioration au niveau

projet• Apprendre en réalisant (empirisme)

20

© 2013

AGILE et la Gestion de Projet Organisationnelle (GPO)

1. Individus et interactions …• Équipe-produits vs équipes-projets• Promouvoir les équipes autonomes• Augmenter le focus “livraison”

2. Des logiciels (solutions) opérationnels ...• Adaptation des “portes-projets”• Favoriser les échanges horizontaux entre les entités responsables de la

livraison • Arrimage, gestion des changements (d’affaire)• Promouvoir le rolling wave (Scrum)

3. Collaboration avec les clients ...• Maximiser la représentativité de tous les “clients”• Favoriser une plus grande transparence entre les instances

de la GPO

4. Adaptation au changement …• Révision fréquente du portefeuille• Révision fréquente des pratiques en fonction du

feedback des projets• Favoriser l’adoption de pratiques LEAN – aspect

gaspillage

21

© 2013

Pour résumer…

� Scrum, PMBOK™, PRINCE2, P3O� Cadres de référence (framework)

� Ensemble de meilleures pratiques

� Scrum et PRINCE2 permettent d’appliquer un ensemble de pratiques dans une démarche d’amélioration continue grâce à l’approche empirique

� Ces approches forment un excellent moyen de gérer la complexité inhérente aux projets d’aujourd’hui.� Complémentarité et non compétition

22

© 2013

Notre ambition

23

Changer le focus de la discussion

Parler d’Agileau lieu de

Scrum

© 2013

APPENDICES

24

© 2013

Idée V1.0 : deux approches très différentes

25

Processus « défini » :•Il nécessite que tout soit identifié et connu.

•Si la totalité des intrants sont bien définis en amont

ceci assurera les mêmes extrants à chaque fois.

•Un processus bien défini peut être entamé et

exécuté jusqu’à sa fin, avec les mêmes résultats à

tous coups.

Processus « empirique » :•Un processus empirique en est un basé sur

l'expérience.

•Il nécessite une bonne visibilité, des inspections

fréquentes et des adaptations aux plans.

IPECC + 9 domaines de compétence

Planifier et contrôler +

DDC

PMBOK®

Processus défini

Learn as you

go

Inspect

and adapt

Scrum

Processus empirique

Apprendre en

faisant

Tout savoir

avant de démarrer

© 2013

Idée V1.1 : Deux approches si différentes?

� La gestion de projet classique et Scrum sont fondés sur le même « triangle » de contraintes.

� Par contre, en Scrum, le triangle est inversé.� Les ressources et le

calendrier sont fixes.� La portée est variable.

26

Les plans définissent

les estimations

de coûts et le calendrier.

Les thématiques des « releases » et les intentions

des fonctionnalités définissent les estimations.

Éléments fixes Portée Ressources Calendrier

Variable Ressources

Calendrier Portée

Le plan dicte les étapes

Valeur et visiondictent les

étapesScrum inversele triangle.

PMBOK® Scrum

© 2013

Idée V1.2 : Deux approches pas si différentes?

27

Processus reconnu en gestion de projet classique qui vise à planifier le mode « cascade » en vagues successives au fur et à mesure que les éléments du projet se confirment et que le projet avance.

Approche de gestion de projet Agile basé sur un modèle empirique qui propose la livraison de fonctionnalités ‘potentiellement’ livrables en production par une série de cycles courts appelés itérations.

© 2013

Même combat!

� Les facteurs-clés de succès sont les mêmes :� Implication des utilisateurs� Soutien de la haute direction� Équipe et gestionnaires expérimentés� Besoins clairs� Portée bien définie� Infrastructure et outils standards� Méthodologie adaptée� Estimations fiables

28

Source: CHAOS Report from Standish Group 2004

Challenged

Failed

Succeeded

� Les principales causes d’échec sont les mêmes :� Manque de soutien des parties

prenantes� Manque de bonnes pratiques

© 2013

Les DDC en Scrum?

� Quelques définitions courtes� Demande de changement :

• Demande d’approbation de changement pour une ou plusieurs contraintes du projet (temps, coûts-avantages, portée)

� Responsable de produit (product owner) : • Représentant des utilisateurs qui définit et priorise les

demandes concernant les produits• Délégué du comité directeur

� Équipe Scrum : • Équipe de +/- 7 personnes regroupant tous les rôles

traditionnels : architecte, développeur, analyste, testeur, administrateur

• Équipe développant le produit et se gérant en toute autonomie.� ScrumMaster :

• Il n’est pas le chef de projet mais a un rôle de coach • Sa mission est de tout mettre en œuvre pour que l'équipe

travaille dans de bonnes conditions et qu’elle se concentre sur l'objectif du projet.

29