Cette présentation a trait à l'agilité que l'on peut ... - Agile Grenoble

L’agilité au niveau du portfolio
Cette présentation a trait à l’agilité que l’on peut mettre en œuvre au niveau d’une gestion de portefeuille de projets.

Je me présente : Jean Dupuis
J’ai 41 ans – 18 ans d’expérience sur
assistance maîtrise d’ouvrage.
Je suis intervenu sur la stratégie de
SI, l’urbanisation, les schémas directeurs
du SI, la mise en place ou
la rénovation de la gouvernance du
SI avec les métier, avec des processus
de gestion de portefeuilles
de projets. J’ai également dirigé des
projets, tant dans les phases amont
que dans la mise en œuvre.
Je suis également enseignant à Grenoble
Ecole de Management, en particulier
sur la gestion de portfeuilles
de projets.
Pour en savoir plus :
http://jean.dupuis.free.fr
Twitter :@ jidup
Blog : http://jidup.wordpress.com
Jean Dupuis
18 ans d’AMO sur projets

Il y a un an, j’ai hébergé un ami qui venait d’être embauché
dans la région chez un éditeur de SIG et qui
cherchait un logement.
Un soir, en discutant, il me dit que dans sa nouvelle
société, on travaille en agile…
je lui dis… « ah oui, en RAD ? » et il me dit…
« Non, le RAD c’est autre chose, nous on
travaille en agile, en SCREUM précisément… »
et il me met sous le nez le livre de Véronique
Messager Rota et me dit qu’il est très bien
écrit et que je devrais le lire…
Je mets ça sur ma pile de choses intéressantes
à faire… comme tant d’autres, sans
plus m’alerter.

Deux jours plus tard, je me promène
dans le Vercors avec mon beau-frère
qui vient de changer de crèmerie,
également chez un éditeur du bassin
Grenoblois.
En discutant de son nouveau job, il
me parle d’agile… et de SCRUM en
particulier…
Et d’autres évènements de ce type
s’enchaînent. Il me semble soudain
que je suis le seul à ne pas connaître
SCRUM…

Alors je lis et dévore les écrits
avec boulimie ! D’abord, pour me
mettre en appétit le livre de Véronique
Messager Rota, puis celui de
Claude Aubry…
Cela me semble clair, limpide, évident…
Je poursuis mes lectures, télécharge
un livre sur kanban et
scrum de Henrik Kniberg traduit
par Claude Aubry, surfe sur des
blogs… découvre les excellentes
BD et un PDF très complet sur
le retour d’expérience d’Emmanuel
Chenu présentant ce qu’il a mis en
place chez Thalès avec des apports
de différents cadres agiles,
de Scrum, XP, Lean…

qu’est « un bon chef de projet »… qui me fait l’effet d’une
bombe.
Je tombe du haut de mes 18 années d’expérience… ce post hu-
gestion de projet dans lequel j’ai l’impression d’avoir passé 18
années de ma vie professionnelle…
Une tonne de questions me viennent à l’esprit.
Je prends contact avec l’auteur de ce billet,
Jean-François Jagodzinski un coach agile du
bassin grenoblois
(www.jago.fr).
Jean-François est coach agile. Son
job est principalement de regarder
les autres travailler. Il répond aux
questions aussi, et reçoit des courriers
de dizaines de fans ;-).
Un jour il reçoit un mail pas comme
les autres avec plein de questions.
L’approche lui semble intéressante et
pleine de bon sens, et puis je suis un lecteur
de son blog, pour une fois qu’il en a un, il décide
de me rencontrer. En général, cela amène à une rencontre assez
formelle avec quelques échanges courtois, intéressants
mais cela ne va pas plus loin.

Avec l’aide de quelques bières, nous
égrenons les heures à parler d’agilité.
Il faut dire que je lui ai envoyé une
liste de questions longue comme le
bras et consciencieusement, je le
questionne, reformule, analyse les impacts
de ses réponses sur mes cadres
de référence, revient à la charge
jusqu’à plus soif… ou plus possibilité
de boire plus.
Nous convenons de continuer à
échanger pour analyser le gap qui sépare
une méthode classique d’une approche
agile.

Mon monde me semble tout à coup être un
jeu de dominos qui s’impactent les uns les
autres jusqu’à ce que tous mes repères
tombent à terre.
Les questions se multiplient :
Tous les projets vont-ils devenir agile ?
Y aura-t-il encore besoin de MOAs, de chefs de projets, de consultants AMOA ?
L’agilité est-elle compatible avec les grands projets, une démarche d’urbanisation du SI…
Et si on généralise l’agilité… qu’adviendra-t-il des schémas directeurs, des plans à 3 ou 5 ans ?
De la gestion de portefeuilles de projets ??
Et après tout, est-ce un feu de paille ou un feu de forêt ? Une nouvelle petite vague ou un
tsunami… ?
J’enquête et continue ma boulimie de lectures et de cyber ballades…

Méthodes en cascade
méthodes agiles
Je survole les blogs, les études
de Gartner, de Forrester,
d’Ovum…
Les chiffres diffèrent mais il y
a une constante…
Tout le monde voit arriver à
grande vitesse les méthodes agiles…
La cascade est en chute ;-)…
tandis que l’agilité connaît un
succès fulgurant !

35%
D’après l’étude du second trimestre
2010 de Forrester, 35% des compagnies
interrogées ont dit que leur
première méthode de développement
était agile…
De nombreuses autres études sont
conduites de par le monde sur le
sujet avec des résultats plus ou
moins similaires.
Un billet publié le 11 août 2010 Application
Development trends relate
Associates qui a été menée lors du
dernier Gartner Summit auprès de
cadres de compagnies européennes
et du moyen orient.
L’agilité n’aurait pas encore supplanté
la méthode en cascade dans
ces zones géographiques… mais 43%
des répondants disent que cela va
devenir bientôt la première approche
de développement.

43
230.000
350.000
Parallèlement à ce mouvement d’essor de l’agilité,
la professionnalisation de la gestion de projet
prend son envol.
Le PMI (Project Management Institute dont je
fais partie), premier référentiel méthodologique
de conduite de projet, a eu ses 43 premiers cer-
1984… On en comptait 230.000 en 2007 et plus
de 350.000 à l’heure où je vous parle…

Aujourd’hui, seuls, quelques « pure players » internet ou éditeurs
de logiciels ont basculé en 100% agile (et encore depuis peu…)
avec plus ou moins de facilité, d’obstacles.
100%
Rares sont les entreprises
agiles

? Alors
? Quel avenir pour l’agilité
dans les entreprises ? L’agilité va-telle
vraiment s’imposer ?
Si oui ? Comment ? Pourquoi ? Et
avec quelles conséquences pour
l’entreprise ??

Avant de parler d’une généralisation de l’agilité à tous les
portefeuilles de projets,
Voyons d’abord ce qu’apporte l’agilité sur un projet par rapport
à une méthode classique.

Un projet « classique », en cascade dure 12 à 24
mois en moyenne.
Est séquentiel dans le principe (même si on parallélise).
On n’a jamais le temps de faire des retours d’expérience.
Le projet ne se déroule jamais comme prévu …
On passe beaucoup (trop) de temps à gérer les décalages
de plannings, les changements d’affectations
d’équipiers… (les fameux 42 processus du PMI).
Or les délais (déjà très longs) sont contraints… donc
on ferme les yeux sur la qualité (pas le temps de
tester avant de livrer… le client fera le débugage…).
On a des effets tunnels énormes avec de grands
écarts entre ce que le client attendait et ce qu’il reçoit
18 mois plus tard…
Et les projets arrivent mécaniquement en retard (en
effet, sur 12 ou 18 mois, il y a toujours des aléas
avec des impacts en cascade)… sur un marché dont
la demande a évolué et donc avec une valeur ajoutée
qui a baissée sur le marché par rapport à ce qu’elle
aurait été 18 mois auparavant…

Possibilité de changer de priorités
Sprint en cours
Quelques jours entre
demande et recette
Le projet agile vise au contraire à supprimer l’effet tunnel en livrant
très rapidement (sous 2 à 3 semaines = un sprint) et en priorité des
demandes à plus forte valeur ajoutée…
Concrètement, pendant le déroulé d’un sprint, vous pouvez changer de
demandes pour le sprint suivant.
Au pire, si le sprint vient de démarrer, on traitera votre demande dans le
prochain sprint (soit une livraison sous 3 à 6 semaines).
Au mieux (on arrive en bout de sprint, on va lancer le nouveau et cette
demande sera traitée en premier…), on vous livre la solution pour recette
dans une à deux semaines…
Faisons un rapide rappel de ce qu’est l’agilité, en particulier SCRUM
qui domine le marché (plus de 70% des équipes agiles).

L’agilité est un changement
de point de vue.
Un monde cartésien de
la méthode face à un
monde ou les pratiques
dominent et où
l’expérience est essentielle.
Le rapport au temps
est revisité (sprints
courts avec livraison
de fonctions opérationnelles).
Le rapport à l’information
change : en classique,
l’information
est dans des docu-
l’information a une
durée de vie limitée, liée
à un moment du projet,
dans le cadre d’une
relation entre participants.
Les méthodes classiques
sont comme un
jeu d’échec : on peut
changer de joueur en
cours de partie car
tout est écrit sur
l’échiquier. Et la partie
En agile, cela ressemble
plutôt à un jeu de
de changer de joueur
en cours de « partie
» mais une partie
est très courte et une
soirée carte comprend
plusieurs parties… sans
au départ. Et on peut
changer de joueur entre
deux parties (=sprints).
Les vecteurs de réussite
diffèrent : on jugera
la réussite d’un projet
classique à la qualité
et au respect des procédures.
Sur un projet
agile, c’est la qualité
des relations le véritable
vecteur de réussite du
projet.

Project management
42 processus
4 artéfacts,
3 rôles
4 types de réunions
Projets cycle en V Projets agiles Scrum
Dans une approche classique avec cycle en V et
-
jours avoir des décalages pour aléas.
Par exemple, sur un chantier, si pour des raisons
d’intempéries, on décale le travail sur les fondations,
cela décale tout le reste du chantier de construction,
de charpente, menuiserie, plomberie, électricité
etc. Or si on décale de 15 j, il n’est pas dit que les
autres intervenants puissent se libérer 15 jours plus
tard car ils ont peut être d’autres chantiers. Chacun
va donc ajouter un décalage pour être à nouveau
D’autre part, cela implique parfois de revoir les
conditions d’achat (changement d’année avec changement
de tarif par ex.), etc. Ce qui se traduit dans
le référebntiel du PMI par 42 processus de gestion
d’un projet.
En scrum, le cadre est beaucoup plus simple que
acteurs (équipe, scrummaster et Product Owner),
3 ou 4 réunions (Scrum, sprint planning, démo et
rétrospective) et 4 artéfacts (manifeste agile). Chaque
itération est comme un mini cycle en V de 2
semaines. Sur un délai aussi court, le risque d’aléa
est faible. La probabilité de dérapage est quasi nulle.
s’il n’y a plus de décalages à gérer…

D’où la question essentielle
suivante issue d’une démarche
de progrès lean : faut-il
encore passer tout ce temps
(environ 15 à 18% de l’enveloppe
projet) à « gérer le projet »
au lieu de travailler sur la
production des livrables ?

Dans le PMI, manager le projet, c’est manager les délais, les
coûts, les ressources, le périmètre, la qualité, les risques, les
achats, la com et l’intégration de l’ensemble.
En agile (Scrum / XP): le délai est intangible car contraint (on
livre ce qu’on peut mais à la date prévue) de même que les ressources
(équipes plein temps), les coûts(à 90% salaires de
l’équipe) et achats (d’équipiers pour l’essentiel), la qualité n’est
pas négociable (pratique XP du pair programming, du code lisible,
des tests automatisés), la communication est le cœur du dispositif
(le PO client est au cœur de l’équipe 24h/24, et il communique
par relais vers les utilisateurs ou le sponsor sans qu’il
complexe. De même, plus besoin de décaler la communication en
cas de dérapgae puisqu’il n’y a plus de dérapage…
Seul, le scope (périmètre) est la variable d’ajustement au début:
dans les 3 premiers sprints, le temps d’apprivoiser la capacité de
production de l’équipe dite « vélocité » on peut ne pas livrer une
partie de ce qui était prévu mais ce qu’on livre doit fonctionner
et être de qualité ; au-delà des premières itérations, l’équipe
-
tion, exécution, contrôle et maîtrise du PMI semblent surdimensionnés
et se retrouver mis en pratique naturellement par une
équipe qui maîtrise chaque « mini-projet » de 15 jours c’est à
-
sus de « planning » (comme sprint planning ou release planning)
et « clôture » (rétrospective en agile) qui sontle plus proche en
Scrum et dans le PMI.

A-t-on raison de parler de projet agile ? Par exemple,
chez Kelkoo, il n’y a plus de notions de projets.
Il y a des PO et équipes par domaine mais on
parle de domaines, releases, sprints, stories mais
plus de projets.
Pour bien tout poser à plat, nous avons repris la
Un projet est un effort temporaire exercé dans le
but de créer un produit, un service ou un résultat
unique.
Résultat unique ? A priori, oui, comme dans le
projet classique.
Mais que pourrait-on appeler projet en agile ? Une
story ? Un sprint ? Une release ? L’ensemble des
releases ? Faut-il chercher ailleurs la notion de
projet ?

Stories
=
Project ?
Supposons que la brique de légo symbolise la story, le grain
élémentaire.
Une Story serait-elle un projet ?? Ou une sous-partie d’un
projet ?
-
tion de projet du PMI. Elle est temporaire (une fois la story
une story qu’une fois, le but n’est pas de produire la même
story à la chaine 10.000 fois…).
On pourrait gérer chaque story comme un projet ; le PO deviendrait
un Portfolio Owner et prioriserait les projets. Cela
colle ! Mais à l’échelle d’une entreprise, ce serait un cassetête
pour piloter les évolutions à grande échelle ; il faudrait
maille semble trop petite pour être gérable à un niveau de gouvernance.

Sprint
=
Project ?
Une porte faite en briquettes de légos pourrait syboliser un SPRINT.
Est-ce vrai pour un SPRINT ? Y a-t-il un avant / après ? OUI c’est
VRAI.
Délivrer un résultat unique ? OUI : chaque SPRINT délivre un résultat
nouveau, unique… C’est donc VRAI
Un SPRINT serait-il un projet ??
Un sprint délivre plus de valeur qu’une story, il a une maille supérieure
mais il est possible qu’il faille passer à une release pour avoir une livrai-
on parle d’un produit, un service ou un résultat... encore faut-il qu’il soit
cohérent, complet par rapport à un besoin. Et pour cela il faut parfois

Release
=
Project ?
Un étage avec des cloisons et des portes pourrait représenter
une release avec ses différents sprints.
Chaque release délivre un résultat nouveau, unique et dans
une période de temps limitée… Cela correspond également à la
Curieusement, cela me fait penser à un client (« classique
») qui a 950 demandes de projets dans son pipeline et
où les projets à 3 M€ sur 2 ou 3 ans côtoient sur un pied
d’égalité la petite évolution de 10 jh de travail…
Une release serait-elle un projet ?? Après échange avec
quelques uns de nos pairs du CARA, il semblerait que la
release soit la bonne dimension pour parler d’un projet.
Mais une release peut comporter 3, 4, 10 20 sprints…de 2 à
3 semaines… soit durer de 2 à 15 mois Une bonne pratique
constatée parmi nos pairs semble cependant de livrer des releases
fréquemment soit tous les 2 ou 3 mois ce qui correspond
à environ 4 sprints de 2 ou 3 semaines…

En agrégeant les étages (releases), on obtient une tour… Admettons qu’on la nomme
« programme ».
-
sultat unique. Un programme serait-il alors un projet ?? Sand doute pas.
-
ges et une maîtrise que n’apporterait pas un management individuel.
Cela pourrait aussi s’entendre en agile.
Et puis si l’on pousse la métaphore avec un programme comme la réhabilisation de
Défense... ces programmes sont tellement énormes (grain trop gros pour être arbi-
des priorités.

Il ressort de ce que l’on vient de voir qu’en agile,
une story, un sprint, une release a minima...
Curieusement, cela me fait penser à un client
(« classique ») qui a 950 demandes de projets dans
son pipeline et où les projets à 3 M€ (ERP etc.)
sur 2 ou 3 ans côtoient sur un pied d’égalité la petite
évolution de 10 jh de travail…
Le déploiement de l’agilité est l’occasion de revoir
votre référentiel de gestion de projet en commençant
Admettons que, tout en restant en phase avec la
agile la release et supposions qu’une release dure
un trimestre et soit composée de 4 sprints de 3 semaines.

Voyons maintenant s’il y a des raisons objectives de
penser qu’il faut basculer en 100% agile.
Dans un premier temps, voyons POURQUOI il faut
généraliser l’agilité ? Pourquoi ne peut-on faire
autrement et conserver des méthodes classiques…
Dans un second temps, nous reviendrons sur le
COMMENT ? Est-ce faisable ? Que faut-il faire
pour limiter les risques lors du changement de modèle
??

Premier argument, en 2000 (un an avant la création
du manifeste agile en février 2001), le Standish
Group publie son étude sur les taux de succès
et d’échec des projets (classiques donc, puisque
Scrum est un épiphénomène et que le manifeste
agile na pas encore été proclamé - fév 2001).
72% de projets sont en échec ou en retard (avec
un dépassement moyen de 189%), cela fait pas mal de
bonnes raisons de chercher à changer de méthodes
et pourquoi pas de tester une approche en rupture
: l’approche agile…
Cela étant, l’agilité ne se prête pas à tous les projets.
La mise en place de SAP en mode agile n’a a
priori encore jamais été faite…

argument : le succès de l’agilité n’est plus
à démontrer même si certains vivent des succès
mitigés au début (première année, le temps de
2ème
trouver ses repères, sa vélocité, grandir).
Témoignage de membres du CARA Grenoble : Luc
et Bruno avouent que l’équipe cherchait ses marques
la première année en 2005 mais a trouvé
rapidement son rythme de croisière. Aujourd’hui,
ils ont une super qualité, un risque nul ou presque
et des clients ravis… Idem chez « La Boite
à outil » d’après son Directeur Informatique. Et
les exemples sont légion.
3ème argument : CEUX QUI TRAVAILLENT EN
AGILE ne veulent plus revenir au cycle en cascade…
JAMAIS PLUS !!!!

4ème argument : ceux qui n’y sont pas continuent
de vivre dans les affres des projets en échec et en
dérapage, à travailler tard pour rattrapper le temps
perdu et revoir les plannings et les effets de bord…
et regardent les équipes agiles avec envie.
Il y avait mi-novembre 2010 un reportage sur M6
dans l’émission Capital qui montrait une équipe agile
et qui présentait le cas d’un nouvel équipier qui
avait quitté son entreprise pour rejoindre une équipe
agile car il n’en pouvait plus du mode de gestion
classique… Et il semble que le marché des ingénieurs
informatiques soit tendu. Alors…

Les entreprises sont-elles prêtes à
accueillir cette rupture dans la pratique
projet ?
Les dirigeants ne savent en général
pas ce qu’est l’agilité dans la plupart
des cas (sauf dans quelques
SSII) .
Ceux qui en ont entendu parler se
disent qu’on ne peut pas généraliser
l’approche… Car ils sont habitués à
une approche prédictive, à une vision
à trois ans… à un schéma directeur,
à un rythme lent, à diriger de loin,
laissant les échéances court terme
aux opérationnels sur le terrain.
L’agilité avec sa visibilité à court
terme peut faire peur à certains dirigeants…

Mais actuellement, … 4ème argument, la vision à long
terme fait souvent place à des actions tactiques à
court terme… Et là, quand tous les budgets sont investis
sur des projets qui livreront leur valeur dans 18
mois… les DG peuvent être réceptifs à une approche
offrant plus d’agilité.
Au delà des actions tactiques conjoncturelles liées à
la gestion de la crise, depuis une quinzaine d’années, les
rachats d’entreprises s’enchaînent sans discontinuer.
Et qui dit changement d’organisation ou fusion-acquisition
dit fusion des SI, alignement stratégique des
portefeuilles d’investissements…
Autant de changements de caps à gérer avec agilité,
réactivité, rapidité…

Dans beaucoup de cas de fusions d’entreprise et des
DSI en particulier, les équipes agiles se retrouvent
dans un combat de David contre Goliath ….
Une petite équipe agile mature qui se retrouve projetée
sous une Direction qui a conservé une gestion de
projet traditionnelle et qui veut lui faire réintégrer les
méthodes classiques (processus de documentation,
décision, reporting…).
Les équipes agiles sont alors confrontées à un challenge
: promouvoir leur modèle et convaincre les décideurs
qu’il faut déployer l’agilité plutôt que de faire
marche arrière vers une approche à l’ancienne.
Equipe
classique
Grand effort pour
frapper à côté et
trop tard
Frappe rapide,
légère, dans le
mille
Equipe Agile

pour ce qui est de changer de
cap rapidement avec agilité et réactivité,
il est plus facile de prendre
-
tille de petits projets qu’avec un
Et
énorme projet qui s’étale sur 5
ans…
Projet agile (release)
Projet classique
(merise like)
On peut arrêter de convoyer la
valeur en cessant d’envoyer de petits
navires. Ceux qui seront arrivés
auront livré leur valeur (dans le
temps d’une release, un trimestre).
Mais arrêter un gros projet qui
est en route depuis 2 ans, qui
est bientôt prêt à être déployé et
n’a encore livré aucune valeur est
Mettre un terme à un projet Peoplesoft
worlwide arrêté juste avant
son déploiement parce que l’entreprise
est rachetée par un groupe
qui a déployé SAP.

Partout, la tendance est
sur le site de l’AGEFI, mais
-
nances etc. La tendance actuelle
est à la fusion acquisition,
à la restructuration
et à la consolidation.
Une de mes amies a changé
5 fois d’entreprise en 6 ans
sans jamais changer de bureau…
J’ai moi-même changé
3 fois d’employeur mais 6
fois de marque et d’actionnaire
en 7 ans entre 1997 et
2003…
Chaque fois, ces changements
stratégiques se
répercutent directement
sur le SI à la fois pour
réorganiser et fusionner
les SI, à la fois pour
optimiser les investissements
sur des projets
les plus en ligne avec la
nouvelle stratégie.

Pour aller au-delà de notre vision personnelle
dans cette étude, nous avons interviewé
des collaborateurs de 8 entreprises.
De la PMI à la Grande Entreprise, du privé
et du public. C’est loin d’un échantillon
représentatif en termes de quotas mais on
constate tout de même des tendances.

La plus petite des entreprises étudiée compte tout
de même 3000 salariés et a été rachetée par une
grosse entreprise de 19.000 salariés.
Post fusion, dans l’une des divisions informatiques
du groupe, il y a 40 personnes (de l’ancienne PMI)
qui travaillent en agile sur 200. Ces 40 personnes
ont un portefeuille de 30 demandes de projet et une
capacité à délivrer 15 projets annuels en agile.
Leurs collègues non agilistes sont confrontés aux
problèmes classiques de dérapages coût / délais, de
problèmes de qualité et d’insatisfaction client.
La BU agile a démontré la performance de sa manière
de travailler. Il lui reste à convaincre la Direction
(R&D, Marketing, Finance...) que déployer l’agilité sur
Vous trouverez par la suite quelques éléments que
travailler pour basculer en 100% agile.

A l’autre extrémité, j’ai fait le point
avec une ex collègue qui travaille dans
une administration de 80.000 salariés
dans laquelle j’étais intervenu en 2005
pour mettre en oeuvre une gouvernance
et une gestion de portefeuille de projets.
Cette organisation qui compte 500
personnes en « MOA » (dont la plupart
sont d’origine MOE et raisonnent
donc solution avant de penser besoins)
et environ 500 personnes en maîtrise
d’œuvre et prestataires…
Ils ont un pipeline de 950 demandes de
projets de toutes tailles (de 20 K€ à
10 M€) dont environ 500 sont servies.
Cette organisation donne la priorité aux
projets apportant des gains rapidement.
Ils sont en train de revoir leur gestion
-
ses de décisions et réduire les goulets
d’étranglement.

Nous avons également confronté notre vision aux
cadres de référence existant.
Plus précisément, la gouvernance du SI, l’alignement
stratégique des projets de SI et le portfolio mana-
par quelques cadres de référence :
- COBIT
- VAL IT
- PMI
les processus de gestion de portefeuilles de projets
ou d’initiatives.
En ce qui concerne COBIT, VAL IT et les « Best
practices in Portfolio Management » du PMI, quelques
entreprises les connaissent, peu les maîtrisent.
-
dres de références (ce qu’il faut faire), pas de méthodes
(comment faire).
De l’ensemble de ces sources confrontée à ma propre
expérience, il ressort une vision de la mise en
place d’un portfolio management.

Voici par exemple une cartographie des processus extraite
du document de référence du PMI en ce qui concerne le
Portfolio Management.

La première étape consiste à recenser les projets en cours (comment
on consomme des ressources / quelle valeur on délivre), les projets à
lancer (pour mettre en œuvre le SI cible dans le cadre d’une démarche
d’urbanisation par exemple) et les applications existantes (potentiel de
demandes d’évolution).
En 2005, dans cette organisation de 80.000 salariés et 1000 personnes
travaillant en MOA et MOE sur les projets informatiques…, il n’y
aujourd’hui). Pas non plus dans une autre organisation de 15.000 salariés
et 200 projets en cours ou à lancer. Pas non plus dans une organisation
de 600 personnes en 2010…
Donc le CODIR ne dispose d’aucune vision d’ensemble stratégique sur
la manière dont les ressources sont utilisées… Et cela est sans doute
encore un phénomène répandu aujourd’hui en 2010.
Dans ces organisations, on affecte à chaque unité d’organisation MOA /
MOE les moyens de l’année N en fonction de l’affectation de l’année N-1
-
ses et le SI étant complexe, cette absence de vision fait qu’on empile
les projets en cours, sollicitant toujours les mêmes expertises rares,
constituant beaucoup de goulets d’étranglements autour d’experts… De
fait les projets dérapent et ne livrent que tardivement voire jamais la valeur
attendue.
Est-ce cela l’alignement stratégique ??
les stories à mettre dans le backlog.

2ème étape : revoir chacun des projets
du backlog (en cours et candidats)
à l’aune des objectifs stratégiques
prioritaires.
l’alignement stratégique du SI d’une
grande organisation. Quand on leur a
demandé les objectifs stratégiques
prioritaires, il y a eu un grand silence…
puis rien. Personne ne connaissait
la stratégie métier et il n’y avait
pas de stratégie SI… Le plus long a
été de leur faire découvrir leurs axes
stratégiques et critères de priorisation
/ scoring…
NB : si on fait le parallèle avec le
rôle du PO dans une équipe agile,
cette activité consiste à mensurer
la valeur métier qu’apporte chaque
story.

3ème étape dans ce processus d’alignement
stratégique du portfolio : choisir les bons
projets, ceux à lancer en priorité… C’est le
fameux slogan « Do the right projects »
NB : c’est la même chose que ce que fait le
PO en priorisant ses stories : « do the right
stories ».

-
sation et cadres de référence, on utilise des critères sur lesquels
on va « scorer » chaque projet en mettant des notes de 1 à 3 pour
rester macro :
Contribution du chaque projet à chacun des 3 ou 4 objectifs
stratégiques prioritaires (1 = faible contribution / 3 = forte contribution)
Risque à ne pas faire (1 = risque faible / 3 = risque fort)
Risques à faire (1 = risque faible / 3 = risque fort)
Revenus attendus (on peut parfois mettre en K€ ou rester en 1 / 3)
Coût total (idem)
Délai de mise en œuvre (idem : en durée ou de date de début / date
Comment procéder ? En général, mieux vaut faire scorer les projets
par plusieurs personnes pour tenter d’objectiver les notations. Les
outils de PPM pour les projets candidats (ex. Clarity, Microsoft
Enterprise Project, PS Next…) prévoient cette possibilité). Cela si-
de projets candidats d’autant que dans les grandes organisations,
il faut beaucoup de monde pour être capable de scorer tous les
projets.
un total pondéré comme le proposent les progiciels ? Mais est-ce
ses inclinaisons personnelles ?

-
ses sont confrontées à une logique où tout
est urgent et prioritaire…
Le travail sur les critères de priorisation doit
aider mais ne fera pas tout. Il faudra dans
certains cas apprendre aux managers à choisir,
trancher, décider, renoncer…

-
risés, et priorisés, il faut évaluer le coût de mise
en œuvre : tous les projets / initiatives doivent
-
cières et de compétences techniques / métier.
considèrent pas les ressources internes comme
c’est même le cas dans une grande SSII de la
place française). Or sans estimation de la charge
de travail en particulier sur les domaines d’expertises,
on est certain de bloquer les projets pour
des raisons de goulets d’étranglement sur les ressources
rares.

5ème étape : une fois que l’on connaît le
« pipeline » avec le besoin de ressources
corrélé, là encore, on retrouve la même logique
que dans SCRUM… Il faut sélectionner
ce qui est prioritaire et que l’on est capable
de traiter dans la première année (comme
on le ferait avec ce que l’on est capable de
traiter dans le premier sprint).
Le Portfolio management jusqu’à ce jour
est proche d’une itération SCRUM mais à
l’échelle supérieure :
On ne priorise pas des stories mais des projets.
Cela ne se fait pas toutes les 2 ou 3 semaines
mais tous les 2 ou 3 ans…

« sprint backlog » correspondant à ce qui
doit être fait dans la première année (/ itération),
on va construire le plan à 3 ans et
ajuster le planning des projets de manière à
lisser l’utilisation des ressources et éviter
d’avoir des besoins de ressources en sinusoïde.
S’il le faut on décalera un projet pour
s’adapter aux ressources.

le communique et on décide de
lancer les opérations conformément
au plan.
GO !!!Après avoir passé ces 6 éta-
NB : pour en arriver là, dans
de grandes organisations, cela
peut nécessiter 6 mois de recensement,
priorisation, décisions…

7ème étape : Une fois le plan en cours de
mise en œuvre, on revoit ensuite le plan
mois après mois ou trimestre après trimestre
à la lecture des reportings qui remontent
du terrain.
Le plan a-t-il été bien observé ? A-t-on
sur ou sous-performé ? Est-on en avance,
en retard sur tel ou tel projet ? En sur
ou sous consommation ?
On fait des ajustements marginaux : on
reprend quelques ressources sur un projet
moins prioritaire pour venir en aide à
un projet prioritaire. Et encore… Le plus
souvent, on constate mais on ne fait rien
et les projets dérapent sous le regard impuissant
de l’instance de gouvernance.

8ème étape : lors du processus
budgétaire annuel, on révise le plan
d’allocation des ressources mais
-
chées suite au dernier alignement
stratégique / schéma directeur
stratégique du SI…
La marge de manœuvre est donc
-
ce joli plan sauf à convenir 6 mois
pertinent, inutile et qu’on a gaspillé
6 mois et des centaines de journées
hommes pour le bâtir…

Malheureusement, le temps des 30 glo-
-
cile de faire des plans à moyen et long
terme… L’environnement étant instable…
tous ces beaux plans qui ont pris plusieurs
mois à se mettre en place sont
presque caduques avant d’avoir commencé…
Cela peut venir de l’extérieur, des règlementations,
de la concurrence, ou de
l’intérieur (Le nouveau Big Boss / Diva
a décidé que…)
A mon avis, faut sans doute abandonner
la programmation détaillée à moyen
terme et se recentrer sur :
Une vision / intention de commandement
Un alignement opérationnel à fréquence
rapprochée (trimestrielle) et en divisant
la complexité (par portefeuille)
faire un portefeuille par domaine fonctionnel
pour réduire la complexité. Mais
dès lors qu’on travaille dans une organisation
qui se transversalise, les programmes
deviennent multi-domaines… et
la priorisation ne peut alors se faire
qu’au niveau programme transverse.

Clairement, ce que l’on vient de voir
est plus rigide qu’agile.
marges d’ajustements.
Vouloir être agile dans ces conditions
là pour réagir dans le climat
économique actuel, c’est comme
essayer de faire du HIP HOP avec
une ARMURE…
Ou alors, on remet tout le plan et
l’allocation des ressources en cause
mais il y a rupture du modèle
: tout ce processus d’alignement
coûteux ne sert à rien si le plan
n’est pas suivi.

Nous venons de rappeler ce qu’est l’agilité avec
quelques uns de ses avantages par rapport aux
méthodes classiques.
Nous avons également vu que l’agilité ébranle un
peu la logique montante de gestion de projet ou
tout au moins son cœur :
-Les modalités concrètes de management de
projet
-Les modalités de gestion de l’alignement stratégique
et de la gestion de portefeuilles de projets
-
nes ont entendu parler de l’agilité mais croient
qu’elle se cantonne à de petits projets simples,
sans complexité et à des produits jetables de
faible qualité.
Cela rassure ceux qui gèrent les projets de
manière traditionnelle car cela permet de mettre
l’agilité dans une petite case et de conserver
ses repères chèrement acquis.
Mais cette catégorisation n’est pas fondée. Bien
au contraire, l’agilité est sans doute beaucoup
plus adaptée à des environnements complexes et
mouvants. D’ailleurs, plusieurs d’éditeurs sont
en train ou ont déjà basculé en agile pour l’ensemble
de leur offre progicielle.

Considérons donc que pour les raisons évoquées
plus haut, il faille absolument rendre
l’entreprise agile pour mieux évoluer avec son
environnement. Il faut donc renoncer au carcan
de la gestion de portefeuille de projets à l’ancienne
que l’on vient de présenter.
Admettons pour chaque initiative nécessitant
des développements, que l’on décide de la mener
en agile avec la règle suivante : chaque initiative
est appelée programme, décomposée en projets
(release) de 3 mois, décomposés en 4 sprints
de 3 semaines. Toutes les releases de tous
les programmes sont arbitrairement calées sur
les trimestres civils.
Chaque sprint contient les stories à plus
haute valeur ajoutée du moment.
Les ressources sont affectées à plein temps…
donc on est obligé de prioriser ce qu’on leur
demande de faire. On ne peut pas lancer tous
les projets en même temps…

Dans un premier temps, voyons ce que deviendrait un grand projet
s’il était mené en agile : on passerait d’une logique séquentielle
avec cycle en cascade à une logique agile itérative…
Le « programme » serait découpé en plusieurs releases contenant
chacune plusieurs sprints contenant chacun plusieurs
stories. On délivrerait le plus de valeur ajoutée au début du
programme puisque les stories prioritaires seraient livrées en
premier (rouge). La première release aurait donc la plus forte
valeur, la seconde (verte) comporterait des stories à valeur intéressante
mais moins élevée que dans la précédente release… En-
des stories à faible valeur métier.

Si on considère non plus un mais 2
projets, par ex :
un projet CRM pour redéployer l’effort
commercial, prendre des parts de
marché, et favoriser le développement
du CA chez les clients en cours et
l’ouverture de nouveaux clients.
Un projet SIRH : l’actuel SIRH maison
est obsolète, codé en dur en cobol,
n’est plus en règle avec la loi,
nous coûte très cher à maintenir et à
gérer, ne permet pas d’externaliser la
paye sur laquelle on a beaucoup d’erreurs
qui coûtent très cher à l’entreprise...
Si l’entreprise a une capacité limitée
à un projet, et le Directeur Commercial
a le dessus, son projet passera en
premier et le projet SIRH ne démarrera
que dans 18 à 24 mois.
Si on raisonne en projets agile, projet
par projet, cela ne changera guère. La
différence sera qu’on aura les premières
fonctions à valeur ajoutée du CRM
assez rapidement.

Si a contrario, on considère qu’il faut raisonner en portfolio
agile et non en portfolio classique de projets agiles,
la partition sera différente : on commencera par la première
release du CRM puis la première release du SIRH toutes
deux à plus forte VA.
Viendront ensuite les release de second ordre de VA et on
renoncera peut-être aux release de dernier rang contenant
des stories à faible valeur métier, laissant ainsi la place à
des stories à haute VA d’autres projets à venir.

Considérons donc maintenant le portefeuille tout
entier d’une organisation ayant de 30 à plusieurs
centaines de projets… il ressemble à cela.
Inconvénient : lors des revues trimestrielles de
portefeuille comme on l’a vu, l’horizon est bouché
; impossible d’introduire de nouvelles demandes de
stories à valeur ajoutée…
Comme dans toute organisation gérant un portefeuille
de projets… on va constater certains retards
/ sur ou sous-consommations par rapport au
plan… et on va faire glisser les ressources… mais la
marge de revirement stratégique est faible. C’est un
pouillème.
Globalement, on a peu de marges de manœuvre stratégique.
La plupart des projets ont du retard, sont livrés
après 18 mois si tout va bien, avec des problèmes de
retard de mise sur le marché.
Le Portfolio Management consiste à se réunir pour
faire « glisser » des plannings et des allocations de
ressources… ce qui, avouons le est peu alléchant
pour une DG… Ceci explique pourquoi il est si dif-
-
nions dites d’arbitrage qui en réalité n’ont pas beaucoup
de marge de manœuvre.

Le plan de charge ressemblerait à un mur avec des briques
qui se complètent et avec seulement l’espace de quelques
joints pour les ajustements.
5% de capacité d’adaptation, pas de quoi se faire pavaner le
comité de direction.

Si on bascule tous les projets en agile, on pourrait avoir un
portefeuille qui ressemblerait à une sorte de TETRIS mais
n’offrirait pas pour autant tellement plus d’opportunités de revirement
stratégique.
Il y aurait pourtant un léger mieux : bien que l’horizon semble
« bouché », le contenu de chaque bouteille (contenant =
Cela veut dire qu’on pourrait facilement demander de nouvelles
stories sorties du chapeau et qui viendraient alimenter le backlog
sur les domaines fonctionnels déjà servis en ressources.

Mais on pourrait gagner encore plus avec une véritable logique de portfolio agile.
En choisissant arbitrairement d’aligner toutes les releases de tous les programmes
sur les trimestres civils, on change de paradigme et de capacité de changement
stratégique.

100%
De réactivité à 3 mois
D’un seul coup, l’horizon se dégage totalement c’est à dire
revoir à 100% la composition d’un portfolio à un horizon de 3
mois au lieu de 3 ans… Sacrée accélération ! Et qu’on peut
livrer les premier résultats (premier projets) en 3 mois supplémentaires
(au lieu de 18 mois en moyenne).
En synthèse, le portfolio agile apporte 100% de capacité de
production mobilisable à 3 mois maximum, un raccourcissement
drastique du Time to market (3 mois), une division
par 7 à 10 du coût d’un projet : une release de 3 mois coûte
environ 150-250 K€
Si le besoin se fait sentir de changer les priorités profondément,
on peut changer toute la roadmap en 3 mois sans rien
le cours des choses en moins d’un mois (sprint suivant).
On peut même faire mieux : découper la capacité de production
en trois tiers. Les projets restent alignés sur des
releases de 3 mois comportant 4 sprints de 3 semaines. Chaque
tiers démarre et clôture sa release avec un décalage
d’un mois par rapport au tiers précédant. Cela désengorge les
de trimestre, donne une capacité de réaction de 33% tous les
mois.
Cela mobilise par contre l’instance de gouvernance pour arbitrer
sur les priorités tous les mois au lieu de tous les 3
mois et offre donc à la DG une capacité formidable de réactivité
stratégique non plus à 3 mois mais à un mois !!!

Mais pour atteindre ce nirvana de la
mise en œuvre agile de la stratégie,
l’entreprise doit globalement penser
AGILE...
Au niveau de la déclinaison de la
stratégie vers les opérations
Au niveau de sa culture d’entreprise
De ses valeurs
De ses achats
De sa gestion des ressources humaines
De sa gouvernance
Etc.

Pour être agile absolument, il faut
commencer par …
commandement simple, concrète…
que chacun pourra comprendre et
décliner à son niveau en fonction des
surprises qui jalonnent le terrain.
Renoncer aux schémas directeurs,
aux plans à 3 ou 5 ans (mais pas à
l’urbanisation par exemple).
Ne jamais descendre dans un niveau
de détail tel qu’il risquerait d’être
rendu obsolète par des évènements
imprévus.
Le livre « Ces idées qui collent »
des frères Heath en donne une excellente
illustration.

Pour être agile absolument, il faut envisager de renverser certains aspects
de la culture d’entreprise par rapport à la prise de risque et au
droit à l’erreur …
Nombreuses sont les entreprises où la non décision est la règle, par
peur de faire une erreur, d’être l’objet d’une chasse au coupable et de
Avec l’agilité, le droit à l’erreur est acceptable car :
Ce n’est pas l’erreur d’une personne mais de l’équipe (sauf du PO qui
lui est seul).
Une erreur ne touchera pas toutes les stories… une story perdue c’est
-
pective, on ne reproduira plus cette erreur (principe lean d’amélioration
continue).
En comparaison, dans un projet classique, on livre 1 M€ après 18 mois de
tunnel l’enjeu est gros, le risque est important, la hiérarchie prend participe
donc à toutes les décisions et le management intermédiaire n’ose
plus rien décider sans sortir le parapluie

Pour être agile absolument, il faut développer
au plus haut niveau de nouvelles valeurs :
Fini le chacun pour soi à défendre son propre
projet, son pré carré.
Tout le monde doit chercher à maximiser la valeur
ajoutée pour l’entreprise grâce au message
fédérateur, à l’intention de commandement, à la
politique RH.
Mais tout cela ne fonctionnera que si le CO-
DIR donne l’exemple et fait diffuser cela jusque
dans les équipes. Certains n’y arriveront pas
et devront quitter le navire…

Pour être agile absolument, il faut
des équipiers qui ont une véritable
culture de l’équipe, de la réalisation
ensemble, de la satisfaction personnelle
et de celle du client, de l’engagement.
Les équipes doivent également ne
pas craindre de perdre le confort du
chacun son tour (je fais un cahier
des charges pendant 3 mois et
ensuite, c’est à votre tour !!!) et
du LT (travail avec un horizon de
6 ou 8 mois avant deadline qui se
raccourcit dans un sprint à 2 ou 3
semaines).
Les équipes doivent également être
agiles et polyvalentes, capables de
travailler quelques sprints sur un
projet du domaine commercial puis
quelques sprints sur le domaine RH
et en changeant parfois de technologie
de développement… Cette capacité
peut se développer avec l’aide de
la DRH. Au USA, les échanges de
développeurs commencent même à
se faire entre entreprises partenaires…
d’après Asllak Hellsoy, Keynote
à Agile Grenoble 2010 et fondateur
de l’outil de BDD Cucumber.

Pour être agile absolument, il faut systématiser
l’analyse de la valeur !!!
Et cesser d’investir sur des enveloppes de demandes
fonctionnelles constituées aux deux
tiers de fonctions qui ne seront pas ou peu
utilisées (cf étude du Standish Group).
L’idée est de ne plus acheter un logiciel 10 fois
ce qu’il devrait coûter si l’on s’en tenait aux
fonctions que l’on utilise vraiment (ex. micro-
realease.

Ne plus acheter avec des cahiers
des charges (que l’on croit) exhaustifs
en demandant un forfait
immuable (mais qui en réalité se
traduira à chaque sortie de périmètre
par un avenant).
Favoriser un contrat cadre de prestation
partenariale, un achat de capacité
d eproduction agile, un forfait
au sprint.

Pour être agile absolument, il faut un métier véritablement
présent au cœur et au centre de
l’équipe. Donc un travail en « war room », en plateau
projet, avec développeurs testeurs et métier
réunis.
Au niveau des product owners, il s devront être
capables d’alimenter plusieurs mêlées de front.
Le gap est aussi grand que lorsque l’industrie
Il n’y a plus le confort du stock. Donc il faut
compétentes, capables d’alimenter les équipes et
de décider seules en temps réel.

Pour être agile absolument, il faut également
revoir la relation au management…
Les équipes agiles doivent être auto-organisées.
Il n’y a pas de chef de projet. Cela
Il faut trouver un avenir possible à vos
chefs de projet.
Il faut aider l’équipe à s’approprier sa nouvelle
autonomie : elle avait l’habitude de se
comporter en exécutant d’un plan établi par
un chef de projet ; chaque équipier doit
apprendre à anticiper pour lui-même et pour
qu’on a oublié des activités essentielles.
Le scrummaster et le coach agile sont des
acteurs essentiels de cette transformation
pour sécuriser l’équipe et accompagner en
douceur la transition

grandement les modalités de gouvernance !!!
route pour 3 ans à partir d’une page blanche à un
pilotage où on peut tout changer à un horizon
de 3 mois donne beaucoup de puissance de feu à
la Direction mais aussi demande une plus grande
implication des grands décideurs (CODIR). On ne
fait plus une priorisation une fois tous les 3 ans
mais tous les 2 ou 3 mois…
Auparavant, une fois le schéma directeur terminé,
le CODIR redonnait au DSI la main pour conduire
agile, le rôle du CODIR et des métiers se renforce
et c’est la DG qui préside aux décisions trimestrielles.
L’alignement stratégie est alors véritablement porté
par l’agilité, bien plus qu’il ne l’a jamais été. Les
réunions annuelles et trimestrielles ne servent
plus à se partager des pouillèmes (réunions peu
mobilisantes) mais deviennent des réunions à très
forte valeur d’adaptation stratégique et tactique.

Etre agile absolument, cela signi-
l’entreprise, de la Direction jusqu’au
PO et à l’équipe en passant par les
responsables de programmes, de domaines,
de portefeuilles… de revoir en
permanence si ce qui est prévu est le
meilleur en termes d’alignement stratégique.

Reclasser les chefs de projet
Penser globalement une affectation plein temps
des équipiers (plus de muliti-projets) et des product
owner (plus de PO continuant à diriger un
service opérationnel)
Penser équipier et non analyste ou développeur ou
testeur ou qualiticien : chacun doit pouvoir passer
de l’une à l’autre activité dans la mise en œuvre.
Tourner la page de la culture MOA classique avec
ses phases de leadership et ses phases de suivi
du maître d’œuvre, avec sa peur de décider sans
réunir un groupe d’utilisateurs. Accepter de devenir
PRODUCT OWNER c’est-à-dire capable
d’alimenter l’équipe à la volée en ayant anticipé les
questions.
Bien dimensionner les représentants métier (PO),
traditionnellement trop faible, tant en volume qu’en
Renforcer le travail de portfolio managers (car les
revues de portefeuilles vraiment stratégiques sont
désormais tous les 3 mois… et il convient de la
préparer en amont…

On voit que la diffusion des pratiques agiles dans
tous les projets SI et jusqu’à la gouvernance permet
d’accélérer vivement la mise en œuvre de la stratégie,
la réactivité et l’agilité concurrentielle de l’entreprise.
Encore faut-il réussir à convaincre le Comité de Direction
de changer de rythme à son propre niveau et
de piloter à plus court terme la stratégie de l’entreprise.
DG, Stratégie, Dir Métiers, DSI, DRH, DHA… devront
être convaincus et fortement impliqués comme on
vient de le voir avec cette analyse d’impact qui leur
donnera à tous un travail d’adaptation à mener.

En résumé un portefeuille de gestion de
projet classique prend une petite bouffée
d’air frais (5% de sa capacité respiratoire)
une fois par an lors de la préparation
budgétaire.
Un portefeuille de projets agiles prend
une grande respiration (100%) tous les 3
mois.

Sur un marché en constante accélération, avec
une forte pression concurrentielle et une course
constante à l’innovation, une entreprise qui continuerait
à travailler sur un mode prédictif classique avec
une programmation à 3 ans serait-elle encore en vie
dans 10 ans ?
Peut-on réellement renoncer à déployer l’agilité ?

Jean Dupuis
http://jean.dupuis.free.fr
http://jidup.wordpress.com
Twitter : @jidup
Jean-François Jagodzinski
http://www.jago.fr
Twitter : @jago
Merci !
Cette présentation est le fruit de plusieurs mois de collaboration, de lectures, d’interviews
et de confrontation avec notre expérience d’une part, et notre vision de ce que serait
l’agilité au niveau du portfolio. Nous l’avons confronté avec des cas existants pour valider
la qualité de la vision proposée.
La première diffusion de cette conférence a été faite lors d’AGILE GRENOBLE 2010, premier
évènement français autour de l’agilité avec 45 participants.
nous.