Cette session est le retour d’expérience de 8 mois de mise en place de scrum au sein d’une équipe de développement logiciel en haute-normandie. Le scrum master et l’architecte de l’équipe vous feront des retours terrains sans langue de bois.

1. Scrum dans les tranchées normandes
Youen Chene, Anthony Hurot
Rouen - 13 octobre 2011
13 octobre 2011

2. Partenaires Gold
Partenaires logistique
13 octobre 2011

3. Vos intervenants
Anthony Hurot Youen Chéné
Scrum Master Architecte
Masternaut Masternaut

4. Mise en place de l'agilité

5. Contexte initiale
Un bilan mitigé au sein de l'entreprise :
● une équipe de développement hétérogène
techniquement et fonctionnellement,
● une gestion de projet basé sur le cycle en V et avec
des manques sur les premières étapes,
● frustation des développeurs de ne pas être impliqué,
● frustation des MOA dû à des retards à la livraison et
une qualité inappropriée.

6. Contexte initiale
La solution ?
● arrivé d'un nouveau projet de refonte,
● sélection d'une nouvelle approche/ méthode,
● sélection d'une équipe pilote au seins du service
développement,
● nouvelle direction dans l'entreprise.

7. Gains espérés
Gain Objectif
Compétence de l'équipe Meilleur homogénéité
Augmentation des compétences.
Time To Market
Implication des
développeurs
Transparence
Traitement des Focalisation sur la résolution plutôt
problèmes que sur les coupables.

8. Pratiques cibles
Scrum

9. Les 3 premiers mois
Mise en place d'un ScrumMaster débutant (ex
développeur).
Mise en places de l'ensemble des cérémoniaux scrum
remanié par le ScrumMaster en version light.
Mise en place d'un Product Owner et d'un super Product
Owner.

10. Les 3 premiers mois
Dashboard

11. Les 3 premiers mois
Burn Down Chart

12. Les 3 premiers mois
Le bilan
Dérive des artefacts scrum (manque le burndown chart,
pas de reporting).
Vision positive de l'agilité.
Apport bénéfique sur l'équipe, le Product Owner et les
contacts extérieurs.

13. Les 3 premiers mois
Plan d'action
Mise en place de reporting et d'indicateur.
Intervention extérieur coach agile.
Changement de scrum master.

14. De 3 à 6 mois
Mise en place d'un ScrumMaster plus rigide.
Application des cérémoniaux scrum intégralement.
Mise en place d'un outil en ligne (IceScrum puis Jira/
Greenhopper).
Travail sur le Definition of Done, le formalisme d'une story
/ tâche.
Changement dans l'équipe (éviction des éléments
perturbateurs).

15. De 6 mois à un 1 an
Dashboard

16. De 6 mois à un 1 an
Burn Down Chart

17. De 6 mois à un 1 an
Burn Down Chart

18. De 3 à 6 mois
Le bilan
Remise en cause de l'agilité par l'équipe.
Coups de mou, la méthode est dans le dur.
Turn over dans les équipes.
Mise en place de scrumban.
Mutualisation scrum master
Réflexion sur un contrat Scrum

19. De 6 à 9 mois
Débat et intégration de l'équipe sur la méthode de travail.
Clarification des rôles de chacun.
Sortie régulière d'éléments livrables.

20. De 6 à 9 mois
Dashboard
Scrumban

21. De 6 à 9 mois
Burn Down Chart

22. De 6 à 9 mois
Rien n'est jamais acquis

23. De 6 à 9 mois
Burn Down Chart

24. De 6 à 9 mois
Le bilan
3ème scrum master.
Equipe rodée.
Perte du product owner.
Non adoption au niveau entreprise (manque de visibilité
planning pour la direction).
Mieux expliquer les intérêts et les limites.

25. Dans le monde de
l'entreprise

26. La gestion des anomalies et des urgences
Les bug et les demandes urgentes.
Ajout d'une ligne Bugfix sur le dashboard (Scrumban).
Remplissage des sprints entre 50% et 80%.
Point de contention.
Pédagogie nécessaire pour expliquer le fonctionnement
des sprints.

27. Les livraisons à l'exploitation
Difficile sur les premiers sprints.
Ajout d'un tâche récurrente de packaging sur chaque
sprint.
Capacité à livrer à chaque sprint sur les 3 derniers mois.
Nécessité d'un rôle à part de type "Devops" pour le
support à l'exploitation.

28. L'architecture
En cycle V : mise à l'épreuve au bout de 4 à 6 mois.
En scrum, c'est au bout de 2 sprints (1 mois).
Une plus grande implication des développeurs.
Plus de débats, plus d'ajustements.
Une architecture améliorée.
Davantage de place pour du refactoring.

29. Au sein de l'organigramme
Conflits entre Chef de projet MOA et Product Owner.
Conflits entre Chef de projet PMO et Scrum Master.
Des dates versus un engagement sur une première
itération.
Conflit permanent entre les scolaires GANTT/PERT et
Scrum.
1er règle de Claude Emond :
"Ne jamais donner de date."

30. Bilan

31. Le point de vue des développeurs
Les avantages
La responsabilisation des développeurs :
○ Une plus grande marge de manoeuvre.
○ Pas de sur-spécifications.
Un meilleur esprit d'équipe :
○ Plus d'intéractions.
○ Equipe plus facile à intégrer pour les nouveaux.
○ Equipe plus homogène.
Un meilleur pragmatisme :
○ Les dérives sont détectés au plus tôt.
○ Capacité de corriger au plus vite.
Confort d'un périmètre stable sur un sprint.

32. Le point de vue des développeurs
Les inconvénients
Lourdeurs des cérémoniaux.
Manque de formalisation/spécifications.
Difficulté d'intégration des développeurs sur un autre site
ou en télétravail.
Plus difficile quand un développeur est sur un autre projet.

33. Le point de vue des développeurs
Bilan
Les interactions avec le Product Owner est le point le plus
important.
Quid de l'opportunité de Kanban?

34. Le point de vue du directeur
Les avantages
Fin des effets tunnels sur les projets.
Evaluation rapide des résultats, moins de gaspillage de
ressources.
Constitution d'une équipe cohérente après plusieurs mois.

35. Le point de vue du directeur
Les inconvénients
Exacerbation des tensions existantes au sein de l'équipe.
Règle des cérémoniaux trop strict.
Gros impact si le product owner et/ou le scrum master
sont défaillants (pas propre à Scrum).
Gros besoin d'évangéliser les autres services pour faire
comprendre le changement d'habitude.

36. Le point de vue du directeur
Bilan et Conseils
Meilleur résultat qu'un cycle en V.
Ne pas subir l'auto-gestion de l'équipe mais imposer des
règles.
Choisir un Scrum Master et un Product Owner avec de
l'expérience (ou se faire accompagner).
Ne pas hésitez à remplacer les membres de l'équipe qui
n'adhèrent pas.

37. Notre point de vue
Les difficultés
L'adoption dans la durée et dans toutes les strates.
La communication transparente sur les gains possibles et
les limites.
La mise en place sur un existant.
La gestion des égos dans l'équipe.

38. Notre point de vue
Les points positifs
Responsabilisation des équipes.
Une meilleure homogénéité des compétences.
Davantage de confiance dans les relations MOA/MOE.
Des livraisons régulières.

39. Conclusion et perspectives

40. Gains espérés versus obtenus
Gain Objectif Obtenu
Compétence de Meilleur homogénéité
Augmentation des compétences. Homogénéisation.
l'équipe
Time To Market Plus de livraisons.
Mais pas synchro.
Implication des
Au bout de 8 mois.
développeurs
Transparence
Echec vis à vis des
autres services
Traitement des Focalisation sur la résolution plutôt que
sur les coupables. Meilleur réactivité
problèmes avec
Scrumban.

41. Leçons apprises
Rien n'est acquis.
Constituer une équipe est difficile.
L'agile doit aller au delà du service informatique.
Scrum n'est pas l'unique méthode agile (adaptez au
contexte).

42. Conseils
Une pause d'une semaine pour relâcher la pression après
une série de sprints.
La technique "En tant que .., je .." marche très bien pour
les demandes avec UI mais pas pour du middleware.
Evangéliser, Evangéliser, Evangéliser!

43. Perspectives
Kanban ?
Scrumban ?

44. Crédits Images
Equipe de France - Grève des joueurs | Reuters/© Charles Platiau / Reuters
http://www.flickr.com/photos/paddymccann/417406760/
http://www.flickr.com/photos/photorobw/2673808472/
http://www.flickr.com/photos/thomaslevinson/3602997478/
http://www.flickr.com/photos/catmurray/1687104755/
http://www.flickr.com/photos/maxiwalton/5060384810/
13 octobre 2011