Mettre en œuvre SCRUM :

ScrumDay Paris

27 mars 2012

Bruno Borghi

Akeirou

2

Merci à nos sponsors Platinum

3

Et merci à nos sponsors Gold et Silver

4

Développer un produit, c’est simultanément construire et faire fonctionner deux systèmes indissociables :

un système social et un système technique.

management

systèmetechnique

ingénierie

systèmesocial

5

La construction et le fonctionnement du système social

génèrent

6

Par exemple,

7

8

9

Pourquoi y a-t-il des sujets qui fâchent ?

10

Les connaissances, les convictions, les croyances sur la marche de l’entreprise

s’affrontent

Objectifs

Moyens

RésultatsPertinence

Efficience

Efficacité

11

• Accueillir chaleureusement tous les sujets qui fâchent, d’où qu’ils viennent– Reconnaître la légitimité des désaccords

• Créer les conditions d’un dialogue entre les protagonistes sur ces sujets

• Considérer ces sujets comme des obstacles à lever progressivement

Démarche générale de traitement des sujets qui fâchent

12

Revue de sujets qui fâchent

13

Les estimations

• Les demandes d’estimations sur un périmètre fonctionnel flou, voire inconnu

• La précision attendue par le business pour les estimations

• Les estimations « macro » en story points

14

Pour calmer le jeu

• Le business comprend les estimations en charge et en délai– Ne pas les énerver inutilement avec nos

histoires de story points

• Le business veut estimer un retour sur investissement et une date de disponibilité– Faire des chiffrages « macro » à la mode

analytique– Fournir des chiffrages uniquement sous forme

de fourchettes

15

Pour calmer le jeu

• La technique a besoin d’un périmètre clair pour chiffrer– Organiser les besoins en Sagas, Épopées,

Histoires– Chiffrer au niveau Épopée– Pour chaque épopée, instituer une conversation

entre business et technique pour préciser le périmètre

• Appeler ces conversations « Réunions de cadrage »

16

17

Le planning, la valeur business

• « Ce sera fait pour quand ? »– « Ce sera fait quand on en sera là dans le

Product Backlog »– « Cela dépend des priorités entre le business

B2B et le business B2C »

• « Et si j’augmente la valeur business, ce sera fait avant ? »

• « C’est super-urgent. Vos sprints, ils sont trop longs. »

18

Pour calmer le jeu

• La transparence est clé– Afficher une Roadmap en fiches Bristol dans le

bureau du Product Owner– Rester ferme sur la durée des sprints

• Les différentes lignes de business en concurrence ont besoin d’une instance pour négocier les priorités– Instaurer une cérémonie du genre « Comité

d’Orientation Roadmap »

19

20

Les coûts

• « La moindre fonctionnalité nous coûte trop cher ! »

• « Vous ne prenez pas assez de fonctionnalités dans un sprint ! »

21

Pour calmer le jeu

• Augmenter la qualité– User stories au format standard– Contrôles croisés fréquents

• Ramener le débat sur la question des coûts completsDéveloppement + correction des bugs en cours de mise au point + recette + incidents de production + correction des bugs après déploiement

22

Pour calmer le jeu

• Remplacer la réduction des coûts par la réduction des gaspillages– Expliquer au business et à la technique les 3 M

• Muda (gâchis)

• Mura (variabilités entraînant des stocks)

• Muri (excès)

23

La dette technique

• Pour la technique : un cauchemar

• Pour le business : un truc de développeur pour se faire plaisir plutôt que de développer des nouvelles fonctionnalités

24

Pour calmer le jeu

• Mettre des items de dette technique explicitement au backlog

Visible Invisible+

Valeur Business Positive

FonctionnalitésEvolutions architecture / infrastructure

-Valeur Business Négative

Anomalies Dette Technique

25

L’équipe auto-organisée

• Qui prend les décisions ?– 2 tendances cohabitent souvent

• Tendance à prendre des décisions techniques par un processus supposé démocratique

– Immobilisme

• Tendance à ce que chacun n’en fasse qu’à sa tête– Désordre

• Qui est le chef ?• Qui fait passer les entretiens annuels ?

26

Pour calmer le jeu

• En tant que coach, être directif– Quand il le faut …

• Redonner du sens à la vie de ceux qui étaient chefs

27

SCRUM

• « Pourquoi on fait SCRUM ? On pourrait simplement faire de l’agile ! »

• « On n’a pas besoin de faire tout SCRUM ! »

• « On n’a pas besoin d’un Product Owner ! »

• « On n’a pas besoin d’un Scrum Master ! »

28

Pour calmer le jeu

• Former le maximum de monde à SCRUM– Le business comme la technique– Si possible, tous Certified Scrum Master

• Faire des sessions d’information SCRUM avec ceux qui ne sont pas formés et qui sont un peu périphériques

29

En conclusion,

lors du déploiement de SCRUM, il y a des foyers permanents de tensions entre

la direction, le business et la technique

Quand ces foyers de tensions n’existent pas, il vaut mieux s’inquiéter …

Merci de votre attention