Bon coach bad coach

835 vues

Publié le

L'histoire de 2 transitions chez Ubisoft racontée par 2 coachs. 2 approches différentes, 2 résultats intéressants.

Publié dans : Logiciels
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
835
Sur SlideShare
0
Issues des intégrations
0
Intégrations
78
Actions
Partages
0
Téléchargements
10
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Introduction de l’organisation initiale
  • Sans vision, sans savoir sur quoi travailler ensuite, Notion faible d’itération, JIRA était un bugtracker/wishlist

    Une sorte de chaos maitrisé!
  • Commencer la liste au début puis insister sur le fait que ce sont toutes les pratiques à mettre en œuvre que l’on peut voir dans un guide scrum, sauf que je l’ai étalé sur plusieurs mois et dans un certain ordre. Nécessaire car différent chapeaux!
    Finir par le dernier, attention du mgmt.
  • Analyse importante : J’ai passé du temps en itérant avec plusieurs personnes du management pour confronter les idées et amener un flow basé sur l’outil… Feedback important.
    Inclure l’importance du management et de son soutien.
    Approbation version 1.0 du flow!
  • Outil mal utilisé : Beaucoup de monde détestait travailler avec JIRA!
    Besoin de reposer la transition sur des éléments concret : Permet de tester de nombreux cas de figure
    Volonté d’adapter l’outil au processus
    Mise à jour régulière du flow pour adapter au quotidien et en retour des rétrospectives


  • Scrum de ScrumMasters pour mesurer l’efficacité de la méthode et avoir du feedback et des indices en cas de déclinaison.
    Mise en place outils de base : définition DONE, Point de référence, Core process, etc…
    Formation rapide : Agilité, Jira, Core process
    Il semble qu’il manque une équipe? (Pas Service 2 qui a déjà fait la transition) mais l’équipe de Release. Qui en fait était assez petite à l’époque de la réorganisation (juste 2 personnes).
    On avait la volonté de les intégrer complètement dans l’équipe mais par manque de temps et pour la petite équipe on a laissé faire. Pour info, je viens de terminer la transition de cette équipe. ils ont grossi, ils sont maintenant 4.
  • Il existait déjà la séparation CORE/SERVICES
    Note : Mettre Equipe management à gauche! Mettre les 5 équipes
  • Gros travail de coaching… on a pas seulement remplacé les titres des personnes, on a créé des rôles et j’ai participé à la formation des nouveaux rôles. C’est un travail de fond qui ne s’arrête jamais!
  • SIG : Pour traiter les sujets transverses à l’équipe. Présidé par un « owner ». Les personnes sont libres d’y participer mais cela demande un minimum d’implication. (on veut encourager les motivations! Les personnes motivées sont les plus à même de répondre au besoin)
    Anecdote : Les Backlog Maintenance de Leads étaient très difficile à leader et à apporter une valeur ajoutée, après plusieurs petites ajustements (redéfinition des objectifs, réunion en sous-groupes etc..), Plus personne ne s’en passe ajourd’hui!
  • Disponibilité réelle
    Balance entre les besoins de structure et la souplesse de mise en œuvre
    Créer une structure décisionnelle efficace
    Conflit rôle : SM – TL – Coach Agile


  • Rétros : que du bashing inter-équipe
    Dailys : reporting
  • Des équipes multi-disciplinaires concentrées sur un seul projet
    Pour que les équipiers ne se sentent pas constamment tiraillés
    Pour qu’ils deviennent responsables des dépendances
    Pour qu’ils puissent compléter leurs items sans être dépendants d’autre équipes
    Pour qu’ils apprennent à travailler ensemble, qu’ils améliorent leur processus, qu’ils apprennent à prévoir ce qu’ils vont accomplir
  • + coaching individuel des Scrum Masters
  • Chacun suggère des sujets et on en choisit une
    Quelqu’un amène du matériel qu’il a appris ailleurs (livre, formation, conférence)
    Ouvert à tous OU pour SM seulement
  • 1. d’appartenir à une équipe, créée par les journées de démarrage et les noms d’équipe
    2.
    3. de ce sur quoi on travaille et de ce qui vient dans les prochains mois
    4.
    5. 2 semaines avant la date annoncée
    6. inter-équipe

    9. Ex. Après mon départ :
  • FeedBack!
    Assurez-vous que les gens comprennent ce que vous dites
  • Ex : Je suis perçu comme un évangéliste – intégristes pour certains et laxiste pour d’autres
    Ne promettez pas la lune, ce n’est pas le but de la méthode. La méthode parfaite n’existe pas. Identifiez les risque au plus tôt!
  • Bon coach bad coach

    1. 1. Isabelle Therrien @itherrien Nicolas Mivielle @sonic1200
    2. 2. UBISOFT & GROUPE TECHNOLOGIQUE - Plus de 300 personnes - Fourniture de solutions logicielles pour les jeux - Collaboration directe avec les jeux, « architectes volants »…
    3. 3. PRODUITS ONLINE CONCERNÉS 40+ personnes, 5 équipes Serveur Jeu Online prêt à l’emploi SDK (Framework logiciel) Online Multiplateforme - Résilient Services enrichis facile à intégrer 30+ personnes, 6 équipes Plateforme de gestion de communautés pour consoles et appareils mobiles
    4. 4. ORGANISATION INITIALE Requis CORE 1 Team Lead / Tech lead Développeurs (6 – 8 personnes) Équipe CORE 1 Équipe Management Besoins Deadlines Produit Date au besoin Requis CORE 2 Requis Service 1 Requis Service 2 Requis Release Équipe CORE 2 Équipe Service 1 Équipe Service 2 Équipe Release Productions (Jeux) Demandes Collaborations
    5. 5. CONTRAINTES Produit Rendez-Vous Support Framework Online (SDK) Base de services Online (évolution) Orientations technologiques Collaboration - Demandes Productions Déploiement - Opérabilité (outils)
    6. 6. CONSTAT DE DÉPART DANS L’ÉQUIPE - Pas de visibilité sur les tâches futures - Vision globale difficile à déchiffrer - Collaboration inter-équipe difficile - Envie de l’équipe de s’orienter en Scrum - Outils non adaptés au Flow
    7. 7. MISE EN PLACE DANS MON ÉQUIPE Attention du management pour passer aux autres équipes - Formation / introduction Scrum - Création rôle Scrum Master / Coach Agile - Constitution d’un premier backlog - Mise en place de Sprints bornés - Mise en place des rétrospectives - Création d’une définition de DONE - Introduction notion points - Estimations et Backlog Maintenance - Notion d’engagement de Sprint - Formalisation des concepts d’Epic et Spikes - Introduction du concept de Product Owner avec le Team Lead Mai 2012 Juin Juillet Août Septembre Octobre 2012
    8. 8. ON PASSE AUX AUTRES ÉQUIPES - Il y a de plus en plus de nouvelles personnes sur Rendez-Vous - Besoin de plus de structure et de formalisme - Nécessite plus de travail inter-équipes / Collaborations - Envie d’obtenir une vision du produit commune - Besoin de livraison incrémentale
    9. 9. TRANSITION APPUYÉE PAR L’OUTIL • L’outil était mal utilisé • Besoin de reposer la transition sur des éléments concrets • L’outil renforce l’adaptation du processus et favorise les interactions entre les personnes
    10. 10. MISE EN PLACE DANS LES AUTRES ÉQUIPES • Dans chacune des équipes : – Scrum Master/Coach pendant 2-3 Sprints – Mini Sprint 0 et formations – Sélection d’un Scrum Master • Suivi régulier en tant que Coach Agile • Communautés de pratique pour les Scrum Masters Equipe Core 1 Equipe Core 2 Equipe Service 1 Nov 2012 Décembre Janvier Février Mars Avril 2013
    11. 11. ORGANISATION INITIALE Requis CORE 1 Team Lead / Tech lead Développeurs (6 – 8 personnes) Équipe CORE 1 Équipe Management Besoins Deadlines Produit Date au besoin Requis CORE 2 Requis Service 1 Requis Service 2 Requis Release Équipe CORE 2 Équipe Service 1 Équipe Service 2 Équipe Release Productions (Jeux) Demandes Collaborations
    12. 12. ÉQUIPE SCRUM Backlog commun – Produit « Rendez-Vous » Product Owner Développeurs (6 – 8 personnes) Équipe CORE 1 Équipe Product Owner Produit Équipe CORE 2 Équipe Service 1 Équipe Service 2 Équipe Release Productions (Jeux) Demandes Collaborations Scrum Master Livraison incrémentale Directeurs Technique Product Managers
    13. 13. AMÉLIORATIONS APPORTÉES Les Comités (par spécialité) Mise en place de l’équipe « Product Owners » Rétrospectives tous les 6 mois Rencontres de priorisation toutes les semaines Mars 2013 Avril Mai Juin Juillet Août 2013
    14. 14. DÉFIS EN TANT QUE COACH • Au sein des équipes : – Pas de rôle de Product Owner – Adaptation du rôle de Product Owner pour les Team Leads de chaque équipe • Sur le plan personnel : – Conflit de rôle – Peu d’exemples de transitions au Groupe Technologique
    15. 15. CONTAGION À UPLAY • Discussion avec Leads • « Introduction à l’agilité » dans les équipes • Démonstration de l’importance du Coach Arrivée d’Isabelle en Juin 2013
    16. 16. OBJECTIFS POUR LA TRANSITION ATTENTES DE LA DIRECTION 1. Réduction des dépendances entre les équipes 2. Priorités communes à toutes les équipes 3. Meilleur travail d’équipe 4. Équipes auto-organisées Approche TOP DOWN
    17. 17. 1. FORMATION
    18. 18. ATTENTES DES ÉQUIPES ET DES LEADS Focus Pouvoir se concentrer sur une tâche à la fois, au moins un projet à la fois Que cessent les changements de priorités quotidiens Travailler sans interruptions Minimiser les imprévus Rôles Trouver un PO Valeurs agiles Événements Pratiques Moins de doc, plus de logiciel fonctionnel Transparence Respecter les boîtes de temps dans les mêlées quotidiennes Rendre plus efficaces les mêlées quotidiennes Faire des rétrospectives Utiliser les récits avec le bon format et le bon niveau de détail Utiliser les points d’effort Estimer en équipe Intégrer les urgences
    19. 19. ORGANISATION INITIALE DES ÉQUIPES Ops Tools & Automation Services UX & Art Projets Projet WiiU CurrentGen Playground NextGen Ops Engine UI Mobile QA
    20. 20. 2. ORGANISATION DES ÉQUIPES UX & Art UX Engine UI Mobile QA Engine UI Mobile QA Ops Tools & Automation Services UPlay Console UPlay Mobile Playground
    21. 21. 3. DÉMARRAGE DES ÉQUIPES Visibilité sur le processus Estimation en points Priorisé par importance Tâches ajoutées  début de product backlog Durée : de 1 à 3 jours consécutifs Résultats : 1. Meilleure vision d’ensemble pour tous 2. Backlog estimé et priorisé 3. Les équipiers apprennent à se connaître 4. On est prêts à sprinter
    22. 22. 4. ÉQUIPE OPS • Objectif : – minimiser les dérangements dans les équipes • Moyens : – Équipe dédiée – Membres en rotation – Tableau Kanban
    23. 23. 5. RÉAMÉNAGEMENT DES BUREAUX • Tous ont déménagé pour rejoindre leur équipe
    24. 24. 6. COACHING ET FORMATION DES SM Responsabilité individuelle Smells Coaching Approche empirique et amélioration continue
    25. 25. 7. COMMUNAUTÉS DE PRATIQUE • Objectif : – Partager les connaissances • Moyens : – Amener un sujet – En parler en groupe
    26. 26. 8. SUIVI DES POINTS D’ACTION
    27. 27. RÉSULTATS CONSTATÉS APRÈS 4 MOIS • Fierté • Énergie positive • Meilleure vision • On livre! • Portée “obligatoire” terminée d’avance • Coordination inter-équipes • Résolution de problèmes en équipe • Amélioration continue. Exemples : – Propriétaire de story (1ère étape vers une plus grande responsabilité de l’équipe) – Rencontre globale “Looking ahead” avec plusieurs membres des équipes
    28. 28. RÉSULTATS 1. Réduction des dépendances entre les équipes 2. Priorités communes à toutes les équipes 3. Meilleur travail d’équipe 4. Équipes auto-organisées
    29. 29. COMMUNIQUEZ… - Appropriez-vous le processus et parlez-en autour de vous - Évangélisez mais sans brutaliser! - Intégrez votre management dans la transition - Affichez des infos pertinentes, des métriques, des tableaux, des réussites…
    30. 30. CONCLUSIONS - Ne vous arrêtez pas au premier échec. Testez et adaptez! - Prenez le temps de comprendre les problèmes - Les 2 approches - ont combiné bottom-up et top-down - ont bâti sur la réalité présente - avaient le même objectif global

    ×