Scrum et le forfait incompatibles ? Pas si sûr. Lors du Scrumday 2011, Bertrand Pinel, directeur technique d'Ippon a présenté les retours d'expérience de la société

1. Les projets au forfait
Scrum but...
But Scrum !
Scrum day France 2011

2. Merci aux sponsors
du Scrum day !
Sponsors Platinum
Sponsors Gold
Parrainage :

3. Copyright
● Cette présentation vous est fournie sous licence Creative Commons
Attribution Share Alike
● Vous êtes libres :
✔ De reproduire, distribuer et communiquer cette création au public
● Selon les conditions suivantes :
✔ Paternité. Vous devez citer le nom des auteurs originaux mais pas
d'une maniere qui suggérerait qu'ils vous soutiennent ou approuvent
votre utilisation de l'œuvre.
✔ A chaque réutilisation ou distribution de cette création, vous devez
faire apparaitre clairement au public les conditions contractuelles de
sa mise a disposition sous licence identique Creative Commons Share
Alike.
✔ Chacune de ces conditions peut être levée si vous obtenez
l'autorisation du titulaire des droits sur cette œuvre.
✔ Rien dans ce contrat ne diminue ou ne restreint le droit moral de
l'auteur ou des auteurs.

4. Ippon Technologies en bref
160
CA
8 000 (Keuros)
CA 2010 : 9,1 ME Effectif
120
Objectif 2011 : 10,5 ME 6 000
115 Collaborateurs : 4 000
80
- Paris
40
- Nantes 2 000
- Bordeaux
- 0
2005 2006 2007 2008 2009 B2010
Principaux Clients 2010 Services
Services Publics : DGA, RATP, SNCF, CCIP, Apec
Banques : Crédit Immobilier, BNP Paribas, Crédit
Mutuel, Société Générale, GMF, Pacifica, Coface - Conseil : Architecture, Performances, Audit, POC
Telecoms / Internet : Orange Vallée, Globecast, - Assistance : Développement, Intégration, « Coaching »
PagesJaunes, Karavel Promovacances - Forfaits : 50 à 1500 j.h, méthodes agiles SCRUM
Distribution : Fnac, Accor, Carrefour, Cora, LVMH, - Centres de services : Agile ou UP / Prise en charge SLAs
Chanel
- Formations : Inter & Intra, 120 cours spécialisés
Industrie : CEA, EDF, Thales, GDF Suez,
Partenaires

5. Qui suis-je ?

20 ans d'activité dans la création de systemes informatique...

Dans l'industrie
 Utilisation de Hood, RUP, 6Sigma...

En SSII
 Passage sur UP, XP, Scrum

Participation a la mise en place de plusieurs socles méthodologiques

Directeur technique chez Ippon Technologies depuis 2003

Chef de projet et Directeur de projet
de plusieurs projets réalisés sur
une base Scrum

6. Scrum et forfait

Pourquoi Scrum peut-il s'adapter au
mode forfait ?

Comment peut-on adapter Scrum au
mode forfait ?

7. La vaste notion de projet

Définition PMI

Entreprise temporaire décidée dans le but de créer un produit,
un service ou un résultat unique

La gestion d'un projet s'inscrit dans des contraintes :
Coût

De périmetre fonctionnel

De délai

De coût
Délai Périmetre

Pour arriver au résultat, plusieurs voies sont possibles dont le
mode forfait

8. Tout est dans le partage du risque !

Traditionnellement, on oppose en SSII :

La régie : délégation de ressources aupres d'un client

Le forfait : prise en charge de la réalisation d'un périmetre
fonctionnel

Forfait : C'est la que ça frotte !

Le Client voudrait garder engagement délai / périmetre / budget

Tout le monde est intéressé par
le changement Partage du risque
Régie

Résistance a s'engager Forfait
SSII Client

9. La préhistoire de la gestion de projet

Waterfall (Cascade)

Hérité du BTP

Ce qui est spécifié est livré
a la virgule pres

Le cycle de prédilection du forfait

Long, tres long

Cycle en V

UP, RUP, 2TUP,...

Parallélisation

Cycle raccourcis

Résistance au changement

10. Introduire de l'agilité dans le forfait

Le manifeste agile : 2001 
Bénéfices

Individuals and interactions over 
Validation permanente du produit
processes and tools 
Flexibilité

Working software over 
Qualité du code
comprehensive documentation

Satisfaction du client

Customer collaboration over contract
negotiation 
Communication et motivation
permanente

Responding to change over following
a plan

Les méthodes agiles 
Contraintes

XP 
Acceptation du changement

Scrum 
Collaboration étroite avec le client

Crystal 
Priorisation des besoins

DSDM 
Prise de décision opérationnelle et
rapide

Lean

Contractualisation adéquate

11. Le forfait « non agile »
Bill – Maitrise ouvrage
« J 'ai fait 42 réunions utilisateurs pour sortir
mes 220 pages de cahier des charges,
c'est la Bible de l'Intranet »
Jo – Chef de projet
« Avec 220 pages de cahier des charges
et 342 pages de specs je suis sûr
que les développeurs vont sortir le projet »
« En plus j'ai pris les moins chers au forfait comme ça
j'aurai du budget pour les avenants »
Mike – Développeur(s)
« Je sais pas lire, je suis a 600 km de Jo,
je ne connais pas Bill,
je vais coder et je verrai bien... »

12. Le forfait « agile » Jo – Scrum Master
« Je lance le projet avec
25 exigences,
Bill – Product Owner Je communique avec Bill
« On lance le projet avec nos 25 pour faire évoluer cette liste
plus importantes exigences » Je me mets d'accord avec
Mike pour faire des sprints
efficaces et ne pas
les perturber »
Mike et ses copains
« Je travaille sur les taches qui m'intéressent a partir du chiffrage fait avec Jo
On démontre a Bill toutes les 3 semaines un soft qui marche
On l'adapte a l'issue du sprint selon le retour de Bill »

13. Concilier agilité et forfait

Pas une recette miracle, mais des pistes a explorer :

Engagement des équipes :
 Responsabilisation des développeurs
 motivation portée par les sprints

Partage du chiffrage et du risque
 Transparence
 Répondre aux changements dans
le respect des charges

Priorisation des exigences

Engagement sur des sprints courts et consistants

Mise en avant des avantages pour le client
 Flexibilité et acceptation des demandes de changement
 Tester tôt = recetter moins

Ne pas forcément appliquer Scrum a la lettre :

Le ScumMaster doit rester centré sur le management de l'équipe de réalisation

Ne pas hésiter a prendre la casquette de « Product Owner » si les décisions tardent

Gérer le calcul de vélocité de l'équipe pour les sprints a venir

14. Pistes de contractualisation forfaitaires
Modalités Avantages Contraintes Use Case
Forfait normal Périmetre fixe Habitude Cdc/specs 100% Refonte
Délai fixe Légitimité Pas de applicative
Budget fixe changement
Forfait par Périmetre évolutif Flexibilité Implication PO Marché privé
itérations Délai fixe Contrôle Contrat toutes les Régie ++
(3 mini) Budget évolutif 3 itérations
Forfait agile Périmetre évolutif Le changement Respect des Marché public
« Change for Délai fixe se fait par charges
free » remplacement
Budget fixe
Régie bonus / Périmetre évolutif Focus Respecter Scrum Productivité
malus Délai évolutif Prédictibilité Bonus / malus d'une équipe
Budget évolutif Suivi quotidien pour tout le monde régie
Engagement Périmetre a deux Engagement de Respecter Proof of concept
sur périmètre niveaux best effort sur périmetre
minimum Délai fixe périmetre minimum
Budget fixe complet

15. Case studies Scrum et forfait

Cadre peu propice a l'approche

Client demandeur d'une telle approche

Client déja préparé a la méthode Scrum

Proof of concept a fort risque

16. Plate-forme Internet eco - multi-sites (1/2)

Informations projet

Client public
 Dialogue compétitif suivi de la publication d'un CCTP
 Communication avant projet tres formalisée
 Equipe MOA en frontal des utilisateurs finaux

Non formé au méthodologies agiles

Constituée de plusieurs personnes pouvant porter la décision
 Contexte « tres politique »

Coût / Délai / Contenu
 Charge importante : environ 600 j.h
 Délai tres serré : moins de 6 mois
 Périmetre fonctionnel peu clair
 Incertitude technique forte (intégration avec un SI en construction)

17. Plate-forme Internet eco - multi-sites (2/2)

Utilisation d'une approche agile orientée Scrum

Définition « dirigiste » d'un product
backlog

Gestion d’un sprint 0 de 6 semaines
et de 6 sprints de 2 a 3 semaines

Lots de travaux visibles

Mise en place d'un outillage de
support méthode

Retour d'expérience

Les difficultés
 Difficulté a identifier un Product Owner
 Décision tardant a être prise

Les avantages
 Visibilité progressive de la solution
 Motivation continue de l'équipe
 Adaptation aux retards des
systemes tiers connectés

18. Galaxie de sites Internet européens (1/2)

Informations projet

Client européen
 Migration technologique
 Coldfusion => Liferay
 Réorganisation des équipes
 Fin du 1 projet = 1 développeur

Plateformes Internet
 15+ sites vitrines (petits projets)
 5 plateformes collaboratives (gros
projets)

Besoin initial
 Formations techniques
 Coaching technique
 Delivery de préférence au forfait

19. Galaxie de sites Internet Européens (2/2)

Formation Product Owner

Réorganisation avec mise en place PMO qui arbitre

Véritable backlog multi-projets partagé

Centre de service de développement multi-projets alimenté par
capacité (régie ou forfait)
Responsables de site Product owner
PMO
Equipe
Développeurs (dont ScrumMaster)

20. Projet d'application métier innovante (1/2)
 Informations projet
 Client privé
 Grosse entreprise du CAC40
 Précédente expérience de forfait Scrum
 Applicatif tres innovant
 Gros travail de spécifications préalables
 Wireframes applicatifs
 Spécifications fonctionnelles
 Évolutivité et adaptabilité de la solution
fortement recherchée
 En terme de fonctionnel
 En terme d'ergonomie
 Charge initiale de 250 j.h
 Délai de réalisation sur 16 semaines

21. Projet d'application métier innovante (2/2)

Utilisation de l'outillage Trac / Agilo

Publication du product backlog et du sprint backlog

Découpage des tâches et estimation partagée
de leur charge

Priorisation systématique des Users Stories

Planification initiale sur :

1 sprint 0 de 2 semaines
 Architecture, spécifications, mise en place environnements

6 sprints de 2 semaines en réalisation

1 release sprint de 3 semaines pour la recette avant production

Déroulement du projet avec acceptation des
demandes de changement

User stories supplémentaires

Travail de priorisation

Ajout concerté d'un sprint 7 de réalisation

Conclusion

Grande confiance réciproque

Disponibilité d'un vrai product owner

Equipe co-localisée et performante

22. Proof of concept bancaire (1/2)

Informations projet

Grande banque française
 Objectif de refonte sur technologie récente d'une offre existante

Proof of concept
 Utilisation d'un progiciel portail CMS éditeur
 Intégration applicative d'applications métier
 Fonctions Web 2.0 évoluées

Demande de cotation au forfait malgré :
 Une forte incertitude technique
 Une couverture fonctionnelle importante

Budget serré et délai tres court
 Objectif d'engagement du projet complet
 Durée : 4 semaines
 Charge : environ 50 j.h

23. Proof of concept bancaire (2/2)

Contractualisation avec un engagement

De résultat sur un périmetre minimum

De moyen sur le périmetre complet

Réalisation effectuée sur 4 sprints

Priorisation des users stories

Participation de toutes les parties prenantes aux scrum meetings

Finalisation du périmetre minimum des la fin du troisieme sprint

Ajouts fonctionnels selon demande sur sprint 4

Client extrêmement satisfait du résultat et du moyen de l’atteindre
Périmetre souhaité
Périmetre contractualisé
Périmetre réalisé

24. Retour d'expérience

Éligibilité d'un projet

Bonnes pratiques

Management de l'équipe

Outillage

Forces et faiblesses

25. Eligibilité d'un projet à Scrum
Taille équipe Petite Moyenne Grande
Délai projet Serré correct Détendu
Budget projet Serré correct Confortable
Périmètre contractuel Clair Peu clair Brumeux
Coopération client Forte Faible
Autonomie équipe Forte Faible

Critères essentiels :

Equipe projet de taille modeste (< 8 personnes)

Projet suffisamment long (au moins 10 semaines)

Critères facilitateurs :

Interaction forte possible avec le client (disponibilité, colocation, etc..)

Equipe de réalisation assez autonome (déja formée a Scrum, senior sur les technos
utilisés)

26. Particularités des sprints forfaitaires

Sprint 0 obligatoire :

Constitution, valorisation et priorisation du backlog

Mise en place de l'environnement de développement

Formation de l 'équipe a l'approche méthodologique et aux outils

Définition d'éléments d'architecture

Production de livrables contractuels

Sprint de réalisation :

Scrum meeting et auto-affectation des tâches

Tests unitaires et description des tests fonctionnels

Démonstration systématique en fin de sprint

Pas de mise en production

Sprint final de recette (« Release sprint »)

Finalisation des tests fonctionnels usine

Support a la recette cliente

27. Bonnes pratiques

Ne pas masquer « L'arrache » par « Agile »
http://www.risacher.com/
la-rache/

Éduquer, expliquer, démontrer

En début de projet : brieffing, REX, formation

En cours de projet : démos larges, outils accessibles a tous

Dire ce que je fais, faire ce que je dis

Ne pas être le premier a bypasser le stand-up

Ne jamais décaler une démo

Ne pas se tuer a vouloir « faire bouger les lignes »

Si management dit « non », ne pas essayer au niveau opérationnel

Si MOA dit « non » alors réduire scope a MOE

28. Management de l'équipe

Equipe au sens large
 Client (Product Owner) et Fournisseur (ScrumMaster)

Etablir une relation de confiance
 Assurer une transparence totale

Sur l'avancement

Sur le chiffrage des efforts
 Montrer un respect des engagements

Pas de décalage des rendez-vous

Démonstration de la qualité des livrables

Au sens de l'équipe de réalisation

Maintenir un rythme de production soutenu sans en abuser
 Prévoir un délai entre les sprints

Préparation des démonstrations

Estimation des tâches du sprint suivant
 Ne pas céder a la tentation de trop charger un sprint

Collégialité et honnêteté des estimations

Respect de la capacité maximale d'un sprint

29. Importance de l'outillage

Le besoin essentiel est de gérer

Le « product backlog »

Le « sprint backlog »

De donner une visibilité de l'avancement du projet

Les différents niveaux d'outillage

Les post-it
 Co-localisation obligatoire
 Attention aux courants d'air !

La matrice Excel
 Peu visible car au fond d'un répertoire de fichiers
 Circulation de la matrice a organiser

L'outil dédié. Les grands classiques :
 Jira + Greenhopper
 IceScrum
 Beaucoup d’autres !

30. Starter kit Scrum Ippon Technologies

Outillage d'un projet standard Outillage d'un projet Scrum

Gestionnaire de configuration Gestion du product backlog

Wiki de collaboration Planification des sprints

Gestion documentaire Gestion des sprints backlog

Tableau de bord de pilotage Décomposition et estimation des tâches

Gestionnaire de tests Burn down chart
Intégration continue et audit de code
 Ippon Technologies a mis en place une plate-forme spécifique orientée Scrum :
 SVN + Hudson + Sonar pour la gestion du code et son contrôle
 Plate-forme virtualisée pour l'intégration continue
 Plate-forme unifiée de suivi projet complete :
 Sur base du gestionnaire d'anomalie Trac spécifiquement paramétré (http://trac.edgewall.org/)
 Présence d'un Wiki simple et performant
 Structuration adaptée aux problématiques de GED
 Acces au SVN
 Intégration de la gestion des risques et des actions (PAQ)
 Plugin Agilo d'extension de trac (http://www.agile42.com/cms/pages/agilo/)
 Support des aspects propres a Scrum (User Stories, Sprints, etc..)

31. Forces, faiblesses et écueils de Scrum
Forces Faiblesses Ecueils
Relation avec le client
 Permet d'instaurer une relation  A t-on véritablement un Product  Retourner a un mode forfaitaire
de confiance et d'échange Owner côté Client ? standard des le premier
 Démonstration réguliere  Est-on réellement protégé symptôme de blocage
 Transparence sur l'avancement contractuellement pour accepter  Se retrouver dans une approche
 Donne la capacité de satisfaire le changement ? trop dirigiste du projet
au mieux les besoins  Prendre définitivement la
casquette de Product Owner...
Management de l'équipe de réalisation
 Réduction de l'inertie de  L'équipe est-elle prête a  Rendre chaque sprint comme un
démarrage d'un projet s'impliquer et a collaborer ? challenge pour l'équipe en les
 Maintien de la motivation de  Les développeurs sont-ils surchargeant
l'équipe a chaque sprint suffisamment polyvalents  Renoncer a gérer une ressource
 Démarche de responsabilisation (codage, tests, correction) ? non formée
Qualité générale du produit
 Démarche de tests et  Comment minimiser le surcoût  Ne pas négliger de gérer la
d'assemblage systématique lié aux tests et aux dette technique
 Recherche de la simplicité de démonstrations de fin de sprint ?  Bien gérer la communication
réalisation entre membres de l'équipe
 Visibilité anticipé du résultat  Ne pas omettre les outils
pour le client connexes (IC, Sonar, etc..)

32. Merci