Agilité et Scrum

Concepts, valeurs, utilisation.

aribeiro@betomorrow.com V 1.7
 Programme

A. Attentes des participants ?

B. Les principes essentiels de l’agilité
C. Menu de sujets à la carte
D. Coaching clinic – Cas pratiques
 Vos attentes ?

Qu’est-ce qu’une méthode de travail

pourrait faire pour vous ?
Et cette réunion ?
 Agilité - Scrum

L’intérêt : atteindre les objectifs du client, de chacun.

Nécessité de définir les vrais objectifs, les conditions de succès

du projet.
(pas « respecter ce contrat » ni « être agile »)
 Le scrum à Betomorrow

Introduction progressive « bottom-up »

Chacun y a trouvé ses intérêts : diffusion

naturelle et progressive.

Aujourd’hui : Une vision plus aboutie de l’agilité,

toujours en évolution.
Sur quels atouts peut reposer le
succès d’un projet ?

Les ingrédients du succès ?

 Les ingrédients d’un succès agile.

Les personnes et leurs échanges

avant les processus et outils
 Les ingrédients d’un succès agile.

Collaboration
et Confiance
préférées à
la négociation de contrat
 Les ingrédients d’un succès agile.

Livraisons de logiciel de qualité

Livraison régulière de produits de qualité

préférée à une documentation précise
 Les ingrédients d’un succès agile.

Réaction au changement et adaptation

préférées au suivi d’un plan fixe

Inspect and adapt !

Agilité – Les ingrédients du succès
 Les personnes et leurs échanges
 La collaboration et la confiance
 La transparence et l'adaptabilité
 La réponse au changement
 La livraison de produits de qualité

Un ensemble cohérent
Un Contexte
Agilité – Les ingrédients du succès
Les individus et leurs interactions
Plutôt qu’outils et processus

La collaboration et la confiance
Plutôt que la négociation contractuelle

La réponse au changement
Plutôt que le suivi d’un plan

La livraison de produits fonctionnels

Plutôt qu’une documentation exhaustive

Un choix !
 Transparence

Honnêteté, confiance, visibilité…

Scrum : la base de l’organisation
 Scrum : les
principes agiles en
application

Planning - humains et interactions

Daily - collaboration et confiance
Démo - transparence et adaptabilité
- réponse au changement
Retro -livraison de produits de qualité
Backlog -Timeboxing
Itérations -Feedback client
 La Carte
1. Avantages : Pourquoi l’agilité ?
2. Inconvénients : Mises en garde
3. Itératif : ou incrémental ? Est-ce utile ?
4. Livraisons très fréquentes
5. Chaos : Un ennemi ?
6. Spécifications agiles : Value driven
7. « Done » : Le niveau de qualité
8. Pouvoir de l’équipe
9. Les tests : Agile testing
10.Implication du client
11.Coopération : Pas de snipers !
12.Questions et débats : Engagements, forfaits, grosses équipes...
Les inconvénients du développement agile
 Les inconvénients (potentiels) du
développement agile (1/2)

 Nécessite disponibilité et engagement du client.

 Flexibilité du périmètre
 Moins d’anticipation pour certains acteurs : campagne marketing…
(était-ce possible ? -> engagements différents, plus souples et réalistes)
 Dérapages possibles du « cahier des charges »
si modifications trop impactantes (scope creep) (à éviter avec une vision claire et la
sensibilisation du client : transparence)

 Malentendus possibles si mauvaise communication.

(dus à l’expression assez minimale des besoins, précisés juste à temps)

 Effectuer les tests tout au long du projet, les refaire régulièrement, peut
augmenter les coûts (-> automatisation des tests)
 Les inconvénients (potentiels) du
développement agile (2/2)
Les plus profonds…

 L’agilité et sa transparence révèle les problèmes -> rejet brutal possible.

Ils peuvent être ponctuels pour le projet ou plus profonds : on préfère parfois
se masquer certaines réalités. Une équipe Scrum et son Scrum Master sont contents de révéler,
de mettre à jour des problèmes, parce qu’ils pourront ainsi essayer de les résoudre. Esprit de
rétrospective, de recherche de blockers…

 L’agilité n’est pas magique !

Des projets agiles peuvent mal se dérouler et faire face à des difficultés
majeures, comme avec d’autres méthodes.
 Agilité  notamment transparence, visibilité réelle et remise en question, mais pas
de magie !

 Méfiance du changement et habitudes difficiles à changer.

Les bonnes raisons d’aller vers l’agilité
 Les bonnes raisons pour aller vers
l’agilité

Performance – Productivité

Plus un problème est corrigé tardivement, plus il

coûte cher, de manière exponentielle.

Détecter tous les problèmes au plus tôt

 Tests pendant le dev, conditions réelles complètes dès que
possible, feedback sur les versions partielles...

Eviter les « stocks » et tous leurs inconvénients.

 Les bonnes raisons pour aller vers
l’agilité

 Livraison “du bon” produit

 Feedbacks
 Avec juste assez de prédiction : Précision des specs plus
tard, donc avec plus d’infos et plus réactive.

 Flexibilité – Agilité : Le changement est accepté

(voire encouragé)
 Les bonnes raisons pour aller vers
l’agilité

• Satisfactions individuelles – implication

• grâce à l’esprit de collaboration, aux relations humaines, à la
confiance, aux démonstrations, au rythme soutenable...

• Transparence
• information complète et fiable sur l’avancement, les erreurs
etc… Visibilité réelle, confiance...
 Les bonnes raisons pour aller vers
l’agilité

 Plus de revenu, plus tôt grâce aux versions intermédiaires

 Speed-to-market -> possibilité d’arriver plus vite sur le

marché, avant la concurrence…

 Contrôle des coûts grâce aux itérations fixes (périmètre

variable mais dates fixes)

 Gestion des risques grâce à la visibilité réelle, qui permet

d’anticiper les problèmes au plut tôt.
Des spécifications à valeur client
Juste assez ! Juste à temps!
 Des spécifications à valeur
client
Juste assez ! Juste à temps!

 Objectif : Valeur client !

 Spécifications simples, claires et haut-niveau. (User

Stories)

 Humilité dans l’anticipation -> précision dégressive.

 Guidé par les objectifs. Transparence, implication…

 Des spécifications à valeur
client
Juste assez ! Juste à temps!

 Juste assez Assez !

 Spécifications et Planning Ensemble !

 Spécifications souples au changement et

évolutives. (dates fixes…)

 Specs et docs  lourdeurs  juste assez.

Complexité d’un projet et incertitudes
How D'you Eat An Elephant?
Small, incremental and iterate
 Comment mangez-vous un éléphant ?
« - Une bouchée à la fois ! »
Approche itérative !

 Un maximum de vraie valeur au plus tôt

Éléments du backlog : valeur livrable. Value-driven

 Cycle Agile : Cycles en parallèle, dont analyse/test...

Analyse “juste à temps”. Cycle traditionnel simple: Etapes
séquentielles, dont analyse prédictive

 Avantages :
 Visibilité concrète et claire sur l’avancement.
 Livraison de valeur plus tôt : possibilité de sortir le produit (Public beta…)
 Flexibilité
 Contrôle des coûts : pas d’effet tunnel.
 Feedback pendant le dev pour amélioration
-> Bon itératif vraiment nécessaire pour profiter de l’agilité
Livraison fréquente de produits
Fast But Not So Furious !
 Livraison fréquente de produits
Fast But Not So Furious

 La haute fréquence multiplie les intérêts de l’itératif

 Livraison fréquente de produits cohérents et de qualité  Exigence

entraine l’application nécessaire de pratiques agiles (approche itérative, tests
permanents…)

 Speed-to-market
un avantage concurrentiel essentiel. Très adapté au web.

 Aide à évoluer plus efficacement, à préciser la vélocité et les prévisions.

 Nécessité d’un rythme soutenable sur tous les plans. Eviter l’accumulation de
dettes diverses est nécessaire pour pouvoir livrer régulièrement.
Le Chaos, toujours un ennemi ?
 Le Chaos, toujours un ennemi ?

• Organisation
Chaos
- Rigueur
- Stabilité + Diversité
- Processus * Mouvement
- Plans o Liberté
- « Carré ! » X Création !

• Un Chaos contrôlé ? (discussion libre

timeboxée, auto-organisation cadrée et facilitée…)
 Quelques clés
prati-chaotiques
 Juste assez de procédures, de règles. Un bon début : la
charte de projet.
Attention aux ajouts de lourdeurs, même s’il y a
toujours « une bonne raison ».

 On peut accepter un fonctionnement imparfait, on le

doit.
il faut choisir les imperfections qu’on tolère.
(exple : choisir entre des petits malentendus dans l’équipe ou
les lenteurs dues à des specs très précises)
 "Done" Means "DONE!"
Terminer chaque fonctionnalité avant de passer à la suite.
 "Done" Means "DONE!"
Terminer chaque fonctionnalité avant de
passer à la suivante.

 Trop souvent : “Done” = développé.

Agile : Chaque fonctionnalité est totalement développée, testée, ajustée et accordée avec le PO (Product
Owner) avant d’être notée “Done”.

 "DONE!" doit signifier livrable (shippable). -> prête à envelopper

Comme un cadeau qu’on a enveloppé. “Cette feature est-elle vraiment enveloppée et prête à être livrée?".

 Le produit doit être livrable à la fin du Sprint pour avoir de la valeur

fonctionnalités 100% terminées.

 Apporte la visibilité réelle :

information précise sur l’avancement. Pas d’accumulation de dettes masquées difficiles à estimer.
L’équipe a le pouvoir de prendre des
décisions !
 L’équipe a le pouvoir de
prendre des décisions !

 L’équipe au sens large fait tous les choix importants

choix techniques, priorités, tâches, niveau de qualité et contenu des livraisons.

 Plus de qualité de l’équipe et de confiance nécessaire

que dans une approche traditionnelle : La qualité de l’équipe est essentielle !  La
confiance du management et du client dans l’équipe est donc nécessaire.

 Implication aux décisions -> Motivation et engagement

dès le départ -> apporte qui se révèlent essentiels, surtout lorsque
l’équipe doit faire face à des difficultés.

 Tous présents pour prendre de rapides et bonnes décisions.

 Le client doit aussi être étroitement impliqué.
Agile Testing Is Not For Dummies!
 Les tests sont intégrés au développement durant
tout le cycle de vie du projet.
Agile Testing Is Not For Dummies!

• Phase de test non séparée comme dans une approche traditionnel : tests continuels,
permanents, effectués (développés) par l’équipe  tests automatiques..

• Exigences de l’agilité  intégration continue et qualité des tests

• XP (eXtreme Programming) : Test Driven Development TDD. Tests au cœur du

développement, garantissent la qualité et définissent le produit.

• Conditions de réussite (= tests) au lieu d’une spec exhaustive 100% détaillée.

• Tests humains et feedback -> Rôle plus important : apprécier la qualité du produit.

• Toutes ces raisons font l’exigence de qualité et l’importance des tests agiles!
L’implication du client est impérative
Engagement partagé
 L’implication du client est
impérative
Engagement partagé

 Les besoins sont clairement communiqués, expliqués et

détaillés. De nouveaux besoins émergent.
 “Le bon produit” : correspondant aux attentes du client.
 Engagement et responsabilité partagés : gestion des
problèmes, livraison à temps  effort commun de l’équipe.
 Décisions rapides
 Toute l’équipe – business et technique – travaille ensemble!
 Transparence complète : avancement, problèmes…
Une approche coopérative est essentielle.
No Place For Snipers!
 Une approche collaborative et
coopérative entre tous les intervenants
est essentielle.
No Place For Snipers!

 L’agilité repose sur une étroite collaboration et coopération entre TOUS les
membres de l’équipe et les intervenants.

 Auto-organisation de l’équipe, qui prend des décisions, choisit son engagement 

esprit collaboratif nécessaire.
 Avec le client : Documentation légère, changeante et précisée “juste à temps” 
étroite collaboration permanente nécessaire.

En travaillant dans un but commun, pour créer un meilleur travail d’équipe et

construire de solides relations de coopérations.

 L’agilité contribue à l’esprit d’équipe et à la motivation.

 L’agilité nécessite l’esprit d’équipe et la motivation.
 Questions et débats…
• S’engager sur le résultat, sur la date ?
• Quel type de contrat ? Des forfaits ?
• Scrum et les gros projets ?
• Equipe multi-projets ?
• Réponse agile à un appel d’offres ?
• L’agilité et les conflits ? humains, business…
• Et si on sait exactement ce qu’on veut faire ?
• Convaincre un client de travailler Agile ?
• Scrum = relax ? Travailleurs tranquilles ?
• … vos doutes ? Questions ?
 Avancé
 Des « stocks » dans nos projets ? Flux tendu industriel ?
Les conséquences des stocks en tout genre. Repérage systématique et
réduction.
 Scrum sans besoin d'en parler, c’est possible ?

 Les indicateurs : l’intérêt et les travers.

Que faudrait-il mesurer ? - Les optimisations locales et le vrai objectif
 Réflexe : « Non parce que... »
-> Cette raison est-elle vraiment suffisante ?
 Pièges agiles...
À lire avec précautions

Ces pièges sont des exceptions à travailler

seulement si le niveau d’agilité de l’équipe est
déjà bien avancé.
 Pièges de fans de Scrum
 « Vive le Scrum ! Vive la méthode et ses outils ! » ...
Le succès du projet ne doit pas reposer sur la méthode et les outils !

 Pourquoi on ne peut pas... ? Parce qu’on est en Scrum !

Le scrum n’est pas une excuse obscure, et ses pratiques sont là pour de vraies
bonnes raisons, à repréciser à chaque fois.

 Le PO est avec nous, il écoute l’équipe... un peu trop ?

Le PO doit connaitre ses priorités, ses principes essentiels et ne pas les
négliger petit à petit sous les pressions diverses. L’écoute utile de l’équipe ne doit pas
devenir une faiblesse des positions.
 Pièges d’amélioration continue
 On s’adapte ! Super, et si on résolvait tous les problèmes ?

 L’inacceptable potentiel de l’inaction

L’inaction face à un problème est-elle respectable ? défendable ?
Se protéger et arriver à l'inertie
 Problème -> action... Quoi ? Des effets secondaires ?
Considérer tous les effets de bords d’un choix et l’ensemble de la situation :
nécessité d’un ensemble cohérent (ici un ensemble agile), d’un ensemble d’actions qui
envoient le même message. Des messages contradictoires ne permettent pas de
construire une dynamique efficace.
 Faut-il forcément tout comprendre ?
Les pièges des réflexions sur les relations de cause à effet face aux avantages
de l’expérimentation.
 Sommaire
A. Introduction aux objectifs
B. Attentes des participants ?
C. Les principes essentiels de l’agilité
D. Menu à la carte en fonction de l’audience :
1. Avantages : Pourquoi l’agilité ?
2. Inconvénients : Mises en garde
3. Itératif : ou incrémental ? Est-ce utile ?
4. Livraisons très fréquentes : Pourquoi et comment ?
5. Le chaos : Un ennemi ?
6. Spécifications agiles : Précision et flexibilité ?
7. « Done » : Le niveau de qualité.
8. Pouvoir de l’équipe : Quelles implications ?
9. Les tests : Agile testing.
10. Implication du client : Vrai membre de l’équipe.
11. Collaboration : Tous ensemble... Sans snipers !
12. Questions et débats : Dates fixes ? Gros projets ? Specs fixes ? ...
13. Scrum avancé : Pièges des fans de scrum et de l’amélioration continue.
 Sources – Liens - Remerciements
Ce document est créé et rédigé par l’auteur, librement inspiré de plusieurs sources
citées ci-dessous. Nous remercions particulièrement :
 http://www.pyxis-tech.com et l’équipe de Pyxis, dont François
Beauregard et Vincent Tencé.
 Toute l’équipe de BeTomorrow, pour son intérêt pour l’agilité et
ses contributions continues.

 http://www.agile-software-development.com
 http://scrum.aubryconseil.com
 http://www.mountaingoatsoftware.com
 http://etreagile.thierrycros.net
 http://www.controlchaos.com

Alexandre Ribeiro
aribeiro@betomorrow.com